Field Manual

Before you start: No prior technical experience. Keep a notebook for questions and discoveries.

Cybersecurity involves investigation, building, communication, and judgment. You do not have to enjoy every part of it. Try several kinds of work before choosing a specialization. Curiosity and a repeatable learning habit are more useful starting points than buying a stack of exams.

Degrees, certifications, and prior IT work can help; employer requirements vary. A help-desk role can build strong foundations, but it is not the only route. Neither a certification nor visibility online guarantees a job. Your learning plan should fit your available time, responsibilities, and target roles.

• Start with two focused sessions each week and keep a record of what you tested.
• When stuck, record the exact error, your hypothesis, and one change at a time.
• Use breaks and sustainable study hours; ask for support when difficult material or investigations affect you.

Try it — worked exercise

Spend one session reading a provided log and another building a simple web server in your own lab. For each, write what interested you, what frustrated you, and what you want to understand next.

Expected result & troubleshooting

You should have two small artifacts and a better sense of the work you enjoy. Difficulty on a first attempt is normal; distinguish a missing prerequisite from a lack of interest.

Defender’s view / practical application

Analysts and engineers both need clear notes. Practice separating observed facts, interpretations, and next actions. That habit transfers across technical and governance roles.

Reference: NIST NICE Framework

Before you start: Understand the difference between building a control, testing it, and monitoring it.

Job titles overlap. Use tasks and required skills to compare roles rather than assuming every “analyst” or “engineer” job is the same. Learn networking and operating-system basics before specializing. Add certifications when they support a role or an identified knowledge gap.

Try it — worked exercise

Choose three current job descriptions in one path. Build a matrix: recurring task → skill required → evidence you already have → a lab that closes the gap. Pick one gap for the coming week.

Expected result & troubleshooting

A useful plan contains specific actions such as “explain a failed login using its event fields,” rather than “learn all of security.” Do not count repeated job advertisements as independent evidence of demand.

Defender’s view / practical application

Every role benefits from understanding how its output is used: an alert needs an investigation path, a finding needs remediation, and a policy needs an owner and evidence of implementation.

Reference: NIST NICE Framework

Before you start: No tooling required. Use a system you understand, such as a student portal.

Try it — worked exercise

For the student portal, write one failure for each CIA property. Then choose a preventive control and an observation that would demonstrate the control works.

Expected result & troubleshooting

A good answer is testable: “User A cannot retrieve User B’s record, and the denied request is logged.” “The system is secure” is not a measurable result.

Defender’s view / practical application

Map each proposed control to evidence and a responsible owner. A control that exists on paper but cannot be demonstrated may not reduce the risk you identified.

Reference: FIRST CVSS v4.0

Before you start: Know the core vocabulary and the difference between an observation and a conclusion.

An IP address, a filename, or a failed login alone rarely identifies an attacker. Indicators of compromise are useful clues; behavior and context make them meaningful. Baselines must account for administrators, scheduled jobs, vulnerability scanners, and normal maintenance.

Try it — worked exercise

Scenario: a service account has 40 failed sign-ins followed by one success. Write three explanations: password attack, stale saved credentials, and a legitimate password change. List the evidence that would distinguish them.

Expected result & troubleshooting

You should identify the host, account, time window, failure reasons, successful session, and any subsequent action. The success may be unrelated unless you correlate the details.

Defender’s view / practical application

Build detections around a question and an action: what makes this unusual, what could explain it, and what should the analyst check next? A high alert count is not the same as good detection coverage.

Reference: MITRE ATT&CK · Microsoft event 4625

Before you start: A computer with virtualization support, free disk space, and guest images matching its CPU architecture.

Suggested starting allocation for a basic Kali VM: 4 GB RAM and 40–60 GB disk, adjusted to your host and tasks. This is a planning baseline, not a universal product minimum. Start with Kali plus one ordinary Linux target; add Windows and a domain controller after basic networking works. Large SIEM stacks need their own sizing review.

• Download from the vendor and verify its published checksum.
• Create separate lab-only accounts and an isolated network.
• Take a clean snapshot before exercises; snapshots are not independent backups.
• On Kali, use the distribution’s guest packages rather than assuming an ISO-based Guest Additions install is required.
• Keep a record of image version, architecture, IP address and snapshot name.

Terminal

# Linux inventory — run inside your VM
uname -m
cat /etc/os-release
ip -br addr
ip route
df -h
free -h
# Kali guest tools, if needed after updating the VM
sudo apt update
sudo apt install virtualbox-guest-x11

Try it — worked exercise

Boot your Linux VM, record its architecture and IP, take a snapshot, create a text file, and restore the snapshot. Check whether the test file remains.

