In memory fileless malwar edetection ..... any antimalware software?

Ha ha ha.... Rofl

If you read my previous two threads, you miht get an idea.

 

I stand corrected. The new malware is not really new it is a stolen PowerLiks loader is all.

Update 1
We want to thank Kafeine, FireF0x and Horgh_rce for pointing out that the malware is actually Kovter.C that ripped off Powelik’s loader.

 

Ok. Hopefully this will resolve. Run PowerShell from Start -> search box. Do you receive a UAC prompt? I run UAC at it's highest level in WIN 7 and run as default limited admin. I received no UAC prompt. Powershell will also run under a standard user account if you check it's permissions; read and execute.

 

I did. As Malwarebytes noted, Powerliks will load a dll from the registry into its memory. It will then inject that dll from its memory into the targeted process's memory. It is exactly the same technique (memory injection) reflective dll injection uses. It's immaterial what the origin of the malware dll is.

 

Hmmm.... power shell is not must for malware and I doubt that AppGuard will intercept fileless in memory injection but I can't test AG at the moment. Even I don't feel I am expert enough to test all this but I am deducting all this on the basis of my limited testing.

 

I think dll is injected first and reg entery is later and there is fileless malware that doesn't even write to registry.

 

If you use a Reboot-to-Restore program that protects the Registry, won't anything written to the Registry be removed on a reboot? That is, the initial writing of the encrypted registry key will be removed on a reboot?

----
rich

 

What I am referencing is a black-hat lecture on powershell. In the presentation, the attacker substituted powershell.exe with their own proprietary interface and they were able to run power shell scripts, despite powershell.exe being blocked by the systems admin. The presentation was dated earlier this year and its possible that a fix has been issues or a method exists to prevent this. This is a fairly new area for me, so I can not speak for the effectiveness of CryptoPrevent in regards to blocking access to powershell, but I thought it was worth mentioning as newbies to powershell, such as myself, might presume that locking his executable down would be sufficient.

 

Thanks,

I'm bookmarking this since Windows will be including powershell in every new OS moving forward. Every bit helps.

 

Classical HIPS do the same and they are blind to it, so I guess same for AG.

 

Wish I had knowledge time and resources to analyze and test these and give the definite answers. Most antimalware products/ vendors seem not to bother about detection and interception of these malware. So you will not see them ever commenting in these threads.

 

Yes it will run without UAC prompt with medium integrity level. Which means it won't be able to modify registry keys, you were mentioning (only the last one - HKCU, which could be blocked changing ACL on that key).

If it would want to change those reg keys it would have to elevate to high or system integrity level.

 

Here's the problem with Poweliks. Referring back to the original Symantec article that was posted at the beginning of this thread, the earliest version of the malware did this:

Watchdog

The Watchdog DLL launched from the registry entry is loaded every time Windows starts. The Watchdog process starts Windows’ dllhost.exe and injects itself into it. With the process loaded in memory, another thread is used to make sure that the relevant registry load points are continuously primed to load Poweliks.
​

So monitoring dllhost for memory injection would stop it.

However with the introduction of ver. 1.7, it's a whole new ball game ...........

With this component, Poweliks targets even more processes, instead of only dllhost.exe, so that it can inject itself into many others too. Poweliks 1.7 may inject itself into any of the following processes in the %System32%
directory:

• cmmon32.exe
• ctfmon.exe
• dllhost.exe
• dllhost3g.exe
• dplaysvr.exe
• dpnsvr.exe
• dvdupgrd.exe
• fixmapi.exe
• logagent.exe
• msfeedssync.exe
• napstat.exe
• regsvr32.exe
• rundll32.exe
• shrpubw.exe
• svchost.exe
• systray.exe
• upnpcont.exe
• wextract.exe
• wiaacmgr.exe​

The scope of this makes monitoring via HIPS impractical. Additionally, memory injection monitoring of one or more of the above processes will probably break your OS. However, monitoring dllhost.exe will at least let you know your infected.

 

Yes, it appears it might work. Also possibly a system restore since that will restore the registry; but you would have to use a restore point prior to when you were infected ..........

