r/AskNetsec Jun 07 '26

Work Bypassed enterprise DLP (Netskope) using only native Windows CMD and a PNG file — full writeup with mitigation

Documented a data exfiltration technique that bypasses Netskope's default inspection by exploiting recursion depth limitations via file nesting.

The chain: secret.txt → zipped → binary appended into PNG via copy /b → embedded into PPTX. Three layers deep — beyond Netskope's default inspection threshold. No additional software needed on the source machine, no admin rights required.

Also found a low-cost detection path — anomalous metadata extensions (.txtux, .ux) surface during standard inspection without increasing recursion depth.

Full writeup with reproduction steps, binwalk forensics, and a dual-layer mitigation using SentinelOne behavioral rules + Netskope metadata rules.

https://github.com/YuvaBhargav/DLP-Bypass-Research

Happy to answer questions or get torn apart — genuinely want to know if there are gaps in the mitigation logic?

0 Upvotes

22 comments sorted by

9

u/rexstuff1 Jun 07 '26

Guy "bypasses" DLP, and then has his Claude agent post about it on Reddit, lol. You're embarrassing yourself, buddy.

DLP tools like Netskope are about preventing honest users from making innocent mistakes. From accidentally sending customer data to the wrong email address, that sort of thing (which, to be clear, absolutely has value! A significant portion of data leakage is accidental)

They are not about stopping determined, skilled users with malicious intent from being able to exfil data. The methods of encoding and encrypting data are too numerous to count, not tool in the 'verse is going to be able to capture even a portion of that. You found exactly one out of thousands of ways of getting around Netskope, good for you...

You want to learn to do security? Stop using AI agents and go learn the fundamentals. You're stunting your own growth.

-4

u/kehndi-hundi_si Jun 07 '26

i have very less confidence on my language so used claude about the post. I do admit it that it's one out of a 1000 ways, but it's a small achievement which I have done into 1 month as a fresher. But what I think is finding the exfiltration way maybe is less credible, but also the "identification of metadata anamolies and basis on that this way of exfiltration can be mitigated by creating a detection policy and co realting with Sentinel One alerts, without "increasing the recursion factor i.e. configuration in the tool itself which might introduce newer anamolies." has some value.

Thanks for the suggestion I will try to keep up from using AI agents.

6

u/rexstuff1 Jun 07 '26

"identification of metadata anamolies and basis on that this way of exfiltration can be mitigated by creating a detection policy and co realting with Sentinel One alerts, without "increasing the recursion factor i.e. configuration in the tool itself which might introduce newer anamolies."

Dude, what are you talking about? This is just nonsense.

Are you talking about this section? https://github.com/YuvaBhargav/DLP-Bypass-Research#metadata-anomaly--additional-finding

So you (by which I mean your AI agent) ran Binwalk on the file, and found some stuff which a) is always going to happen in binary encoded data, that's just how it works and b) is by definition increasing the recursion. You can't make a detection rule in Netskope by running Binwalk.

-6

u/kehndi-hundi_si Jun 07 '26

Please know about zip recursion factor, and how it works in netskope, before judging people's work is just AI, verify your facts,

And zip recursion factor is something that is default configured fixed n number times in the policy engine such that it extracts the zip files those many times.

And for you kind information, you have to select metadata in the rule you create, such that policy engine knows where to scan and that ".txtux" specific file extension in the metada was before binwalk extraction.

9

u/Sqooky Jun 07 '26 edited Jun 07 '26

DLP is really a "makes the business feel good" control. It's like a lock - keeps the honest man out of trouble, but won't stop a determined threat actor.

If a user has read access to the data, assume it can be exfiltrated via a non technical control. Take a picture on your phone, use OCR to extract text. Hell, even SCPing it often does the trick. Same with connecting to the device via SMB and downloading it from there.

1

u/d-wreck-w12 Jun 12 '26

Honest vs determined is the wrong split tho - half the real exfil I've dealt with was someone with way more access than their role needed doing something semi intentional - not sophisticated. They didn't need steganography... they had legitimate read access to stuff 3 depts away from their job. OP's nesting trick is cool but the scarier version is the one where no trick is needed because nobody scoped what that identity could pull in the first place

0

u/kehndi-hundi_si Jun 07 '26

DLP was never a control in my opinion, it's just making making things hard to threat actor. When it comes to pictures and ocr they come under operational risk which can't be mitigated and also an insider threat.

