The Evolution of Attacker Behavior: 3 Case Studies This blog post was authored by Mike Ortlieb, Director, Security and Privacy and Chris Porter, Associate Director, Security and Privacy on The Technology Insights Blog. Threat actors are an ever-evolving species. Portrayed in popular advertising as guys dressed in black, probably sporting a ski mask, the harsh reality is that these bad actors are everywhere and are getting more creative by the day. Just when an organisation’s security systems have been upgraded to avoid the latest threats, new challenges appear on the horizon. Staying steps ahead of these disruptors is what causes Chief Information Security Officers (CISOs) to toss and turn at night, dreaming of the next breach possibility. We recently presented a webinar (now available for on-demand viewing) outlining three case studies in which a threat actor was able to successfully compromise a network environment and the technical and process breakdowns that occurred along the way. Each case study also includes key concepts and takeaways that organisations can bring to their internal teams. We illustrate some of the changes we’ve seen in how threat actors have honed their techniques to cause disruptions to organisations, and to increase the effectiveness of how they defeat common defenses. A common theme among each of these case studies is the fact that each of these organisations had some missteps in their defenses and processes, resulting in much more significant compromises than what may have occurred if defenses and processes had operated properly. Topics Cybersecurity and Privacy Case study 1 – Coordination, collaboration and communication The first case study involved a compromise by a threat actor who had not specifically targeted anyone in the organisation. This was a “drive-by-download,” where a user within the organisation browsed to an infected website and executed the threat actor’s script, giving the threat actor a foothold on the user’s workstation. From there, the threat actor downloaded several malicious tools onto the user’s workstation and used those tools to move laterally through the environment, escalate privilege to an administrator-level account and then obtain access to sensitive company information, including intellectual property, sensitive files, and employee data. Unfortunately for the organisation, there were several breakdowns in their detection and response actions that allowed the threat actor to be successful: A series of alerts came to the Tier One team in the Security Operations Center (SOC); however, the analyst assigned to the alerts did not complete a thorough analysis of the behavior identified by the Endpoint Detection and Response (EDR) tool deployed on the workstation. Some malicious activity was discovered, but the full depth and breadth of the threat actor’s actions on the workstation were missed. Next, while the Tier One SOC analyst correctly identified some malicious activity in the environment, this information was not properly communicated to the Tier-Two team that would perform further analysis and containment. Due to their notification and escalation procedure design, approximately 10 days passed before the event was examined further. There was no common language for the Tier One and Tier Two operators to communicate the criticality of the issue at hand. As a result, neither group was able to impress upon the other the full scope and details of the event or coordinate a timely response. The resulting security incident could have been mitigated if the organisation had approached these issues from a slightly different perspective. Any organisation may consider these questions: Does our detection and analysis process allow for different tiers of SOC personnel to communicate and collaborate on triaging events? Is there a common language to describe the criticality of events and the service levels established to perform analysis? Is the Tier Two analyst group able to mentor or otherwise review the analysis performed by the Tier One analyst group? Case study 2 – Exfiltration and identification The second case study featured an organisation that first became aware of a security incident when a federal agency contacted them about discovering sensitive information belonging to the organisation on the Dark Web. None of the organisation’s security alerts had been triggered, and they were at a loss to understand how their sensitive data had been compromised by a threat actor. After spending several weeks in a hurried investigation of their internal environment, the company pieced together some details about the incident. A user had clicked on a phishing email, resulting in a threat actor gaining a foothold in the environment. The user did not appear to be specifically targeted, however, the phishing email had been customised to the organisation. Analysis showed that the threat actor accessed several different systems in the environment; however, at this point the investigation was stymied due to the lack of log data or other telemetry. As a result, the organisation was never able to get the complete story of how the threat actor managed to remove data from the environment. This incident occurred due to several different factors, notably: Security awareness training had not been fully rolled out to the enterprise. Some security training existed but it was ad-hoc and not well tracked. As a result, not all employees received security awareness training or completed training that had been assigned to them Users had the ability to download and install any software on their own systems. In this case, the threat actor was able to leverage that to install malicious software tools as well as disable local security defense tools, leaving the organisation with a limited view to what occurred on the endpoint Log data, critical to following the threat actor’s activity and building a timeline of systems that were compromised, was not offloaded to a central platform and not retained for further analysis. By the time the organisation became aware of the threat actor’s presence, the logs had already rolled over. Organisations in similar situations may want to explore potential remediation options to the challenges listed above. Potential options for addressing these concerns include: Implementing an enterprise-wide security awareness training programme that encompasses all of the threats and attack vectors that might result in a successful social engineering attack. This might include different programme content for different roles, geographies or industries, depending on the organisation’s profile. Reviewing the business need for administrative access on local systems by end users. In many cases, the ability to prevent unauthorised software from being installed in the environment can help curtail the risk that a threat actor can deploy tools if they get a foothold on a system in the environment Evaluating current log sources in the environment and determining if they are sent to the Security Information and Event Management (SIEM) in a timely manner and are stored as long as is necessary to support both an immediate response and a long-term forensic investigation. Case study 3 – Logging, tuning and validation In our third case study, a much more sophisticated threat actor targeted a specific individual at an organisation. A member of the IT organisation was targeted via a personal email address that they checked using their corporate laptop. After a successful spear phishing attack, the threat actor leveraged the user’s identity to connect to the organisation’s VPN, using a social engineering attack to bypass multifactor authentication (MFA). Once the threat actor established this foothold in the environment, they were able to capture the credentials for a powerful service account, deploy software to a number of critical systems in the organisation, exfiltrate several Terabytes of sensitive information and the deploy ransomware across the entire server environment. This resulted in a massive organisational disruption and the loss of sensitive data. Factors allowing the threat actor to be successful in this case included: Network detection rules believed to be configured to identify and alert upon some of the tools used by the threat actor were misconfigured. Logic errors prevented them from firing, even when the behaviors they were designed to observe were present in the environment. Server and endpoint logging was not set up to look for specific attacker behavior. Many of the rules in the existing SIEM were default, “out of the box” rules and were not customised to match the organisation’s IT environment. The environment was not segmented to sufficiently stop the threat actor from moving freely from the VPN to the internal network, including the server environment. As in our other case studies, some key takeaways and questions for how to prevent or mitigate such an attack include: Ensuring the detection rules configured in the environment are functioning properly. Proper testing of SIEM and EDR content can help ensure the alerts the company analysis relies upon are functioning as intended. A common test case is to generate the malicious activity the rules are intended to alert upon, introducing that activity into the network. This can be performed for every rule in the environment to verify they create the alerts needed by the SOC. Building or tuning detection systems to look for behavior specific to the organisation’s environment. This can help reduce false positives as well as ensure alerts received are meaningful and context-aware to the network. Performing network architecture analysis and review to determine if critical systems are core to ongoing operations or contain sensitive data. These case studies show that threat actors continuously innovate and that defenders will need to adapt their defensive security posture to meet the evolving challenge. Organisations looking to improve threat protection in the coming year should consider these closing thoughts: Sophisticated threat actors are aware of traditional security defenses and know how to evade or bypass them. Threat actor activity leaves traces behind, and it is incumbent on defenders to continuously look for those clues. There is no aspect of the enterprise that is out of scope for threat actors. Servers, workstations, employee identities as well as employees’ personal assets can all be targeted. Has the organisation validated its defenses from both a design/architecture perspective and a practical/technical perspective? Ensuring that people and processes are aligned and that tools and technologies are properly configured and deployed can help reduce the impact of a security incident and better prepare teams for effective response. To learn more about our incident response solutions, contact us.
