Competition Day Guide · Guide 04 · First 10 Minutes
First 10 Minutes
The first ten minutes should reduce uncertainty, not maximize the number of changes. Read the mission, assign ownership, capture the baseline, rank priorities, and begin one controlled work cycle.
A disciplined opening prevents the team from breaking required services, destroying evidence, duplicating work, or spending the round recovering from rushed decisions.
Opening Goal
Opening rule
The first ten minutes are for orientation before acceleration
Teams move faster later when they understand what must stay functional, who owns each platform, and which findings actually deserve immediate attention.
10-minute plan
Use the opening in short, deliberate blocks
0-2 minutes
Read before touching
Open the scenario, README, or competition instructions and identify required users, services, remote access, special restrictions, and scoring-sensitive functions.
2-4 minutes
Assign ownership
Confirm who owns Windows, Server, Linux, Cisco, forensics, and the shared status log. Avoid multiple people beginning on the same platform.
4-6 minutes
Capture the first baseline
Record the obvious starting state: approved users, privileged groups, required services, listeners, network status, and anything immediately suspicious.
6-8 minutes
Rank the first priorities
Separate mission-breaking issues, high-confidence security problems, useful hardening, and low-confidence findings.
8-10 minutes
Begin the first controlled work cycle
Start with the highest-value issue that has clear evidence and a safe verification path. Do not launch several broad changes at once.
Read the mission
Confirm ownership
Baseline the environment
Prioritize
Do not rush into
Avoid high-impact changes before context is clear
Bulk account deletion
Disabling unfamiliar services
Turning off RDP or SSH automatically
Broad firewall rewrites
Recursive permission changes
Large ACL edits
Unplanned software removal
Deleting suspicious files before evidence capture
Rebooting systems to see what happens
Changing several platforms before the team has a shared baseline
Priority model
Rank work before the team scatters
P1
Mission-breaking or critical
Required service failure, approved access failure, dangerous unauthorized privilege, major persistence, or broken network path.
P2
High-confidence security issue
The evidence is strong, the risk is meaningful, and the remediation is understood and verifiable.
P3
Useful hardening
Security improvement with lower urgency than confirmed privilege, persistence, service, or network issues.
P4
Low-confidence or cosmetic
The evidence is weak, the value is low, or the change carries more risk than the likely benefit.
Opening baseline
Capture enough state to know what changes later
Hostname / device identity
System time and time zone
Approved users
Privileged groups
Required services
Remote-access state
Important listeners
Basic IP / route state
Critical shares or applications
Obvious scheduled tasks / cron / timers
Immediate suspicious processes or services
Current platform owner
Weak opening vs better opening
Replace immediate action with informed action
Weak opening
Start securing the machine immediately.
Better opening
Read the scenario, identify required functions, capture the baseline, then begin with the highest-value confirmed issue.
Weak opening
Everyone should check for something suspicious.
Better opening
Assign platforms and issue ownership before parallel work begins.
Weak opening
Disable anything that is not obviously needed.
Better opening
Classify accounts, services, listeners, and tasks before changing them.
Weak opening
Fix easy settings first to build points quickly.
Better opening
Prioritize mission impact, security impact, evidence confidence, and reversibility.
Weak opening
We can document later.
Better opening
Start the shared log immediately so the original state and first changes are not lost.
Weak opening
If the first command works, keep going.
Better opening
Verify the result and required functionality before stacking more changes on top.
Opening questions
The team should be able to answer these by minute ten
What absolutely must keep working?
Which users and administrators are approved?
Which services or roles are explicitly required?
Which remote-access methods are required or forbidden?
Which platform has the highest current risk?
What evidence should be preserved before remediation?
Who owns each system right now?
What is the first change we can safely verify?
Opening warning signs
These signals mean the team is moving faster than its understanding
A teammate is already making changes before the scenario is read.
Two people are working the same platform.
Nobody has written down required services.
The team cannot say which account changes are approved.
A broad firewall or service change is being attempted immediately.
The shared log is still empty after several minutes.
No one knows what the current top priority is.
The team is making changes faster than it is verifying them.
First 10 Minutes final checklist
Finish the opening with context, ownership, and one safe next action
Scenario / README was read before major hardening.
Required users and administrators were identified.
Required services and remote-access paths were identified.
Special restrictions were recorded.
Platform ownership was assigned.
Shared status log was opened.
Initial baseline was captured.
High-value evidence was preserved.
First priorities were ranked.
No broad low-confidence changes were started.
The first remediation has a verification plan.
The team knows what it is doing next.