Heist

Scenario

In this hard Sherlock, you are tasked with investigating a serious breach at Forela’s YouTube channel. Instead of the regular company content, the live stream has been hijacked to display videos promoting cryptocurrency scams, sparking complaints from viewers. The channel, managed by IT administrator Alonzo Spire, is a significant platform for Forela to engage with its audience through product showcases and educational content.

Once the incident was reported, Alonzo’s system was swiftly triaged and artifacts collected for forensic analysis. Your responsibility is to analyze these artifacts to understand how the YouTube channel was compromised. This scenario calls on your digital forensics expertise and your understanding of a variety of evidence sources to uncover the breach’s origin, ensuring the company’s digital presence remains secure.

Executive Summary

A phishing email sent to the Forela IT administrator linked to a Google Drive download of a zip archive. Inside was an executable dressed up as a PDF with a double extension, which the victim ran. It unpacked a chain of self-extracting stagers into Temp, the last of which was a RedLine stealer that connected to a bare-IP command server over a WCF net.tcp channel. The stealer swept the workstation and uploaded browser logins, a saved payment card, an FTP credential, a desktop note and sensitive Office documents in one stream. The packet capture shows the stolen content and the Windows SRUM database gives the byte count the stealer sent. The leaked browser credentials explain the hijacked YouTube channel.

Artifacts

• Kape_Acquisition.zip: KAPE triage collection from the victim workstation. Holds the $MFT and $J, prefetch, event logs, the Chrome profile and SRUDB.dat
• Email.eml: the phishing message, read as text for its Received headers
• Heist.pcapng: full-content capture, read with tshark

Timestamp note: Answers are UTC. Prefetch, MFT and Chrome downloads already store UTC. The email carries several Received hops in different zones, so pick the hop with care (Q1).

Initial Access

Read the Received chain in the .eml from the bottom up. The Zoho relay hop is stamped in CEST (10:55:24), the sender-side handoff. The Postfix hop on the receiving server records arrival and is already in UTC.

grep -i '^Received' Email.eml

Gotcha: The Zoho hop converts to 08:55:24 UTC and looks right, but it is the relay hop. Delivery is the Postfix Received line, two seconds earlier.

The email link leads to Google Drive. Chrome’s History SQLite file stores every redirect hop of a download in downloads_url_chains. The last hop is the direct googleusercontent.com URL that served the bytes, not the Drive share page.

sqlite3 History "select id, chain_index, url from downloads_url_chains order by id, chain_index"

Tip: Take the highest chain_index for the download id. Earlier hops are Drive landing pages.

The downloads table in the same database names the target file. The $MFT output shows the same archive created in the user’s profile.

sqlite3 History "select target_path, start_time, tab_url from downloads"

downloads.start_time is a WebKit epoch (microseconds since 1601), so convert it. The MFT creation time of the zip lands on the same second.

sqlite3 History "select datetime(start_time/1000000-11644473600,'unixepoch') from downloads"

MFTECmd -f '$MFT' --csv work/mft

Execution

Parse the prefetch folder and look for executed binaries that do not belong. One .pf stands out: a name carrying two extensions that matches the archive from Q3.

PECmd -d prefetch --csv work/pf

The binary from Q5 is named Partnership.pdf.exe. Windows hides known extensions by default, so the victim sees a PDF while the real type is an executable. The answer is the type it pretended to be.

The FilesLoaded column of the PARTNERSHIP.PDF.EXE prefetch record lists the volume paths the process touched, which gives the directory it ran from.

python3 -I -c "import csv;[print(r['SourceFilename'],r['FilesLoaded'][:400]) for r in csv.DictReader(open('work/pf/pecmd.csv')) if 'PARTNERSHIP' in r['SourceFilename']]"

LastRun in the same prefetch record gives the execution time, about 40 seconds after the download finished in Q4.

python3 -I -c "import csv;[print(r['SourceFilename'],r['RunCount'],r['LastRun']) for r in csv.DictReader(open('work/pf/pecmd.csv')) if 'PARTNERSHIP' in r['SourceFilename']]"

FilesLoaded for Partnership.pdf.exe, cross-checked against the MFT, shows two executables loaded from Temp\IXP000.TMP. That folder naming matches an IExpress self-extractor unpacking its payload, so these are the first-stage droppers.

python3 -I -c "import csv;[print(r['FilesLoaded']) for r in csv.DictReader(open('work/pf/pecmd.csv')) if r['SourceFilename'].startswith('PARTNERSHIP')]"

Repeat for the prefetch entry of UN598654.EXE, one of the two droppers from Q10. It loads two further binaries from a new IXP001.TMP folder, the next layer of the same extractor chain.

python3 -I -c "import csv;[print(r['FilesLoaded']) for r in csv.DictReader(open('work/pf/pecmd.csv')) if r['SourceFilename'].startswith('UN598654')]"

