Microsoft 365
ProCloud Identity & Email
The identity perimeter most SMBs live behind — routed into your SOC, not Microsoft's.
Microsoft 365 homepage ↗The default identity perimeter for most SMBs. Pulls Entra ID sign-in events, audit log, risky-user signals, mailbox audit — everything Microsoft already tracks, just routed into your sovereign SOC instead of Microsoft's.
What it watches
- Entra ID sign-ins — impossible travel, new-country, legacy-auth, MFA fatigue
- Risky-user + risky-sign-in signals from Identity Protection
- Mailbox audit — auto-forward rules, mass-delete, delegate adds
- Admin actions — role grants, app consents, conditional-access changes
- OAuth-app + token activity (consent phishing)
MITRE ATT&CK coverage
Tactics this connector gives CyberCLI visibility into.
Every alert this connector surfaces
4 event types
Every matrix-covered event_type on the passthrough lane — pinned by the engine's coverage matrix.
The right column shows the operator-friendly phrase the dashboard renders. High-severity
AI-lane signals are summarized in What it watches above (Warden + Herald
handle those); the rest take the substrate's passthrough lane (no AI tokens burned).
| event_type | dashboard renders |
|---|---|
| 3002.0001 | Authentication failed on m365 |
| 3004 | Directory audit on m365 |
| 3004.0001 | Directory audit on m365 |
| 1001.0001 | Security finding on m365 |
What it helps you catch
What you'd see in CyberCLI
illustrativeImpossible-travel sign-in + new inbox forwarding rule
- user
- cfo@acme.com
- from
- Lagos, NG
- prior
- Austin, TX · 22m ago
- rule
- auto-forward → external
Routed to Warden (triage) → Knight (detection) → Marshal (response) → Paladin (containment) → Herald (notify)
Suggested Revoke sessions · disable rule (needs approval)
⛓ every step hash-chained · replayable
What CyberCLI reads from Microsoft 365
audit our mathM365 is the identity plane — every Entra ID sign-in, every directory audit action, every Defender alert is a CyberCLI-relevant event. We pull the Graph API + Defender alerts v2 schema: who signed in, from where (IP, country, device, app), how (interactive vs service principal vs token refresh), what the conditional-access policy said, and which directory roles changed. Defender alerts arrive with full kill-chain context.
Event categories we parse
- Alerts v2 defender alert alerts_v2_defender_alert.json
Defender for Identity / Defender for Cloud Apps alert with mapped MITRE technique, evidence, and recommended action.
- Directory audit role change directory_audit_role_change.json
Role assignment change in Entra ID. Carries actor, target, role granted, and whether it's a permanent or eligible PIM assignment.
- Signin interactive failed signin_interactive_failed.json
Failed interactive sign-in — carries IP, user, app, location, failure reason, conditional-access policy decision.
- Signin service principal signin_service_principal.json
Service-principal sign-ins (app-only tokens). Carries app ID, tenant, IP, scopes — the surface most attackers target post-compromise.
Sample event · Alerts v2 defender alert ↓
{
"id": "ad399f7a-91ee-4f9b-a8fa-2c4f8e9c3d72",
"providerAlertId": "da637854...",
"createdDateTime": "2026-05-12T13:20:00.000Z",
"title": "Suspicious sign-in activity",
"category": "InitialAccess",
"severity": "high",
"status": "new",
"classification": "unknown",
"determination": "unknown",
"serviceSource": "microsoftDefenderForCloudApps",
"detectionSource": "mcas",
"productName": "Microsoft Defender for Cloud Apps",
"tenantId": "00000000-0000-0000-0000-000000000099",
"description": "Impossible travel detected for chris@example.com between IS and US within 1 hour.",
"mitreTechniques": [
"T1078"
],
"threatDisplayName": null,
"threatFamilyName": null,
"evidence": [
{
"@odata.type": "#microsoft.graph.security.userEvidence",
"userAccount": {
"userPrincipalName": "chris@example.com",
"displayName": "Chris Test"
}
},
{
"@odata.type": "#microsoft.graph.security.ipEvidence",
"ipAddress": "203.0.113.42",
"countryLetterCode": "IS"
}
]
}MITRE techniques typically mapped
- T1078.004 ↗
Valid Accounts: Cloud AccountsInitial Access · Persistence
- T1110 ↗
Brute ForceCredential Access
- T1098.001 ↗
Account Manipulation: Cloud CredentialsPersistence
- T1556.006 ↗
MFA Request GenerationCredential Access
- T1486 ↗
Data Encrypted for ImpactImpact
Trust Ladder ceiling · L0 → L4
- ·L0–L2: digest the sign-in / audit event · notify · summarize the alert chain
- ·L3 (Knight verification): correlate with prior sign-ins, geo-IP, device-compliance state — read-only Graph queries
- ·L4 (Paladin containment, Pro+): user disable via m365.disable_user · sign-in session revoke via m365.revoke_sign_in_sessions
- ·L5+: role revocation, conditional-access policy changes, tenant-wide enforcement
- ·Any action affecting break-glass or service accounts
Full ladder semantics · /trust →
Field count + sample event auto-derived from src/cybercli/connectors/microsoft365/vector.vrl at build time. Numbers update the moment the engine's parser changes — no drift.
Close more of the kill chain
Microsoft 365 covers 6 of 14 ATT&CK tactics. Pair it with these to widen coverage:
How to connect
- 1 Create an Entra app registration with Reports.Read.All + AuditLog.Read.All.
- 2 Grant admin consent + generate a client secret (stored in the CyberCLI vault).
- 3 Run `cybercli onboard m365` with the tenant + app credentials.
- 4 Confirm sign-in + audit events flowing in the dashboard's Connectors panel.
Already on M365? Create an Entra app registration with Reports.Read.All → `cybercli onboard m365`
- Warden (triage)
- Knight (detection)
- Marshal (response)
- Paladin (containment)
- Herald (notify)
Hybrid. CyberCLI pulls M365's audit data via Microsoft's API into your local SOC — the data Microsoft already holds, now correlated under your control instead of only theirs.