Third-Party Support System Breach: Analyzing the EY Incident and Defensive Strategies

Ernst & Young (EY) recently disclosed a significant security incident stemming from the compromise of a third-party support ticket system utilized by its internal IT teams. While the initial vector involved an external vendor, the impact directly affected EY's data integrity. This incident underscores the persistent danger of the supply chain attack surface—specifically, how administrative support tools can become pivot points for data exfiltration. For defenders, this is a stark reminder that perimeter defenses often fail when trusted third-party relationships are weaponized. We must assume that valid access to support portals can be hijacked and pivot immediately to detection of lateral movement and data staging within the enterprise environment.

Technical Analysis

The breach involves a compromise of a cloud-based support ticketing platform used by EY's IT personnel.

• Affected Component: Third-party IT support ticketing system (SaaS).
• Attack Vector: The threat actor compromised the support system, likely through credential theft, session hijacking, or a vulnerability in the vendor's platform. Once inside, they accessed support tickets containing sensitive customer information.
• Mechanism: Access to the support system provided a trove of potentially sensitive data. In many similar incidents, access to a support portal allows attackers to view session tokens, view internal error logs, or manipulate ticket attachments to deliver payloads. In this specific instance, the primary risk is data exposure and leakage.
• Exploitation Status: Confirmed active exploitation resulting in a data breach notification.

Detection & Response

Detecting breaches originating from third-party SaaS platforms requires correlating identity anomalies with endpoint activity. While we cannot patch the vendor's code, we can detect the behavior of an attacker who has gained access to support tools—specifically, the staging of data for exfiltration or the use of administrative support tools to pivot.

SIGMA Rules

---
title: Potential Data Staging via Archiving Tools
id: 8a2b4c91-3d5e-4f6a-9b1c-2d3e4f5a6b7c
status: experimental
description: Detects the use of common archiving tools (WinRAR, 7-Zip) often used to stage data for exfiltration after accessing web-based portals. This activity frequently follows the initial reconnaissance phase of a support system breach.
references:
  - https://attack.mitre.org/techniques/T1560/
author: Security Arsenal
date: 2026/04/21
tags:
  - attack.collection
  - attack.t1560.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\winrar.exe'
      - '\7z.exe'
      - '\winzip64.exe'
      - '\tar.exe'
  condition: selection
falsepositives:
  - Legitimate administrative backups
  - User file compression
level: medium
---
title: Suspicious PowerShell Web Request Activity
id: 9c3d5e02-4e6f-5a7b-0c2d-3e4f5a6b7c8d
status: experimental
description: Detects PowerShell processes making web requests, a common technique for interacting with compromised support APIs or exfiltrating data programmatically after initial access.
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: Security Arsenal
date: 2026/04/21
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Invoke-WebRequest'
      - 'IWR'
      - 'WebRequest'
  condition: selection
falsepositives:
  - System management scripts
  - Package managers
level: high

KQL (Microsoft Sentinel)

This query hunts for anomalous sign-ins to the specific support application (replace AppDisplayName with the actual vendor name if known) correlated with high-volume data access or file transfer events on the endpoint.

let SupportApp = "*Support*"; // Adjust based on actual vendor name
SigninLogs
| where AppDisplayName contains SupportApp
| where ResultDescription == "Success" or ResultDescription == "0"
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, DeviceDetail
| join kind=inner (
    DeviceFileEvents
    | where Timestamp > ago(1h) 
    | where ActionType == "FileCreated" 
    | summarize FileCount = count(), Timestamp = max(Timestamp) by AccountName, DeviceName
) on $left.UserPrincipalName == $right.AccountName
| where FileCount > 10 // Threshold for bulk file creation
| project TimeGenerated, UserPrincipalName, IPAddress, DeviceName, FileCount

Velociraptor VQL

This artifact hunts for processes that have established network connections to non-corporate IP ranges while simultaneously accessing files on the disk, indicative of data exfiltration tools.

-- Hunt for processes with network connections and file handles
SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE 
  Pid IN (SELECT Pid FROM netstat() WHERE RemoteAddress NOT MATCH '^192\.168\.|^10\.|^172\.(1[6-9]|2[0-9]|3[0-1])\.')
  AND Pid IN (SELECT Pid FROM handles() WHERE Type =~ "File")

Remediation Script (PowerShell)

Use this script to audit and immediately revoke OAuth tokens for known support applications in your tenant (requires AzureAD module).

# Revoke active sessions for a specific Service Principal (Support System)
$SupportAppName = "Support Ticket System" # Replace with actual App Name

Connect-AzureAD

$App = Get-AzureADServicePrincipal -Filter "DisplayName eq '$SupportAppName'"

if ($App) {
    Write-Host "Found App: $($App.DisplayName)"
    
    # Get all users who have granted permission to this app
    $OAuth2Perms = Get-AzureADOAuth2PermissionGrant -All $true | Where-Object { $_.ClientId -eq $App.ObjectId }
    
    foreach ($Grant in $OAuth2Perms) {
        Write-Host "Revoking grant for User: $($Grant.ObjectId)"
        # Note: This deletes the delegation grant, forcing re-authentication
        Remove-AzureADOAuth2PermissionGrant -ObjectId $Grant.ObjectId
    }
    
    Write-Host "Remediation Complete: All OAuth grants revoked. Users must re-authenticate."
} else {
    Write-Host "Support Application not found."
}

Remediation

1. Immediate Access Revocation: Assume all credentials and sessions associated with the compromised third-party support system are invalid. Force a password reset and MFA re-enrollment for all IT personnel with access to the platform.
2. Token Revocation: Revoke all OAuth refresh tokens and sessions granted to the third-party application via your identity provider (IdP). This forces a fresh authentication cycle and breaks active attacker sessions.
3. Vendor Coordination: Engage the third-party vendor to obtain logs identifying specific API calls or data access attributed to the compromise window. Cross-reference this with internal audit logs.
4. Data Classification Audit: Review the types of data permitted in support tickets. Implement DLP (Data Loss Prevention) rules to redact or block PII/PHI from being pasted into external support portals.
5. Least Privilege: Restrict IT support staff access to the third-party portal. Ensure they only have access to the specific tickets relevant to their scope, rather than global administrative access to the support database.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub