Many firms hit by global cyber-attacks

"Petya.2017 is a wiper not a ransomware...

TLDR: The ransonware was a lure for the media, this version of Petya actually wipes the first sectors of the disk like we have seen with malwares such as Shamoon...

After comparing both implementation, we noticed that the current implemented that massively infected multiple entities Ukraine was in fact a wiper which just trashed the 25 first sector blocks of the disk...

The first sector block is being reversibly encoded by XORed with the 0x7 key and saved later in the 34th block. But since it replaces it with a new bootloader
that would mean that 24 sector blocks following the first sector block are being purposely overwritten, they are not read or saved anywhere. Whereas the original 2016 Petya version correctly reads each sector block and reversibly encode them...

2016 Petya modifies the disk in a way where it can actually revert its changes. Whereas, 2017 Petya does permanent and irreversible damages to the disk...

This means the MBR section of the disk is purposely over written by the new bootloader...

We believe the ransomware was in fact a lure to control the media narrative, especially after the WannaCry incidents to attract the attention on some mysterious hacker group rather than a national state attacker like we have seen in the past in cases that involved wipers such as Shamoon..."

https://blog.comae.io/petya-2017-is-a-wiper-not-a-ransomware-9ea1d8961d3b

 

Haven't read all of the articles yet, but seems like this is basically Wannacry part 2, so nothing new. All of those companies should be ashamed that they didn't take any extra security measures. But it's sure good for business, a lot of security companies are now doing very well on the stock market.

 

@Rasheed187

Read the post above yours -- it may cause you to rethink your post

 

FedEx halts trading after cyberattack affects TNT Express operations

"FedEx cyberattack damage 'could be material'...

In an announcement Wednesday, the company based in Memphis, Tennessee, said it had been "significantly affected" by the malicious program, which emerged in Ukraine on Tuesday before spreading around the world..."

http://hosted.ap.org/dynamic/storie...ME&TEMPLATE=DEFAULT&CTIME=2017-06-28-13-25-33

 

Fed-EX was hit last time too

 

"...This isn't ransomware – it's merry chaos...

As more details about the malware come in, the whole affair is looking very fishy and atypical. There is a confluence of little pieces of evidence that suggest this is not a run-of-the-mill criminal malware attack, but might serve a darker purpose..."

https://www.theregister.co.uk/2017/06/28/petya_notpetya_ransomware/?page=2

 

Pfft, a comment I made about updates was general--every business I've walked into: clinic, store, etc is running Windows 7. Who knows if they're updated, that's their problem, don't make it my problem with your carelessness.. OK, I see Federal Express was hit again, let's see how that affects the global market, along with everything else.

It's understood that a different approach would be used in the second attack as no one got wise to that one yet. Everyone has a strong suspicion which nation is behind this but no one yet has "claimed responsibility," like a faction might after a truck bomb. I said this is evil because the attackers remain hidden, unpredictable and free to strike again. What power, right?

 

"ExPetr/Petya/NotPetya is a Wiper, Not Ransomware...

After an analysis of the encryption routine of the malware used in the Petya/ExPetr attacks, we have confirmed that the threat actor cannot decrypt victims’ disk, even if a payment was made.

This supports the theory that this malware campaign was not designed as a ransomware attack for financial gain. Instead, it appears it was designed as a wiper pretending to be ransomware...

Our friend Matt Suiche from Comae Technologies [**] independently came to the same conclusion..."

https://securelist.com/expetrpetyanotpetya-is-a-wiper-not-ransomware/78902/

** https://www.wilderssecurity.com/thr...obal-cyber-attacks.395036/page-5#post-2688444

Edit: Kaspersky confirms:

"...'We have analyzed the high level code of the encryption routine and we have figured out that after disk encryption, the threat actor could not decrypt victims’ disks.'..."

https://threatpost.com/little-hope-to-recover-data-lost-to-petya-ransomware/126598/

 

My goodness.

The more things change, the more they stay the same. No escape. (yet)

There used to be various types of Wiper (KillDisk) malware on XP and of course courtesy 32bit easily transitionable over to Windows 7 and beyond.

I suppose WoW64, as x86 emulator, will also continue to allow 32-bit Windows-based applications/code to run seamlessly on 64-bit Windows for the foreseeable future.

https://cyber-sec-news.blogspot.com/2017/06/expetrpetyanotpetya-is-wiper-not.html

 

So should AV's flag it as FakeRansomware, NonPetya or Drive wiper? This is a dilemma.
From what I see is it comes in 32 & 64 bit.

 

If I read the deciphered traced code patterns right and this old article right.

https://social.technet.microsoft.co...fe30/cryptoapi-disabled?forum=w7itprosecurity

Please someone who is better adapt to this then I am, be at liberty to spell out why Microsoft is left this API so loose that malware(s) can so easily tap into that library within the Windows machines.

