by Nicholas McBride – ECURON Cybersecurity Consultant
Two stories from my own experiences demonstrate the importance of Incident Response Frameworks and the impacts of not having the right elements in place. The stories I relate here arose from my own experience assisting with Incident Detection and Response. In these cases, the lack of a robust Incident Response Framework (IRF) led to an extended Incident Response (IR) process, resulting in increased risk towards the organization’s objectives. I’ll illustrate how a seemingly unimportant and often overlooked piece of an organization’s overall security posture can lead to substantial financial and mission objective impact. By sharing these stories, I hope to help you to avoid experiencing a similar challenge.
Story One: When a Whale Gets Phished
Phishing is the fraudulent practice of sending emails purporting to be from a reputable company that is actually sent from a malicious party usually with the intention of inducing the victim to reveal personal information such as passwords or credit cards. These emails are usually mass spammed with the idea that if you send enough of them you are bound to get some responses. A more targeted form of this attack, in which the threat actor tailors the email to specifically targeted individuals, is known as a Spear Phishing attack. Whale Phishing is a version of Spear Phishing in which the phishing emails are targeted at high-level executives. This allows an attacker to leverage the executives high level of access and authority within the organization for malicious purposes.
In this story the targeted individual was an executive within an organization who fell victim to a phishing attack that gave the attacker the credentials to the executive’s Office 365 account, allowing them to not only copy sensitive information from the executive’s email and SharePoint, but also to send emails as if they were the executive in question. The attacker leveraged this access to send an email to the financial department asking for a wire transfer to a bank account which, if not for the diligence of the employees of this organization, could have led to thousands of dollars in losses. That said, the importance of this story lies not in the attack itself but rather in the Incident Response process of the organization.
When I was first alerted to the email asking for the invoice I was looped in after the account password had been reset and Multi-Factor Authentication had been enabled to prevent the attacker from further illicit access. My purpose was to help the organization identify how the account was compromised and to determine the scope of the compromise. At this time, it was not yet confirmed that the initial attack vector was phishing and we also were unsure if the attacker had managed to con the executive into installing malicious software on the executive’s workstation as well. As such we decided upon a two prong approach of reading logs, both email and workstation, as well as performing basic endpoint investigation on the executive’s workstation to ensure that the machine was not compromised as well as the executive’s Office 365 account.
The issue that we ran into is that when attempting to perform the endpoint investigation on the executive’s workstation we were unable to get ahold of it. While this person was in the office for the first two days of the investigation, they were unwilling to give up their laptop, citing a variety of excuses. As a result, what might have been a week-long investigation turned into a several week ordeal lacking only performance of the endpoint check to consider this incident successfully resolved. The failing with this organization’s Incident Response Process became quite apparent: lack of executive buy-in. As discussed in my last article, it is vital that the security team have the authority to perform their jobs when in the middle of an incident. Had the executive’s workstation been infected, the risk to this company would have been greatly increased with each passing day.
While it is understandable that executives have mission critical work to perform, it is unacceptable not to work with the security team to find alternate ways to perform this work (even at a semi-reduced capacity) while an incident is ongoing. It is also important for the security team to understand the executive’s need to perform their job and to work with them and the IT team to solve this problem. My personal favorite method is to provide the executive with a replacement laptop that is built from a backup image of a known good configuration that they can use while security is performing their investigation, with the onus on the executive to have proper data backups so that they can access the information they need while the investigation is being performed. This would have led to a quickly resolved incident with all stakeholders assured that the threat had been properly contained and mitigated, allowing us to move on to other tasks rather than wasting time each day looking for suspicious logs coming from the executive’s potentially compromised workstation.
Story Two: Clear Communications
In this story I was brought in after the first 24 hours of the investigation had already passed to assist with providing ancillary information that would help the teams working the investigation to uncover the full timeline and scope of the compromise. I was told that a compromised system had been detected and initial investigation revealed lateral movement onto several systems. The goal of bringing me in was to help ensure that remediation had worked on the compromised systems and to look for Indicators of Compromise (IOC’s) from systems that had not been identified as compromised. It quickly became apparent that there was no IR in place, or if there was it was not flexible enough to account for this particular scenario. What should have been a 48 hour investigation followed by monitoring turned into an investigation that lasted almost a week as new problems in visibility were found and tools built to try and work around it. This was combined with a lack of clear and transparent communication between the various teams working on the incident and was further hindered by the fact that there were three third-party organizations working alongside the compromised organization, with limited communication and collaboration between the third-party organizations.
Over the course of this investigation it became clear that three key pieces were missing from the IRF that would have allowed for faster resolution and lessened financial impact. The first piece that was missing was a clearly defined escalation process. As a result, escalation to the wrong parties before certain parts of the IR process had taken place caused panic and led stakeholders to disagree on the best way to go about the IR. The second missing piece was designating who should oversee the IR process, from declaring it an incident to declaring the incident completed. And the final missing piece was clear communication between the various parties assisting in the investigation. The third-party organizations brought in to assist with the process were able to apply their own methodology and known best practices to the investigation of the compromise so that ultimately the incident was successfully contained and remediated. But the entire process was rendered highly inefficient due to the lack of a more clearly defined escalation process and assignation of responsibility within their own organization. Bad as it was in this relatively simple incident, such a problem would quickly spiral into major complications in a more complex and severe incident.
Conclusion:
As I’ve stated before, it is usually not the lack of proper tooling but rather the processes around tools and people involved in the IR process that leads to IR failure. In the first story we saw how a lack of executive buy in and lack of authority given to the security team can lead to greater financial risk for the entire organization. It’s not enough to have a security team with an Incident Response Framework, they also must be able to execute the processes laid out in the framework to be effective. In the second story we saw how a lack of clearly defined escalation paths and lack of assigned responsibility led to an increase in overall cost for the Incident Response process. By clearly stating to whom the incident should be escalated, we ensure that the proper stakeholders are notified at the proper time. With proper assignation of responsibility for each part of the IR process to the proper people we ensure that there is quick and clear communication amongst all parties involved, contributing to an efficient resolution.
When an organization includes these elements into their IRF, they reduce the risk to their organization in the event of an incident. This reduced risk directly translates to a reduced overall cost for the incident response process and a reduced negative impact upon the organization’s objectives. It is through proper planning and the design of flexible frameworks that organizations will be able to meet the ever-changing threat landscape of tomorrow.