Now you see me: Exposing fileless malware

[509322]

Deep in the heart, I would like to disable the PowerShell library system.management.automation.dll.
PROS:​

• After blocking this library the PowerShell 3+ is dead.
• One can copy PowerShell executables to another folder with another filename and it still will be dead.
• One can compile an application that uses PowerShell functions directly from this library (not using PowerShell executables) and this also will fail.

CONS:​

• There is no good Windows built-in mechanism to block this DLL in Windows Home and Pro.
• One could use SRP with DLL checking but this will break Edge and can slow down the system.
• Microsoft announced that PowerShell will replace CMD, and CMD is commonly used by some system scheduled tasks and 3-rd party programs.
• The scheduled task sdiagnhost.exe can often trigger troubleshooter scripts TS_WERQueue.ps1, TS_DiagnosticHistory.ps1, and the library of functions CL_Utility.ps1
• Some popular applications use PowerShell like: Chocolatey, K-lite codec pack, etc.
• PowerShell can be used by hardware vendors to update their software.

So, blocking the PowerShell library system.management.automation.dll can be recommended to advanced users.
I would not recommend it on computers of average users.​

• Microsoft is only replacing the CMD console with PowerShell console; cmd.exe is still going to execute the command line function on Windows.

 

[Deleted member 178]

PowerShell should be disabled. The vast majority of Average Joe users never need it. Therefore, they are specifically the ones who should not have it enabled by default. Microsoft itself advises to disable PowerShell when it isn't needed.

+1, the only time i used Powershell was to reset the Metro Apps after some issues with the store.

 

[shmu26]

Time will tell, we might find out that Microsoft (and other vendors) will be using powershell more and more.

 

[Deleted member 178]

Time will tell, we might find out that Microsoft (and other vendors) will be using powershell more and more.

Of course they will, they said it. The issue is how the defenses about its exploitation will be without hampering the OS.

 

[Andy Ful]

Preventing the loading of system.managment.automation.dll does not break Edge. I have it disabled from all file paths system-wide on Windows 10 and Edge works and there is no problem with Windows. Microsoft recommends to disable it and there is no advisory that disabling it will cause any problem on WIndows.
...

I did not say it (see the red fragment). I said that SRP with DLL checking breaks Edge.
If you know how to disable this DLL using Windows features I would be grateful.
I also did not say that blocking it will break Windows. Personally, I like the blocking idea.
Anyone can see PROS and CONS from my previous post and decide which to choose.

 

[Andy Ful]

PowerShell should be disabled. The vast majority of Average Joe users never need it. Therefore, they are specifically the ones who should not have it enabled by default. Microsoft itself advises to disable PowerShell when it isn't needed.

I can fully agree with this appeal. If I could propose something, I would like Microsoft to drop also .NET Framework, WMI, CMD, Windows ScriptHost, Bash, SMB protocols, Remote services and some other features which are unnecessary to home users.

 

[ParaXY]

@ParaXY, @shmu26

I know you keep PowerShell disabled. Have you experienced any problems with Windows Updates not installing any feature updates or Office 2016 not updating because PowerShell is disabled ?

I've had PS disabled with AppGuard for many months now and I don't think I have had a single issue with doing this. Since I work in IT I do *temporarily* enable PS to test a script I have created. Other than that, it stays disabled until I need it and my system runs just fine. I have upgraded Windows 10 from 1703 and 1709 and this went fine.

Hey, I'm on your side, but I'm not convinced of the effectiveness of CLM by what I have seen in messing with it. So instead I choose the nuclear option. I know you have that PoC. If you have a PoC - and there are other PoCs - I wonder what some criminal has done. So the probability is that there is already nasty stuff somewhere in the works or out there in the wild. We just ain't heard of or seen it yet.

The only effective way to protect a system against PowerShell attacks - right from Microsoft Security itself - is to disable the shell and system.management.automation.dll at the same time. All paths *powershell*, *powershell_ise* and *system.management.automation*.

Even then, I don't fully trust what Microsoft advises will provide absolute security !!!

MetaSploit, PowerSploit, and such pen-test tools make for really disingenuous videos where the user had to allow something - like macros - in an Office Word document. Plus the video creator does not explain that such attacks are targeted and instead leaves the Average Joe who doesn't know nor understand anything that is happening in the video, to view and arrive all by themselves at all the wrong face-value conclusions and go crazy in their mind. Now some would argue that the video creator is lying by omission to the viewer as well as creating fear, uncertainty and doubt.

