Christopher Scott
@ScochaNewcastle upon TyneCompletionist
0 followers20 downloads229 copies7 likes1,247 views
54 detections
Filters
Last updated
All Time
Detection languages
33
20
1
Categories
22
22
9
8
7
Platforms
27
17
7
2
2
Products / Services
21
10
7
5
4
MITRE Techniques
20
12
6
6
6
Five or more service account keys created by the same principal inside a 1 hour time bucket, indicating potential mass credential generation.
This rule detects when a user (excluding service accounts) explicitly sets IAM permissions on a Google Cloud Storage bucket, potentially indicating unauthorized privilege escalation or modification of access controls to facilitate data exfiltration or persistence.
This rule detects unsuccessful attempts by human users to delete objects from Google Cloud Storage buckets that are protected by bucket-level retention policies. By filtering out service accounts, the rule specifically focuses on non-automated, human-initiated actions that violate data retention requirements.
This rule detects instances where a Google Cloud Platform (GCP) identity attempts to grant themselves highly privileged IAM roles at the project level. It monitors 'SetIamPolicy' events in GCP audit logs, filtering for activities where the actor (user) is included in the set of members receiving high-privilege roles such as owner, editor, or various administrative roles (e.g., storage.admin, compute.admin).
This rule detects potential credential abuse by monitoring for a burst of GCP access or ID token generation requests by a single user across five or more distinct resource targets within a single project. Such behavior is often indicative of an adversary enumerating resources or performing reconnaissance to identify reachable services or systems after successfully assuming a principal's identity.
Detects the creation or update of IAM custom roles in Google Cloud Platform. This activity can be indicative of privilege escalation or the establishment of persistence by an adversary modifying access controls.
A VPC network created or deleted, enriched with actor type and whether the change came via Terraform.
Detects the execution of suspicious commands, PowerShell scripts, or LOLBins (Living-off-the-Land Binaries) - commonly seen in ClickFix and CrashFix campaigns - recorded in the Windows 'RunMRU' registry key.
This rule detects suspicious activity on high blast radius accounts, specifically correlating failed authentication attempts, password resets, and successful logons outside business hours.
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
The detection looks for Entra ID sign-in events where both the source country and user agent string are new for the authenticating account(e.g., neither value has been seen during the 14-day training window (days 14–2 prior to now)). This can be changed easily in the let variable
The double signal requirement is intentional. A new country alone is relatively common (VPN usage, business travel, Microsoft service IPs), and a new user agent alone is low signal (browser updates, new devices). Requiring both to be new on the same sign-in increases fidelity, while still capturing the pattern typically associated with credential compromise or account takeover.
Sign-in events are collapsed to a single row per user per country, with EventStartTime and EventEndTime showing the first and last sign-in seen within the defined detection window.
A dynamic risk score is applied on top of the core detection to drive alert severity so you can set noise for your environment to 'informational' and reduce SOC alert fatigue.
Set the `HighRiskCountries` array to suit your risk profile
The double signal requirement is intentional. A new country alone is relatively common (VPN usage, business travel, Microsoft service IPs), and a new user agent alone is low signal (browser updates, new devices). Requiring both to be new on the same sign-in increases fidelity, while still capturing the pattern typically associated with credential compromise or account takeover.
Sign-in events are collapsed to a single row per user per country, with EventStartTime and EventEndTime showing the first and last sign-in seen within the defined detection window.
A dynamic risk score is applied on top of the core detection to drive alert severity so you can set noise for your environment to 'informational' and reduce SOC alert fatigue.
Set the `HighRiskCountries` array to suit your risk profile
Page 5 of 6