
Lacey Cochrane
@NullVectorXUSTrusted contributorCompletionist
11 followers143 downloads2,343 copies55 likes67,608 views
232 detections
Filters
Last updated
All Time
Detection languages
232
Categories
66
60
54
27
26
Platforms
81
53
36
26
22
Products / Services
30
26
23
21
19
MITRE Techniques
77
68
45
42
40
CVEs
4
4
This rule detects authentication attempts to Microsoft 365 Azure AD from a list of known malicious IP addresses and CIDR ranges associated with the EvilToken phishing campaign. It specifically filters for 'Cmsi:Cmsi' request types, which are indicative of session replay signals used in device code phishing.
Detects suspicious sharing activity in Box, including the creation of open links, external collaboration invites, role escalation, and weakening of sharing policies. This rule identifies high-risk activities such as making files publicly visible without password protection, inviting external users with co-owner or editor roles, and changes that reduce security like removing expiration dates on shared links.
This rule detects DNS queries to known malicious domains associated with the Tycoon2FA phishing campaign. These domains are used for anti-bot verification during the attack chain, which typically involves hijacking Microsoft 365 accounts via device code phishing.
Azure VM RunCommand Activity
Cortex XDR
This rule detects activity related to Azure VM RunCommand, which allows execution of scripts on virtual machines without requiring RDP/SSH access. It specifically looks for 'WRITE', 'ACTION', 'DELETE', and 'READ' operations, filtering for successful or accepted statuses and valid identities. This activity can indicate an attacker executing commands or performing post-execution cleanup.
Tycoon2FA Known Infrastructure Detection
Cortex XDR
This rule detects suspicious sign-in attempts to Microsoft 365 accounts that originate from known Tycoon2FA infrastructure. It specifically looks for device code flow authentications from IP addresses and Autonomous System Numbers (ASNs) associated with Tycoon2FA, combined with indicators like unmanaged/non-compliant devices, specific user agent patterns (axios, node, undici), and particular application IDs, and an unbound sign-in token protection status. This combination of indicators suggests an attempt to hijack Microsoft 365 accounts using device code phishing.
Tycoon2FA PHaaS User Agent Detection
Cortex XDR
Detects user agents associated with Tycoon2FA phishing-as-a-service (PHaaS) campaigns, specifically targeting Microsoft 365 accounts via device code phishing. The rule identifies user agents like 'axios/1.13.x' (credential relay variant) and 'node' or 'undici' (device code variant) in Azure AD sign-in logs where the original transfer method is 'deviceCodeFlow', and the device is neither managed nor compliant, and the sign-in token protection status is unbound.
This rule tracks user and administrator submissions of potential phishing emails to Microsoft for analysis within the Security & Compliance Center. It extracts and logs details such as the submission verdict, rescan verdict, recipients, subject, content, submitter's display name, sender information (P1 and P2), email destination, final delivery verdict, and sender IP address. This provides visibility into an organization's proactive efforts to report and analyze suspected phishing attempts.
Okta Sensitive OAuth Activity Detection
Cortex XDR
This rule detects sensitive OAuth activities within Okta, specifically focusing on OAuth client secret access, token revocation requests, and implicit flow requests. These activities can indicate potential compromise of OAuth clients, attempts to invalidate legitimate tokens, or the use of less secure OAuth flows that could be exploited.
Detects when users are added to groups or applications within Okta, which could potentially grant them elevated privileges. This rule monitors for events indicating changes in user membership for both groups and applications.
Detects Okta Multi-Factor Authentication (MFA) factor enrollment, activation, update, and reset events. These events may indicate an attacker adding their own MFA factor post-compromise to maintain access or removing an existing factor to weaken account security and facilitate unauthorized access.
Page 16 of 24