It's basically in the same vein as the IT security news that reports things without fully explaining things - the exceptions and caveats - to the general public.

The question I have is, should I block system.management.automation.dll in AppAguard from running? (ie: add it to user space)

Where can I find system.management.automation.dll in Windows 10? I did a search and couldn't find it...

Edit: Ok, my search came back with many results after waiting long enough. Is this the one to block:

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll

 

[Andy Ful]

...
Edit: Ok, my search came back with many results after waiting long enough. Is this the one to block:

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll

For the maximum safety, you should block all instances, because those DLLs can be loaded by the malware to run advanced PowerShell capabilities. That is the idea of blocking System.Management.Automation.dll .
If you block only that one DLL which is loaded by the native powershell.exe than you can skip DLL blocking and simply block powershell.exe.

 

[Deleted member 65228]

If you block only that one DLL which is loaded by the native powershell.exe than you can skip DLL blocking and simply block powershell.exe.

You can re-name the System.Management.Automation.dll to something else and still get PowerShell (also re-named) to work though. Therefore, you can block it with these techniques... But it'll never be full-proof because nothing is.

 

[Andy Ful]

You can re-name the System.Management.Automation.dll to something else and still get PowerShell (also re-named) to work though. Therefore, you can block it with these techniques... But it'll never be full-proof because nothing is.

That would be hard for the malware running as standard user against AppGuard, because the renamed DLL will be blocked in the Userspace.

 

[WildByDesign]

So, blocking the PowerShell library system.management.automation.dll can be recommended to advanced users.

I would not recommend it on computers of average users.​

Speaking of this, what are the general thoughts on blocking system.management.automation.ni.dll as well?

It has been a while since specific testing, but I recall some targeted C# PowerShell bypass executables which from my understanding would dynamically create this system.management.automation.ni.dll module as a means of its bypass technique.

For example, in the Excubits command line rules, I would typically block something such as "*>*system.management.automation*.dll*" to cover for this. But I was wondering other users thoughts specifically on system.management.automation.ni.dll. Both PowerShell and .NET are areas in which I have less experience with but I am playing catch up with now due to the relevance of these possible attack vectors.


By the way, I am really enjoying and appreciating the great activity and participation level of this forum. It has taken me some time to get warmed up here but I am enjoying it.

 

[shmu26]

Block it with a wild card: C:\*System.Management.Automation.dll

 

[shmu26]

Speaking of this, what are the general thoughts on blocking system.management.automation.ni.dll as well?

It has been a while since specific testing, but I recall some targeted C# PowerShell bypass executables which from my understanding would dynamically create this system.management.automation.ni.dll module as a means of its bypass technique.

For example, in the Excubits command line rules, I would typically block something such as "*>*system.management.automation*.dll*" to cover for this. But I was wondering other users thoughts specifically on system.management.automation.ni.dll. Both PowerShell and .NET are areas in which I have less experience with but I am playing catch up with now due to the relevance of these possible attack vectors.


By the way, I am really enjoying and appreciating the great activity and participation level of this forum. It has taken me some time to get warmed up here but I am enjoying it.

Ah, I see you beat me to it. So better with two wildcards, like you said. I think this will work in Apguard
C:\*System.Management.Automation*.dll

 

[Deleted member 65228]

If you did want to re-name System.Management.Automation.dll then this is how you would do it and still get PowerShell.exe to work.

1. Start PowerShell.exe (re-named) with CREATE_SUSPENDED flags
2. Patch the entry-point of PowerShell.exe to redirect to some shell-code (allocate memory and fill it with the shell-code obviously)
3. NtResumeThread -> main thread of PowerShell.exe (re-named)

Alternatively you can locally patch a routine like NtResumeThread and then do your virtual memory operations.

The injected shell-code which will be executed after #3 can patch LdrLoadDll (NTDLL) and LdrGetDllHandle (NTDLL). Since shell-code isn't linked to the IAT you have to find the PEB and go through the Ldr linked list yourself to find the base address of NTDLL and then parse NTDLL image in-memory with an EAT scanner... not that bad. PEB is located at FS:[0x30] for x86 processes and GS:[0x60] for x64 processes. Then you can find address of LdrLoadDll/LdrGetDllHandle easily.

LdrLoadDll callback (called by LoadLibraryExA/W):
- Filter for the System.Management.Automation.dll and alter parameters so it targets the re-named copy -> there's a PUNICODE_STRING data-type parameter and thus you can update the Buffer (along with the Length & MaximumLength calculations of course)

