New Attack Uses Microsoft's Application Verifier to Hijack Antivirus Software

If you mean that CIS doesn’t do command-line analysis of python scripts? Which can be easily addressed by adding *\python.exe and *\pythonw.exe to the heuristic command-line analysis for certain applications list. Which I thought was strange when looking at the list, that perl was there but not python and I consider python to be more widespread on windows than perl. Of course it requires python to be installed on a users PC for this particular attack to work.

Exactly. Its a configuration issue. You are right about python. We will simply make this part of default config so you dont have to add it manually. Thats all.

It’s not really practical anyway since it needs administrator rights.

MichaelEngstler,

Which AV were tested or only those listed in the list?

Thank you.

The problem remains the same, secure files are not trusted, they can be used to run malicious code. For example: trojancrypt use dllhost, wscript … but for being considered system files are allowed by default.

On boot failure and execution on system boot, in the vast majority of cases, extraction takes place for boot folders or run lines run through runonce, rundll, dllhost, cmd, conhost …

This topic just started over here>>>> Windows 'DoubleAgent' Attack Turns AV Tools into Malware | PC Help Forum

Here’s more info on it>>>>> Windows 'DoubleAgent' Attack Turns AV Tools into Malware

Good marketing, I guess. :-La

Hi,

I am wondering if this bypass have something to do with the removed feature after CIS 3 to intercept dll injections?

Post 2: (CIS 5 failed)

Post 6: (CIS 3 passed but impractical)

Thanks!

If you are running with administrator rights and you take away Sandbox, HIPS then you cannot stop it. This behavior is intended and there is no vulnerability. You can do pretty much anything as administrator and that’s the way it should be. Just try to kill a process, load drivers, whatever. It’s not a traditional AV. You could look at it as a test for embedded code detection in best case.
I disagree with proposed solution. [at]liosant has a good point-- you solve the issue for unsigned DLLs but that’s it. It’s a partial solution. This is only useful for troubleshooting when a DLL breaks the application and you’d want to blacklist it.