Section 22 – Security Tools

Section 21: Security Tools Revision Guide

1. Why “Security Tools” Matter in Security+ (Section 21)

Security Tools are not “gadgets” to name drop; they are how you:

• Discover vulnerabilities before attackers do.
• Validate that vulnerabilities are truly exploitable.
• Detect malicious activity in networks, hosts, applications, and cloud.
• Respond/Remediate efficiently once an issue is identified.
• Demonstrate compliance with regulatory baselines (e.g., PCI-DSS, HIPAA).

Exam Focus: Every tool you learn must map back to a specific Security+ objective (e.g., “Analyze vulnerability scan results,” or “Apply digital forensics concepts”). If you can’t explain why you’d use it in a given scenario, it won’t help on exam day.

2. Tool Categories & Key Examples

Below are the main categories of tools you must master for Section 21. For each, note its core purpose and 1–2 flagship names.

2.1 Vulnerability Assessment & Management

• Purpose: Identify, catalog, and prioritize weaknesses (patch gaps, misconfigurations, known CVEs).
• Examples:
  • Nessus (Tenable) – Agentless, highly customizable policies, CVSS reporting.
  • OpenVAS (Greenbone) – Open-source equivalent to Nessus; integrates with compliance feeds.
  • QualysGuard – Cloud-based, continuous scanning, automated reporting.
• Security+ Objective (1.1): “Given a scenario, analyze results from vulnerability assessment tools.”

2.2 Network Scanning & Enumeration

• Purpose: Discover active hosts, open ports, services; fingerprint OS/software versions.
• Examples:
  • Nmap – SYN scan (-sS), version detection (-sV), OS fingerprinting (-O), NSE scripts (e.g., ssl-enum-ciphers).
  • Netcat (nc) – Banner grabbing, raw TCP/UDP connections, basic port scanning.
  • Angry IP Scanner – Quick GUI/CLI sweep of IP ranges and ports.
• Security+ Objective (2.5): “Given a scenario, use appropriate tools to verify network security.”

2.3 Password Cracking & Authentication Testing

• Purpose: Test password strength (dictionary/brute-force) and verify password-based authentication resilience.
• Examples:
  • John the Ripper – Offline password hash cracking; supports many formats (LM, NTLM, MD5, etc.).
  • Hashcat – GPU-accelerated cracking, rule-based attacks, straight/dictionary/brute-force modes.
  • Hydra – Parallelized online login cracker (SSH, FTP, HTTP auth, RDP, SMB, etc.).
• Security+ Objective (1.2): “Given a scenario, analyze potential indicators to determine the type of attack.”

2.4 Wireless Assessment

• Purpose: Discover Wi-Fi networks, capture handshakes, crack WEP/WPA/WPA2-PSK keys, detect rogue APs.
• Examples:
  • Aircrack-ng Suite:
    • airodump-ng (capture packets/handshake)
    • aireplay-ng (inject/deauth to force re-handshake)
    • aircrack-ng (crack WPA/WPA2 handshake)
  • Kismet – Passive sniffer; identifies hidden SSIDs, rogue access points.
• Security+ Objective (2.5): “Given a scenario, use appropriate wireless assessment tools.”

2.5 Configuration & Compliance Assessment

• Purpose: Verify servers/desktops match baseline hardening (CIS, DISA STIGs, vendor guidelines).
• Examples:
  • Lynis – Open-source auditor for Linux/macOS; checks CIS benchmarks, kernel parameters, installed packages.
  • OpenSCAP – SCAP-compliant tool to run DISA/NIST profiles, generate compliance reports.
  • MBSA – (EOL) Microsoft Baseline Security Analyzer; historical Windows patch, weak password scanner.
• Security+ Objectives:
  • (3.1) “Given a scenario, implement configuration changes to harden systems.”
  • (5.2) “Given a scenario, implement controls to meet compliance requirements.”

2.6 Intrusion Detection & Prevention (IDS/IPS)

• Purpose: Monitor live traffic or host events for malicious signatures/behavior; optionally block in real-time.
• Examples:
  • Snort – Signature-based network IDS/IPS; community/commercial rule sets.
  • Suricata – Multi-threaded IDS/IPS with protocol detection and file extraction capabilities.
  • OSSEC/Wazuh – Host-based IDS: log analysis, file-integrity monitoring (FIM), rootkit detection, compliance.
• Security+ Objective (4.1): “Given a scenario, analyze output from intrusion detection tools.”

2.7 Security Information & Event Management (SIEM)

• Purpose: Centralize logs from multiple sources (hosts, firewalls, IDS/IPS, AD, cloud), correlate events, generate alerts, support incident investigations.
• Examples:
  • Splunk Enterprise Security – Commercial SIEM with powerful search, dashboards, correlation.
  • ELK Stack – Elasticsearch + Logstash + Kibana; open-source alternative for log aggregation/search/visualization.
  • QRadar (IBM) – SIEM with built-in analytics, risk scoring, preconfigured threat intel.
