What the US federal agency hack teaches us about patching. Again.
Another high-profile breach shows that we still haven't learned the lessons from WannaCry.A CISA alert from 15 November has detailed a successful compromise of a Federal Civilian Executive Branch (FCEB). While there’s no details on which FCEB, there’s a lot of them, ranging from fairly benign (e.g. National Endowment for the Arts) to those of critical national importance — the Department of Justice , NASA and the Department of Homeland Security.This hack might have significant ramifications for the US. And from what we know so far, the breach could have been prevented if basic security controls had been in place and working effectively.
How did the hackers get in?
CISA’s alert is detailed, and what stands out is just how much free reign the adversary had. The initial compromise was via the incredibly well-publicized Log4J vulnerabilities, which were extensively patched. Discovery was at the network level, with CISA observing traffic from the FCEB’s network to a known IP associated with exploiting Log4Shell in April 2022.The software that hosted the vulnerability, VMWare Horizons, had a patch available in December 2021. Forensic analysis determined that the attack started in February 2022: two months after mitigations were available. It took a further two months for the activity to be detected through network monitoring.And that’s why I say we need to learn about patching again. WannaCry, which wreaked so much havoc globally five years ago, was able to infect and spread due to vulnerabilities that should have been patched.Once on the network, the adversary was quick to act. They turned off AV scanning to avoid detection, installed a cryptominer, used well-known tools and techniques (including Mimikatz), altered local admin accounts, created a new domain admin account, used remote desktop protocol (RDP) internally and via reverse proxy, and more. They attained credentials by attacking the key management infrastructure, and were thwarted when attacking LSASS by AV software.This wasn’t a zero-day attack
Basic cyber hygiene would likely have stopped the initial compromise. If the FCEB’s patches were up to date, this would have been prevented. It’s not known if the FCEB employed a vulnerability scanner, however they will be doing so now given the recommended mitigations.If there is a security operations center (SOC), then we assume they are overloaded with the number of alerts as there are multiple indicators of compromise that the SOC should have noted. However, there are further checks outside of the SOC that would help detect such activity.What controls would have limited the impact?
Rather than focus on reacting to indicators of compromise (IOCs), there’s another line of defense: security control checks. These exist across all the techniques the adversary used.There are numerous instances where the FCEB could have discovered the presence of the adversary, if security controls were in place and working properly. For example:- Ensuring endpoints (including virtual desktops) use allowed and banned app lists would stop Mimikatz and cryptominers from running.
- Checking if AV scan reporting frequency is in line with service-level agreements (SLAs) (e.g. one week, or even one day for certain assets), which would raise a red flag to investigate when the adversary turned off scanning.
- Auditing all privileged access functions would flag creation of new domain admin accounts, and activity on local admin accounts.
- Checking for compound risk created by multiple control failures used in common exploits. Asking “show me where we have endpoints that have AV scanning disabled with a change to local admin accounts since the last scan” would give higher fidelity signals. Bring in whether the asset has been scanned by the vulnerability scanner and you’ve got a high fidelity alert to act on.