Defensive Hardening and Log Analysis
Defenders must move beyond legacy authentication paradigms to counter automated token-theft toolkits. Standard hardening measures should be deployed across Microsoft Entra ID and connected identity systems to neutralize the core vectors utilized by Jalisco and OmegaLord.
Microsoft Entra ID Hardening Policies
First, organizations should restrict or disable the device code authentication flow. This can be achieved by writing a Microsoft Entra Conditional Access policy that blocks device code flows for all users and all cloud applications. Exceptions should be tightly controlled and restricted solely to verified service accounts with documented requirements. Second, administrators must reduce the default Entra ID device registration limit. By default, Microsoft Entra ID allows a single user to register up to 50 devices. Reducing this limit to one or two significantly hinders an attacker’s capacity to establish multiple persistent rogue endpoints.
Furthermore, organizations must transition away from telephonic authentication, such as SMS or voice codes, which OmegaLord is designed to exploit. Transitioning to phishing-resistant authentication methods, such as FIDO2 security keys or Windows Hello for Business, prevents these kits from successfully intercepting the credentials needed to gain access. Regular testing of these authentication configurations is critical. Utilizing expert Penetration Testing services can help validate that your identity provider policies are correctly configured and resilient to advanced adversary-in-the-middle attacks.
KQL Detection Signatures
Security teams can deploy the following Kusto Query Language (KQL) detections within Microsoft Sentinel or advanced hunting environments to identify signs of Jalisco or OmegaLord activity.
To monitor Sign-In logs for successful authentications that rely on the Device Code flow, utilize this query:
SigninLogs
| where AuthenticationProtocol == 'deviceCode'
| where ResultType == 0
| summarize Count=count() by UserPrincipalName, IPAddress, Location, ClientAppUsed, OperatingSystem=DeviceDetail.operatingSystem
| order by Count desc
To identify instances where a new device enrollment occurs in close temporal proximity to a successful sign-in, deploy this correlation query:
let anomalous_signin = SigninLogs
| where ResultType == 0
| project SigninTime = TimeGenerated, UserPrincipalName, IPAddress, Location;
AuditLogs
| where OperationName == 'Register device'
| project RegistrationTime = TimeGenerated, UserPrincipalName = tostring(TargetResources[0].userPrincipalName), DeviceName = tostring(TargetResources[0].displayName)
| join kind=inner anomalous_signin on UserPrincipalName
| where RegistrationTime between (SigninTime .. (SigninTime + 30m))
| project RegistrationTime, UserPrincipalName, DeviceName, IPAddress, Location
To sweep your tenant specifically for rogue device registrations that attempt to masquerade as trusted vendor endpoints, use this detection:
AuditLogs
| where OperationName == 'Register device'
| extend DeviceName = tostring(TargetResources[0].displayName)
| where DeviceName i_contains 'microsoft' or DeviceName i_contains 'windows'
| project TimeGenerated, InitiatedBy=Identity, DeviceName, Result