Researchers at the University of Massachusetts Amherst have disclosed a practical attack — dubbed Zombie Card — that allows an attacker to take an expired Visa contactless credit card and successfully complete real, in-store purchases at point-of-sale (POS) terminals. The technique rewrites the expiration date that the terminal reads over near-field communication (NFC) during the contactless transaction exchange. Critically, the attack does not break, clone, or bypass any of the card's EMV cryptography. The card's chip still produces valid cryptograms — the attacker simply convinces the terminal that the card has not expired.
Why this matters to defenders: payment card expiration is a control that issuers, merchants, and fraud teams implicitly trust as a first-line kill switch for lost, stolen, or decommissioned cards. Zombie Card demonstrates that, under specific conditions, that trust is misplaced at the terminal level. An attacker with physical possession of an expired card — trivially obtained from discarded cards, stolen wallets never reported, or cards harvested from mail theft — can potentially extend its useful fraud life well past its printed expiry. For fraud teams, IR responders handling payment incidents, and architects responsible for EMV kernel and terminal configurations, this is a present-day, demonstrated technique, not a theoretical one.
No CVE has been assigned to this research as of publication; this is a protocol/implementation-level weakness in how expiry data is handled in the contactless transaction flow rather than a single patchable software flaw.
Technical Analysis
Affected Products and Platforms
- Payment scheme: Visa contactless (payWave) transactions, per the published research. The underlying weakness — expiry date transmitted as a terminal-readable data element rather than a cryptographically enforced one — is architecturally relevant to EMV contactless kernels broadly, and other schemes should be presumed similarly exposed until validated otherwise.
- Terminal side: POS terminals and SoftPOS implementations running EMV Level 2 contactless kernels that accept the expiry date presented in the card's response (e.g., Track 2 Equivalent Data, tag 57, or the Application Expiration Date, tag 5F24) without independent validation.
- Issuer side: Authorization flows that rely on the terminal/acquirer to reject expired cards rather than enforcing expiry at the issuer host.
How the Attack Works (Defender's View of the Kill Chain)
A contactless EMV transaction is a structured dialogue: the terminal issues a SELECT PPSE command, the card responds with available applications, the terminal reads records via READ RECORD / GET PROCESSING OPTIONS, and the card generates an application cryptogram (ARQC) signed under keys only the issuer can verify. The expiry date travels in this exchange as plaintext data elements.
The Zombie Card attack chain, from a defender's perspective:
- Acquisition: Attacker obtains an expired but otherwise intact Visa contactless card. The chip, keys, and EMV application are all still functional — expiry does not disable the silicon.
- Manipulation of the NFC exchange: Using an NFC-capable device positioned between the card and the terminal (a relay/interposer role), the attacker alters the expiration date fields the terminal reads during the transaction. The genuine card chip is still answering; the cryptographic exchange completes legitimately because the cryptogram is computed over transaction data the card itself controls.
- Terminal acceptance: The POS terminal sees a non-expired card, proceeds through kernel processing, and forwards an authorization request.
- Authorization: If the issuer host does not independently validate the presented expiry against its own card record — or relies on expiry data echoed from the transaction — the purchase approves.
The defensive lesson is architectural: expiry is being treated as advisory data read from an untrusted channel rather than as issuer-enforced state. The NFC interface is a physical, attacker-influenceable medium, and any field read from it that is not integrity-protected end-to-end must be treated as attacker-controlled input.
Exploitation Status
- Origin: Academic research (University of Massachusetts Amherst), demonstrated against real in-store purchases.
- In-the-wild exploitation: No confirmed widespread criminal campaigns have been publicly attributed to this technique as of publication. However, the barrier to entry is low — commodity NFC hardware and physical possession of expired cards — and the fraud economics (harvested expired cards from mail theft, dumpster diving, or carding markets) are favorable. Treat this as PoC-demonstrated with high criminal adoptability.
- CISA KEV: Not applicable — no CVE assigned.
- Patch posture: This is not remediated by a single vendor patch. Mitigation requires coordinated issuer-side validation, EMV kernel/terminal configuration review, and fraud analytics tuning.
Detection & Response
Honest scoping first: the decisive detections for Zombie Card live in issuer authorization systems and acquirer transaction monitoring — expiry mismatches between presented transaction data and issuer card records — not in endpoint EDR telemetry. That said, the merchant/POS estate is part of the attack surface (an attacker may also probe terminals, tamper with POS software, or operate rogue NFC equipment near checkout lanes), and defenders with visibility into Windows-based POS endpoints and payment infrastructure should hunt there too. The content below targets what is actually observable.
Sigma Rules
These rules target POS-endpoint tampering behaviors that accompany payment fraud operations against the terminal estate: unauthorized modification of payment application binaries/configs and execution of non-whitelisted processes on POS systems.
---
title: POS Payment Application Binary or Configuration Modification
id: 3f9c2a71-8b4e-4d6a-91c2-7e5f0a3b9d21
status: experimental
description: Detects modification of payment application executables, EMV kernel configuration, or transaction data files on point-of-sale endpoints, consistent with POS tampering preceding fraudulent transaction acceptance.
references:
- https://thehackernews.com/2026/08/zombie-card-attack-can-revive-expired.html
author: Security Arsenal
date: 2026/08/15
tags:
- attack.impact
- attack.t1565.001
logsource:
category: file_event
product: windows
detection:
selection_paths:
TargetFilename|contains:
- '\Program Files\'
- '\Program Files (x86)\'
selection_keywords:
TargetFilename|contains:
- '\pos\'
- '\payment\'
- '\emv\'
- '\pinpad\'
- '\txn\'
- '\tender\'
filter_images:
Image|contains:
- '\Windows\Installer\'
- 'msiexec.exe'
- '\updater'
condition: selection_paths and selection_keywords and not filter_images
falsepositives:
- Scheduled POS software updates pushed by the payment application vendor
- Managed deployment tools (SCCM/Intune) updating POS software
level: high
---
title: Non-Whitelisted Process Execution on POS Endpoint
id: 8d1e4b62-5c37-49fa-b284-6a2d9f0e7c15
status: experimental
description: Detects execution of scripting engines, remote access tools, or NFC-capable utilities on point-of-sale systems, which have a tightly defined software baseline under PCI-DSS and should run almost nothing outside the payment stack.
references:
- https://thehackernews.com/2026/08/zombie-card-attack-can-revive-expired.html
author: Security Arsenal
date: 2026/08/15
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\psexec.exe'
- '\anydesk.exe'
- '\teamviewer.exe'
- '\ngrok.exe'
filter_paths:
Image|contains:
- '\POSVendor\'
- '\PaymentApp\'
condition: selection and not filter_paths
falsepositives:
- POS vendor remote support sessions — whitelist approved support tooling explicitly
- Inventory management agents
level: high
---
title: USB or Serial Peripheral Attached to POS Endpoint
id: 1c7a5d93-2e68-4f1b-a356-9b4c8e2d6f07
status: experimental
description: Detects new USB device installation events on POS endpoints. Zombie Card-class attacks involve physical NFC hardware near checkout lanes; unexpected USB peripherals on fixed POS stations are high-signal anomalies.
references:
- https://thehackernews.com/2026/08/zombie-card-attack-can-revive-expired.html
author: Security Arsenal
date: 2026/08/15
tags:
- attack.initial_access
- attack.t1200
logsource:
category: driver
product: windows
detection:
selection:
ImageLoaded|contains:
- '\drivers\USBSTOR.SYS'
- '\drivers\usbccgp.sys'
- '\drivers\WinUSB.SYS'
condition: selection
falsepositives:
- Approved payment PIN pads and receipt printers — maintain a device-class whitelist per store
level: medium
KQL (Microsoft Sentinel / Defender)
The highest-fidelity analytic for Zombie Card is an issuer/acquirer-side expiry mismatch: the expiration date present in authorization data does not match the issuer's card-on-file record, or an authorization is approved for a PAN whose issuer record shows the card as expired. If your organization ingests payment switch or authorization logs into Sentinel (via CEF/Syslog or a custom table), hunt for that mismatch directly. The endpoint-side query below hunts POS process anomalies in Defender.
// Hunt 1: Authorization approvals where presented expiry indicates an expired card
// Adapt field names to your payment switch / acquirer log schema ingested via CEF or custom logs
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor contains "Payment" or DeviceProduct contains "Switch"
| extend PresentedExpiry = tostring(AdditionalExtensions) // parse expiry from auth payload per your schema
| extend ResponseCode = tostring(DeviceCustomString1)
| where ResponseCode in ("00", "000", "APPROVED")
| summarize AuthCount = count(), Terminals = dcount(DeviceAddress) by SourceHostName, PresentedExpiry, bin(TimeGenerated, 1h)
| where AuthCount > 5 // tune: expired-card retries often appear as clustered attempts across terminals
| sort by AuthCount desc
// Hunt 2: POS endpoint process anomalies (Defender for Endpoint)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where DeviceName has_any ("pos", "register", "checkout", "lane") // align with your POS naming convention
| where FileName in~ ("powershell.exe","cmd.exe","wscript.exe","mshta.exe","rundll32.exe","psexec.exe","anydesk.exe","teamviewer.exe")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by TimeGenerated desc
Velociraptor VQL
Use this artifact across POS endpoints to establish whether payment application binaries or NFC-related drivers have been altered outside of a change window.
-- Hunt POS endpoints for modified payment application files and unexpected processes
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(powershell|wscript|cscript|mshta|psexec|anydesk|teamviewer|nfc)'
OR Exe =~ '(?i)(temp|appdata|users\\public)'
-- Enumerate payment application directories with hashes for baseline diffing
SELECT FullPath, Size, Mtime, hash(path=FullPath) AS Hash
FROM glob(globs=['C:/Program Files/*POS*/**','C:/Program Files (x86)/*Payment*/**','C:/Program Files (x86)/*EMV*/**'])
WHERE NOT IsDir
Remediation / Verification Script
For issuers and acquirers, the primary fix is authorization-host logic, not an endpoint script. For merchants, this PowerShell audit establishes a file-integrity baseline of the POS payment stack and flags drift — run it during a known-good state, then on a schedule and diff the output.
# POS Payment Stack Integrity Baseline and Drift Check
# Run as local admin on each POS endpoint. Compare against the golden baseline per store.
$PaymentDirs = @(
"C:\Program Files\*POS*",
"C:\Program Files (x86)\*Payment*",
"C:\Program Files (x86)\*EMV*"
)
$BaselinePath = "C:\POSBaseline\payment-baseline-$env:COMPUTERNAME.json"
$OutPath = "C:\POSBaseline\integrity-$(Get-Date -Format 'yyyyMMdd-HHmmss').csv"
New-Item -ItemType Directory -Path "C:\POSBaseline" -Force | Out-Null
# Hash all payment application files
$inventory = foreach ($dir in $PaymentDirs) {
Get-ChildItem -Path $dir -Recurse -File -ErrorAction SilentlyContinue | ForEach-Object {
[PSCustomObject]@{
Path = $_.FullName
Hash = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
Mtime = $_.LastWriteTime
}
}
}
$inventory | Export-Csv -Path $OutPath -NoTypeInformation
# First run: save golden baseline
if (-not (Test-Path $BaselinePath)) {
$inventory | ConvertTo-Json | Set-Content $BaselinePath
Write-Output "Baseline created at $BaselinePath"
} else {
$baseline = Get-Content $BaselinePath | ConvertFrom-Json
$drift = Compare-Object $baseline $inventory -Property Path, Hash |
Where-Object { $_.SideIndicator -ne '==' }
if ($drift) {
$drift | Format-Table -AutoSize
Write-Warning "DRIFT DETECTED in payment application files — investigate before next settlement window"
} else {
Write-Output "No drift detected against baseline."
}
}
# Audit unexpected USB storage/peripheral history
Get-PnpDevice -Class USB -ErrorAction SilentlyContinue |
Where-Object { $_.FriendlyName -notmatch 'Receipt|PIN|Printer|Scanner|Keyboard|Mouse' } |
Select-Object FriendlyName, InstanceId, Status
Remediation
Because Zombie Card exploits a trust assumption rather than a single software bug, remediation is layered. Prioritize in this order:
1. Issuer-side expiry enforcement (highest impact). The issuer authorization host must independently validate the card's expiration against its own card record on every authorization — including contactless, card-present, offline-capable, and stand-in processing flows — and must never rely on expiry values echoed from terminal-supplied transaction data. Decline any authorization for a PAN the issuer record shows as expired, regardless of the expiry date presented in the message. Review stand-in processing (STIP) agreements with acquirers: STIP rules that auto-approve low-value contactless transactions without issuer host contact are the softest target for this attack.
2. Acquirer and terminal risk management. Raise floor-limit and terminal risk-management (TRM) configurations with your acquirer: reduce offline approval limits, force online authorization for contactless transactions wherever network availability permits, and review EMV contactless kernel configurations for how expiry date data elements (tag 5F24, Track 2 Equivalent Data tag 57) are processed and validated. Engage your terminal vendors and EMV kernel suppliers directly regarding the UMass Amherst findings and request their remediation roadmap.
3. Fraud analytics tuning. Add or sharpen rules for: authorizations on PANs past issuer-record expiry; clusters of contactless approvals across multiple merchant terminals from a single PAN in short windows (expired-card testing behavior); and sudden transaction activity on cards with zero spend since their expiry date. Feed chargeback and confirmed-fraud data back into these rules.
4. Card lifecycle hygiene. Encourage and enforce physical destruction of expired cards (issuer communications should explicitly tell cardholders to cut through the chip, not just the magnetic stripe). Audit mail-theft and non-receipt fraud controls — expired cards intercepted in transit are prime feedstock for this attack.
5. Merchant estate hardening. Maintain strict software baselining and file-integrity monitoring on POS endpoints (PCI-DSS Requirement 11.5 FIM), USB device control on fixed terminals, and physical inspection of checkout lanes for unauthorized NFC hardware. Train front-of-house staff that contactless terminals should never be handed off or left unattended with unfamiliar devices nearby.
6. Monitor for scheme guidance. Track Visa security bulletins and EMVCo specification updates responding to this research. When scheme-level mandates or kernel updates land, treat them as prioritized change items with defined deadlines, and document compensating controls (items 1–3 above) in the interim.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.