Expected result & troubleshooting

The VM should boot cleanly and the post-snapshot file should disappear after restoration. If the VM cannot start, check host virtualization support, available RAM, and architecture compatibility before changing networking.

Defender’s view / practical application

A reliable lab makes security experiments reproducible. Keep targets isolated, avoid personal credentials, and record every deliberate configuration change.

Reference: Kali virtualization guides · Kali guest tools · VMware download and licensing

Before you start: Know which machine is the host, which are guests, and which interface is used for the exercise.

The host counts above describe conventional subnets with network and broadcast addresses; /31 point-to-point links are a special case. Private address space includes 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Private does not mean authorized: your employer or household may use the same ranges.

Linux / PowerShell — run only the commands for your OS

# Linux: address → route → neighbor → service
ip -br addr
ip route
ip neigh
ping -c 3 192.168.56.20
ss -lntup
# Windows PowerShell equivalents
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Get-NetNeighbor
Test-NetConnection 192.168.56.20 -Port 8000

Try it — worked exercise

Put two lab guests on one isolated network: analyst 192.168.56.10/24 and target 192.168.56.20/24, after confirming that subnet does not conflict with your existing networks. Compare guest-to-guest connectivity with the configured routes. Do not add a gateway unless the exercise needs one.

Expected result & troubleshooting

Both guests should have the intended addresses. A blocked ping does not prove the host is down; test a known allowed TCP service. If a guest unexpectedly reaches the internet, inspect every adapter, forwarding rule, NAT service and host route.

Defender’s view / practical application

A sensor on a switched or virtual network does not automatically see all traffic. Capture at an endpoint, configure supported mirroring, or route traffic through the sensor. Record the visibility boundary.

Reference: Oracle virtual networking · Linux ip reference · Linux ss reference

Before you start: Use your own domain or an explicitly scoped training domain. Distinguish third-party lookups from direct target requests.

Passive research uses information already published or held by third parties. It is not a promise of “no footprint.” Search providers and platforms may log your activity. Opening a discovered website contacts that site; authoritative DNS lookups and some tools can also generate target-visible traffic.

Terminal

# Search-engine queries — replace example.com with your scoped domain
site:example.com filetype:pdf
site:example.com "security"
site:example.com "careers"

# DNS queries — these are queries to a resolver, not guaranteed invisible
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer
dig example.com NS +noall +answer
dig example.com TXT +noall +answer
dig example.com SOA +noall +answer
# Query the exact name/type needed; ANY is not a complete zone dump.

Try it — worked exercise

Build a small asset-evidence table with hostname, source URL, collection time, apparent owner, confidence, and an explicit “not yet validated” flag. Cross-check one result using a second independent source.

Expected result & troubleshooting

You should distinguish an observed name from an approved test target. Do not expand scope based on a search result. Missing records may reflect caching, filtering, split DNS or an incorrect name.

Defender’s view / practical application

Use the same inventory to identify unintended disclosures and stale public records. Remove unnecessary exposure through the responsible owner rather than attempting to hide essential public services.

Before you start: Define the question, approved scope and minimum information needed before choosing a tool.

Tool help and reference note

# Record installed-tool help before choosing source-specific flags
theHarvester -h
recon-ng -h

# A research note, not a command
Question: Which hostnames are publicly associated with the scoped domain?
Observation: A certificate includes portal.example.com.
Source and time: Record the exact certificate/source and UTC time.
Confidence: Moderate association; current ownership not established.
Next action: Ask the asset owner to validate scope.

Use API keys through each tool’s supported secret configuration. Avoid placing them in screenshots, shared notebooks, shell history or URLs. A dataset with many records is not necessarily accurate or recent.

Try it — worked exercise

Take five findings from one source. Deduplicate names, preserve original evidence, and label each as confirmed, plausible, contradicted or unresolved. Explain one discarded result.

Expected result & troubleshooting

A smaller evidence-backed list is better than an unqualified tool dump. If a source returns zero results, check syntax, API access, rate limits and date coverage before concluding that an asset does not exist.

Defender’s view / practical application

OSINT hygiene includes published metadata, naming conventions and accidental disclosures. Keep findings focused on the authorized organization; minimize unrelated personal information.

Before you start: Nmap installed; one approved lab target at 192.168.56.20; a known service to compare with results.

Terminal

