Executive Summary
USB file storage devices have been a popular infection vector for cybercriminals for many years. Despite the development of new infection methods, USB drives continue to be a significant threat to modern-day organizations.
One of the most notable examples of this is the Stuxnet worm, but current day examples include Raspberry Robin, a widespread and dangerous worm that can lead to post-infection ransomware, and PlugX, a sophisticated malware used by multiple APT groups. The Unit 42 Managed Threat Hunting team has identified execution attempts of Raspberry Robin, PlugX, and more across multiple victims over the past several months, indicating that this infection vector is one that still requires attention from defenders.
Threat actors rely on unsuspecting users discovering infected devices and inserting them into systems, where wormable USB malware can persist and spread to other removable media or network drives. This can happen in various ways, such as a USB drive left in a parking lot or a seemingly harmless device given as a gift. Once plugged in, the malware can quietly infiltrate the network and begin to cause damage.
In this article, we will take an in-depth look at threats from removable USB file storage devices. We'll share real-life examples of how USB malware can infiltrate an organization and wreak havoc, how to identify and investigate with Cortex XDR, and we'll examine the reasons why these types of attacks are still so effective.
Step 1: Identity mount/insertion events
// Description: Use Host Insights data to list all attached removable drives.
dataset = host_inventory
| fields host_name, os_type, agent_*, disks, ip_addresses
| arrayexpand disks
| alter drive_type = disks -> drive_type
| alter file_systems = disks -> file_systems
| alter free_space = disks -> free_space
| alter size = disks -> size
| alter device = disks -> device
| alter disk_name = disks -> name
| filter drive_type = "2" // 2: Removable
Identifying all mounted removable media devices is a crucial first step in protecting against USB-borne malware. Identifying these devices can seem daunting, but there are a few simple ways to get started with Cortex XDR. One option is to utilize a Host Insights license and run a specific query to list all currently mounted removable disks. This can provide a comprehensive overview of all devices that have been connected to the system and can help identify any potential threats.
// Description: Show drive mount activity
dataset = xdr_data
| filter event_type = ENUM.MOUNT
| alter mount_point = action_mount_device_info -> storage_device_mount_point
| alter storage_device_class_name = action_mount_device_info -> storage_device_class_name
| alter vendor_id = action_mount_device_info -> storage_device_vendor_id
| alter product_id = action_mount_device_info -> storage_device_product_id
| alter storage_device_drive_type = action_mount_device_info -> storage_device_drive_type
| fields _time, agent_hostname, action_mount_device_info, mount_point, storage_device_*, vendor_id, product_id, agent_os_type, agent_os_sub_type
| filter storage_device_drive_type = "2" // 2: Removable
Another option to identify mounted removable media devices is to use the query provided above. This approach offers two additional benefits over the Host Insights license method. First, it allows you to access historical data to see telemetry from device mounts even after the user has removed the drive. This can be particularly useful in identifying patterns of suspicious activity and tracking the spread of malware within your network.
Second, the query provides VID and PID (vendor ID and product ID) when available. This information can be used to look up the device information using the Linux USB ID repository (http://www.linux-usb.org/usb-ids.html). This can provide additional context and insights into the device, including the manufacturer and model. Additionally, you can optionally upload the USB ID CSV file as a lookup table into your Cortex XDR tenant to further enrich the data, making it easier to identify the device, manufacturer, and other details.
// Description: Detect USB devices inserted into a Windows machine. Uses registry events to detect these devices.
config case_sensitive = false
| dataset = xdr_data
| filter event_type = ENUM.REGISTRY and (action_registry_key_name contains "enum\usb") and action_registry_value_name contains "DeviceDesc"
| fields agent_hostname, actor_effective_username, actor_process_image_path, action_registry*
The last method provided above is not specific to USB file storage devices, but it can be a useful part of any investigation into potential USB-borne malware. This query uses registry events to capture USB device insertions for any USB device. When a USB device is inserted into a system, a registry key is written to the following path:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\
This query can be useful in identifying potential threats because it typically captures a brief description of the device, which is written to the registry key. This can provide valuable information, such as the device's manufacturer and model, which can be used to identify any potential vulnerabilities or known malware associated with the device.
It's worth noting that this method is not limited to USB file storage devices, it can be used to monitor all USB devices. This can be especially useful in identifying malicious USB devices that are disguised as legitimate ones. By capturing all USB device insertions and providing a brief description of the device, organizations can gain a better understanding of what USB devices are connected to their systems and take appropriate actions to protect against potential threats.
Step 2: Identify anomalous activity
Let's look at a couple of detection opportunities for malicious activity:
- Lnk file read from removable drive
- Process launch from removable drive
- DLL load from removable drive
1. Process launch from removable drive:
In this case, we can observe the threat actor attempting to execute processes directly off of the removable drive, without first copying them to the host system. This behavior is uncommon in most environments and especially stands out if the executable is unsigned or has a mismatched file extension.
// Description: Detect processes executed directly from removable drives
dataset = xdr_data
| filter event_type = PROCESS and event_sub_type = PROCESS_START and action_process_device_info != Null
// Device Info parsing
| alter Drive_Type = json_extract(to_json_string(action_process_device_info),"$.storage_device_drive_type"), Drive_Letter = json_extract_scalar(to_json_string(action_process_device_info),"$.storage_device_mount_point"), Device_Serial_Number = json_extract_scalar(to_json_string(action_process_device_info),"$.storage_device_serial_number") // Getting details about the device a file was created on
| filter drive_type = "2" // Removable = 2
| fields agent_hostname, actor_effective_username, action_process_image_path, action_process_image_command_line, action_process_file_info, action_process_signature_status, action_process_signature_vendor, actor_process_image_path, actor_process_signature_vendor, actor_process_command_line, action_file_path, action_process_device_info, Drive_Type, Drive_Letter, Device_Serial_Number, event_type, event_sub_type
2. DLL Load from removable drive:
Similar to the above case, DLL loads can occur directly from the removable drive, instead of being copied to the host system first. These cases are quite suspicious, especially if they are being loaded by other legitimate binaries known for abuse through proxy execution such as rundll32.
dataset = xdr_data
| filter event_type = ENUM.LOAD_IMAGE and action_module_device_info != Null
// Device Info parsing
| alter Drive_Type = json_extract(to_json_string(action_module_device_info),"$.storage_device_drive_type"), Drive_Letter = json_extract_scalar(to_json_string(action_module_device_info),"$.storage_device_mount_point"), Device_Serial_Number = json_extract_scalar(to_json_string(action_module_device_info),"$.storage_device_serial_number") // Getting details about the device a file was created on
| filter drive_type = "2" // Removable = 2
| fields agent_hostname, actor_effective_username, action_module_path, action_module_signature_status, action_module_signature_vendor, actor_process_image_path, actor_process_signature_vendor, actor_process_command_line, action_file_path, action_module_device_info, Drive_Type, Drive_Letter, Device_Serial_Number, event_type, event_sub_type
3. LNK read from removable drive
LNK files are typically abused by threat actors as a mechanism to start the execution chain on the victim system. When the victim clicks on the LNK file, it starts a script or binary that then carries out the rest of the attack. Therefore, one indication of removable media abuse is to look for LNK file read events where the LNK file is located on a removable drive. Without this simple step, threat actors would have to resort to a more sophisticated method of execution such as USB autorun/autoplay (typically disabled) or driver/firmware abuse.
// Description: Detect LNK file read from removable drive
dataset = xdr_data
| filter event_type = ENUM.FILE and event_sub_type = ENUM.FILE_OPEN and lowercase(action_file_extension) = "lnk"
// Device Info parsing
| alter Drive_Type = json_extract(to_json_string(action_file_device_info),"$.storage_device_drive_type"), Drive_Letter = json_extract_scalar(to_json_string(action_file_device_info),"$.storage_device_mount_point"), Device_Serial_Number = json_extract_scalar(to_json_string(action_file_device_info),"$.storage_device_serial_number") // Getting details about the device a file was created on
| filter Drive_Type = "3" or Drive_Type = "2" // CDROM = 3, Removable = 2
| fields Drive_Type, action_file_path, action_file_name, action_file_extension
Case Study: NeksMiner Crypto Worm
The Unit 42 Managed Threat Hunting team recently identified a suspicious DLL that was suspected to be a sample of the NeksMiner crypto worm. Crypto worms can spread through USB storage devices (among other methods) and continue proliferating by enumerating network storage devices and attached USB drives, copying itself to each one. The identified sample was introduced into the customer environment through a removable USB device.
It can sometimes be hard to tell when activity originated from a removable USB device, as shown in Figure 1. Since the legitimate "rundll32.exe" binary on the host machine's disk is used to proxy execution (MITRE ATT&CK subtechnique T1218.011), there's no obvious indication of any removable drive activity.
However, we also get our first clue in Figure 1 by noting the "Module Path" for the suspicious DLL is not on the C:\ drive. This indicates that we may need to look for drive mount activity.
Using the above queries to detect USB storage devices, we can see a removable drive was indeed mounted shortly before the suspicious event. Upon further investigation, we can see a malicious LNK file was present on the drive, and this malware relied on the user clicking the LNK file to start the execution chain (see Figure 2).
When the user clicks on the LNK file, this creates a "File Read" event for the LNK file performed by File Explorer (explorer.exe). Shortly afterward, File Explorer will spawn a child process according to the contents of the LNK file.
Why USB malware continues to be effective
Most USB malware relies heavily on social engineering to trick users into opening their payloads. Modern USB malware typically uses a .LNK to execute, triggering a script or executable stored elsewhere on the removable drive. The trick here is that malware authors can typically hide all malicious binaries and scripts out of view of the user. This can be accomplished through simple hidden folders, although more sophisticated malware may use even stealthier methods. All that appears in the drive is the .LNK itself, which can be visually modified to make it more likely for the user to click on it.
Besides the above, many organizations still do not enforce strict USB storage device controls throughout their environments. A simple control would be a technical measure to prevent users from using or mounting USB storage devices on their hosts, subject to any necessary exclusions. Without these controls, mistakes could allow malware to infiltrate through infected USB devices, or even be unintentionally transferred from unsecured personal devices.
Summary
USB spreading malware is a technique attackers use to gain initial access into organizations. This type of malware can infect a computer when a USB device, such as a flash drive, is plugged into it. The malware can then spread to other computers and other USB devices on the network. The above queries can be used as part of a threat hunting engagement to check if these techniques are being used in the environment, or as part of an investigation into specific activity to see if USB devices may have been used as the initial infection vector.
About Unit 42 Managed Services
Unit 42 Managed Threat Hunting is a powerful service that empowers organizations to stay ahead of the ever-evolving threat landscape. Led by the renowned Unit 42 threat intelligence team, this service is designed to identify hidden attacks that would otherwise go undetected. Our team of expert threat hunters uses a combination of human expertise, big data analytics and comprehensive threat intelligence to surface malicious tactics, techniques, and procedures hiding in plain sight. This cutting-edge service is fueled by data collected and retained in the Cortex Data Lake, ensuring that organizations have access to the most comprehensive and accurate information available. With Unit 42 Managed Threat Hunting, organizations can take proactive steps to protect their assets and stay one step ahead of cybercriminals.