The investigation began when an alert was received within the Countercept console. A user receiving a zip file with an embedded executable had been detected within an HTTP stream arriving via the proxy from a non-whitelisted domain. This had been picked up by the Countercept network sensors monitoring all outbound and inbound internet traffic and had been flagged for manual review.
This could be a legitimate situation – software being shared with a user in a way that would get around the corporate security controls. However, it’s also the exact tactics used by some highly resourced attackers.
A casual inspection of the domain and filename revealed it to be particularly suspicious, quite possibly the result of a spear-phishing attack. The domain was <SUSPICIOUS_DOMAIN> and the zip file name was <INTERESTING_SOUNDING_REPORT>.zip. The embedded EXE had the same name and was also observed to have an associated icon that gave it the appearance of a PDF, despite being an executable – All factors that immediately raise the suspicions of the analyst. A quick check revealed that neither of the file hashes were known to any public databases so whatever it was hadn’t been seen and reported in this form before. A quick scan of all network communications revealed that only the affected user’s system had been seen to have communicated with <SUSPICIOUS_DOMAIN>.
Whilst this initial analysis was being conducted, the latest endpoint-based forensics data was being retrieved by the Deteqt agents installed in the environment. This data was then quickly analyzed with a focus on the specific host that had been observed downloading the suspicious zip file. The first question to answer was whether the user had actually executed the file. An entry with a matching filename was found in the prefetch data for the host with a timestamp that corresponded with when the file was downloaded. The answer to that question was therefore immediately available, the user had indeed run the executable.
Additionally, a comparison of the current autorun data obtained by the Deteqt agent showed that a Run key now existed in the registry that didn’t appear in the previous day’s data. It also showed that it had been created shortly after the suspicious executable was launched. As a result of this initial response and triage, the forensic investigation report was already being constructed, even before an incident had officially been raised with the organization.
The run key referred specified to use rundll32.exe to run a DLL within the user’s roaming profile, which appeared to have a randomly generated name. The Deteqt console data correlation stats showed that this run key was not present on any other system on the network.
All of this data combined suggested something highly suspicious in nature, with a case being built that a compromise had just occurred. Whilst it was not absolutely certain yet, the correlation of the timestamps indicated that it was likely the suspicious executable that had run had created a Run key in order to ensure it ran again next time the user logged on. This is commonly performed by malware to maintain persistent control over an endpoint past reboots. This could still have been a legitimate activity, software being shared between users – what was needed was more evidence.
Further analysis of the forensic data gathered by the Deteqt agent focused on the analysis of running processes and advanced memory analysis techniques. The objective of this was to detect any other signs of compromise that could be compared with the same data from other machines across the estate. The key findings from the investigation that had been collected through the Deteqt agent’s memory analysis were:
- No instance of rundll32.exe was running that had been supplied with an argument of the suspicious DLL in the previously identified run key.
- The user’s running instance of Internet Explorer showed evidence of an injected DLL having been manually mapped into memory via reflective loading. This specific behavior was not seen within Internet Explorer on any other system on the network.
- The same instance of Internet Explorer showed evidence of a running thread that had not been launched from an area corresponding to a known loaded module and that tied in with the same base address the injected DLL entry had been seen.
- Various sensitive functions for web communication and file creation were being hooked within the same Internet Explorer instance. The source of the hooking referred back to the same memory address range observed in the suspicious thread and injected DLL entry. These functions were not hooked within Internet Explorer on any other system on the network.
- This behavior had not been seen on the affected host prior to the suspicious zip file having been downloaded.
Therefore, by reviewing the memory analysis results from all the Deteqt agents across the network, highly suspicious behavior was identified on the one affected system. This was consistent with browser hijacker style malware that aims to spy on communications within a web browser. This technique is used in order to break through encryption and gain access to sensitive data, including usernames and passwords. This behavior not having been seen anywhere else on the network or prior to the delivery of the suspicious zip file gave a strong indication that the anomalous behavior was directly as a result of the suspected attack.
This was enough evidence to trigger further analysis activity, all of which was occurring within minutes of the event being flagged.
Both the EXE embedded within the suspicious zip file and the DLL that was referenced in the run key were then fed into Countercept’s malware analysis platform for automated dynamic analysis. The key outputs from this were:
- The EXE wrote a DLL and a run key that were very similar in format to those found on the affected system.
- The rundll32.exe instance calling the suspicious DLL wrote to the process memory of internet explorer and injecting a thread and then exited.
- Immediately after rundll32.exe exited, internet explorer began attempting to communicate with <INTERESTING_C2_DOMAIN>*
This behavior directly correlates to the memory analysis results observed on the affected host. It also suggests that the Run key referencing the suspicious DLL is used simply to inject itself into internet explorer before exiting. This explains the hidden injected DLL evidence, suspicious thread and lack of rundll32.exe process, which were all observed on the affected system.
The domain accessed via internet explorer could potentially be a command and control (C2) channel. Consequently, this domain was fed back into Countercept’s network monitoring components to detect any evidence of prior communication with this domain. The results of this indicated that only the affected system had ever communicated with this domain and that it had first communicated with it shortly after the delivery of the suspicious zip file.
At this point, a relatively thorough investigation had been performed which had revealed a significant amount of interesting information and forensic artifacts. Whilst the content seen was almost certainly malware, specific follow up reverse engineering and incident response activities would be required to answer the remaining questions. Additionally, whilst it had appeared to only affect one system, alert rules were created on Countercept’s network sensors to flag any further communication with the C2 domain.
The following day two alerts were received for other hosts related to communications with the C2 domain, despite no further alerts being received for the suspicious zip file being contained in HTTP streams. Further, analysis of the forensic data collected by the Deteqt agent on these systems showed very similar evidence of the malware that was seen on the original host. However, these users had been working remotely the previous day and hadn’t been visible to the sensors owing to the organization’s remote working setup.
Consequently, the initial alert had not been seen for these systems as they had been exploited while outside the network perimeter. However, the tactical threat intelligence that had been discovered via the Countercept investigation and the host-based analysis possible via the Deteqt agent had allowed these systems to be identified once they returned to the network. Further analysis of these were then added to the incident response plan along with the original system.
Without the capabilities referenced in this case study the organization would not have been aware of this compromise of their systems. However, with a combination of network sensor alerting, log data and endpoint analysis it was possible to detect and respond to the attack in a timely manner. This ensured that the incident response process was constrained to a small number of systems, thereby reducing its complexity and cost. Facts based on evidence gathered in near real-time could be communicated to the organization to provide situational awareness in a calm and measured manner. More importantly, the business could continue as normal, accepting that this type of incident is just part of doing business in the modern world.
<*>actual information redacted for security reasons
Categories