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

I fail to understand why a default/deny setup can't stop a zero-day. A zero-day might fool an AV, but it won't fool anti-exe or SRP.

 

Couple of questions for anyone... is Windows 7 immune to Zacinlo, i.e. is this just a concern to W10 users??
Also, HitmanPro.Alert does not appear to be targeted by Zacinlo, but can anyone tell me if HMPA can protect against Zacinlo?
Thank you!

 

RP- I actually did a video on one such method a year ago (Ophelia says that there are many other methods, but why would one believe a cat?).

As I'm precluded from posting links to my video on Wilders, just google 'NotPetya and Standard User Account". The search results will show 2 videos- the first from July 2 is "Notpetya vs Comodo Firewall" which gives an introduction to the malware. The second, from July 9th is 'NotPetya and Standard user Account" which may be of interest.

 

I would say that any OS that predates Win 8.1 would be more vulnerable to it. At least, Win 8.1+ offers methods to block the rootkit device driver via Secure Boot option. Also it should be noted that a clean install of Win 10 1607+ would have stopped it because all drivers must countersigned with a MS driver code signing cert.. The people most vulnerable to the rootkit are those running Win 10 Home that upgraded from Win 7 or 8.

I don't see how HMP-A could have stopped the rootkit device driver. It was a validity signed device driver and device drivers perform all types of low level system activities. As such, they are impossible to monitor by behavior.

 

It depends on your definition of anti-exec processing. If it is to block the execution of anything not specifically whitelisted. Specifically remote code execution:

1. Use a trusted system process that is whitelisted: https://www.andreafortuna.org/cyber...yload-and-execute-malicious-code-in-one-line/

2. Find a vulnerability in a whitelisted process and exploit it to download and run your malware code from memory: https://securityxploded.com/memory-execution-of-executable.php

For today's breed of malware you need a security solution that has a memory scanning component. A least you stand a chance of it picking up some code or behavior signature hit hopefully prior to any major system modification or data capturing occurs. Again since this is post-execution detection, you have a risk of partial malicious activities occurring prior to detection.

 

Here are a couple of Win trusted system binaries that can bypass most whitelisting solutions:

https://attack.mitre.org/wiki/Execution

Bottom line - the only way to positively stop malware abusing legit Windows processes is to use a HIPS. On a "clean" OS, set the HIPS to training mode for a while. After all process activity has been learned, switch the HIPS to policy mode. In policy mode, all process activity for which no existing HIPS rule exists will be blocked. Of course when there is an OS or app update or new app install, policy mode will have to be disabled and learning mode will have to be reinitiated. If the new app contains malicious code of course it will be allowed in learning mode.

Even after all this, you can still get nailed because most HIPS's will ignore or can't monitor malicious shell code running from a previously allowed process. Nor can most HIPS's detect parameter arguments that would cause a previous learned safe process to perform malicious activities as in the above Mavinject.exe example.

 

or use SRP solutions but that assume people knows about Windows's processes and install it on a clean system.

 

Most anti-exec and SRP solutions can also block or monitor vulnerable processes such as cmd, mshta, powershell, etc.
With a secured and updated browser, and with avoiding MS Office and Adobe PDF products (or locking them down), the default/deny user should be safe from most known threats, I would think. I mean, there has to be an attack vector, right?

 

You sabotaged all the effort put into using SUA by manually elevating program by "Run as administrator". You should have "Behavior of the elevation prompt for standard user" set to "Automatically deny elevation requests". NotPetya has abilities to harvest credentials elevate privileges, but it can't be done without manually granting these credentials first.
NotPetya also contains NSA exploit. Fortunately vulnerability used by exploit was patched long time ago, so up-to-date OSes are immune to this exploit.
Petya was dangerous, because it had zero-day exploit back then and I understand that zero-day exploit usually can't be mitigated by SUA. At the same time it is not so likely that mindful, knowledgeable is going execute untrusted, shiny new program with zero-day exploit on its personal computer (maybe excluding Javascript on the web, but browsers have quite strong sandboxes).

 

And if anyone is still worried that malware will elevate in a standard user account, OSArmor has some good rules for that.

 

RP- I guess you didn't really view the entire video. The "Run as Admin" section was just a fill-in to answer a question from someone (I tended to ramble on my videos); what you actually wanted to see was after the final fade at 2:45 of the video. Here the malware was just run on a Standard account- no tricks, no magic.

Also, please understand that the NSA exploits (E Blue and E Romance) were included in the initial malware for Network spread. The malware used in this video (modified and with a single endpoint victim) was run on an updated Win7 system and did not include any exploit. When this malware was initially reported, the concentration for whatever reason (whether from ignorance or the need to impress) was on the NSA exploits. The Press failed to note that the malware was morphed into a single endpoint variant where network spread was not needed.

