Jugglin

Scenario

Jugglin is a medium difficulty Sherlock where you are tasked with analysing provided .apmx64 files within API monitor to confirm the actions taken by an attacker and insider threat within the Forela organsiation.

Using the API Monitor:

We are well-acquainted with opening PCAP and .EVTX files, but what are .apmx64? The .apmx64 file extension is associated with API Monitor, a software used to monitor and control API calls made by applications and services.

To commence your analysis, follow the steps provided below:

• Download the API Monitor
• Navigate to “Files” and click on “Open” to view captured data from the file: “Employee.apmx64” or “DC01.apmx64”
• After opening the file, the “Monitoring Process” window will populate with a list of processes. Expand the view by clicking the ’+’ symbol to reveal the modules and threads associated with each process.
• The API calls can be observed in the “Summary” window. To focus our analysis on a specific module, click on the different DLLs loaded by the processes.

Executive Summary

An insider on an employee workstation opened a Kali WSL console, ran an identity check, and read two notes that named the Win32 and Rtl string-conversion APIs a defender would need to hook to see WSL activity. The insider then called Windows PowerShell from inside the Linux shell to push data to an external host over HTTP. A second capture shows an attacker in a WSL session trying a credential-dumping tool that was not installed, pulling it from the same external host, and running it to print a domain user’s hash. Because WSL keeps Linux tooling outside the usual Windows process and command-line telemetry, the captures show this activity as console I/O and string-conversion API calls rather than ordinary child processes.

Artifacts

• Employee.apmx64: API Monitor capture from the insider’s workstation. An .apmx64 is a zip, so unzip exposes one data blob per monitored process
• DC01.apmx64: API Monitor capture from the domain controller, same format
• Attacker.apmx64: API Monitor capture of the attacker’s WSL session, same format

Tip: API Monitor is the intended viewer, but the per-process data blobs are raw captured memory. Running strings over them in both ASCII and UTF-16LE recovers the console text (typed commands, file contents, command output) much faster than clicking through the Summary window.

Format note: Several answers carry a character mask (* for unknown characters, letters fixed). It is a useful sanity check on long names such as the API functions.

Execution

Unzip the employee capture and pull ASCII and UTF-16LE strings from every process blob. The WSL console buffer repeats the shell prompt many times, and the user@host part of that prompt names the distribution.

unzip Employee.apmx64 -d work/x/employee

strings -n6 work/x/employee/process/*/data > work/x/employee.txt; strings -n6 -el work/x/employee/process/*/data >> work/x/employee.txt

grep -E '@MSI' work/x/employee.txt | sort | uniq -c | sort -rn | head

From Q3 the console is the Kali prompt, so read the strings around the first occurrence of that prompt. The first thing typed at it is the identity check people run on a fresh shell.

grep -n -m5 -A3 'kali@' work/x/employee.txt

Gotcha: The prompt text is printed before the command. Take what was typed after the prompt, not the prompt itself.

Unzip the attacker capture, build its strings file the same way, and search for the shell’s error text. Bash names the missing binary in the message, and the attacker then goes and downloads that same binary in Q10.

unzip Attacker.apmx64 -d work/x/attacker

grep -a 'command not found' work/x/attacker.txt

Collection

The Kali console buffer from Q1 continues with a directory listing and then a cat of a text file in the home directory.

grep -n -B2 -A4 'cat ' work/x/employee.txt | head -40

The output of the cat in Q4 is the flag. It is written in leetspeak and spells out an Rtl conversion function, which becomes the lead for Q2.

grep -n -A2 'cat flag.txt' work/x/employee.txt

Search the same console text for the second file name. Its contents open with a sentence about tracking Windows tools and end with the second flag, which names a different Rtl function from the one in Q5.

grep -n -B2 -A6 'confidential.txt' work/x/employee.txt

This one was reasoned rather than read straight from an artifact. The Q5 flag names RtlUnicodeToUTF8N, the conversion that console input takes on its way into a WSL process, and the answer wants two functions. The second is the Win32 counterpart for the same conversion, WideCharToMultiByte. The evidence pointing here is the flag text plus the two-API format.

Gotcha: The mask gives no letter hints, and plausible pairings built from MultiByteToWideChar and WideCharToMultiByte are wrong. Anchor on the Rtl name from the flag and add its Win32 counterpart.

