Added more rules and triage guides gear towards microsoft environment

Author: aring87

content/triage-guides/sentinel/collection/graph-mail-search-keyword-burst.md

@@ -0,0 +1,54 @@
+# Quick Assist Followed by Batch or PowerShell Execution
+
+## Goal
+Identify suspicious use of Quick Assist followed by batch or PowerShell execution, which may indicate social-engineering-driven remote access abuse.
+
+## Why This Alert Matters
+Quick Assist is a legitimate Microsoft support tool, but it is increasingly abused by attackers posing as helpdesk or IT support. Script execution after the session starts is a strong sign that the session may be malicious.
+
+## What the Detection Is Looking For
+This detection looks for:
+- Quick Assist execution
+- followed by batch script or PowerShell activity
+- with suspicious command-line indicators
+
+## Initial Triage Questions
+1. Did the user request support?
+2. Was Quick Assist approved or expected?
+3. What script or batch file executed afterward?
+4. Did the session lead to downloads, persistence, or credential abuse?
+
+## Key Evidence To Review
+- Quick Assist process start
+- follow-on script command lines
+- helpdesk records
+- downloaded files
+- persistence and remote tool activity
+
+## Investigation Steps
+1. Confirm whether the Quick Assist session was legitimate.
+2. Review the batch or PowerShell command launched after the session.
+3. Determine whether the command downloaded content or altered the system.
+4. Check for RMM installation, persistence, or credential access after the session.
+5. Validate the user story and whether the operator claimed to be support.
+
+## Common Benign Explanations
+- legitimate IT remediation
+- approved remote support
+- scripted support diagnostics
+
+## Escalate When
+Escalate if:
+- the user did not request help
+- the script is suspicious or obfuscated
+- malicious downloads or persistence follow
+- the activity aligns with known social-engineering patterns
+
+## Suggested Response Actions
+- terminate the session
+- isolate the endpoint if compromise is suspected
+- preserve scripts and command lines
+- review other endpoints for similar Quick Assist chains
+
+## Analyst Notes
+This should be treated seriously when Quick Assist is not common in your environment.

content/triage-guides/sentinel/command-and-control/quick-assist-followed-by-batch-or-powershell.md

@@ -0,0 +1,54 @@
+# OAuth Redirection Abuse Followed by Browser Download
+
+## Goal
+Identify suspicious OAuth phishing links that are followed by browser-driven download or payload execution.
+
+## Why This Alert Matters
+This pattern suggests the user clicked a Microsoft-branded auth link and was then redirected into malware delivery or scripted execution. It bridges phishing into endpoint compromise.
+
+## What the Detection Is Looking For
+This detection looks for:
+- suspicious OAuth authorization URL click activity
+- followed by browser-related download or execution
+- using installers or LOLBins
+
+## Initial Triage Questions
+1. What file or payload was downloaded?
+2. Was the user redirected to an attacker-controlled site?
+3. Did the payload launch through a browser, installer, or script host?
+4. Did the user report seeing a fake Microsoft auth page?
+
+## Key Evidence To Review
+- clicked URL and redirect chain
+- endpoint process creation
+- browser download history
+- downloaded file names and hashes
+- process ancestry and execution timing
+
+## Investigation Steps
+1. Review the clicked OAuth link and determine final destination.
+2. Identify what was downloaded or launched.
+3. Check whether the payload executed via PowerShell, CMD, MSHTA, MSIExec, or Rundll32.
+4. Determine whether the user was prompted to approve anything or just click through.
+5. Review for persistence, RMM, credential theft, or exfiltration after execution.
+
+## Common Benign Explanations
+- legitimate software downloads after SSO-based login
+- testing by developers or IT
+- approved installers launched after portal sign-in
+
+## Escalate When
+Escalate if:
+- the redirect target is malicious or suspicious
+- payload execution follows quickly
+- obfuscated or download-heavy command lines appear
+- additional malicious behaviors are detected
+
+## Suggested Response Actions
+- isolate the endpoint if execution occurred
+- collect the downloaded file and command line evidence
+- review all other recipients of the same message
+- block related URLs and payload indicators
+
+## Analyst Notes
+This is a strong cross-domain detection because it correlates mail/browser activity with endpoint execution.

content/triage-guides/sentinel/credential_access/device-code-phishing-followed-by-graph-mail-access.md

