It’s very common for system administrators or cloud-based service providers to create test accounts to experiment with new features or proofs of concept without impacting an actual user. But these imaginary users can turn into real-life trouble if malicious actors discover them and use them as an intrusion point that ultimately leads to a widespread compromise.
Here are some important tips for how to manage your own test accounts…
* Keep these accounts temporary.
Just as you should remove the access credentials of an employee who has left your company, you should also delete accounts belonging to pretend test users. Otherwise, the legacy accounts remain in play for malicious outsiders to take over – and from there, they can move laterally to other parts of your systems.
* Employ proper authentication and IAM practices.
Even if these test accounts are temporary in nature, it’s a wise idea to require a strong password, plus multifactor authentication or other IAM best practices when logging in. Also, set policies to limit the number of times any user can attempt to sign in. Failing to enact these safeguards allows attackers to use brute-force or credential stuffing techniques to log in and establish a foothold.
* Limit privilege whenever possible.
Test accounts should follow the zero-trust principles of least privilege. Unless it’s absolutely necessary, these accounts should not be granted admin powers or have widespread access to valuable assets. To disregard this advice is to allow intruders a methodology for elevating their privileges once they gain access to the test account.
* Employ threat detection and response.
Establish a robust defense that flags anomalous behaviors that could be a sign of malicious identity theft and fraud activity, and ensure that these measures extend to non-human identities within your organization.
The cybersecurity community was recently reminded of the dangers around neglected test accounts when Microsoft in January 2024 acknowledged a series of configuration mistakes associated with an old test tenant account. These errors ultimately led to Russian-state hackers using a password spray attack to swipe Microsoft 365 credentials and subsequently compromise corporate emails.
By Microsoft’s own account, the attackers, referred to as Midnight Blizzard, “utilized password spray attacks that successfully compromised a legacy, non-production test tenant account that did not have multifactor authentication (MFA) enabled.” Next, the culprits “leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access...” From there, the malicious actors were able to create additional malicious OAuth applications and grant them access to the Microsoft corporate environment, including mailboxes.
In response to the incident, Microsoft provided some of its own public guidance to help organizations hunt for, detect and reduce risk around this particular species of threat.
