NovaCookies AitM Phishing Kit Abuses DocuSign to Steal Microsoft 365 Sessions — Detection and Hardening Guide

Security researchers at Island have disclosed a new subscription-based adversary-in-the-middle (AitM) social engineering toolkit called NovaCookies, sold for roughly $320/month, that proxies Microsoft 365 sign-in flows and captures authenticated session cookies in real time. What makes this campaign particularly dangerous is its delivery mechanism: the operators are abusing genuine DocuSign notification infrastructure to deliver lures. The emails aren't spoofed — they ride legitimate DocuSign sending domains and pass SPF, DKIM, and DMARC cleanly, which neutralizes the email authentication stack most organizations rely on as their first line of defense.

This is not a vulnerability in Microsoft 365 or DocuSign. There is no CVE to patch. The attack succeeds because it targets the weakest remaining control in most tenants: phishable authentication factors. Once a victim completes sign-in through the NovaCookies reverse proxy, the attacker holds a valid session token — MFA already satisfied — and can replay it from their own infrastructure to access Exchange Online, SharePoint, and Teams without ever needing the password again.

If your organization uses Microsoft 365 and your users sign DocuSign envelopes (which is to say: nearly everyone), this campaign is in your threat model today. This post breaks down the attack chain and gives your SOC concrete detections and hardening steps.

Technical Analysis

How the NovaCookies Attack Chain Works

NovaCookies follows the now-industrialized AitM reverse-proxy pattern, but with a polished social engineering layer:

1. Lure delivery via genuine DocuSign. The attacker creates a real DocuSign envelope or abuses DocuSign's notification features so that the phishing email originates from actual DocuSign sending infrastructure (docusign.net and related domains). Because the sender is authentic, the message passes email authentication and sails through secure email gateways that trust DocuSign's reputation.

2. Redirect to the AitM proxy. The lure directs the victim to an attacker-controlled domain that mirrors the Microsoft 365 login experience. NovaCookies acts as a transparent reverse proxy between the victim and login.microsoftonline.com — the victim sees the real Microsoft login page, renders real MFA prompts, and completes genuine authentication.

3. Session capture. As authentication completes, the proxy harvests the session cookies (including the token artifacts issued post-MFA). The victim is typically redirected onward to a legitimate destination and never realizes anything happened.

4. Session replay. The operator imports the stolen cookies into their own browser session and accesses the victim's Microsoft 365 environment. From there, typical follow-on activity includes mailbox inbox rule creation for mail hiding/forwarding, OAuth consent grants for persistence, internal phishing pivots, and BEC preparation.

Why This Bypasses Common Defenses

• Email authentication (SPF/DKIM/DMARC): Passes, because the email genuinely comes from DocuSign.
• URL reputation filtering: Newly registered phishing domains have no reputation; the initial hop is a trusted DocuSign URL.
• OTP and push-based MFA: Defeated by design — the proxy relays MFA challenges in real time. This includes Microsoft Authenticator push approvals, SMS codes, and TOTP.

The controls that do stop this class of attack are phishing-resistant authentication (FIDO2/passkeys, certificate-based auth) and Conditional Access token protection / continuous access evaluation, which bind sessions to the device and network context that performed the original authentication.

Exploitation Status

Actively exploited in the wild. NovaCookies is a live, commercially marketed service with observed campaigns. The $320/month price point puts AitM capability — previously associated with kits like Evilginx derivatives and more resourced actors — within reach of low-skill criminals. Expect volume.

Detection & Response

The session theft itself happens on attacker infrastructure, so your strongest telemetry is in Entra ID sign-in logs and Office 365 audit logs. Hunt for the replay: a session token authenticated in one context suddenly being used from an anomalous ASN, impossible-travel patterns, and the post-compromise behaviors (inbox rules, consent grants) that reliably follow.

Sigma Rules

The following rules target Entra ID / Azure sign-in and audit telemetry ingested into your SIEM. Tune the ASN/network baselines for your environment.

---
title: Microsoft 365 Sign-In From High-Risk ASN With Anomalous Session Pattern
id: 3f8a1c24-9d47-4b8e-a6f1-2c5d7e9b0134
status: experimental
description: Detects Microsoft 365 sign-ins from ASNs associated with hosting providers, VPNs, or anonymization services where the user has no prior history, consistent with AitM session cookie replay (e.g., NovaCookies).
references:
  - https://thehackernews.com/2026/08/novacookies-campaigns-abuse-genuine.html
  - https://attack.mitre.org/techniques/T1557/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1557
  - attack.t1557.002
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    properties.status.errorCode: 0
  filter_known_good:
    properties.networkLocationDetails.networkNames|contains:
      - 'Corporate'
      - 'Trusted'
  condition: selection and not filter_known_good
