Part one of this blog series discussed what Dynamic Data Exchange (DDE) is, what an attack may look like, and steps for mitigation. In Part 2, I’ll cover how LogRhythm and Carbon Black can work together to help detect a DDE-enabled attack.
Suppose you’re a security operations center (SOC) analyst. Upon arriving for work one morning, you hear about a DDE attack through your daily RSS feed review. The attack news has just broken, and there is a high potential for end user impact. As a proactive SOC analyst, you do a little research and get your hands on some threat intelligence for this type of attack vector.
You can use this threat intelligence to effectively mitigate the attack and protect your network. The LogRhythm and Carbon Black integration can help streamline your process to ensure you’re able to successfully apply threat intelligence and consistently stay ahead of the DDE-enabled attack.
Establishing Initial Protection and Visibility via Carbon Black
As a Carbon Black user, you log in to the Carbon Black Community and quickly discover a forum topic discussing DDE attacks. A forum post includes a particular query (shown below), which can be utilized within the Carbon Black dashboard by adding it to a new watchlist.
Additionally, another query (shown below) can be run directly in the Carbon Black interface to help alert to the execution of child processes. When a Microsoft (MS) Office program executes a child process, such as cmd.exe, wscript.exe, powershell.exe, or mshta.exe, the watchlist will then flag this event within Carbon Black and, ultimately, the LogRhythm NextGen SIEM Platform.
After running both queries in Carbon Black, you have established a basic level of initial protection and visibility into any endpoints that could execute a DDE-enabled MS Office document.
Zeroing in on a DDE Attack with LogRhythm
Later that same morning, you check your Carbon Black dashboard within the LogRhythm Web Console. In the Top Watchlist Hit widget, you see the watchlist you created in Carbon Black earlier, “AC DDE Test,” has some hits.
Please note: “Watchlist” is just one of many rich metadata fields that is parsed from Carbon Black logs.
Drilling down a bit further, you can quickly ascertain the suspected infected host, as well as some metadata about the event. In this case, you find that the calling application and path to that application is “WinWord.exe.” This would instantly be suspicious, as this path likely indicates that Microsoft Word may contain some potentially malicious DDE code.
If you notice any further DDE attacks on your environment, you can drill down and inspect the raw logs, add evidence to a case, and further triage the logs within the Carbon Black dashboard to obtain additional forensic insights.
Manually Creating DDE Watchlists in Carbon Black
Next, you need to more deeply examine your watchlist and the alerts it contains. In the image below, the HUD displays the watchlist, the host machine name, and the application name. The DDE watchlist you manually created is shown. From here, you can see additional threat intel feed alerts that triggered via Bit9 Advanced Threat feeds.
As an analyst, you might ask what is different between the watchlist created manually and the Bit9 provided feed watchlist. By clicking “Word Spawning Command Process,” you can find additional information pertaining to the feed provided by the watchlist, including details of the query. This may be useful if you’re receiving threat feeds due to time limitations that make manual investigations and research difficult. However, for the SOCs that are fortunate enough to have more resources, this function enables an analyst to perform a side-by-side comparison, and then further modify and tune their own watchlists to suit their environment’s specific requirements.
This example illustrates how threat feeds can be useful aids to an analyst. For example, OneNote—which was not widely reported on as being susceptible to DDE—could be added to a watchlist that contains Microsoft Word, Excel, and Outlook.
Diving further into the alert generated by the custom watchlist shows you a rich set of data produced by the attack. The visual representation in Figure 6 shows that Microsoft Word spawned a command prompt, which subsequently executed the tasklist.exe process, along with other forensic objects. These processes could later be used within LogRhythm lists for further detection, such as file hashes.
This data links back to the original query found via the Carbon Black Community forum, as well as the Bit9 thread feeds. In other words, the parent process, Winword.exe, spawned a child process, cmd.exe, which subsequently triggered the command, tasklist.exe.
A manual search, using the search queries provided above, can also be performed in the process menu, as shown below.
Creating a DDE Alarm LogRhythm
At this point, there is enough data to either add to a case for further triage, or create an alarm rule with the Carbon Black SmartResponse Plug-in. This alarm rule could be configured to either isolate the infected host, download or delete the suspect file from the infected computer, kill a process, list all processes, or even perform a memory dump!
Currently the Carbon Black SmartResponse Plug-in allows for a subset of commands that are available in the full Carbon Black product—however more of these commands will be supported within the LogRhythm SmartResponse in the near future.
In this instance use the “isolate” command for the SmartResponse plug-in. This will isolate the remote host network availability, while still allowing connections from the host to move back to the Carbon Black Server. In the future, a DDE alarm will display in the “Alarms” tab, alerting your team to enable a quick response.
Other analysts on your team not familiar with the newly created rule can quickly open the alarm card and look at the higher-level metadata fields, or drill down further to view the raw logs—assuming these logs are being selectively indexed or not—to gain clarity.
If you’re seeing this alarm for the first time, you can also use the inspector pane to view the AI Engine rule details, as shown in Figure 11, to see how exactly the alarm fired and various other parameters specific to the rule.
Assuming the AI Engine rule has an associated SmartResponse, you can additionally view the command that is configured to run and decide whether to approve or deny this action. In the example below, you can see the “Isolate Host” command configured. Perhaps this event requires escalation to a Tier 2 or higher, such as the SOC manager, or perhaps it requires further engagement with IT or IS. Once an action is agreed upon, with just a click the SmartResponse is approved and LogRhythm does the rest.
The LogRhythm and Carbon Black Integration
The LogRhythm and Carbon Black integration can help your team detect and respond to DDE attacks. You can easily establish comprehensive visibility into your environment, then set alarms to automatically monitor your critical assets and alert your team to the presence of a DDE attack, enabling effective mitigation.
Two security solutions working together, such as LogRhythm and Carbon Black, can offer increased threat visibility, an efficient workflow, and fast remediation when you need it most.
If you’re currently a customer, visit the LogRhythm Community to discuss this post, get your questions answered, and more. Keep the conversation going here: https://community.logrhythm.com/t5/Blog/bd-p/Blog