Post cover image

October 31, 2026

Network Based Attacks CTF 1

Task 1: Get the Perimeter Host to Release Its Diagnostic Token

By Shubhampanchal

18 min read

1. Objective

The objective of this challenge was to perform reconnaissance on the perimeter host, identify its diagnostic service, understand why a normal connection was rejected, and access the service by using the expected source port to retrieve the diagnostic token.

Target host: 192.7.24.3 Diagnostic service port: 13337/TCP Expected source port: 53 Tools used: Nmap and Netcat

2. Step 1 — Initial Reconnaissance

The first step was to identify the target host and determine which TCP ports were open. Since the challenge mentioned a diagnostic service but did not initially reveal its behavior, service discovery was required.

Command

nmap -sV -Pn 192.7.24.3

Command explanation

  • nmap: Network exploration and port-scanning tool.
  • -sV: Attempts to identify the services and versions running on open ports.
  • -Pn: Skips host discovery and treats the target as online, which is useful when ICMP or other discovery probes are blocked.
  • 192.7.24.3: IP address of the perimeter host.

Purpose

This scan was used to identify open TCP ports and gather information about the services exposed by the target.

Observation: The diagnostic listener was associated with TCP port 13337. This port became the focus of further investigation.

Note: The initial scan identifies the service port, but it does not by itself establish the special source-port requirement.

3. Step 2 — Scan the Identified Diagnostic Port

After identifying TCP port 13337 as the likely diagnostic service, a targeted scan was used to investigate it more closely.

Command

nmap -sV -p 13337 192.7.24.3

Command explanation

  • -sV: Attempts service detection.
  • -p 13337: Scans only TCP port 13337.
  • 192.7.24.3: Target perimeter host.

Purpose

A targeted scan reduces unnecessary scanning and focuses on the port relevant to the challenge.

Interpretation

The port scan helped identify the diagnostic listener. However, an open TCP port does not guarantee that the application will accept every connection. The application can impose additional checks after the TCP connection is established.

4. Step 3 — Attempt a Normal Connection

The next step was to connect to the diagnostic service using Netcat without specifying a special source port.

Command

nc -nv 192.7.24.3 13337

Command explanation

  • nc: Netcat, a utility for establishing network connections.
  • -n: Disables name resolution.
  • -v: Enables verbose connection information.
  • 192.7.24.3: Destination IP address.
  • 13337: Destination TCP port.

Result

The service returned an access-denied message indicating that the diagnostic channel expected a management source port.

Analysis

This response was an important clue. It indicated that the service was not relying only on the destination port. It was also checking a property of the incoming connection: the client's source port.

Ordinarily, an operating system selects an available ephemeral source port for an outgoing TCP connection. In this case, the service expected a specific low-numbered source port.

Therefore, the next step was to identify the expected port from the challenge description.

5. Step 4 — Analyze the Source-Port Clue

The challenge stated that the diagnostic service responded only to connections that presented themselves as low-numbered, well-known traffic, such as DNS, rather than using a random high-numbered source port.

DNS commonly uses port 53. Based on this clue, source port 53 was selected for the next connection attempt.

Important networking concept

A TCP connection has two endpoints:

  • Source endpoint: The IP address and port of the connecting client.
  • Destination endpoint: The IP address and port of the server.

For this task:

Parameter Value Client source port 53 Server destination IP 192.7.24.3 Server destination port 13337/TCP

The source port and destination port are different values and serve different purposes. Selecting source port 53 does not mean the client is connecting to the server's DNS service.

6. Step 5 — Connect Using Source Port 53

Netcat was used again, this time explicitly requesting source port 53.

Command used successfully

sudo nc -nv -p 53 192.7.24.3 13337

Command explanation

  • sudo: Runs Netcat with elevated privileges. On typical Linux systems, binding to a port below 1024 requires elevated privileges.
  • nc: Starts Netcat.
  • -n: Disables DNS name resolution.
  • -v: Displays verbose connection information.
  • -p 53: Requests local source port 53.
  • 192.7.24.3: Target perimeter host.
  • 13337: Destination TCP port of the diagnostic service.

Why did this work?

The ordinary connection was rejected because it used an automatically assigned source port. The second connection explicitly requested source port 53, satisfying the service's source-port check in this lab.

The sudo prefix allowed the client to request the low-numbered source port on the local machine.

