dotrobin_SECURITY / ENGINEERING / EVIDENCE
◈   butler.mddotrobin.dev / workbench
FIELD NOTES / ISOLATED TRAINING LAB

Butler
A shell is evidence.

Intentionally vulnerable, isolated training VM. Commands are lab-only; LAB_TARGET and LAB_KALI stand for the target and callback addresses on that isolated network. Credentials and unrelated local data are omitted.

Result: SYSTEM execution on the Windows 10 lab VM. Jenkins led into Windows enumeration and a suspicious LocalSystem service. The final identity is proven; attribution to the precise service exploit remains incomplete.

Investigation path

Jenkins discovery → credential testing → Windows execution → WinPEAS → WiseBootAssistant investigation → verified SYSTEM shell. The final transition’s exact trigger was not retained.

01 / Locate Jenkins and establish access

The reconstructed scan targets the services investigated in this lab:

sudo nmap -sS -sV -Pn -n -p 22,80,8080 "$LAB_TARGET"

Jenkins was accessible on TCP/8080. Burp Suite Intruder tested login combinations against /j_spring_security_check. HTTP 302 redirects alone did not prove authentication; the subsequent workflow reached Windows execution. Credentials and the unrecorded initial-shell command are omitted.

02 / Enumerate the execution context

winpeas.exe

The retained enumeration identifies BUTLER\butler, high integrity, enabled administrator membership, SeImpersonatePrivilege and SeDebugPrivilege, and disabled UAC. These are context and candidate attack paths, not proof that a specific privilege was exploited.

WiseBootAssistant ran automatically as LocalSystem with this unquoted executable path:

C:\Program Files (x86)\Wise\Wise Care 365\BootTime.exe

03 / Inspect and test the service

The recorded service investigation used:

sc.exe qc WiseBootAssistant
sc.exe query WiseBootAssistant
sc.exe stop WiseBootAssistant
sc.exe start WiseBootAssistant
sc.exe queryex WiseBootAssistant

An unquoted path with spaces creates ambiguous executable resolution; exploitation also requires writable candidate locations and a way to trigger execution. The service initially returned error 1053. That startup error alone neither proves nor disproves payload execution.

04 / Confirm SYSTEM

The later saved screenshot shows a callback from the Butler VM to a Kali listener on TCP/7777:

# Kali listener
nc -lvnp 7777

# Captured Windows identity check
C:\Windows\system32>whoami
nt authority\system

This confirms SYSTEM execution and supersedes the earlier diagram’s “unconfirmed” label. It does not identify the executable that launched, its placement, or the triggering command.

Findings → fixes

  • Jenkins access: harden authentication and restrict build/script execution to authorized operators.
  • Privileged service context: reduce build-account privileges; review unnecessary administrative membership and disabled UAC.
  • Unquoted service path: quote the executable path and audit directory write permissions and service-control rights.
  • Verification: retain process creation and service-start evidence to connect the trigger to the elevated process.

Evidence limits

Jenkins discovery, WinPEAS findings, the service misconfiguration, callback, and SYSTEM identity are documented. The initial Jenkins command, payload placement, and exact escalation trigger are not. No full unquoted-path exploit chain or remediation retest is claimed.

← All selected write-ups

Explore the workbench

Use ↑ / ↓ to move, Enter to open, Esc to close.