Infostealers & Session Hijacking

Disconnect it from the network. A full reinstall of the operating system is the only fully trustworthy outcome. If you clean rather than rebuild, understand that you are accepting residual risk.

Look for "sign out of all devices", "revoke sessions" or "where you are logged in" in each account's security settings. This is the step that actually evicts an attacker holding your cookies, and it is the step people skip.

Start with email, then banking and crypto, then everything reused. Email comes first because it is the reset channel for everything else.

Regenerate backup codes, since the old set may have been in a stolen file, and re-enrol authenticator apps where the service allows it.

Generate a fresh seed phrase on a clean device. If a wallet file or seed phrase was on the infected machine, that wallet must be treated as permanently compromised.

Go: open a terminal in a folder you can write to — cd ~/Desktop on macOS or Linux, cd %USERPROFILE%\Desktop on Windows.

Do: save this as login.py and run python3 login.py. This is an ordinary, correctly built login: the password is checked, then a second factor, and only then is a session created.

"""A perfectly ordinary login. Password, then a code from your phone."""
import json, secrets, time

USERS = {"sarah": {"password": "correct-horse-battery", "totp": "418907"}}
SESSIONS = "sessions.json"

def issue(user):
    token = secrets.token_hex(24)
    store = {token: {"user": user, "created": int(time.time())}}
    json.dump(store, open(SESSIONS, "w"))
    return token

def log_in(user, password, code):
    rec = USERS.get(user)
    if not rec or rec["password"] != password:
        return None, "wrong password"
    if rec["totp"] != code:
        return None, "wrong 2FA code"
    return issue(user), "logged in"

token, why = log_in("sarah", "correct-horse-battery", "418907")
print("password checked :", "yes")
print("2FA code checked :", "yes")
print("result           :", why)
print("cookie issued    :", len(token), "hex characters =", len(token) * 4, "bits")
print()
print("This token is now written to sessions.json, and in a real browser")
print("to the cookie store on disk. It is what proves you are Sarah.")

You should see: a successful login and a token written to disk:

password checked : yes
2FA code checked : yes
result           : logged in
cookie issued    : 48 hex characters = 192 bits

This token is now written to sessions.json, and in a real browser
to the cookie store on disk. It is what proves you are Sarah.

The token's value is different every run and is deliberately not printed — 192 bits of randomness is far beyond guessing, which is exactly right and is not the weakness here. Note what the server has just done: it verified two factors once, and then created something that stands in for that verification from now on. Every website works this way, because the alternative is asking for your password on every click.

If not: PermissionError means the folder is not writable — cd somewhere you own. If it prints wrong 2FA code, the string in USERS and the one passed to log_in differ; both are "418907".

Go: the same folder.

Do: save this as peek.py and run python3 peek.py.

"""What the token alone is worth."""
import json

store = json.load(open("sessions.json"))
token = list(store)[0]

def whoami(presented_token):
    rec = store.get(presented_token)
    return rec["user"] if rec else None

print("the server is asked: who is holding this token?")
print("   answer:", whoami(token))
print()
print("password required to get that answer :", "no")
print("2FA code required                    :", "no")
print("device or location checked           :", "no")
print()
print("A session token is a bearer credential: whoever holds it IS the user,")
print("for as long as it lasts. That is the whole design, and it is why")
print("stealing one is worth more than stealing a password.")

You should see: full identification, with nothing else supplied:

the server is asked: who is holding this token?
   answer: sarah

password required to get that answer : no
2FA code required                    : no
device or location checked           : no

A session token is a bearer credential: whoever holds it IS the user,
for as long as it lasts. That is the whole design, and it is why
stealing one is worth more than stealing a password.

“Bearer credential” is the term worth keeping. It means possession is the whole of the claim — like a train ticket, which does not care who is holding it. A password is something you know and can be protected by a second factor; a session token is something you have, and once someone else also has it, they have the same thing you do.

This is why session theft outranks password theft for an attacker. A stolen password meets your 2FA. A stolen session was issued after your 2FA.

If not: FileNotFoundError: sessions.json means step 1 has not been run in this folder. If answer prints None, the token being looked up is not the one in the file — the script deliberately reads whichever token is there rather than hard-coding one.

Go: the same folder.

Do: save this as exfiltrate.py and run python3 exfiltrate.py. Real infostealers sweep browser profile folders for the cookie database and the saved-password store; sessions.json stands in for those.

"""What an infostealer actually does: copy files, then leave."""
import json, os, shutil

# The real thing sweeps browser profile directories for exactly these.
WANTED = ["sessions.json"]          # stands for cookies.sqlite / Login Data / Local State

os.makedirs("attacker-machine", exist_ok=True)
taken = []
for name in WANTED:
    if os.path.exists(name):
        shutil.copy(name, os.path.join("attacker-machine", name))
        taken.append((name, os.path.getsize(name)))

for name, size in taken:
    print("copied %-16s %d bytes" % (name, size))
print()
print("time on the machine :", "under a second")
print("files changed       :", 0)
print("processes left behind:", 0)
print()
print("Nothing was encrypted, nothing was deleted, nothing popped up.")
print("There is no moment at which the victim notices anything.")

