How to Investigate Infostealer Malware
If you’re not familiar with infostealer malware—a type of malware specifically designed to locate and exfiltrate credentials—consider yourself lucky.
And consider being prepared.
In this article, Forensic Consultant, Chris Cone will utilize a fictional scenario to demonstrate how you can be ready to investigate infostealer malware quickly and effectively.
There’s No “One Size Fits All” Approach to Digital Investigations
When it comes to the methodology you employ in an incident response investigation, options are a great thing to have— whether it’s the tools you use, the resources you confirm your findings with, or any other aspect related to this type of work. In the digital forensics and incident response (DFIR) world, you often hear the phrase toolbox approach, and this is something we all embrace.
Setting the Stage
This fictional scenario will illustrate a methodology for using a combination of tools to successfully triage and assess a Windows endpoint reportedly exhibiting unusual behavior. With that, the current scenario unfolds like this:
It is Friday afternoon, just after lunch. You have had a long and busy week and are looking forward to some time off over the upcoming weekend. Your phone rings and the boss tells you a user has called in claiming their computer is acting “strange”. So much for a quiet Friday afternoon…
Now What?
Determining where to start can sometimes be a challenge. Maybe your organization has developed a robust security posture which includes a detailed IR playbook and written guidelines, so you know exactly how to approach this Friday afternoon caper. Maybe a playbook has been on your to-do list, and you are not quite there yet; or maybe you’re somewhere in between.
Nothing here is meant to come across as the way to approach an incident, nothing is set in stone. Again, the great thing about conducting digital investigations is that we have options. Sure, the details of a specific situation can impact those options and shape our actions, but this goes back to the earlier idea of having certain artifacts and secondary artifacts we can use to develop our hypothesis about what occurred on a running computer.
Modern operating systems, like Microsoft Windows, provide examiners with a wealth of artifacts to help them piece together user interaction with a system. We may be interested in the files and folders a user interacted with, or which applications that user launched. In an incident response investigation, particularly one in which malware may be suspected, we’re uniquely interested in artifacts related to things like running processes, active network connections, and autorun items.
For those situations, some of the best data we can hope to get our hands on exists in the physical memory of the running computer. Not just the typical contents of a RAM dump, but volatile data that can be acquired through native operating system commands or using Axiom Cyber for remote volatile data collection while the potentially compromised system is still powered on.
While it may be possible to acquire some of that data through traditional dead box analysis—after a disk image has been created and then processed—that is typically a much more time-consuming process. A recently updated guide from the Cybersecurity and Infrastructure Security Agency (CISA) and other partners includes guidance for network defenders in protecting against new and evolving tactics employed by malicious actors. While this guide focuses on ransomware—and there are plenty of news stories about ransomware these days—the suggestions included can be applied to a more holistic approach to network security and responding to potential security incidents.
Modern computers—with an active network connection, untold number of running applications and processes, and multi-gigabyte physical memory, and cloud resources—hold a tremendous amount of volatile data. This volatile data can provide actionable intelligence that may be lost once the machine is powered off. To acquire this volatile data, we need a tested solution that will perform these actions for us.
Magnet Forensics offers a variety of volatile data collection options, ranging from standalone free tools for items like memory or process captures, to free tools that can be used to obtain a variety of volatile data artifacts from a running computer to cloud-based DFIR solutions which provide tremendous benefits at scale and for geographically dispersed environments.
Collection
So back to our current scenario, we have an employee complaining about their computer, and they happen to be in the same building as we are. We make our way to the user, a nice enough guy named Walter. Walter works in the shipping department for our organization, and he gives us a rundown of his daily activity—it is always great to speak to the user and find out what they know.
When the compromised endpoint is located in another geographic location, Magnet Nexus provides a mechanism for performing rapid, remote scans and analysis of endpoints to determine the scope of a security incident.
Walter says he came into work early, around 6:00AM, logged on and used his computer as he normally would. But like most users, Walter does not really remember what he did on his computer before things went downhill. Walter goes on to say that when he returned from lunch, he noticed the computer seemed to be running slowly and his Internet speed seems to have really dropped, with some pages that he usually visits not loading at all.
First things first, Walter’s computer is powered on and is running Microsoft Windows. His user account is logged in and the machine is still connected to our corporate network. Because we have planned for an incident such as this, we isolate Walter’s computer from the network and connect an external USB drive with Magnet Response for volatile data collection. We might even feel a touch of excitement, maybe this will turn out to be something completely new.
If you have not used it before, Magnet Response is a free and easy-to-use solution to quickly collect and preserve data from local endpoints before it is potentially modified or lost. Magnet Response can be used to capture RAM along with other volatile data from a running Windows computer.
In addition to the collection options shown here, someone performing a collection can configure additional options which may be useful with certain investigation types. These options can be used to further pare down what you are collecting to speed things along or when you may only be interested in a subset of the items supported for collection.
In addition to the normal GUI interface and the available collection and configuration options shown here, Magnet Response also offers automatic capture modes that can be utilized when having non-technical users assist with the collection.
In this example, Magnet Response was utilized with all collection options enabled which means we have a memory dump along with a .zip archive containing everything from recent files to running processes. The output from Magnet Response is ideally suited for processing with Magnet Axiom Cyber and that will make our job of working through that data to identify any potentially malicious activity easier than just looking at the raw output and likely faster, which may be significant in many situations.
When creating a new case in Axiom Cyber, use the File Browser option from the Windows computer platform to load the Magnet Response .zip file.
To add the memory dump, use the appropriate option under the Windows computer platform here, as well. One thing to note: Magnet Response defaults to using Magnet DumpIt for memory captures. If that fails for any reason, Magnet Response will revert to using Magnet RAM Capture. This works well for a variety of Windows versions, with DumpIt and the Comae memory artifacts in Axiom Cyber suited to newer releases of Windows 10 and Windows 11 and the Volatility framework and associated memory artifacts for older releases of Windows 10 and anything prior.
An added benefit to using Magnet DumpIt, either in conjunction with Magnet Response or standalone, for memory capture is the ability to then leverage YARA Rules on that memory item when processed using Axiom Cyber. This can be beneficial when additional information is available that may have provided an indication as to the specific type of malware you may be dealing with or when investigating other potentially compromised endpoints involved in an incident after identifying the specific malware at play.
Analysis
Now that we have collected the memory and other useful data from Walter’s computer, and we have processed that collection in Axiom Cyber, we can start looking for answers.
But where do we start?
Remember the idea of options earlier? We should revisit that.
There are likely people who have strong feelings about the absolute first artifact we should go look at in this scenario, and if we took a poll, there would likely be several suggestions. The great news is, they are probably all right. Running process? Yes. Network connections? Absolutely. Event Log entries, Autorun items? Of course. Prefetch, UserAssist, and JumpList items? Check, check, and check.
We have a memory capture and the other data collected using Magnet Response. Just as a point of reference, that was conducted on a system with four gigabytes of RAM and the entire collection took about 12 minutes. Processing that collection and the memory dump in Axiom Cyber took just a touch over four minutes. This means in around 16 minutes from the time we connected that USB drive to Walter’s computer, performed the Magnet Response collection, and then brought that back to our computer, we have a processed case consisting of a full memory capture and volatile data artifacts that we can begin working through in our effort to find answers. So back to that place to start, look at the artifact results below and take your pick—there are plenty of good options here.
Memory
In this scenario, one of the first artifact categories we may want to review is Memory. This could include artifacts for items such as running Processes on the computer and Dynamically Loaded Libraries (DLLs) associated with a specific process. We may also be interested in the Scheduled Tasks – Memory artifact with the idea that some malware may utilize this feature as a persistence mechanism on Microsoft Windows systems.
Processes
Again, there are no wrong answers here, but if we start with the Processes artifact then we have an opportunity to see what exactly is running on this computer.
We are all familiar with various types of malware and we recognize that some varieties may only exist in memory. By design these variants are never written to disk and this type of attack has been on the rise in recent years. For malware to perform whatever ill-intent it has been crafted for, it must run; and therefore, we may see items of interest in the list of running processes found in memory on this computer. When reviewing the artifacts listed in Processes, we see powershell.exe with a Process ID (PID) of 7684 and a Parent Process ID (PPID) of 4884.
Just a quick note about tagging items. The volume of artifacts for examiners to review in most cases is significant. Using tags can be a great way to draw attention to the items of interest that discovered. Take notes, add tags, add comments to those tags. Leave yourself (and other examiners) breadcrumbs that will help you find your way when working back through a case, or continuing an examination when you had to step away for whatever else popped up and demanded your undivided attention. The sheer volume of artifacts in a typical case means that we could probably continue working through the data well beyond what is practical, and it is simply not feasible to depend on our memory for everything we review.
That stands out as something to investigate further. There may be nothing to it, but it may be a good idea to add a tag to this artifact and make note of both the PID and PPID—both of which make excellent search terms across the remaining memory artifacts—to potentially get a more complete picture of just how PowerShell may have been used on this computer.
Through further investigation, if we determine this instance of PowerShell is legitimate, we can then add a comment to that effect on the tag that was created and move on to the next item of interest.
Process Security Identifiers
A global search for the term “powershell” reveals matching results in several artifact categories which are present in this case. Continuing our review of the memory artifacts, we can see the instance of PowerShell (PID 7684) was associated with the security identifier (SID) which matches our Walter user account on this computer, as shown below. Later in our investigation, Walter’s security identifier and associated relative identifier (RID) of 1001 may be useful search terms so it might be a good idea to make a note of it, while we have it available.
Dynamically Loaded Libraries
The next artifact we can review in the memory category is Dynamically Loaded Libraries, and in this case, there are a total of 7,768 artifacts listed here.
Because the keyword search for powershell is still applied to the case, this reduces the artifact count to 97 from the original 7,768. This is something that comes up regularly but is a reality of modern digital investigations.
There can be an overwhelming amount of data for us to review and in many of the cases we work, examiners find themselves under pressure to locate actionable data—and quickly. Using a targeted approach to our review of the data, and the features in Axiom Cyber to search, sort, and filter our results, can be hugely beneficial when trying to identify items of interest in a case.
Of those matching results, all are associated with PID 7684, the artifact details are included below.
There is a lot going on with the File Path artifact fragment for powershell.exe and a couple of items likely stand out immediately. First, the call to PowerShell itself includes parameters which stand out – both for the choice of parameter and the text case used (shown below after copying from Axiom Cyber to Notepad++ for clarity). The use of toggle case for some common words has been employed by some threat actors as a method to avoid detection techniques, and that may be the reason we see it here.
We can see PowerShell.exe was used along with parameters for windowstyle, execution policy, and command. First, the parameter windowstyle was used to silently run the associated PowerShell command via the hidden attribute; which would minimize the window. Next up is “-ep BypASS” which was likely set to allow a script to run in the current session, and then the command part follows, which we can see below.
There are some obfuscation techniques at play (1, 4). Even without digging further into that, this is a characteristic which firmly belongs in the “bad” category.
If you are fuzzy on the whole good versus bad thing, just some added detail. Sometimes we get lucky and whatever malicious item we have encountered is one that we can quickly upload to something like VirusTotal and have an identification report almost instantly. Other times, we have more work to do because there are factors at play which mean the specific instance of malware we are dealing with is unique to the current system, so a hash comparison will not always work. When using this methodology, try to keep things simple—we already have plenty to keep focused on. Keep a running total under two columns—good and bad. For the current example, this is probably bad. PowerShell commands should be human readable to make them easy to follow. The arguments passed in this command are not human readable and that defies logic. If this command did not function as intended, how much more difficult would troubleshooting be to make a correction? We can also see what looks like a file path at (2):
C:\Users\Walter\AppData\Roaming\MiCrOsoFt\MuQlFopCZK
We should make a note of that path, or better yet, add a comment to this tag to follow up on that location once we have a disk image of Walter’s computer for review—we may find that path serves as a staging area for data exfiltration.
The other item of interest is at (3) where we can see the string MArS.Deimos. A quick web search for that tells us that Deimos is, in fact, the smaller and outermost moon of Mars. So, can we conclude that we are on the wrong track, and this apparently has nothing to do with malware? Of course not! Refining that web search will yield results that range from AT&T’s AlienVault to articles on ZDNet describing a prolific malware family known by many names in various forms, including Jupyter, Polazert, SolarMarker, and Yellow Cockatoo, exhibiting improved functionality and new techniques with each iteration.
If you are interested, there are many excellent writeups available that go into much greater detail with reversing the various stages of infection you can find related to Mars:Deimos and friends.
A bit more work and we just may be able to confirm this is what we are dealing with on Walter’s computer. If you are interested in reading more about Infostealer Malware in general, take a look at this post What is Infostealer Malware? authored by Ivan King (Security Research Engineer) with contributions by Matt Suiche (Director, Memory, IR & R&D).
At this point, depending on our investigative goals, there may be enough here to send us off checking other resources and come back armed with a plan of action to remediate this threat from Walter’s computer.
But there are plenty of other artifacts we can look at.
We may not always have such a clear path from the memory artifacts, or we may need corroborating information from other artifact categories in our Axiom Cyber case, particularly if the malware that we happen to be dealing with is not something that was so easily identified, or maybe we have encountered a new variant that behaves a bit differently.
Remember, part of the approach here is a methodology that you can utilize in similar situations and perhaps we approach this investigation from a different starting point.
Another reason to look at additional artifacts is when combatting lateral movement. The spread of infection throughout an organization is a real threat and we may not always have such a complete volatile data capture from a potentially compromised endpoint—maybe the computer was powered off.
But we can also take a few minutes to review other artifacts which may also be found in this volatile data capture that can serve as both a point of comparison and a guide for places to look when you make your way over to looking at a disk image and performing traditional dead box forensic methods. These are all options which we can leverage in an investigation, either to identify other compromised endpoints, to develop YARA rules for more broad scanning across an organization, or any other use that you may have—like trying to determine how Walter’s computer was infected in the first place.
Operating System
The operating system category in Axiom Cyber may hold a laundry list of candidates for places to start during an incident response investigation, or any other type for that matter. From our review of memory artifacts, we have uncovered items which may guide our efforts. Just as a reminder, the data we are currently using was captured using Magnet Response, we have not acquired a disk image or processed that data source.
Prefetch Files
When reviewing the operating system artifacts, one thing we are often looking for is evidence of program execution. We have already determined that PowerShell was likely used to facilitate the activity on Walter’s computer, so we review Prefetch artifacts related to that program’s launch.
Using the last run timestamp for PowerShell.exe, which falls in line with the time frame for this incident, we could utilize the relative time feature in Axiom Cyber to filter matching results to a window thirty minutes before and after that event. This is just one attempt at filtering out the noise present on a modern Windows computer, but once applying the filter and then reviewing the results, we can arrive at some interesting user activity showing browser usage and search engine queries which may be relevant to this investigation.
Lessons Learned
Research on this infostealer would lead to the conclusion that the malware, in its various forms, is often delivered through search engine optimization (SEO) manipulation techniques leading users to pages containing file downloads, often document file templates.
Armed with this information, we might return to Walter and upon further questioning learn that Walter was looking for ways to convert scanned PDF invoices and use them in Microsoft Excel and he admits to conducting web searches and performing downloads of several document templates.
So now we have an idea how Walter’s computer was infected. Further review of the web history artifacts, captured via Magnet Response, would provide actionable data in the form of URLs that we would likely want to block in our organization to prevent further infection. Additional research could lead to updated signatures or development of YARA rules which could be used for further scanning efforts to detect other compromised systems.
Again, we have options.
If we determined there were other compromised endpoints in our environment, we might choose to leverage the rapid scalability of Magnet Nexus, and this could provide an excellent way to perform scans of multiple endpoints across your organization – regardless of physical location. From using Magnet Response for local volatile data collection to Magnet Nexus for cloud-based rapid triage and initial scanning, Magnet Forensics offers solutions you can leverage to help determine the scope of an incident and your next steps.
Recommend Resources
- Want to learn more about how Axiom Cyber can help you unravel complex incidents? Check out our blog post Enhancing Your Incident Response Playbook With Magnet Axiom Cyber.
- To learn more about the IR capabilities of Axiom Cyber visit our Incident Response hub to explore blogs, how-to videos, and webinars on key features that help simplify your incident response investigation.
- Are you ready to try Axiom Cyber? Request your free trial here.