Blog / A Case Study About a Russian State-Sponsored Attack
Quickly installing updates and performing regular maintenance could have stopped a Russian state-sponsored attack.
I’ve used the last couple of newsletters to give gentle reminders that, due to the war in the Ukraine, organizations should be paying more attention to their cyber security. Recently the US released details on how a Russian state-sponsored attack managed to breach an organization’s defenses. Personally, I find these studies useful because they provide detailed information about what went wrong during an event that allows us to reevaluate our own setups.
The article provided is invaluable for two reasons. First, it reveals the tactics that attackers are using, and secondly, it acts as a cautionary tale to avoid making the same mistakes.
To quickly summarize what happened, Russian hackers made use of an old (but not disabled!) account in Active Directory (AD). They logged in, then used an exploit to elevate their privileges and gain access to other accounts to gather information. However, it’s in the specific details of the attack that we can find some useful information.
First off, as we mentioned, the account the hackers used was old. By default an old account should get removed from multi-factor authentication after a period of inactivity (this is configurable and a default of any MFA solution). So the first mistake was that the organization didn’t regularly audit its AD accounts. Make sure you have a process in place to create and delete AD accounts during on- and offboarding. Also, you need to regularly audit those accounts to make sure something hasn’t been missed; sometimes 3rd party organizations have remote access accounts so who knows how often those get used.
Because the attackers logged in with an old account from a time prior to the organization’s implementation of MFA, the attackers were forced to setup the MFA, but of course that does not good when the hackers are the ones setting up the MFA creds for themselves. After that, they exploited the PrintNightmare vulnerability to gain administrative privileges on their account. This brings us to the second error, failing to apply a critical update in a timely manner. When this attack occurred, an important security patch that could have prevented the attack had been available for months. They were clearly not monitoring their administrative users, but that should be a regular audit, so the victims could be forgiven for that. Failing to take a security update in a timely manner, though? That’s should really be common knowledge by now.
Next the hackers altered the MFA configuration so it was unable to properly validate the codes it received. The default configuration with most MFA solutions in the case of an error is to “fail open,” which isn’t really a mistake and exists with many different things (like web filtering). Basically, in the event that something goes wrong with whatever check you’re performing (MFA in this case) there are two choices; consider the check to have failed, or consider the check to have succeeded. Failure means whatever you are doing will stop working. This is good because it means you will find out about the error very quickly and bad because it means nobody can use that service at all until the problem has been fixed. The mistake here wasn’t the configuration; it’s that the victim did not routinely monitor their logs to verify their MFA solution was working properly.
With all this done the attackers were free to get into any account without needing to change a single password. The organization’s final mistake? Not monitoring user login events.
Breaking down the situation further we see is that very little of it was an actual “attack”. Most of the attack just exploited standard behavior. There’s nothing strange about an inactive AD account no longer enforcing MFA after a set period of inactivity. Likewise, there’s nothing incorrect about a MFA solution failing open if it can’t properly validate the codes it received. These are both expected behaviors. The only actual “attack” was using PrintNightmare to give the compromised account administrative privileges.
The biggest takeaway from this is, in my opinion, that organizations need to routinely audit their Active Directory user accounts. Keep an eye on users with passwords set to never expire, users who are admins, the last time a user logged in, and all the rest of those technical details. Old or inactive accounts should be disabled, which prevents them from being used but preserves them for possible use, and disabled accounts should be evaluated for possible deletion. Unfortunately, after many years of security audits with a variety of clients, I can confidently say these tasks are very rarely done. They should be regular activities and performed every month or so. Also, and I can’t stress this enough, if there’s a critical update released for any of the software you have, find the time to install it quickly. Make the time, if necessary.
It’s surprisingly easy to find applicable Shakespeare quotes about modern cyber security issues. And yet, there’s plenty of material to search through for wisdom, like this weeks quote from The Two Gentlemen from Verona; “How use doth breed a habit in a man.”
If you’d like help improving your security during this period of unprecedented Russian hacking, please contact your TRINUS account manager today.
Be kind,
Courtesy your friendly neighbourhood cyber-man.
