How Attackers Can Hide Data Inside Images Lab
For this lab, I wanted to investigate a simple but interesting cybersecurity concept: how data can be hidden inside a file that appears completely harmless.
When we see a file called holiday.jpg, we naturally assume it's an image but in cybersecurity, we can't always rely on what a file appears to be.
Attackers can use techniques such as steganography to conceal information inside other files. The technique itself isn't inherently malicious, but it can be abused to make suspicious or sensitive data less obvious.
Rather than just reading about the technique, I decided to recreate a basic example myself using Windows 11 and then investigate the resulting file from a defensive perspective.
The experiment was deliberately harmless. I used a simple text file as the data being hidden and a normal JPEG as the cover file.
What I Wanted to Find Out
The main question behind the lab was:
Could I create a file that looked like an ordinary image but also contained additional data?
I also wanted to look at the experiment from two different perspectives.
First, the attacker perspective:
How could additional data be concealed inside something that doesn't immediately look suspicious?
Then the defender perspective:
What clues might tell me that the file isn't simply an ordinary JPEG?
Building the Test Environment
I started by creating a dedicated Windows 11 folder for the experiment.
I wanted to keep everything contained within one location so that I could easily see exactly what was happening to the files throughout the experiment.
Inside the folder, I created a harmless text file called:
confidential.txtThe file didn't contain any real confidential information. It simply contained text explaining that it was part of my cybersecurity experiment.
I then compressed the text file into a ZIP archive.
This gave me:
At this point, there was nothing particularly interesting happening. I simply had a text file, a ZIP archive and a JPEG image.
Creating the Suspicious Image
The interesting part came when I combined the JPEG and ZIP archive using Windows Command Prompt.
I used the Windows binary copy command:
copy /b holiday.jpg + confidential.zip holiday_secret.jpgThe command produced a new file:
holiday_secret.jpg
This was the point where the experiment became interesting.
I now had an image file that had additional data appended to it.
The First Test: Does It Still Look Like an Image?
I opened holiday_secret.jpg normally.
It opened as an image.
From the perspective of someone casually browsing the folder, there was nothing particularly suspicious about it.
It was still called:
holiday_secret.jpgand Windows treated it like an image.
This demonstrated the basic idea I wanted to investigate:
The presence of hidden data doesn't necessarily change what the user sees when they open the file normally.
Looking at the File Size
I then started looking at the file from a defensive perspective.
One of the first things I checked was the file size.
I compared the original JPEG with the modified version.
The modified image was larger because additional data had been added to it.
That doesn't automatically mean a file is malicious. Images can legitimately have different file sizes for countless reasons.
However, an unexpected size difference can become an interesting investigation lead when combined with other indicators.
Looking Beyond the File Extension
This experiment also reinforced something important about digital forensics:
A file extension isn't proof of what a file actually contains.
Seeing:
holiday_secret.jpgdoesn't necessarily tell an investigator everything about the contents of that file.
Security analysts can look deeper by examining things such as:
File headers
Magic bytes
File structure
Metadata
Hashes
Entropy
Behaviour
This is where the simple experiment starts becoming relevant to defensive security.
Checking the File Hash
I also generated a SHA-256 hash of the modified image using PowerShell.
I used:
Get-FileHash holiday_secret.jpg
A hash gives investigators a unique fingerprint for the file.
If the contents of the file change, the hash changes as well.
In a real investigation, hashes can be useful for documenting evidence, comparing files and identifying whether a file has been modified.
Looking at File Signatures
Another area I wanted to understand was file signatures, sometimes referred to as magic bytes.
Different file formats have characteristic byte sequences.
For example, JPEG files commonly begin with:
FF D8 FFZIP archives commonly contain:
50 4B 03 04This is important because a security analyst isn't necessarily limited to looking at the filename.
They can examine the actual data inside the file.
This is one of the biggest lessons I took from the experiment.
The filename tells me what Windows thinks the file is.
The file contents can tell me something much more useful.
Recovering the Hidden Data
After creating the file, I wanted to verify that the additional data wasn't just theoretical.
I opened the resulting image using 7-Zip.
7-Zip was able to recognise the archive data associated with the file.
I was then able to recover the original test file.
This confirmed that the additional data had successfully survived the process.
Looking at It From an Attacker's Perspective
The experiment gave me a simple demonstration of why techniques like this can be interesting to attackers.
Imagine receiving an attachment called:
holiday.jpgA normal user might simply open the photograph.
They may never think about what else could be contained within the file.
In a real attack, threat actors could potentially use more sophisticated forms of steganography to conceal information or payloads.
The important point isn't that every unusual image is malicious.
It's that attackers can take advantage of assumptions that users make about files.
Looking at It From a Defender's Perspective
The defensive side of the experiment was arguably more interesting.
Instead of asking:
"What does this file look like?"
a security analyst should be asking:
"Does this file behave and look internally like the type of file it claims to be?"
That can lead to questions such as:
Is the file size unusual?
Does its internal structure match its extension?
Are there unexpected file signatures?
Has the file been modified?
Where did it come from?
Was it downloaded from an unusual location?
Does endpoint telemetry show suspicious activity around it?
None of these indicators alone necessarily proves malicious activity.
Together, however, they can provide valuable investigative clues.
What I Learned
The biggest lesson from this lab wasn't actually the Command Prompt command.
It was the difference between appearance and reality when analysing digital files.
Before doing this experiment, it would have been easy to think about a JPEG simply as:
.jpg = imageAfter the experiment, that assumption doesn't seem quite as reliable.
Files have structure.
They have headers.
They contain data.
They have metadata.
And their extensions don't necessarily tell the whole story.
Why I Think This Makes a Useful Security Lab
I like labs like this because they're simple enough to reproduce on a Windows 11 machine but still demonstrate a genuine cybersecurity concept.
It also provides a useful way of thinking about the relationship between offensive and defensive security.
The attacker asks:
"How can I make this data less obvious?"
The defender asks:
"What evidence would reveal that something isn't right?"
Understanding the first question can help answer the second.
Final Thoughts
This was a relatively simple experiment, and it shouldn't be confused with the much more sophisticated techniques used by modern malware and threat actors.
However, it demonstrated an important cybersecurity principle:
Don't assume a file is safe simply because it looks harmless.
By recreating the technique in a controlled environment, I was able to see how easily assumptions about file types can be challenged.
For me, that's what makes hands-on cybersecurity labs useful.
Rather than simply reading that attackers can hide information inside files, I was able to reproduce the concept, examine the result and then approach the same file from a defender's perspective.
The real value wasn't learning how to hide the file.
It was learning how I might go about finding it.
Comments