# Discovery limited to the authorized training subnet
nmap -sn 192.168.56.0/24 -oA lab-discovery
# One known target, narrow service set
nmap -sT -sV -p 22,80,443,8000 --reason 192.168.56.20 -oA lab-services
# A known host that blocks discovery
nmap -Pn -sT -p 8000 192.168.56.20
# Optional UDP checks, only when included in lab scope
sudo nmap -sU -p 53,123,161 192.168.56.20 -oA lab-udp
# Read script descriptions before executing scripts
nmap --script-help "vuln and safe"
nmap -sV -p 8000 --script http-title,http-headers 192.168.56.20

NSE correction: --script "vuln and safe" selects the intersection. --script vuln,safe selects either category and is not “safe vulnerability scripts only.” A safe label does not guarantee zero impact. Review individual scripts. -A enables OS detection, version detection, default scripts and traceroute; it is not merely a faster scan.

Try it — worked exercise

Start the small HTTP lab in the exploitation section, then scan port 8000. Save output, stop the server, and repeat. Compare the evidence rather than only the service label.

Expected result & troubleshooting

Expect an open port while the server is listening, and a different state after it stops, depending on the firewall. If the result disagrees, check the listening address, VM IP, firewall and network mode.

Defender’s view / practical application

Compare scan timestamps and source IPs with firewall or endpoint logs. Use this to test telemetry coverage, not to assume every scan produces an IDS alert.

Reference: Nmap script selection · Nmap port states · Nmap service detection

Before you start: A Windows or Samba lab server, a known share and a lab account approved for access tests.

Terminal

# Linux: list shares; enter the lab password at the prompt
smbclient -L //192.168.56.20 -U labuser
# Open only the named training share
smbclient //192.168.56.20/training -U labuser
# Inside smbclient
ls
pwd
help
quit

# Windows PowerShell: local server configuration, with suitable rights
Get-SmbShare
Get-SmbShareAccess -Name training
Get-SmbSession
Get-SmbServerConfiguration |
  Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature

Assess share permissions and file-system permissions together. Test using the intended ordinary user, not only an administrator. Keep credentials out of command arguments and reusable reports.

Try it — worked exercise

Place a harmless instructor-provided text file in the training share. Compare listing and reading it as two lab identities with different permissions. Record the intended and observed results.

Expected result & troubleshooting

The restricted identity should receive the intended denial. If both users succeed, inspect group membership, inherited permissions and cached sessions before claiming a vulnerability.

Defender’s view / practical application

Correlate authentication records with share/object auditing when configured. A network logon is common administration activity; detection needs the identity, host, resource and behavior together.

Reference: Samba smbclient reference · Microsoft event 4625

Before you start: Know TCP versus UDP and remember that software can listen on nonstandard ports.

Terminal

# Inspect headers on your training service
curl --head --max-time 10 http://192.168.56.20:8000/
# Inspect a response without following redirects automatically
curl --silent --show-error --dump-header response-headers.txt   --output response-body.html http://192.168.56.20:8000/
# Confirm a listener on the Linux target
ss -lntup

Try it — worked exercise

Compare a service’s configured port, local listening socket and remote scan result. Record transport, address, product evidence and whether authentication is required.

Expected result & troubleshooting

A matching port number is a starting hypothesis. HEAD may be unsupported even when GET works. TLS errors should be investigated, not routinely bypassed with curl’s insecure option.

Defender’s view / practical application

Prioritize unnecessary exposure and weak access boundaries. The presence of a port is not automatically a reportable vulnerability.

Reference: curl reference · Linux ss reference · Nmap service detection

Before you start: A scoped lab or supplied scenario. Map the observed behavior, not just a tool’s name.

MITRE ATT&CK catalogs adversary behavior; OWASP WSTG organizes web testing. A weakness such as XSS is not automatically equivalent to a single ATT&CK technique. Choose a mapping after understanding execution context, objective and evidence.

Try it — worked exercise

In an instructor-provided web lab, compare access to a test record as its owner and as another ordinary user. Document the request, response and expected authorization rule. Use only synthetic records.

Expected result & troubleshooting

A valid finding shows unauthorized access, not merely a different status code. Exclude cached content and intentionally public records before concluding that access control failed.

Defender’s view / practical application

Write a paired test: the authorized action should succeed and the unauthorized action should fail. Log enough identity and resource context to distinguish them.

Reference: OWASP Web Security Testing Guide · MITRE ATT&CK · PortSwigger Web Security Academy

Before you start: An IPv6-enabled lab host. Substitute the actual interface name and a known lab address.

IPv6 uses 128-bit addresses. A /64 contains 2⁶⁴ addresses, so an exhaustive sweep is not a sensible host-discovery method. Use DNS, address inventories, neighbor information, logs and known endpoints. Neighbor Discovery replaces ARP’s IPv4 role; it uses ICMPv6. Avoid blanket ICMPv6 blocking.

