Mystery still Surrounds theft of MSA signing Key in recent FCEB Breaches

Last week Microsoft, the FBI, and CISA made disclosed several attacks on Federal Civilian Executive Branch agencies and other targets of a campaign that appeared to be driven by a new threat group out of China. The attack we detected and tracked down using internal logging available to the GCC low-side tenants and with the help of Microsoft. Fortunately, GCC (Government Cloud Computing) Low Side is not supposed to contain or pass any classified information. It is intended to be used by government agencies and contractors that do not need or have authorization to access anything more than routine sensitive information. This does not reduce the seriousness of the attack and does beg the question on how well the tenants were secured by the cybersecurity teams involved, but at least nothing National Security related was compromised.

Microsoft was able to track down the attackers and identify their attack patterns and tactics in this incident. The group used forged tokens to compromise the Exchange Online and Azure AD accounts of multiple people. They were able to forge these tokens through the use of a stollen/compromised Microsoft Account Consumer Signing Key (MSA Signing Key). How access to this key was gained is still under investigation by Microsoft. After identifying the forged access tokens, Microsoft moved to block the stollen key to prevent future access by the threat actor.

According to Microsoft, the attackers used a flaw in the GetAccessTokenForResource API call combined with scripts to generate the new tokens for targeted accounts. From there the attackers were able to gain access to email accounts and exfiltrate the information in them as part of the post compromise activities. Again, the initial access and method used to gain access to the MSA signing key is still unknown. Once the key was blocked/revoked, Microsoft says that the infrastructure used to replay the tokens for access was shut down about 24 hours later and the attackers have moved on to different techniques. This would seem to indicate that the attackers only had access to a single key and/or do not have an easily repeatable method to steal additional signing keys.

As an additional precaution, Microsoft has said that they have revoked all existing valid MSA signing tokens to proactively prevent using any potentially compromised keys that might be out there. They have regenerated all of the keys in their key store. If they have reviewed and/or improved security around the store, Microsoft has declined to say. We imagine that they are at the very least improving logging and monitoring around who and what accesses the keys in the key store to either identify any insider risk, or to see if there is potential data leakage in any internal APIs that access the store. It would be the sensible thing to do considering the information they have on the theft.

The theft and use of an MSA signing key in an attack is a concern. It could indicate flaws in Microsoft’s own security around these critical components or that someone with a high level of access inside Microsoft is willing to give these keys out to threat groups. Either one is bad, but this attack also highlights a large issue with the use of cloud services; how often internal security settings in those cloud services are left at default, or only enabled with the basic settings. The reliance on cloud systems without understanding how to harden them against attacks is just as serious of an issue as an attacker compromising a signing key. The sooner organizations realize this and start taking the proper steps to secure their environments (including hiring the right staff) the better things will be.

No comments

Leave your comment

In reply to Some User