Now you see me: Exposing fileless malware

[ParaXY]

I'm late to the conversation regarding setting ConstrainedLanguage for Powershell by running:

[Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)

but I have now enabled this so am hoping this helps lock down my desktop even further.

I have some reading to do about this so thanks for bringing this to my attention!

 

[WildByDesign]

I'm late to the conversation regarding setting ConstrainedLanguage for Powershell by running:

[Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)

but I have now enabled this so am hoping this helps lock down my desktop even further.

I have some reading to do about this so thanks for bringing this to my attention!

I forgot to mention this initially, but let's say you need to temporarily disable Constrained Language Mode (CLM) or remove it completely, you can go to:

Control Panel > System > Advanced System Settings > Environment Variables and simply delete _PSLockdownPolicy 4 from System Variables section.

CLM blocks any PS functionality that requires any of the more advanced languages that PS has access to and therefore has the potential to block a lot of legitimate PS usage. It does not break basic system functionality for running Windows, however, if you have certain special scripts and programs that you run once in a while which require more language support via PS, then temporarily disabling CLM for brief periods of time can be handy.

For example, I only ever have to disable CLM temporarily when I play around with the ProcessMitigations PS module, and in particular the updating of certain PS modules at times.

EDIT: But in general, I easily go 3-4 weeks at a time between ever having to temporarily disable CLM. Although this, of course, is dependent upon individual user use cases based on the software they use.

 

[ParaXY]

That's really helpful, thank you. I was wondering about temporarily disabling it. I'm hoping I won't have to but at least I know how to now.

 

[Andy Ful]

That's really helpful, thank you. I was wondering about temporarily disabling it. I'm hoping I won't have to but at least I know how to now.

You can also do this by a simple reg tweak. Pressing the reg file that will make the proper changes is slightly more convenient.
How-to Guide - How do you secure PowerShell?

 

[509322]

I don't know what you are saying. The post I made which you quoted is about malware authors not genuine developers at MS. I'm saying that malware authors choose to use it when they do because is quick and easy for them to do/deploy and it is true that many AVs struggle with PS scripts.

@Opcode

I'm cross-eyed today.

 

[509322]

Malc0ders do not need the stuff that Constrained Language Mode disables to completely smash a system. All they need is PowerShell to be enabled.

 

[Deleted member 178]

Disabling powershell 2.0 in Programs & Features doesn't disable powershell, it just disable this obsolete, unsecure and over-abused legacy version... Win10 use Powershell 5.0.

 

[shmu26]

I forgot to mention this initially, but let's say you need to temporarily disable Constrained Language Mode (CSL) or remove it completely, you can go to:

Control Panel > System > Advanced System Settings > Environment Variables and simply delete _PSLockdownPolicy 4 from System Variables section.

You don't even have to delete it. All you have to do is change the value from 4 to 0. That makes it super easy to just re-enable it again by changing it back to 4.

 

[shmu26]

Generally yes. But Constrained Language mode will not protect you against some PowerShell attacks performed as standard user (uncommon in the wild).

So this advanced bypass technique is by reflexively loading the dll?

 

[ParaXY]

Malc0ders do not need the stuff that Constrained Language Mode disables to completely smash a system. All they need is PowerShell to be enabled.

Luckily AppGuard does that for me

 

[Andy Ful]

Malc0ders do not need the stuff that Constrained Language Mode disables to completely smash a system. All they need is PowerShell to be enabled.

That is true in theory and may be the fact in the future.
Bypassing it is not a rocket science because I can do it.
But so far, Constrained Language mode is the most effective security against almost all dangerous PowerShell attacks, including targetted attacks based on pentester tools like Metasploit.

 

[Andy Ful]

So this advanced bypass technique is by reflexively loading the dll?

The word bypass is slightly misleading. CLM restricts PowerShell from accessing advanced PowerShell capabilities which are also very common among in the wild PowerShell attacks. But as both me and @Lockdown have mentioned this cannot fully protect against the potential infection.
If you really want to see the POC I can PM it to you.

 

[shmu26]

The word bypass is slightly misleading. CLM restricts PowerShell from accessing advanced PowerShell capabilities which are also very common among in the wild PowerShell attacks. But as both me and @Lockdown have mentioned this cannot fully protect against the potential infection.
If you really want to see the POC I can PM it to you.

Thanks. So even if an attack succeeds in reflexively loading the dll, the restrictions of CLM still apply?

 

[Deleted member 65228]

I've never tried it but maybe running PowerShell from memory even while it's technically "disabled" would work. For anyone unaware, running from memory means you don't spawn a new process for it.

You could also try dynamic forking with PowerShell.exe. Target the EIP for 32-bit dynamic forking or RIP for 64-bit dynamic forking. When you hijack the EIP/RIP to set to the correct new entry-point address, that is thread hijacking technique FYI.