falsepositives:
  - Remote users on consumer ISPs or VPNs (baseline ASNs per user before enabling)
level: medium
---
title: Suspicious Inbox Rule Creation Following Sign-In (Post-AitM Behavior)
id: 8b2d5e91-4c37-4a19-b7f3-6d8e0a2c4517
status: experimental
description: Detects creation of Exchange inbox rules that delete, move, or forward mail to obscure folders, a common post-compromise action after Microsoft 365 session theft via AitM phishing kits.
references:
  - https://thehackernews.com/2026/08/novacookies-campaigns-abuse-genuine.html
  - https://attack.mitre.org/techniques/T1114/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.collection
  - attack.t1114.003
  - attack.persistence
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName:
      - 'New-InboxRule'
      - 'Set-InboxRule'
  selection_suspicious_params:
    properties.targetResources.modifiedProperties.newValue|contains:
      - 'DeleteMessage'
      - 'MoveToFolder'
      - 'ForwardTo'
      - 'RedirectTo'
  condition: selection and selection_suspicious_params
falsepositives:
  - Legitimate user-created mail organization rules (correlate with sign-in anomaly)
level: high

KQL — Microsoft Sentinel / Defender

This two-stage hunt first identifies sign-ins where a successful interactive auth is followed by token use from a different ASN within a short window (the replay signature), then surfaces the classic post-theft inbox rules.

// Stage 1: Potential AitM session replay - auth context vs usage context divergence
let lookback = 14d;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| summarize
    AuthLocations = make_set(Location),
    AuthASNs = make_set(tostring(parse_json(NetworkLocationDetails)[0].networkNames)),
    AuthIPs = make_set(IPAddress),
    AuthCount = count()
    by UserPrincipalName, CorrelationId
| project UserPrincipalName, CorrelationId, AuthLocations, AuthIPs;

// Stage 2: Post-compromise inbox rule creation (hunt across OfficeActivity)
OfficeActivity
| where TimeGenerated > ago(14d)
| where OfficeWorkload == "Exchange"
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend RuleParams = tostring(Parameters)
| where RuleParams has_any ("DeleteMessage", "ForwardTo", "RedirectTo", "MoveToFolder")
| project TimeGenerated, UserId = UserId, Operation, RuleParams, ClientIP = ClientIP
| sort by TimeGenerated desc;

Also hunt DocuSign-abuse delivery at the email layer if you ingest mail flow data:

// Hunt: DocuSign-originated mail containing non-DocuSign redirect links
EmailUrlInfo
| where TimeGenerated > ago(14d)
| join kind=inner (EmailEvents | where SenderFromDomain has "docusign") on NetworkMessageId
| where UrlDomain !has "docusign.net" and UrlDomain !has "docusign.com"
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress, Url, UrlDomain
| sort by TimeGenerated desc;

Velociraptor VQL

On endpoints, the most useful artifact is evidence the user actually visited the AitM proxy domain. This VQL hunts browser history databases for DocuSign-themed phishing URLs hosted on non-DocuSign domains — a strong lead for scoping which users completed the flow and need session revocation.

-- Hunt Chrome/Edge history for DocuSign-themed lures on non-DocuSign domains
SELECT url, title, visit_count, last_visit_time, FullPath
FROM glob(globs='''C:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\*\\History''')
WHERE FullPath =~ '(Chrome|Edge)'
AND (
  SELECT * FROM foreach(row={
    SELECT url, title, visit_count, last_visit_time
    FROM sqlite(file=FullPath, query='SELECT url, title, visit_count, last_visit_time FROM urls')
    WHERE url =~ '(?i)docusign|docu-sign|d0cusign|secure-doc|envelope'
      AND url !~ '(?i)docusign\\.(net|com)'
  })
)

Remediation / Verification Script

This PowerShell script checks for the tenant-level controls that actually stop AitM session replay — Conditional Access coverage, legacy auth blocking, and phishing-resistant methods — and surfaces risky inbox rules and OAuth consents for IR scoping. Requires the Microsoft Graph PowerShell SDK with appropriate scopes.