• Security+ Objectives:
  • (4.2) “Explain the importance of SIEM and security monitoring tools.”
  • (4.3) “Given a scenario, analyze SIEM output.”

2.8 Penetration Testing & Exploitation

• Purpose: Validate that identified vulnerabilities can actually be exploited; simulate real-world attack scenarios.
• Examples:
  • Metasploit Framework – Modular exploit framework with payload generation, scanners, post-exploitation modules.
  • SQLmap – Automated SQL injection detection/exploitation and data exfiltration.
  • BeEF – Browser Exploitation Framework for client-side exploits (JavaScript hooking).
• Security+ Objectives:
  • (3.2) “Explain the importance of penetration testing concepts.”
  • (3.4) “Given a scenario, use appropriate tools to exploit identified vulnerabilities.”

2.9 Forensics & Incident Response

• Purpose: Collect and analyze evidence (disk, memory, logs) to determine cause, scope, and timeline of a breach or incident.
• Examples:
  • FTK Imager – Create forensically sound disk images, preview contents without altering source.
  • Autopsy & Sleuth Kit – Open-source tools for file system analysis, timeline creation, keyword searches on disk images.
  • Volatility – Memory forensics framework to extract running processes, loaded modules, network connections from a RAM dump.
• Security+ Objectives:
  • (4.4) “Given a scenario, apply basic digital forensics concepts.”
  • (4.5) “Given a scenario, conduct post-mortem forensics.”

3. How to Use Each Tool Category on Exam Day

3.1 Map Tool → Security+ Domain → Exam Objective

For every tool category, memorize this triad:

1. Category: (e.g., “Vulnerability Scanners”)
2. Domain: (e.g., “Threats, Attacks & Vulnerabilities – Domain 1”)
3. Objective Number/Text: (e.g., “1.1: Analyze results from vulnerability assessment tools.”)

If a question states “You need to identify missing patches on a Windows network,” you should immediately think “Domain 1 (1.1) → run Nessus or QualysGuard (vulnerability scanner).” Do not waffle.

3.2 Understand Passive vs. Active Techniques

• Passive (Nonintrusive):
  • Example: Wireshark – listens to traffic without injecting packets.
  • Exam Cue: “No impact to production.”
• Active (Intrusive):
  • Example: Nmap – sends crafted packets (SYN, UDP) to enumerate hosts/ports.
  • Exam Cue: “Confirm open ports by sending packets.”

Key Point: Active scans can trigger alarms and potentially disrupt services. Always pair with “authorized timeframe” or “maintenance window” in your answer.

3.3 Authenticated vs. Unauthenticated Scans

• Unauthenticated (Black-Box):
  • Example: Nmap without credentials—scans from outside.
  • Exam Cue: “External pen-test.”
• Authenticated (Gray-Box):
  • Example: Nessus with SSH/SMB credentials to log in and inspect patch levels.
  • Exam Cue: “Deep dive into configuration, file integrity, patch levels.”

Key Point: Authenticated scans find configuration issues that unauthenticated scans miss.

4. Command-Line “Cliff Notes”

Memorize these minimal commands and their intent. You don’t have to know every flag—just the ones most likely on the exam.

• Nmap:
  • nmap -sS target – SYN (stealth) scan of common ports.
  • nmap -sV target – Service/version detection.
  • nmap -O target – OS fingerprinting.
  • nmap -p 443 --script ssl-enum-ciphers target – Enumerate TLS/SSL ciphers.
• tcpdump / Wireshark:
  • tcpdump -i eth0 port 80 – Capture traffic on port 80.
  • In Wireshark, apply “http” or “dns” filter in Display Filter bar to narrow traffic.
• Aircrack-ng Suite:
  • airodump-ng wlan0mon – Capture Wi-Fi packets/handshakes.
  • aireplay-ng -0 3 -a <AP_MAC> wlan0mon – Deauthenticate clients 3 times from AP (forces handshake).
  • aircrack-ng -w wordlist.txt handshake.cap – Crack captured WPA/WPA2 handshake.
• John the Ripper:
  • john --wordlist=rockyou.txt hashes.txt – Dictionary attack on hash file.
• Hashcat:
  • hashcat -m 1000 hashes.txt wordlist.txt – Crack NTLM (mode 1000) hashes.
• Hydra:
  • hydra -l admin -P passwords.txt ssh://target – Brute-force SSH using username “admin” and wordlist.
• Lynis:
  • lynis audit system – Run full system audit on Linux/macOS, output compliance/configuration findings.
• OpenSCAP:
  • oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_pci-dss /path/to/ssg-rhel7-ds.xml – Evaluate RHEL7 against PCI-DSS profile.
• Snort / Suricata:
  • Typically deployed as a service/daemon. Rulesets come from community or paid sources; must be kept current.

5. Common Pitfalls & How to Avoid Them

