ViRobot APT Shield 2.0...next tool for blocking exploits

Trying it out with EMET 5.0 and HitmanPro.Alert 2.6.5. No issues so far.

 

Same setup, works okay.

 

Interesting, but I don´t know what you mean.

I guess you´re still claiming that AG is better than ERP when it comes to blocking exploits?

 

Well you guessed it sort of , the link shows there are lot's of in-memory intrusions.

 

Anyone tested this against exploits yet, or found a video of someone doing so? I know home-grown tests are not really allowed here, but they should be in this instance as this product is probably not tested by testing organizations, so home-grown tests are all we'd have to go on.

 

Seems to be a few videos on YouTube of it being tested but all are in Korean, I tried to install it on my VM but just get invalid license, i presume there is some protection on the free version which won't let it be installed in a commercial environment (or what it thinks is a commercial enviroment). seems to install OK on my desktop but i already have enough running.

 

Is it possible that ViRobot is really another HIPS application? I have not tried it yet, and I have not been keeping up with this thread. I have some reading to do to catch up. The screenshot shown on their website shows the type of prompts I normally get with Online Armor. If it is a HIPS then maybe it covers some things that AppGuard does not cover. Online Armor covers areas that AppGuard does not, but Online Armor is a very robust HIPS. I tested OA against all of Hitman Pro Alert's test, and it easily intercepted all of them without blocking the exploit itself. I tested AG against the same test, and it only blocked 2 of them since there was no actual binary payload to block.

 

Quick question: You said that Online Armor easily intercepted all of HitmanPro.Alert's tests without blocking the exploit itself-but did OA block all of these tests, I mean what's the point of intercepting something, if you can't block it in the first place?
I wonder how good ViRobot would in this category of testing...

 

I playng with it again, as far as I can deduct by using some PoC's and their video's:
a) It loads a dll (like EMET, MBAE, HMPA) into programs. The etc on their website suggests more applications, but it injects only in the programs mentioned on its webpage.
b) It seems to function as an execution filter: blocking all from user folders, allowing from uac protected folders.
c) Blocked execution from windows + program files (uac protected) are determined through heuristics analysis (the behavioral element). The claimed intelligence is probably based on its understanding of the context of the monitored events (through its own injected DLL) when applying the heuristic rules.

So it seems not so usefull for MBAE or HPMA users, but it could be a usefull addition for EMET users not using an HIPS, Anti-executable or (policy/virtualization) third party sandbox. The overlap with EMET is probably on LoadLib (block dll froms from non UNC path) and ASR (block DLL loading), so one could disable it in applications protected by both (EMET + APT-Shield).

 

@ Windows_Security

So you're saying that it does have some abilities similar to MBAE and HMPA, it's not a simple HIPS who will block all child process executions? In that case it would be kinda cool.

 

No it is more like execution filter loaded through dll-injection simular as EMET and MBAE (not memory overflow, not the dropper, but the execution of dropped code)

Because it is injected in the protected process it can make more accurate decisions with the context and flow of events about the triggered code (child processes), it also uses a small blacklist like ThreatFire to determine which calls from safe places like Windows and Program Files should be blocked. Default deny from user space, default allow from UAC protected folders, except for some blacklisted processes (registering a service etc) and some "intelligent" behavioral detection (probably static heuristic analysis, after all Hauri is an AV-company).

 

Online Armor does not block the payload from being injected into the memory of the vulnerable process. The exploit's payload will be injected into the memory of the vulnerable process, but OA will block any attempted actions made by the payload. If the exploit can't do anything other than run in the memory of the process it has exploited then the harm it can cause may be little to none at all. The exploit will not be able to inject into other processes, or execute binary code to become a persistent infection. It's not the same with kernel exploits. Kernel exploits are not common, and are due to a fundamental flaw in the kernel so the only defense against them may be to patch the kernel. I don't think that is always the case though. I have read that proper configuration of applocker can sometimes stop kernel exploits, but I don't remember the specifics.

To me the only real question is what harm can an exploit do that is only able to run in the memory of the process it has exploited. If an exploit infects the memory space of my browser then I would be concerned that maybe it could capture my keystrokes, but it's not really clear to me if it could even do that. I think it would probably depend on how well designed the exploit is. Regardless, I think the exploit should be gone once the user reboots, or kills the process that has been exploited.

 

