Back to Intelligence

OAuth Consent Traps, CEO Social-Engineering Kits, and 5,000 Dropbox Account Hacks: A Defender's Detection and Response Playbook

SA
Security Arsenal Team
September 3, 2026
11 min read

This week's ThreatsDay roundup from The Hacker News reads like a greatest-hits album of modern intrusion tradecraft — and that's precisely the problem. None of it looks like an attack. A help desk call. A shared Dropbox file. A consent screen asking you to click "Allow" in an app you already trust. A vendor-branded login page one letter off from the real domain.

The reporting covers three headline campaigns defenders need to internalize right now:

  1. CEO-focused social engineering kits being sold on criminal forums, packaging voice scripts, pretext templates, and spoofed executive infrastructure so low-skill attackers can run convincing business email compromise (BEC) and help-desk fraud at scale.
  2. Roughly 5,000 Dropbox accounts compromised, where stolen credentials and session tokens are being used to weaponize trusted file-sharing workflows — turning a legitimate collaboration platform into a malware delivery and data staging channel.
  3. OAuth consent phishing (a.k.a. "consent phishing"), where users grant a malicious third-party application persistent access to their mailbox, files, and identity — no password theft required, and MFA doesn't stop it.

The through-line: attackers have largely stopped breaking in. They're getting themselves invited in — and once inside, they ride legitimate SaaS tokens and trusted platforms in ways that bypass most perimeter controls. If your detections still assume malware on disk and known-bad IPs, you are blind to all three of these campaigns.


Technical Analysis

Attack Chain 1: Consent Phishing (Illicit OAuth Grants)

The OAuth consent trap follows a well-documented chain (MITRE ATT&CK T1550.001 — Use Alternate Authentication Material: Web Session Cookies and T1528 — Steal Application Access Token):

  1. Lure: The victim receives an email, Teams message, or shared-document notification (often from an already-compromised account, making it internal and trusted) prompting them to open a file or install an app.
  2. Consent screen: The link resolves to a real Microsoft 365 / Entra ID or Google OAuth authorization URL. The app requests scopes like Mail.Read, Mail.Send, offline_access, Files.Read.All, or User.Read.All. Because the URL is genuinely login.microsoftonline.com, URL filters and even trained users wave it through.
  3. Grant: The user clicks "Accept." The attacker's app now holds an OAuth refresh token tied to the victim — persistent, MFA-agnostic, and invisible to password resets.
  4. Persistence and abuse: The attacker reads mail for reconnaissance and invoice fraud, plants forwarding rules, or accesses OneDrive/SharePoint data. Revoking the app consent — not resetting the password — is what kills access.

The critical defensive point: the grant is the intrusion. By the time the attacker uses the token, your best detection window has already closed.

Attack Chain 2: Dropbox Account Compromise and Trusted-Platform Abuse