Which apparently is what this latest strain was coded up to take advantage of?

Of course other/some ransomwares also include their own crypto libraries and avoid using the M$ crypto API entirely, dodging that routine. But if it's already there for them to use?

 

Remember this ...

https://www.ghacks.net/2016/10/21/mbrfilter-protects-the-master-boot-record-against-manipulation/

 

Yes we do remember it but how are you going to get home users and enterprises to use that?

 

I do not understand why not all, if not most, popular and highly demanding security vendors cannot already protect against the Petya payload. All samples of Petya I have seen are executing from user-mode and are not even that sophisticated, they merely rely on basic Win32 API functions to perform the Master Boot Record overwrite through opening a handle via kernel32.dll!CreateFile to "\\.\\PhysicalDrive0" and then overwrite the 512 bytes with the custom boot loader (512 bytes since that is how large the MBR is at all times, of course with the 55 AA boot sector at the end).

There is simply no excuse for the AV vendors which cannot dynamically protect against the attack. They do not need to rely on static detection methods to detect Petya samples through standard checksum hash signatures and generic (HEX) signatures; all they need to do is restrict write access to the PhysicalDrive0 - they can accomplish this through detouring NtWriteFile within unknown running processes, or alternatively take the more secure route and restrict access from within a device driver. Using either one of those two mitigation methods they would have decent protection and all current samples of Petya would fail to successfully deploy the attack due to not having the correct desired access to the MBR to overwrite the contents.

Obviously the device driver route would be much more sufficient and secure although the first method through code injection and detouring of NtWriteFile would also be quite sufficient and get the job done since no samples of Petya (which I have seen yet) make use of manual system calls, they don't even call the NTAPI functions directly... Just Win32 API functions. The samples themselves are not actually sophisticated at all.

If you wish to manually block the attack instead of relying on your primary AV solution, I suggest you invest time using something like MBR Filter (which is also open source and available on GitHub). Anything that will protect the MBR will be sufficient.

Sorry but it is pretty silly that vendors have teams of experienced software engineers, some being very experienced with device driver development, who are unable to implement such a feature? It should take no longer than a few hours for them to implement a PoC of MBR protection, maximum a few days - a week for extensive testing to ensure the feature works correctly as intended. Very interesting...

 

Again most Wilders members know how to protect against these kinds of attacks and they most likely won't bother regular users only targeted members but still most enterprises won't use them to lock down systems since it is too hard for them to do.

 

Hmm... Fair enough point. I just don't understand why it would be so difficult for AV vendors to implement such a feature when they are capable of working the hyper-visor... E.g. Kaspersky use the hyper-visor for screen capture protection and Comodo obviously use it for their sandbox feature yet they cannot restrict access to PhysicalDrive0?

Its not like it would interfere with much. How often do you find genuine software trying to access the MBR with the exception of a user manually trying to access it via a HEX editor of some sort? If they implemented an MBR restriction feature which only applied to unknown programs to the cloud then it would work even better.

 

Link for 32/64 bit flavours of MBR filter mentioned above...

https://www.talosintelligence.com/mbrfilter

 

"A worm is a worm" folks.

As noted in the above posted Microsoft TechNet article, the easiest way to spread it in a network is via an unpatched server:

Of course, this is not the only way you can get nailed by a worm:

 

I´m not following this in detail, but regarding the MBR:

- Shadow Defender protects the MBR.
- If this malware depends on altering the MBR, it means it doesn´t affect GPT disks.

 

Difference between this attack and WannaCry:

https://www.infosecurity-magazine.com/news/maersk-confirms-ransomware/

 

I don't think you'll get much in the way of any arguments on that from most of us here.

There is been past research on similar methods just like this used to drive a wedge between user/corp. network and machine as described here from back in 2013.

https://securelist.com/destructive-malware-five-wipers-in-the-spotlight/58194/

 

You might also want to include the stand-alone anti-ransomware software. As best as I can determine, they also would have been bypassed.

The simple answer is it depends on who is the attacker. In the majority of cases it appears, the attacker was a trusted process updater that was applying a malicious hijacked update file. Being an updater, it was running with Trusted Installer privileges; more than enough access to run PsExec via remote access means. This attack obviously would have bypassed any anti-exec detection since the updater would have been a whitelisted trusted process. Most major AV's did have a positive signature for the update file within a few hours. Some of those probably detected the malicious update file initially via generic signature detection.

 

Yup.

If a malware runs as a trusted file, an AV or AM will assume there's a legitimate elevated process running.

Easy enough to hack a trusted file, with calamitous consequences. Only so much security software can do.

 

What's the difference on MBR & MFT? One is as vulnerable as the other isn't it in a situation like this?

Can't BOTH be backed up and saved to file with certain MBR Tools BEFORE issues and simply restored?