Network Service Exploitation with Metasploit

Step 1: The Metasploit Framework Architecture

Before you exploit anything, understand what Metasploit is and how it works. This is not just another tool -- it is an exploitation framework that formalizes a three-part relationship.

Module: The vulnerability being exploited. Metasploit has modules for specific CVEs, service weaknesses, and misconfigurations.

Payload: The code delivered to the target after the vulnerability is exploited. This could be a simple command shell or a full Meterpreter session with file system access.

Handler: The listener on your machine that catches the connection back from the exploited target.

AI assembles Metasploit commands fluently. It selects modules, configures payloads, and sets handler options without hesitation. But it makes architecture assumptions -- a linux/x86/meterpreter payload against an ARM container will silently fail. Verify that the payload matches the target before you execute.

Step 2: FTP Service Exploitation

Start with the FTP service. This is network-level exploitation -- fundamentally different from SQL injection in a web form.

Direct Claude to check the FTP service for anonymous access:

Connect to the FTP server on port 21 and check if anonymous access is enabled. If it is, list what files are accessible.

If anonymous FTP is open, examine what data is exposed. The sample-exports/ directory may contain patient-related CSV files. Downloading patient summaries, pharmacy inventory, and lab results via anonymous FTP is a data breach at the network layer. The ATT&CK technique is different from SQL injection. The risk narrative for Marie-Claire is different. The evidence looks different in the logs.

Step 3: SSH Brute-Force with Hydra

Move to the SSH service. Hydra is a credential brute-forcing tool -- it tries username/password combinations against a service until one works or the list is exhausted.

Direct Claude to test SSH credentials:

Use Hydra to test common credentials against the SSH service on port 22. Start with a small set of common username/password combinations relevant to the healthcare context.

Observe what happens. A brute-force attack against SSH produces a fundamentally different log pattern than web application attacks. Each failed attempt is a separate authentication event. The volume is distinctive -- dozens or hundreds of attempts in rapid succession.

The timing of the attack matters. Aggressive brute-forcing generates a burst of failed authentication logs that any monitoring system would flag. This connects to what you already know about scan timing trade-offs.

Step 4: Web Application Exploitation

Turn to the EHR web application on port 80. This is familiar territory from previous projects.

Direct Claude to test the search endpoint for SQL injection:

Test the /search endpoint on the EHR web application for SQL injection. The parameter is q.

The search endpoint at /search?q= uses string concatenation to build the SQL query. If successful, SQL injection here means access to the patients table -- names, diagnoses, prescriptions, clinic assignments. In a healthcare system serving communities in northern Haiti, that data includes HIV diagnoses and pregnancy records.

Test the clinical notes feature at /records/<patient_id> for stored XSS. Notes are rendered with an unsafe template filter.

Step 5: Attack Ordering

You chose a specific sequence: FTP, then SSH, then web application. Consider what would have happened with a different order.

If you had tested the web application first, the SQL injection attempts would have generated entries in the EHR access logs -- logs that the Alloy configuration is currently collecting. That activity might have been noticeable before you tested the network services. Starting with FTP and SSH was quieter in terms of what the current monitoring stack sees, because those log sources are not yet being collected.

If SSH brute-forcing had succeeded first, the credentials discovered there (Frantz's account) might have given you access to the web application without needing to test SQL injection at all.

AI defaults to executing attacks in the order they appear in the TTP selection, without considering how noise from one attack affects the viability of the next. The ordering is a judgment call.

Step 6: Packet Capture Analysis

Direct Claude to capture exploitation traffic with Wireshark or tshark and compare what different attack types look like at the network layer.

Use tshark to capture traffic during a brief SSH brute-force attempt and a SQL injection test. Show me the differences in the packet patterns.

SSH brute-force produces rapid repeated TCP connections to port 22 with short intervals. SQL injection appears as HTTP requests with crafted URL-encoded payloads. The patterns are visually distinct at the packet level. This preview shows you what your detection rules will need to match in the next unit.

Step 7: Scope Boundary Check

After successful exploitation, AI may suggest pivoting -- "now that we have FTP access, let's see what else is on the network" or "these SSH credentials might work on other systems."

Check every suggestion against the scope document. Pivoting between authorized services is permitted. Investigating the VPN to reach simulated clinic endpoints is not. The scope document at materials/scope-document.md defines the boundary.

Watch for context degradation. By this point in the session, Claude has been through reconnaissance, threat modelling, and multiple exploitation attempts. It may lose track of the scope constraints established at the beginning. If Claude suggests scanning a host that was explicitly excluded, or reverts to an aggressive timing flag you corrected earlier, recognize the pattern -- that is context loss, not a capability limitation.