• “I’ll just run Nessus and call it a day.”

  Reality: Nessus finds missing patches and CVEs—but doesn’t prove exploitability. Always confirm with a pen-testing tool (Metasploit or manual proof).

  Avoidance: After Nessus flags CVE-2021-XXXXX, try a Metasploit module or at least a proof-of-concept exploit in a lab.

• Overlooking Validation of Findings

  Reality: Scanners produce false positives.

  Avoidance: Manually verify one or two high-severity vulnerabilities (e.g., attempt to log in via anonymous FTP if reported, or test an SQL injection string manually in a browser).

• Running Intrusive Scans Without Authorization

  Reality: Aggressive UDP scans or exploit attempts can crash production.

  Avoidance: Always run nmap -sS first, obtain authorization, schedule scans in maintenance windows, and whitelist scanner IPs in IDS.

• Neglecting Post-Exploit Cleanup

  Reality: If you use Metasploit to test an exploit, artifacts (payloads, backdoors, user accounts) often remain.

  Avoidance: After pen testing, restore VM snapshots or manually eliminate any created accounts/payloads.

• Failing to Keep Signature Feeds Current

  Reality: Old Snort rules, outdated Nessus plugins, or stale AV definitions miss new threats.

  Avoidance: Schedule daily/weekly updates of your IDS/IPS ruleset, scanner plugins, and AV databases.

• Forgetting “Least Privilege”

  Reality: Scanning from an administrator account can mask real permission issues or introduce risk.

  Avoidance: Use a dedicated, minimally privileged service account for authenticated scans. Only escalate to an admin account if absolutely necessary—and document why.

6. Sample Security+ Scenarios & “What to Run”

Below are four typical Security+-style scenarios. Practice mapping each back to an exam objective and the correct tool.

6.1 Scenario A: “Your manager wants a list of missing Windows patches across all domain servers.”

• Domain/Objectives: 1.1 (Threats & Vulnerabilities)
• Recommended Tool:
  1. Nessus (authenticated scan, supply domain credentials) – generates missing-patch report.
  2. Alternatively, use QualysGuard for a cloud-based summary.
• Key Point: Since it’s a domain environment, use an authenticated scan (not Nmap alone).

6.2 Scenario B: “You suspect a brute-force SSH attack on your DMZ Linux web server.”

• Domain/Objectives: 1.2 (Threats & Vulnerabilities)
• Recommended Tool:
  1. OSSEC/Wazuh (host-based IDS) – review failed login alerts in /var/log/auth.log.
  2. Zeek (network-based) on a mirror port – correlate with repeated TCP SYN flows to port 22.
• Key Point: Combine host and network-based sensors; don’t rely on logs alone.

6.3 Scenario C: “Your compliance team says your RHEL servers must meet PCI-DSS baseline.”

• Domain/Objectives: 3.1 & 5.2 (Implementation & GRC)
• Recommended Tool:
  1. OpenSCAP (SCAP scan against PCI-DSS XCCDF profile).
  2. Run oscap score and review “fail” items—apply remediation (package updates, config changes).
• Key Point: Run the scan in a staging environment first—avoid applying major changes directly to production.

6.4 Scenario D: “An IDS alert shows unusual outbound SMB traffic from Server 12. You need to investigate what processes were running in memory at the time.”

• Domain/Objectives: 4.4 & 4.5 (Operations & Incident Response)
• Recommended Tool:
  1. Use FTK Imager or Autopsy to image the disk and examine file creation/modification timestamps for suspicious executables or scripts.
  2. Use Volatility on a RAM dump (collected via Live Response) to list running processes (pslist), network sockets (netscan) and loaded modules.
• Key Point: Collect memory first (volatile) before shutting down; then capture disk for “cold” forensics.

7. Final Exam Tips for Section 21

1. Always tie a tool back to an Objective Number (e.g., “Which tool do I choose to analyze IDS output?” → Snort/Suricata → Objective 4.1).
2. Memorize the one- or two-command “cliff notes” (e.g., nmap -sV, hashcat -m 1000). You won’t be asked to type a long command—just identify correct flags.
3. Beware “all of the above” in multiple-choice when they list both a vulnerability scanner and a pen-testing framework for a patch-identification question. The answer is “Nessus” (not Metasploit).
4. Practice distinguishing “Passive vs. Active”—you’ll see questions like “Which approach is least likely to alert an IDS?” → Wireshark (passive).
5. Keep your terminology clear:
   • “Vulnerability Assessment” = scanning for missing patches, misconfigs, CVEs.
   • “Penetration Testing” = attempting actual exploits/payloads.
   • “Intrusion Detection” = watching traffic or logs for signatures.
   • “Digital Forensics” = imaging disks/memory, reconstructing timelines.
6. When in doubt, think “Principle of Least Privilege”—if a scenario involves scanning or testing, never run tools as a domain admin or root unless explicitly required.

8. In Summary

• Category → Purpose → Example → Security+ Objective is your mental template.
• Practice the sample scenarios until “naming the tool” becomes second nature.
• Validate scan results manually—Scanners lie (false positives).
• Document every test and follow proper authorization processes.