Stories from the SOC is a blog series that describes recent real-world security incident investigations conducted and reported by the AT&T SOC analyst team for AT&T Managed Threat Detection and Response customers.
Malicious network traffic from foreign IPs was observed trying to establish communication to a compromised internal system. The internal system was then observed trying to execute lateral movement to other internal systems by undertaking nefarious actions that were essentially blocked by the on-premises Host Intrusion Detection System (HIDS).
Initial Alarm Review
Indicators of Compromise (IOC)
Image 1 - Initial Alarm
Observing the initial alarm, the first event captured was an internal IP out-calling to a known malicious C2 IP (208[.]100[.]26[.]245). This simple event is an initial clue into the internal system potentially being compromised. A hasty review could suggest that the alarm could be closed out as auto-mitigated, given that we’re observing that the session had been denied. But, a good analyst should dig a little deeper in order to confirm that no persistent threat remains within the internal system that tried to out-call the malicious C2 IP.
Image 2 - Pivot on IP/Events
In order to further investigate the alarm, we dropped down to the child server/customer deployment to pivot on events logged by internal IP (asset 1), in order to correlate/identify any suspicious activity observed within the internal system.
The analyst should take full advantage of the visibility into the different data sources compatible with USM Anywhere in order to build a more complete profile of the traffic being generated by the asset in question. In the alarm/event, we observed firewall and endpoint events associated with the internal IP. This obviously indicates that the internal IP/asset was undertaking activities that are being blocked/denied by these two security tools. Further investigation should be undertaken.
IOC - Malicious C2 server:
Reviewing the different endpoint and firewall logs, we confirmed that the internal system was in fact compromised and observed an attacker attempting malicious lateral movement. Specifically, they were trying to access port 445 SMB and attempt a brute force authentication against another internal asset. As seen in the screenshot below, event ID 6045 was generated and indicates an "SMB Brute Force Attack" with threat severity "Critical”.
Image 3 - Lateral Movement
Reviewing for Additional Indicators
The agent installed on the compromised endpoint was able to give deeper insights into the actual system such as services running, open ports, and installed software.
By analyzing the enriched data reporting back from the agent and previous scans, the compromised system had SMB port 445 open and was running an EOL version of Windows XP. This indicates that no Microsoft security updates have been installed and some of the most exploitable vulnerabilities, such as Bluekeep, affecting SMB over IP were surely to be found on the compromised system. This evidence further confirmed the asset as a probable entry point for the compromise and built the beginnings of our remediation and containment recommendations.
Referencing the Cyber Kill Chain®, we can see that the malicious actor was able to perform all tactics and techniques from reconnaissance (scanning) to probing (brute-force), delivery and attack (find open vulnerable ports), exploitation & installation (Bluekeep vulnerability), and finally system compromise/lateral movement (malicious internal brute-force activity captured targeting different internal systems).
Building the Investigation - Recommendations for Mitigation
Best security practice in the event of a system compromise is to first and foremost quarantine the compromised system from the live network. The customer was told to take the compromised system offline and run multiple scans on it.
Next, the customer was instructed to grab login logs and note who logged into the system. If an internal username was used, it was recommended to reach out to the user ASAP in order to instruct them to change their password.
Without proper digital forensics conducted on the system, there is no sure way of telling if the attacker installed any backdoors or rootkits. For this reason, the customer was instructed to perform a fresh install on the OS in order to provide that no remaining malware is left after the scans.
In the incident observed, the customer was running an end-of-life system with numerous vulnerable ports open. It left the customer completely open to an attack. An analyst should always look for these small security details when performing investigations in order to start depicting where the attack came from and how it occurred.
If an analyst observes bad security practices such as open/unneeded service or open ports, they should notify the customer ASAP. This goes for highly exploitable vulnerabilities being reported back from any asset as well.
The customer followed the recommendations given and took the compromised system offline. They provided a hard date of when the system will be migrated and brought back online to inform our future monitoring strategies.
Limitations and Opportunities
One of the limitations encountered was the lack of authorized actions allowed by the customer’s existing Incident Response Plan. USM Anywhere has the capability to remotely take a system offline, and ideally, we would have done so after confirming the compromise.