7. Step 6 — Read the Diagnostic Service Banner

After the connection succeeded, the service returned the following information:

ASHCROFT-LOGISTICS NETDIAG v2.1
----------------------------------------
link: UP   mtu: 1500   mgmt: SNMP(v1) enabled on this host
diagnostic token: Flag1_dde4887e645d484da935ed5606ff217a

Information obtained

Service identification: ASHCROFT-LOGISTICS NETDIAG v2.1

Network status: The service reported that the network link was up and the MTU was 1500 bytes.

Management information: SNMPv1 was reported as enabled on the host. This was useful reconnaissance information for subsequent tasks.

Diagnostic token:

Flag1_dde4887e645d484da935ed5606ff217a

The token was recorded as the result of Task 1.

8. Step 7 — Document the Findings

The relevant findings were recorded for use in subsequent challenges.

Finding Result Target host 192.7.24.3 Diagnostic service ASHCROFT-LOGISTICS NETDIAG v2.1 Service port TCP 13337 Required source port 53 Normal connection Rejected by the application Connection with source port 53 Successful Management protocol disclosed SNMPv1 Token retrieved Flag1_dde4887e645d484da935ed5606ff217a

The SNMPv1 information was retained as a clue for investigating the management layer in the next challenge.

9. Conclusion

Task 1 was completed by following a structured reconnaissance and connection-testing process. Nmap was first used to identify the diagnostic listener. A normal Netcat connection then revealed that the application enforced a source-port requirement. The challenge description suggested DNS port 53, so Netcat was configured to request that source port. The service accepted the connection and disclosed the diagnostic token, along with information about the host's network status and SNMPv1 management configuration.

Key lessons learned

  1. Port scanning helps identify exposed services, but it does not reveal every application-level access restriction.
  2. A TCP connection's source port is distinct from its destination port.
  3. Netcat can request a specific local source port using -p.
  4. Ports below 1024 generally require elevated privileges on Linux.
  5. Service banners can disclose useful information for later enumeration.
  6. SNMP information revealed by one service can provide a lead for subsequent management-layer investigation.

Security takeaway: Source-port checks alone are not a strong authentication mechanism. A client can often select a low-numbered source port when it has the necessary privileges, so services should rely on robust authentication and authorization rather than trusting a port number as proof of identity.

None None None

Explanation of command flag

  • sudo — runs the command with elevated privileges.
  • nc — Netcat, used to connect to a network service.
  • -n — disables DNS name resolution.
  • -v — displays detailed connection information.
  • -p 53 — requests local source port 53, commonly associated with DNS.
  • 192.7.24.3 — target host IP address.
  • 13337 — destination port hosting the diagnostic service.

Task 2: Interrogate the Host's Management Layer

1. Objective

The objective was to enumerate the perimeter host's SNMP management service, discover the correct community string, and retrieve the information exposed by the management layer. The enumeration was also intended to reveal a token and an account username useful for subsequent tasks.

2. Step 1 — Identify the SNMP service

During Task 1, the diagnostic service banner revealed that SNMPv1 was enabled on the perimeter host. SNMP commonly uses UDP port 161, so we investigated this management service.

We performed a targeted scan to check whether the SNMP port was accessible:

sudo nmap -sU -p 161 -sV 192.7.24.3

Command explanation:

  • sudo — runs the scan with elevated privileges.
  • nmap — network scanning and service discovery tool.
  • -sU — scans UDP ports.
  • -p 161 — targets UDP port 161, commonly used by SNMP.
  • -sV — attempts to identify the service and version.
  • 192.7.24.3 — perimeter host IP address.

3. Step 2 — Test the default community string

SNMPv1 uses a community string to control access to management information. We initially tested the common default value public.

snmpwalk -v1 -c public -t 2 -r 1 192.7.24.3

Command explanation:

  • snmpwalk — queries SNMP objects and retrieves their values.
  • -v1 — selects SNMP version 1.
  • -c public — supplies public as the community string.
  • -t 2 — waits up to 2 seconds for a response.
  • -r 1 — retries once.
  • 192.7.24.3 — target host.

The request did not return the expected management information. Since the challenge explicitly stated that the host would not respond to the obvious defaults, we proceeded to discover the correct community string.

4. Step 3 — Discover the community string