Command and Control

Rank the TCP conversations in the capture. One external bare-IP peer on a high port carries almost all of the outbound data, far more than any browsing traffic. Sysmon-style event logs were parsed as a cross-check.

tshark -r Heist.pcapng -q -z conv,tcp

EvtxECmd -d evtx --csv work/evtx --csvf e.csv

Following the streams to the C2 shows net.tcp WCF framing with Entity and Id records and a file-grabber configuration. That structure is characteristic of RedLine. This was identified from the protocol shape and the layout of the stolen data, not from a hash or sandbox verdict.

tshark -r Heist.pcapng -q -z follow,tcp,raw,441

Exfiltration

The stealer’s process list is embedded in the exfil stream and names qu2705.exe, the second-layer binary from Q11, which ran from IXP001.TMP. A second RedLine instance (si168290.exe) also reached the same C2, so the SRUM byte count in Q21 is what pins this one down.

grep -i qu2705 work/pf/pecmd.csv | cut -c1-300

Gotcha: Both qu2705.exe and si168290.exe talked to the C2. The Q21 format mask ends in 9, and only qu2705.exe has a SRUM total that fits.

The RedLine stream carries a process list with a line like ID: 3924, Name: qu2705.exe. The Application Error (1000) event for the crashed process has the PID in hex in its parameters, f54, which is 3924 decimal.

strings -n 6 s54013.bin | grep -i 'qu2705'

grep -i qu2705 evtx/e.csv

SRUM’s NetworkUsage table keeps bytes sent per application. SrumECmd does not run on Linux, so the ESE database was read with impacket’s ese module and the table dumped. QU2705.exe shows the figure that fits the Q14 mask.

SrumECmd -f SRUDB.dat -r SOFTWARE --csv work/srum

python3 -I srum_dump.py SRUDB.dat

Tip: The second RedLine instance, SI168290.EXE, sent 106903 bytes. Close, but not the target.

Collection

RedLine uploads files from the desktop. Decoding the exfil stream shows reminder.txt and its contents. The WCF chunk boundary splits the last word across two records, so stitch the pieces together.

strings -n 6 s54015.bin | grep -B2 -A6 'reminder.txt'

Gotcha: The sentence is split mid-word in the stream (neede then d.). Reassemble it and leave off the trailing period, which is not part of the accepted text.

The stolen files include a Word document about an AWS migration. Carve it out of the stream by locating the zip signature, then read the signature block for the sender.

python3 -I carve_docx.py s54013.bin

Gotcha: The first PK match can belong to a different embedded file. Cut at the first PK\x05\x06 end-of-central-directory record after the local header so the zip opens cleanly.

A second stolen Office file, Infra upgrade.docx, carves the same way. The planned date appears in its title text.

python3 -I carve_docx.py s54013.bin

grep -ri 'upgrade' kape/ | head

Credential Access

RedLine uploads saved FTP credentials as an Id12 record in the stream. It names an FTPS server at 13.45.67.23:21 for the user alonzo.spire, with the saved password beside it.

strings -n 6 s54015.bin | grep -B3 -A6 '13.45.67.23'

The stolen browser logins sit in the same stream. The entry for https://youtube.com/ under the username Forela-Media holds the channel password, which explains how the live stream was hijacked.

strings -n 6 s54015.bin | grep -B2 -A4 -i 'youtube.com'

The stream also holds a saved payment card record in the name of Alonzo Spire. Scan for 16-digit card patterns and take the one with his name.

python3 -I -c "import re;d=open('s54015.bin','rb').read();print(set(re.findall(rb'\b4\d{15}\b',d)))"

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Show file extensions and block double extensions. The whole chain started with a .pdf.exe the victim read as a PDF. Showing known extensions through policy, and blocking execution of files with a document extension before .exe, removes the lure.

Execution from user-writable folders deserves an alert. Prefetch shows a binary running from Documents that then spawned self-extracting stagers in Temp\IXP00x.TMP. An EDR rule on that chain (user-folder exe spawning nested IExpress-style extractors) catches it in seconds.

A bare IP on a high port with a large upload is a clean network signal. One external peer received almost all of the workstation’s outbound bytes. Egress allow-listing or a volume-per-destination baseline would flag it.

Browser-saved credentials are the real loss. The channel password, the FTP password and a payment card all came from the browser store. A password manager with MFA on the channel account would have kept a stolen password from being enough.

Keep SRUM in your collection. It recorded per-process bytes sent when the capture could not attribute traffic to a process, and it is what separated two near-identical RedLine instances.

Conclusion

A single disguised executable gave RedLine everything it needed: one outbound stream carried the admin’s channel login, FTP access, card number and internal documents. The evidence needed to scope the loss was all on the endpoint, and SRUM plus prefetch told the story the network capture alone could not.