Monitoring for certain types of events could detect an active intrusion before serious damage occurs.
In many payment card data breaches, a point-of-sale (POS) system is infected with malware that searches for specific processes in memory known to store card data in plain text. Systems can become infected with this type of malware in various ways, from standard phishing emails containing malicious links or attachments, to manual placement using compromised credentials. In many enterprise POS breaches, threat actors gain access to the environment using legitimate credentials, elevate privileges using credential harvesting tools, conduct reconnaissance, and then distribute and execute their preferred POS malware.
Companies rely heavily on intrusion detection (IDS) and intrusion protection (IPS) systems, firewalls, and antivirus (AV) solutions to detect malicious activity; however, threat actors often use custom binaries that are not detected by these security applications. In addition, some events generated from threat actor interaction with the systems are captured in logs passed to a security information and event management (SIEM) platform that is cluttered with numerous events. These logs are often overlooked by administrators and security analysts due to the large volume of daily events.
Based on forensic analysis and threat intelligence gathered during dozens of POS investigations, SecureWorks® incident response (IR) analysts identified commonalities in host-based logs that revealed indicators of compromise that sometimes occurred months before SecureWorks was engaged. Many of these indicators were overlooked or not reviewed. There were three main indicators of threat actor activity within a compromised environment:- Services were created.
- Windows event logs were cleared.
- AV software detected anomalies.
Service creation
In most enterprise POS breaches, the threat actor distributed and executed malware via remote access or lateral movement tools such as PsExec and RemCom, or customized versions of these tools. AV does not typically detect these tools because they are legitimate programs often used by IT staff to perform administrative functions. Figure 1 shows a Windows System Event log entry identifying the creation of a "One-time execution service." This Windows service was created when a modified RemCom variant was executed against the endpoint.
Figure 1. One-time execution service. (Source: SecureWorks)
In addition to remote execution tools, threat actors use malware variants that are installed as a service (see the RawPOS example in Figure 2). Installation of a service requires at least Administrator privileges, indicating the compromise of a privileged account. On Windows Vista and later operating systems, the System Event logs record service installations with event ID 7045. This event should be logged and forwarded to the SIEM platform for review as services are not created often. Organizations should be vigilant about investigating when several systems alert that a new service was created or installed, especially on systems with strict quality controls.
Figure 2. RawPOS service. (Source: SecureWorks)
Log deletion
Event log clearing requires administrator credentials and is an abnormal occurrence. Threat actors clear event logs to hide their activity, which makes analysis and tracking more difficult for investigators and security analysts. Administrators should forward logs to a centralized logging environment to create an isolated archive away from a potentially compromised host. Events indicating that the Windows Event log was cleared should be reviewed as they occur. An Advanced Endpoint Threat Detection (AETD) service alerts on this activity and helps determine the account that cleared the logs, the method that was used, and the initial entry point that provided access to the system where the logs were cleared. Figure 3 shows an example event created after the Security Event log was cleared on a Windows 7 operating system. In the log, this event would appear as "Event ID 104 - the System log file was cleared."
Figure 3. Event indicating cleared log. (Source: SecureWorks)
Antivirus alerts
In many incidents, antivirus software detects malware or files used by the threat actors weeks or months before the compromise is identified via other means. Antivirus software includes commercial solutions such as McAfee or Symantec, and native tools like Windows Defender. Individuals with extensive cybersecurity experience should review these alerts regardless of whether they were quarantined, deleted, or failed clean, because automated removal does not necessarily eliminate the threat. Network defenders need to determine how the malware appeared on the system, what accounts were involved, and what type of file (e.g., tool, downloader, backdoor) was detected.
Figure 4 shows a truncated antivirus log file extracted from the McAfee ePolicy Orchestrator (ePO) system revealing the detection of the wceaux.dll file on six hosts. The wceaux.dll file is known to be associated with Windows Credential Editor (WCE), a credential harvesting tool. Although antivirus indicates the file was deleted, its identification on six hosts is cause for concern and further inspection.
Figure 4. McAfee wceaux.dll detection. (Source: SecureWorks)
In a December 2016 engagement, SecureWorks analysts identified evidence that WCE was executed on multiple systems. Review of the Windows Defender logs revealed detections for \Windows\wce64.exe, classified by Microsoft as "HackTool:Mimikatz" (see Figure 5), weeks before malicious activity was identified. The client's commercial antivirus solution did not generate any detections or alerts.
Figure 5. WCE detection by Windows Defender. (Source: SecureWorks)
Figure 6 shows a Symantec Antivirus detection recorded in the Application Event log for C:\Windows\System32\tabint.exe months before the compromise was detected. The tabint.exe file is an older component of the RawPOS family; it dumps the card holder data found in specific memory processes. The detection of the malware as "!WS.Malware.2" does not provide much context, so additional scrutiny should have been applied to determine how it originated on the system, what account placed it there, if there were other files that were not detected, and how it got into the \Windows\System32\ directory.
Figure 6. Symantec detection. (Source: SecureWorks)
- hdmsvc.exe — This service, identified as "Windows Hardware Management Service," provided the persistence mechanism for RawPOS to continue operating after system reboot by calling psrmon.exe.
- psrmon.exe — This Perl2Exe-compiled executable file parses dumped processes for card data using regular expressions and then XOR-encodes the scraped data into a file named dxfs32.dll. It also runs the process dumper component, oobentfy.exe.
- oobentfy.exe — This process dumper is hard-coded to dump process data from specific process names associated with POS applications. The process dump is saved to a file in a directory named memdump, where psrmon.exe is configured to scrape and encode the card data.
Figure 7 lists a truncated RawPOS infection process tree from the engagement, minus the hdmsvc.exe process. SecureWorks analysts used the pattern of processes/command line arguments for RawPOS to identify other infected systems. Red Cloak also helped to confirm that eradication was successful and that the threat actor did not re-enter the environment.
Figure 7. Red Cloak RawPOS detection. (Source: SecureWorks)
Conclusion
Payment card data breaches can cause significant financial and reputational damage for an organization, and can lead to restrictions from compliance bodies and loss of future business. Organizations can greatly improve their resilience to POS breaches with a few simple steps:- Monitor event logs for service creation events and event log clearing.
- Monitor and review antivirus detections from both commercial and native platforms.
- Consider AETD tools to monitor and alert on anomalous activity on sensitive systems such as POS terminals and application servers.