Illegitimate Data Protection Requests: To Delete or to Address?
This talk analyzes the security risks associated with Data Subject Access Requests (DSARs), which can be weaponized as an attack vector to deliver malware or disrupt organizational resources. It highlights how attackers exploit the legal obligation to process these requests by embedding malicious payloads in files that bypass standard security inspection techniques. The presentation emphasizes the need for organizations to implement robust operational measures, such as strict access controls and human-centric security training, to mitigate these threats.
Weaponizing Data Subject Access Requests: The Compliance Trap
TLDR: Data Subject Access Requests (DSARs) are being weaponized as a novel delivery vector for malware and social engineering. Attackers exploit the legal mandate for organizations to process these requests by embedding malicious payloads in files that bypass standard security inspection. Security teams must treat incoming DSARs as untrusted input and implement strict, automated validation workflows to prevent this abuse.
Compliance mandates are often viewed as a checkbox exercise, but they create a massive, overlooked attack surface. When a company receives a request under the General Data Protection Regulation (GDPR) or similar frameworks, the legal team often panics. They see a ticking clock and a potential fine, which creates the perfect environment for social engineering. Attackers have realized that if they frame a malicious payload as a legitimate DSAR, they can force a security or legal team to bypass their own security controls to "comply" with the law.
The Mechanics of the DSAR Attack Vector
The attack is deceptively simple. An attacker sends an email to an organization’s privacy or legal alias, posing as a data subject. They include a link or an attachment that supposedly contains their personal data or a formal request for information. Because the organization is legally obligated to respond to these requests within a specific timeframe, the recipient is incentivized to open the file immediately.
In a typical engagement, this looks like a standard T1566 Phishing attempt, but with a legal twist. The attacker relies on the fact that the person handling the request is likely not a security engineer. They are often a paralegal or a privacy officer who is more concerned with the legal implications of ignoring the request than the technical implications of opening a suspicious file.
The payload itself often leverages T1204 User Execution by using obfuscated files. During the research presented at Black Hat, it was clear that attackers are not just sending simple executables. They are using complex, multi-layered documents that appear to be legitimate PDFs or spreadsheets but contain hidden macros or malicious scripts. These files are designed to evade signature-based detection by using techniques like file-format confusion or embedding malicious content in non-standard metadata fields.
Why Standard Defenses Fail
Most organizations have robust email filtering, but these filters are tuned to look for known malware signatures or suspicious domains. They are rarely configured to inspect the contents of a "legal" document with the same scrutiny they apply to a random attachment. When a file is labeled as a "Data Subject Access Request," it is often fast-tracked through the security stack.
This is a classic case of A01:2021-Broken Access Control, where the process itself is the vulnerability. By abusing the organization's own compliance workflow, the attacker effectively whitelists their own malicious activity. If the security team is not explicitly trained to treat these requests as untrusted input, they will continue to fall for this.
Practical Implications for Pentesters
If you are running a red team engagement, this is a high-value target. Most organizations have a dedicated email address for privacy requests, such as privacy@company.com or dpo@company.com. These addresses are rarely monitored with the same level of intensity as the general support or sales queues.
During your reconnaissance, identify these addresses. When crafting your payload, do not just send a generic link. Research the company's privacy policy, which is usually public. Use the language from their own policy in your email. If they mention a specific portal for requests, try to mimic the structure of that portal. The goal is to make the request look so authentic that the recipient feels a sense of urgency to open the file to avoid a compliance failure.
Hardening the Compliance Workflow
Defenders need to move away from manual, human-centric processing of these requests. The first step is to implement a strict, automated validation workflow. No file should ever be opened by a human on a production machine. Instead, all incoming requests should be routed through a sandbox environment where the files are detonated and analyzed.
Furthermore, the organization should mandate that all DSARs be submitted through a secure, authenticated portal rather than via email. This removes the reliance on email-based delivery and allows the organization to enforce file-type restrictions and size limits at the point of entry. If a user insists on sending a file via email, it should be automatically stripped of all active content before it ever reaches a human inbox.
Finally, security awareness training must be updated to include this specific threat. Your legal and privacy teams need to understand that they are high-value targets. They should be trained to recognize the signs of a weaponized DSAR, such as unexpected file formats or requests that deviate from the standard submission process.
Compliance is not a substitute for security. If your legal team is not talking to your security team about how they handle these requests, you are already vulnerable. Start by auditing your current intake process and identifying where the human-in-the-loop is being forced to make a security decision they are not equipped to handle. The next time you see a "legal" request in your queue, don't just click it. Treat it like the potential breach it is.
Vulnerability Classes
Target Technologies
Attack Techniques
OWASP Categories
Up Next From This Conference

A Security RISC? The State of Microarchitectural Attacks on RISC-V

REDIScovering HeadCrab: A Technical Analysis of a Novel Malware and the Mind Behind It

TsuKing: Coordinating DNS Resolvers and Queries into Potent DDoS Amplifiers
Similar Talks

Surveilling the Masses with Wi-Fi Positioning Systems

Exploiting Shadow Data in AI Models and Embeddings

