DEADFACE CTF

2. Discovered HTTP Staging & Secret XOR Key:

Filtered for the staging server connection:

Followed the TCP stream on the GET /staging.bin request and guess what The server returned the attacker's staging config:

This showed that data was being smuggled out over DNS using the repeating XOR key Sp00ky surprised? yeah me too ( u alone )

3. Collected Exfiltrated DNS Chunks:

Filtered Wireshark for the tunneling domain:

Extracted the ordered query subdomains (s00 through s04):

Stripped the s00- prefixes and joined the Base32 chunks in sequence:

intersting right?

4. Decoded Flag in CyberChef:

Pasted the concatenated string into CyberChef with this recipe:

1. From Base32
2. XOR (Key: Sp00ky, UTF8)

Output decoded directly into the flag:

1. Identified ICMP Traffic Anomaly:

Filtered PCAP01.pcap for ICMP packets:

Baseline traffic showed standard 90-byte pings to the gateway 192.168.1.1. However, a burst of 50-byte requests appeared targeting an external host 10.10.14.7:

soo guess what !

u guessed??

2. Isolated Exfiltration Requests: ( hope u think of that too )

Filtered specifically for the outbound packets to the suspect IP:

This isolated 8 distinct Echo Requests (Packets 13, 15, 17, 19, 21, 23, 25, 27):

3. Inspected Payload Data (Base64 Chunks):

Selected Packet 13 and expanded the ICMP data field (Data (8 bytes)). Instead of default ping padding, the payload contained custom ASCII characters ZGVhZGZh:

guess what :) there's more

Checking each outbound request revealed sequential 8-byte Base64 chunks:

4. Reassembled & Decoded in CyberChef:

Concatenated the chunks into the full Base64 string:

Decoded using the From Base64 recipe to recover the flag:

1. Intercepted PBX Diagnostics via FTP:

Filtered DontLeaveMeHanging.pcap for FTP file transfers:

Identified user mkowalski downloading the PBX diagnostic archive pbx-diag-20261008.tar.gz from the PBX server (10.20.200.5):

2. Analyzed PBX Logs & Discovered In-Band Audio Anomaly:

Extracted the archive to inspect the Asterisk PBX logs (messages.log) and SSL secrets (tls-keys.log).

Standard VoIP systems transmit dial tones as out-of-band network events (RFC 4733). However, a critical warning in messages.log revealed that extension 2003 was misconfigured:

This meant the touch-tones were not separate packets—they were audible sound frequencies baked directly into the call's voice audio:

