Vishal Tharu
← All writeups

Network forensics TryHackMe · Hacker Holidays, Day 4

Every keystroke, smuggled out one letter at a time

A guest laptop was quietly sending everything typed on it to an attacker — one character per web request, hidden in the part of a request nobody inspects.

  • T1056.001 Input Capture: Keylogging
  • T1041 Exfiltration Over C2 Channel

What I was given

A packet capture — a recording of everything that crossed a network for a period of time. Somewhere in it, a laptop was betraying its owner.

How the data got out

Programs that record what you type have an obvious problem: getting the recording out. Sending a big file is conspicuous. Anything that looks like a file transfer to a strange address invites questions.

So this one did not send a file. It sent one keystroke per web request, and hid each one inside a cookie.

Cookies are the small pieces of text a browser attaches to requests so a website remembers who you are. They are meaningless-looking by design, they are on almost every request on the internet, and essentially nobody reads them. A perfect place to hide something.

Each keystroke was scrambled with a simple reversible trick and then encoded into harmless-looking characters, so the traffic read as one more browser talking to one more web server.

The mistake that unravelled it

The capture also contained the keylogger’s own source code, sent in the clear.

So the encryption did not need breaking. It needed reading. The program explained exactly how it scrambled each character, which made reassembling the stolen keystrokes a matter of putting the requests back in order and running the process backwards.

That is a more realistic finding than it sounds. Attackers make ordinary mistakes — staging a tool over the same channel they exfiltrate with, forgetting that a capture records everything, not just the part they were thinking about.

Where I lost time

I initially reassembled the keystrokes in the order the packets appeared in the file, which is not necessarily the order they were typed. Requests arrive out of order, get retransmitted, and interleave. The first version of my output was almost right, which is the worst way to be wrong — close enough to look like a solution and wrong enough to be useless.

How you would actually catch this

The traffic is well disguised. The behaviour is not.

  • A session cookie that changes on every single request is not a session. Real session cookies stay the same for hours. This one was different every time, because it was the data. That single anomaly gives it away with no knowledge of the encryption at all.
  • Cookie contents that look random rather than like a normal identifier. Measuring the randomness of cookie values across a proxy is cheap and this stands out.
  • The rhythm is wrong. Human browsing is bursty — a page, then a pause. One tiny request per keystroke produces a steady trickle no human browsing pattern resembles.
  • The destination. Web traffic to a plain IP address on an unusual port, with no domain name, is worth a question on its own.

The reason I like this one: the detection needs no signature, no threat feed and no knowledge of this specific malware. It only needs someone to notice that a thing which should be stable is changing constantly.

Flags are redacted throughout. These are learning writeups, not answer keys.