Challenge 0 : The Single Host

[AURORA SYSTEMS ASSESSMENT #A-221]

Mira here, running point on this engagement. Last quarter we absorbed a smaller firm and inherited one undocumented box: a legacy asset-management server at auroralab. No inventory, no owner, nobody left who configured it. Before we harden it, we have to know what it exposes.

Why start with a port scan?
The services that get a box owned are rarely exotic. Remote-admin services left in a default state are the bread and butter of initial access: VNC can hand over a live desktop, SSH a shell, FTP a whole directory tree. None of that needs a software exploit. They are configuration failures, and enumeration is how you find them.

A note on privileges:
You are an unprivileged user in this lab, so SYN and UDP scans (which need raw sockets) are off the table. A plain TCP connect scan reaches everything we need on this pass. SNMP lives on UDP 161 and gets its own tooling later.

Your task:
Scan auroralab for open TCP ports 21, 22, and 5900. One of them will fingerprint as a remote-desktop service. That is your entry point for the next challenge.

Hint: Unprivileged nmap selects connect mode on its own, so no scan-type flag is needed. Add -sV so the service banners are readable.

Challenge 1 : VNC Fingerprinting and Open Access

[AURORA SYSTEMS ASSESSMENT #A-221]

You found VNC on port 5900. It speaks RFB, the Remote Frame Buffer protocol. Before touching it, fingerprint it, because the fingerprint tells you whether it even asks for a password.

What to look for:
Every VNC server advertises a list of security types during its handshake. That list is the whole authentication story. If it includes a real type, the server expects a credential. If the only type offered is None, the server authenticates nobody: any client that connects lands on the desktop. x11vnc started with -nopw ends up exactly here, and it is one of the most common remote-desktop exposures in the wild.

Why nmap is enough:
The vnc-info script completes just enough of the handshake to read the advertised security types, then reports them. When it sees an open server it prints a blunt warning that the server requires no authentication. You do not need a client, a display, or a password to prove the finding. The scanner states it for you.

Your task, step by step:
1. Run nmap -p 5900 -sV auroralab and confirm the service is VNC on RFB 3.8.
2. Run nmap -p 5900 --script vnc-info auroralab.
3. Read the security types. None (1) means no credentials, and the script says so outright.

Hint: The line that closes the finding begins with WARNING:. A numbered security type other than None would mean the server is asking for something. Here it is not.

Challenge 2 : SSH Authentication Methods

[AURORA SYSTEMS ASSESSMENT #A-221]

SSH next. Same discipline: nmap, then the service.

Why fingerprint again?
SSH servers disagree on what they accept: passwords, keys, or both. The banner names the implementation and version; the ssh-auth-methods script probes as a named user and lists exactly which methods are enabled. If password auth is on the list, the box is brute-forceable and the plan writes itself. If it is keys only, you stop and look elsewhere. You learn that before spending a single guess.

Your task, step by step:
1. Run nmap -p 22 -sV auroralab and confirm the SSH banner.
2. Run nmap -p 22 --script ssh-auth-methods auroralab and note whether password authentication is enabled.

Challenge 3 : SNMP Community String and OID Walk

[AURORA SYSTEMS ASSESSMENT #A-221]

SNMP is the quietest service here and the most misread. A minute on what it actually is pays off.

Why no nmap this time:
SNMP runs on UDP 161, and probing UDP needs raw-socket privileges you do not have. That is fine. SNMP has its own clients that speak plain UDP from any account, and they are what analysts reach for anyway.

What it is:
The Simple Network Management Protocol lets one monitoring station ask hundreds of devices the same questions without logging into each. A router, a switch, a printer, a UPS, and a Linux server all expose the same schema, the MIB (Management Information Base). The client is the manager, the agent runs on the device. snmpget asks for one value; snmpwalk asks for every value under a branch.

How it authenticates:
Versions 1 and 2c have no usernames or passwords. Each request carries a plaintext community string. If it matches, the agent answers. That is the whole model. The default is public, then private. If the previous owner never changed them, they still work.

How it is addressed:
Every value has a numeric OID. The system group at 1.3.6.1.2.1.1 holds the description, uptime, contact, name, and location. Symbolic names map to those numbers through standard MIBs, so you rarely type the digits.

Your task, step by step:
1. Walk the system group with the common default: snmpwalk -v2c -c public auroralab system.
2. If the agent answers, read every line. One free-text field holds the flag.
3. If it stays silent, try the other classic default. It is documented publicly.
4. Drop the system argument to walk everything the agent will share.

Hint: The community string travels in cleartext, so knowing the value is the whole game. snmptranslate -On system shows the numeric OID behind a symbolic name. Read the text fields, not just the numeric ones.

Challenge 4 : FTP Anonymous Access

[AURORA SYSTEMS ASSESSMENT #A-221]

Fourth service: FTP on TCP 21. Same discipline: nmap, then connect.

Why nmap again?
The banner names the daemon and version, and nmap's default scripts test anonymous login for you. One run tells you the door is open before you type a single command, and it is quieter than logging in blind.

What FTP is:
Two channels. A control channel on TCP 21 carries commands and the plaintext login; a data channel opens on demand for each transfer and directory listing.

What anonymous access is:
An old convention for public file distribution. When it is enabled, any client logs in with the literal username anonymous and any password, and gets whatever directory was marked public. Convenient, and routinely left on by accident.

Your task, step by step:
1. Run nmap -p 21 -sV -sC auroralab and note whether anonymous login is reported as allowed.
2. Connect with lftp auroralab, automatically logging in as anonymous.
3. Run ls to see the share, and cd into any subdirectories.
4. Read anything that looks like a flag with cat <filename>.
5. Shortcut: curl ftp://auroralab/<path> speaks FTP directly.

Hint: The anonymous-login script prints a line starting Anonymous FTP login allowed when the server is open. lftp is easier to drive than the classic client. The flag is a text file under the top of the shared directory.

Challenge 5 : From SNMP to SSH

[AURORA SYSTEMS ASSESSMENT #A-221]

Here enumeration turns into investigation. The SNMP data you pulled earlier is not just inventory. One free-text field holds a note an admin left behind, and that note carries a username and password for a second account on this host.

Why nmap again?
Before you spend a credential, confirm the target is still there. A quick nmap -p 22 -sV auroralab proves SSH is up and the box has not moved.

Why this matters:
Credential reuse across services is the single most common jump from a low-value finding to real access. SNMP here is read-only, but what it leaks opens a service that is not. This is how chains get built: one harmless-looking leak feeds the next step.

Your task, step by step:
1. Run nmap -p 22 -sV auroralab to confirm SSH is up.
2. Re-read the system group you walked in Challenge 3.
3. Pull the username and password from the field that does not match its schema.
4. Log in with ssh <user>@auroralab. The flag prints when the shell starts.

Hint: You already walked this MIB. Look at the fields meant for human text, not numbers or timestamps. One of them is carrying something it should not.