We used onesixtyone, an SNMP community-string discovery tool, to test candidate community strings from a wordlist against the target.

onesixtyone -c communities.txt 192.7.24.3

Command explanation:

  • onesixtyone — tests candidate SNMP community strings.
  • -c communities.txt — specifies a file containing candidate strings.
  • 192.7.24.3 — target host IP address.

The tool tested the candidate values and identified the community string accepted by the lab host. We then used that value in the next enumeration step.

5. Step 4 — Enumerate the management information

After identifying the correct community string, we used snmpwalk to retrieve the management information exposed by the host.

snmpwalk -v1 -c mngt 192.7.24.3

Command explanation:

  • snmpwalk — retrieves available SNMP objects and their values.
  • -v1 — uses SNMP version 1, as indicated by the diagnostic banner.
  • -c mngt — supplies the discovered community string.
  • 192.7.24.3 — target perimeter host.

The command queries the accessible SNMP management information, potentially including system details, network information, and other exposed management objects.

6. Step 5 — Save and review the complete output

Since the SNMP enumeration could return a large amount of information, we redirected the output to a file for easier examination.

snmpwalk -v1 -c mngt 192.7.24.3 2>&1 | tee snmp_results.txt

Command explanation:

  • 2>&1 — combines standard error with standard output.
  • | — passes the combined output to the next command.
  • tee snmp_results.txt — displays the output in the terminal and saves it to snmp_results.txt.

To review the saved information page by page, we used:

less snmp_results.txt

In less, the Space key moves forward, b moves backward, and q exits.

We examined the returned SNMP objects to locate the token and the account username mentioned in the challenge description.

7. Methodology summary

  1. Identified SNMPv1 as a management service from the Task 1 diagnostic banner.
  2. Checked UDP port 161 using Nmap.
  3. Tested the default SNMP community string public.
  4. Used onesixtyone with a candidate wordlist to discover the expected community string.
  5. Used snmpwalk with the discovered string to enumerate the management information.
  6. Saved the complete output to snmp_results.txt and reviewed it for the token and account username.

8. Key learning

SNMP enumeration can expose useful information about a host's configuration and management environment. A community string acts as an access credential for SNMPv1 and SNMPv2c, so default values should not be assumed to work. Combining service discovery, community-string testing, and systematic output review provides an effective methodology for investigating an SNMP service in an authorized lab.

Task 3: Enumerate the Host's File Services Without Credentials

1. Objective

The objective of this task was to enumerate file-sharing services on the perimeter host, identify shares accessible without credentials, and read the information stored in an openly accessible share.

2. Enumerate SMB Shares

I used the smbclient utility to list the SMB shares available on the target host without providing a password.

smbclient -L //target1.ine.local/ -N

Command explanation:

  • smbclient — a command-line utility for accessing SMB file shares.
  • -L — lists the available shares on the target server.
  • //target1.ine.local/ — specifies the target host.
  • -N — attempts to connect without requesting a password.

Result: The server listed three shares:

ShareTypeDescriptionpublicDiskPublic Staff NoticesbackupDiskBackup Operators OnlyIPC$IPCIPC Service (BR-EDGE01 File Services)

The public share appeared to be intended for general access, whereas backup was labelled for backup operators. This identified the shares to investigate further.

3. Access the Public Share Without Credentials

Next, I connected directly to the public share without providing a password.

smbclient //target1.ine.local/public -N

Command explanation:

  • //target1.ine.local/public — specifies the public share on the target host.
  • -N — attempts access without a password.

Result: The connection succeeded, confirming that I could access the public share without supplying a password.

4. List the Files in the Share

After connecting, I used the ls command inside the SMB interactive prompt.

smb: \> ls

Command explanation:

  • ls — lists the files and directories available in the current share.
  • smb: \> — indicates that commands are being entered inside the SMB session.

Result: The share contained a file named note_to_staff.txt, which became the next file to inspect.

5. Read the Exposed File

To read the contents of the file, I could use the following command inside the SMB prompt:

more note_to_staff.txt

Alternatively, I could download it to the local machine and read it there:

get note_to_staff.txt

Then, after exiting the SMB session:

cat note_to_staff.txt

The file's contents should be recorded as evidence because they may contain information relevant to the task.