(don't be surprised idk what this shit mean -_- )

3. Extracted Session Key & Decrypted SRTP Stream:

The SIP call setup was protected by TLS, but feeding tls-keys.log into Wireshark revealed the decrypted SDP media negotiation, including the cryptographic master key:

The actual call audio was carried over UDP ports 14740 & 7078 and encrypted with SRTP (AES Counter Mode), preventing standard audio players from reading it.

Used srtp_fixed.py to derive session keys per RFC 3711 and strip the 10-byte HMAC auth tags, decrypting raw payload into a playable WAV file (call_in_fixed.wav).

4. Decoded DTMF Audio Frequencies into the Flag:

Because standard tools struggled with the audio stream, wrote a custom Python decoder (decode_dtmf_fixed.py) to run FFT frequency analysis over 50ms windows matching the DTMF frequency grid (697–941 Hz low / 1209–1633 Hz high):

import wave
import numpy as np

ROW_FREQS = [697, 770, 852, 941]
COL_FREQS = [1209, 1336, 1477, 1633]
KEY_MAP = {
    (697, 1209): '1', (697, 1336): '2', (697, 1477): '3',
    (770, 1209): '4', (770, 1336): '5', (770, 1477): '6',
    (852, 1209): '7', (852, 1336): '8', (852, 1477): '9',
    (941, 1209): '*', (941, 1336): '0', (941, 1477): '#'
}

with wave.open('call_in_fixed.wav', 'rb') as wf:
    data = np.frombuffer(wf.readframes(wf.getnframes()), dtype=np.int16)
    rate = wf.getframerate()

win, hop = int(rate * 0.05), int(rate * 0.025)
tones, curr, count = [], None, 0
for i in range(0, len(data) - win, hop):
    chunk = data[i:i+win] * np.hamming(win)
    fft, freqs = np.abs(np.fft.rfft(chunk)), np.fft.rfftfreq(win, 1.0 / rate)
    r_best = min(ROW_FREQS, key=lambda rf: abs(freqs[np.argmax(fft)] - rf))
    c_best = min(COL_FREQS, key=lambda cf: abs(freqs[np.argmax(fft)] - cf))
    r_val = max(fft[np.argmin(np.abs(freqs - rf))] for rf in ROW_FREQS)
    c_val = max(fft[np.argmin(np.abs(freqs - cf))] for cf in COL_FREQS)
    k = KEY_MAP.get((r_best, c_best)) if (r_val > 50000 and c_val > 50000) else None
    if k == curr:
        count += 1
    else:
        if curr and count >= 2: tones.append(curr)
        curr, count = k, 1
if curr and count >= 2: tones.append(curr)

digits = "".join(tones)
print("Detected tones:", digits)

Executed the script against call_in_fixed.wav:

Extracted 96 sequential touch-tone digits and mapped them into 3-digit ASCII decimal values:

fr that was SOLID PEAK challenge ( nvm was good)

1. Open pirateslife.pcap in Wireshark.

2. Apply this display filter:

1. Inspected Extracted Chrome Artifacts:

Unpacked CTF_Caches_Kampeter_1.zip, revealing standard Google Chrome user profile databases:

extractedctf_artifactsChromeUser DataDefault  ├── History          (SQLite 3: URLs, timestamps, transition types)
  ├── Login Data       (SQLite 3: saved autofill & submitted credentials)
  └── Cookies

2. Queried Chrome History & Converted Timestamps:

Chrome stores timestamps as WebKit epoch (microseconds since January 1, 1601 UTC). Ran inspect_history.py to query the urls table and convert timestamps:

Command Input:

Terminal Output:

=== URLS ===
ID: 1 | 2025-03-14 09:05:10 | https://confluence.demonne.int/wiki/IT/VPNSetup
ID: 2 | 2025-03-14 09:47:32 | https://demonne.sharepoint.com/sites/finance/Shared%20Documents
ID: 3 | 2025-03-14 10:01:55 | https://www.reuters.com/markets/
ID: 4 | 2025-03-14 10:22:15 | https://mail.google.com/mail/u/0/#inbox/FMfcgzQXKlwJqTvBnDpCmRsYhWxGbVkL
      Title: [URGENT] De Monne VPN Migration - Action Required - Gmail
ID: 5 | 2025-03-14 10:22:31 | https://mail.google.com/mail/u/0/#inbox
ID: 6 | 2025-03-14 10:23:44 | http://demonne-secure-portal.net/login?ref=vpn_auth&token=df4e91bc
      Title: De Monne Financial - Secure Employee Portal
ID: 7 | 2025-03-14 10:23:45 | http://demonne-secure-portal.net/auth/redirect?session=9f3a22cd&status=ok

3. Traced the Click Chain via visits Table:

Checking the visits table verified that URL ID 6 originated directly from the open webmail session (from_visit = 5):

Transition code 838860801 (PAGE_TRANSITION_LINK) proves the employee clicked the link inside the urgent VPN migration email. The destination was an HTTP lookalike phishing domain:
http://demonne-secure-portal.net/login?ref=vpn_auth&token=df4e91bc

4. Confirmed Credential Capture in Login Data:

Querying the logins table in Login Data showed that the victim entered corporate credentials on the malicious site:

=== LOGIN DATA ===
('http://demonne-secure-portal.net/login', 'http://demonne-secure-portal.net/auth/verify', 'f.kampeter@demonne.com')

1. Unpacked the Victim's Stolen Identity Files:

Extracted File_Dump_Challenge.zip, containing personal resumes, receipts, photos, and staged documents belonging to Daniel Hameser:

2. Identified Operational Note Staged by the Attacker:

Found notes.docx, which revealed the adversary's instructions for staging accounts across sites:

"Remember to keep the Hameser accounts consistent across sites. Use the FL address for anything that mails a code. Reroute the rest. Coffee place wifi is reliable in the mornings."

Also included a cropped snippet of an Apple Specialist store location used for scouting:

3. Extracted OpenXML Metadata from notes.docx:

Modern .docx files are zipped OpenXML packages. Extracted docProps/core.xml to inspect the embedded creator metadata:

Command Input:

Terminal Output:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:coreProperties xmlns:cp="http://schemas.openxmlformats.org/package/2006/metadata/core-properties" ...>
    <dc:title>notes</dc:title>
    <dc:creator>ghostwriter404</dc:creator>
    <cp:lastModifiedBy>GHOST404-PC</cp:lastModifiedBy>
    <cp:revision>1</cp:revision>
    <dcterms:created xsi:type="dcterms:W3CDTF">2026-08-22T21:33:04.269Z</dcterms:created>
    <dcterms:modified xsi:type="dcterms:W3CDTF">2026-08-22T21:33:04.269Z</dcterms:modified>
</cp:coreProperties>

(Alternatively, in Windows Explorer: Right-click notes.docx ➔ Properties ➔ Details ➔ Authors: ghostwriter404, Last saved by: GHOST404-PC).

4. Correlated with DEADFACE Threat Actors:

The creator ghostwriter404 and machine name GHOST404-PC directly map to the known DEADFACE operative gh0st404 (alias: ghost404).

1. Timestamp Triage Across Archive:

• • Unpacked CTF_Forgery_Paintings.zip containing Painting_001.png through Painting_005.png.
• • Inspected file modification timestamps in File Explorer:
• • Four paintings shared an identical creation timestamp of September 1, 2026.
• • Painting_002.png stood out with a much newer timestamp of October 14, 2026.

2. Inspected the Forged Artwork:

Opening Painting_002.png revealed the hacked parody artwork ("Mona Lisa Loading"):

3. Extracted Embedded XMP Metadata:

Searched for embedded text / metadata signatures across all paintings:

Command Input:

Terminal Output:

Painting_002.png:20:  <dc:identifier>deadface{L4MIA_SIGNS_HER_WORK}</dc:identifier>

Reading the full XMP metadata chunk (exiftool Painting_002.png) confirmed Lamia's forger attribution:

<dc:creator>Leonardo da Vinci / LAMIA</dc:creator>
<dc:title>Mona Lisa Loading</dc:title>
<dc:rights>LAMIA temporary acquisition</dc:rights>
<dc:identifier>deadface{L4MIA_SIGNS_HER_WORK}</dc:identifier>

1. Scene Inspection (truck_crash.png):

Opened the provided photo showing a multi-vehicle collision at an intersection involving a commercial box truck and a black sedan:

2. Isolating Vehicle Markings:

Zoomed in along the upper right portion of the white cargo box to look for commercial registration stencil markings required by federal law:

3. FMCSA SAFER Carrier Lookup:

Queried the official Federal Motor Carrier Safety Administration (FMCSA) SAFER Company Snapshot database (https://safer.fmcsa.dot.gov/CompanySnapshot.aspx) using USDOT number 80806:

4. Founding Date OSINT:

Checked public corporate records / Wikipedia for J.B. Hunt:

• • Founded: August 10, 1961 (by Johnnie Bryan Hunt & Johnelle Hunt)
• • Formatting to MM_DD_YYYY:
• • Month: August ➔ 08
• • Day: 10 ➔ 10
• • Year: 1961 ➔ 1961
• • Combined: 08_10_1961

1. Document Inspection (Doc_20261017_0915.jpg):

Opened the provided scan of an official student reprimand letter addressed to Cornelius Kellerman from Dr. Margaret Finch (Office of Student Conduct):

The challenge prompt asks for the specific equipment asset ID used to print the physical document. This points directly to Machine Identification Codes (MIC) faint yellow tracking dots embedded by color laser printers into printed documents to identify the device model, serial number, and timestamp.

2. Isolating the Yellow Tracking Dots:

Yellow toner absorbs blue light while reflecting red and green. Therefore, decomposing the image into its RGB components and inspecting the inverted Blue channel (or boosting contrast/levels on faint background pixels) makes yellow tracking dots stand out as dark, clearly defined dots against the white page.

Scanning the margins revealed a repeating pattern in the lower right margin (around coordinates X ≈ 2330–2420, Y ≈ 3020–3180). The dots form a clean rectangular grid: 8 columns spaced evenly 12 pixels apart across 13 rows.

3. Decoding the Dot Matrix:

Each row consists of an 8-bit byte (MSB to LSB), where a dot represents 1 and blank space represents 0:

Concatenating the decoded ASCII characters produces: NVU-PRINT-17.

if u have life don't try do it by your hands

1. Archive Extraction & Initial Triage:

Extracted exfiltration.zip, yielding 20 JPEG images named image_01.jpg through image_20.jpg. Standard checks for appended files after JPEG End of Image marker (FF D9) showed 0 bytes, confirming steganography was embedded within standard image headers.

2. EXIF Metadata Inspection:

Inspected the image EXIF tags across all 20 images and noticed two key patterns:

• • Timestamp (DateTimeOriginal): Each file has an exact timestamp recorded on 2026:06:01 between 14:02:17 and 15:12:29.
• • Embedded Hex Tag: The Document Name / Image Identifier tag holds a hex string prefixed by IMG_ (e.g. IMG_6465, IMG_61, IMG_7469).

3. Chronological Sorting & Covert Stream:

The filenames image_01.jpg through image_20.jpg are randomized decoys. Sorting the images chronologically by their EXIF timestamp orders the hex chunks sequentially:

4. Automated Solver Script:

Wrote a Python one-liner to parse EXIF timestamps and hex tags, sort chronologically, and decode the assembled hex stream:

Command Input:

python -c "
import glob, re
items = []
for f in glob.glob('extracted/*.jpg'):
    d = open(f, 'rb').read()
    ts = re.search(rb'(\d{4}:\d{2}:\d{2} \d{2}:\d{2}:\d{2})', d).group(1).decode()
    hx = re.search(rb'IMG_([0-9a-fA-F]+)', d).group(1).decode()
    items.append((ts, hx))
items.sort(key=lambda x: x[0])
hex_str = ''.join(x[1] for x in items)
print('Hex String:', hex_str)
print('Flag:', bytes.fromhex(hex_str).decode())
"

Command Output: