Classical HIPS and policy based HIPS discussion

Discussion in 'other anti-malware software' started by BoerenkoolMetWorst, Jan 28, 2015.

Thread Status:
Not open for further replies.
  1. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I will also add that if your security solution cannot detect this basic Stephen Fewer original reflective DLL injection technique posted above, it certainly won't detect more advanced RMI techniques such as this:

    How it’s done

    The basic process is as follows, summarized for brevity:

    1.Open target process and allocate memory.
    2.Copy the DLL into the allocated memory.
    3.Copy a hash of the entry point function name and any arguments to the function into the memory space after the DLL.
    4.Copy over some bootstrap shellcode that calls a modified reflective loader with pointers to the data copied in step 3.
    5.Create a remote thread in the target process, using the address of the beginning of the shellcode as the entry point.


    Ref.: https://disman.tl/2015/01/30/an-improved-reflective-dll-injection-technique.html
    Or this:

    Now we can use this knowledge to perform reflective DLL injection from a 32-bit/WoW64 process into a 64-bit process

    Ref.: https://disman.tl/2015/03/16/cross-architecture-reflective-dll-inection.html
     
  2. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    3,344
    Location:
    Europe, UE citizen
    May be this is my error. I'll try.

    Thank you, but I'm sure to have download the correct files from your link.

    I don't use the sandbox. Yes, I allowed the process, but may be that I have to modify some Defense+ setting to fully allow it at the beginning, I'll check.
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Well, according to this:

    Once installed, Defense+ watches all file system activity on your computer. Every new executable file introduced to the computer, is first scanned against the Comodo certified safe files database. If they are not safe, they are added to the 'Unrecognized Files' for users to review and possibly submit to Comodo. Apart from new executables, any executables that are modified are also moved to the ' Unrecognized Files' area.
    You have to move the file to either "Trusted" or perhaps "Limited" application status. Obviously moving it to Trusted status will allow the app to do anything I assume? If you move it to Limited status, then the inject.exe would fail I assume since your browser is protected by Defense+.

    What we are trying to simulate with this test is some app has been able to slip by your front line defenses. In your case that would be Comodo's whitelisting. So I guess, you will have to set inject.exe to "Trusted" status which I believe will allow inject.exe to do anything. Testing will confirm this. Again, what we want to test is if the rules Comodo has set up for your browser will unconditionally block any unknown or undetected process from modifying your browser's memory.
     
    Last edited: Apr 13, 2016
  4. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    3,344
    Location:
    Europe, UE citizen
    Well. The test is completely safe, is it ? In my previous test I did it using the option Try & Decide of Acronis, a soft virtual mode, but if the test it's safe I'll run it in normal mode.
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes. Test is safe. But always scan with your AV anything you download from Github since what's there is open source and there have past instances of code substitution there . Both Emsisoft and Eset AV scanners showed inject.x64.exe as clean.
     
  6. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    3,344
    Location:
    Europe, UE citizen
    Done. The first thing - I'm inexcusable ! In my previous trials I didn't report that I saw the alert " Hall ofrom DLLMain ! ", but alone the name of the process and the path. Sorry, but I was so focused on to see or not to see Defense+ alerts that I forget to report it !! :oops::rolleyes:

    In last minutes I did two trial to inject the process: one after moved the file in
    Trusted files and one after moved it in Unknown files. In both test after my OK, Run disappeared. No alerts from no one.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I assume these were the tests you did while running in a VM? In any case if you saw the "Hello from DLLMain" popup box, Comodo failed to detect the reflective memory injection. See the readme from GitHub noting:

    The ReflectiveLoader will then call its newly loaded image's entry point function, DllMain with DLL_PROCESS_ATTACH. The library has now been successfully loaded into memory.
    Don't know quite what you mean here?

    I have seen different behavior from Eset for example, if I try to inject svchost.exe. In this case, svchost.exe will run conhost.exe which displays the black command prompt box. It is only displayed like in a flash and then it is gone. Emsisoft on the other hand will fully display the command box and then alert about the injection attempt to svchost.exe.-EDIT- What this shows was that partial memory modification to svchost.exe occurred and allowed conhost.exe to run but any attempt to modify the internal control structures of svchost.exe failed.

    In both these above cases, the reflective injection was actually blocked since no "Hello from DLLMain" box was displayed. Nor was there text in the command box indicating the reflective injection was successful as shown in my prior posting. However in Eset's case, I did not receive any Eset alert nor was there any entry in my Eset HIPS log about inject.x64.exe being block. Eset's advanced memory scanning and exploit protection does not alert or log but just silently blocks the memory injection. Bottom line - both Emsisoft's and Eset's protection block reflective memory injection regardless of whether the process being injected is an application or system process.

    It is possible Comodo is doing the same as Eset does when you ran inject.x64..exe as both a trusted and subsequently as an unknown process. Look for the quick flash display of the command box on the desktop as I described previously.

    The outstanding questions are:

    1. Why did Comodo did not detect the reflective injection when you ran it in a VM?
    2. Whether Comodo detected the reflective injection when run as a trusted or unknown process running outside a VM appears to hinge on if the inject.x64.exe process actually ran?

    In regards to "In both test after my OK, Run disappeared. No alerts from no one," check your Comodo logs for any entries related to inject.x64.exe. You can also open Process Explorer and observe if an entry appears for inject.x64.exe after allowing the process to run. This would confirm the process started execution. If execution started, it would be safe to assume Defense+ silently blocked the process although no alert was displayed or log entry created.

    -EDIT- Finally dawned on me why Eset didn't alert from my custom HIPS rule to protect system processes. Eset has hidden default rules that protect system processes. Those are always executed before any explicitly defined user rules. So, I will remove my system rules since they are redundant.
     
    Last edited: Apr 14, 2016
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Let's talk a bit more about my above svchost.exe RMI test of Eset and Emsisoft; namely what Emsisoft didn't detect.

    Emsisoft did not detect a hook being set in svchost.exe from inject.x64.exe that allowed for the startup and execution of conhost.exe as a spawned process. This in itself does not mean much since conhost.exe is not a malicious process. However, further testing is needed to determine how effective Emsisoft is against advanced threats such as process hollowing from actively executing processes in which its hook is not being set. Note that Emsisoft's only sets its hook in a few selected system processes.

    When I did my previous process hollowing tests against Emsisoft, I suspended an existing spawned process and then tried to do the reflective dll injection into that process. Emsisoft did detect the RMI activity. However, it was perform against a process that had already been created and which Emsisoft had set its hook into. Whether the same applies to new suspended process spawned by hooking where Emsisoft has not set its hook into remains to be determined.

    Eset's HIPS does not employ hooking as a primary detection mechanism. Hence, the immediate termination of conhost.exe upon startup by svchost.exe.
     
    Last edited: Apr 14, 2016
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    To quote an old truism, " Try, try again, and you will succeed."

    I found a hollowing process test. It will attempt to do a hollow process routine against svchost.exe. You can read about and download from here: http://www.autosectools.com/process-hollowing.pdf .

    Emsisoft Anti-malware behavior blocker definitely didn't like this bugger and immediately quarantined it. So we can now say Emsisoft does protect against hollow processing.

    EAM_Process_Hollowing.png
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  11. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Interesting find, I tested it inside the sandbox and it seems to perform a process hollow attack on svchost. SS didn't alert about anything. BTW, MRG released a new test again (Q1 2016), the simulators seem to be a bit less advanced:

    https://www.mrg-effitas.com/recent-projects/our-projects/
     
  12. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    BTW, check out these articles about CryptoWall. As mentioned before, if you block the loading of svchost.exe and explorer.exe as a child process, you probably have already won the battle. You don't even need to block the process hollow attack anymore. Weird that a lot of HIPS have not implemented this simple trick to interfere with this type of attack.

    https://blogs.sophos.com/2015/12/17/the-current-state-of-ransomware-cryptowall/
    https://www.sentinelone.com/blogs/anatomy-of-cryptowall-3-0-a-look-inside-ransomwares-tactics/
     
  13. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Here's the results.

    Emsisoft blocks it upon execution:

    EAM_IAT_Hooking_Block.png

    Eset HIPS blocked it upon its attempt to modify calc.exe memory. What's important to note here is that Eset did not block it by default rule but by my custom user rule to prevent any system process modification. So this proves that Eset's default HIPS rules do not protect all system processes i.e. those located in C:\Windows\*.*

    Eset_IAT_Hooking_Block.png
     
    Last edited: Apr 16, 2016
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes. From the Sentinelone article, the malware is doing a process hollowing routine against both:

    the malware spawns a new suspended explorer.exe process, allocates some memory inside it, and writes a designated code section into the process. It creates a remote thread and calls NtResumeThread on it.

    A “svchost.exe –k netsvcs” is spawned, suspended, and injected with a thread executing the main payload, which performs the rest of the malware’s work.
    And just how would you block the above? The only way to stop this is to prevent the execution of the malware payload. If that fails, it is game over for most security solutions.

    I have already proven both Emsisoft and Eset with default system and user supplemented HIPS rules can prevent this. You have already stated that Spyshelter does not. Spyshelter by design uses a classical HIPS. Classical HIPS's are no longer effective against today's advanced malware. A HIPS running in policy mode which is whitelist/anti-exec mode might stop the both the dropper and payload from running. It all depends on how malware was delivered and the method by which it was executed.

     
    Last edited: Apr 15, 2016
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Eset failed this simulator test:

    Simulator Test – Powershell keylogger test

    One of the oldest techniques to steal password is to log the keyboard events. We used a Meterpreter Powershell with the keyscan module to test the protection. No malware or exploit has been used for this test, we simply executed powershell commands which started a new Meterpreter session. We used the exploit/multi/script/web_delivery scripts, with encoding the stage 2 dll files, along with the commonly used reverse_http Meterpreter shellcode.
    Answer for failure is simple; Eset's HIPS by default doesn't monitor Powershell execution. I do so with a user ask rule. Eset doesn't want to monitor Powershell this way since it will require user decision on alert. Powershell can be used for legit purposes but on a home user PC, the instances are nill for all practical purposes. I have yet to receive an alert from my custom created Powershell HIPS rule.
     
    Last edited: Apr 16, 2016
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    @Rasheed187, here is the "latest and greatest" banking Trojan currently floating around in cyberspace: https://securityintelligence.com/meet-goznym-the-banking-malware-offspring-of-gozi-isfb-and-nymaim/

    Some Technical Details

    Before merging into an actual hybrid, earlier versions of Nymaim used to fetch and inject Gozi ISFB’s financial module as a complete DLL into the infected victim’s browser to enable webinjections on online banking sites. That DLL is about 150 KB and was a valid Portable Executable (PE) file.

    More recent versions of Nymaim include altered Gozi ISFB code. Instead of the 150 KB DLL, it now injects a 40 KB buffer into the browser. This buffer still performs Gozi ISFB’s functionality. For example, when it comes to the Export Address Table (EAT), which contains the addresses of modules exposed for consumption by other applications and services, GozNym uses the same hook engine to perform webinjections.

    However, there are some pointed differences. For one, the new buffer is not a valid PE file — it has more of a shellcode structure. It constructs its own Import Address Table (IAT) and has no PE headers.

    Another difference is that the new buffer is intertwined with Nymaim’s code. We have at least two examples that demonstrate that interoperability: One is where Gozi ISFB calls Nymaim code to obtain strings; the other is where Gozi ISFB’s buffer code needs to perform actions such as memory allocations.

    This intertwined construction led us to the conclusion that Nymaim and Gozi ISFB were in fact compiled into one project.
    This is one nasty bugger indeed. Unlike other banking Trojans such as Dridex and the like that were delivered using phishing techniques and e-mail, this uses drive-by downloading and like browser download methods to deliver its dropper. Then the payload does RMI as noted above to inject the browser.

    -EDIT- Forgot to mention that the dropper for this puppy is encrypted and obfuscated, de-cloaks in memory, and is specifically design to avoid detection by conventional behavior analysis such as heuristics. So if your security solution does not employ advanced memory scanning designed to detect such stealth behavior, you're nailed. Again Emsisoft and Eset employ AMS technology to detect like behavior.
     
    Last edited: Apr 15, 2016
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Time to talk a bit about sandboxing. Whereas it is an effective mitigation against "run of the mill" malware, it can be bypassed by advanced persistent threats. The two that immediately come to mind are:

    - Com based malware; especially WMI based that was briefly previously discussed: https://www.vmray.com/sandbox-evasion-with-com-by-malware-in-the-wild/
    - Remote access Trojans: https://www.alienvault.com/blogs/security-essentials/trochilus-rat-invading-your-sandbox . In regards to R.A.T.'s, an effective mitigation is - you guessed it - behavior monitoring:

    The only way to detect RATs that are designed to evade detection by preventive technologies (such as sandboxing) is through detection capabilities that can identify the behavior of the malware once it’s compromised a system.
     
  19. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Hi itman

    I took a look at those two links, particularily the alienvault. Saw the usual marketing hype of It's dangerous out there, you aren't safe, that is unless you use OUR new unique solutions. Not impressed. Noticed they didn't mention Sandboxie as it could prevent all the stuff they are talking about.
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Hi Pete,

    Here's some more info on Trochilus here: http://securityaffairs.co/wordpress/43889/cyber-crime/new-rat-trochilus.html

    "The malware is very sophisticated, it operates in memory only and doesn’t use disks for its operations, for this reason it is hard to detect.

    This malware executes in memory only and the final payload never appears on disk in normal operations, however the binaries can be decoded and are subsequently easier to analyze.” states the report.

    The threat actors behind the Trochilus RAT primarily used malicious email as attack vector, they included the malware in .RAR attachment.

    Detailed analysis of Trochilus here: https://www.arbornetworks.com/blog/...15-08-Uncovering-the-Seven-Pointed-Dagger.pdf

     
  21. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Okay. THanks, First software that blocks is the brain. It comes in email. Then the rar files wouldn't survive HMPA's application lock down. Plus more. SEe PM
     
  22. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Hi Pete, you can use Sandboxie for opening RAR files, this is how I handle RAR files. I force WinRar, as the RAR file gets executed, it runs sandboxed automatically in its own dedicated sandbox. The RAR sandbox is set with Drop rights, only a few programs can run, nothing allowed access to the internet and sensitive files and folders are blocked. Then I cherry pick what I am going to recover and recoiver it to a Forced folder which is also highly restricted. This things described in this links provided by Itman don't belong in the same league as SBIE.

    Bo
     
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  24. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Hi Itman, this articles you posted today seems to me they are about security program that have a sandboxing feature that sandboxes files when this files are flagged as malicious or are unknown to the security programs. The articles talk about malware that tries to fool this security programs. But thats not how Sandboxie works. Sandboxie doesn't detect nothing.

    The way to really really use Sandboxie to protect yourself is to run all files and programs untrusted by running then in a sandbox all the time. When I recover a file from the internet, that file is going to run sandboxed until it gets deleted, a day from now or five years from now. It doesn't matter. Not everyone uses SBIE that way but thats how I use it. If you use Sandboxie this way, the malware in the articles cant touch your system, and cant fool the user into running it unsandboxed.

    Earlier today, this thread caught my eye when you said, "Time to talk a bit about sandboxing. Whereas it is an effective mitigation against "run of the mill" malware..."...Run of the mill malware? What about ransomware, is that run of the mill malware? I ask because, I see a lot of people all over the place worrying about ransomeware, and even seen the YouTube videos that show security programs that are supposed to protect against that kind of threat fail, but according to the same YouTuber testers, the ransomware dont do nothing against SBIE (expected).

    Bo
     
  25. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Although again another sort of advertising thing one thing that caught my eye was the sleep thing. Bo does have a good solution for him, but it would be tougher for me on a couple of levels. So for me it's layering. That way should I have something that has malware that is sleeping and then wakes up I probably wouldn't run the file in sandboxie, but HMPA would shut it down, and if not Appguard would protect the system.

    Interesting HMPA takes advantage of all this detecting of sandboxing, by making it seem the system it self is a sandbox which keeps some malware from ever running.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.