DoubleAgent: Taking Full Control Over Your Antivirus

As far as those who will state running as a SUA will prevent Application Verifier from running is this tidbit. Also believe this "blows holes" in the running as admin rebuttals:

https://msdn.microsoft.com/en-us/library/ms220948(v=vs.90).aspx

 

So would running Application Verifier under SUA allow it to make changes to those registry keys with no Admin rights?

 

Thanks for the update

 

Let's back up a bit.

Appears Cybellum is not just doing FUD, but is doing much more. For starters, Application Verifier most likely is not even installed on your PC:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff538115(v=vs.85).aspxhttps://msdn.microsoft.com/en-us/library/windows/hardware/ff538115(v=vs.85).aspx

I just checked my Win 10 x64 1607 build. Appverif.exe and Appverif.chm do not exist. So either you intentionally installed Windows Software Development Kit or malware downloaded Appverif.exe and Appverif.chm. Let's go with the second scenario.

Malware fingerprints your system and IDs your SUA info. Hacker then opens up his copy of Appverif.exe and sets up system access rights for the SUA. I am assuming that its possible with Application Verify to grant access rights to a SUA that would be denied under its normal permissions. Malware then downloads and ideally copies the hacked version to System32 directory. Since its a validly signed .exe in a system directory, it will bypass most anti-exec's. The malware also has to download .exe, script, whatever that will run the hacked Appverif.exe. Next malware dropper has create a means to run the payload at next boot time; RunOnce reg. key would be ideal. Finally, the malware dropper has to perform the registry activity noted in reply #51. SUA logons on, hacked Appverif.exe runs hidden, you're nailed. Obviously, other malware infection vectors possible than this one.

 

I doubt that the part I bolded is possible without admin rights. Few AV companies also noted in their response that admin rights are needed to perform those actions. So I still think that without admin rights this couldn't be pulled off. Still great to see vendors released new versions with additional protections

 

I am not too worried. if UAC set to high, Voodoo don't block it Appguard will .

 

Can't go there: http://54.200.58.62/?nxdomain=http:...latformInfo=DNSA&Version=3.0.5&blockedDomain=

 

Not so sure about that.

Based on the below, Application Verifier can hook a higher privileged process while running in SUA mode. Once a hook is established, you can do anything through it.

https://blogs.technet.microsoft.com/askperf/2009/05/22/two-minute-drill-application-verifier/

Also agree that privately notifying software vendors including Microsoft about vulnerabilities is worthless. Just publically disclose it and those are fixed in hours.

 

Maybe your router blocks access to that site?
You can check if IP in Url that you posted it the same as your IP. If so you should probably edit your post and hide it.

 

Me also! That is, what those "unknown code injection features" are.

 

Thank bro. That not my ip address.

https://safeweb.norton.com/report/show?url=www.kernelmode.info

https://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=24312

 

As I understand it can monitor interaction of apps in SUA mode with OS. It doesn't mean that itself is running in SUA mode. It probably has to run with admin rights to do what it's intended to do.

 

Picked this up from a comment on the Cybellum blog. Appears their "exploit" was copied verbatim from Microsoft: https://blogs.msdn.microsoft.com/reiley/2012/08/17/a-debugging-approach-to-application-verifier/

 

It need admin rights, so if you are in SUA and doesn't allow it in the first place, this malware is just BS for noobs.

 

Yes, so far I didn't hear of any tool that would be intentionally allowed to bypass this AUA/SUA security boundary (doing admin stuff with app running under SUA). I also doubt that MS would ever make such security hole.

 

In regards to SUA being bypassed, Avast below again notes that is indeed possible and well known. But it appears, people just want to believe that cannot happen:

http://infosechotspot.com/microsoft...urn-antivirus-software-into-your-worst-enemy/

 

Lame excuses by AV companies, just keep popping up. It is interesting to see, how many actually take it like a man and admit a failure by fixing it.

 

And yet there is nothing in that quote about SUA bypass. As usually user with admin rights can do harm to their computer and AV can help here. Nothing new, really.
Of course there were (and might still be) exploits that could do that, but not in this case. In this case user needs admin rights.

 

Exact, this is a weak malware, it doesn't even get admin rights by itself, he needs an happy clicker.

This is the exact type of FUD made and needed by those guys to promote their brand new "next gen" company.

 

I wonder why? What is most striking to me is that AV's (with HIPS) should be blocking modifications to the "Image File Execution" registry keys in the first place. And why are the more popular AV's still not using the Protected Process feature? Both of this would have stopped this attack vector.

 

Perhaps they don't want to undergo all the process needed for Microsoft accept them as trusted vendors. Mostly $$$, I think.

 

Eset stated it was "a bear" to get implemented so it isn't just a matter of cost. As such, I suspect getting associated spawned child processes to do the same will be worse. Eset did state they will try to do it but no promises. At least now they have "locked down" the GUI child process via self-protection from the protected parent kernel process to prevent any code or hook injection.

 

Most don't since any new software installation will generate HIPS alerts when its keys are created there.

Remember that "Image File Execution" registry keys modification plus many more registry area changes are part of the old Comodo Leak Tests. Defense+ monitors those registry key areas but it also has features such as "Windows Update" and "Trusted Installer" modes that can be switched to that eliminate the HIPS alerts.

 

This also will allow access to Image File Execution Options registry keys from user mode and unlike that previously noted, no reboot is required: http://www.geoffchappell.com/studie...ysinfo/image_file_execution_options.htm?tx=48