The US Cybersecurity and Infrastructure Security Agency (CISA) has just put out a bulletin numbered AA22-074A, with the dramatic title Russian State-Sponsored Cyber Actors Gain Network Access by Exploiting Default Multifactor Authentication Protocols and “PrintNightmare” Vulnerability.
To sidestep rumours based on the title alone (which some readers might interpret as an attack that is going on right now), and instead to reinforce the lessons that CISA hopes this incident can teach us, here’s what you need to know.
Fortunately, the overall story is simply and quickly told.
The attack dates back to May 2021, and the victim was an non-government organisation, or NGO, un-named by CISA.
As far as we can tell, and briefly summarised, the attackers:
- Got an initial foothold due to a poorly-chosen password.
- Found an account that had been left inactive for ages, instead of being removed.
- Re-enrolled the account into the 2FA system, as though the original user were reactivating it.
- Logged in as this user, sailing past the 2FA part thanks to re-enrolling the account with their own device.
- Exploited the PrintNightmare vulnerability to get Domain Administrator access.
- Deliberately broke the 2FA system by messing with its configuration, so it no longer demanded 2FA reponses from anyone.
At this point, as you can imagine, the attackers were able to add new accounts without worrying about 2FA; wander around the network; riffle through organisational data stored in the cloud; and snoop on email accounts.
CISA didn’t give any information about how much data was accessed, how long the attackers stayed inside the network, or what, if anything, was exfiltrated.
Those details would have been interesting to read about, to be sure, but they’re not critical to the story.
What’s important is how the attackers got in, and how the infiltration could have been prevented.
What to do?
Our recommendations are:
- 1. Pick proper passwords. If your users find good passwords hard to invent and remember (and most people do, leading them to fall back on obvious words or phrases instead), consider investing in a password manager for everyone, and showing your staff how to use it.
- 2. Fully disable or remove dud accounts as soon as you can. Make sure that you have a clear and complete process for removing users and their accounts if they leave the company, or if they switch to a different part of the organisation with a different network. Review unused accounts regularly and get rid of any that are no longer needed.
- 3. Don’t set up your 2FA to “fail open”. Failing open means that if the system breaks, it will starts letting everyone bypass that part of the authentication process, instead of keeping everyone out until the problem is fixed. If you have an authentication system that you consider so unimportant that your policy allows you to skip it for convenience, why have it at all? Build the system to be suitably robust that it can fail closed, and devise a robust procedure for recovering it on the rare occasions that it does go wrong.
- 4. React quickly if key system security features stop working. If you notice that security checks you’d expect to face suddenly stop showing up, don’t treat that as a time-saving treat. Report the anomaly, and investigate why it’s happening as soon as you can.
- 5. Give staff a single point for reporting problems. The sooner you know something is wrong, the sooner you can investigate. Turn your whole staff into the eyes and ears of your security team by providing an easy-to-remember email address and internal phone number. Encourage reports, investigate promptly, and thank users who do their best to help you, even if what they report turns out to be harmless.
- 6. Monitor your system logs regularly for risky behaviours such as new account creation. These days, cybercriminals do their best to blend in by choosing account names, computer names and program filenames that match the nomenclature you use yourself. (They typically wander round your network first and make notes, so they can learn how to fit the mould.) Don’t rely on attackers being obvious.
And, of course:
- 7. Patch early, patch often. We don’t know, given that this incident apparently started in May 2021, whether these attackers knew about the PrintNightware bug just before it was patched, or first adopted it shortly after it was widely reported. Nevertheless, make prompt patching your watchword: get ahead of the cybercrooks whenevever you can, and catch up with patches for zero-day attacks as soon as possible when required.
Things to remember
The title of this CISA bulletin may sound dramatic, but this was not a new type of attack; it did not rely on any previously unknown flaws in 2FA; and it did not rely on hard-to-spot exploits or brand new hacking tools.
(Although the attackers did indeed use the PrintNightmare exploit in this case, they were still able to get inside the network without it.)
Remember that Proactive SecOps + Strong monitoring + Fast response + Safe configuration choices = A better prospect of stopping attackers in time.
If you don’t have the experience or the time to maintain ongoing threat reponse by yourself, consider partnering with a service like Sophos Managed Threat Response.
We help you take care of the activities you’re struggling to keep up with because of all all the other daily demands that IT dumps on your plate.
Not enough time or staff?
Learn more about Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response ▶
4 comments on “CISA warning: “Russian actors bypassed 2FA” – what happened and how to avoid it”
The first link is wrong to the CISA bulletin.
Ooops, good spot. Fixing now! (I transposed “074” in the text into “047” in the link. Should be correct now [2022-02-16T13:00Z].)
MFA config to fail open is common. MFA bypass for non-enrolled users is common. No alerts for these configs that are supposed to be for test/setup phase. MFA providers need to do better.
When you make a bad setting easy to enable (or default enabled) and don’t create an onboarding and alerting flow around those bad settings, some of that responsibility must go back to the provider of the service. You built it. The customer is renting it, likely with inexperienced staff trying to speed RTM during rollout.
Leaky S3 buckets everywhere? Amazon finally built a blinky light for that. Duo does not have this for bypass policy settings.
I might add that any security system/implementation should be tested from time to time – make sure it works and that it has no critical vulnerabilities.
If you only test your system when your IDS or IPS flags something, you’re not actually testing it – testing should be proactive not reactive.