Terminal

# Linux: inspect your own interfaces and known neighbors
ip -6 addr show
ip -6 route show
ip -6 neigh show
# Link-local ping: replace eth0 and the address with actual lab values
ping -6 -c 3 fe80::1%eth0
# DNS AAAA asks for an IPv6 record; transport can still be IPv4
dig example.com AAAA +noall +answer
# Scan one explicitly configured ULA lab endpoint, not a /64
nmap -6 -sT -p 22,80,443 fd12:3456:789a::20

# Windows PowerShell
Get-NetIPAddress -AddressFamily IPv6
Get-NetRoute -AddressFamily IPv6
Get-NetNeighbor -AddressFamily IPv6

Try it — worked exercise

Find your guest’s link-local address and interface. Communicate with a known peer on the same isolated link. Compare the neighbor table before and after. Separately check whether your lab has a configured ULA or global address.

Expected result & troubleshooting

A link-local address does not imply internet connectivity. If a link-local request fails, check interface scope, peer address and firewall policy. Do not replace real addresses with 2001:db8 examples and expect connectivity.

Defender’s view / practical application

Inventory and monitor IPv6 alongside IPv4. Assess rogue router advertisements, unexpected DNS behavior and policy differences using evidence; IPv6 being enabled is not by itself a vulnerability.

Reference: IANA IPv6 address space · Linux ip reference

Before you start: A supplied PCAP or capture permission on your own lab interface. Confirm the capture point and time zone.

Capture-filter reference / terminal

# Capture filters (different syntax from display filters)
host 192.168.56.20
tcp port 8000
net 192.168.56.0/24
not tcp port 22

# TShark: analyze an existing capture
tshark -r lab.pcapng -Y 'dns.flags.response == 0'
tshark -r lab.pcapng -Y 'http.request' -T fields   -e frame.time -e ip.src -e http.host -e http.request.uri
tshark -r lab.pcapng -q -z conv,tcp
tshark -r lab.pcapng -Y 'tcp.stream eq 0' -V

Capture filters decide what is collected; display filters select from what was collected. Follow TCP Stream, Protocol Hierarchy and Conversations help connect packets into a story. TLS application data remains encrypted without suitable session secrets and supported decryption; “Follow Stream” does not defeat encryption. A capture cannot show traffic outside its visibility.

Try it — worked exercise

Capture one request to your lab’s HTTP server on port 8000. Find the TCP handshake, request method, response status and connection endpoints. Compare a fresh connection with a repeated browser request.

Expected result & troubleshooting

You should identify an HTTP transaction when the traffic is captured and decoded. If no packets appear, check interface selection and filters. Checksum warnings can result from host offloading; retransmissions can reflect capture loss as well as network problems.

Defender’s view / practical application

Join network observations with endpoint and service logs. Record what the capture cannot establish, including traffic on other paths and encrypted content.

Reference: Wireshark User’s Guide · TShark reference · Wireshark DNS fields

Before you start: A defined asset list, assessment window, contact and evidence location.

Record the CVSS version and vector, not just a number. Severity bands do not prescribe universal 30/90/180-day deadlines. Remediation priority also depends on exposure, business context, active exploitation and the organization’s policy. CISA KEV is evidence of exploitation in the wild; absence from KEV is not evidence of safety.

Example finding — illustrative, not a live assessment

Finding: Lab HTTP directory listing exposes a synthetic note
Asset: 192.168.56.20:8000
Observed condition: The root path lists note.txt without authentication.
Evidence: Request/response, timestamp, file name; use synthetic contents.
Impact: In this configuration, anyone who can reach the service can retrieve it.
Limits: This is a deliberate training server, not proof of a production exposure.
Fix: Stop the unnecessary server or replace it with a properly configured service.
Retest: Confirm the listing is unavailable and the intended function still works.

Try it — worked exercise

Compare two hypothetical findings: a high-severity isolated test service and a lower-scored internet-facing issue with known exploitation. Write the missing questions before choosing a remediation order.

Expected result & troubleshooting

A defensible priority explains why the asset matters, who can reach it, what controls exist and how urgently action is needed. Do not lower severity simply because you failed to exploit a condition.

Defender’s view / practical application

Keep detection and remediation connected. Preserve evidence of exposed behavior and verify monitoring during the retest; a clean scanner result alone may not prove the control works.

Reference: FIRST CVSS v4.0 · CISA Known Exploited Vulnerabilities · OWASP Web Security Testing Guide

Before you start: One or two approved lab targets. Check the license and scan policy available in your installed version.

