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

itman, thanks for your informative posts!
I have EIS, AppGuard (on Lockdown mode), HMP.A and CryptoPrevent (on Set and Forget). Will my security setup prevent, or at least mitigate, any fileless memory exploit?

 

After reading through this, it is bad but it still requires privilege escalation to do damage and running a LUA with strict ACL settings will help mitigate this type of exploit and prevent any persistence so it won't survive a reboot. The paper assumes an admin account. So will javascript blocking and click to play for the flash plugin in a browser. And above all, paying attention to what you click on. The exploit process still uses social engineering to trigger the exploit.

It is an interesting paper. It assumes an attacker who is actively trying to pwn a system. If the attack was automated with scripting, it would be more easily foiled.

 

Refer to the link to the SANS article, section 4, on ways to get System level access and to ensure Meterpreter persistence.

Yeah. In the comments, the author replies to a question on how to delivery:

How do you get the victim the visit the malicious server? That's up to you. Maybe, send them a link in an email and ask them to click on it. Haven't you seen such techniques in your email?
​

Obviously hacking a web site and placing the link there or creating a javascript to redirect to the server would be a lot more effective.

-EDIT-

Actually, the preferred way to deliver the Meterpreter payload is via a stager executable as described in the SANS article. It could be delivered any way any file can be downloaded; e-mail attachment, bundled with other legit software, etc.. It could be disguised not to be an executable e.g. zip file, different file suffix, you name it.

Now the SANS article states the authors:

Further, the executable was run by the Administrator account on a Windows 7 system, with the UAC bypass accepted.
​

Again, they were analyzing the malware and just want to get the thing to run. Any clever hacker will package a UAC bypass most likely via a Powershell script and also escalate privileges at the same time.

Ways To Avoid Meterpreter stager detection

This will load the payload executable into memory without touching disk, allowing otherwise disk-detectable executable to bypass detection
Ref.: https://sathisharthars.wordpress.com/2014/07/01/delivery-and-execute-undetectable-payloads-in-windows-7-using-veil-catapult/

Powershell payloads for example seem to be particularly useful for evading AV, and Metasploit can create a powershell stager and there is a psexec variant that does this. Also the WinRM modules can deliver powershell payloads if your target has a WinRM service you can bruteforce.

I might also suggest that you could write an EXE in .NET that acts as a stager and talks back to the handler to grab the stage, then use that as an EXE::Custom for psexec or whatever other delivery method you might be using.
Ref.: https://community.rapid7.com/thread/5619

 

HMPA would prevented the exploit and things would end at that point.

 

Thanks for the answer and assurance!

 

ACL and SRP limiting of powershell to a fully logged on admin will stop this. ACL would be best. UAC is weak. I just did an ACL change on a system I'm using. It is nice to have all the Powershell files in one folder but it was still a pain. I had to take ownership of the Powershell folder and remove all groups other than System and locally logged on Administrators. This should make it difficult for the stager too unless the exploit tricks a limited user to log on as administrator.

 

From the SANS article:

Escalation from a non-admin account can occur through various exploits so this does not make the setup unreasonable.
​

Metasploit can esculate to System level:

Fortunately, Metasploit has a Meterpreter script, ‘getsystem’, that will use a number of different techniques to attempt to gain SYSTEM level privileges on the remote system. There are also various other (local) exploits that can be used to also escalate privileges.
Ref.: https://www.offensive-security.com/metasploit-unleashed/privilege-escalation/

-EDIT- This won't work for WIN 7 and above if running as normal user. You have to do an exploit as noted below. However, I do believe it will work for default limited admin account coupled with a UAC bypass.:

If you do not have administrator privileges and the session is running with a normal user privileges, you have to exploit a local vulnerability within the OS. There are two exploits in Windows 7 I can think of: MS-12-042 Sysret for which the exploit is available at https://github.com/shjalayeri/sysret and the latest privilege escalation bug EPATHOBJ:prFlattenRec Local Privilege Escalation. Note one thing that the sysret exploit will work only on x64 bit machines while EPATHOBJ is only for 32 bit Windows machines.
​

Finally, you don't need to use Powershell to do privilege escalation - ref.: https://www.trustwave.com/Resources/SpiderLabs-Blog/My-5-Top-Ways-to-Escalate-Privileges/

​

 

Setting ACLs isn't the last word in stopping this sort of attack just a good procedure. It makes it more difficult for the exploit process to fully succeed and is more effective if combined with other mechanisms and procedures.

No but it is a big security hole in many ways. In my test system from a user account, the whole powershell folder is completely inaccessible. I further tweaked the ACL and removed the "system" group from it. Only the local administrator can access powershell. So far no glitches. Windows works fine without Powershell. I am going to do some ACL experiments and remove "system" from some other places in the Windows folder.

There are many ways to escalate privilege. Of the five in the article, only number 3 gives me pause for thought. The others are easily prevented by setting appropriate ACLs in the appropriate places, whether local or network shares. They all involve storage, not getting code directly in memory. In Windows, I set any volumes used for data storage to be read write only with the "Everyone" group. No one, users, system or admin can execute code from them. That would apply to any network shared folders of course.

 

