When we hear the term “Credential Access” our detection engineer thoughts typically turn to the Windows LSASS Process and tools like Mimikatz.
Recently, however, researchers have drawn our attention to Microsoft Office processes. These processes also store credential material, in the form of access tokens. If stolen by an attacker, this access token theft can result in unexpected privilege escalation avenues; potentially allowing a threat actor to move from on-premises resources to cloud resources in a fairly linear fashion.
The Sumo Logic Threat Labs team has previously written about cloud credentials stored on the endpoint, and how to protect against the threat of theft of these types of credentials.
The previous work noted that credential material that is left on filesystems on Windows endpoints is at risk of theft and re-use.
Building on this context, this blog shifts these detection engineering efforts and highlights how to protect yourself from similar threat and attack vectors, but with the credential theft occurring in-memory, rather than on disk.
Technique overview
A great overview of this technique and its associated tooling is provided by researcher mr.d0x here.
Overall, this technique relies on dumping the process memory of an Office product (Teams, Word, Excel), or a process that is connected to Office services (Edge, Chrome).
Once the memory of that process is dumped, the tooling searches through it to find a specific pattern, denoting an Office token.
Detections
There are a number of methods available currently to execute this particular technique, including:
Executing the PowerShell script provides us with the following output:
When looking at the telemetry generated by this event, namely Sysmon Event ID 10, we can see the following potentially suspicious attributes:
A suspicious process (PowerShell) accessing the memory space of an Office product
The presence of DLLs which provide credential dumping functionality found in the call trace
A suspicious access mask
The above events look very similar to more traditional credential dumping techniques, however, the target process is no longer LSASS, but rather an Office or Web application.
Moving onto the Python version of this tooling, we see the following output:
The characteristics of this version of the technique are similar to that of PowerShell, however, the source process that is accessing our Office or Browser processes will be Python instead of PowerShell.
A final method for executing this technique is via a Beacon Object File (BOF).
Thankfully, researchers at TrustedSec have released a tool called COFFLoader which allows us to mimic the execution of Beacon Object Files without having a copy of Cobalt Strike or other compatible command and control frameworks.
In order to pass a parameter to COFFLoader, we first need to use the beacon_generate.py script to generate the relevant argument:
The BOF method of execution differs slightly from the other methods outlined:
The CallTrace field does not contain any dbgcore DLLs
The GrantedAccess mask differs slightly from other execution methods
However, we still do see that a suspicious process has accessed the memory space of an Office product or a browser connecting to Office services.
Hunting
We can combine the various characteristics outlined above into one Sumo Logic CIP (Continuous Intelligence Platform) query:
_index=sec_record_endpoint metadata_deviceEventId="Microsoft-Windows-Sysmon/Operational-10"
| where toLowerCase(%"fields.EventData.TargetImage") matches /(microsoft office|teams|msedge|chrome.exe)/
| where toLowerCase(%"fields.EventData.GrantedAccess") in ("0x1fffff","0x1f3fff")
| where toLowerCase(%"fields.EventData.CallTrace") matches /(unknown|dbgcore.dll)/
| values(%"fields.EventData.TargetImage") as TargetImages,values(%"fields.EventData.SourceImage") as SourceImages by device_hostname
And looking at our results we see the following:
We note the target images, that is, the processes that were targeted for in-memory token extraction on the left hand side. These include the Edge process, Chrome, Winword and Teams.
Likewise, on the right hand side, we see the source images, that is, the processes that were the source of in-memory scraping attempts. As we can see, these include the Python, PowerShell and BOF versions of this particular technique.
Final thoughts
As the Threat Labs team has previously outlined credential theft can occur on Windows endpoints in many places other than the LSASS process. Office applications and web browsers that access Office applications online can store sensitive token material which can be stolen and re-used by threat actors.
This blog post has aimed to provide some detection guidance, in order to alert on this activity in your networks. In complex, hybrid environments, it is important that organizations understand where credential material may be present on systems and craft response processes to deal with these threats and risks. This is vital not just in the context of on-premises credentials, which may grant access to other resources, but also credential material which may allow access to cloud resources, including both compute and productivity services.
CSE rules
The threat labs team has developed and deployed the following rules for Cloud SIEM Enterprise customers.
Rule ID |
Rule Name |
MATCH-S00822 |
Potential Microsoft Office In-Memory Token Theft |
MITRE ATT&CK Mapping
In terms of MITRE ATT&CK Mappings, the following MITRE IDs make up the bulk of the techniques which were covered in this blog:
Name |
ID |
T1003 |
|
Credentials from Password Stores: Credentials from Web Browsers |
T1555.003 |
References
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.
