OpTinselTrace24-5: Tale of Maple Syrup

Scenario

In this scenario we’re asked to analyze collection from an Android mobile device to detect malicious activity and insider threat.

Executive Summary

An insider at Santa’s workshop negotiated a paid leak with an outside buyer over the MEGA chat app on his Android phone. He kept a short to-do note in Google Keep about what the buyer wanted, then moved files from his workstation to the phone through a browser-based transfer service and forwarded them to the buyer as a password-protected ZIP. The ZIP held a KeePass vault and a text file of emails. The archive password was recovered with a known-plaintext attack against the ZIP’s legacy encryption, and the vault master password fell to a wordlist attack. The vault exposed the credentials for Santa’s workstation, and the chat shows the insider was paid in a cryptocurrency wallet address.

Artifacts

• Android data dump: app data directories (data/) → browse the file tree, open the SQLite databases with sqlite3 -readonly
• MEGA: karere-*.db chat history and contacts. Message bodies are stored as hex blobs, so decode them
• Google Keep: keep.db, tables tree_entity and list_item
• Firefox: places.sqlite history plus the cache directory
• Play Store: com.android.vending/databases/localappstate.db
• info-send(1).zip: the archive the insider sent, containing the KDBX and Emails.txt

Timestamp note: Android stores times as epoch milliseconds. Convert to UTC before submitting in YYYY-MM-DD HH:MM:SS.

Command and Control

Start with the chat app, since an insider needs a channel to the buyer. The MEGA karere database keeps a contacts table, and the one external contact carries the buyer’s email address.

sqlite3 -readonly karere-*.db ".tables" "select * from contacts"

The karere database belongs to MEGA, and its history table holds the full conversation between the insider and the contact from Q1. The directory name of the app data gives the package name.

sqlite3 -readonly karere-*.db "select hex(data) from history"

Tip: The message bodies are plain hex, not encrypted. Piping hex(data) through a hex decoder is all it takes to read the chat.

The Play Store keeps its own install bookkeeping in localappstate.db. The appstate table has a first_download_ms value for each package; convert the MEGA row from epoch milliseconds to UTC. This was reasoned rather than read from a dedicated install-time field: several timestamps for the app exist, and first_download_ms is the earliest and the one that matches a first install.

sqlite3 -readonly com.android.vending/databases/localappstate.db "select package_name, first_download_ms from appstate where package_name like '%mega%'"

Decode the history table from Q2 and read the negotiation. The price is agreed in the eighth message of the conversation.

sqlite3 -readonly karere-*.db "select hex(data) from history" | xxd -r -p

The payment details are later in the same MEGA conversation (message 50). The currency name and wallet address are given together, which matches the currencyname:address format.

sqlite3 -readonly karere-*.db "select hex(data) from history" | xxd -r -p | grep -ai elfereum

Collection

The phone has Google Keep installed. Its keep.db stores the note body in the list_item table, with the note metadata in tree_entity.

sqlite3 -readonly keep.db "select * from list_item"

Gotcha: The format mask has two sentences separated by . and ends in !!. Copy the text exactly, including the double exclamation marks.

The title is on the matching row in tree_entity, joined to the note from Q5.

sqlite3 -readonly keep.db "select * from tree_entity"

The time_created column in tree_entity holds epoch milliseconds (1730722495549). Converted to UTC it gives the creation time.

sqlite3 -readonly keep.db "select title, datetime(time_created/1000,'unixepoch') from tree_entity"

Exfiltration

Check Firefox history and cache for the transfer service. JustBeamIt links carry a one-time token parameter, so grep the whole Firefox directory for the URL pattern and match the token to the info-send ZIP.

sqlite3 -readonly places.sqlite "select url, datetime(visit_date/1000000,'unixepoch') from moz_places p join moz_historyvisits v on v.place_id=p.id"

grep -rhao 'https://[a-z]*.justbeamit.com:8443/download?token=[a-z0-9]*' firefox/

The ZIP was handed to the buyer through the MEGA chat from Q2. The message carrying info-send(1).zip is message 38, and its timestamp is the share time. This was reasoned from the chat record: the other timestamps (download on the phone, local file times) belong to earlier steps, and the message time is the moment the buyer received it.

sqlite3 -readonly karere-*.db "select ts, hex(data) from history"

Credential Access

List the archive first: it holds Emails.txt and a SANTA-CONFIDENTIAL-PROD-ITR.kdbx vault, encrypted with legacy ZipCrypto. A dictionary attack on the 11-character password with rockyou got nowhere, so use a known-plaintext attack instead. A KDBX3 file starts with fixed signature bytes (03d9a29a67fb4bb5) followed by version bytes 01000300, which gives enough known plaintext for bkcrack to recover the internal keys. With the keys, brute-force the password with a mask search at length 11.

bkcrack -C a.zip -c SANTA-CONFIDENTIAL-PROD-ITR.kdbx -p p3.bin

bkcrack -k cec26f80 cc8751a0 fdf67470 -r 11 '?p'

Gotcha: The known-plaintext header must use the KDBX3 version bytes (01 00 03 00). Guessing KDBX4 headers fails, and each failed run costs several minutes.

Use the recovered keys from Q10 to decrypt the vault straight out of the archive with bkcrack, so the ZIP password is not even needed. Then extract a hash with keepass2john and run it through hashcat mode 13400 against rockyou.

bkcrack -C a.zip -k cec26f80 cc8751a0 fdf67470 -c SANTA-CONFIDENTIAL-PROD-ITR.kdbx -d s.kdbx

keepass2john s.kdbx > s.hash && hashcat -m 13400 s.hash /usr/share/dict/rockyou.txt

Open the vault with the master password from Q11 and read the entry named for Santa’s workstation.

from pykeepass import PyKeePass
kp = PyKeePass('s.kdbx', password='weed420')
for e in kp.entries: print(e.title, e.username, e.password)

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Personal phones are an unmanaged exfiltration path. The insider moved data from the workstation to his phone with a browser-based transfer service and passed it on through a consumer chat app. Block or alert on file-transfer services such as JustBeamIt and MEGA from corporate endpoints, and put mobile device management in front of work data.

A password manager vault is only as strong as its master password. weed420 fell to rockyou in moments. Enforce long, random master passphrases and a key file for high-value vaults, and never keep the vault with a copy of the credentials it protects.

ZipCrypto is not encryption you can lean on. Known plaintext at the start of a file (the KDBX header here) was enough to recover the keys and skip the password entirely. Use AES-256 archives, or encrypt the vault itself and not just the wrapper.

Insider risk shows in the small signals. A note titled with a collection plan and a new chat app installed the same day were sitting on the device. Combine HR context with DLP and endpoint telemetry so that unusual transfers and privileged-credential access trigger review before the data leaves.

Conclusion

The insider sold Santa’s secrets, including workstation credentials in a KeePass vault, for $69000 paid in cryptocurrency, and every step left traces in ordinary Android app databases. The attacker’s real edge was weak crypto hygiene: a legacy ZIP cipher and a wordlist-grade master password protected the secrets in name only.