For the complete documentation index, see llms.txt. This page is also available as Markdown.

Overview

The actions on objective phase is where the operator shows the real-world impact of the access achieved. It encompasses data access, credential extraction, persistence establishment, and any other actions that fulfill the engagement's defined objectives.

Strategic context

Everything preceding this phase, reconnaissance, initial access, privilege escalation, lateral movement, exists to reach this point. Actions on objective answer the question the client is actually asking: what can an attacker do with this access, and what does it mean for our organization?

The specific actions depend entirely on the engagement objectives. A penetration test may require demonstrating access to sensitive data. A red team operation may require simulating a specific threat group. An assumed breach assessment may focus on how far access can be extended from a starting position. In each case, the operator's actions must be tied directly to what the client needs to understand about their risk.

Documentation is critical in this phase. The engagement's value to the client depends on how clearly the operator communicates what was accessed, how it was accessed, and what it means. Evidence collected during this phase forms the core of the engagement report.

For security leaders, actions on objective show the actual business impact of the security weaknesses identified throughout the engagement. A list of vulnerabilities is useful, but demonstrating that those vulnerabilities led to access to customer data, financial systems, or production infrastructure communicates risk in terms that drive organizational action. This is what you want to show your board to support your budget request.

Categories

Data access and evidence collection

Identifying and documenting access to sensitive data shows business impact. This includes file shares containing confidential information, databases with customer or financial data, email access, and cloud resources.

The goal is to demonstrate what an attacker could access, not to exfiltrate large volumes of data. A screenshot of a file listing, a record count, or a sample of non-sensitive fields is typically sufficient evidence.

# Search SMB shares for sensitive content
manspider TARGET -u user -p pass -c password secret confidential

# Search file systems
findstr /si "confidential" *.docx *.xlsx *.pdf

Credential harvesting

Extracting credentials at this stage serves two purposes: it shows the scope of compromise, and it provides evidence of how deep the access extends. Extract only the credentials needed to support the accomplishment of engagement objectives. Dumping all domain credentials can create huge headaches for IT teams.

The existence of cached, stored, or extractable credentials across multiple systems shows systemic credential management weaknesses.

Cloud resource access

When cloud service credentials are obtained, through SSRF, metadata services, configuration files, or credential extraction, the impact extends beyond the local environment.

Cloud access shows that a compromise of on-premise infrastructure can cascade into cloud resources, or vice versa:

Cloud service access often reveals additional credentials, configuration data, and resources that expand the scope of demonstrated impact.

Common mistakes

  • Failing to demonstrate business impact

  • Exfiltrating more data than necessary

  • Not collecting sufficient evidence (screenshots, logs, hashes) for reporting

  • Forgetting to remove persistence mechanisms

Operator notes

  • Every action in this phase should be tied to an engagement objective

  • Documenting evidence is not optional

  • Consider the client's monitoring capabilities when collecting evidence

Last updated