6. Methodology Summary

  1. Used smbclient -L to enumerate the target's SMB shares without a password.
  2. Identified the public, backup, and IPC$ shares.
  3. Connected to the public share using -N.
  4. Used ls to enumerate the files in the share.
  5. Identified note_to_staff.txt as an exposed file.
  6. Read the file to inspect the information available without authentication.
None None

7. Key Learning

SMB enumeration can reveal shared resources and their descriptions. Connecting with -N tests whether a share permits access without a password. A share may expose files to unauthenticated users even when other shares on the same server require credentials. Such exposure can reveal internal information that should not be publicly accessible.

Task 4: Access the Restricted Backup Share

1. Objective

The objective of this task was to access the restricted backup SMB share on the perimeter host, discover valid credentials, and retrieve the backup notes containing information about the internal network.

2. Use Information Gathered from Previous Tasks

During Task 2, SNMP enumeration revealed the username svc_backup. This username provided a useful starting point for investigating access to the backup service.

During Task 3, SMB enumeration revealed three shares on target1.ine.local:

  • public — Public Staff Notices
  • backup — Backup Operators Only
  • IPC$ — IPC Service

I successfully accessed the public share without credentials and read note_to_staff.txt. The notice explicitly stated that the backup share was restricted to backup operators and required credentials.

3. Test Access to the Restricted Share

I first attempted to access the backup share without credentials:

smbclient //target1.ine.local/backup -N

The connection failed with NT_STATUS_ACCESS_DENIED, confirming that anonymous access was not permitted for this share.

This indicated that valid authentication was required to access the restricted backup files.

4. Brute-Force the SMB Password Using Hydra

Using the username svc_backup discovered during Task 2, I used Hydra with the provided password wordlist to test possible passwords against the SMB service.

hydra -l svc_backup -P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt target1.ine.local smb

Command explanation:

  • hydra — a tool for testing credentials against supported network services.
  • -l svc_backup — specifies the username to test.
  • -P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt — supplies a file containing candidate passwords.
  • target1.ine.local — identifies the target host.
  • smb — specifies SMB as the service being tested.

Result: Hydra identified a valid password for svc_backup. This provided the credentials needed to attempt authenticated access to the restricted share.

5. Authenticate and Enumerate the Backup Share

After obtaining the credentials, I connected to the restricted share using the discovered username.

smbclient //target1.ine.local/backup -U svc_backup

I entered the password identified by Hydra when prompted.

After authentication, I listed the contents of the share:

smb: \> ls

The share contained the file backup_notes.txt.

6. Download and Read the Backup Notes

I downloaded the file from the authenticated SMB session:

smb: \> get backup_notes.txt

After exiting the SMB session, I read the downloaded file locally:

cat backup_notes.txt

The file revealed a backup token and information about an internal file server, FILE02, identified by the hostname target2.ine.local.

The notes explained that FILE02 only accepts file-share connections originating from the perimeter host, BR-EDGE01. Direct connections from other systems are refused, and the svc_backup account has SSH access to the perimeter host.

7. How Task 4 Leads to Task 5

The backup notes provided the key information for the next task:

  • Internal host: FILE02
  • Hostname: target2.ine.local
  • Access restriction: File-share connections must originate from BR-EDGE01.
  • Suggested approach: Use the perimeter host as a pivot to reach the internal file server.

This indicates that the next step is to establish a route or forwarding path through the perimeter host and enumerate the SMB shares on FILE02. The internal server may need to be discovered by its IP address if the hostname cannot be resolved from the attacking machine.

8. Methodology Summary

  1. Reused the svc_backup username discovered through SNMP enumeration in Task 2.
  2. Used Task 3's public-share notice to identify backup as a restricted share.
  3. Confirmed that anonymous access was denied.
  4. Used Hydra with a password wordlist to discover a valid SMB password.
  5. Authenticated to the backup share using svc_backup.
  6. Downloaded and read backup_notes.txt.
  7. Identified FILE02 and the requirement to access it through BR-EDGE01, providing the direction for Task 5.
None None

9. Key Learning

Information gathered during reconnaissance can be combined to gain access to restricted resources. SNMP enumeration revealed a username, SMB enumeration identified a restricted share, and password testing supplied valid credentials. The backup notes then exposed an internal network dependency, demonstrating how access to one host can provide a path toward an otherwise inaccessible internal server.

Task 5: Reach the Internal File Server

1. Objective