Offer checked September 12, 2026: Tenable’s current Essentials product page describes a 30-day, non-commercial/personal license for up to 5 IPs, without reporting or data export. It also describes Essentials Plus access for verified students and instructors. Older references to an unrestricted-duration 16-IP Essentials offer should not be used to plan a new lab. Review current terms and preserve your own permitted notes before expiry.

• Create a named lab policy and record its important settings.
• Run a narrow baseline scan and confirm the intended target answered.
• Inspect plugin output and affected software/configuration.
• Cross-check one result using local configuration or a vendor advisory.
• Apply a reversible lab remediation, then repeat the same relevant checks.

Try it — worked exercise

Scan one ordinary lab VM before and after a planned package update. Compare the scanner evidence with the guest’s installed package records. Identify at least one result that needs context rather than automatic acceptance.

Expected result & troubleshooting

Your notes should show whether the scan authenticated and what changed. If credentials fail, fix and rerun the coverage step. Do not treat an empty result list as proof of no vulnerabilities.

Defender’s view / practical application

Label authorized scanner addresses in your monitoring records while still watching for unusual activity from them. Scanner suppression should be precise and time-bounded, not a permanent blind spot.

Reference: Tenable Nessus Essentials

Before you start: An isolated training target and a snapshot. Match each test to the exact lab objective and authorized impact.

Exploitation demonstrates that a weakness can produce an unintended effect. It does not always create a shell: reading another test user’s record or bypassing a workflow can establish impact. Begin with the least invasive proof that answers the question, then document what remains untested.

Terminal

# Metasploit console reference: inspect before selecting an action
msfconsole
search type:auxiliary name:http_version
use auxiliary/scanner/http/http_version
info
show options
set RHOSTS 192.168.56.20
set RPORT 8000
run
back
sessions
exit

The example above identifies an HTTP service; it does not exploit one. For an exploit exercise, use the instructor’s exact target/module and read its documentation, options and side effects. Never assume check is harmless. Bind sessions require the tester to reach a listener on the target; reverse sessions require the target to reach the tester. Routing, firewall rules and addressing decide whether either can work.

Worked lab — intentional HTTP exposure

# On the isolated Linux target, in a new empty training directory
mkdir -p ~/c6-http-lab
cd ~/c6-http-lab
printf 'Synthetic training note
' > note.txt
python3 -m http.server 8000 --bind 192.168.56.20

# On the analyst VM
curl --fail --show-error http://192.168.56.20:8000/note.txt
# Stop the server with Ctrl-C on the target when finished.

Try it — worked exercise

Use the commands to serve a synthetic note on the isolated network. Retrieve it once, capture the request/response and explain the lack of authentication. Stop the server and verify the service is no longer available.

Expected result & troubleshooting

The response should contain “Synthetic training note.” This demonstrates exposed content, not arbitrary code execution. If binding fails, the target does not have that address or the port is occupied. Python’s development server is not a production service.

Defender’s view / practical application

Correlate the request with the target’s access log and process/listener evidence. For more advanced exercises, define the detection and cleanup checks before running the exploit.

Reference: Metasploit module workflow · Metasploit module checks and side effects · Python development HTTP server

Before you start: An explicitly authorized lab session. Define which post-access actions are allowed before attempting them.

Linux / Windows — use the appropriate shell

# Linux session orientation
whoami
id
hostname
pwd
ip route
ss -lntup

# Windows session orientation
whoami
whoami /groups
whoami /priv
hostname
ipconfig /all
route print
netstat -ano

Credential access, persistence, lateral movement and data transfer each require explicit scope. A foothold does not authorize every action on the host. For a beginner exercise, prove access with a synthetic marker and document identity; avoid collecting real secrets. An ordinary shell and Meterpreter have different commands—use the current session’s help, not a mixed command list.

Reference checklist

Action log fields:
UTC time | session/host | action | observed result | artifact | cleanup
Cleanup checklist:
Stop the training process; remove only the named lab artifacts.
Revert approved permission changes or restore the agreed snapshot.
Confirm the expected services and access still work.
Record what could not be restored and notify the instructor/owner.

Try it — worked exercise

After the HTTP lab, list the listening service and process, stop it, and record the before/after evidence. Inventory only the files created by that exercise and remove them after retaining the required training notes.

Expected result & troubleshooting

Cleanup should be demonstrable: no training listener, no unexpected running process and a complete action log. Do not delete logs to “clean up”; they are part of the evidence.

Defender’s view / practical application

The same action log is a detection-validation timeline. Compare each planned action with available process, authentication and network records, and document missing coverage.