Exfiltration

The insider calls Windows PowerShell from inside the WSL console, which is itself the evasion. Search for powershell.exe and read the full command line: a -c one-liner posting to the external host 3.6.165.8. The cmdlet in that line is the answer.

grep -a 'powershell.exe' work/x/employee.txt

Defense Evasion

The note in confidential.txt from Q8 is headed by the tracking-Windows-tools line, and the second flag spells the function in leetspeak. It is the opposite conversion direction from the Q2 function. This was read from the note’s wording, not from a traced call in the capture.

grep -n -i 'windows tools' work/x/employee.txt

Gotcha: RtlUnicodeToUTF8N fits the mask and is the function from the first flag, but it is the wrong direction. Tool invocation from WSL converts UTF-8 to UTF-16, so the name starts RtlUTF8.

No capture in this case shows this call directly, so the answer comes from WSL2’s architecture plus the nine-letter mask ending in e. WSL2 runs Linux in a lightweight VM, and traffic between the Windows side and the Linux side moves over pipe and socket handles. The Win32 call that writes to those handles is WriteFile. This is reasoned from reference knowledge, not read from an artifact.

Command and Control

From Q9 the missing tool is lsassy. In the attacker capture, the wget that follows the error pulls it from the same host the insider’s PowerShell talked to in Q6.

grep -a 'wget' work/x/attacker.txt

Credential Access

After the download, lsassy output is echoed into the attacker console. It prints a [SHA1] tag beside each recovered credential, and the value on the line for the user account is the answer.

grep -a '\[SHA1\]' work/x/attacker.txt

Attack Summary

Phase	Action
Execution	Insider opens a Kali WSL console and runs an identity check first
Collection	Insider reads a flag file and a note listing the string APIs to hook
Defense Evasion	Windows tools are driven from WSL so activity appears as console I/O and string conversion calls
Exfiltration	Insider calls PowerShell from the WSL shell to send data to an external host over HTTP
Execution	Attacker session runs lsassy, which is not installed
Command and Control	Attacker fetches lsassy from the external host with wget
Credential Access	lsassy output exposes the SHA1 hash of the user account

IOCs

Type	Value
IP	3.6.165[.]8
URL	hxxp[://]3[.]6[.]165[.]8/lsassy
Tool	lsassy
Hash (SHA1, account user)	e8f97fba9104d1ea5047948e6dfb67facd9f5b73

MITRE ATT&CK

Technique	ID	Description
Command and Scripting Interpreter: Unix Shell	T1059.004	Commands run in a Kali WSL console
Command and Scripting Interpreter: PowerShell	T1059.001	powershell.exe -c launched from WSL
Indirect Command Execution	T1202	Windows tools run through WSL rather than directly
Input Capture	T1056	Keystroke monitoring discussed as hooks on string conversion APIs
Exfiltration Over Alternative Protocol	T1048	Data sent to an external host with Invoke-WebRequest
Ingress Tool Transfer	T1105	lsassy downloaded with wget
OS Credential Dumping: LSASS Memory	T1003.001	lsassy used to pull credentials from a host

Defender Takeaways

WSL hides Linux tooling from standard Windows process telemetry. The insider and the attacker both ran commands inside a Linux console, so the evidence is console text and API calls rather than process trees. Monitor wsl.exe, bash.exe and the WSL host processes, and alert when they spawn powershell.exe or other Windows binaries.

String conversion APIs are a usable hook point. The notes in this case point at the UTF-16/UTF-8 conversions as the choke point where typed input and Windows tool output cross the WSL boundary. API-level capture of those calls exposes command text that command-line logging never sees.

Treat outbound HTTP to a bare IP from a WSL-launched PowerShell as exfiltration. The Invoke-WebRequest call and the lsassy download both went to the same address. A single egress rule on that host would have tied the insider and the attacker together.

Watch for credential-dumping tools arriving on any endpoint. lsassy is a known LSASS dumper and printed credential hashes straight into a console. Blocking downloads of such tools and alerting on LSASS access closes the step before hashes are printed.

Conclusion

An insider and an attacker both used WSL to keep their commands out of normal Windows telemetry, and the attacker ended by printing a user’s hash with a freshly downloaded lsassy. The case shows that WSL activity has to be monitored at the API or console level, because the process tree will not tell the story.