# NovaCookies / AitM Exposure Assessment - run as Global Admin or Security Admin
# Requires: Microsoft.Graph module, Connect-MgGraph -Scopes "Policy.Read.All,Directory.Read.All,AuditLog.Read.All"

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All","AuditLog.Read.All" -NoWelcome

# 1. Check for Conditional Access policies requiring phishing-resistant auth or token protection
Write-Host "`n=== Conditional Access Policy Review ===" -ForegroundColor Cyan
$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($p in $policies) {
    $state = $p.State
    $grant = ($p.GrantControls.BuiltInControls -join ",")
    $hasTokenProtection = ($p.SessionControls | ConvertTo-Json -Depth 5) -match "secureTokenProtection|tokenProtection"
    Write-Host ("[{0}] {1} | Grants: {2} | TokenProtection: {3}" -f $state, $p.DisplayName, $grant, $hasTokenProtection)
}

# 2. Check whether legacy authentication is blocked (legacy auth cannot do MFA or CA)
Write-Host "`n=== Legacy Auth Blocking Check ===" -ForegroundColor Cyan
$legacyBlocked = $policies | Where-Object {
    $_.State -eq 'enabled' -and
    (($_.Conditions.ClientAppTypes) -contains 'exchangeActiveSync' -or
     ($_.Conditions.ClientAppTypes) -contains 'other') -and
    ($_.GrantControls.BuiltInControls -contains 'block')
}
if ($legacyBlocked) { Write-Host "Legacy auth is blocked. GOOD." -ForegroundColor Green }
else { Write-Host "WARNING: No enabled CA policy blocks legacy authentication. Remediate immediately." -ForegroundColor Red }

# 3. Enumerate recent suspicious inbox rules via Graph audit (requires Exchange perms in production)
Write-Host "`n=== Recent Consent Grants (potential OAuth persistence) ===" -ForegroundColor Cyan
$consents = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application'" -Top 50
$consents | ForEach-Object {
    Write-Host ("{0} | {1} | Result: {2}" -f $_.ActivityDateTime, $_.InitiatedBy.User.UserPrincipalName, $_.Result)
}

# 4. Emergency response helper: revoke all refresh tokens for a compromised user
# Uncomment and set UPN when scoping a confirmed NovaCookies victim:
# $victimUPN = "user@domain.com"
# Revoke-MgUserSignInSession -UserId $victimUPN
# Write-Host "Sessions revoked for $victimUPN - also reset credentials and review inbox rules/OAuth grants." -ForegroundColor Yellow

Write-Host "`nAssessment complete. Prioritize: FIDO2/passkey rollout, CA token protection, legacy auth block." -ForegroundColor Cyan

Remediation

There is no patch — this is an authentication-architecture problem. Remediate in this order:

Immediate (today):

1. Scope and contain suspected victims. Run the KQL hunts above. For any user with session-replay indicators: revoke all sessions (Revoke-MgUserSignInSession), force a password reset, review and remove inbox rules, and audit OAuth consent grants.
2. Alert users to the DocuSign lure. Genuine DocuSign notifications are now a viable phishing vector. Instruct users to navigate to docusign.com directly rather than clicking envelope links, and to verify the URL bar shows login.microsoftonline.com — though note AitM proxies can obscure this, making technical controls the real fix.

Short term (this week): 3. Deploy Conditional Access token protection (requires Entra ID P1/P2) for Exchange Online and SharePoint Online. This cryptographically binds tokens to the device and breaks replay from attacker infrastructure — the single highest-impact control against NovaCookies. 4. Block legacy authentication tenant-wide via Conditional Access. Legacy protocols bypass MFA entirely and are a parallel abuse path. 5. Enable Continuous Access Evaluation (CAE) so stolen tokens are invalidated faster when conditions change.

Strategic (this quarter): 6. Roll out phishing-resistant MFA — FIDO2 security keys or Windows Hello for Business passkeys — starting with executives, finance, and admins. AitM proxies cannot relay FIDO2 challenges to an origin they don't control. 7. Harden DocuSign itself: restrict envelope-sending permissions, enable DocuSign's anti-abuse controls, and coordinate with DocuSign trust & safety to report abused accounts. 8. Add ASN-based Conditional Access policies to flag or block sign-ins from hosting providers and anonymization networks where your user base has no legitimate presence.

The bottom line: NovaCookies is commodity AitM tooling wrapped in an exceptionally credible delivery channel. Email-layer defenses will not save you here — only phishing-resistant authentication and token binding will.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub