Whoami
  • Welcome
  • Home Lab: C2 Detection, Ransomware Defense & YARA Automation
    • SOC Lab – What is this Lab about ?
    • Part 1 - Setting Up the Environment
    • Part 2 - Detecting C2 Activity
    • Part 3 - Credential Dumping & Threat Detection
    • Part 4 - Blocking Ransomware
    • Part 5 - Reducing False Positives
    • Part 6 - Automated YARA Scanning
  • Automation Lab - Home Project
    • Sysmon Installation
    • Wazuh & TheHive: Installation, Configuration, and Optimization
    • Tracking Mimikatz Activity with Wazuh & Sysmon Logs
    • End-to-End Alert Automation: Wazuh → Shuffle → TheHive
  • Active Directory Attack Lab: Recon-to-Root
    • Reconnaissance Phase
      • 1. Full TCP Port Scan on Target Host
      • 2. Service and Version Detection
      • 3. Null Session SMB Enumeration
      • 4. LDAP Anonymous Bind Check
      • 5. Kerberos Username Enumeration
      • 6. Password Brute Force via SMB Login
    • Exploitation Phase
      • 7. Dump Domain Information via LDAP
      • 8. Perform Remote AD Recon with BloodHound
      • 9. Set Up Neo4j and Launch BloodHound GUI
      • 10. Abuse ForceChangePassword Right via RPC
      • 11. Validate New Credentials via WinRM
      • 12. Enumerate Local Privileges and AutoLogon
      • 13. Reuse Administrator Credentials
      • 14. Capture the User Flag
  • QRadar101 Lab Challenge
    • Scenario and Instructions
    • The Walkthrough
Powered by GitBook
On this page
  • False Positive Tuning in SOC Analysis
  • 1. Understanding False Positives in SOC Analysis
  • 2. Example of a Poorly Written Detection Rule
  • But first, What is svchost.exe?
  • Trying to test the False Positive Detection: svchost Rule Test
  • 4. Refining the False Positive Rule
  • 5. Deploying the False Positive Rule
  1. Home Lab: C2 Detection, Ransomware Defense & YARA Automation

Part 5 - Reducing False Positives

This section is an additional part that explains the false positive detection of the svchost rule test. It helps refine the rule to reduce unnecessary alerts.

False Positive Tuning in SOC Analysis

1. Understanding False Positives in SOC Analysis

  • False positives are a major challenge for SOC analysts.

  • Detection rules might not always be fine-tuned for a specific environment.

  • Some alerts may be generated even when there is no real threat.


2. Example of a Poorly Written Detection Rule

  • The example rule detects any svchost.exe execution, which is too broad.

  • svchost.exe is a legitimate system process that runs frequently on Windows.

  • This leads to many false positives, flooding the SOC console.

But first, What is svchost.exe?

svchost.exe (Service Host) is a Windows system process that runs multiple services to optimize performance.

Why is it Important?

  • Legit Path: ✅ C:\Windows\System32\svchost.exe

  • Suspicious Path: ❌ C:\Users\Public\svchost.exe, C:\Temp\svchost.exe

  • Malware Trick: Hackers rename malware as svchost.exe and place it outside System32.

How to Detect Suspicious svchost.exe?

  1. Check Path → Must be in C:\Windows\System32.

  2. Analyze Command-Line → -k is normal; strange args are suspicious.

  3. Monitor Network → Unexpected external connections = 🚨.

  4. Watch Behavior → If svchost.exe launches PowerShell, investigate.

Rule:

  1. Detect:

event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: \svchost.exe 

This is a detection rule configuration that triggers an alert when a new process is created, and its file path ends with \svchost.exe. Here's a breakdown of each line:

  1. event: NEW_PROCESS → This rule applies to new process creation events.

  2. op: ends with → The condition checks if the process file path ends with a specific value.

  3. path: event/FILE_PATH → The rule evaluates the file path of the newly created process.

  4. value: \svchost.exe → The detection triggers when the file path ends with \svchost.exe.

2. Response :

  - action: report
  name: Suspicious svchost execution
  • What It Does? Flags new processes ending with svchost.exe to detect suspicious activity.

  • Action? Generates an alert for SOC analysts to review.

here is the detection


3. Now let's improve the Detection Rule: Click on Mark False Positive

  • Instead of detecting all svchost.exe executions, refine the rule by:

    • Checking for unusual file paths (e.g., C:\Windows\Temp\svchost.exe).

    • Inspecting command-line arguments used during execution.

Improved Rule:

op: and
rules:
  - op: is
    path: cat
    value: Suspicious scvhost execution
  - op: is
    path: detect/event/FILE_PATH
    value: C:\Windows\System32\svchost.exe
  - op: contains
    path: detect/event/COMMAND_LINE
    value: -k
  • The -k argument is expected for normal svchost.exe executions.

  • This helps reduce false positives.

Trying to test the False Positive Detection: svchost Rule Test

  • Select a false positive detection event from the SOC console.

  • Copy the raw event data and test it against the new FP rule.

  • If the rule matches, it means the detection will be suppressed.

  • The rule triggered successfully, but the detection is too broad.

  • It matched any svchost.exe execution with the -k parameter.

✅ Matched Conditions:

  1. cat = Suspicious svchost execution → Rule triggered

  2. FILE_PATH = C:\Windows\System32\svchost.exe → Common system file

  3. COMMAND_LINE contains "-k" → Common Windows service argument


4. Refining the False Positive Rule

  • Avoid using process hash in the False Positive rule because:

    • The hash could be change with system updates.

    • Relying on it can lead to missing future legitimate detections.

  • Avoid using hostnames in the False Positive rule because:

    • We want the rule to apply to all systems, not just one specific host.


5. Deploying the False Positive Rule

  • Once validated, save the FP rule.

  • It will now automatically suppress normal svchost.exe executions.

  • This reduces noise and allows analysts to focus on real threats.

PreviousPart 4 - Blocking RansomwareNextPart 6 - Automated YARA Scanning

Last updated 3 months ago