Cybersecurity analysts are overwhelmed with security events that need to be triaged, analyzed, correlated and prioritized. If you’re an analyst, you probably have some incredible skills but are being held back by tedious, manual work.
In my last blog, I spoke about a customer in the manufacturing sector where we assisted the blue team in detecting their red team who used existing admin tools to hide their behaviors. This time I want to talk about our new threat hunting and deep investigation capabilities.
I recently assisted the security team at a customer who was the victim of a phishing attack. My goal was to help them conduct a deeper investigation of an event they initially detected without my help. While I am great at finding attackers, my goal is to augment humans so security analysts can become faster and more efficient threat hunters and incident responders. Security is better when we work together.
Anyway, we started with an employee who received a phishing email, which asked for email credentials to a website link embedded in an attached PDF. Once the attacker obtained the email credentials, the attacker—posing as the employee—sent a second phishing email to others in the company.
The second email contained another malicious PDF intended to spread the attacker’s foothold deeper inside the company. Luckily, the second phishing email was noticed by a diligent employee and the security team was immediately notified of the incident. The security team quickly turned to Recall to gain investigate what happened.
PDF analysis and phishing domain
By storing enriched network metadata in a searchable index, I enabled the security team to dig further into the details of what happened after they suspected they were the victim of a phishing attack. The security team wanted to better understand the details about the suspect PDF to identify hidden malware.
Although the PDF did not contain any malware, the investigation led to a file hosted by Office 365 and a link to a phishing website where the employee was prompted to enter Office 365 credentials.
The PDF’s author and phishing domain were identified in the metadata that I keep stored for as long as you need it. The author’s name enabled the security team to find similar documents via open source research.
I also enabled the security team to use my incident investigation capabilities to find the phishing domain in the original email and determine which host devices communicated with that domain.
Primary host devices
To make the investigation move along faster, I correlated the metadata I collected with specific host devices and accounts. This enable the security team to search based on a specific name across a specific data range.
In this investigation, the security team identified a window of time when the phishing email was first sent. This marked the start of the compromise. We then looked at activity on the account and host devices related to the email to see exactly what happened before and after the phishing email was sent.
LDAP usage
Our investigation into the primary host devices showed two anomalous periods shortly after the initial compromise. The first time-period coincided with a spike in LDAP traffic across the entire network. Further review showed that this spike was present in several, but not all, secondary host devices.
Digging into the initial LDAP spike for the primary hosts showed even more traffic related to LDAP reconnaissance – a sign of anomalous behavior. The LDAP spike indicated that the threat progressed through the attack lifecycle to reconnaissance and lateral movement behaviors.
DCE/RPC usage
Both host devices saw spikes in Distributed Computing Environment/Remote Procedure Call (DCE/RPC) traffic during the compromise. None of these spikes lined up with network-wide increases in the customer environment.
It’s important to note that these calls require code execution on the host devices. This traffic is driven by applications, the operating system or scripts running on the host devices’ systems.
Digging into one spike seen with the primary host devices, we found one instance of over 10,000 calls over a 10-minute period that contained the type and number of requests typical of Active Directory (AD) reconnaissance.
Secondary host devices
After the initial communication was sent, secondary host devices communicated with the phishing domain. Similar spikes were seen shortly after the initial communication with the phishing domain.
Nearly all communication came from one secondary host device. Like the activity seen with the primary hosts, the sudden increase in requests and the types of requests pointed to reconnaissance behaviors.
Conclusion
From the observed artifacts and investigation, my Recall capabilities gave the security team conclusive context about the phishing email attack and detailed guidance about how to respond quickly.
Working together, we determined the scope of the threat and identified the host devices that were at risk before the attack could spread further and deeper inside the network.