Jinkies

Scenario

Jinkies is a medium difficulty Sherlock where you’ll investigate the theft of intellectual property from an organisation called Cloud-guru. Find the source of the leak and answer the questions for senior management!

Executive Summary

An attacker reached a workstation belonging to the user Velma through an exposed file share. A database backup in her Documents folder held her cleartext password along with a few hundred other credentials, and the same password was in use for her Windows account. The attacker logged on over the network and interactively with it, ran basic recon from a command prompt, opened a Python project in VSCode, then browsed to a public paste site, which is the likely exfiltration point. A note dropped in her Pictures folder afterwards signed off with the attacker’s handle. Everything was reconstructed from the Security and Sysmon event logs, Chrome history, the registry dump and the raw $MFT.

Artifacts

• KAPE-style collection: evidence/ → event logs parsed with EvtxECmd, $MFT with MFTECmd
• CrowdResponse output: CrowdResponse_regdump.csv, CrowdResponse_dirlist, DNS cache and network connection dumps → read with grep and Python
• Registry hives: config.7z holding SAM and SYSTEM → extract, then secretsdump
• Chrome profile: History SQLite database → sqlite3
• User files: Velma’s Documents and Pictures, including the InnoDB backup, a Python script and a ipynb notebook → strings and a text editor

Timestamp note: Questions use YYYY-MM-DD hh:mm:ss. All times in the collection are UTC and the events fall on 2023-10-06.

Initial Access

Share creation events (5140, 5142) were not logged, so the event logs cannot answer this. The shares live in the registry under LanmanServer\Shares, and the SYSTEM hive in the collection did not expose that key through regipy. The CrowdResponse registry dump does carry it. Each value holds a Path= entry, and two shares are defined: one for the whole Users tree and one for Velma’s Documents folder.

grep -a 'LanmanServer.Shares.*Path=' CrowdResponse_regdump.csv

Gotcha: The dump lists the Users share first, but the platform expects the narrower Documents share first. Order matters in the comma-separated answer.

The share from Q1 exposes Velma’s Documents. Under a logon website\bk\ folder sits an InnoDB backup (.ibd) of a login database. strings shows cleartext rows, including one for the velma user. On the event side, Security 4624 shows a network logon for Velma from 192.168.157.151 at 17:15:56, before any hands-on activity. The file is the only artifact containing her password in cleartext, so it is the access source. This was reasoned from those two facts rather than read from a single artifact that links them.

strings -a bk_db.ibd | grep -i velma

Credential Access

The backup stores one row per user, with the email address as the username. Pull every unique Gmail address out of the file with a regex and count them.

python3 -I -c "import re,sys; d=open(sys.argv[1],'rb').read(); print(len(set(re.findall(rb'[\w.+-]+@gmail\.[a-z.]+', d))))" bk_db.ibd

Extract config.7z for clean SAM and SYSTEM hives and dump the local hashes offline. Velma is RID 1002.

secretsdump.py -sam work/cfg/SAM -system work/cfg/SYSTEM LOCAL

Take the password from Velma’s row in the Q2 backup and test it against the Q4 hash with hashcat mode 1000. The candidate matches, so her Windows password and her application password are identical.

hashcat -m 1000 -a 0 work/nt.txt /usr/share/dict/rockyou.txt

Tip: Rockyou alone is not needed if you feed hashcat the password from the ibd row as a one-line wordlist.

Execution

Parse the Security log with EvtxECmd and filter 4624 for Velma from 192.168.157.151. Two records land in consecutive seconds: a type 3 logon from the authentication package and a type 10 (RemoteInteractive) logon one second later. The first of the two is the logon the platform accepts.

EvtxECmd -d evidence/ --csv work/evtx

Gotcha: The type 10 record is the textbook “interactive” logon, but the accepted time is the second before it, on the preceding type 3 record.

Sysmon Event ID 1 after the logon shows cmd.exe starting at 17:17:43. Its first child process, two seconds later, is the one-word answer, followed by net group and net users enumeration.