The ~5,000 compromised Dropbox accounts matter less for the raw number than for the method of monetization. Attackers are:

  • Logging in with phished or credential-stuffed credentials (fake Dropbox login pages distributed via email and malvertising, per the report's note on "fake login pages" and "software guides that point to unsafe downloads").
  • Uploading malicious payloads or replacing legitimate shared files with trojanized versions, so the delivery channel carries a trusted dropbox.com URL that sails past web filtering.
  • Using shared-link notifications as the phishing lure itself — the email comes from Dropbox's real infrastructure, so SPF/DKIM/DMARC all pass.
  • Abusing typosquatted domains ("one wrong letter in a web address") for credential harvesting pages impersonating Dropbox and SSO portals.

Defensive implication: a clean sender domain and a passing DMARC check are no longer evidence of safety. Detection must move to post-authentication behavior and token/session analytics.

Attack Chain 3: CEO Impersonation and Help-Desk Pretexting Kits

The commoditized social engineering kits lower the skill floor for voice phishing (vishing) against help desks and finance staff: spoofed caller ID, scripted pretexts ("I'm the new IT contractor, the CEO needs MFA reset before the board call"), and forged executive email threads. The technical payload is usually an MFA reset or new device registration — after which the attacker self-enrolls and owns the account.

Exploitation Status

These are confirmed active, in-the-wild campaigns — not theoretical tradecraft. Consent phishing has been a staple of criminal and nation-state actors alike for years, and the current reporting indicates fresh, scaled abuse. No CVE is involved: this is abuse of intended platform functionality, which is exactly why patching won't save you. Configuration, conditional access, and detection are your controls.


Detection & Response

SIGMA Rules

YAML
---
title: OAuth Consent Grant to Application (Potential Illicit Consent)
id: 3f8a2b14-9c6e-4d71-a52b-8e1f4c7d9a03
status: experimental
description: Detects user or admin consent grants to OAuth applications in Entra ID. Consent phishing campaigns trick users into granting malicious apps persistent mailbox and file access. Tune against known approved enterprise applications.
references:
  - https://attack.mitre.org/techniques/T1550/001/
  - https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/09/11
tags:
  - attack.credential_access
  - attack.persistence
  - attack.t1550.001
  - attack.t1528
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    OperationName:
      - 'Consent to application'
      - 'Add delegated permission grant'
      - 'Add app role assignment to service principal'
  filter_known_apps:
    InitiatedBy|contains:
      - 'admin@yourdomain.tld'
  condition: selection and not filter_known_apps
falsepositives:
  - Legitimate user consent to approved SaaS applications where user consent is still enabled
  - Administrators onboarding new enterprise applications
level: medium
---
title: Office or Browser Process Spawning Script Interpreter (Phish Payload Execution)
id: 6c1d9e47-2a83-4f55-b3d0-5e8a7c2f1b94
status: experimental
description: Detects Office applications, browsers, or email clients spawning script interpreters — a common execution stage after a user opens a lure document or follows a link delivered via trusted file-sharing platforms such as compromised Dropbox shares.
references:
  - https://attack.mitre.org/techniques/T1204/002/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/11
tags:
  - attack.execution
  - attack.initial_access
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\msedge.exe'
      - '\chrome.exe'
      - '\firefox.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Browser-launched installers and legitimate Office add-ins (rare); baseline per parent process
level: high
---
title: DNS Query for Dropbox Typosquat or Lookalike Domain
id: 9b4e7c21-5d38-4a90-e6f2-1c3a8d5b7f60
status: experimental
description: Detects DNS resolutions matching common Dropbox typosquatting and lookalike patterns used by credential-harvesting pages. Excludes the legitimate dropbox.com namespace.
references:
  - https://attack.mitre.org/techniques/T1566/002/
author: Security Arsenal
date: 2026/09/11
tags:
  - attack.initial_access
  - attack.t1566.002
logsource:
  category: dns
  product: windows
detection:
  selection:
    query|contains:
      - 'dropbox-'
      - '-dropbox'
      - 'dr0pbox'
      - 'dropb0x'
      - 'drobpox'
      - 'dropboxlogin'
      - 'dropboxverify'
  filter_legitimate:
    query|endswith:
      - 'dropbox.com'
      - 'dropbox-dns.com'
      - 'dropboxapi.com'
  condition: selection and not filter_legitimate
falsepositives:
  - Security research or brand-protection scanning infrastructure
level: medium

KQL — Microsoft Sentinel / Defender

KQL — Microsoft Sentinel / Defender
// Hunt 1: Suspicious OAuth consent grants with high-risk scopes (consent phishing)
let RiskyScopes = dynamic(["Mail.Read","Mail.ReadWrite","Mail.Send","offline_access","Files.Read.All","Files.ReadWrite.All","User.Read.All","full_access_as_app","EWS.AccessAsUser.All","Contacts.Read","MailboxSettings.ReadWrite"]);
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName in ("Consent to application","Add delegated permission grant")
| mv-apply TargetResource = TargetResources on (
    extend AppName = tostring(TargetResource.displayName),
           Scopes = tostring(TargetResource.modifiedProperties)
)
| extend Grantor = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| where Scopes has_any (RiskyScopes)
| project TimeGenerated, OperationName, AppName, Grantor, Scopes, CorrelationId, Result
| order by TimeGenerated desc;
// Hunt 2: Token-theft style sign-ins — new ASN/device for accounts accessing file-sharing apps
SigninLogs
| where TimeGenerated > ago(7d)
| where AppDisplayName has_any ("Dropbox","OneDrive","SharePoint")
| summarize SignInCount = count(),
            DistinctASNs = dcount(NetworkLocationDetails),
            IPs = make_set(IPAddress),
            Locations = make_set(LocationDetails),
            Devices = make_set(DeviceDetail)
  by UserPrincipalName, AppDisplayName
| where array_length(IPs) > 3 or SignInCount > 50
| order by SignInCount desc;
// Hunt 3: Endpoint execution — browser/Office spawning script interpreters
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","msedge.exe","chrome.exe","firefox.exe")
| where FileName in~ ("powershell.exe","pwsh.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc

Velociraptor VQL

VQL — Velociraptor
-- Hunt for script interpreters launched with remote URLs or executed from user-writable staging paths
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (
    (Name =~ '(?i)mshta|rundll32|regsvr32|powershell|wscript|cscript'
     AND CommandLine =~ '(?i)http[s]?://')
    OR Exe =~ '(?i)(Downloads|AppData\\\\Local\\\\Temp|ProgramData)'
)
ORDER BY CreateTime DESC

Remediation & Hardening Script

PowerShell
# OAuth Consent Audit & Hardening for Entra ID (requires Microsoft.Graph module, ConsentPolicy.ReadWrite.All)
# Step 1: Connect with least-privilege scopes needed for audit + policy update
Connect-MgGraph -Scopes "Application.Read.All","DelegatedPermissionGrant.ReadWrite.All","Policy.ReadWrite.PermissionGrant","Directory.Read.All"

# Step 2: Inventory all delegated permission grants and flag risky scopes
$RiskyScopes = @("Mail.Read","Mail.ReadWrite","Mail.Send","offline_access","Files.Read.All","Files.ReadWrite.All","User.Read.All","full_access_as_app","EWS.AccessAsUser.All","MailboxSettings.ReadWrite")
$grants = Get-MgOauth2PermissionGrant -All
foreach ($g in $grants) {
    $sp = Get-MgServicePrincipal -ServicePrincipalId $g.ClientId -ErrorAction SilentlyContinue
    $matched = $RiskyScopes | Where-Object { $g.Scope -match [regex]::Escape($_) }
    if ($matched) {
        [PSCustomObject]@{
            AppDisplayName = $sp.DisplayName
            AppId          = $sp.AppId
            ConsentType    = $g.ConsentType
            RiskyScope     = ($matched -join ",")
            AllScopes      = $g.Scope
            GrantId        = $g.Id
            Publisher      = $sp.PublisherName
            VerifiedPublisher = $sp.VerifiedPublisher.DisplayName
        }
    }
} | Format-Table -AutoSize
# Review the output: any unverified publisher, unfamiliar app name, or recent grant timestamp is a suspect.

# Step 3: Revoke a malicious grant (replace with the GrantId from Step 2 output)
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<GRANT_ID>"
# Also revoke the user's refresh tokens to kill active attacker sessions:
# Revoke-MgUserSignInSession -UserId "<USER_OBJECT_ID>"

# Step 4: Disable end-user consent so only admins can approve apps going forward
Update-MgPolicyAuthorizationPolicy -AuthorizationPolicyId "authorizationPolicy" `
  -BodyParameter @{ defaultUserRolePermissions = @{ permissionGrantPoliciesAssigned = @() } }
# Verify: Entra portal > Enterprise applications > Consent and permissions > User consent settings
# should now read "Do not allow user consent" or "Allow consent for verified publishers, low-risk scopes only"

# Step 5: Audit for persistence planted via compromised mailboxes
$users = Get-MgUser -All -Property Id,UserPrincipalName
foreach ($u in $users) {
    Get-MgUserMailFolderMessageRule -UserId $u.Id -MailFolderId "inbox" -ErrorAction SilentlyContinue |
      Where-Object { $_.Actions.ForwardTo -or $_.Actions.ForwardAsAttachmentTo -or $_.Actions.RedirectTo } |
      Select-Object @{n="User";e={$u.UserPrincipalName}}, DisplayName, IsEnabled, Actions
}
# Investigate any rule forwarding to external addresses — classic BEC persistence.

Remediation

Immediate (24–48 hours)

  1. Run the OAuth consent audit above. Every tenant that still allows user consent should be treated as presumptively exposed. Revoke any grant from an unverified publisher or an app you cannot positively identify, then Revoke-MgUserSignInSession for affected users.
  2. Disable end-user OAuth consent (Step 4 in the script) or restrict it to verified publishers with Microsoft-classified low-risk permissions. Enable the admin consent workflow so users request apps and admins approve them — this converts the attacker's one-click win into a human review gate.
  3. For the Dropbox exposure: force credential resets and, critically, invalidate all active sessions and linked API tokens for affected accounts — password resets alone do not kill stolen session tokens. Audit shared links created in the compromise window and disable any external links to sensitive folders. Move Dropbox to SSO with enforced MFA if you haven't.
  4. Hunt mailbox forwarding rules on any account that clicked a consent lure (Step 5). Attackers plant these within minutes of mailbox access.

Short-Term (1–2 weeks)

  1. Deploy phishing-resistant MFA — FIDO2 security keys or passkeys — prioritizing executives, finance, and help-desk staff. Number matching in push MFA is the floor, not the ceiling; consent phishing and AiTM token theft both defeat push-based MFA.
  2. Help-desk MFA-reset controls: require out-of-band verification (manager callback on a known number, video verification) for any MFA reset or new device registration, with a mandatory cooling-off alert to the security team. The CEO-impersonation kits succeed or fail at this single control point.
  3. Conditional Access for OAuth tokens: require compliant devices for application access where feasible, and block token issuance from unfamiliar ASNs/locations for high-value users.
  4. Web filtering: block newly registered domains (NRD) category and alert on dropbox-*-style lookalikes per the Sigma rule above. Subscribe to Dropbox's security guidance at https://www.dropbox.com/security and Microsoft's consent phishing documentation at https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants.

Strategic

  1. Detection posture shift: if your SOC is not ingesting Entra AuditLogs and SigninLogs into Sentinel (or equivalent), you have no visibility into the attack class this week's news is built on. This is table stakes for identity-centric defense in 2026.
  2. Tabletop the scenario: run an exercise where a finance user grants a malicious app Mail.Read + Mail.Send. Measure time-to-detect and time-to-revoke. If you can't answer both, that's your gap.

The adversaries in this week's reporting aren't exploiting software — they're exploiting the trust assumptions baked into how we collaborate. Your controls need to assume the lure arrives from a legitimate platform, on a passing-DMARC email, from a compromised-but-known sender. Detect the grant, the token use, and the post-access behavior — because by then, the phish itself is ancient history.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.