Unless you’ve been living under a rock, you’ve probably read or heard about the targeted attacks on US government email that used an access token generated by Microsoft to spoof allowed access. Called Storm-0558, it involved a China-based threat actor using an acquired Microsoft account consumer key to forge tokens to access OWA and Outlook.com, gaining access to sensitive email accounts. The attackers were discovered thanks to some smart outside investigators and some well-created log files that showcased that someone other than the parties authorized to access the accounts was opening these technology assets with unusual methods.
In other words (and in my interpretation of Microsoft’s reporting), rather than opening up email on a desktop client, what gave the attackers away was that they used some different and unusual means of opening the email. Merely not being normal triggered the investigation. Microsoft then found that a consumer-based account signing key was used to forge the necessary corporate credentials. Microsoft soon determined how the attackers acquired the key and what it found revealed that the intrusion might have been prevented with enough foresight (albeit only if you were very forward-thinking about the threat of determined attackers several years ago).
Bad actors may already lurk in your network
In April 2021, a consumer credential signing system suffered a blue screen of death, and the associated crash dump included the signing key information. While normally this credential signing system is on an isolated production network, at some point in time after April of 2021 it was moved to the corporate network to be debugged.
When an attacker compromised an engineer’s account to gain access to the network, the crash dump that included these sensitive keys was picked up by the attacker. When I read Microsoft’s writeup of what happened, it makes me wonder if — due to log-retention policies that do not go back as far as an event that happened years ago — the present explanation represents what it thinks happened, not what it knows with absolute certainty.
Without actual log files and forensic evidence to be certain, one ultimately must gather what information exists and infer what occurred. What’s clear is that attackers have started to lay in wait and are taking longer between gaining access and abusing it. Thus, the ability to identify when someone has gained access and make the decision to restore your network back to a point in time before the intrusion may become a physical as well as a technical impossibility.
While many organizations and companies do not operate in the same high-profile and target-rich environments as Microsoft and national governments, there are some valuable lessons and considerations for all CISOs in the way the Storm-0558 attacks played out.
Targeted workstations and servers may need more protection
For any asset or human in your organization that handles any key or sensitive processes in your firm, review several items. First, is the workstation they use hardened? Are only those software and tools absolutely needed on that operating system?
In light of the crash dump that revealed sensitive secrets, should crash dumps be disabled completely in any sensitive machine? Should you have a dedicated and isolated space for crash analysis and have your staff trained to handle and identify those machines that might hold sensitive secrets?
Review the hardware and operating system that these key individuals are using and determine whether they should be on newer equipment with more secure boot features or have more security features enabled that often are gated by a Microsoft E5 license.
Follow workstation hardening guidance provided by NIST or the Center for Internet Security and ensure additional protections for authentication that would help prevent credential stealing such as hardware tokens, Microsoft Hello, or other biometric improvements are in place. Consider the steps you’ve already taken and whether you need to prioritize any human or asset that you consider a likely target.
Review log files and retention
While it’s difficult to keep log files going back more than a year and to keep those we do have adequately secure, it is essential to review our log file retention policies to take into account that attackers often can and do wait for quite a while before taking action. In the past speed was on the side of the bad actors. The faster they got into a network and did damage or installed ransomware, the better. But targeted attackers often have a different goal in mind — accessing data, information, or secrets is their goal, not causing damage.
Where ransomware attacks are often quick and bloody, information attacks can be stealthy and lurk for far longer. Depending on the nature of an organization and what are considered its crown jewels, different logging techniques and recordkeeping lengths can better prepare for defense in the long term.
Reporting may not give you time to investigate
Ideally, every log will be analyzed, every computer examined, and every forensic investigator’s report reviewed before a breach is reported. But the reality of reporting requirements means there may not be time to paint a truly full picture of the attack. In the US, the Securities and Exchange Commission (SEC) has shortened the length of time a business has to report material cybersecurity incidents and has added requirements that information regarding cybersecurity risk management, strategy, and governance be provided annually. Starting with annual reports for fiscal years ending on or after December 15, 2023, the new rules mandate that SEC registrants “disclose on the new Item 1.05 of Form 8-K any cybersecurity incident they determine to be material and to describe the material aspects of the incident’s nature, scope, and timing, as well as its material impact or reasonably likely material impact on the registrant.”
That report is generally due just four business days after a registrant determines that a cybersecurity incident is material. The disclosure may be delayed if the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety, but that’s not something that can be counted on in every instance. It’s far better to ensure that there is a process, a team, and ideally consultants ready to guide communication in four days or fewer.
The bottom line is to consider whether an organization could even start an investigation of a material breach in four days, let alone prepare a report meant for a public location. Prepare a network for the worst sort of attack by assuming the attackers are already in place and waiting for the right time.