Segmented VLAN and a Poisoning Dead End
Aster Manufacturing has 1,000 hosts across six internal VLANs. The engagement covers VLAN 10 (corporate), VLAN 20 (office), VLAN 30 (engineering), and VLAN 40 (file servers); VLAN 50 is the OT network and is explicitly excluded. You have ten days and no initial credentials. On VLAN 20, LLMNR/NBT-NS poisoning yields three NTLMv2 hashes in two hours. On VLAN 30, four hours of poisoning yields no hashes. SMB signing is enforced on servers but not workstations. You discover an unauthenticated Jenkins instance on VLAN 30 with script console enabled. The client wants lateral movement to the file server and a demonstration of business impact, but the plant manager has warned that any OT disruption stops production. You have a known wordlist and eight days left.
1. How do you decide whether to crack the NTLMv2 hashes or pivot to Jenkins, given 10 days and the OT exclusion?
Read the worked answer
Decide based on time-to-value and risk. Cracking NTLMv2 depends on password strength: if the domain policy allows 8-character passwords, a wordlist plus rules may work in hours; if it is 14+ characters, it may not crack in the remaining time. The three hashes are from office VLAN users, so they may not have file-server access. Jenkins is a direct unauthenticated code-execution path on the engineering VLAN, which is closer to the file server and may yield a service account with more access.
I would spend one day on a targeted cracking run with a known wordlist and rules, while simultaneously validating Jenkins. If the hashes do not crack by day 2, pivot to Jenkins. Before using Jenkins, check whether it is production, whether builds are running, and whether script console access is logged. Use it to run non-destructive commands and extract the Jenkins service account context. Then use that account to enumerate the file server. The OT VLAN is out of scope, so I would not use Jenkins to reach it even if a network path exists. Document the decision and the timebox.
2. What steps do you take before using Jenkins script console to avoid impacting production builds?
Read the worked answer
First, confirm the Jenkins instance's role and whether it is in scope: it is on VLAN 30, which is in scope, but the client may consider it production. Ask the client contact if there is a maintenance window or a test instance. Before executing, review the dashboard for running builds; do not trigger or cancel jobs. Use the script console only for read-only commands: whoami, hostname, environment variables, and a directory listing of the Jenkins home. Avoid any command that writes to the workspace, restarts the service, or changes configuration. If you need to prove code execution, use a benign command that writes a unique file to a temporary directory and then delete it, with client approval. Log the exact script and output. Have a rollback plan: know how to stop the Jenkins service if a command hangs. If the instance is production and the client has not approved, stop and escalate.
3. The client asks you to demonstrate access to the OT VLAN 'just to be thorough.' How do you handle scope?
Read the worked answer
I would decline and explain why. The rules of engagement explicitly exclude the OT VLAN, and OT systems often have safety and availability consequences that are different from IT. 'Just to be thorough' is not authorization. I would offer alternatives: (1) document the network path from the compromised host to the OT VLAN as a risk without crossing the boundary; (2) if the client wants OT testing, scope a separate engagement with OT specialists, a maintenance window, and safety controls; (3) ask the client to confirm in writing if they are expanding scope, and then re-plan with the engagement lead. I would also document the request and my refusal in the daily notes. The judgement is to protect the client from an unapproved outage and to protect the tester from liability.