Hidden in Plain Sight: Steganography, EXIF Geolocation, and AI-Powered Log Analysis

A few weeks back I went down a rabbit hole that started with one simple question: how easy is it, really, to hide a secret inside an ordinary-looking JPEG — and how would a defender ever catch it?

That question turned into a full weekend project covering two very different but connected corners of security work: steganography (hiding and finding secrets inside media files) and log analysis (finding the story hidden inside thousands of boring log lines). Along the way I leaned on AI tools to speed up both the detection and the analysis side, which turned out to be the most interesting part of the whole exercise.

This post walks through everything I did — extracting a hidden message from an image, pulling GPS coordinates out of EXIF metadata, running an AI-assisted steganalysis scan, and finally using an AI assistant to triage 10,000 lines of Apache access logs for suspicious activity.

Problem Statement

Two questions I wanted real, hands-on answers to:

1. Can hidden data inside an image actually be detected and extracted reliably — and can AI meaningfully help with that detection?
2. When you're staring down a huge pile of raw system or web server logs, can AI actually speed up finding the anomalies, or is it just noise?

The best way to answer both was to just do it: hide/extract data myself, run it through an automated steganalysis pipeline, then separately dig through real authentication logs and a public Apache access log dataset.

Step-by-Step Walkthrough

1. Extracting a hidden message with Steghide

steghide is a classic LSB (Least Significant Bit) steganography tool — it embeds a file inside an image or audio file by making tiny, visually imperceptible changes to pixel data. Extraction is just the reverse of that process.

Given a suspicious image (mons.jpg), extraction looked like this:

steghide extract -sf /home/khalif/Desktop/mons.jpg
Enter passphrase:
the file "secret.txt" does already exist. overwrite ? (y/n) y
wrote extracted data to "secret.txt".

You can also point it at a specific output path with -xf:

steghide extract -sf /home/khalif/Desktop/mons.jpg -xf /home/khalif/Desktop/secret.txt
Enter passphrase:
wrote extracted data to "/home/khalif/Desktop/secret.txt".

And then just read it:

cat secret.txt
Every secure system is just undiscovered weak logic.

2. Pulling the exact location from EXIF metadata

Images from phones often carry a lot more than pixels — camera make/model, timestamps, and sometimes precise GPS coordinates, all sitting quietly in the EXIF header. exiftool makes this trivial to pull out:

exiftool /home/khalif/Desktop/picture.jpg

Buried in the output were the geolocation fields:

GPS Latitude    : 25 deg 43' 56.97" N
GPS Longitude   : 89 deg 15' 22.66" E
GPS Position    : 25 deg 43' 56.97" N, 89 deg 15' 22.66" E

This is a good reminder for anyone sharing photos online: metadata can leak far more than people realize, and it takes one command to pull it back out.

3. AI-assisted steganalysis with Aperi'Solve

Manually trying every steganalysis technique against a suspicious file gets old fast, so I ran the same image through Aperi'Solve, a web-based tool that automates a whole pipeline of steganalysis checks — bit-plane decomposition, zsteg-style extraction, steghide, outguess, jsteg, jpseek, metadata inspection, and more — all in one pass.

The results confirmed what I already knew from the manual extraction, but automatically:

