DoubleAgent: Taking Full Control Over Your Antivirus

if you look at this "attack", you can see that this is a PR action of another "next-gen" "security" company, they took an idea from a Recon 2015 presentation and turned it into a PR media-hack, the technique they describe is so "undocumented" that even Microsoft blogged about it here: https://blogs.msdn.microsoft.com/reiley/2012/08/17/a-debugging-approach-to-application-verifier/

If you want to use this "attack", you need to write into a registry key that is write-able only with admin rights, so on modern (non WinXP) systems it means that you have to elevate your code, either with a Local Escalation of Privilege or with a UAC prompt that will be confusing enough to trick the user to click on itif you want to use this "attack", you need to write into a registry key that is write-able only with admin rights, so on modern (non WinXP) systems it means that you have to elevate your code, either with a Local Escalation of Privilege or with a UAC prompt that will be confusing enough to trick the user to click on it

 

That link is from 2012

 

And it still works. It is how Cybellum replaced the verifier.dll with whatever .dll they chose.

Although by now most AV vendors have self-protected their own processes from this type of .dll injection, most by default are not protecting all sub-keys of:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*
​

So as NVT previously recommended to their users, I have created HIPS rules to alert on any modification activity in those keys.

​

 

I'm also protecting these registry keys. Not with HIPS rules, but with the program which was mentioned in #21

 

does the code listed in 21 just get added to settings in the ini? Not under options , right?

 

OT:
The rules in #21 are included in the file Rules.DB
For "NVT Registry Guard Service"-related things, configuration, errors after installation (see MBAM-thread), etc. this thread might be a better place

 

As far as the NVT registry protection software goes, see if it protects against renaming of any of the two keys mentioned reply #78. That was one of Cybellum's bypasses.

Make sure you reset reg. key names back to proper values.

 

Yes but default setting breaks malwarbytes web protection.

 

@boredog

You need to exclude blocked events related to Malwarebytes by editing the \Exclusions\Exclusions.DB file, i.e:

[%OPR%: WRITE_VALUE] [%EXE%: *:\Windows\System32\services.exe] [%KEY%: *\SYSTEM\ControlSet*\Services\tunnel] [%VAL%: ImagePath]

The rule above will allow *:\Windows\System32\services.exe to write (%OPR%: WRITE_VALUE) the "ImagePath" value on key *\SYSTEM\ControlSet*\Services\tunnel

I believe Registry Guard is blocking Malwarebytes from installing the service.

 

according to this link https://cybellum.com/doubleagent-taking-full-control-antivirus/ it uses application verifier. is it possible to disable application verifier ?

 

Renaming of the key to, for example "Image File Execution Options_RENAME", was prevented:

Code:

Operation: Rename Key
Process: [8568]C:\Windows\regedit.exe
Parent: [3384]C:\Program Files\totalcmd\TOTALCMD64.EXE
Thread Id: 8540
Key: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
New Key Name: Image File Execution Options_RENAME
Rule: [%OPR%: RENAME_KEY] [%EXE%: *] [%KEY%: *\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options*]

 

See reply #54. It is not present unless manually installed by the user.

The problem is that malware could download it or a renamed equivalent of it; bundle it in an app installer; or just download and run the Windows SDK. Since it is a valid Microsoft signed .exe, it won't be detected as malicious by conventional security products. Worse, the default directory it is installed in is System32 although it can run from any directory.

If the security product has the ability to block a .exe from running by hash value, most don't, Windows SDK can be downloaded and the hash value for Application Verifier determined.

-EDIT- You also don't have to download the entire Windows SDK but can just download Application Verifier:

 

Yes it was explained by MS years ago....this is just a old bug

 

is this advice from reading my log in the malwarbytes 3.0 thread, # 1418?

This is already included in the exclusions DB file. So that must not be the culprit.

[%OPR%: WRITE_VALUE] [%EXE%: *:\Windows\System32\services.exe] [%KEY%: *\SYSTEM\ControlSet*\Services\tunnel] [%VAL%: ImagePath]
[%OPR%: WRITE_VALUE] [%EXE%: *:\Windows\System32\WinSAT.exe] [%KEY%: *\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce] [%VAL%: WinSATRestorePower]
[%OPR%: WRITE_VALUE] [%EXE%: *:\Windows\System32\browser_broker.exe] [%KEY%: *\Software\Microsoft\Windows\CurrentVersion\Internet Settings*] [%VAL%: *]
[%OPR%: WRITE_VALUE] [%EXE%: *:\Program Files\Internet Explorer\iexplore.exe] [%KEY%: *\Software\Microsoft\Windows\CurrentVersion\Internet Settings*] [%VAL%: *]

 

NVT

or at you saying I need to remove that one from exclusions? I can reproduce it every time. too bad there are not any other registry guard users also using malwarbytes 3.0 so we could verify.

 

In my case the web protection service has already been running but is killed after a short while later.

 

Yesterday, I "refound" the article with a detailed analysis of ELAM use on Win 8.1 and 10 here: https://blogs.technet.microsoft.com/dubaisec/2016/05/09/elam-driver/

Whereas this thread concentrated on the use of ELAM for protecting security vendor's core processes, this is not the primary purpose of the ELAM driver and processing. It's primary purpose is to allow security vendors to scan kernel drivers by malware signature prior to loading. This is especially critical for all Win OSes other than Win 10 ver. 1607 that was installed from scratch since none of these OSes employ Microsoft's enhanced driver signature enforcement which requires kernel drivers to be signed with a restricted Microsoft code certificate.

Also for added security, the registry keys used by ELAM are not permanent stored in the registry where they could be tampered with by malware. The keys are loaded by the OS at early boot initialization and then unloaded after ELAM driver processing has completed.

Finally, this processing is the only driver security for home versions of Windows since the Secure Boot feature which adds additional driver hash verification capability is only available on the paid versions of Windows.

 

That's the thing, certain modifications should be auto-blocked. Most apps have absolutely no business trying to modify certain registry keys.

Sounds ridiculous to me, there is no excuse for this.