What is it?
Quishing is an attack pattern in which a QR code moves a victim from a trusted context to a malicious destination. The learning goal is to identify the trust boundary being abused, the attacker’s sequence, and the telemetry that records it.
How it works in plain English
Use this three-part model to understand the attack without memorizing a tool name.
A person trusts the message, caller, brand, process, or apparent urgency.
The attacker causes the person to disclose information, approve access, open content, or execute an action.
Join message delivery and user interaction with identity and endpoint activity; the decisive evidence often appears after the click or approval.
Worked example: how the sequence may look
Access to or influence over the relevant Email, Human environment.
Trigger the condition that enables quishing.
Email headers, message trace, attachment sandbox, URL rewriting, click, and browser telemetry.
Baseline the affected identity, host, application, service, or protocol.
If successful, the attacker may continue with Credential Stuffing. This is a possibility, not a guaranteed next step.
This is a defensive learning scenario. Real incidents vary, and the listed outcome is only one possible path.
Why do attackers use it?
Advance an objective associated with initial access.
Exploit a weak control, unsafe default, exposed service, trusted relationship, or human decision.
Create access, gain privilege, evade defenses, steal information, or disrupt operations.
Prerequisites
Access to or influence over the relevant Email, Human environment.
Knowledge of the target’s technology, identities, configuration, or user behavior.
A weakness, misconfiguration, exposed interface, stolen secret, or social opportunity.
A path to observe success and continue toward the objective.
Attack path possibilities
Attack chains are not fixed. These links show common possibilities to investigate before and after this behavior.
A fabricated scenario persuades a target to disclose information or act.
Concept Deepfake Social EngineeringSynthetic voice, video, or imagery impersonates a trusted person.
Concept Help Desk ImpersonationAn attacker impersonates a user or technician to obtain resets, enrollment, or remote access.
T1189 Watering HoleA site used by a target group is compromised to deliver exploits or tracking.
Username and password pairs stolen elsewhere are replayed against a new service.
T1621 MFA FatigueRepeated push prompts pressure a user into approving an attacker login.
T1557 Adversary-in-the-Middle PhishingA reverse proxy captures credentials, MFA exchanges, and session cookies in real time.
T1078.004 Cloud Account TakeoverStolen credentials, tokens, or recovery paths control a cloud identity.
Step-by-step attack flow
Reconnoiter the target and identify the exposed trust boundary.
Prepare the infrastructure, lure, input, credential, or payload required.
Trigger the condition that enables quishing.
Confirm access or effect while attempting to avoid controls.
Use the result for follow-on access, execution, collection, movement, persistence, or impact.
Remove evidence, rotate infrastructure, or repeat against other targets.
MITRE ATT&CK mapping
ATT&CK is updated over time. Verify the live technique before operationalizing a detection.
Logs and artifacts
Email headers, message trace, attachment sandbox, URL rewriting, click, and browser telemetry.
Sign-ins, process creation, downloads, and network activity immediately after interaction.
Mailbox rules, forwarding changes, recovery events, and suspicious sent messages.
Realistic log examples
These records use realistic field names and formats but synthetic organizations, users, addresses, and identifiers. A single event is not proof; correlate time, identity, source, target, and the resulting action.
Sender identity, authentication results, delivery action, URLs, attachments, and campaign linkage.
2026-07-16T13:55:18Z NetworkMessageId=6f3f2a1c
SenderAddress=payroll@vendor-example.com RecipientAddress=j.singh@corp.example
Subject="Updated compensation statement" DeliveryAction=Delivered
SPF=fail DKIM=none DMARC=fail
URLCount=1 AttachmentCount=0 ThreatTypes=PhishBaseline the affected identity, host, application, service, or protocol.
User interaction joined to browser or process behavior.
2026-07-16T13:56:07Z DeviceName=WS-044 AccountName=j.singh
InitiatingProcessFileName=outlook.exe ActionType=BrowserLaunchedToOpenUrl
RemoteUrl=hxxps://login-review.example/office
ProcessCommandLine="msedge.exe --single-argument <url-redacted>"Detect rare combinations of source, target, action, timing, volume, and result.
Cloud sign-in context including identity, application, source, result, device, and conditional access.
2026-07-16T14:24:51Z UserPrincipalName=j.singh@corp.example
AppDisplayName="Office 365 Exchange Online" IPAddress=203.0.113.48
ResultType=50126 ResultDescription="Invalid username or password"
ClientAppUsed=Browser ConditionalAccessStatus=notApplied
DeviceDetail.operatingSystem=Windows Location=SGCorrelate identity, endpoint, network, application, and control-plane evidence across the sequence.
- Who or what identity acted?
- From which device, process, IP, or workload?
- What target and operation were involved?
- Did it fail, succeed, or change state?
- What correlated event happened immediately before and after?
Detection logic / SIEM queries
Baseline the affected identity, host, application, service, or protocol.
Detect rare combinations of source, target, action, timing, volume, and result.
Correlate identity, endpoint, network, application, and control-plane evidence across the sequence.
Prioritize activity followed by successful access, privilege change, execution, or data movement.
FROM security_events
WHERE event_time > now() - 30m
AND behavior = "Quishing"
GROUP BY source, target, user
HAVING count(*) > baseline(source, target, user)
OR rare(action, source, target) = true
CORRELATE WITH success, privilege_change, execution, data_accessMitigations
Reduce exposed attack surface and remove unused services, identities, features, and trust relationships.
Apply least privilege, strong authentication, secure defaults, segmentation, and timely patching.
Validate untrusted input and independently authorize sensitive operations.
Centralize and protect relevant logs; test detections with controlled simulations.
Maintain a response playbook for containment, credential rotation, evidence preservation, and recovery.
Real-world examples
Quishing appears in opportunistic campaigns and targeted intrusions when the required condition exists.
Real incidents usually combine it with credential theft, phishing, exploitation, persistence, or exfiltration.
The best case studies describe the full attack chain rather than an isolated tool or indicator.
Common questions
01What makes Quishing possible?
A trust assumption fails: an identity, input, component, network message, user decision, or software relationship is accepted without enough verification.
02What should a defender collect first?
Start with logs closest to the decision point, then add identity, endpoint, network, and control-plane context.
03How should I study this attack?
Learn the concept, identify prerequisites, map observable steps, write a detection hypothesis, and validate it safely in a lab.