27 Mar 2024, by Slade Baylis
In news that should concern everyone who uses Microsoft services - either personally or for work – Microsoft have disclosed that an attack from earlier this year appears to have led to source code being stolen in an “ongoing attack”.
Originally announced on January 19th, Microsoft1 revealed that their security team had detected an attack on their systems by a threat actor referred to as “Midnight Blizzard” – also known as “Nobelium” – who are a Russian state-sponsored hacking group. The method used to gain access to their systems was the compromise of a legacy and non-production test account, which was then used as a foothold to compromise other systems.
As per usual, we’ll be approaching this article with a view to help our readers understand how Microsoft was breached, explain some of the cyber-security terms related to this breach, as well as help our readers understand how to protect themselves from similar kinds of threats in the future.
In this case, the initial attack vector used to get into Microsoft’s systems was a "password spray attack" - which is a type of "brute-force attack". This type of attack is used to bypass protections that are in place against regular brute-force attacks, but to understand how, we’ll first need to explain what a brute-force attack is.
A “brute-force attack” – also known as “brute forcing” - is a type of cyber-attack where an attacker attempts to break into an account by submitting many passwords over and over again, with the hope of eventually guessing the correct password. The idea for this is fairly simple and stems from the knowledge that many people use simple passwords because they're easier to remember - so if an attacker is able to guess enough times, they may be able to get into the account.
It’s for this reason that the basic standard for all online systems is to enforce password strength requirements. In addition to this, another protection also often implemented is to only allow users to attempt to enter their password a certain number of times before blocking any further attempts.
A "password spray attack" is slightly different than regular brute forcing. In password spray attacks, the attackers keep the passwords constant and then attempt to guess – or brute force - different usernames. This may sound odd to you, as how could an attacker only use a single password and have any chance of getting access? The answer is that this attack only works against systems where a “default password” is used for new accounts set by either administrators or the application itself.
On systems that utilise a default password for new users or accounts, if the attacker is able to learn of this password, they're able to then gain access as long as they can find one account where the default password was never changed. Usually this is just a matter of time, which is why applications that utilise default passwords should be avoided when possible. This type of password spray attack also routes around some of the protections that are in place against regular brute-force attacks.
As mentioned earlier, most applications will lock users out if they fail to log in too many times. However, as they usually track consecutive logins to a single user, this protection can be avoided by only attempting each user once. This doesn’t help if you are trying to guess the password of a single user, but works incredibly well when they’re only checking to see if that user has the default password set.
For Microsoft, the password spray attack method was used to get an original foothold on that initial legacy system – and then through that system, they were able to move laterally and gain access to other systems.
As reported by Microsoft originally in January, the initial system that they gained access to was a “legacy non-production test tenant account”. However, it appears that this test tenant had access to other systems that definitely weren’t testing and non-production systems. From that compromised tenant account, the malicious actors were then able to “use that account’s permissions to access a very small percentage of Microsoft corporate email accounts”, which included the email accounts of members of their senior leadership team and employees in their cybersecurity, legal, and other teams.
Through this access they “exfiltrated” – a cyber-security term for the discrete stealing of information from a device or network – some emails and also the attached documents from those corporate email accounts. At the time it was announced, Microsoft stated that there was no evidence to date that the threat actor had any access to production systems or source code – however this has since been superseded in their most recent announcement in March.
In this update2, they announced that as part of their investigation, they have seen evidence that the group that hacked them - Midnight Blizzard - had been and are using this information to access other systems. Specifically, Microsoft stated that the information was being used to gain access to other internal systems, such as the successful breach of “some of the company’s source code repositories and internal systems”.
What wasn’t revealed in their update was which systems and source-code was compromised - as source code repositories could contain the source code for smaller non-vital applications and services, or they could alternatively be the source code repository for key production systems – so without more information it’s hard to know just how concerning the breach truly is.
Whilst any breach of any scale should be cause for some concern, they have also stated in that same announcement, that to date they have not found any evidence that Microsoft-hosted customer-facing systems are being compromised. So – at least in principle – customers of Microsoft may not need to be too concerned over the security of their own Microsoft-hosted systems. However, there are several things that can be learned from this breach in order to protect yourself against similar types of breaches from happening to you.
The first lesson should be that if you have legacy and/or non-production systems, access to these systems should be highly restricted if they need to be left running at all.
If they are no longer needed for production purposes, you should review whether these systems can be shut down in their entirety to limit your attack surface. After all, due to being legacy systems, it’s likely that they will only become more insecure with time. For legacy systems that still need to be accessible in some form, looking at ways to isolate these systems as much as possible from external access is advised, as this can help prevent the types of breaches we saw here.
As we’ve consistently reported on, the unfortunate truth is that attacks like these are happening with greater frequency as time goes on. Since the successful attack on Microsoft, they’ve announced that the volume of some aspects of the attacks targeting their systems, such as the aforementioned password sprays, have increased as much as 10-fold in February, compared to what they saw the month prior.
What this breach (and others like it) highlight is the continued risk posed to all organisations from well-resourced nation-state threat actors.
If you would like to discuss your security posture and how you can improve it, let us know!
We’re happy to have a chat and provide general guidance if you have general questions, or alternatively even complete a full review and offer specific recommendations unique to your environment.
You can call us on 1300 769 972 (Option #1) or email us at sales@micron21.com!
1, Microsoft, “Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard”, <https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/>
2, Microsoft, “Update on Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard”, <https://msrc.microsoft.com/blog/2024/03/update-on-microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/>