Tracking cyber exposure requires detailed investigation to understand how a network has been breached and what data has been exposed to attackers. The following post explains how CYDEF investigates cyber exposure using our proprietary tool, SMART-Monitor.
2020: Ending with a Surge of Breaches
In the final months of 2020, global networks were inundated by a surge of breaches. Our CYDEF clients experienced a similar surge, which we tracked through our keystone product SMART-Monitor. The following post details the actions our team of analysts took in tracking cyber exposure for our clients.
Tracking Cyber Exposure with SMART-Monitor
CYDEF’s SMART-Monitor platform uses machine learning to review client telemetry. Once the automated systems remove all of the known good activity, analysts manually review the remaining activities.
Our team recently picked up the following anomaly while tracking cyber exposure. The command line activity was unclassified at that time.
Figure 1: rundll command line relationship for the living off the land attack
This command line activity was linked to the rundll program. Upon initial inspection, the command line raised suspicion. The file name only included a bunch of dashes and underscores, with a single dot. The entry point was a nonsensical string of letters.
This command line was very unlikely to be linked to a legitimate program.
CYDEF’s Response to a Suspicious Command Line
Every time our analysts identify an unusual command line, we dig deeper into the data. Our response in this instance was no different.
By drilling down in the stack view, we saw the raw logs aggregated by activity and by machines/clients.
We identified a single log, a process creation event from Sysmon, associated with the command line. (Screenshot was cropped to obscure user information)
Figure 2: Excerpt from Sysmon process creation event
By checking the hash for the rundll32.exe, we identified the legitimate rundll executable from Microsoft. The parent process was explorer.exe (the Windows UI).
From this early investigation, we could tell that a user may have clicked on a malicious item or a malicious item ran when the desktop loaded. So far, we didn’t have enough information to understand the source of the suspicious item.
From the Stack view, we drilled down into the ProcessGuid activity. After downloading all the logs linked with that individual process, we learned that the ProcessGuid from rundll32 only showed a process stop event. No actionable information was garnered in that search.
The explorer.exe process did not help much either. It only contained the logs for the session initialization and some generic office activity. The logs didn’t appear to load weird DLLs, and the generic office activity was standard fare like checking emails, surfing the web, and working on documents. We still hadn’t revealed any contextual information to go on.
As a response, our analysts contacted the client. We needed to get consent to take remote control of their systems using the SMART-Monitor response module. At that time, our plan was to grab the file and upload it to VirusTotal.
When Time Zones Present Operational Challenges
The reality of monitoring operations on the other side of the world is availability. Clients in Asia may be going to bed as our analysts in North America are getting to the office.
Despite our best efforts, we couldn’t get ahold of the client. This client is based in Asia, and they’d gone home for the night. An activity performed by one of their employees in the afternoon and was picked up for investigation by our team when they came in the following morning.
By the time the early investigation steps were complete and we needed to contact the client, they were unavailable – likely asleep. Even the emergency contacts were not responding.
Google Search Identifies a Similar rundll Naming Convention
When life gives you lemon, you Google the recipe for lemonade.
Since we couldn’t get ahold of the client, we did a web search. We’d thought, “Perhaps someone else had seen this too”.
Naturally, running a search on the DLL entry point returned nothing. We expected that, given that the entry point appeared to be uniquely generated. Searching for sections of the file name didn’t return anything either.
However, searching for “file name only dash and underscore rundll” led to a promising search result.
Figure 3: Google search result for file name with only dash and underscores rundll
The blog post indicated that both the file naming convention and the DLL entry point are very similar to the one we’ve detected. However, this could be a coincidence. With only limited data and strong suspicion, we could not confirm our case and the web example are the same.
Malware Spread Using a USB
The blog post indicated the malware in question was spread using a USB key. A user would be tricked into clicking on a LNK file that would run the malware.
Maybe, we thought, we could find the USB access.
The initial rundll32 activity indicated the particular machine and time the incident occurred. We used the Event Viewer functionality in SMART-Monitor to download log data from the affected system in a narrow time band around the activity. We then searched for the DLL entry point (a very unique identifier) in order to highlight the activity.
We quickly found the process creation event again and continued our search for logs containing traces of USB activity. (Client data obscured in the screen capture below).
Figure 4: SMART-Monitor event viewer highlighting event containing DLL entry point
The working directory was actually the E: drive and the DLL in question was on the USB key.
In the moment, we didn’t notice the USB key and looked at the other events. A few milliseconds before the event, the drivers were being updated.
Figure 5: Driver updater software triggered
Figure 6: User mode driver executable called
A few milliseconds later, a Word document was loaded from the E: drive.
Figure 7: Word document loaded from the USB drive
We finally noticed the working directory in the rundll32 log related to a USB key. We felt fairly confident that this event was actually the malware described in the blog post (a strain of Gamarue/Andromeda).
We advised the client to quarantine the computer and, more importantly, the USB key.
We also asked the client if we could get a forensic copy of the USB key in order to validate our findings. Since the DLL resided on the USB key it would be impossible to conduct a remote assessment.
However, we were unable to access the USB key. Unfortunately we could not confirm the specific strain of malware – or if it was malware in the first place.
Remote Incident Tracking
Our team works with SMART-Monitor every day, yet we are still amazed by the capacity to identify and track one weird command line related to an infected USB key in the middle of Asia.
We even managed to identify, with moderate confidence, the probable strain of malware.
When you have worked on a project for so long, it feels very satisfying to see all the dominos fall exactly as you expect.
Our investigation wouldn’t have been a success without the research provided by malwarenailed. The collaborative nature of the cyber defense community is a key component of cybersecurity.