LdrGetDllHandle (called by GetModuleHandleA/W):
- Do the same as in the LdrLoadDll callback

Now when PowerShell.exe tries to find System.Management.Automation.dll, the execution flow has changed in-memory and it still gets back its module handle even though it's a re-named copy. It'll be oblivious that the module has even been re-named, it should function perfectly fine. Since PowerShell.exe doesn't manually map the System.Management.Automation.dll nor parse the Process Environment Block's Ldr linked lists to get the base address of the System.Management.Automation.dll but invokes Win32 API instead itself, I see no reason for it to not work.

As for the start of what you could do, you don't have to patch the EP. You could do something different like hijack the EIP/RIP of the main thread before resuming, then redirect back to the original EP after the shell-code has been executed. You could even patch the LdrLoadDll/LdrGetDllHandle stubs themselves which are going to be invoked anyway and thus not hijack the thread or patch the EP at all.

If you didn't care for on-disk patching then you could always just patch the binary on-disk and completely avoid starting it up and then remotely patching the memory prior to allowing it to execute it's own code. That too.

 

[Deleted member 65228]

If you want to block PowerShell then a much a more reliable method would be via generic signatures. In which the generic signatures represent bytes within the PE. Using wild-cards helps in case the binaries are updated in the future. PowerShell could always be packed and un-packed in memory so doing it with a memory scanner combined, that would be good.

File name restrictions is fine anyway because chances of malware doing something like re-naming those DLLs and then patching it to update this and that blah blah blahhhhhhh.... malware in the wild targeting home users won't do that. And most malware authors using PowerShell probably won't even know much about such topics or about anything except how to use ctrl + C. So there's no need to care anyway.

If you ask me, Microsoft should just drop PowerShell and work on something better in terms of security. That, or really really restrict what the process can do to stop loads of things which shouldn't be done by it in the first place.

 

[Andy Ful]

That would be hard for the malware running as standard user against AppGuard, because the renamed DLL will be blocked in the Userspace.

Speaking of this, what are the general thoughts on blocking system.management.automation.ni.dll as well?
...
By the way, I am really enjoying and appreciating the great activity and participation level of this forum. It has taken me some time to get warmed up here but I am enjoying it.

You are welcome. Thanks for recalling system.management.automation.ni.dll. This is a native image of system.management.automation.dll and should be blocked, too.

 

[shmu26]

But realistically speaking, as long as the user has a default/deny setup, and/or he willingly refrains from running unknown files on his PC, the attack vectors for powershell attacks are relatively limited.
The browser? Most people are using a modern browser with strong built-in security.
Pics and vids and music? Windows 10 opens them by default in appcontainer-protected programs.
MS Office docs? If they are downloaded from the net, they automatically open in protected mode.
If I am not mistaken, it is almost always the people that flout basic security rules who get bitten by powershell.

 

[Andy Ful]

But realistically speaking, as long as the user has a default/deny setup, and/or he willingly refrains from running unknown files on his PC, the attack vectors for powershell attacks are relatively limited.
The browser? Most people are using a modern browser with strong built-in security.
Pics and vids and music? Windows 10 opens them by default in appcontainer-protected programs.
MS Office docs? If they are downloaded from the net, they automatically open in protected mode.
If I am not mistaken, it is almost always the people that flout basic security rules who get bitten by powershell.

You forgot about DDE in MS Office.
Also, documents from archives, Fat-32 pendrives, ISO images, etc. get lost 'Mark of the Web', so they will not be opened in protected mode.
But, you are certainly right about default-deny setup and running/opening unknown files. The PowerShell malware files are especially dangerous for average users, because most of them are happy clickers.

 

[ParaXY]

Ah, I see you beat me to it. So better with two wildcards, like you said. I think this will work in Apguard
C:\*System.Management.Automation*.dll

It looks like this works in AppGuard:

I had PS blocked already so I have no idea if this is going to help me as I still get the usual AppGuard error to say it has been blocked:

 

[Andy Ful]

...
I had PS blocked already so I have no idea if this is going to help me as I still get the usual AppGuard error to say it has been blocked:

View attachment 181110

I think that this could help:
Now you see me: Exposing fileless malware
You did not have PS blocked (only PS executables were blocked). Some malware can use PowerShell while not using PS executables, except when you block System.Management.Automation DLLs.