The objective of this task was to access an internal file server that could not be reached directly from the attacking machine. The perimeter host, BR-EDGE01, acted as the intermediate system. I used SSH local port forwarding to reach the internal SMB service, enumerate its shares, and retrieve the token from a share accessible without credentials.

2. Use the Information from Task 4

In Task 4, I accessed the restricted backup share using the svc_backup account and retrieved backup_notes.txt.

The notes identified the internal server:

  • Internal server: FILE02
  • Hostname: target2.ine.local
  • Perimeter host: BR-EDGE01
  • Access restriction: FILE02 accepts file-share connections originating from BR-EDGE01.
  • Available access: The svc_backup account has SSH access to the perimeter host.

This information indicated that I needed to use the perimeter host as a jump point instead of attempting to access the internal SMB service directly.

3. Connect to the Perimeter Host Using SSH

I connected to the perimeter host using the credentials obtained in Task 4.

ssh svc_backup@192.252.120.3

Command explanation:

  • ssh — establishes a secure remote connection.
  • svc_backup — the account used to authenticate.
  • 192.252.120.3 — the perimeter host's IP address used in my lab.

After accepting the host key and entering the password, I successfully obtained an SSH session on the Ubuntu perimeter host.

4. Verify the Internal Hostname

After logging in, I inspected the host's /etc/hosts file:

cat /etc/hosts

The output contained an entry mapping target2.ine.local to the internal server's address. This helped identify the destination hostname that the perimeter host could resolve.

Because the internal server was reachable from the perimeter host, I could use SSH local port forwarding to access its SMB service through that host.

5. Establish SSH Local Port Forwarding

From the attacking machine, I created an SSH tunnel:

ssh -N -L 1445:target2.ine.local:445 svc_backup@target1.ine.local

Command explanation:

  • ssh — creates the SSH connection to the perimeter host.
  • -N — keeps the SSH connection open without starting a remote shell.
  • -L 1445:target2.ine.local:445 — forwards local port 1445 to port 445 on the internal server, as reached from the perimeter host.
  • svc_backup@target1.ine.local — authenticates to the perimeter host using the svc_backup account.

In this setup, connections sent to local port 1445 were forwarded through the SSH connection to the internal server's SMB port 445.

I kept this SSH tunnel running while accessing the SMB service in another terminal.

6. Enumerate the Internal SMB Shares

With the tunnel established, I used smbclient to enumerate the shares through the forwarded port:

smbclient -L //127.0.0.1 -p 1445 -N

Command explanation:

  • smbclient — interacts with SMB file shares.
  • -L — lists the shares offered by the server.
  • //127.0.0.1 — connects to the local end of the SSH tunnel.
  • -p 1445 — uses the forwarded local port rather than the default SMB port.
  • -N — attempts SMB access without a password.

The enumeration revealed the following shares:

ShareTypeDescriptiondropboxDiskInternal Dropboxsql-backupsDiskSQL Backups (Restricted)IPC$IPCIPC Service (FILE02 Internal Files)

This confirmed that the forwarded connection reached the internal file server. The dropbox share was the best candidate because it was an internal drop location and the task specifically required reading a share that did not require credentials.

7. Access the Drop Box Share Without Credentials

I connected directly to the dropbox share through the forwarded port:

smbclient //127.0.0.1/dropbox -p 1445 -N

After connecting, I listed the files:

smb: \> ls

The share contained:

README.txt

This demonstrated that the internal dropbox share permitted access without supplying SMB credentials.

8. Download and Read README.txt

I downloaded the file from the SMB session:

smb: \> get README.txt

After exiting the SMB session, I read it locally:

cat README.txt

The file contained an internal token and database-maintenance information:

  • Internal token: Flag5_a57320fd26c145f0b2999ed3608fb173
  • Restricted share: sql-backups
  • Account: db_admin
  • Password: Sql!Backup2024

The README also described the dropbox as a temporary location for the internal network segment and marked the database-maintenance information as restricted.

9. How Task 5 Leads to Task 6

The README provides the next investigation lead:

  • The sql-backups SMB share is restricted.
  • A database-maintenance account, db_admin, is mentioned.
  • The file provides a password associated with that account.

These details suggest that Task 6 will involve investigating the restricted SQL backup share and determining whether the supplied account can access it. The next step is to test the provided credentials against the appropriate service within the authorized lab and inspect any accessible backup files.

