NoiseCloud turns YouTube into a DLP problem

Hackaday covered NoiseCloud, a tool by Lucas Ferraz that converts files into video frames of high contrast visual noise. The project compresses input data, packs it into a visual format, renders it as MP4 with FFmpeg, and relies on the fact that video platforms are very good at accepting, storing, transcoding, and redistributing video.

That makes for a neat storage stunt. It also makes for a useful DLP conversation.

NoiseCloud is not magic. It is not encryption. The project documentation says as much: encrypt first if you need secrecy. But it does prove an awkward point for defenders: a channel does not have to look like file transfer to move files. Sometimes it looks like someone uploading a harmless video full of noise.

Why this matters for DLP

Most DLP programs are built around recognisable paths: email attachments, browser uploads, managed file sharing, removable media, source code repositories, paste sites, and sometimes chat tools. Those controls still matter, but they do not cover the whole problem.

A visual video carrier changes the shape of the data:

The original file becomes pixels.
The network transaction becomes a media upload.
The destination becomes a trusted consumer platform.
The stored object becomes a video that may survive recompression.
The payload may only be recoverable with the right decoder and parameters.

That is enough to bypass many lazy assumptions. If a DLP stack only asks "is this a document, archive, spreadsheet, database dump, or source file?", a video carrier is already outside its comfort zone.

The useful framing

This should not become "YouTube is evil" or "block all video uploads". That would be theatre, and not even good theatre.

The better framing is: public media platforms can act as dead drops when an insider or compromised endpoint can transform data before upload. YouTube is one example because it is large, normal, and video-native. The same class of problem can exist anywhere that accepts rich media and does heavy server-side processing.

For defenders, the question is not whether NoiseCloud itself is common in incidents. The question is whether your controls would notice this pattern at all.

What to look for

A practical hunt should combine endpoint, proxy, identity, and content signals. None of these indicators proves exfiltration on its own. Together, they get interesting.

Endpoint signals:

unusual use of FFmpeg, video encoders, frame extraction tools, or recently built Go utilities
archive, compression, or encryption activity followed by video creation
high entropy files being rendered into image sequences or MP4 files
short-lived working directories full of PNG frames or raw video intermediates
command lines that read sensitive file paths and write media outputs

Network and SaaS signals:

large video uploads from users or hosts that do not normally publish media
uploads to consumer video, short form, or social platforms from corporate networks
repeated failed or retried uploads after local video generation
browser uploads shortly after suspicious local encoding activity
new OAuth grants or sessions for consumer media platforms on managed devices

Content signals:

videos dominated by high contrast noise, grid-like blocks, calibration bars, or barcode-like frames
very low semantic video content despite large size or high duration
repeated uploads with similar dimensions, frame rates, and visual structure
metadata showing synthetic generation or unusual encoder settings

The trap is overfitting to one tool. Do not write a detection for the string noisecloud and call it done. That catches demos, not tradecraft.

A safe lab version

We maintain the hands-on DLP test case on the self-hosted S6 DLP test site, separate from the public marketing site:

NoiseCloud MP4 carrier DLP lab

The lab is deliberately framed as a defensive validation tool. It uses small benign payloads, makes the MP4 carrier visible, and keeps the operator in control of any external upload step. The point is to show the control failure mode without quietly turning the public website into an unattended exfil utility. A rare moment of restraint on the internet. We should probably mark the date.

Detection engineering angle

For a SOC or DLP team, this method belongs in a test suite as a class, not as a single exploit. The test case should ask:

Can the endpoint see sensitive data being transformed into media?
Can the network layer distinguish normal video viewing from unusual video uploading?
Can SaaS controls flag unmanaged consumer publishing destinations?
Can analysts correlate local encoding, browser upload, and identity context?
Can policy handle legitimate media teams without teaching everyone to ignore alerts?

That last one matters. If your marketing team uploads videos all day, the control cannot be "video upload bad". It has to understand who, where, how often, how large, and what happened immediately before the upload.

The S6 view

NoiseCloud is interesting because it abuses normality. Nobody needs a zero-day when the allowed path already moves gigabytes to someone else's infrastructure.

The defensive answer is not panic blocking. It is better coverage of data transformation, richer upload telemetry, and test cases that include weird carriers. DLP that only recognises office documents is a paperwork detector. Attackers and bored insiders have had more imagination than that for quite some time.