Checking up on Malware with Script Block Logging

Checking up on Malware with Script Block Logging

Download 1

So in the last two posts: (Blocking Ransomware with Honeypots and DNS blackholes for Ransomware), we looked at using FSRM to immediately block SMB share access for someone who triggers a honeypot (not a known extension but a honeypot) and then how to see, with a level of certainty, where that attack came from. Now we’re going to see what we can find out about that malware itself.

Since Powershell v4 Microsoft has included Script Block Logging (SBL) in one form or another but since WMI 5.1 (Powershell 5.1), Script Block Logging now works on C# applications (.NET apps) as well as Powershell.

So why do we care? Well, Script Block Logging allows us to see every command run on the machine in Powershell – exactly what that command contains, what it called and super importantly, what was processed. So this is how we get around obfuscated code. I’ll show you how it works.

Firstly, turn it on with this registry key (you can push this out by GPO – I assume people know how).

Windows Registry Editor Version 5.00

Once that’s on your PC, reboot – because HKLM.

Now we want a test Powershell script with obfuscated code. Microsoft provide us this one:


function SuperDecrypt {
$bytes = [Convert]::FromBase64String($script)
## XOR “encryption”
$xorKey = 0x42
for($counter = 0; $counter -lt $bytes.Length; $counter++)
$bytes[$counter] = $bytes[$counter] -bxor $xorKey
$decrypted = SuperDecrypt "FUIwQitCNkInQm9CCkItQjFCNkJiQmVCEkI1QixCJkJlQg=="
Invoke-Expression $decrypted

Now we can see the obfuscated string here -“FUIwQitCNkInQm9CCkItQjFCNkJiQmVCEkI1QixCJkJlQg==” and we have no idea what’s it’s doing. But let’s have a look at what SBL can tell us about all this. I’m saving this into “sbl.ps1”

Let’s go to the Windows Powershell\Operational log:

First up, we see the actual command, as it was run from powershell.

Next up, we can see the actual contents of the script, as they stand (or part of the c# code):

But we still don’t know what it did! Fortunately, SBL tells us that too, by interpreting the actual runtime of the script for us:

So now we know the obfuscated code just wrote out “pwned”! Great! We can now use SBL to work out if our malware installed a keylogger or whatever else it did, even when it’s obfuscated.

EventID 4104

But wait! There’s more!

Microsoft has been helpful here in another way – that event ID, 4104, is Microsoft’s way of telling us they consider this code to be suspicious. So we don’t even have to think about this too much or go hunting for problems. We can actually use this to alert us to attacks in our network, in real time. Even better – event ID 4104 is logged even if you forget those registry keys above (you don’t get the other things we’re logging but you do still get the suspicious event log).

So now we can just go to the task scheduler and add a new EVENT driven ID (yes, it can have tasks scheduled on events, not just time) and that schedule could email admin or shutdown the effected PC or whatever you want.

Then just make your own command to run to do what you want (blatt to send an email or shutdown -t 1 to shutdown, whatever you feel is appropriate).

About the Author


RodneyI'm a veteran of way too many years of IT (although I still love it) and I currently head up the techincal work over at Host One (major sponsor of this site), where I'm also a partner. Feel free to ask me anything about Cloud Computing and I'll try to be helpful, in a non-salesy kind of way.View all posts by Rodney →

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.