I will try to look at this one in the weekend. Macro's and IE should be a good starting point

 

This has already been discussed in some other thread. According to a certain member, "in-memory" malware can be just as powerful as the ones that need to run from disk. I have to see it, to believe it.

 

OK, sounds like it is more advanced than I initially thought it was. Perhaps I will install it, I wonder if it will work with Sandboxie, did you test that?

Yes, please do check.

 

FireEye has a great blog post describing diskless malware that only resists in memory: https://www.fireeye.com/blog/threat...linked-to-deputydog-uses-diskless-method.html

 

I have read those threads as well. I don't see how that's possible if the infection is contained to the memory of one process. I think the biggest danger is if the user is entering sensitive info into the infected application. If Firefox.exe memory space is infected I would not want to login to my accounts online, or purchase anything.

 

(Sorry for my English)

Okay, I did some quick testing.

Set-up used:
Windows 7 VM running outdated IE8 and Office 2010.

Methods used:
- PoC targeting Internet Explorer 8 on Windows 7 (PoC would be blocked by MBAE/EMET/HMPA), payload: shellcode that would launch calc.exe or cmd.exe
- Word document containing an embedded macro, payload: Very basic VBS script (would just show a pop-up) which would be downloaded and executed by the macro (two versions tested)

Results:
- Internet Explorer 8: Nothing was being blocked (calc.exe or cmd.exe could just be launched)
- Macro: Nothing was being blocked (VBS script could just be downloaded and executed)

So basically I couldn't get it triggered and I have no idea why. APT-shield does not contain *any* possible way of confirming that it's running as expected, even worse, it doesn't contain a GUI.
I am even wondering whether I did something wrong although APT Shield is indicating that it's running.

NB: This was just a very quick and limited test with some PoC's I still had lying around, for example I didn't perform any testing on Windows XP or 8 and I haven't used samples from the wild.
You are free to question my results (I even do), I encourage people to test APT Shield with Exploit Kits or with other samples used in the wild.

Edit: APT Shield is able to block calc.exe when IE8 on WinXP is being exploited.

 

@regenpijp
Was VrNsdAppMon.dll loaded in the protected programs and did you allow it go outbound and update once after installation?

 

I'll have a look

Edit:
Yes, VrNsdAppMon.dll was loaded in iexplore.exe and in winword.exe

The product version was: 2.1 (2014.11.10.1) and the Engine version: 2014.11.7.1
afaik I didn't block any update connection

Tomorrow I'll try it on WinXP. Maybe someone else is able to test it in the meantime?

 

I have read it quickly, but they didn't mention the exact capabilities of such a "in-memory" trojan. Yes, it could make outbound connections, no wonder because it has the same rights as the browser. But does this mean that it has complete control over your PC? I don't think so.

If the exploited process is running restricted, malware is going to have a hard time doing any damage. It won't be able to inject code into other processes, won't be able to install a service/driver, and if it's running sandboxed, it can't modify files and registry keys.

I was thinking the same thing. However, the question is, what CAN it do? It still has access to the file system and could steal data I suppose, at least if those files/folders are not protected. I also wonder if it could act like a banking trojan, which can simply hijack your banking session.

 

I have done some additional testing on Windows XP and this time calc.exe was blocked.

I also found the reason why my initial PoC targetting IE8 on Windows 7 didn't trigger an alert. Executables only seem to be blocked when they are being launched from RWX memory with ‘traditional’ shellcode. (This was tested on Win XP and Win 7) My initial PoC targetting IE8 on Win7 used a different type of 'shellcode' which might be the reason that it did not trigger an alert.

 

Though your statement about entering sensitive info is right, how can you know our browser is exploited by in-memory malware w/out anti-exploit?
As to Rasheed and your question, one possible scenario is HTML injection where attacker modify original contents of the page and thus steal credentials entered by fooled user. I initially thought in-mem malware can steal credentials directly from browser, but I have to admit it seems to be not right cuz in most major broser all credentials in memory and on disk are encrypted.

 

Well, I was thinking about that when I wrote the post. You wouldn't know unless your security software alerted you to it's presence. I'm not sure about he credentials in memory being encrypted. I think in the case of the content of the webpage being modified to fool the user into typing their information into it is perfectly logically except i'm not sure that falls into the boundary of memory malware. That's more of a phishing attack, or social engineering.

 

OK, so what is your verdict?