Why Default SIEM Rules Aren’t Enough

(And How Attackers Quietly Slip Through)

If you’ve ever worked in a SOC or even just started exploring SIEM tools like Microsoft Sentinel or Splunk , you’ve probably felt a sense of relief seeing all those ready-made detection rules.

“Nice yaar… everything is already covered.”

There are GitHub repositories, prebuilt analytics, MITRE-mapped detections… it feels like you just need to turn them on and you’re secure.

But here’s the uncomfortable truth:

Attackers already know these rules.

And more importantly…they know how to avoid them.

The Problem with Out-of-the-Box Detection Rules

Let’s understand how most default SIEM rules work.

They’re usually based on:

• Known attack patterns
• Fixed thresholds
• Common indicators (like IPs, hashes, domains)
• Generic behavior (like “5 failed logins in 5 minutes”)

For example:

Alert if failed login attempts > 5 within 5 minutes

Sounds reasonable, right? Now think like an attacker.

Instead of 10 failed attempts in 1 minute, they do:

• 1 attempt every 10 minutes
• Spread across multiple accounts
• From different IPs

Result?

No alert. No noise. No detection.

Welcome to the world of low-and-slow attacks.

Attackers Are Not in a Hurry

This is where many SOC analysts get it wrong.

We expect attackers to be loud:

• Brute force attacks
• Malware explosions
• Obvious lateral movement

But modern attackers, especially APTs are patient.

They:

• Stay under thresholds
• Blend into normal user behavior
• Use legitimate tools (PowerShell, WMI, RDP)
• Move slowly over days or weeks

This is often called:

• “Living Off The Land” (LOTL)
• “Low-and-Slow Attacks”

And honestly, default rules struggle here.

So How Do We Detect What Doesn’t Cross the Threshold?

Now comes the interesting part. If attackers avoid thresholds… we stop relying only on thresholds.

Instead, we shift our thinking.

1. From Threshold-Based → Behavior-Based Detection

**Instead of asking: **“Did 5 failed logins happen?”

Ask: “Is this login behavior normal for this user?”

Examples:

• User logging in at 3 AM (but usually works 9–6)
• Login from a new country/location
• Accessing systems never touched before

This is behavior analytics.

Tools:

• UEBA (User & Entity Behavior Analytics)
• Microsoft Sentinel UEBA
• Splunk UBA

These systems build a baseline and detect deviations, not just counts.

2. Correlation Is King (Single Events Lie)

A single event may look harmless. But multiple small signals together?

That’s your attacker.

Example:

• One failed login → normal
• One successful login → normal
• One PowerShell execution → normal

But combine:

• Failed logins across accounts
• Followed by a successful login
• Followed by unusual PowerShell activity

Now you have a story. This is called event correlation

Instead of:

“Alert on one event”

We do:

“Alert on sequence of suspicious behavior”

3. Time-Based Aggregation (Think Long-Term)

Default rules often look at short windows:

• 5 minutes
• 10 minutes

Attackers stretch across:

• Hours
• Days
• Weeks

So what can we do?

Create rules that track behavior over longer durations

Example:

• “Failed login attempts across 24 hours per user”
• “Number of distinct IPs accessing one account in a day”

This catches slow brute force and credential stuffing attempts.

4. Hunt, Don’t Just Wait for Alerts

This is where you level up from analyst → hunter.

*Instead of relying only on alerts: *Start asking questions in logs

Examples:

• “Which users logged in from multiple geolocations in 24 hours?”
• “Which endpoints ran PowerShell with encoded commands?”
• “Which service accounts suddenly became active?”

This is Threat Hunting.

No alert required. Just curiosity + hypothesis.

5. Focus on Anomalies, Not Just Indicators

Indicators (IOCs) are useful… but limited.

Why? Because:

• IPs change
• Domains rotate
• Malware evolves

But behavior? Harder to fake consistently.

So focus on:

• Rare processes
• Unusual parent-child process relationships
• First-time-seen activity

Example:

“Why is Word spawning PowerShell?”

That’s suspicious, even if no known malware is detected.

6. Build Custom Detection Rules (This Is Where Real SOC Work Begins)

Honestly, this is the biggest takeaway.

• Out-of-the-box rules = baseline
• Custom rules = real defense

You should:

• Tune thresholds based on your environment
• Create rules for business-specific behavior
• Reduce noise and focus on meaningful alerts

Example:

• Admin accounts logging into non-admin machines
• Finance systems accessed outside working hours
• VPN logins followed by sensitive data access

This is where you move from:

“Tool operator” → “Security engineer”

7. Add Context (Because Logs Alone Are Dumb)

Logs don’t know:

• Who is a VIP
• Which server is critical
• What’s normal for your company

You need enrichment:

• Asset criticality
• User roles
• Threat intelligence
• Geo-location data

**With context: **Same alert becomes HIGH or LOW priority intelligently

Real Talk: Why This Matters

If you rely only on default rules:

• You detect noisy attackers
• You miss smart attackers

And the scary part?

Smart attackers are the ones who:

• Stay longer
• Steal more data
• Cause bigger damage

Final Thoughts

Out-of-the-box SIEM rules are not useless far from it.

They’re a starting point.

But thinking they’re enough is like:

Installing CCTV cameras and assuming no theft will happen

• Attackers don’t break the door anymore.
• They walk in like they belong.

So your job is not just to detect noise…It’s to detect what doesn’t look wrong at first glance

And that, honestly, is where cybersecurity becomes both:

• challenging and a little bit fun