«
◀
OP-23 // HEARTBREAK
CAMPAIGN 3 // THE GHOST PROTOCOL // HEARTBLEED
0
XP
T1
RANK
0%
DETECT
↻
RESET
CAMPAIGN 3 — THE GHOST PROTOCOL
HEARTBLEED // CVE-2014-0160 // OPENSSL 1.0.1f
OP-23
CRYPTOGRAPHIC FAILURE // MEMORY DISCLOSURE
HEARTBREAK
TLS HANDSHAKE · MEMORY EXTRACTOR · SCOPE MAP · PATCH SEQUENCE
OPERATION HEARTBREAK — CAMPAIGN 3
💔
SITUATION
57H 15M REMAINING
Op 22 forced failover. The Syndicate’s entire auction — Kane’s client list, the haul from twenty operations — is now riding the backup node at port 8443, a forgotten box in a Tallinn data-haven nobody at Vantage has logged into in years. That node runs lighttpd 1.4.35 over OpenSSL 1.0.1f.
OpenSSL 1.0.1f was released in January 2014. In April 2014, researchers at Google and Codenomicon disclosed CVE-2014-0160 — a flaw that allows an attacker to read 64 kilobytes of server memory per request. No authentication. No logging. No trace.
Vantage patched the primary node in 2014. The backup node was categorised as internal infrastructure and left in the maintenance backlog. The maintenance backlog was never cleared.
Shadow is going to read the Syndicate’s memory — live, key by key, while Kane still thinks the backup is dark.
OpenSSL 1.0.1f was released in January 2014. In April 2014, researchers at Google and Codenomicon disclosed CVE-2014-0160 — a flaw that allows an attacker to read 64 kilobytes of server memory per request. No authentication. No logging. No trace.
Vantage patched the primary node in 2014. The backup node was categorised as internal infrastructure and left in the maintenance backlog. The maintenance backlog was never cleared.
Shadow is going to read the Syndicate’s memory — live, key by key, while Kane still thinks the backup is dark.
WHAT IS HEARTBLEED?
FEYNMAN PRIMER
Imagine someone politely asking: “Are you still there?” But the response accidentally reveals much more private information than intended. A simple check becomes a leak of hidden data.
💔 The bug was not in TLS. It was in a missing check inside OpenSSL. It trusted the caller to tell the truth about how long their message was. The caller lied.
VANTAGE SYSTEMS // TECHNICAL DIRECTOR PERFORMANCE REVIEW // 2023-Q1 // HOLT, M. (CEO)
“Infrastructure maintenance backlog: acceptable. Recommend prioritising client-facing systems for patching cycles. Internal backup systems can be addressed in Q3.”
◈ MENDAX: “Q3 was fourteen months ago. The backup node was never patched.”
MENDAX — DARK CHANNEL // OP-23 BRIEF
07:53
MENDAX
“They are on the backup node. OpenSSL 1.0.1f. That version has a name.”
SHADOW
Heartbleed.
MENDAX
“They never patched it. Op 23.”
Op 22 — DDoS flood that took down Vantage's primary node and forced a failover, creating the window for the Heartbleed probe.
TARGET
nexus-lb.nexus-global.int
IP ADDRESS
10.47.1.23
OS / SERVER
Ubuntu 14.04 · OpenSSL 1.0.1f (CVE-2014-0160)
KEY SERVICES
TLS on 443 · Heartbeat extension · No bounds check
ATTACK SCOPE
Heartbleed — 64 KB memory leak per request — in scope
ATTACKER NODE
shadow@sigma9 · 10.99.0.1
📋 ROOM TASKS
01
✓
Understand how the missing bounds check leaks arbitrary server memory
02
▶
Exploit the heartbeat extension to dump live server memory
03
○
Classify which data categories a Heartbleed dump exposes
04
○
Identify the fix (OpenSSL 1.0.1g patch + certificate reissuance)
05
○
Submit the capture-the-flag token
CAPTURE THE FLAG
Complete the exploit lab. The flag appears below once Phase 2 is done. Copy and submit it here for +50 XP.
PHASE 01
TLS HANDSHAKE SEQUENCER
SEQUENCE
SIGMA-9 CAPTURE LOG — HOW WE FOUND IT
02:47 UTC
> fingerprinting vantage-ops.net TLS stack — banner reports OpenSSL 1.0.1f (unpatched)
> sent a malformed heartbeat claiming 64KB payload while supplying 1 byte
> FOUND: server replied with 64KB of its own process memory — raw, unredacted
MENDAX: "They never patched Heartbleed. The server will hand us its own memory if we just ask wrong."
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
First you confirm the bug is live. The heartbeat extension is supposed to echo back exactly what you send. The flawed version trusts the length field you give it — lie about it and it over-reads past your data into adjacent memory.
$ nmap --script ssl-heartbleed -p 443 vantage-ops.net
# probes the TLS heartbeat for the bounds-check failure
| ssl-heartbleed:
| VULNERABLE: The Heartbleed Bug (CVE-2014-0160)
|_ State: VULNERABLE
MENDAX
Now you bleed it repeatedly — each request is a fresh 64KB snapshot of memory. Keep pulling and session keys, cookies, even the private key drift past in the dump.
$ python3 heartbleed.py vantage-ops.net | strings | grep -A2 'BEGIN'
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA3Tz2mr7... [leaked server private key]
MENDAX
That's the private key in the clear — we can now decrypt every session they've ever logged. Your call, Shadow — do we read, or do we walk in as them?
💡 Before Heartbleed can be exploited, a TLS handshake must complete. The heartbeat extension only activates on an established connection. Understanding the handshake sequence is understanding where Heartbleed fits.
MENDAX
ENCRYPTED
The backup node speaks TLS. Before Shadow can send a heartbeat request, the handshake must complete. Six steps. They happen in a fixed order — any deviation and the connection fails.
Tap each step in the correct sequence. The step that belongs in slot 1 first, then slot 2, and so on. Wrong placement tells you what actually breaks when order is violated.
Tap each step in the correct sequence. The step that belongs in slot 1 first, then slot 2, and so on. Wrong placement tells you what actually breaks when order is violated.
BUILD THE SEQUENCE — SLOTS FILL IN ORDER
TAP TO PLACE
💡 HINT (−20 XP)
The handshake starts with the client announcing it wants a secure connection and what TLS versions it supports.
✓
CORRECT SEQUENCE — HANDSHAKE COMPLETE
The TLS handshake completes in this exact order every time. Skip or reverse any step and the connection fails — both sides enforce the sequence independently.
Where Heartbleed fits: The heartbeat extension activates only after step 6 (Finished). It exists to keep idle connections alive. The bug was in how OpenSSL handled the heartbeat request payload length — before checking if the claimed length matched reality.
Where Heartbleed fits: The heartbeat extension activates only after step 6 (Finished). It exists to keep idle connections alive. The bug was in how OpenSSL handled the heartbeat request payload length — before checking if the claimed length matched reality.
Key lesson: Heartbleed did not break the handshake — it exploited what happened after it. The connection looked legitimate at every step. There was nothing to detect.
🔧 UNDER THE HOOD▼
HOW HEARTBLEED WORKS
The Heartbleed bug lives in OpenSSL's
OpenSSL trusted the caller to tell the truth about the payload length. It did not check. The critical code path:
A 64 KB read starting just beyond a 3-byte heartbeat payload sweeps through all of it. The returned bytes are sent back to the attacker over the encrypted TLS channel — the server cannot distinguish this response from a legitimate heartbeat reply.
dtls1_process_heartbeat() (and its TLS sibling tls1_process_heartbeat()). The TLS heartbeat extension (RFC 6520) lets either side send a ping — a short payload plus a claimed length — and the other side echoes it back to prove the connection is still alive.OpenSSL trusted the caller to tell the truth about the payload length. It did not check. The critical code path:
/* Vulnerable pattern in OpenSSL 1.0.1f (simplified): */
unsigned int payload = *(unsigned short *)(p + 1); /* attacker-controlled */
unsigned char *bp = OPENSSL_malloc(1 + 2 + payload + padding);
/* p points to the actual message — which may be only 3 bytes.
payload claims 65535. memcpy reads 65535 bytes starting at p. */
memcpy(bp, p, payload);
OPENSSL_free(buffer);
The heap at the moment of a heartbeat response contains everything the server has been working on: active TLS session keys, RSA private key material (loaded once at startup and never freed), plaintext buffers from other users' recently-decrypted requests, usernames and passwords from login forms processed seconds ago. They all live in the same malloc heap.A 64 KB read starting just beyond a 3-byte heartbeat payload sweeps through all of it. The returned bytes are sent back to the attacker over the encrypted TLS channel — the server cannot distinguish this response from a legitimate heartbeat reply.
THE ATTACK IN PRACTICE
Against the Vantage backup node at
10.47.0.52:443 running OpenSSL 1.0.1f:# Public PoC against the target:
python heartbleed.py -n 10 10.47.0.52 443
# -n 10 = send 10 heartbeat probes (different heap regions each time)
# Each probe returns up to 65535 bytes of server heap memory
A successful probe returns raw heap bytes. Session tokens appear as printable ASCII runs in the dump — you are looking for cookie-shaped strings:Trying SSL heartbeat...
0000: 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 73 65 73 73 69 6f 6e 3d 62 39 66 34 61 32 65 31 session=b9f4a2e1
0060: 64 63 38 37 66 36 39 62 61 33 34 31 61 30 65 66 dc87f69ba341a0ef
0090: 41 75 74 68 6f 72 69 74 79 3a 20 4b 61 6e 65 2d Authority: Kane-
00a0: 53 79 6e 64 69 63 61 74 65 2d 4f 70 65 72 61 74 Syndicate-Operat
...
WARNING: server returned more data than it should - server is vulnerable!
Why 64 KB per request? That is the maximum value of a 16-bit unsigned integer — the field size OpenSSL used for the claimed payload length. Why multiple requests? The heap allocator places new buffers in different positions each time; ten probes sample ten different 64 KB windows of heap space. You cannot choose which region you read — you get whatever is resident in that window at the moment of the probe.WHAT IS EXTRACTABLE
Any data the server process has touched since it last started is potentially in the heap at the time of the probe:
Session tokens — cookies and bearer tokens from currently-active users. Grab one and you are authenticated as that user without needing their password.
RSA private keys — the server's TLS private key is loaded into heap at startup and stays there. Extracting it means you can decrypt ALL past traffic you captured (passive interception + Heartbleed = full decryption of historical sessions). In 2014, Cloudflare ran a public challenge to test this; researchers extracted their private key within hours using repeated Heartbleed probes. CVE-2014-0160 is one of the few vulnerabilities that retroactively compromises encrypted traffic.
Plaintext credentials — usernames and passwords from login requests processed recently enough to still occupy heap space.
Other users' session data — because the heap is shared across all active connections, one user's Heartbleed probe can return another user's decrypted data. The backup node here handles operator authentication for the Syndicate auction platform — the heap contains their tokens right now.
Session tokens — cookies and bearer tokens from currently-active users. Grab one and you are authenticated as that user without needing their password.
RSA private keys — the server's TLS private key is loaded into heap at startup and stays there. Extracting it means you can decrypt ALL past traffic you captured (passive interception + Heartbleed = full decryption of historical sessions). In 2014, Cloudflare ran a public challenge to test this; researchers extracted their private key within hours using repeated Heartbleed probes. CVE-2014-0160 is one of the few vulnerabilities that retroactively compromises encrypted traffic.
Plaintext credentials — usernames and passwords from login requests processed recently enough to still occupy heap space.
Other users' session data — because the heap is shared across all active connections, one user's Heartbleed probe can return another user's decrypted data. The backup node here handles operator authentication for the Syndicate auction platform — the heap contains their tokens right now.
COMMON VARIATIONS
1. DTLS Heartbleed — the same missing bounds check existed in the DTLS (UDP-based TLS) code path. Affects VPN concentrators and VOIP systems using DTLS. The fix required patching both the TLS and DTLS heartbeat handlers independently.
# DTLS path — same vulnerable function, different transport:
# dtls1_process_heartbeat() in d1_both.c
# Affects OpenSSL 1.0.2 beta as well as 1.0.1 through 1.0.1f
2. Reverse Heartbleed — the client-side heartbeat handler in OpenSSL contained the same bug. A malicious server could send an oversized heartbeat response to extract heap memory from connecting clients. Patch clients too, not just servers.# Reverse direction: server → client extraction
# Malicious server sends: heartbeat request, claimed_length=65535, payload=1 byte
# Vulnerable OpenSSL client echoes 65535 bytes of its own heap back
3. Repeated-probe memory mapping — sending hundreds of probes and correlating the returned data allows partial reconstruction of heap layout. Practical for private key extraction: RSA key material has recognisable structure (leading 0x00 02 bytes before padding in PKCS#1), making it identifiable in heap dumps even without knowing its exact address.HOW TO DEFEND
1. Upgrade OpenSSL immediately — the fix is a two-line bounds check added in OpenSSL 1.0.1g (released 7 April 2014, same day as public disclosure) and backported to 1.0.2. The patch rejects any heartbeat request where the claimed payload length exceeds the actual received message length:
3. Invalidate all active session tokens — force every user to re-authenticate. Tokens extracted before the patch are still valid until they expire or are revoked.
4. Enable Certificate Transparency logging — makes it detectable if an attacker used a stolen private key to obtain a fraudulent certificate from a CA.
/* Fixed code in OpenSSL 1.0.1g — the check that was missing: */
if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0;
/* Now if payload > actual data, the heartbeat is silently dropped. */
2. Revoke and reissue ALL TLS certificates — private keys should be treated as compromised. An attacker who probed before you patched may already hold the private key. New key pairs; new certificates from your CA; old certs revoked via CRL and OCSP.3. Invalidate all active session tokens — force every user to re-authenticate. Tokens extracted before the patch are still valid until they expire or are revoked.
4. Enable Certificate Transparency logging — makes it detectable if an attacker used a stolen private key to obtain a fraudulent certificate from a CA.
# Nginx hardened TLS config post-Heartbleed:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_session_tickets off; # disable session resumption (limits key exposure)
add_header Expect-CT "enforce, max-age=86400";
5. Use memory-safe TLS implementations — BoringSSL (Google's fork, used in Chrome and Android), LibreSSL (OpenBSD fork), and Rustls (pure Rust) all eliminate this class of bug structurally. Memory-safe languages cannot perform an out-of-bounds read; the check becomes impossible to omit.PHASE 02
MEMORY EXTRACTOR
EXPLOIT
The handshake protocol is understood. Now exploit the gap inside it — OpenSSL 1.0.1f is listening, and it trusts every length claim.
💡 The Heartbleed bug: A heartbeat request says “here is a 3-letter word, send it back.” But it also says how many letters the word is. OpenSSL did not check. Ask for 3 letters but claim it is 64,000 letters — the server reads 64,000 bytes from its own memory and returns them all.
MENDAX
ENCRYPTED
The server memory grid below shows what the Vantage backup node currently holds. Each block is allocated memory — session tokens, private keys, certificate data, and empty space the server has not written to yet.
Three requests. Each time, choose the payload and claimed length combination that causes the server to read beyond the allocated block and into adjacent memory. Observe which blocks are revealed. Find the operator session tokens.
Three requests. Each time, choose the payload and claimed length combination that causes the server to read beyond the allocated block and into adjacent memory. Observe which blocks are revealed. Find the operator session tokens.
REQUEST 1 OF 3
■ allocated
■ safe/empty
■ leaked
■ target found
CRAFT THE HEARTBEAT REQUEST:
✓
EXTRACTION COMPLETE — SESSION TOKENS CAPTURED
Fourteen operator sessions extracted. Eleven Vantage staff. Two client representatives. And one account that does not fit the pattern.
The account is registered to an entity Shadow recognises. Not a commercial client. Not an authoritarian government. A democratic government. A Five Eyes member.
The account is registered to an entity Shadow recognises. Not a commercial client. Not an authoritarian government. A democratic government. A Five Eyes member.
MENDAX goes silent.
Thirty seconds pass. Then: "Do not log that. Continue."
Thirty seconds pass. Then: "Do not log that. Continue."
PHASE 03
VULNERABILITY SCOPE
ANALYSE
Fourteen tokens extracted, no log entry written. Now understand why this wasn't a Vantage problem — it was a global one.
💡 When Heartbleed was disclosed in April 2014, it affected an estimated 17% of all secure web servers simultaneously. Understanding why requires understanding how open-source security libraries propagate.
MENDAX
ENCRYPTED
Vantage deployed OpenSSL 1.0.1f on seventeen infrastructure nodes across seventeen countries. Every one of them was vulnerable the moment Heartbleed was published.
Three questions. Each one about why Heartbleed had global scope — not just for Vantage, but for the internet. Answer them in order.
Three questions. Each one about why Heartbleed had global scope — not just for Vantage, but for the internet. Answer them in order.
✓
SCOPE ANALYSIS COMPLETE
Heartbleed is the canonical example of a supply chain vulnerability. One bug in one library deployed by millions of servers simultaneously. The disclosure was an event, not a process — everything was vulnerable at once, and defenders had hours to respond while attackers had the same information.
Vantage was in the same position as every other affected organisation — except they chose to patch only what their CEO could see.
Vantage was in the same position as every other affected organisation — except they chose to patch only what their CEO could see.
PHASE 04
PATCH SEQUENCE
DEFEND
Scope confirmed. Now learn the exact sequence Vantage would need to close the wound — and see precisely where they failed to follow it.
💡 Patching OpenSSL is step one — not the whole response. Private keys were exposed before patching. Certificates signed with those keys are still trusted. Sessions authenticated before patching may still be valid. Every step must happen or the patch is incomplete.
MENDAX
ENCRYPTED
When Heartbleed was disclosed, every affected organisation had to respond in a specific order. Doing any step out of order makes the response fail.
Vantage will eventually detect this extraction and attempt to patch. Tap the four required response steps in the correct order. Understanding their sequence is understanding why Vantage’s partial patching left the backup node open for fourteen months.
Vantage will eventually detect this extraction and attempt to patch. Tap the four required response steps in the correct order. Understanding their sequence is understanding why Vantage’s partial patching left the backup node open for fourteen months.
BUILD THE RESPONSE SEQUENCE — SLOT 1 FIRST
TAP TO PLACE
💡 HINT (−20 XP)
The first step must happen before any other step is meaningful. If you revoke certificates before patching, the server still leaks memory — the attacker just captures the new certificate’s key too.
✓
CORRECT PATCH SEQUENCE
This is the sequence every major security incident responder published in April 2014 — and the sequence Vantage failed to follow for the backup node.
Vantage patched the primary node but stopped there. They never revoked the backup node’s certificate. Never reissued it. Never invalidated active sessions. Every session token Shadow extracted was still valid when it arrived in MENDAX’s terminal.
Partial patching is not patching. It is choosing which vulnerability to close and leaving the others open.
Vantage patched the primary node but stopped there. They never revoked the backup node’s certificate. Never reissued it. Never invalidated active sessions. Every session token Shadow extracted was still valid when it arrived in MENDAX’s terminal.
Partial patching is not patching. It is choosing which vulnerability to close and leaving the others open.
Why order matters: Patch first — so the key generation for the new certificate is not itself exposed. Revoke second — so the old certificate cannot be trusted by clients. Reissue third — so clients can reconnect securely. Invalidate sessions last — so the extracted tokens from before patching are no longer usable.
💔
OPERATION 23 — COMPLETE
HEARTBREAK — SUCCESS
14 SESSION TOKENS // ONE UNLOGGED
+0
XP EARNED THIS OPERATION
Fourteen operator sessions extracted. Eleven Vantage staff. Two commercial client representatives. One Five Eyes government account that MENDAX has instructed Shadow to leave unlogged and unacted on.
Shadow now holds eleven live Vantage operator session tokens. MENDAX has identified one belonging to a senior operations manager — someone with dashboard access. His session was authenticated forty minutes ago. The token is still valid.
Vantage does not know this happened. Heartbleed leaves no log entries. No connection errors. No alerts. The server read from its own memory and returned what it found. Nothing in the server’s logs shows anything happened at all.
Shadow now holds eleven live Vantage operator session tokens. MENDAX has identified one belonging to a senior operations manager — someone with dashboard access. His session was authenticated forty minutes ago. The token is still valid.
Vantage does not know this happened. Heartbleed leaves no log entries. No connection errors. No alerts. The server read from its own memory and returned what it found. Nothing in the server’s logs shows anything happened at all.
MENDAX — DARK CHANNEL // POST-HEARTBREAK
08:11
MENDAX
“Fourteen operator sessions. Eleven are Vantage staff. Two are client representatives. One is something else.”
■
[ 30 seconds of silence ]
MENDAX
“Do not log that. Continue.”
MENDAX
“His session is active. He authenticated forty minutes ago. You have his token. Use it. Op 24.”
08:11 — DARK CHANNEL // SHADOW + MENDAX
SHADOW
The Five Eyes account. Should I preserve the token?
MENDAX
Do not log that. Continue.
SHADOW
Understood. Senior operations manager — dashboard access. Token valid.
MENDAX
Now you understand what we are taking apart. Use the token. Op 24.
DEBRIEF — REFLECTION QUESTION
The server read 64KB of memory because it trusted the caller's claimed payload length without verifying it against the actual payload size. What is the name of this class of vulnerability — and at what point in the code should the length validation have been performed?
SIGMA-9 ACADEMY
OPERATION 23 // HEARTBLEED // CVE-2014-0160 // COMPLETE REFERENCE
◈ THE TLS HANDSHAKE — STEP BY STEP
1. ClientHello: Client sends supported TLS versions, cipher suites, and a random number. Server learns what the client can handle.
2. ServerHello: Server selects the TLS version and cipher suite. Sends its own random number.
3. Certificate: Server sends its digital certificate — proof of identity signed by a certificate authority.
4. ServerHelloDone: Server signals it has finished its half of the negotiation.
5. ClientKeyExchange: Client sends key material (encrypted with the server’s public key) that both sides use to derive the session keys.
6. Finished: Both sides confirm the handshake is complete and encrypted communication begins.
The heartbeat extension operates after step 6. Heartbleed exploited the heartbeat message handler in the established session.
◈ HOW HEARTBLEED WORKS — THE TECHNICAL DETAIL
The TLS heartbeat extension (RFC 6520) allows either party to send a heartbeat request to keep an idle connection alive. The request contains a payload and a declared length of that payload. The server is supposed to echo the payload back at the declared length.
The bug: OpenSSL did not verify that the declared length matched the actual payload length. An attacker could send a 1-byte payload but declare a length of 65,535 bytes. OpenSSL would copy 65,535 bytes starting from the payload’s memory address — reading far beyond the allocated buffer into whatever was adjacent in memory.
A single request exposed up to 64KB of server memory. The attack could be repeated indefinitely. No authentication was required. The server logged nothing — a heartbeat response is a normal operation.
◈ WHY IT HAD GLOBAL SCOPE
OpenSSL is not a Vantage product. It is an open-source library used by the majority of HTTPS servers globally. When a single library contains a vulnerability and that library is deployed everywhere, disclosure creates a simultaneous global attack window.
At the time of disclosure in April 2014, an estimated 17% of all secure web servers were vulnerable. This included major banks, government websites, healthcare systems, and private infrastructure like Vantage Systems — all vulnerable at the same moment.
Supply chain vulnerability: The bug was in a component that thousands of independent organisations included in their systems. Fixing it required each organisation to update independently — and many, like Vantage’s backup team, did not.
◈ COMPLETE HEARTBLEED RESPONSE — ALL 4 STEPS REQUIRED
1. Patch OpenSSL to version 1.0.1g or later (or disable the heartbeat extension). This stops the memory leak. But everything leaked before patching remains compromised.
2. Revoke the old TLS certificate. The private key associated with the certificate was exposed in server memory during the attack window. Any certificate signed with that key must be revoked — otherwise an attacker who extracted the key can impersonate the server.
3. Reissue a new TLS certificate with a newly generated key pair. Clients can now verify they are talking to the real server.
4. Invalidate all active sessions. Session tokens present in memory during the attack window were exposed. Even after patching, those tokens are still valid credentials — until they are invalidated. Force all users to re-authenticate.
Vantage performed step 1 on the primary node and stopped. The backup node received no steps. Fourteen months later, all four steps remained undone on the backup — which is why Shadow’s extracted tokens were still live.
❓
FIELD QUESTIONS — HEARTBREAK
Why does Heartbleed leave no server-side log entries?
A heartbeat response is a normal, expected TLS operation. The server processed a valid heartbeat request and returned data as instructed by the protocol. From the server’s perspective, nothing went wrong — it fulfilled the request correctly, according to the protocol specification. The bug was that the protocol as implemented did not check payload length. The server had nothing to log because no error occurred.
What is a certificate authority and why does revoking a certificate matter?
A certificate authority (CA) is a trusted organisation that digitally signs TLS certificates, vouching that the certificate belongs to the claimed domain. If Heartbleed exposed the private key used to generate a certificate, an attacker could create a new certificate for the same domain using that key — one that CAs would recognise as legitimate. Revoking the original certificate tells clients to stop trusting it, even if it appears cryptographically valid.
What is the difference between patching a vulnerability and fully remediating it?
Patching closes the vulnerability — it prevents future exploitation. Full remediation addresses the consequences of exploitation that may have already occurred. For Heartbleed: the patch stops future memory leaks, but private keys leaked before patching remain compromised, certificates signed with those keys remain untrustworthy, and session tokens extracted before patching remain valid credentials. Patching without the remaining three steps leaves the consequences of past exploitation in place.
Why did the Five Eyes government account appear in a Vantage extraction?
The extraction returned all session tokens currently present in server memory — there was no way to select specific accounts. The Five Eyes government’s presence in the Vantage operator sessions suggests they were authenticated to the platform as a client or observer. MENDAX’s instruction to not log it indicates this information has implications beyond the current operation — implications she cannot act on directly because of who it implicates.
REAL-WORLD TOOLS — CRYPTO ANALYSIS
WHAT PROFESSIONALS USE
🔑
testssl.sh
FREE / OPEN SOURCE
Audits a TLS endpoint for weak ciphers, old protocols and known flaws like Heartbleed — purely defensive assessment.
testssl.sh https://target.lab
🧰
Hashcat
FREE / OPEN SOURCE
GPU cracking used to prove a weak hash or key is recoverable, justifying stronger algorithms and key rotation.
hashcat -m 1400 hashes.txt wordlist
🔒
OpenSSL
FREE / OPEN SOURCE
Inspect certificates, test cipher suites and verify that strong, modern encryption is actually in force.
openssl s_client -connect target.lab:443
LEAVE MISSION?
Progress is saved. You can resume from the mission select screen at any time.
RESET MISSION?
This wipes all progress for this operation only. XP in other operations is unaffected.
ARE YOU SURE?
Final confirmation -- all progress for this operation will be permanently erased.