## Analyzing IDS Alerts

As an Analyst, you will stare at IDS alerts all day. You need to quickly decide: **True Positive** (Real Attack) or **False Positive** (Noise).

### The Analysis Workflow

#### Step 1: Read the Rule (The "msg")
*   Alert: `ET EXPLOIT Obfuscated JavaScript Exploit Kit Landing Page`
*   Meaning: An external website tried to run a script to exploit the browser.

#### Step 2: Check the Direction
*   `External -> Internal`: Attack Attempt.
*   `Internal -> External`: Compromise/Beaconing/Exfiltration. (These are usually scarier).

#### Step 3: Check the Payload (The Packet Capture)
Most SIEMs/IDS allow you to view the payload that triggered the alert.
*   **Context**: Did the payload contain readable text?
    *   Alert says "SQL Injection". Payload contains: `user_id=5`. -> **False Positive**. (5 is normal).
    *   Alert says "SQL Injection". Payload contains: `user_id=1 OR 1=1`. -> **True Positive**.

#### Step 4: Check the Response
Did the server respond?
*   **Request**: `GET /../../etc/passwd` (Directory Traversal).
*   **Response**: `404 Not Found`.
*   **Verdict**: Attempted attack, but **Failed**. (Low Priority).
*   **Response**: `200 OK` (Followed by root:x:0:0...).
*   **Verdict**: **Successful Compromise**. (Critical Priority).

### Common False Positives
1.  **Vulnerability Scanners**: If your creative team runs Nessus/Qualys, your IDS will light up like a Christmas tree. (Whitelist the Scanner IP).
2.  **P2P Traffic**: Torrent apps often use strange behavior that looks like scanning.
3.  **Encrypted Traffic**: Sometimes encrypted bytes coincidentally match a text signature. (e.g., a random string inside a JPEG image matches a "Base64" signature).

### The "Default Deny" Mindset
When investigating, assume it is real until proved otherwise. "I think this is a False Positive" is the last words of many fired analysts. Prove it.