Module 20: Mission Objectives and Reporting

← Return to the Red Team Course #

A red-team report is a decision record. It links an approved objective to observed evidence, impact, limits, remediation ownership, and a retest condition. A dramatic technique name without those links does not help the customer choose a fix.

This module creates a mission finding package. You will write a bounded objective, separate expected from observed behavior, and design a retest another assessor will reproduce.

Allow 35–50 minutes. Difficulty: intermediate. The report example is synthetic.

Learning Outcomes #

• Define objective, observation, impact, limitation, and retest.
• Explain why protocol support does not prove a configured access path.
• Apply an evidence chain to a host or identity finding.
• Evaluate competing explanations and remediation choices.
• Create a concise finding package with an owner and retest.

Start With the Objective #

An objective names the decision the assessment must inform. “Compromise the network” is too broad. “Determine whether the approved service account reads the reporting share from the staging host during the maintenance window” is testable.

Separate Expected and Observed #

Expected behavior comes from documentation, a lab fixture, or a hypothesis. Observed behavior comes from a timestamped command, event, trace, or owner confirmation. A report should label the difference so a reader does not confuse a planned step with a completed action.

SSH supports several authentication methods when configured. A Linux host joins an Active Directory domain, yet neither fact proves a stolen password, an interactive user, or administrative access. State the configured method and evidence source.

Build the Evidence Chain #

An evidence chain has five links: objective, action, observation, interpretation, and decision. If a link is missing, reduce the claim. A failed collection step belongs in the limitation field rather than being silently treated as a negative result.

Impact should be concrete. Name the account, resource, data class, or control affected. Avoid universal claims such as “full domain compromise” unless the evidence in practice establishes the required authority and path.

Watch a Reporting Context #

Compass Security’s incident-response discussion complements the reporting lesson by showing why evidence, timeline, and ownership matter after an event. Use it to consider which facts a defender needs first. Watch the discussion on YouTube .

**The video is context, not evidence for your finding. Your report still needs its own commands, events, timestamps, and scope.

Write a Finding #

Use a finding structure which makes review quick. Put the decision first, then the evidence and limits which support it.

Title:
Objective and scope:
Observed condition:
Evidence references and timestamps:
Impact and affected owner:
Limitations and alternate explanations:
Remediation recommendation:
Remediation owner and target date:
Retest procedure and success condition:

Title should describe the condition and consequence, not a tool name. Remediation should address the weak boundary identified in the evidence. Retest should repeat the disputed operation after the fix and state what result closes the finding.

Analyze a Synthetic Finding #

**Assume a staging Linux host uses an approved SSH certificate. The server log records a successful certificate authentication for the named assessment account. The account reads one application directory but cannot write it. No evidence shows access to production hosts or plaintext passwords.

The supported conclusion is scoped read access to the staging directory through the configured certificate method. The report should not claim stolen passwords, production access, or domain compromise. A remediation owner narrows the account’s directory ACL or remove the certificate after the window.

Choose Remediation and Retest #

A remediation should change the condition enabling the finding. Rotating an unrelated password does not repair a directory ACL. Removing a certificate without checking alternate keys or service accounts might leave the same access path open.

The retest must preserve the same objective, source, target, and operation unless the change intentionally alters one of them. Record the new result and any residual limitation.

Preserve the Timeline #

Timestamps connect operator actions, endpoint events, server logs, and owner decisions. Use a consistent timezone and identify clock uncertainty. An event ID without host, channel, or collection status is difficult to validate.

Evidence retention follows the engagement agreement. Keep raw records and a readable analyst extract when possible. Do not delete customer logs to make the report shorter. If data was unavailable, say which collector, host, or time range was missing.

Create the Mission Package #

Write a one-page mission finding for the synthetic SSH case. Include one alternate explanation and a retest which was able to disprove your conclusion. Identify a remediation owner and the artifact which proves closure.

Completion standard: A reviewer identifies the question, observed result, impact boundary, limitation, owner, and repeatable retest without reading the entire course.

Self-Check and Answers #

Next Steps #

You have completed the Red Team Course sequence. Return to the course hub to review each module, then apply the mission package format to a new approved exercise.