10. Methodology Summary

  1. Used the svc_backup credentials from Task 4 to connect to the perimeter host over SSH.
  2. Checked /etc/hosts to identify the internal server.
  3. Established an SSH local port forward from local port 1445 to the internal server's SMB port 445.
  4. Enumerated the SMB shares through the forwarded connection.
  5. Identified dropbox as the share to investigate for unauthenticated access.
  6. Connected to dropbox without an SMB password.
  7. Downloaded and read README.txt.
  8. Retrieved the Task 5 token and identified the restricted sql-backups share and database account as leads for Task 6.
None None None None None

11. Key Learning

SSH local port forwarding allows a user to reach a service on an internal network through a host that can access that service. In this task, the SSH connection authenticated to the perimeter host, while the forwarded connection reached the internal SMB service. This allowed me to enumerate the internal server and retrieve a file from a share that did not require SMB credentials.

Task 6: Break into the Restricted Database Share

1. Objective

The objective of this task was to authenticate to the restricted SQL backup share on the internal file server using credentials discovered in the previous task, retrieve the database export file, and recover the final token.

2. Use the Information Discovered in Task 5

During Task 5, I accessed the internal server, FILE02, through SSH local port forwarding. After enumerating its SMB shares, I discovered:

  • dropbox — an internal share accessible without credentials.
  • sql-backups — a restricted share containing SQL backups.
  • IPC$ — the server's SMB inter-process communication share.

I connected to the dropbox share and read README.txt. The file contained the credentials required for the restricted database share:

  • Username: db_admin
  • Password: Sql!Backup2024

The task description hinted that the required credentials had already been discovered during the previous task, so I reused those credentials rather than starting a new password-discovery process.

3. Connect to the Restricted SQL Backup Share

With the SSH tunnel from Task 5 still running and forwarding local port 1445 to the internal server's SMB port 445, I connected to the restricted share:

smbclient //127.0.0.1/sql-backups -p 1445 -U db_admin

Command explanation:

  • smbclient — connects to an SMB file share.
  • //127.0.0.1/sql-backups — specifies the sql-backups share through the local end of the SSH tunnel.
  • -p 1445 — uses local port 1445, which forwards traffic to the internal SMB service.
  • -U db_admin — authenticates using the database-maintenance username.

When prompted, I entered the password obtained from README.txt.

Result: Authentication succeeded, and I obtained access to the restricted SQL backup share.

4. Enumerate the Share Contents

After connecting, I listed the files available in the share:

smb: \> ls

The output showed the file:

db_export.txt

This identified the database export file containing the information required to complete the task.

5. Download the Database Export

I downloaded the file through the authenticated SMB session:

smb: \> get db_export.txt

The file was transferred from the restricted share to my local machine. I then exited the SMB session:

smb: \> exit

6. Read the File and Recover the Final Token

I displayed the downloaded file using:

cat db_export.txt

The file contained the following message:

FILE02 - SQL BACKUPS (RESTRICTED, db_admin only)
Database export integrity token: Flag6_3ad1b472a5ce4fc4b4ae1dc8d5a5f576

This confirmed that I had successfully accessed the restricted share and recovered the final token.

Final token: Flag6_3ad1b472a5ce4fc4b4ae1dc8d5a5f576

7. Methodology Summary

  1. Reused the db_admin credentials discovered in Task 5.
  2. Kept the SSH local port-forwarding tunnel active to reach the internal SMB service.
  3. Connected to sql-backups through 127.0.0.1:1445.
  4. Authenticated using the db_admin account.
  5. Enumerated the share and identified db_export.txt.
  6. Downloaded and read the database export file.
  7. Retrieved the final integrity token, completing Task 6.
None

8. Key Learning

This task demonstrated how information discovered during one stage of an assessment can enable access in a later stage. The credentials were exposed in a file on the internal dropbox share during Task 5. Reusing those credentials, together with the established SSH tunnel, allowed me to access the restricted database share and retrieve the final token without needing to brute-force the database account.

9. Overall CTF Learning

Across Tasks 1–6, I followed a progression from service discovery and SNMP enumeration to SMB share enumeration, credential discovery, SSH pivoting, and access to a restricted internal resource. Each task supplied information needed for the next stage, demonstrating the importance of documenting findings and connecting evidence across an authorized penetration-testing workflow.