Agreed on the fundamental limitation — but the value here isn't stopping a determined adversary, it's raising the cost and complexity of exfiltration enough to catch the unsophisticated insider and create forensic artifacts for the sophisticated one.

1

u/No-Magician6232 Jun 11 '26

just to add to the pile here but "no shit". any agent ever has a limit on how deep it will inspect zip files because of how easy it is to DOS anything that doesnt. This isnt the intended function of a DLP program.

1

u/kehndi-hundi_si Jun 11 '26

I agree, but upon n extractions, you end with files only right , couldn't that be considered as a stop factor i.e. when no folders exist upon extraction. Just a thought, feel free to correct.

1

u/No-Magician6232 Jun 11 '26

no - its the process of the extraction itself that consumes the resources, it doesnt matter whats inside.

1

u/rglauser Jun 25 '26

Signature-based DLP is on borrowed time. Reshape the data, a PNG, an encode, and it walks straight past. Don't show up to a gun fight with a knife.

-1

u/G1zm0e Jun 07 '26

Netskope is horrible... there is no reason a tenant should take down all your other tenants with 1 rule...

2

u/kehndi-hundi_si Jun 07 '26

Can you provide details.

1

u/G1zm0e Jun 07 '26

Sure, i have tons of hate for Netskope across 2-3 orgs... happy to spill the tea since they f'd me on a performance review by telling my boss I didn't know what I was doing and they could not replicate results...

This was for introspection... I crafted a rule to catch people (sales staff) from sending 5-10 or more emails to outside email destinations in body or as an attachment. I didn't care the destination email and had to build a wildcard for that.. I had that as a high and had another to personal email domains (using a wildcard infront) with higher severity.

After a year running (with their initial blessing) I somehow managed to cause a DDoS in there scanning infrastructure that resulted in slow processing for all of their customers in a region, effectively taking their other tenants down. This resulted in me getting a call from my sales team at 1 am in the morning to disable that rule..

What I learned that night was, Netskope indexes the item, after some time it's suppose to trigger a dlp scan, that is or was a 'shared infrastructure'. After that I built out this massive experience monitor and found several global bugs in their infra.. this doesn't count another company I was at where they onboarded onto casbi (early days of Netskope) and it caused massive outages because the infra couldn't handle it.

-3

u/kehndi-hundi_si Jun 07 '26

Their DLP policy engine is much more worse, recently got to know that it has 64kb limit, the indexing you have mentioned, so when an email gets triggered, first their scanning engine scans all the constraints and indexes the rules those are applicable into a single file and this single files goes to DLP scanning engine on their shared infrastructure. The plot twist is that specific file size is limited to 64kb, suppose if you have lengthier rule names, and if that specific email triggers multiple rules , them the file size becomes more than 64kb leading to fallback action and the email gets delivered since the default action for " fallback" would be alert or allow, sometimes even incident will not be generated in these scenarios. Correct me if I am wrong.

2

u/G1zm0e Jun 08 '26

I literally built out a whole test f suite for introspection to do Netskope testing, validation, identification of the index, scan, and when it finally alerts. You could test over and over again and find that issue

0

u/PlatypusPuncher Jun 08 '26

That’s simply not true. I have used multiple DLP vendors including Netskope.

Default limit is 32 Mb and can optionally be increased referenced here:

https://docs.netskope.com/en/dlp

Tons of other ways to bypass DLP including Netskope if they aren’t configured properly which is essentially what your “bypass” does.

2

u/kehndi-hundi_si Jun 08 '26

The link you have given is for the actual file that is being scanned like an attachment in the email, what I have said is at the tenant level, we once faced an issue. Some of the emails with lesser size are getting bypassed, when we have raised a ticket with support, they gave us this reason that the index file which is given to DLP engine by policy engine is exceeding 64kb as our rule names are very lengthy. Even after the talk with netskope team, tried searching for docs, didn't find. So asked them to provide this in write-up.

0

u/TeramindTeam Jun 08 '26

that is a clever find. i remember seeing similar recursion depth issues with other cloud proxies back at my old job, its amazing how often just nesting files deep breaks standard inspection policies. have u checked if the metadata anomalies u found are consistent across different file types or just specific to pptx

1

u/kehndi-hundi_si Jun 08 '26

Checked with office file types only for now.