Reference: Linux id reference · Linux ip reference · Linux ss reference

Before you start: A Windows lab VM. Use a standard user first; obtain approved elevation only where a command requires it.

Windows PowerShell

# Identity and token context
whoami /all
whoami /groups
whoami /priv

# PowerShell: inventory without changing services or accounts
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption,Version,BuildNumber
Get-CimInstance Win32_Service |
  Select-Object Name,State,StartName,PathName
Get-ScheduledTask |
  Select-Object TaskName,TaskPath,State
Get-LocalGroupMember -SID 'S-1-5-32-544'
# Inspect permissions on an instructor-provided path
Get-Acl 'C:\Lab\training.txt' | Format-List

Try it — worked exercise

Inspect a harmless instructor-created service definition and its executable path. Record the service account, executable and directory permissions. Do not replace the executable or alter the service to prove your observation.

Expected result & troubleshooting

A useful result connects a privileged execution context to an actual writable path or unsafe permission. An unquoted path or a present privilege alone does not prove an exploitable condition. LocalAccounts cmdlets require a supported Windows environment; they are not available in 32-bit PowerShell on a 64-bit system.

Defender’s view / practical application

Restrict local administrator membership, protect service binaries and directories, audit privileged changes and use Windows LAPS where appropriate. Test remediation with the same low-privilege identity, then confirm the service still starts.

Reference: Microsoft local group membership · Microsoft Windows LAPS

Before you start: A Linux lab account and a directory containing only training files.

Terminal

# Identity, release and sudo policy (may prompt for your password)
id
uname -r
cat /etc/os-release
sudo -l
# File and directory ownership; numeric permissions
ls -ld ~/c6-http-lab
ls -l ~/c6-http-lab
stat ~/c6-http-lab/note.txt
# Local service and process inventory
ps -eo user,pid,ppid,comm --sort=user
ss -lntup
systemctl list-timers --all
# Bounded permission search inside the training directory
find ~/c6-http-lab -type f -perm -0002 -print
# Optional system inventory, with permission; results are not findings alone
find /usr/bin -xdev -type f -perm -4000 -print
getcap -r /usr/bin 2>/dev/null

A SUID binary, root-owned process or old-looking version string is not automatically a vulnerability. Connect the observation to an actual unauthorized capability. Avoid downloading and executing an enumeration script merely because a checklist names it.

Try it — worked exercise

Create a synthetic text file in your training directory. Compare chmod 600 note.txt with chmod 644 note.txt, then restore 600. Explain who can read the file under each mode and whether the directory permits traversal.

Expected result & troubleshooting

The owner retains read/write permission in both cases; 644 adds group/other read access. Permission-denied results may be caused by parent-directory permissions or ACLs. Run changes only on the named training file.

Defender’s view / practical application

Review sudo rules, writable execution paths, service accounts and scheduled jobs. Preserve audit records and verify the corrected permissions using the identity that previously had excessive access.

Reference: sudo reference · Linux id reference · Linux ss reference

Before you start: A dedicated lab domain with synthetic users; distinguish domain controllers, member servers and workstations.

Windows PowerShell — lab directory queries

# PowerShell with the ActiveDirectory module / RSAT in the lab
Get-ADDomain
Get-ADDomainController -Filter *
Get-ADUser -Filter * -Properties Enabled,PasswordLastSet |
  Select-Object SamAccountName,Enabled,PasswordLastSet
Get-ADGroupMember -Identity 'Domain Admins' -Recursive
Get-ADComputer -Filter {TrustedForDelegation -eq $true} |
  Select-Object Name,DNSHostName
# Review accounts registered for services
Get-ADUser -LDAPFilter '(servicePrincipalName=*)'   -Properties ServicePrincipalName |
  Select-Object SamAccountName,ServicePrincipalName

Try it — worked exercise

Create a diagram of your lab domain. Choose one synthetic user, trace direct and nested group membership, and explain one permitted action and one denied action. Record the source of each permission.

Expected result & troubleshooting

You should be able to explain the access path rather than merely display a graph. Domain query failures may mean the RSAT module is absent, DNS is wrong, or the account lacks access. Event 4769 fields vary by Windows version and updates.

Defender’s view / practical application

Use separate admin identities, limit delegation, review privileged groups and manage local passwords with Windows LAPS. Changes such as reducing NTLM need compatibility assessment and staged validation.

Reference: Microsoft event 4769 · Microsoft Windows LAPS

Before you start: For real data: identify the index, sourcetype, log source, permissions, time range and extracted fields. Synthetic queries need only a Splunk search interface.

