How to Blue Team: Detecting USBs Spawning Scripts (Malware Infected USBs) on Windows machines

Ryan Glynn/ September 15, 2018/ Security and Technology/ 0 comments

Introduction to How to Blue Team:

There’s a lot of documents on how to use pen testing tools, how to crack, hack and break into things. Not a lot is written on how to detect these things, especially at the “Enterprise” level where a lot of the blog posts seem to give use cases that do not scale well. So, I figured I would share the things that I learn and what I feel are important aspects of Blue Team Monitoring that do not have good resources currently.

One thing to note about these posts is that they are platform independent. What does that mean? It means that I am not going to be posting “Splunk syntax” or “Elastic Syntax” or any platform specific methods of detection but rather I will tell you how to detect it regardless of which platform you run within your enterprise. While there are cool projects like https://uncoder.io/ – a lot of the posts I am going to make are not supported by this project due to some platforms not having the same functions as others.

This is the first post in the series so please leave comments and feedback and come back for more! Or look through my other blog posts for more if you’re visiting this page well after this post date.

Detecting USBs Spawning Scripts on Windows Machines

Cyber Kill Chain Category: Delivery

Fidelity: 3/5 (Medium)

Purpose and Goal

Something that happens commonly in an enterprise environment is that users plug things into their computers. It could be personal cameras, flash drives, or whatever. The fact of the matter is that people will plug whatever they feel like into their assets and therefore, if those “things” are infected, then chances are your asset will be too. Sure, your anti-virus might detect it, but it also might not — if it’s a signature based AV then it might be a new form of malware that is not on the signature list, or perhaps the vendor removed the signature to make way for newer malware. Or if it’s something “behavior” based like Cylance then it doesn’t scan scripts and only executable files — so any script based malware will by pass you completely.

That is where your SIEM comes into play. Detecting USBs plugged into corporate assets unfortunately is as simple as I would like. In enterprise environments, you have a plethora of network shares, mapped drives and other items that at the logging level look very similar to mapped USBs. However, there are tricks in order to look for behaviors that are more similar in an infected USB than a regular shared drive.

The high level goal is to find infected USB devices that attempt to propagate onto other devices via scripts (either auto-exec or through disguised malware).

Note — this is currently only for Windows. I will write another post when I have the Apple/Mac equivalent tested and confirmed.

Data source(s) needed:

• Sysmon or endpoint monitoring equivalent for Windows hosts (not Windows event logs)

Writing the Alert

Using an endpoint monitoring tool, this alert actually becomes rather simple:

1. Parent Image must be Explorer.exe
2. Image must be one of the following:
   1. cmd.exe
   2. powershell.exe
   3. wscript.exe
   4. cscript.exe
   5. java.exe
   6. javaw.exe
3. The current direction must not be any of the following:
   1. C:\.*
   2. \\.*
4. The executed command must not reference the current working directory (e.g. command_line DOES NOT CONTAIN working_directory)

That is pretty much it. There may be a few (less than 10) commands or scripts to white-list within the environment but running the logic above in your favorite SIEM should yield some interesting results (if any).

Breaking the logic down:

Let’s break the steps down.

1. Parent Image must be explorer.exe

This is because we are looking at USBs that attempt to propagate either via masquerading as a legitimate file for a user to run (e.g. the user double clicks a file on the USB) or it auto-starts when plugged in. Both cases should show up with parent image of explorer.exe (if your mileage varies on the auto-start let me know).

2. Image must be one of the following:
1. cmd.exe
2. powershell.exe
3. wscript.exe
4. cscript.exe
5. java.exe
6. javaw.exe

This should be pretty straight forward – we want to find where anything on the USB calls a script — the above covers the major types including (but not limited to) batch, powershell, javascript and java.

3.The current directory must not be C:\* or \\*

The current directory should be the directory of the USB. \\* also removes any network shares.

4. The executed command must not reference the current working directory

This part is a little bit less intuitive. But if you do not do this part then you run into an issue where individuals that have mapped network shares as drives (e.g. D:\) will blow up the above alert logic. One thing that will become pretty apparent is that the scripts run from network drives typically (not always) reference absolute paths because the drives are already mapped.

For example, if Joe runs D:\job_stuff.bat — then typically the stuff within the .bat file references files within D: (e.g. cd D:\daily_reports). USB Malware will not. Why? Because it doesn’t know what drive it’s going to be mapped to. So it is going to reference relative paths if it references additional files on the USB.

All logic above should be case insensitive. Otherwise you will run into many false positives.

How to Investigate

There may be a few network shares that do not reference any network based files. Those could be put into a white-list of sorts, but there shouldn’t be too many unless a team in your environment relies heavily on shared drives to perform tasks on local disks on other computers.

When the alert fires, ensure it’s a USB drive instead of a network share. If you are part of the Incident Response/SOC teams you should be able to access the devices to ensure what type of mapping it is.

Outside of this, investigations around this alert are pretty straight forward as long as you know how to process chain (or if your tool does it for you). Stringing together from the originating Process ID (PID) you can search the logs for anything that PID may create  (e.g. if the USB script PID is 123 then searching where parent_process_id =123) in order to see what else gets called. If it’s malware you may see weirdly named script files (wzy532u.js) that then call additional items. Gathering up these PIDs and then pulling the endpoint’s network connections are necessary to see if the malware attempts to create a Command and Control (C2) channel.

That’s all I have for this alert. Let me know if you have any questions or need clarification in the comments!