Malware Investigations
How do you know if an unknown program is evil?
Suspicious isn't necessarily malicious
Oddly named executables aren't enough, might still be benign
How can you determine indicators?
Someone might have reverse engineered it already
But not always … and sometimes signatures change
We might see a running process that is suspicious, but whether it is malicious is unknown. For example, an oddly-named process that is not flagged by antivirus. Since suspicious isn't necessarily malicious, you would need to investigate the unknown process.
When investigating malware, two main methods are used:
Behavioral analysis, which involves monitoring how the malware interacts with its environment using specialized tools
Direct code examination with debuggers and disassemblers.
Online Analysis Sites
Online analysis sites like VirusTotal can quickly check potentially suspicious software by scanning it with multiple antivirus tools.
Hybrid Analysis lets you upload a file and choose a virtual machine (e.g., Windows 10, Windows 11) to observe its behavior.
Practicing Good Hygiene
When investigating malware, always adhere to strict security practices to prevent accidental spread or negative exposure for your organization.
Never investigate malware directly on your primary system due to the risk of it escaping. Ideally, use an air-gapped system and wipe it after each use, though this is often impractical during an incident.
For malware investigation, using a virtual machine with host-only networking is common. Despite this, maintain good security practices on the host, such as enabling firewalls and keeping the system updated. When transferring data, use USB drives for air-gapped systems or folder sharing features in virtualization tools, but only enable these temporarily to minimize risks.
Basic Attributes
One of the first things to do when investigating malware is to calculate a cryptographic hash sum. To calculate a SHA256 hash for a Windows file with PowerShell, you can use this command:
Get-FileHash file
You can also add the argument -Algorithm SHA1 to calculate a SHA1 hash instead. On Linux, the equivalent command is:
sha256sum file
Monitoring the Environment
A common malware investigation strategy is monitoring its interactions with the environment, which is faster and partially automatable compared to code analysis, though it may miss certain details.
The basic strategy for monitoring malware is as follows:
Set up the environment, including configuring monitoring tools (temporarily disable them until ready).
Take a snapshot if using a virtual machine.
Enable monitoring tools and take the first snapshot (if applicable).
Run the malware.
Interact with the malware to understand its behavior.
Use commands like Stop-Process to terminate it if needed.
Disable monitoring tools and take the second snapshot (if using one).
Review the output and compare snapshots if applicable
Snapshot vs. Continuous Recording
Some malware monitoring tools take snapshots of the environment at specific points, allowing comparison before and after the malware runs. Others continuously record the environment, logging activity from when the malware starts to when it's stopped for later analysis.
Continuous reporting tools provide more data than snapshot tools, capturing events like file creation and deletion that snapshots might miss. While they offer greater detail and insight, the large volume of data can also be overwhelming.
Regshot
Regshot is a Windows tool that records snapshots of the registry and file system at two points, highlighting changes such as added, removed, or modified registry keys and files. It's simple to use and provides a clear summary of the differences.
Run Regshot as an administrator, check the "Scan dir" box, and add directories to scan for file system changes.
Prepare the malware to run, but don’t execute it yet. Set everything up, minimizing system changes to reduce irrelevant data in the comparison. If using a virtual machine, take a VM snapshot.
Take the first Regshot snapshot by clicking "1st Shot | Shot."
Run the malware and interact with it if needed, then terminate it.
Take the second snapshot by clicking "2nd Shot | Shot."
Click "Compare" to review the changes between snapshots.
Regshot Output
Here's an example of Regshot output. It shows files created by the malware in C:\Users\mike\AppData\Local\Temp. The .pf files listed are Prefetch files, which weren't created by the malware but were generated as a result of it running. Prefetch files help Windows speed up program startup by tracking memory pages used during launch. From an investigative viewpoint, they reveal when and where a program was last run.
Process Monitor
Process Monitor is a Microsoft tool for real-time monitoring of registry, file system, network, and process activities, including profiling events. You can filter information by toggling activity categories using the five buttons for registry, file system, network, process, and profiling.
When reading Process Monitor output, the Operation, Path, Result, and Detail columns are where information about what the process was doing is displayed.
Under the Tools menu, several options summarize activity categories. The Process Activity Summary provides a count of the registry, file, and network areas used by each process. The Registry Summary shows distinct registry keys accessed and how often. The File Summary does the same for files, and the Network Summary lists visited network addresses. The Profiling Events option summarizes process exits, including execution time, CPU, and memory usage.
One of Process Monitor's more useful summary tools is the Process Tree. You can activate it by clicking Tools -> Process Tree to see visually which processes spawned other processes. What makes this especially nice is that unlike Task Manager, this view will also show processes that are no longer running.
Analyzing Code
Another way to investigate malware is by analyzing its code. IDA Pro is a leading tool for code analysis and reverse engineering, featuring a disassembler, debugger, extensive plugin support, and compatibility with various CPU and memory architectures. It also includes the Hex-Rays Decompiler for converting binaries into readable C-like code.
Lab 1.4: Malware Investigation
Scenario
This lab assumes we're already familiar with the first two parts of the scenario ( Lab 1.2: Network Investigation and Lab 1.3: Memory Investigation) before continuing here.
We know from the previous two labs that a malware named analytics.exe was installed using analyticsinstaller.exe.
Calculate Basic Properties
First let's open a PowerShell prompt with administrative privileges and calculate the MD5 and SHA256 hash sums of AnalyticsInstaller.exe file.
Examine Malware Strings
Let's use Sysinternals' strings utility to find ASCII and Unicode strings of 10+ characters.
There are some strings worthy of note:
First the URL
http://www1-google-analytics.com:8088/analytics.exe. In the Network Investigation lab we discovered that the attackers used ports 8090 and 80. Port 8088 is an additional port that we can investigate.The registry key
Software\Microsoft\Windows\CurrentVersion\Runis an AutoStart Extensibility Point (ASEP) and is a common method used by malware to persist following a reboot.The
cmd.exe /c rd c:\ /s /qcommand is used to recursively delete files and folders starting at the root of the file system. Since the ransom note mentioned the loss of files, this could be a possible mechanism.The powershell.exe command line has a Base64 encoded command, which is suspicious, especially since this is malware.
The
cmd.exe /c start /max http://www.midnitemeerkats.com/notewill display a copy of the ransom note, similar to what the CEO saw.
Malware authors can easily embed fake strings and hide real ones, so treat string outputs as suggestions.
Examine Registry and File System Changes
Let's examine the changes made by the malware installer using Regshot. Regshot takes snapshots of the registry and file system at two different times and shows the differences between them.
Regshot shows a configuration screen. It automatically scans the registry and optionally the file system for changes. Check the box labeled "Scan dir1[;dir2;dir3...;dir nn]" and enter "C:" in the field below, and take the first snapshot.
After the first snapshot has finished, let's run the malware file AnalyticsInstaller.exe .
After the malware installer finishes, we'll take the second snapshot.
Once the second snapshot has completed, let's click the Compare button to compare the two snapshots.
After Regshot compares the snapshots, it will open a text file summarizing the changes.
The following entries are noteworthy:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks{13C9BAD0-D2BE-47C5-98D6-855F5A2DE223}\URI: "\Analytics Backup"
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks{13C9BAD0-D2BE-47C5-98D6-855F5A2DE223}\Description: "Analytics Backup Service"
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run\Analytics Client: "C:\Windows\System32\analytics.exe"
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run\File Saver: "cmd.exe /c start /max http://www.midnitemeerkats.com/note"
The first two entries relate to scheduling a task. The third entry runs C:\Windows\System32\analytics.exe at user logon, while the fourth opens a browser window with the ransom note at user logon.
In the Files Added section, the following entries are notable:
C:\Windows\Prefetch\ANALYTICSINSTALLER.EXE-E57CE4F0.pf
C:\Windows\System32\Tasks\Analytics Backup
C:\Windows\SysWOW64\AnalyticsBackup.bat
The first entry is from Windows Prefetch, showing the last run time and directory of a program, useful for timeline correlation. The second entry indicates a new scheduled task, and the third shows a batch file addition, which we can view with the Get-Content cmdlet.
This matches an earlier output from the strings command and likely indicates the recursive file deletion method used by the Midnite Meerkats.
Examine Process Activity
Let's use Procmon.exe to get detailed insights into the malware installer's actions.
Open Procmon and click the capture button (or press Ctrl+E) to stop capturing.
Next let's a filter for events related to AnalyticsInstaller.exe by clicking Filter -> Filter.
In the Filter dialog, change Architecture to Process Name, enter "AnalyticsInstaller.exe" in the input box, click Add, then click OK.
Now let's discard events that do not match the display.
Next before launching the malware installer, click the Capture icon to enable event capturing.
Now let's run the malware installer.
The error occurs because the scheduled task already exists and can be ignored.
After the malware installer finishes, click the capture icon again to disable event capture.
Examine Process Activity
Use Procmon to examine process activity by clicking the registry, file system, and network filter buttons to disable them. This removes their light blue background, showing only process activity.
Now let's look for process creation. To do this click Edit -> Find.
In the Find dialog, enter "Process Create" and click Find Next.
The first result shows a Process Create event for cmd.exe. Double-click the entry for more details.
The command line seems to launch a PowerShell process.
Even though we did not include cmd.exe in the lter, Procmon still captures process spawn activity in the Process Tree. To see this, close the Event Properties window, then click Tools | Process Tree.
As we can see AnalyticsInstaller.exe launched cmd.exe, which then started powershell.exe.
Remove the Malware Artifacts
Now let's remove the malware artifacts.
Next, remove the malware artifacts in C:\windows\SysWOW64\analytics*
Next remove the ASEP entries for the Analytics Client and File Saver properties.
Bonus Lab
Examine Network Traffic
Now let's start tcpdump to monitor for DNS requests.
The tcpdump command is explained as:
-n -> don't resolve host name or port numbers
-i eth0 -> monitor trac on the interface eth0
udp port 53 -> only capture trac destined for UDP port 53
Let's return to our Windows VM, open PowerShell as an administrator, and use Set-DnsClientServerAddress to set the DNS server to 10.10.75.1.
This command sets the DNS server address for the network interface named "Ethernet" to 10.10.75.1. When a device on this interface needs to resolve a domain name, it will send DNS queries to the server at 10.10.75.1.
10.10.75.1 is the IP address for the slingshot linux machine.
Next, let's launch the malware installer again.
After the malware installer completes, let's return to our Linux VM and stop tcpdump by pressing CTRL+C.
The output shows a DNS request from our Windows VM to the Linux VM, querying the host www1-google-analytics.com.
Let's configure the environment for the malware by updating the Windows VM's hosts file to redirect www1-google-analytics.com to 10.10.75.1, so we can intercept the request.
Since the malware's connection type to www1-google-analytics.com is unknown, we need to restart tcpdump to capture all traffic.
Next let's return to the Windows VM and run the malware installer again.
Once the malware installer completes, let's return to our Linux VM and stop tcpdump by pressing CTRL+C.
A connection attempt to TCP port 8088 is made, but since no service is listening, a TCP reset is returned.
Let's set up a Netcat listener on TCP port 8088 with the nc command, as the malware installer is trying to connect to this port.
The nc command can be summarized as:
-n -> don't resolve host names
-v -> displays verbose output
-l -> listen mode
-p 8088 -> listen on port 8088
Next let's switch back to the Windows VM and run the malware installer again.
Next let's return to the Linux VM and review the Netcat output.
This is an HTTP GET request for /analytics.exe. Let's stop the Netcat listener with CTRL+C and set up an HTTP server for the malware.
We have a copy of analytics.exe file in the current directory, so let's start the HTTP server.
Next let's switch back to the Windows VM and run the malware installer again.
Now let's go back to our Linux VM.
This indicates that the malware installer is trying to download analytics.exe. To confirm, let's check for analytics.exe in the C:\Windows\SysWOW64 directory on the Windows VM.
When looking at evidence, consider how well it supports one theory and rules out others. Here, we see a normal HTTP GET request that seems to support the idea that malware downloaded the file. But this alone doesn't rule out other possibilities, like the malware using a request to mislead analysts. To be sure, you need more evidence, like network traffic and code analysis, before dismissing other theories.
Lastly, let's delete the DNS server settings for the Ethernet adapter.
Next, let's clean the malware from the system.
Last updated