Start with raw evidence, then normalize. Event IDs are meaningful only with their provider/log. The absence of an event can mean auditing was disabled, collection failed or the time range is wrong. Windows 4688 requires process-creation auditing; command-line text needs its separate policy setting.

SPL syntax desk reference

SPL — synthetic dataset; no Windows log ingestion required

| makeresults count=6
| streamstats count as n
| eval _time=now()-(6-n)*60, user="labuser",
    src_ip="192.168.56.10", EventCode=if(n<6,4625,4624)
| stats count(eval(EventCode=4625)) as failures,
    count(eval(EventCode=4624)) as successes by user src_ip

SPL templates — replace index and map fields to your own data

index=YOUR_WINDOWS_INDEX earliest=-24h
| stats count by sourcetype

index=YOUR_WINDOWS_INDEX earliest=-24h EventCode=4625
| table _time host EventCode TargetUserName IpAddress Status SubStatus

index=YOUR_WINDOWS_INDEX earliest=-24h EventCode=4625
| bin _time span=5m
| stats count as failures by _time host TargetUserName IpAddress
| where failures>=5
| sort 0 - failures

index=YOUR_WINDOWS_INDEX earliest=-24h EventCode=4688
| table _time host SubjectUserName NewProcessName ParentProcessName CommandLine

index=YOUR_WINDOWS_INDEX earliest=-24h EventCode=4625
| timechart span=15m count by host limit=10

The templates assume EventCode and XML-style Windows fields are extracted. Some inputs use EventID, Account_Name, or normalized fields instead. Inspect a raw event before adapting the query. The threshold of five failures is a lab demonstration, not a production rule. These queries organize evidence; they do not prove password spraying, lateral movement or privilege escalation.

PowerShell — local Windows log inspection

# Windows PowerShell: inspect local events, with permission to read the log
Get-WinEvent -FilterHashtable @{
  LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-1)
} -MaxEvents 20 | Select-Object TimeCreated,Id,MachineName,Message

Try it — worked exercise

Run the synthetic SPL example, then change one generated outcome and explain the result. For a real-log exercise, generate one approved failed login on a lab account, note the UTC time, and find its event on the relevant host.

Expected result & troubleshooting

The unchanged synthetic query produces one row: five failures and one success. Real log fields and collection are environment-dependent. Empty results require checking collection, permissions and time range before changing the detection.

Defender’s view / practical application

Correlate failures with successful sessions and subsequent behavior. Document false positives, telemetry dependencies, review steps and a clear escalation reason before promoting a query into an alert.

Reference: Splunk synthetic results · Splunk timechart · Microsoft event 4625 · Microsoft event 4688

Before you start: An incident contact list, a reporting channel and authority for containment decisions.

NIST SP 800-61 Rev. 3, published in April 2025, supersedes Rev. 2 and integrates incident response with CSF 2.0. Preparation and improvements extend across risk management; operational response includes Detect, Respond and Recover. The practical checklist below is a training workflow, not a substitute for your organization’s incident plan.

Reference — fill in with case-specific facts

Incident note template
Case ID / analyst / UTC time:
Trigger and evidence source:
Confirmed observations:
Current hypothesis and confidence:
Affected identities, hosts and services:
Containment decision / authority / impact:
Evidence locations and custodians:
Next action / owner / due time:
What would change this assessment?

Keep original evidence and analyze working copies. A hash helps detect change; it does not establish when, where or by whom the evidence was collected. Record those details separately. Avoid automatically rebooting a suspect host or deleting files before considering volatile evidence and containment needs.

Try it — worked exercise

Use the five-failure/one-success training sequence. Draft a triage note with two competing explanations. Add a hypothetical process event after the success and explain how it changes your confidence and next steps.

Expected result & troubleshooting

A good response identifies missing evidence and a justified next action. Do not declare a breach from the authentication sequence alone. Record the difference between detection time and estimated activity time.

Defender’s view / practical application

Response improves when owners, authority and evidence paths are already known. Test handoffs and recovery, not only alert generation.

Reference: NIST SP 800-61 Rev. 3

Before you start: A training account or a locally isolated target; read each platform’s scope and publication rules.

Platform paths, free access and account features change. Check the current platform page before committing time or money. Use an old deliberately vulnerable image only in an isolated environment; it teaches a historical condition, not necessarily a modern deployment.

Try it — worked exercise

Complete one authorized web access-control lab. Write a short explanation without publishing a restricted solution or live challenge flag. Add a regression test that describes the fixed behavior.

Expected result & troubleshooting

Someone else should understand the reasoning without needing your account or secrets. Screenshots alone are insufficient if they omit the method. Redact tokens, personal data and unrelated infrastructure.

