The Midnight OAuth

Solution walkthrough

Q1: Application legitimacy. The application “DocuSign Integration Service” is NOT the legitimate DocuSign application. Evidence: the AppId does not match DocuSign’s known registered application IDs. The publisher is unverified. The application was registered in an external tenant within the last 7 days. The legitimate DocuSign application is publisher-verified and has a well-known AppId. This is a social engineering attack — the attacker named their application to mimic a trusted brand.

Q2: Risk score. Mail.ReadWrite = 3 (Critical). Files.Read.All = 3 (Critical). User.Read = 0 (Low). Bulk consent (4 users in 90 min) = +4. Non-corporate IP = +1. Total: 11 (High — investigate immediately). Mail.ReadWrite is the highest concern: it grants the application the ability to read AND modify email — including deleting evidence of the phishing campaign.

Q3: IP analysis. Both IPs (198.51.100.44 and 198.51.100.51) are in the same /24 range, suggesting shared hosting infrastructure. Query the ASN: they belong to a cloud hosting provider, not a legitimate corporate network. The attacker used two IPs from the same provider — likely two VPS instances.

Q4: Phishing email. An email with subject “Action Required: Authorise DocuSign Integration” was sent from noreply@docusign-integration-service.com — a lookalike domain. The email directed users to a legitimate Microsoft consent prompt URL with the attacker’s application pre-loaded.

Q5: Campaign scope. The email was sent to 12 users across Finance, IT, and Engineering. 4 consented (the alert). 8 received but did not consent. 0 were blocked by email protection (the email contained a legitimate microsoft.com URL, so Safe Links did not flag it).

Q6-7: Data exposure. The application authenticated immediately after each consent. Exchange Online was accessed for all 4 users. j.morrison (Finance): 127 emails accessed. a.patel (Accounts Payable): 94 emails accessed. s.chen (IT): 43 emails accessed. r.williams (Engineering): 31 emails accessed. No SharePoint files were accessed (Files.Read.All permission was granted but not yet used).

Q8: Containment sequence. 1) Delete the enterprise application (immediately stops all application access for all 4 users — single action, maximum impact). 2) Block the phishing sender domain (prevents additional waves). 3) Reset passwords (the consent was not credential-based, but reset as precaution). 4) Revoke tokens (in case the attacker also captured credentials). 5) Notify users (after containment is complete — not before, to avoid alerting the attacker if any user forwards the notification). Order matters: deleting the application is the single action that revokes ALL OAuth access immediately. Password reset and token revocation address potential credential compromise. Notification comes last.

Q9: Detection rule.

1
2
3
4
5
6
7
8
9

// Consent from non-corporate IP with high-risk permissions
AuditLogs
| where OperationName == "Consent to application"
| where Result == "success"
| extend ConsentUser = tostring(InitiatedBy.user.userPrincipalName)
| extend IPAddress = tostring(InitiatedBy.user.ipAddress)
| extend Permissions = tostring(TargetResources[0].modifiedProperties)
| where IPAddress !in (_GetWatchlist('CorporateExternalIPs') | project SearchKey)
| where Permissions has_any ("Mail.ReadWrite", "Mail.Send", "Files.ReadWrite.All")

Q10: Executive summary. “On 8 April 2026, four Northgate Engineering employees consented to a malicious OAuth application disguised as a DocuSign integration, granting it access to read and modify their email. The application was delivered via a phishing email targeting 12 users across Finance, IT, and Engineering. The application accessed approximately 295 emails before detection and revocation. No financial fraud or data exfiltration has been confirmed. The application has been deleted, affected users notified, and a detection rule deployed to prevent recurrence.”