Finally, the mechanism to bypass SUA that was used with Notpetya was not new, just not utilized. There are actually a number of ways to defeat such security measures, but why should a Blackhat bother? There is more than enough Low Hanging Fruit (those running as Admin with traditional AV in place) to make more complex infection modalities a Game not worth the Candle.

 

That's a good point. Bypassing SUA is not what most malware is doing, even though theoretically, it could be done.

 

It's not theoretical:

From the comments in;
DoubleAgent: Zero-Day Code Injection and Persistence Technique: https://cybellum.com/doubleagentzero-day-code-injection-and-persistence-technique/

Another method here: https://www.fortinet.com/blog/threa...-to-elevate-privilege-for-fareit-malware.html

 

Shmu- Yeah- but why bother? There are just so many of the "Windows defender and Windows firewall are Enough" Home User crowd to make coding something more complex just not worth the time.

As a sidenote- I was Point on a Post Mortem for a multi-hundreds of Millions USD retail breach. I was amazed that the Talkers from the Enterprise Security Solution that was bypassed had the absolute Gall to minimize the malware that cut through their protection like butter as being "coded by a 15 year old". I guess the Fools thought that malware must be complex to be effective.

BlackHat Rule #3- Complex malware is less easily morphed and more easily detected, so keep it simple.

 

Yes, as I mentioned it also has ability to steal credentials.

SUA don't have write permissions to this registry key.

It is a method to elevate privileges on Admin account protected by bypassable UAC mechanism. User using SUA (I am not talking about account in the Administrators group) is executing eventvwr.exe at Medium integrity therefore it won't work.

 

I really do get tired of these endlessly SUA discussions on Wilders.

If Microsoft thought that SUA and likewise UAC and SRP were effective security boundaries which official they do not, they would have long ago had the OS upon installation create SUA as the default user account. Also, malware would have been stopped "in its tracks" and there would be no need for additional security mechanisms.

The above are nothing more than access restriction mechanisms within OS. They are effective in corp. and home environments for restricting user access to areas that should only be done so by administrators. These mechanisms will indirectly slow down "run of the mill" malware's damage but can easily be bypassed by advanced threats.

 

@cruelsister
I've watched your video regarding NotPetya and SUA. I have one question. How was your SUA set up? In your second test (before NotPetya) you've tried to use "Run as Administrator" option but you didn't get a prompt to enter Administrator credentials. Do you have elevation auto-blocked?

 

AFAIK, MS regards SUA as a security boundary, but not UAC. Off course it's not "bullet-proof" boundary.

 

The reason why Microsoft doesn't push these security features is probably because they are too restrictive and aggravating for the average user. They take away from the "great user experience" that MS is trying to sell consumers. But that doesn't mean they don't work...

 

FYI - I was a senior systems consultant employed by a well known international consulting firm for a number of years. I had numerous clients; most were Fortune 200 concerns. Not one of those concerns set up their client devices to run as SUA; they were all limited admins. I was also employed by the U.S. gov. for a number of years. Likewise, all client devices at the agency I worked for were limited admins. Of course, they used SRP and other access restrictions to limit what users can do.

Finally, Microsoft itself is "throwing in the towel" on SRP:

https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features

 

Hm, I guess there are different approaches when it comes to security. Our company is working with some medium size companies that have their own IT departments.
Endpoint users always log in as domain users and they are never members of administrator group. Even for local login they don't have that rights. Only few administrators have local administrator or domain administrator rights.
And this are not such large companies...

 

As noted in this article and others, SUA and SRP can be bypassed by fileless malware attacks:

http://mechbgon.com/srp/

 

No- it does not require elevation; that was actually the point of that little snippet- I added it as someone at MT had previously asked. The malware could care less what Account type is being used, whether UAC is on or off, etc.

Also please understand that for a certain segment seeing all that they had thought was true was actually a lie is unacceptable. I was both a peon (at the start) and then headed Breach remediation teams and it always made me sad that IT would NEVER accept that malware could breach the unbreachable security that they had put in place (if only this was true! We would NEVER have had millions of credit card data being stolen from major retailers, nor would the ENTIRE STORY OF MY LIFE be sitting on a Server somewhere in the Far East- so much for Limited Admin and SRP...).

 

No one claimed that any of these security features on its own does the whole job. A table needs 3 or 4 legs to be stable, right?

 

Actually many claim that these security features "are enough". And it is not hard for malware to knock out any or all of the 3 or 4 legs that MS provides.

But whatever! believe what you want!

(And if there ever was a topic that should be closed...)