~/f4n6 $ grep -r "Using Microsoft Graph and Powershell - Risk Detection Commands" ./investigations/ --include="*.md"

Using Microsoft Graph and Powershell - Risk Detection Commands

Jeff Davies 20 Aug 2026 4 min read

1. Executive summary

SANS Internet Storm Center published a Microsoft Graph PowerShell workflow for reviewing Microsoft Entra risky-login detections; it does not report a breach, campaign or confirmed compromise. The workflow exposes derived risk reasons including unfamiliar devices, EAS identifiers and tenant IP subnets, alongside source IP, location and user-agent context. No CVE is identified, and no verified CVSS score, severity or CISA KEV exploitation state is available; no threat actor is named. For EMEA financial services, this is an identity-monitoring opportunity: suspicious authentication activity may remain untriaged if these records are not reviewed, but the signals require validation before account or network enforcement.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

No confirmed attacker chain is described. The source documents the following defender-side collection and triage sequence:

  1. Authenticate to Microsoft Graph. Request the two Identity Protection scopes shown by the source:

powershell Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All", "IdentityRiskEvent.Read.All"

  1. Retrieve risk detections.

powershell $riskylogins = Get-MgRiskDetection -all

  1. Exclude already closed records. The following filter removes detections whose riskState is dismissed or remediated:

powershell $riskylogins = Get-MgRiskDetection -All -Filter "riskState ne 'dismissed' and riskState ne 'remediated'"

  1. Expose triage fields. The source selects userdisplayname, activitydatetime, ipaddress and additionalinfo:

powershell $riskylogins | select userdisplayname, activitydatetime, ipaddress, additionalinfo

  1. Parse risk reasons from JSON. additionalinfo is JSON-formatted and may contain multiple key-value pairs. The demonstrated record contained:
  • riskReasons: UnfamiliarDevice, UnfamiliarEASId, UnfamiliarTenantIPsubnet
  • userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0 AnyConnect/5.1.9.113 (win)
  • mitreTechniques: T1078.004

Array position is not reliable because some records return userAgent rather than riskReasons at the same position. The source therefore locates the required object by its Key:

powershell (($riskylogins[4].additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" }).value

  1. Add location context. The location object already provides city, state and country data. The demonstrated record returned Gunseo-Myeon, Chungcheongbuk-Do and country code KR; country can be extracted with:

powershell ($RiskyLogins[4].location).countryorregion

  1. Produce a reviewable report.

powershell $riskylogins | select userdisplayname, activitydatetime, ipaddress, @{N='Country';e={($_.location.countryorregion)}}, @{N='Reason';E={ ((($_.additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" })).value -join '; '}} | out-gridview

out-gridview can be replaced with ft for text output or out-csv for an Excel-readable export.

The underlying risk logic identifies unexpected IP addresses, subnets, ASNs or countries and unfamiliar devices. The author’s dataset included login attempts geolocated to Malaysia, Colombia and South Korea, plus a client IP associated with Warsaw; no actual IP addresses, users or event timestamps were published, and the source did not establish that these attempts succeeded or were malicious.

The source states that Get-MgRiskDetection is available with a basic Entra licence. Persistent-risk user commands—Get-MgRiskyUser, Confirm-MgRiskyUserCompromised and Get-MgRiskyUserHistory—require a higher licence, but the tier is not specified.

No exploited component, CVE, payload, persistence, privilege escalation, command-and-control, lateral movement, data access, exfiltration or operational impact is reported. Consequently, no verified CVSS severity or CISA KEV exploitation state applies. All technical observations originate from one SANS ISC diary and are single-sourced; verify before enforcement.

4. Mitigation & containment

No patch, affected version, registry change or vendor fix applies because this is defensive query guidance rather than a vulnerability disclosure.

P1 — within 24 hours

  • Run the source-provided query for detections not marked dismissed or remediated.
  • Preserve userdisplayname, activitydatetime, ipaddress, location, additionalinfo and the full user-agent value during triage.
  • Validate unexpected geography and device context before taking enforcement action. These are derived risk signals, not proof of compromise.
  • If activity is independently confirmed as unauthorised, invoke the client’s established identity-containment procedure to block or disable the affected account. The source provides no tenant-specific disablement, session-revocation or IP-blocking command.

P2 — within 72 hours

  • Implement the key-based riskReasons extraction shown above. Do not assume that the required object is always the first entry in additionalinfo.
  • Include location.countryorregion in reports and retain the original IP address for investigation.
  • Export active detections through out-gridview, ft or out-csv, then track analyst disposition separately from the raw record.
  • Test the Sigma logic in §6 against locally retained Get-MgRiskDetection output before enabling automated alerting.

P3 — within 7 days

  • Establish a recurring review cadence for unresolved risk detections.
  • Assess whether persistent-risk-user handling is required and whether the necessary licence is available before adopting Get-MgRiskyUser, Confirm-MgRiskyUserCompromised or Get-MgRiskyUserHistory.
  • Document when analysts may mark records dismissed or remediated; do not close records solely because the geography or device can be plausibly explained.

5. Indicators of compromise

No indicators of compromise available in the source material.

Behavioural indicators

The following observations are single-sourced; verify before enforcement.

behaviour where to observe confidence
riskReasons contains UnfamiliarDevice, UnfamiliarEASId or UnfamiliarTenantIPsubnet additionalinfo within Get-MgRiskDetection output High confidence that these values occurred in the example; low confidence of compromise without contextual validation
Login context is unexpected for the IP address, subnet, ASN or country ipaddress, location and activitydatetime fields Context-dependent; not independently malicious
Example record carries mitreTechniques value T1078.004 Parsed additionalinfo JSON Example-only; the source does not establish successful account compromise

6. Detection

A YARA rule is not appropriate: the source provides no malicious file content or threat artefact. The PowerShell commands are defensive administration commands and must not be treated as malware strings.

The following Sigma rule applies to retained or normalised Get-MgRiskDetection records. Local field mapping may be required because additionalinfo is JSON-formatted.

title: Using Microsoft Graph and Powershell - Risk Detection Commands
author: Adverse Trace
date: 2026-08-20
references:

  - https://isc.sans.edu/diary/rss/33266
description: Detects unresolved Microsoft Graph risk-detection records containing the demonstrated riskReasons values.
logsource:
  definition: Microsoft Graph Get-MgRiskDetection output retaining additionalinfo and riskState
detection:
  selection_key:
    additionalinfo|contains: 'riskReasons'
  selection_value:
    additionalinfo|contains:

      - 'UnfamiliarDevice'
      - 'UnfamiliarEASId'
      - 'UnfamiliarTenantIPsubnet'
  filter_closed:
    riskState:

      - 'dismissed'
      - 'remediated'
  condition: selection_key and selection_value and not filter_closed

This is a triage rule, not a compromise verdict. Test it against local record structure before enforcement.

7. Sources

  • SANS Internet Storm Center, “Using Microsoft Graph and Powershell - Risk Detection Commands,” 20 August 2026 — https://isc.sans.edu/diary/rss/33266

8. Adverse Trace position

Adverse Trace assesses this as defensive identity-detection guidance, not evidence of an active incident or vulnerability. No CVE, verified CVSS severity or CISA KEV exploitation state is available, and no actor attribution is present. Client impact depends on whether tenant review identifies unauthorised authentication activity; the supplied examples and behavioural signals are single-sourced; verify before enforcement. Adverse Trace recommends implementing and testing the unresolved-risk query and will monitor for corroborating campaign reporting or actionable atomic indicators.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies