DDE or Dynamic Data Exchange is a Microsoft protocol used to transmit data/messages between applications. This sounds harmless and useful, but can be weaponized and abused by malware authors. Microsoft blacklisted DDE last year for Word, but DDE is still enabled (by default) in Excel.
Here is an example of a DDE payload from a malicious word doc used in a campaign by an advanced threat group. It's a simple exploit, directly spawning an .hta file from the internet. The DDEAUTO tag allows this command to run upon opening the document.
Malware authors have been observed weaponizing not just the plain-jane Excel files such as .csv or .xls, but also more obscure file types that also open by default in Excel. Equally as dangerous, and not nearly as well-known.
One example of this file type is the .slk file. Symbolic link files are for transmitting data between spreadsheets or databases, and are pretty much just text files.
The payload within this .slk file spawns PowerShell to download and invoke an executable. The "CMD|'" is an indication of DDE abuse.
Here is an example of a significantly more robust .slk file. This one is going to save a long base64 string as a .sct or Script Component file (COM objects!), decode the base64 with certutil, delete the original .sct, and finally run the scriptlet within the .sct file.
As you can see from the decoded results, .sct files are in XML. The interesting code within the binary is the encoded scriplet, this one is in VBscript, although Jscript and JS script are also supported.
To quickly decode this binary, we can do a little manual debugging...
Procmon will show us not only the sequence of process execution/relations, but also the full command-line arguments for each "Process Start". This is a quick and dirty way to allow the obfuscated code to self-decode.
The decoded scriptlet spawns cmd.exe, which then passes an encoded command string to PowerShell.
The decoded PowerShell payload is a simple downloader, nothing out of the ordinary or particularly interesting.
Another odd Excel-related file type observed in the wild is that of the .iqy file. This is an Excel Web Query file. Basically, you point this simple text file at a domain, and by default Excel will open and send a request to said domain.
Here is all the that the file consists of. This is one that I created (obviously!).
At my simple Python C2, I stored the command to be dropped into Excel. See the 'http_response' variable.
Now we are able to escape Excel, most likely to download a larger payload. But this is just for testing, so it will end here!
There are a few anomalies associated with this traffic that defenders can use for detection. Notice the Excel-related UserAgent, as well as the 'OPTIONS' HTTP method. Neither one of these are super common.
Now for a real world example. As I said before, these are simple text files.
This blog post is about how malware authors may abuse Excel, but I couldn't resist getting that next payload, which turned out to be a very long compressed PowerShell script.
I am an advocate of manipulating malware into doing what I need it to do, like self-decode. For example, here I stored the results of the decompression function into a variable and then just printed that value to the console (Write-Host). The malware looks to be attempting to become environment-aware through WMI, notice the WQL queries towards the bottom of the screenshot.
Some quick OSINT found several of the hard-coded domains as being malicious. Very interestingly, the malware defines a list of DNS query types....
Next, the malware appears to be leveraging WMI to detect if it is being analyzed. It is checking for virtualization (VMware/VirtualBox), hardware properties (low amt of cores/memory), and running processes (Wireshark/Sysinternals) -- the program will terminate itself if any of these conditions are met.
If the malware makes it past these checks, it then does some recon on the box/user. Notice the 'Get-LocalUser' and 'net group domain admins' cmdlets, the malware is checking for what privileges it has. The 'net group' cmdlet can only be used on Domain Controllers.
Scrolling through the deobfuscated payload, I noticed a ton of values that are read-in, and string comparisons followed by interesting actions or branching. The code segment below leads me to believe that this is a backdoor, listening for commands.
Just connecting the dots, and without spending anymore time on this payload, it's probably safe to say that the malware is taking in commands via responses from DNS queries. Here is an interesting DNS Check function.
(Back to the topic!)...So while playing around and experimenting with the different file formats that Excel will load, I found a couple more file extensions that can be used to leverage DDE: .prn. and .dif files. Both of these file types are for spreadsheets(text files), and can be abused the same way as .slk files (=cmd|'/c <COMMAND>'!A0). Even .txt files can deliver malware so long as the proper DDE command string is provided, and the file is opened in Excel. This would of course require some extra social engineering to get a user to manually 'Open With' Excel instead of notepad. So as defenders, we may want to start paying better attention to the less popular, but equally effective forms of delivery malware.
Watch out for....
- Potentially risky files extensions: .slk, .iqy, .prn, .dif
- UserAgent containing Microsoft Excel, 'OPTIONS' http method, and a network connection to a weird domain
- Anomalous Parent/Child process relationships (office application spawning powershell)
Thanks for reading!
Here is an example of a DDE payload from a malicious word doc used in a campaign by an advanced threat group. It's a simple exploit, directly spawning an .hta file from the internet. The DDEAUTO tag allows this command to run upon opening the document.
Malware authors have been observed weaponizing not just the plain-jane Excel files such as .csv or .xls, but also more obscure file types that also open by default in Excel. Equally as dangerous, and not nearly as well-known.
One example of this file type is the .slk file. Symbolic link files are for transmitting data between spreadsheets or databases, and are pretty much just text files.
The payload within this .slk file spawns PowerShell to download and invoke an executable. The "CMD|'" is an indication of DDE abuse.
Procmon will show us not only the sequence of process execution/relations, but also the full command-line arguments for each "Process Start". This is a quick and dirty way to allow the obfuscated code to self-decode.
Here is all the that the file consists of. This is one that I created (obviously!).
At my simple Python C2, I stored the command to be dropped into Excel. See the 'http_response' variable.
Now we are able to escape Excel, most likely to download a larger payload. But this is just for testing, so it will end here!
Now for a real world example. As I said before, these are simple text files.
This .iqy file calls out to a suspicious domain to grab a little command string that'll read in the contents of a webpage (PowerShell script) and invoke it without dropping it to disk by directly passing those contents to the IEX or Invoke-Expression cmdlet.
This blog post is about how malware authors may abuse Excel, but I couldn't resist getting that next payload, which turned out to be a very long compressed PowerShell script.
I am an advocate of manipulating malware into doing what I need it to do, like self-decode. For example, here I stored the results of the decompression function into a variable and then just printed that value to the console (Write-Host). The malware looks to be attempting to become environment-aware through WMI, notice the WQL queries towards the bottom of the screenshot.
Some quick OSINT found several of the hard-coded domains as being malicious. Very interestingly, the malware defines a list of DNS query types....
Next, the malware appears to be leveraging WMI to detect if it is being analyzed. It is checking for virtualization (VMware/VirtualBox), hardware properties (low amt of cores/memory), and running processes (Wireshark/Sysinternals) -- the program will terminate itself if any of these conditions are met.
If the malware makes it past these checks, it then does some recon on the box/user. Notice the 'Get-LocalUser' and 'net group domain admins' cmdlets, the malware is checking for what privileges it has. The 'net group' cmdlet can only be used on Domain Controllers.
Scrolling through the deobfuscated payload, I noticed a ton of values that are read-in, and string comparisons followed by interesting actions or branching. The code segment below leads me to believe that this is a backdoor, listening for commands.
Just connecting the dots, and without spending anymore time on this payload, it's probably safe to say that the malware is taking in commands via responses from DNS queries. Here is an interesting DNS Check function.
(Back to the topic!)...So while playing around and experimenting with the different file formats that Excel will load, I found a couple more file extensions that can be used to leverage DDE: .prn. and .dif files. Both of these file types are for spreadsheets(text files), and can be abused the same way as .slk files (=cmd|'/c <COMMAND>'!A0). Even .txt files can deliver malware so long as the proper DDE command string is provided, and the file is opened in Excel. This would of course require some extra social engineering to get a user to manually 'Open With' Excel instead of notepad. So as defenders, we may want to start paying better attention to the less popular, but equally effective forms of delivery malware.
Watch out for....
- Potentially risky files extensions: .slk, .iqy, .prn, .dif
- UserAgent containing Microsoft Excel, 'OPTIONS' http method, and a network connection to a weird domain
- Anomalous Parent/Child process relationships (office application spawning powershell)
Thanks for reading!
Comments
Post a Comment