> For the complete documentation index, see [llms.txt](https://capcap-1.gitbook.io/capcap/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://capcap-1.gitbook.io/capcap/readme/ctf-modules/exploitation/service-exploitation/approach.md).

# Approach

### Key notes

* Learn how a service works before attacking it.
* Break each flaw into source, process, privileges, and destination.
* Treat every small finding as a possible pivot.

### Quick workflow

1. Identify the service and protocol.
2. Use the native client or standard admin tool.
3. Validate authentication, access, and network reachability.
4. Enumerate for sensitive data and pivot paths.
5. Model any flaw through the attack cycle.

### Interacting with common network services

Successful service exploitation starts with understanding the service itself. You need to know its purpose, how it normally works, and which tools interact with it.

* **File shares (SMB):** SMB is common in Windows environments. Interact with it from Windows CMD (`net use`, `dir`, `findstr`), PowerShell (`New-PSDrive`, `Get-ChildItem`), or Linux (`mount -t cifs`).
* **Databases:** The most common relational targets are MSSQL and MySQL. Interact with them through CLI clients like `sqsh`, `sqlcmd`, and `mysql`, or GUI tools like SSMS, MySQL Workbench, and DBeaver.
* **Email:** Sending usually uses SMTP. Receiving usually uses POP3 or IMAP. Mail clients like Evolution can interact directly with these services.

If a connection fails, check these first:

* Authentication
* Privileges
* Network connection
* Firewall rules
* Protocol support

### The attack cycle

Most vulnerabilities fit a predictable four-part model. This helps you break down what the flaw needs and what it affects.

1. **Source:** The input entering the system. This can be user input, code, configuration, or an API call.
2. **Process:** The code path that handles the input. Vulnerabilities usually live here when input is trusted or processed unsafely.
3. **Privileges:** The permissions available to that process. This defines what the exploit can actually do.
4. **Destination:** The final target of the action. This can be local storage, memory, another process, or a remote system.

### JNDI lookups and Log4j

JNDI lets Java applications look up external resources without hardcoding connection details. The application asks for a resource, then resolves it dynamically.

Log4j became vulnerable when attacker-controlled input was treated as a JNDI lookup instead of plain text. A malicious string placed in a source like the `User-Agent` header reached the logging process, triggered a lookup, and caused the application to contact an attacker-controlled destination. If the application loaded a remote Java class, this could lead to remote code execution.

This maps cleanly to the attack cycle:

1. **Source:** Attacker-controlled input such as an HTTP header
2. **Process:** Log4j parses and resolves the JNDI string
3. **Privileges:** Code runs with the application's permissions
4. **Destination:** The application reaches out to an attacker-controlled server

### Finding sensitive information

Recon often works through chaining. One small detail can unlock the next system.

For example, a username from an anonymous FTP share can lead to mailbox access. That mailbox can expose database credentials. Those credentials can lead to RCE.

* **File shares:** Look for usernames, passwords, config files, API tokens, source code, and PII.
* **Email services:** Look for org charts, internal hostnames, DNS details, automated alerts, and temporary passwords.
* **Databases:** Look for application credentials, linked servers, and dangerous settings like `xp_cmdshell`.

### Core strategy

Deep service knowledge creates better enumeration. Target context makes that enumeration useful.

Understand both the technology and the business using it. That is usually where the best pivots appear.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://capcap-1.gitbook.io/capcap/readme/ctf-modules/exploitation/service-exploitation/approach.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.