Rootkit-Based Adware Wreaks Havoc Among Windows 10 Users in the US

Guys- Please forget about the Petya part of the video! Obviously the point I was trying to make was either poorly done and/or not understood. I just wanted to show that the original Petya would be contained by someone using SUA. That's it! I added the original Petya ONLY to contrast it with the later NotPetya variant.

And as far as UAC bypass is concerned, the bulk of malware extent does not need privilege escalation.

 

Yes credentials theft and vulnerability exploitation can be used to elevate from SUA.

 

On that regard:

https://answers.microsoft.com/en-us...tion-for/00282c2c-a222-44ef-8c83-cf9e34731c06

 

Hi Min! Yeah, sorry for that omission. I actually should have left out Parts 1 and 2 of the video. This would have negated any confusion, but I had to add something so I could fit in the song.

Considering the amount of comments on this video- I always fervently hoped that there would have been some discussion like what is seen on this thread over the inability of well regarded products to detect and eradicate various scriptors (like worms). These are a HELL of a lot more prevalent that any ransomware strain; God knows that I concentrated my efforts in this area but was always met without a peep (except for some fancy sidestepping dances by the Loman boys).

 

The article is based on a report made in 2013, and furthermore, neither the article nor the original report discusses specific strains of malware or their prevalence or severity.
It is a generalized analysis of the mechanism of admin account versus SUA.
Nevertheless, the author says in conclusion that he sees a significant advantage to SUA, for the sake of "damage control".

 

Yes, but SUA can't for example change firewall rules, so malware can be denied access to network - prevention of data leakage.
Second copy of files can prevent data loss by deleting or encrypting by malware. This second copy can be even stored on the same partition, just other directory and appropriate permissions to isolate copy of files from malware. This does not prevent data loss from drive failure, but is enough to prevent loss by malicious activity of malware.

 

That point I will agree with you on.

The main points about SUA are:

1. It will not prevent you from getting infected.
2. Once malware has established itself on a device, you are in a "lose lose" situation.

Again if Microsoft thought that SUA was an effective malware mitigation, they would have long ago made it the mandatory logon account.

 

IMO main purpose of SUA is not solely malware mitigation, it's rather preventing system-wide changes done by SUA users. So in principle, if SUA gets infected, admin could just log in as Administrator, delete old SUA account, create another one and system would remain clean without a need to reinstall it. Of course malware could still encrypt or upload any data that SUA has access to.
In past, I've also read some research that majority of malware still requires admin privileges when run. It's probably because it can get them from regular users. So using SUA instead of admin could prevent some malware from running or correctly running.

 

Yes weird. But it would be very cool to test this malware against behavior blockers, because we're talking about a scenario where people think it's a legit VPN app, and lots of AV's failed to block it via signature scanning. I've read most of the report, and HIPS should alert about the driver loading and outbound connections being made, but if you trust the app, you will probably allow it. And I'm not sure if BB's are monitoring the Windows Certificate Store, but I assume the MITM attack is also done via API hooking of the browser, which should be blocked.

 

I checked the file hashes for it that were listed in the BD article at VirusTotal. Many detected its installer with only a few detecting the actual executable variants. Interestingly, Windows Defender detected all the file hashes at VT.

My understanding is the fake VPN, s5Mark, has to be installed to be functional. So I would say that non-detection of its components was blown out of proportion by BD. I am also always skeptical of VT detections since its only running the AV's realtime engine w/o any supporting detection components.

We've discussed this before. Not all HIPS monitor driver loading with most only monitoring driver installation. And in this instance, the driver was a legit properly signed device driver.

 

OK, then I don't see what all the fuzz is about. But to me it's always interesting to know how to block stuff post execution.

A good HIPS will monitor this, for example SpyShelter wil always alert about this, even if the driver gets modified. But if you trust the app, it's probably game over depending on how advanced the driver/rootkit is.

What I didn't understand is how it targets other security software, aren't they protected from tampering by malicious drivers? Especially on Windows 64 bit, rootkits shouldn't be able to modify the kernel in order to get full privileges, so I'm a bit surprised by this.

 

You often say that Win Firewall can be easily bypassed, but if you use a tool like WFC, it will block all apps including malware from adding inbound/outbound rules, are you aware of this? Or is this still not good enough? And third party firewalls can also be bypassed if they are not monitoring code injection.

https://www.binisoft.org/wfc.php

I don't see how a firewall would have blocked this, because people thought it was a VPN app, so that's the tricky part. It performs things that look normal, like getting network access and driver loading. So would be very cool to see which behavior blocker would alert about it.

 

Every driver loaded into kernel on x86/amd64 architecture (ring 0) is able to modify the kernel in some way. PatchGuard is as effective as UAC. You don't want to load malicious driver.

 