A Few Whitelisting Bypass Methods

The classic one: http://www.infosecisland.com/blogview/23578-Application-Whitelist-Bypass-Using-IEexecexe.html

More: https://khr0x40sh.wordpress.com/2015/05/27/whitelist-evasion-revisited/

More, more: http://subt0x10.blogspot.com/2015/08/hiding-in-plain-sight-com-surrogate.html

 

All of these assume getting admin access and can be blocked with ACLs if you are running a LUA. The obvious second candidate for taking ownership and removing "system" from the ACL was cmd.exe which is, of course, along with Powershell, one of the paths to getting persistence in a newly pwned Windows box. As with Powershell, Windows runs fine without system access to it. I could restrict access to it further if I removed the "users" group from the ACL but that is convenient for me in my own setup. If I was doing this for a business network, I would do it.

Amusing to read the first article and the assumption is that the hacker has a pwned Windows box in a corporate network with a full admin privilege level. I don't work with corporate networks but any machine on such a network should be be properly locked down and subnetted. If there are so many sloppily configured Windows boxes and networks out there, the corporate owners are begging to get hacked. Once the hacker gets admin access, the game is pretty much over. If that is the default privilege level, pwning the machine and getting persistence is an easy job. If it is a tightly locked down LUA with custom ACLs set, it is not such an easy job. That is the beauty of knowing how to set ACLs. They can be easily customized to deal with specific kinds of threats and attack vectors. It just took me a couple of minutes to lock down Powershell and cmd.exe after reading about the processes that used them to compromise a Windows system.

 

If you use environment variables, SRP can be bypassed: http://www.sysadmins.lv/blog-en/hacking-and-securing-software-restriction-policies.aspx . Also as far as Microsoft is concerned, SRP has been deprecated by AppGuard.

C# i.e. .net programs can execute Powershell by using CLI calls. So if the goal is to 100% restrict Powershell usage, the only way it can be done is to use AppGuard and define restrictions for all PowerShell assemblies and dlls: https://www.sixdub.net/?p=367

 

Here's a simple script to bypass all software restriction policies. Note: Powershell can run from anywhere!

Let’s assume this scenario:

1. We’ve compromised the victims machine with software restriction policies on it.
2. We have access to the system in some fashion albeit a limited user account.
3. Our executable/PE file resides in %TEMP% however cannot execute.

https://www.trustedsec.com/may-2013/pauldotcom-thwarting-client-side-attacks/

 

Hi Pete,
For sure you're going to test AppGuard don't you?
Hopefully you find it can't be bypassed in memory...

 

Hi,

I'm interested in how this is currently being done in the wild -- drive-by attack; email with link/attachment; compromised USB stick?

Do you have a URL or captured email that triggers your compromise?

thanks,

-rich

 

Assumption no. 1 is that the system has been compromised. Could be an exploit or anyway way a system can be hacked. Running a script from memory at that point would be no big deal. Also although it isn't explicitly stated, I believe the "compromise" at this point is a backdoor. Once a backdoor has been opened, it is pretty much came over.

Per Eset:

Trojans have various functions, from keylogging (they log and transmit every keystroke), to deleting files or disc formatting. Some contain a special feature that installs a backdoor program, (a client-server application that grants the developer remote access to your computer). Unlike common (legitimate) software with similar functions, it installs itself without the consent of the client computer.
​

Recent example: https://www.incapsula.com/blog/backdoor-malware-analysis-obfuscation-techniques.html

 

-EDIT- Actually the script installs the backdoor.

 

Blogger name is Devek. You might be able to contact him here: https://www.trustedsec.com/contact

 

Good morning, Pete!

Well, corporate culture is in a messy state, for sure!

But that doesn't concern me: I'm more interested in how compromises could occur on my system.

Not much has changed in the delivery methods over the years, but I keep alert for a possible new phase of intrusion! That's why I asked.

----
rich

 

Good example of using .Net to bypass PowerShell GPO restrictions: http://wroot.org/posts/babadook-connection-less-powershell-persistent-and-resilient-backdoor/

 

This could only work if SRP is not configured correctly. If set correctly limited user can not write to locations from which they can execute and can not execute from locations where they can write. So copying or renaming & copying and executing in whitelisted locations would fail with correctly configured SRP and ACL.
Also how would compromise (first assumption) be achieved if we disable scrip engines and powershell (or change powershell execution policies and blacklist PS1 files)?

 

If it's a drive by exploit and the sandboxed browser is set up for only the browser to run in the sandbox, this should terminate the driveby right?

 

I'm referring to ntfs file permission and object ACLs, not SRP which is much weaker. That being said, I generally employ both of them redundantly. The ACL bypass method in this article assumes MS default permissions which should be changed to eliminate all execution permissions anywhere a limited user has write permissions.

The ACL limiting I used is pretty much the same as what AppGuard does. I'm not allowing limited users to access powershell or its dlls. I've taken it one step further and eliminated system from the access list. The beauty of NTFS ACLs is that they are universal and will work regardless of the system or version so the lack of Applocker isn't an issue.