• Decomposer / bit-plane analysis — ran successfully, showing the superimposed color-channel breakdown
• Steghide module — flagged Success and independently extracted the same secret.txt file
• Jsteg — reported no hidden data (correctly, since the image wasn't encoded with that method)
• Outguess — failed to extract (also expected, wrong technique for this file)

This is where AI/ML genuinely earns its keep in steganalysis: instead of manually running six different tools against every suspicious file, an automated pipeline (and increasingly, CNN-based classifiers trained on stego vs. clean images) can flag which files deserve a closer human look, at scale.

4. Practicing log analysis fundamentals

Before touching real data, I worked through two hands-on labs to build a mental model of what "normal" log activity looks like versus a genuine compromise:

• Log fundamentals — logging sources, formats, standards, centralization, retention, and hands-on filtering practice
• Windows incident investigation — tracing an actual breach through Windows event logs: identifying the attacker's foothold, a malicious scheduled task, credential dumping via Mimikatz, the external C2 IP address, a webshell dropped through a vulnerable upload endpoint, and even DNS poisoning targeting a legitimate domain

Working through a real (simulated) breach start-to-finish made it obvious how much of incident response is just pattern recognition across timestamps — which set up the next part perfectly.

5. Building a timeline from my own system logs

Next I turned to my own Kali VM and filtered journalctl for anything security-relevant:

sudo journalctl --since "2026-08-08" | grep -Ei "failed|failure|authentication|invalid|sudo|session opened|session closed" | tail -100

Scanning the filtered output, one sequence stood out:

01:08:45 - Password check failed for user khalif
01:08:45 - PAM reported authentication failure
01:08:49 - xfce4-screensaver: setuid failed: Operation not permitted

I laid the surrounding events out as a timeline:

Time	Observed Event	Analysis
01:08:45	Password check failed for user	Authentication anomaly detected
01:08:45	PAM reported authentication failure	Confirms the failed authentication
01:08:49	setuid operation failed	Permission-related system error
01:09:01	Root CRON session opened and closed	Routine automated activity
01:09:34	User executed a command via sudo	Administrative activity
01:11:37	User accessed apt history log via sudo	Related to investigation
01:12:41	User ran journalctl via sudo	Related to investigation

Important nuance: a failed login plus a setuid error doesn't automatically mean "attacker." It's just as likely to be a mistyped password followed by an unrelated desktop-session hiccup. I flagged it as anomalous and worth a second look, not as confirmed malicious activity — that distinction matters a lot in real incident response, where over-alerting burns analyst trust just as fast as under-alerting does.

6. Turning an AI assistant loose on 10,000 log lines

For the second half of the log analysis, I grabbed a public sample Apache access log (10,000 entries) and uploaded it straight to an AI assistant with a simple prompt: analyze this for anomalies and suspicious activity.

The model parsed all 10,000 entries and came back with a structured breakdown covering status code distribution, top requesting IPs, User-Agent patterns, HTTP methods, and known-bad URL signatures. It surfaced three genuinely interesting findings:

• Coordinated CMS admin-panel scanning — repeated hits on /wp-login.php and /administrator/index.php from multiple IPs, all with blank User-Agent strings (a classic automated-scanner fingerprint)
• A vulnerability scan targeting the FCKeditor file-upload exploit — an old but still commonly probed-for vulnerability
• Repeated failed requests from an automated client pointing at a missing file — this one turned out to be a misconfiguration, not an attack, once the requesting client was identified

Every one of the suspicious requests returned a 403 or 404, meaning none of the scans actually succeeded — but the pattern-matching itself, done in seconds across 10,000 lines, is exactly the kind of triage work that would take a human analyst a lot longer to do by hand.

How to Verify

If you want to reproduce any of this:

1. Steghide extraction — install with sudo apt install steghide, then run steghide extract -sf <image> on a known stego-embedded file.
2. EXIF metadata — install with sudo apt install libimage-exiftool-perl, then run exiftool <image> and check for GPS Latitude / GPS Longitude fields.
3. Aperi'Solve — upload any image at aperisolve.com and check which modules return "Success" versus "No result."
4. journalctl filtering — adjust the --since date and the grep -Ei pattern to match your own system's timestamps, then confirm the flagged lines correspond to real login attempts (last -f /var/log/wtmp is a good cross-check).
5. AI log triage — grab any public Apache/Nginx access log sample, upload it to an AI assistant, and compare its flagged IPs/paths against a quick manual grep for wp-login, admin, or .php in the same file.

What I Learned

Working through both halves of this project side by side made the connection between them a lot clearer than I expected. Steganography and log analysis are really the same underlying skill wearing two different outfits: finding a meaningful signal buried inside a huge amount of ordinary-looking noise. Whether that noise is pixel values in a JPEG or ten thousand HTTP requests, the workflow is the same — narrow the field with automated tooling, then apply human judgment to what's left.

The other big takeaway was about calibration. AI tools are genuinely fast at flagging candidates — a suspicious image, a burst of failed logins, a scanning pattern in a log file — but they're not a verdict machine. The "anomalous, not confirmed malicious" framing I used for my own auth logs is the right default posture, and it's one I plan to carry into any future investigation work.

Common Mistakes

Mistake	Why It's a Problem	Better Approach
Assuming a failed login = an attack	Password typos and session glitches happen constantly	Cross-reference multiple log sources before concluding malicious intent
Only running one steganalysis tool	Different embedding techniques need different detection tools	Run a multi-tool pipeline (or an automated one) so no single blind spot slips through
Ignoring EXIF metadata on shared images	Photos can leak precise GPS location without anyone realizing	Strip metadata (exiftool -all=) before sharing sensitive images publicly
Treating every AI-flagged anomaly as confirmed	Automated flags are a starting point, not a conclusion	Always validate AI findings against raw log evidence before acting
Skipping a proper timeline	Isolated log lines are hard to interpret out of context	Lay events out chronologically — the sequence often tells the real story

Conclusion

Hiding a message in an image and hiding an attack in a wall of logs turn out to require the exact same mindset: assume there's a signal in the noise, narrow it down systematically, and don't stop at the first tool's output. AI made both halves of this project noticeably faster — automated steganalysis pipelines and AI-assisted log triage both did in seconds what would've taken a lot longer by hand — but the actual judgment calls, like distinguishing "anomalous" from "confirmed malicious," still came down to careful, manual reasoning.

If you're getting into digital forensics or blue-team work, I'd genuinely recommend doing both halves of this exercise yourself — hide something in an image and try to find it, then pull a public access log and go hunting. It sticks a lot better than reading about it.