python3 -I list_sysmon_eid1.py work/evtx/*.csv --after "2023-10-06 17:17" --parent cmd.exe

Collection

Same Sysmon Event ID 1 listing: Code.exe starts at 17:18:26 with a Python script from Velma’s profile on its command line, and chrome.exe follows at 17:18:41.

python3 -I list_sysmon_eid1.py work/evtx/*.csv --after "2023-10-06 17:18" --image Code.exe,chrome.exe

Exfiltration

Copy the Chrome History database and read the urls table. The attacker searched Google for a paste service and then visited its site at 17:19:38, right after the VSCode session. No upload artifact survived, so this is the likely destination rather than a proven transfer.

sqlite3 work/ch/History "select datetime(last_visit_time/1000000-11644473600,'unixepoch'), url from urls order by last_visit_time"

Attribution

A learn.txt file was created in Velma’s Pictures folder at 17:23:46. The file itself was not collected, but it is small enough to be stored resident in its $MFT record. Locate the entry with MFTECmd, then read the resident data straight out of the raw record. It is a taunt signed with the attacker’s handle.

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

python3 -I parse_mft_resident.py '$MFT' 'Users\Velma\Pictures\learn.txt'

Attack Summary

Phase	Action
Initial Access	Attacker reaches Velma’s exposed Documents share
Credential Access	Reads her cleartext password from the InnoDB backup
Initial Access	Network logon as Velma from 192.168.157.151
Execution	Interactive logon, then cmd.exe
Discovery	whoami, net group, net users
Collection	Opens a Python project in VSCode
Exfiltration	Browses to a paste site in Chrome
Impact	Drops a signed taunt note in Pictures

Forensic Timeline

Timestamp (UTC)	Event
2023-10-06 17:15:56	Velma network logon from 192.168.157.151
2023-10-06 17:17:23	First logon of the interactive session (type 3)
2023-10-06 17:17:24	RemoteInteractive logon (type 10)
2023-10-06 17:17:43	cmd.exe starts
2023-10-06 17:17:45	First command runs from cmd.exe
2023-10-06 17:18:26	Code.exe opens the Python file
2023-10-06 17:18:41	chrome.exe starts
2023-10-06 17:19:38	Visit to the paste site
2023-10-06 17:23:46	learn.txt created in Pictures

IOCs

Type	Value
IP	192.168.157[.]151
Domain	pastes[.]io
Account	Velma (RID 1002)
File	C:\Users\Velma\Documents\...\logon website\bk\bk_db.ibd
File	C:\Users\Velma\Pictures\learn.txt
Handle	pwnmaster12

MITRE ATT&CK

Technique	ID	Description
Valid Accounts: Local Accounts	T1078.003	Logon as Velma with her real password
Unsecured Credentials: Credentials in Files	T1552.001	Cleartext password in the database backup
Brute Force: Password Cracking	T1110.002	NT hash matched against the backup password
Remote Services: Remote Desktop Protocol	T1021.001	RemoteInteractive (type 10) logon
System Owner/User Discovery	T1033	whoami as the first command
Account Discovery: Local Account	T1087.001	net users and net group
Command and Scripting Interpreter: Windows Command Shell	T1059.003	Hands-on cmd.exe session
Data from Local System	T1005	Project files opened in VSCode
Exfiltration Over Web Service	T1567	Paste site visited right after

Defender Takeaways

Never share a whole profile tree. A share on C:\Users and another on a user’s Documents folder let anyone who could reach SMB read a backup that was never meant to leave the machine. Restrict shares to named groups and review them regularly, since the share definitions here were only visible in the registry.

Keep credential backups out of user folders. An InnoDB file held cleartext passwords for hundreds of accounts. Hash application passwords, and treat database backups as sensitive data with controlled storage.

Password reuse turned an application leak into a host compromise. The password in the backup was also Velma’s Windows password, so the attacker needed no exploit at all. Unique passwords and MFA on remote logons break this step.

Log share activity. Events 5140 and 5142 were absent, so share access had to be inferred. Enabling file share auditing would have shown the original read of the backup.

Alert on a new logon followed within seconds by cmd.exe and recon. whoami and net users seconds after a remote logon from a new address is a cheap and reliable detection.

Conclusion

The attacker needed no exploit: a world-readable backup gave up a password that was reused on the Windows account, and the rest was a hands-on session ending at a paste site. The case turns on one reused credential and a share that should never have existed.