25th March Update: Microsoft shares new detection, hunting, and mitigation information.
﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉﹉
The Lapsus hacker group claimed to hack Microsoft and leaked the source code of Microsoft Bing, Bing Maps, and Cortana. The group posted a file that it claimed contains partial source code for Bing and Cortana in an archive holding nearly 37GB of data.
On Tuesday evening, after investigating, Microsoft confirmed the group that it calls DEV-0537 compromised “a single account” and stole parts of source code for some of its products. A blog post on its security site says Microsoft investigators have been tracking the Lapsus$ group for weeks, and details some of the methods they’ve used to compromise victims’ systems.
According to the Microsoft Threat Intelligence Center (MSTIC), “the objective of DEV-0537 actors is to gain elevated access through stolen credentials that enable data theft and destructive attacks against a targeted organization, often resulting in extortion. Tactics and objectives indicate this is a cybercriminal actor motivated by theft and destruction.”
Also Read:
- A Teenager Reportedly Behind the Lapsus$ Hacking Group.
- Seven Teenagers Arrested in Connection with Lapsus$ Hacker Group
Microsoft also noted that their investigation has found a single account had been compromised, granting limited access. "No customer code or data was involved in the observed activities."- they added.
Microsoft acknowledges that they do not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and techniques discussed in this blog post.
Strengthen MFA implementation
In its blog post, Microsoft outlines a number of steps other organizations can take to improve their security, including requiring multifactor authentication, not using “weak” multifactor authentication methods like text messages or secondary email, educating team members about the potential for social engineering attacks, and creating processes for potential responses to Lapsus$ attacks.
Multifactor authentication (MFA) is one of the primary lines of defense against DEV-0537. While this group attempts to identify gaps in MFA, it remains a critical pillar in identity security for employees, vendors, and other personnel alike. See the following recommendations to implement MFA more securely:
Do's:
- Require Multifactor Authenticator for all users coming from all locations including perceived trusted environments, and all internet-facing infrastructure–even those coming from on-premises systems.
- Leverage more secure implementations such as FIDO Tokens, or the Microsoft Authenticator with number matching. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
- Use Azure Active Directory Password Protection to ensure that users aren’t using easily-guessed passwords. Our blog about password spray attacks outlines additional recommendations.
- Leverage passwordless authentication methods such as Windows Hello for Business, the Microsoft Authenticator, or FIDO tokens to reduce risks and user experience issues associated with passwords.
Don't:
- Use weak MFA factors such as text messages (susceptible to SIM swapping), simple voice approvals, simple push (instead, use number matching), or “secondary email” based MFA methods.
- Include location-based exclusions. MFA exclusions allow an actor with only one factor for a set of identities to bypass the MFA requirements if they can fully compromise a single identity.
- Allow credential or MFA factor sharing between users.
Detecting, hunting, and responding to Lapsus Hacker
Microsoft 365 Defender hunting queries
- Multiple admin role removal operations are done by a single user – This query looks for multiple users that had their administrator role removed by a single user within a certain period.
- ‘ElevateAccess’ operation followed risky sign-in – This query looks for users who had a risky sign-in (based on AAD Identity Protection risk score) and then performed and ‘ElevateAccess’ action. ‘ElevateAccess’ operations can be used by Global Administrators to obtain permissions over Azure resources.
Microsoft Sentinel hunting queries
- User Assigned Privileged Role – This query identifies when a new Privileged role is assigned to a user or when any account eligible for a role is given privileged access.
- Near Real-Time (NRT) rule – User added to Azure Active Directory Privileged Groups – This query looks for instances when a user is added to any Privileged Group
- Multiple admin membership removals from newly created admin – This query detects when newly created Global admin removes multiple existing global admins which can be an attempt by adversaries to lock down the organization and retain sole access.
Microsoft Sentinel + Okta logs hunting queries
- Admin privilege granted (Okta) – This query searches for successful grant of administrator permissions to user/groups. Adversaries often attempt to assign administrator permission to users/group to maintain access as well as to elevate privileges.
- Create API Token (Okta) – This query searches for attempts to create a new API Token. Okta API tokens are used to authenticate requests to Okta APIs.
- Initiate impersonation session (Okta) – This query searches for impersonation events used in LAPSUS$ activity. This query searches for impersonation events used in LAPSUS$ activity. User.session.impersonation are rare events, normally triggered when an Okta Support person requests admin access for troubleshooting.
- Rare MFA Operations (Okta) – Multi-factor authentication (MFA) helps prevent credential compromise. This query searches for rare MFA operations like deactivating, updating, resetting, and attempts to bypass MFA.