Thought I explained that. In Win 10, many are using the ELAM driver that allows their kernel process to load prior to any other apps. This also provides for PPL protection. Also many AV's have additional self-defense mechanisms but those can only be deployed via their kernel process and/or kernel mode drivers.

Remember our driver discussions of past? The earlier a kernel mode driver loads, the more harm potential it has. It can intercept activities for any driver that loads after it. Device drivers load at boot time prior to any app drivers including security software ones.

The "ultimate" malware driver would be one that loads prior to any other driver at boot time. -EDIT- Actually, there's a worse one; MBR malware aka Eternal/NoPetra: https://countuponsecurity.com/2017/07/02/analysis-of-a-master-boot-record-eternalpetya/

This explains driver load order in Window: https://docs.microsoft.com/en-us/wi...s/ifs/what-determines-when-a-driver-is-loaded . Device drivers load with this setting - SERVICE_BOOT_START (0x00000000).

 

Hi Rasheed! Yes, I am aware and have been praying folk would switch to using things like WFC, Private Firewall, etc. I consider employing an app like these essential for one serious about computer security.

Actually 3rd party firewalls are natively aware of code injection and will invariably stop such processes from connecting out without any user input.

 

As far as disabling AV software by this bugger, s5Mark has a component that does this called SmartService. Bleepingcomputer.com has an article on it here: https://www.bleepingcomputer.com/ne...are-bodyguard-by-blocking-antivirus-software/.

This second bugger's installer was bundled in the s5Mark installer and being detected by most AV's as of 4/2017. It shows it installed in the Program Files directory as "s5.exe" which was referenced in the BD article. My money is on this Zocinio malware creator dropped the separate SmartService installer and incorporated it into the s5Mark installer.

 

OK, I just wanted to double check, because as long as you block unauthorized rules, then the Win Firewall is pretty good. I'm not sure if tools like TinyWall and GlassWire also offer this feature, it was one of the main reasons I switched to WFC.

No way, on Win XP the situation was way worse. Rootkits could modify crucial parts of the kernel, that''s not possible anymore with PatchGuard, but apparently it's still possible to attack other kernel drivers.

Yes, and you would think that ELAM would prevent malicious drivers from tampering with drivers from security tools. But apparently that's not what it's meant for. So once a malicious driver is able to run then you might be in trouble, even on Win 8 and 10.

https://www.techopedia.com/definition/29079/early-launch-anti-malware-elam-windows-8

 

Again, refresh yourself with PC driver loading concepts.

Low level device drivers are loaded by BIOS via the boot loader. They are needed to load the OS. The OS needs to be loaded and functional before any apps can be loaded including the security kernel process.

Most of the major AV's employ early loading protection device driver/s. However, none are loaded prior to low level OS device drivers. The Win 10 ELAM driver allows the AV kernel process to load prior to any other app process and non-low level OS processes. The AV kernel process must be loaded and functional to communicate with its low level device drivers.

Finally, driver loading order determines driver event servicing priority. The first (lowest memory space) drivers have a higher priority than latter loaded drivers.

-EDIT- Note that in this s5Mark adware incident, the valid at the time signed driver was created by an Installer; it was not just "dropped" on the target device. Also there are other adwares that do like activity. So your best protection is not to install free crapware.

 

No it is not.

 

I don't think that's the point. The point is that apparently this malware is able to target both AV processes and drivers and that shouldn't be possible. AV's are supposed to protect themselves from being disabled. But apparently the Windows OS doesn't give this capability, so once a malicious process combined with driver has got admin/system rights it can do whatever the hell it wants? I do know that HIPS in the past were able to block apps from terminating processes.

Can you expand on this, because you just said that you recommend to use a management tool like WFC, and now you're saying that it's not good enough? So why exactly do you prefer a third party firewall over the Win Firewall? From a technical point of view it does the job.

 

Yeah, I can't remember its name. It loaded a device driver that loaded very early in the boot process. Worked great on Win XP. The introduction of x(64) patch guard was the end for these HIPS's.

Also we are not talking about "apps from terminating processes." Rather its a malicious kernel mode device driver performing this activity.

 

I’m kind of weary to use third party firewall software ever since I saw that av-comparatives test where most of the vendors flunked out on basic inbound protection.

The one time I got compromised I was running an outbound firewall, and it didn’t make a peep. I’m sure the technology has improved a lot since then, but the only thing that saved me was I was glanced at the outbound firewall log and saw it connecting out using some white-listed windows service.

 

Sounds like this malware used process hollowing and apparently this third party firewall was fooled by that.

Yes correct, HIPS should be able to block a process from terminating another process, but I'm not sure if it can block a driver from directly stopping processes.

 

Could have been. I think it was one of these exploits that got me: https://www.cvedetails.com/vulnerab...t_id-1032/Microsoft-Windows-Media-Player.html
But it's been years and I can't for the life of me remember which one. Pay attention to file sizes on TV show downloads