Changes in Observed/Assumed Tactics, Techniques, and Procedures (TTPs)

Dell SecureWorks Counter Threat Unit™ (CTU) researchers interact directly with clients during targeted threat incident response engagements. These engagements provide access to a wide range of data for both analysis and research. CTU researchers can deploy host-based endpoint analysis agents and network monitoring systems, and can collect infrastructure logs for analysis. This access, coupled with alerts from Dell SecureWorks iSensors, allows CTU researchers to achieve a much deeper, targeted level of analysis. As a result, CTU researchers have observed a wide range of tactics, techniques, and procedures (TTPs) used by threat actors to deploy a popular remote access trojan (RAT). Some of these tactics, including the following examples, run counter to assumptions about common techniques.

Example 1: Thumb drive
Our Dell SecureWorks managed security service (MSS) recently detected several iSensor alerts indicating that systems were infected with the Poison Ivy RAT and were configured to use the “smallfish” password when connecting to its command and control (C2) server. This RAT is typically deployed to systems via a spearphishing email that contains a link or file attachment that exploits a vulnerability and ultimately leads to the download and installation of Poison Ivy.

In this case, forensic analysis of the infected system initially turned up very few artifacts or findings regarding the Poison Ivy RAT. In fact, there were almost no indicators of the malware, with the exception of several Windows Event Log records indicating that an oddly-named service had started at various times throughout the lifetime of the system. But those records stopped well before an image of the system was acquired.

Analysis of a detailed timeline of system activity provided significant context around the observed Windows Event Log records. CTU researchers traced the timeline back to the earliest visible event record and determined that the initial infection vector was not a spearphishing email but a USB thumb drive. The timeline clearly indicated that the user had logged out of the domain account, logged back into the system using the local administrator account, connected a USB thumb drive, and then launched what was later determined to be the Poison Ivy installer file.

These findings could indicate that the user was somehow tricked into running the RAT installer file. However, analysis of the hibernation file on the system clearly revealed the presence of the Poison Ivy RAT, including both the RAT configuration information and the Windows service information illustrating the persistence mechanism used by the malware. Although the Windows service artifacts were not found in the Windows Registry hive file within the image, information from the user account registry hive file showed that the last time the user had the Registry Editor open, the key in focus was alphabetically next to the Poison Ivy RAT service key. This result was most likely due to the user deleting the Poison Ivy Windows service Registry key, causing the next key to be in focus when the Registry Editor was closed. Further analysis of the timeline and the acquired image indicated that the user took steps to “clean” the system and remove indications of the RAT prior to returning it to their employer.

The timeline of system activity also provided clear references to previously-observed reconnaissance techniques: running a batch file to collect information about the domain infrastructure, and collecting password hashes. The location of these artifacts in the root of the recycle bin indicated a level of access greater than that provided by the local administrator account. The access was most likely achieved via the Poison Ivy RAT running as a Windows service.

CTU researchers determined that a previously unobserved method was used to infect the system with the Poison Ivy RAT, using the system’s specific configuration. Based on prior experience, most analysts might assume that the system had been infected via a spearphishing attack. However, evidence in this case clearly demonstrated the attacker using human (employee) assets to deliver malware to access the domain infrastructure.

Example 2: AutoHotKey script
During an incident response engagement, endpoint scanning alerted CTU researchers to a system that had the Poison Ivy RAT running in memory. No other endpoint rules provided further indications of the infection, nor were any iSensor alerts (e.g., C2 beaconing) available to indicate an issue with this system. CTU researchers examined a forensic image of the system for indications of “traditional” persistence mechanisms (Windows service, registry Run key, NTFS alternate data stream, etc.) usually associated with the Poison Ivy RAT, but found none.

Analysis of the hibernation file within the acquired image confirmed that Poison Ivy had been running in memory at one point. The Poison Ivy configuration information extracted by CTU researchers indicated that the RAT had been injected into the memory of the Explorer.exe process and used a key rather than a password. The original infected file was set to “melt,” or be deleted, once the RAT was injected into process memory. In short, the configuration information illustrated that the Poison Ivy RAT did not use a persistence mechanism.

Further analysis of the acquired image revealed that the system was also infected with Win32/Vercuser.B, which is essentially a compiled AutoHotKey (AHK) script. This malware used a persistence mechanism that caused it to execute when the user logged into the system. CTU researchers extracted the Vercuser executable from memory, and then extracted the complete contents of the AHK script. Analysis of the script revealed that it would detect several virtual environments and antivirus (AV) applications, which explained why CTU researchers could not run the malware in a virtual environment. Further, CTU researchers found that the Poison Ivy executable file had been converted to a string of hexadecimal characters, broken into several sections, and embedded in the script. This technique, in combination with the AHK script’s ability to detect and possibly disable AV applications, allows the Poison Ivy RAT to remain undetected by most security mechanisms on the system. One of the functions within the AHK script was to reassemble and launch the Poison Ivy executable, which used the previously identified configuration information. A series of C2 host and port pairings were also encoded in a hexadecimal string within the AHK script. Anytime the user logged into the system, the Vercuser malware was launched and a pair of C2 hosts and their associated ports were selected at random and included in the Poison Ivy executable during re-assembly.

The technology employed prior to and during incident response engagements provide CTU researchers access to much more data than would be otherwise available. This level of access allows for much deeper analysis to clearly identify TTPs used by threat actors and to observe when those TTPs change.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Online Tools

  • Print this Page
  • Share This Resource

By completing this form you'll be opting in to receiving future communications about products and services from Dell SecureWorks.