-EDIT- Guess not after all. As I mentioned previously, removing the infect registry keys won't help. The bugger just recreates them on the next boot - see my post #94 below.

 

Yes, but the bogus powershell is still a program and it's activities should be caught by a good behavior blocker assuming it's an unsigned and cloud unknown program i.e. invalid hash. Also assumed is that it wasn't installed in C:\Windows\System32 or SysWOW32\WindowsPowerShell sub-directory.

 

@itman
@Peter

I think I can guess why the fileless malware injection not intercepted by classical HIPS. Typically it come via an exploit of browser plugin like flash. Flash in case is running as part of browser process like iexplore.exe. The malware injects itself into iexplore.exe. So in a way iexplore.exe is injecting code into itself and HIPS don't object this.

Bedep does inject explorer.exe( a different process that the browser). Will this injection be intercepted by HIPS? I am not sure. I tried to get bedep run on my system and inject into explorer.exe but I failed. It is not easy to run this malware, it really needs expert testing.

This code injection might be detected and it might not be. Chances are 50 50. I wish a HIPS developers was around on these board and we could have asked him to test it in reality but unfortunately we have none active on these forums.

 

I think there is some confusion here on how Powershell is used by PoweLike.

Powershell is only used to execute the malware after startup; again to evade detection by AVs. It is dllhost.exe that is actually updating the registry keys; again to avoid detection by AVs. The following is from the McAfee article link I previously posted. Also noted in this article is if Powershell isn't installed, the malware will install it. So removing Powershell from your PC won't help*.

Powershell is used in the restart mechanism to execute the malware after startup. The malware will then start a new process with DLLHOST.EXE in a suspended state, inject its malicious payload (the Powelike binary) into its memory, and start a new thread from the binary entry point. In this case, DLLHOST.EXE is just a host application the malware uses to execute. The dropper will then create any of the following registry keys, which are used as a restart mechanism and to store the malicious payload and malware configuration:
​

* One trick that might prevent Powershell reinstall would be to block write access to these Powershell directories: C:\Windows\System32 or SysWOW32\WindowsPowerShell\*.*
using SRP or a HIPS rule. Also note that in able to do this, the malware has to be running with TrustedInstaller privledges.

Again just monitoring Powershell startup using a HIPS rule is the simplest solution in my opinion.

 

The point is that a true Reboot-to-Restore program, such as Returnil or Deep Freeze, will not permit anything written to the Registry to survive a reboot when in locked down or frozen mode.

Thus, if someone's lack of security permits the Angler Exploit Kit Adobe Exploit to run from a compromised web site, and the exploit writes those keys in the Registry, they are removed upon reboot.

----
rich

 

Hi Rich,

As I pointed out in post #94, Poweliks will just re-infect the registry upon reboot. I assume this software just restores the registry upon reboot? The Powerliks malware will run after that as part of the OS startup initialization. Or I am missing something here.

Again the following from the Symantec article posted at the beginning of this thread:

It uses the PowerShell program along with an embedded PowerShell script to load a DLL into memory which serves as a “Watchdog” to ensure that Poweliks remains installed on the compromised computer. It does this by constantly checking the Poweliks registry subkey to make sure it is still in place.​

 

Yes. Heapspray, ROP, and like crap. Anti-exploit protection should prevent all that.

I tested Eset's exploit and memory protection a while back using SurfRight's test tool using IE10. It stopped every test exploit. Also did so in an interesting way. Blocked every payload from executing but didn't crash the browser. Neat. Note this was with the HIPS set to default Automatic mode: i.e. basically blocking nothing.

If you do your own testing with the SurfRight test tool, make sure your browser is open when performing the tests. Otherwise, every test will fail. All the test tool has is a browser stub. It opens and closes so fast, no network connection is established before the test calc.exe payload is displayed. All of Eset's exploit and memory protection is resident in it's network driver.

 

Yes, but only is you create a specific HIPS rule for it; at least as far as Eset goes. I am presently monitoring dllhost, explorer, notepad, rundll32, svchost, winlogon, plus all my Internet facing executables. I monitor the Internet facing apps more strictly than just for memory injection adding global hooking and event interception checks.

 

Yeah, you're in essence running a VM. Do you use it? I see they are offering a lifetime license currently?