DoubleAgent: Taking Full Control Over Your Antivirus

Here is a list of some AVs that support ELAM: https://www.wilderssecurity.com/thr...re-and-avs-supporting-it.369386/#post-2646974

 

For those interested in ESET with respect to this topic:
Interesting thread at their forum: https://forum.eset.com/topic/11394-zero-day-exploit/
Michael Engstler (Co-Founder & CTO, Cybellum) posted there about an hour ago. He had informed ESET in November 2016 and had been working with them on it, and had been rewarded for that by ESET. Marcos replied and said that since yesterday there is more protection in ESET (my own words). Effin, you can read it there.

EDIT: just noticed that itman already posted the ESET forum link. Didn't know that while I was posting. Sorry!

 

Where I can read (perhaps I missed to read some lines don't know where) to realize it was so obvious ELAM driver is only available on Win 10.

 

Btw I can watch such ELAM driver in my Win 8.1...

Decide to install ESET A/V just for testing and look:

Spoiler

 

I stand corrected. Thought it was only available in Win 10.

 

Now this is confusing for me but I can't watch neither FIDES nor cmdScanner services on Process Explorer 64/Process Hacker 2. Need help on this.

I found them in Process Hacker 2:

Spoiler

 

Thanks. I'll check it out.

But what I meant above is I want to see which processes of my security progs are protected just like ESET's one. And btw none of them so far.

 

Hi Peter,

The tool is called FolderChangesView and can be found here:
http://www.nirsoft.net/utils/folder_changes_view.html
BTW my NOD32 is giving warnings, but that has happened before there.

 

yes because all AVs flagged Nirsoft products as "malicious" because they can be used for malicious purposes.

 

Anyone figure out why? Eset especially is pretty benign when it comes to flagging system-like utilities, keylogger test software, etc..

 

Just for security reasons I've put the Nirsoft link between plain-tags now.

Peter, your welcome!

Guest, I know. Whether all AVs do it, I don't know though.

itman, with respect to Eset: I do like NOD32. It is pretty good at flagging "things".

In general: have I used some Nirsoft tools in the past? Yes, I needed some tool(s) from them.
What file-integrity-checkers I use: ADinf32 Pro and the no-more-available but still so very good NISFileCheck.

 

Isn't a better way to just protect AppGuard's service (and others vendors too) by using cryptographic security that protects the system from the creation or promotion of arbitrary processes to protected status and 3rd party developers to create their own protected processes?
https://www.crowdstrike.com/blog/pr...s-signing-levels-scenarios-signers-root-keys/

 

Theoretically you could just use MemProtect to protect these silly AV processes and allow them to run as Protected Processes with more granularity and control. Although you would have to be absolutely cautious and thorough with permissions. This would also bring Protected Processes back to Windows 7 and others.

 

Cybellum has clarified in an update to the original posting that:

So admin or higher privileges are required.

That said, Cybellum also posted a utube video showing a bypass of Eset's Image File Execution registry keys. Appears it modified its unprotected mode gui process and was able to change those key's permissions allowing it to register its .dll there. I am now protecting those keys with a HIPS rule which will work since my Eset kernel process is running OS kernel level protected. This bypass also does not bode well for other security solutions running as an unprotected process suggested mitigation to protect corresponding registry keys.

 

Exactly. In my case, and for others too, AppGuard's, ERP's, FIDES, cmdScanner's, Sandboxie's, AppCheck's, and a long etc. needs to have their respective ELAM driver to ensure its OS kernel level protection and Image File Execution registry keys protections.

Are you guys, those who actually have good nexus with those vendors, going to contact them to fix this?

 

For Appguard , there is a business angle to consider, i guess. Appguard is mainly a corporate products also used by gov agencies and military; and surely most of them don't run on Win8/10.

ELAM is more an AV thingy , SRP soft aren't much concerned by it. also, Microsoft requires that Early Launch Antimalware vendors be members of the Microsoft Virus Initiative (MVI).
BRN isn't.

prerequisites for MVI:

- Your organization publishes antimalware testing reports on a regular basis.
- Your organization has a research or response team dedicated to fighting malware to protect your organization, your customers, or the general public.

 

Because many Nirsoft tools are useful for attackers, password breaker, network sniffer tools, packet capture tools, etc...

 

AppGuard doesn't need an ELAM driver.

The ELAM driver eligibility requirements - first and foremost must be a member of the MVI - among others:

https://www.microsoft.com/en-us/security/portal/mmpc/mvi/virus_initiative_criteria.aspx

Lots of security soft publishers won't even come close to qualifying even if they are willing to shell out the train-load of money required to jump through all the hoops just to be eligible to submit the applications.

 

Alright. Got it.

 

Now that this thread has run a while, I will say this. The ELAM driver although effective is far from malware "bullet proof." To be such, it would have to be the first driver loaded which it is not. It is just the first application based driver loaded. You can verify where it is loaded by enabling boot logging and viewing the resultant log file created.

All malware has to do is load its kernel driver prior to the ELAM driver and it can intercept the ELAM driver when it is loading. An APT with such capability is Turla which bypassed both Windows driver signature enforcement and PatchGuard: https://www.lastline.com/labsblog/dissecting-turla-rootkit-malware-using-dynamic-analysis/ . Lucky for us end users, these types of APTs are employed by nation state actors against their counterparts.

 

Oh,my .......... Appears, Cybellum has taken "FUD" to unpresented levels in this POC. My mistake was not reading all the technical details until now.

In regards to its File Execution Options registry bypass is this:

Appears Cybellum employed the entire old leak tests arsenal to discredit existing AV vendor products.

SC Magazine just published an article with all of the vendor responses to date here: https://www.scmagazine.com/doubleag...oftware-into-your-worst-enemy/article/646173/ . Notable is the statement by a number of vendors that the Microsoft tool employed by Cybellum can inject a .dll into any process; not just any unprotected AV process.

So the real "culprit" in all these like recent "nonsense" incidents is Microsoft for allowing all these potentially dangerous utility processes to exist in the first place.

 

Thanks itman for that article.

PS: for ESET users:
ESET has published a Customer Advisory today:
"DoubleAgent code injection and process hijacking explained"
http://support.eset.com/ca6376/

 

Yeah, I just ran my own tests and Eset blocked all attempted previously noted bypasses. Note: you will not receive an Eset alert for the attempted registry mods. but a generic popup window in regedit for example that the attempted action is not allowed.