You should see: a copy taken, and nothing else touched:

copied sessions.json    94 bytes

time on the machine : under a second
files changed       : 0
processes left behind: 0

Nothing was encrypted, nothing was deleted, nothing popped up.
There is no moment at which the victim notices anything.

Read the three zeros again. This is the reason infostealer infections are usually discovered weeks later, from the consequences rather than the event: the software has no reason to stay, nothing to encrypt and no need for persistence. It runs once, copies files, and leaves.

It is also why the usual reassurance — “my computer is running fine, so I'm clearly not infected” — carries no information at all.

If not: if copied does not appear, sessions.json is missing; re-run step 1. The byte count is stable at 94 for this file, so a different number means the token length or the record shape was changed.

Go: the same folder.

Do: save this as replay.py and run python3 replay.py.

"""The attacker, on his own computer, in another country."""
import json

# He never saw the password and never had the phone. He has the file.
stolen = json.load(open("attacker-machine/sessions.json"))
token = list(stolen)[0]

# The real server, checking the token it issued.
server = json.load(open("sessions.json"))

def whoami(presented_token):
    rec = server.get(presented_token)
    return rec["user"] if rec else None

print("attacker presents the stolen token")
print("   server says you are:", whoami(token))
print()
print("password entered :", "never")
print("2FA prompt shown :", "never")
print("login email sent :", "never -- no login happened")
print()
print("This is why victims report 'I was hacked but my password still works")
print("and I got no alert'. There was no login to alert on.")

You should see: the attacker recognised as the user, with no login taking place:

attacker presents the stolen token
   server says you are: sarah

password entered : never
2FA prompt shown : never
login email sent : never -- no login happened

This is why victims report 'I was hacked but my password still works
and I got no alert'. There was no login to alert on.

The last two lines explain the whole confusing aftermath. There was no login, so there is no login alert, no new-device email, and nothing in the “recent sign-ins” list to look at. Changing the password afterwards does not help either, unless the service also invalidates existing sessions — the token was issued before the change and, unless explicitly revoked, remains valid after it.

So if you ever suspect this has happened to you, the action is not only “change the password” but “sign out of all devices” — which most major services offer, usually under security settings, and which is the control that actually kills the stolen token.

If not: if the server does not recognise the token, the copy in attacker-machine/ is from an earlier run — delete that folder and repeat step 3, because each run of step 1 issues a new token.

Go: the same folder.

Do: save this as bind.py and run python3 bind.py.

"""Three defences, tested against the same stolen token."""
import json, time

server = json.load(open("sessions.json"))
token = list(server)[0]
rec = server[token]

# The server records what the session was born on, not just who it belongs to.
rec["ip_prefix"] = "203.0.113"
rec["user_agent"] = "Firefox/141.0 Linux"
rec["created"] = int(time.time()) - 60 * 60 * 30      # thirty hours ago

MAX_AGE = 60 * 60 * 24                                 # sessions expire after a day

def check(presented, ip_prefix, user_agent, action="read"):
    r = server.get(presented)
    if not r:
        return "rejected: unknown token"
    if time.time() - r["created"] > MAX_AGE:
        return "rejected: session older than %d hours" % (MAX_AGE // 3600)
    if ip_prefix != r["ip_prefix"] or user_agent != r["user_agent"]:
        return "rejected: does not match the device this session was created on"
    if action == "change-email":
        return "allowed to read, but re-enter your password to change the email"
    return "accepted as " + r["user"]

print("legitimate user, same laptop, session 30 hours old")
print("  ", check(token, "203.0.113", "Firefox/141.0 Linux"))
print()
rec["created"] = int(time.time())
print("legitimate user, same laptop, fresh session")
print("  ", check(token, "203.0.113", "Firefox/141.0 Linux"))
print()
print("attacker, stolen token, his own machine")
print("  ", check(token, "185.244.31", "Chrome/139.0 Windows"))
print()
print("attacker, stolen token, trying to change the recovery email")
print("  ", check(token, "203.0.113", "Firefox/141.0 Linux", action="change-email"))

You should see: the same stolen token failing, and a legitimate session surviving:

legitimate user, same laptop, session 30 hours old
   rejected: session older than 24 hours

legitimate user, same laptop, fresh session
   accepted as sarah

attacker, stolen token, his own machine
   rejected: does not match the device this session was created on

attacker, stolen token, trying to change the recovery email
   allowed to read, but re-enter your password to change the email

Three separate controls are at work, and the fourth case is the subtlest. The expiry limits how long a theft is useful. The binding ties the session to the device and network it was created on, so a token used from elsewhere is refused. And step-up authentication means that even a session which passes both checks must re-enter the password before changing the recovery email — because that single change is how a temporary intrusion becomes permanent ownership of the account.

None of these is something you configure as a user; they are decisions the service made. What you can do is prefer services that make them, and use the two controls you do have: review active sessions occasionally, and sign out of all devices whenever anything feels wrong.

If not: if the first case is accepted rather than rejected, the arithmetic on the created line was altered — it must place the session thirty hours in the past, which is beyond the one-day MAX_AGE. If every case is rejected as unknown token, re-run step 1 first.