@@ -0,0 +1,54 @@
+# SharePoint or OneDrive Bulk Download by Newly Risky User
+
+## Goal
+Identify high-volume SharePoint or OneDrive download activity performed by a user who recently showed risky sign-in behavior.
+
+## Why This Alert Matters
+After account compromise, attackers often collect documents from SharePoint or OneDrive. Bulk download by a newly risky user can indicate cloud collection or exfiltration.
+
+## What the Detection Is Looking For
+This detection looks for:
+- a recent risky or device-code-related successful sign-in
+- followed by high-volume SharePoint or OneDrive download activity
+- by the same user within a short time window
+
+## Initial Triage Questions
+1. Was the sign-in suspicious or expected?
+2. Is the download volume normal for the user?
+3. What sites, folders, or files were involved?
+4. Did the user also access mail, create rules, or grant consent?
+
+## Key Evidence To Review
+- risky sign-in timing and source
+- download count
+- site URLs
+- object IDs or file names
+- related mailbox, app, or forwarding activity
+
+## Investigation Steps
+1. Review the risky sign-in and determine whether it was expected.
+2. Assess whether the download volume is unusual for the user.
+3. Identify which SharePoint or OneDrive locations were accessed.
+4. Determine whether the data appears sensitive or high-value.
+5. Check for related mail compromise, consent abuse, or public-sharing changes.
+
+## Common Benign Explanations
+- planned migration or sync
+- legitimate bulk download by project or admin staff
+- new-device sync behavior
+
+## Escalate When
+Escalate if:
+- the sign-in is suspicious and recent
+- the download volume is unusual
+- the sites contain sensitive documents
+- the user also shows mailbox or app abuse
+
+## Suggested Response Actions
+- revoke sessions and review the account
+- preserve cloud access records
+- notify data owners for affected sites
+- investigate whether files were later shared or exported elsewhere
+
+## Analyst Notes
+This is a strong cloud exfiltration signal when paired with risky sign-in or device code activity.

content/triage-guides/sentinel/execution/oauth-redirection-abuse-followed-by-browser-download.md

@@ -0,0 +1,55 @@
+# Device Code Sign-In Followed by Device Registration
+
+## Goal
+Identify suspicious device code authentication followed by registration of a new device, which may indicate attacker-controlled device enrollment and token abuse.
+
+## Why This Alert Matters
+Device code phishing can allow an attacker to obtain access tokens without stealing a password directly. If that access is then used to register a new device, it may support long-term access, token persistence, or Privileged Refresh Token-related abuse.
+
+## What the Detection Is Looking For
+This detection looks for:
+- a successful device code sign-in
+- followed within a short time window by a device registration event
+- for the same user
+
+## Initial Triage Questions
+1. Did the user expect a device code login prompt?
+2. Is the newly registered device known and corporate-managed?
+3. Did the sign-in originate from an unusual IP, geography, or proxy?
+4. Was there follow-on access to email, files, Teams, or cloud apps?
+
+## Key Evidence To Review
+- user UPN
+- device code sign-in time
+- source IP address
+- app used during the sign-in
+- registered device name and object ID
+- later sign-ins from the new device
+
+## Investigation Steps
+1. Confirm the device code sign-in was successful and review its source context.
+2. Validate the newly registered device with the user, endpoint team, or asset inventory.
+3. Check whether the device is managed, compliant, and expected.
+4. Review follow-on cloud activity such as Graph, mailbox, OneDrive, SharePoint, or Teams access.
+5. Look for related OAuth consent, inbox rule creation, or risky sign-ins.
+
+## Common Benign Explanations
+- approved device enrollment
+- legitimate user setup of a new corporate device
+- IT-guided onboarding workflows
+
+## Escalate When
+Escalate if:
+- the user denies the device code login
+- the device is unknown or unmanaged
+- the source IP is suspicious
+- follow-on access to mail, files, or Teams occurs unexpectedly
+
+## Suggested Response Actions
+- revoke active sessions and refresh tokens
+- disable or remove the suspicious device registration if confirmed malicious
+- require credential reset and MFA review
+- investigate nearby mailbox, file, and Teams activity
+
+## Analyst Notes
+This is a high-priority identity alert because it can indicate an attacker moved from phishing to durable cloud access.

content/triage-guides/sentinel/exfiltration/sharepoint-or-onedrive-bulk-download-by-newly-risky-user.md

@@ -0,0 +1,57 @@
+# OAuth Redirection Abuse URL Click
+
+## Goal
+Identify phishing clicks involving suspicious Microsoft OAuth authorization links that may redirect users into attacker-controlled workflows.
+
+## Why This Alert Matters
+OAuth authorization links can appear legitimate to users because they reference trusted Microsoft domains. Attackers abuse redirection parameters and prompt handling to deliver phishing, auth abuse, or malware.
+
+## What the Detection Is Looking For
+This detection looks for:
+- URL clicks involving Microsoft OAuth authorize paths
+- suspicious parameters such as:
+  - redirect URI manipulation
+  - prompt suppression
+  - unusual scope behavior
+
+## Initial Triage Questions
+1. What message or lure caused the click?
+2. Did the link redirect to a non-Microsoft destination?
+3. Was the user prompted to sign in, authorize, or download something?
+4. Did the click lead to risky sign-ins or endpoint activity?
+
+## Key Evidence To Review
+- full clicked URL
+- full URL chain
+- email subject and sender
+- recipient user
+- redirect target
+- nearby sign-ins or browser downloads
+
+## Investigation Steps
+1. Review the clicked URL and its parameters.
+2. Trace the full redirect path to see where the user landed.
+3. Determine whether the email used a lure such as e-signature, secure message, voicemail, or collaboration invite.
+4. Check for device code sign-ins, risky logins, or follow-on endpoint execution.
+5. Determine whether the same URL was clicked by multiple users.
+
+## Common Benign Explanations
+- rare developer testing
+- internal OAuth troubleshooting
+- benign application login workflows
+
+## Escalate When
+Escalate if:
+- the redirect target is suspicious
+- the user entered credentials or approved access
+- endpoint execution followed the click
+- multiple users were targeted
+
+## Suggested Response Actions
+- block the URL/domain if malicious
+- identify all recipients and clickers
+- review sign-ins and endpoint activity for impacted users
+- notify email security and IR teams
+
+## Analyst Notes
+This is primarily a delivery-stage alert and should be correlated with identity and endpoint activity.

