Over the weekend, claims were made suggesting Microsoft 365 was breached by threat actors. Reuters reports Russian hackers are using a flaw in Microsoft’s platform to conduct surveillance on the U.S. Treasury Department.

The attack is said to be perpetrated by the same state-backed Russian group that recently attacked cybersecurity company FireEye.

Microsoft’s response to the report was a post featuring a guide for IT admins. In the guide, the company shows how they can “find and mitigate potential malicious activity”. Alongside the helpful guide, the company denies Microsoft 365 has been compromised:

“We also want to reassure our customers that we have not identified any Microsoft product or cloud service vulnerabilities in these investigations.”

Non-Nation Attacks

It’s worth pointing out Microsoft’s denial is a state-back attack happened. The company does confirm a “nation-state activity at significant scale, aimed at both the government and private sector” is happening.

Microsoft has a good track record of confirming when attacks happen and what type of attack it is. To help organizations thwart an attack, Microsoft is advising they look for the following warning signs:

  • “An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Also, see SolarWinds Security Advisory.
  • An intruder using administrative permissions acquired through an on-premises compromise to gain access to an organization’s trusted SAML token- signing certificate. This enables them to forge SAML tokens that impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens created by a compromised token-signing certificate, which can be used against any on-premises resources (regardless of identity system or vendor) as well as against any cloud environment (regardless of vendor) because they have been configured to trust the certificate. Because the SAML tokens are signed with their own trusted certificate, the anomalies might be missed by the organization.
  • Using highly privileged accounts acquired through the technique above or other means, attackers may add their own credentials to existing application service principals, enabling them to call APIs with the permission assigned to that application.”