To solve command line arguments, do some manipulation of the Process Environment Block ([FS:0x30] or [GS:0x60]) and then + 0x020 for the RTL_PROCESS_PARAMETERS*. It might work - PowerShell.exe in-memory but not in it's own process may then still function based on the command line arguments.

Just a note though, the CommandLine field of the RTL_PROCESS_PARAMETERS is UNICODE_STRING so you must update the Length and MaximumLength fields of the UNICODE_STRUCTURE for that entry for stability purposes, otherwise if the Length and MaximumLength fields are used for usage of the Buffer, the calculations will be incorrect and thus can lead to a crash depending on the operation.

To calculate the correct lengths of a unicode encoded buffer for a UNICODE_STRING structure:

1. Length field is the number of characters in the wchar_t buffer multiplied (*) by 2 -> use wcslen(...) * 2
2. MaximumLength field is the Length field add (+) 2 -> use <unicodestringvariable> ./- Length + 2

I am leaving this info here in case someone is interested enough to try it out. If no one else wants to try it out then I'll probably do it one day if I can be bothered enough. I recon it would work.

 

[Deleted member 65228]

Thanks. So even if an attack succeeds in reflexively loading the dll, the restrictions of CLM still apply?

If you manually map a module into the address space of a process, it doesn't change anything other than that module is not linked to the Process Environment Block's Ldr field. The Ldr field is the start of all the module information... There's a doubly linked list which is accessible in these areas and it holds a list of all the modules loaded in-memory of the current process.

In the past you could actually remove from the list during execution to hide a module which was loaded without manual mapping and it'd pretty much replicate the effect of manually mapping a module but Microsoft changed some things and block this technique now.

Any mitigations for that current process will be applied for code executing under it, whether the module the code belongs to is "visible" or not. Manual mapping isn't actually as stealth as some make out though, it can actually raise more alarm if you're using some home-brew aggressive security product by flagging suspicious executable memory regions and stuff.... VAD memory forensics is good for finding it as well.

So reflectively loading a DLL should have zero effect on bypassing mitigation this or that for whatever. It depends on how it is enforced I guess.

For example:
1. If product A patches function X in process A but manual mapping is used and a copy of function X is in the manually mapped module then the product A may not know about the module load and thus cannot re-patch function X to enforce the patch
2. If product A enforces mitigations for process A but it doesn't rely on knowing about the code in product A to patch it -> still enforced regardless

PowerShell mitigations won't be enforced with user-mode patching like that so it should have zero effect

--

Most people manual mapping don't even understand the simple of theory about it let alone know how to do it themselves anyway. Most just copy paste lol. In fact most I see mentioning it don't even understand it, except a few here at least

It's just replicating the Ldr* NTAPI routines. You literally just re-implement what some Ldr* routines do. It's pretty simple and straight forward but people act like it's some godly creation.

To explain it in most simple way:
It's pretty much just copying code from a DLL across to executable buffer and fixing addresses/offsets -> then invoking the DllMain

 

[Deleted member 65228]

PowerShell mitigations won't be enforced with user-mode patching like that so it should have zero effect

And if it does then it is really stupid because it "shouldn't"

 

[Andy Ful]

Thanks. So even if an attack succeeds in reflexively loading the dll, the restrictions of CLM still apply?

Yes If this DLL will try running native PowerShell (ver. 3.0 or later). No, If this DLL is fakePowerShellDLL = DLL that is a replacement of native System.Management.Automation.dll . But such attack would be a kind of upside down. So far, PowerShell is commonly used in the first stages of infection, for example, to download and execute the reflective injector. So, the reflective injection normally happens after executing PowerShell (not before).

 

[shmu26]

Yes If this DLL will try running native PowerShell (ver. 3.0 or later). No, If this DLL is fakePowerShellDLL = DLL that is a replacement of native System.Management.Automation.dll . But such attack would be a kind of upside down. So far, PowerShell is commonly used in the first stages of infection, for example, to download and execute the reflective injector. So, the reflective injection normally happens after executing PowerShell (not before).

Sounds good. So the CLM restrictions will apply in the common cases of a "living off the land" attack. If the malware brings along its own PS tools, that's another story.

 

[Deleted member 65228]

Sounds good. So the CLM restrictions will apply in the common cases of a "living off the land" attack. If the malware brings along its own PS tools, that's another story.

Basically Microsoft are incapable of thinking "security" until it is too late. And then they mess that up too

 

[Deleted member 65228]

Speaking of System.Management.Automation... Did anyone else but me read the AMSI exploit details?

Satoshi's note: AMSI Bypass With a Null Character

It was an interesting find of his, luckily it was fixed sooner than later