๐ ๐๐ค๐ ๐ผ๐ณ ๐๐ต๐ฒ ๐ช๐ฒ๐ฒ๐ธ | ๐๐๐ป๐๐ถ๐ป๐ด ๐ณ๐ผ๐ฟ ๐ฆ๐๐๐ฝ๐ถ๐ฐ๐ถ๐ผ๐๐ ๐๐น๐ถ๐ฒ๐ป๐ ๐ฆ๐ฒ๐ฐ๐ฟ๐ฒ๐ ๐๐๐๐ต๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป ๐๐๐๐ฒ๐บ๐ฝ๐๐
After a few weeks away, happy to be back in the hunting field, full of energy! ๐๐ฅ
When we talk about compromised identities in Microsoft Entra ID, we usually think about stolen passwords, compromised sessions, MFA bypass techniques, or suspicious user sign-ins. But what happens when the attacker doesnโt need a user account at all?
A recent investigation published by Todyl ๐ describes a campaign where attackers are using stolen application credentials, specifically client secrets, to authenticate against Microsoft Entra ID as legitimate applications.
Get Sergio Albeaโs stories inย yourย inbox
Join Medium for free to get updates fromย thisย writer.
Depending on the permissions assigned to the compromised application, an attacker could potentially access Microsoft Graph, Azure resources, Key Vault, SharePoint, or other services. And in some environments, these applications could have permissions that were granted years ago and havenโt been reviewed since.
Looking for invalid and expired client secrets
As usual, I will not work or mention IOCs (Indicators of Compromise) as the IPs mentioned in the article because they can be easily rotated to new ones so a query would end obsolete. Focus on IOA (Indicators of Attack), one of the hunting opportunities mentioned in the investigation is looking at authentication failures involving application secrets. There are two Entra ID error codes worth checking:
- AADSTS7000215: Invalid client secret.
- AADSTS7000222: Expired client secret.
Of course, these errors are not automatically suspicious. Applications with outdated configurations, forgotten secret rotations, or deployment mistakes can generate exactly the same errors.
Assessing the Risk: Here is the key, more insights, will help to know the risk score for every results with the mentioned Entra ID Error codes. The source IP, the application involved, the frequency of the failures, and whether there are successful authentications from the same IP or involving the same application.
Hunting with KQL in Microsoft Defender XDR
For this hunt, Iโm using two tables:
- EntraIdSignInEvents โ Entra ID sign-in events.
- EntraIdSpnSignInEvents โ Service principal sign-in events.
The idea is simple: search both tables for the two error codes over the last seven days, combine the results, and identify which table each event came from.
let UserSignIns = EntraIdSignInEvents | where Timestamp > ago(7d) | where ErrorCode in (7000215, 7000222) | project Timestamp, SourceTable = "UserSignIns", Application, IPAddress, Country, ErrorCode;
let SpnSignIns = EntraIdSpnSignInEvents | where Timestamp > ago(7d) | where ErrorCode in (7000215, 7000222) | project Timestamp, SourceTable = "ServicePrincipalSignIns", Application, IPAddress, Country, ErrorCode;
union UserSignIns, SpnSignIns
| extend ErrorDescription = case(ErrorCode == 7000215, "Invalid client secret", ErrorCode == 7000222, "Expired client secret", "Other")This is a starting point, not a detection that should immediately generate an incident for every result. I would first review the applications involved, identify unusual source IP addresses, and check whether those same applications or IPs have successful sign-ins around the same period.
If something looks interesting, the next step would be reviewing the applicationโs permissions and the resources accessed after authentication.
One detail worth remembering: Service Principals
Something I wanted to highlight with this query is the importance of including service principals in our identity hunting activities. We spend a lot of time developing detections for regular Entra ID users but if your organization uses service principals, they are also part of your identity environment.
Iโm not suggesting that every detection developed for users should also run against service principals. Their authentication behavior is different, and some detection techniques simply donโt apply. However, when developing a new identity-related detection, itโs worth asking whether service principal activity should also be included.
Anyway, an interesting investigation and a good excuse to review how weโre monitoring application authentication in our environments.
Original research: Todyl โ Stolen App Credentials, Real Access: An Actor Is Signing Into Entra ID and Azure DevOps as Your Workloads