content/triage-guides/sentinel/initial-access/device-code-sign-in-followed-by-device-registration.md

@@ -0,0 +1,54 @@
+# Teams External Contact Followed by Quick Assist
+
+## Goal
+Identify possible social-engineering chains in which external Teams contact or chat activity is followed by Quick Assist execution.
+
+## Why This Alert Matters
+Attackers may use Teams to impersonate IT or support staff, then move the user into Quick Assist for hands-on-keyboard access. This pattern is especially relevant in Microsoft-centric environments.
+
+## What the Detection Is Looking For
+This detection looks for:
+- external or guest Teams contact activity
+- followed within a short time window by Quick Assist usage
+- for the same user
+
+## Initial Triage Questions
+1. Was the Teams contact internal, guest, or external?
+2. Did the external party claim to be support or IT?
+3. Did the user then accept a Quick Assist session?
+4. Were scripts, tools, or downloads launched afterward?
+
+## Key Evidence To Review
+- Teams operation type
+- external/guest indicators
+- Quick Assist timing
+- user account and endpoint
+- follow-on endpoint activity
+
+## Investigation Steps
+1. Review the Teams contact and whether it was external or guest-originated.
+2. Determine whether the user was coached into accepting remote help.
+3. Review Quick Assist execution on the endpoint.
+4. Check for PowerShell, batch, RMM, or download activity after the session started.
+5. Validate with the user what instructions they received.
+
+## Common Benign Explanations
+- approved external collaboration
+- legitimate support interactions
+- vendor troubleshooting through federated Teams workflows
+
+## Escalate When
+Escalate if:
+- the external contact is suspicious or unknown
+- the user was convinced to accept remote access
+- follow-on script or payload activity occurred
+- similar events affected multiple users
+
+## Suggested Response Actions
+- notify messaging/collaboration admins
+- preserve Teams interaction evidence
+- isolate affected hosts if malicious activity followed
+- review external chat histories for wider targeting
+
+## Analyst Notes
+This is best tuned in environments with frequent external Teams collaboration.

content/triage-guides/sentinel/initial-access/oauth-redirection-abuse-url-click.md

@@ -0,0 +1,54 @@
+# New App Secret Added Then Service Principal Sign-In
+
+## Goal
+Identify cases where a new application credential is added and then the service principal signs in shortly afterward.
+
+## Why This Alert Matters
+This can indicate rapid operationalization of a cloud application after credential creation. In a malicious scenario, an attacker adds a secret to a compromised or newly created app and immediately begins using it.
+
+## What the Detection Is Looking For
+This detection looks for:
+- app secret or key credential creation
+- followed within hours by service principal sign-in
+- using the same application identity
+
+## Initial Triage Questions
+1. Was the secret addition approved?
+2. Who added the credential?
+3. Was the app newly created or recently modified?
+4. What resources did the service principal access afterward?
+
+## Key Evidence To Review
+- app name
+- app owner and initiator
+- secret addition event
+- service principal sign-in timing
+- target resources accessed after sign-in
+
+## Investigation Steps
+1. Validate whether the app is known and managed.
+2. Review who added the secret or key credential.
+3. Check what the service principal accessed shortly after sign-in.
+4. Determine whether the app has broad or high-risk permissions.
+5. Correlate with suspicious consent, mailbox access, SharePoint activity, or unusual cloud administration.
+
+## Common Benign Explanations
+- approved app onboarding
+- secret rotation
+- cloud engineering maintenance
+
+## Escalate When
+Escalate if:
+- the app is unknown or newly created unexpectedly
+- the credential was added by an unexpected user
+- the service principal immediately accessed sensitive resources
+- the app overlaps with consent-phishing or mail/file access detections
+
+## Suggested Response Actions
+- disable or restrict the app if malicious
+- remove the newly added credential
+- review service principal access scope
+- notify cloud identity owners and IR
+
+## Analyst Notes
+This is one of the strongest cloud control-plane detections when timing is tight and access begins immediately.