# Using steganography in various channels to identify the source of a data leak Alexey Drozd · SearchInform MOSCOW FORENSICS DAY ’25 · Day 2 — Friday, 12 September 2025: information security day · Scheduled 16:10–16:40 · In the recording 07:51:30–08:13:23 Talk transcript · https://2025.moscow-forensics-day.workers.dev/en/transcript/18-drozd Summary: https://2025.moscow-forensics-day.workers.dev/en/summary/18-drozd · Slides: https://2025.moscow-forensics-day.workers.dev/en/slides/17-drozd-steganografiya · Watch from 07:51:30: https://youtu.be/4V7Wez3L_58?t=28290 --- ## Moderator's introduction Well, as we've all figured out today, sometimes a single file, some big one, can turn out to be something other than what it seems to be. So, for example, some holiday photo may hold not just palm trees, but also, say, an Excel file. That's what's called steganography, which today Alexey Drozd will be telling us about. A representative of SearchInform. Let's give him a round of applause and see what we've actually got here. ## Talk and Q&A Hello everyone. I've only let go of the microphone for a short while, it turns out. I wanted to rework the talk, but it was too late. Rework it how? To add a callback. Those who were here last year or remember last year's talk, I spoke about methodology, about the incident lifeline. So where does steganography come in? I look at it from one particular angle here, although users themselves also gravitate towards steganography to exfiltrate information, but more often, since you can't install just any software, or since steganography is still not for average minds, writing your own engine for it and getting further than copy /b and file concatenation. So users, for now, still mostly prefer cryptography, but in the sense of very primitive encoding, that is, attacking what DLP systems, for example, or other monitoring systems can't recognize. The most basic thing, which analysts almost the world over are waiting for, is that large language models will arrive, including LLMs, and solve this kind of primitive trick. A user exfiltrating some personal data hits Ctrl+F, find and replace, and replaces every digit 5 with the word "five". So all our personal data, which used to consist of, say, digits and was caught perfectly by regular expressions, now isn't caught so well by regular expressions. And there are a gazillion ways to come up with a trick that none of the DLP systems I know will see through without some neural nets and so on. So, steganography is also something a security officer needs. What does he need it for? Right, aha, now I understand why people kept switching the wrong way. Here's the UI/UX interface for you. The top button goes back, the bottom button goes forward. There you go, now you know. So, why does a security officer need steganography in itself? Precisely in order to lay down some straw in advance. If you look up or recall the incident lifeline, what is it? It's a timeline, and on it there's a point of no return, when the leak happened, when the information was taken out. We, as the now former owners, don't know what's done with it, how it's modified, where it's being distributed, who has access to it. So, the incident has already happened. This gives rise, in the minds of the security department, to a stage of an acute sense of impending apocalypse, that's a scientific term, well, not quite, those very 24 hours to respond, 72 hours to report something to someone, and so on. And so we enter that phase where, on the one hand, we need to investigate, which we can do, but on the other, it's useful to help the security officer find the point to dig from, to narrow the circle a bit. Right. How does this usually happen? Usually, what can a security officer do? Most often, using one tool or another, he uses the information-system-based approach, as I call it. What does it mean? Here we have that same overloaded interface with ugly buttons, but deadly effective. So, basically the data-centric security approach: every little action of the user, when it's intercepted, is intercepted with a bunch of attributes, that is, the content part, what exactly he sent over some channel, and a heap of attributes: who was CC'd, how many attachments, what types of attachments, IP, MAC address and so on. So what we're interested in, most often, in an investigation, is the account under which certain actions were performed by a certain user. And that's great, it works, it seems very convenient, and it can be applied in different guises, including, following the right advice, sometimes it really is better to draw a graph, because in a table the eye gets blurred. That is, some connections shown in a table are not at all obvious to the eye, and it turns out it was some mass mailing from a single external contact or something else. That these 10 rows are actually a bush, with 10 emails fanning out from a single node. However, the main problem with the information-system-based approach is that we have to be somehow integrated with that information system, so that as fully as possible, ideally at the driver level from the OS, we can pull the user's actions. Before you is a piece of, no longer a DLP, but a DCAP system, Data-Centric Audit and Protection, where the actions of the user with a given file are recorded, that is, at the driver level. Why is this necessary? Because an agent, for example, can't always get everything for you. That is, the agent of one system or another, an agent, well, in my terms, a DLP system agent is very good on Windows, almost as good on various Unix-likes, not very good yet on macOS, and practically useless if we're dealing with cloud logic. So if a user opened the already-mentioned Google Workspace, opened Docs in that Google and started writing a plan to take over and completely wreck the company. Right there, in the cloud text editor. From the agent's viewpoint and the actions we record for the user, what will we see? With a keylogger, say, we'll see that he's typing in some process or whatever, but a keylogger captures a stream. If the user got to item 10, then went back and fixed something in item 2, we still end up with gibberish, on the one hand. On the other hand, the main tool, if the user did all this in a browser, it seems we'd need to hook into HTTPS, the transport, intercept all the packets and see that the user was writing this bad document. But we can't do that, in the sense of assembling the whole document, because in that cloud logic, only a small state change is sent in each packet at a time. So a person starts writing a plan to take over the company. The first packet carries some technical junk, which font, which whatever, and the meaningful part: well, "PL", two letters. The next packet carries "AN", another one, something else. In the end, formally you have the entire capture, but no complete document to analyze. And where does it exist? It exists if you're integrated via API with that same Google Workspace, with VK, with Yandex 360, with M365 or Office 365 via the Graph API, and so on. And obviously, what's the problem in this case? Well, the problem is that you can't integrate with everyone out there. So besides the information-system-based approach, I consider two more approaches where steganography can help. The approach I've called user-session-based, that is, no matter which app the user is in, no matter how he does it, through the cloud, simply through VDI, and so on. What do we get in this case? You can't see it here, low contrast, but, for example, at the driver level certain watermarks are rendered, that is, on all monitors and so on. Where did such a solution come from in the world at all? From the problem of photographing the screen with a smartphone. That is, that's it, keeping any logs is useless. The user has access to this file, this information. He got access to it legitimately. And at the same time the DLP system is powerless too. That is, access is handled by all sorts of things, including DCAP. DLP is responsible for controlling information in motion, if the user decides to forward these files, but the user doesn't forward anything, he opened it and took a photo. So, starting from this problem, we got the user-session-based approach. That is, as one option, rendering watermarks, that is, some technical information is displayed, and so on. What for? Precisely so that, if we move along the incident lifeline, that is, when a leak happens and some screenshots surface, those taken with Print Screen or shots taken on a smartphone, then a screenshot with a hidden watermark will speed up handling the incident. That same security officer will take it, see it, bring out those watermarks, that is, the username, the machine name, date, time, text or whatever we decided to display in that watermark. So this approach is used on the Russian market too. Here's an example from, so to speak, colleagues in the trade. This is some public screenshot that I pulled. This is the company EveryTag, which does essentially the same thing. Here they say they can stuff a whole bunch of different attributes in through whitespace. That is, that very steganography, where each document is unique when a user requests it, thanks to certain shifts, either in line spacing, paragraph indents, left-right-up-down margins, and so on. And thanks to this, essentially, later, if a screenshot or photo of such a document surfaces, or a corresponding printout, you can extract the hash and see that it was John Doe who leaked it. So this is needed in addition to the information-system-based approach. However, there's an obvious problem here too. Fine, we've essentially solved one task, but there are more problems. Thinking about these problems, I identified four of them. So the first problem: we have technical limitations by format. You can't get into every format, not every format can you stuff steganography into, essentially, apply steganography. Although maybe you can. Still, there's a problem with this. And what do you do, say, with audio files? That is, fine, text, that's the approach from the previous slide, text is clear, but audio, when it gets leaked, what do you do there? Unclear. The architecture of such solutions has problems too. Architecture in the sense that ideally you need to always provide each user with a unique copy, a unique version of the file at any moment in time, so that it all keeps changing. And again we get the technical limitation by format on top, plus the fact that it's something client-server and so on, unclear. Technical problems with detecting the marks, the Achilles' heel. For example, our watermarks, which can simply be spread across all monitors at the driver level and so on. If you make them transparent enough that they, basically, are invisible to the user's eye, they show up perfectly if a screenshot is taken. However, if a smartphone was used in collaboration with the Russian hero Peresvet, that is, if you overexpose the shot, make it too bright, then naturally these marks disappear. You need to come up with something more robust. So there are also technical snags with detecting the marks. And there are also, in my view, exceptional situations. An example of one of them: when we say, embedded a mark, a file, written it in somehow, and a person opens this file and simply creates the same one beside it. Trivially, if we take a text document, a person legitimately opened the document, doesn't photograph it with a smartphone, doesn't copy-paste information out of it, but simply creates a new, completely unique document, astonishingly, letter for letter, with the same content. What do you do? Nothing. And it turns out that here steganography isn't our helper either, in terms of how that mark would suddenly end up in there. So, basically, given the limitations presented, we arrive at this idea. This is an unsolved problem. I didn't come here to sell you some of our elephants along the lines of "look, you've been living wrong all your life, and now we'll live right". No. Nevertheless, the popularity of the steganography approach has grown in the last two years, demand has grown, the number of requests we get from clients has also grown, saying let's implement this too. And attempts to solve this problem lead to the following conclusions, in my view. On the one hand, it's unlikely we'll manage to make something universal that would apply to all information transfer channels and to all formats, first and foremost, of information transfer. And a third variable is how to embed such a mark, or whatever it may be. I mean, well, steganography, what is it for us? It's when we've hidden one piece of information inside another, let's say, well, very simplified. As a result, for different channels, for a printer, say, it's still more convenient to use something of its own. For audio files or engineering drawings, better to invent something of their own. For text information, some third thing will work well. First conclusion. Second conclusion. Can we, in principle, still try to make something universal that would cover at least the majority of situations? In my view, yes. From the angle, again, of interpreting the term steganography, I believe these could be labels. But these labels cover the cases where the information hasn't leaked yet. But at least we won't let the information leave the protected perimeter at all. By labels I mean labels that can be set on the file's address in the system, or labels that are written directly into the file's metadata. That is, again, we're coming back to the same watermarks that, for example, are used by the makers of software for creating various deepfakes. That is, they made a kind of global agreement and committed to developing their tools responsibly. And if anyone uses their tool to create audio files, in the spectrum or wherever, in short, their own watermarks get embedded. Then detectors detect them well. So, accordingly, there's the same option with files: based on certain rules, either use an automatic label, or in parallel also use another label, this one, our manual labels, that is, a label that is written directly somewhere into the file. Naturally, hidden, naturally, so it can't be ripped out of there, naturally, so that it's inherited. And in this vein, steganography won't fully solve the leak problem for us, but combined with RMS logic it will, in principle, let us arrive at the following situation. That is, roughly speaking, so that a file, when transferred outside the protected perimeter, always goes in encrypted form. And if it reached the wrong recipient, well, that information couldn't be used then. And the encryption would then be based on the label. That is, we essentially take the well-known attribute-based access model, attribute-based access control, ABAC, and bolt encryption onto it, onto that logic, essentially reinventing that Microsoft RMS which once existed, and it turns out there's demand for it again now. So those are the ideas, and in my view the Russian market is moving towards these ideas. We're moving here too, with varying success across different channels. And I'd like to hear the opinion or counterarguments of those present on this as well. So steganography isn't such a scary thing, in my view. It will bring certain benefits, but you shouldn't think it's the one tool that will solve all problems. It's just a supplement. My personal view: in principle, the best incident is the one that never happened. So you shouldn't let it get to the point of execution at all, but catch all the insiders on takeoff, while still at the stage of forming intent or the information-gathering stage. That's all from me, thank you. — — Alexey, thank you very much. Right, let's move on to questions. — — Hello, thank you very much for the talk. First, this isn't even a question, more of a small addition regarding audio, because audio watermarks have existed almost since the 90s. And the second question. What's your view on the mechanisms used in Canarytokens? For example, that same zero pixel embedded in a document so you can later track whether the document was opened or not. The zero pixel here, I understand it, but I take a negative view, and here's why. Essentially, we then create the need for an active action, that is, a risk of exposure. Roughly speaking, I even had an exercise like this in my lab, this spy pixel. A one-pixel image is embedded in a document, and if it's leaked and someone opens it, it phones home to some service like an IP logger. So what's the problem? The problem is that as soon as a document like that gets opened, something starts flying out, something starts calling home somewhere. And maybe the security officer doesn't want to give himself away. So it's a useful thing, you can use it, but you need to do it wisely, and that kind of functionality should be something you can switch off, I think. — — Thank you very much. — — Okay, colleagues, any more questions? I see no hands. Alexey, thanks a lot. Oh no, the speaker again. Alexey, thank you very much. Let's give the speaker another round of applause. That was great.