Defender’s view / practical application

Use the same lab to practice logging and reporting. A strong portfolio shows judgment and clear communication, not just completed flags.

Reference: PortSwigger Web Security Academy

Before you start: Choose a track based on your existing skills. Use the manual as a companion rather than a requirement to finish every topic in order.

• Breaking Into Cyber — explore the career and learning route.
• Intro to Cyber — connect the core concepts.
• Home Lab Setup — establish a repeatable practice environment.
• Cover6: First Watch — explore the defender learning experience.
• Cover6: First Shell — explore the assessment learning experience.
• Cover6 Academy — check current course availability, prerequisites and access terms.

Treat progression as demonstrated ability: can you reproduce the result, explain the evidence and recover the lab? A completed video is useful exposure, but it does not establish that skill on its own.

Try it — worked exercise

Choose one path and schedule three sessions: learn the concept, perform an exercise, and explain the result from memory. At the end, choose a follow-on topic based on the difficulty you actually encountered.

Expected result & troubleshooting

You should finish with a specific artifact rather than only time watched. If prerequisites are missing, return to the relevant foundation and retry the same exercise.

Defender’s view / practical application

Practicing both the activity and the evidence helps connect offensive testing with defensive outcomes. Keep the same lab notebook across courses so you can compare progress.

Before you start: Identify your target role, existing skills, budget and any employer-specific requirement.

There is no universal “Security+ first, always” rule. Security+ can support a broad security foundation; A+ or networking study may be more useful first when operating-system and network basics are missing. An exam is one way to demonstrate knowledge, not a guarantee of employment.

Budget checklist

• Current regional exam price and taxes; do not reuse old dollar figures from a cheat sheet.
• Number of exams, voucher expiry, retake conditions and ID requirements.
• Training and practice materials you actually need.
• Renewal fees, continuing-education requirements and the relevant renewal cycle.
• Any academic or employer benefit, verified directly with its provider.

ISC2 offer update: new enrollment in the One Million Certified in Cybersecurity program ended May 20, 2026. Existing participants should check their own code/access conditions and the program’s remaining deadlines. CC should no longer be described as a free exam available to every new learner.

Use CompTIA’s official site and the ISC2 CC page to confirm the active exam, regional price and renewal rules before paying. Prices vary by region and offer; use the current provider checkout amount when budgeting.

Study planning reference

Objective → evidence → gap → study action
Example: Explain access control
Evidence: Demonstrate allowed/denied access with two lab users.
Gap: Cannot yet distinguish authentication from authorization.
Study action: Review the concept and repeat the test without notes.
Ready check: Explain why each incorrect practice answer is wrong.

Try it — worked exercise

Choose one exam only after reviewing its current objectives. Mark each objective as explain, demonstrate, or needs study. Build a budget with provider-confirmed amounts and record when you checked them.

Expected result & troubleshooting

A readiness decision should combine understanding, practical evidence and representative practice performance. An arbitrary 85% practice score does not guarantee an official exam pass.

Defender’s view / practical application

Certification study is strongest when tied to real tasks: configuration, investigation, risk explanation and verification. Keep the credential’s limits clear.

Reference: ISC2 CC certification · ISC2 free-program transition

Before you start: A small piece of work you can explain honestly and share within its rules.

Your notes, diagrams, questions and explanations make your skills easier to assess. Build professional relationships through useful participation: ask clear questions, follow up on help, and share lessons you can support. Visibility helps people understand your work, but it does not replace skill or guarantee an offer.

Reference — model your question on the evidence

A useful help request
Goal: I am trying to reach my isolated lab HTTP service.
Expected: HTTP 200 from 192.168.56.20:8000.
Actual: Connection refused from the analyst VM.
Checked: Guest IP, network mode, route and firewall rule.
Evidence: The target has no listener on port 8000.
Question: What should I check in the server startup output?

• Cover6 Community — check current community activities.
• Cover6 Academy — find current courses and learning resources.
• Share only exercises you are permitted to publish; remove credentials, private records and unrelated host details.
• Describe the work as a lab when it was a lab. Do not present a simulated engagement as client experience.

Try it — worked exercise

Turn one exercise from this manual into a one-page writeup and a two-minute explanation. Ask a peer to identify what they can reproduce and what is unclear.

Expected result & troubleshooting

A strong explanation includes what failed and how you corrected it. If a reviewer cannot follow the setup or evidence, improve the documentation before adding more screenshots.

Defender’s view / practical application

Communication is part of security delivery: the next analyst, engineer or owner must be able to act on your work. Clear limitations build trust.