Hey folks,
I've been deep in the trenches with LogRhythm for a few years now, specifically around building out custom monitoring for some of the more subtle, high-impact threats. One scenario that always comes up in my client environments is detecting data exfiltration attempts—not just the blatant huge file transfers, but the slow-and-low, blended-into-normal-traffic kind. The out-of-the-box alarms are a great starting point, but to really catch the clever stuff, you often need to roll up your sleeves and build something tailored.
I wanted to share a step-by-step breakdown of a custom alarm I built that focuses on anomalous outbound data transfers. The goal here is to flag potential exfiltration based on a combination of volume, destination, and user context that deviates from established baselines. This isn't a single AIE rule, but a structured approach using several components.
**Core Components of the Custom Alarm:**
* **Data Source:** We're primarily leaning on network metadata (NetFlow or similar from your firewalls/proxies) and Windows security events for logon/logoff (to tie activity to accounts).
* **Key LogRhythm Elements:**
* **AI Engine Rules:** To perform the real-time correlation and anomaly scoring.
* **Lists:** Dynamic lists of "sensitive data servers," known bad/malicious external IPs (threat intel), and a list of "high-risk user" accounts (like domain admins, finance users).
* **Alarm Notification:** Configured to trigger a high-severity alarm and initiate a workflow (like a Slack alert to the SOC and a ticket creation).
**Step-by-Step Implementation Outline:**
1. **Baseline "Normal" Outbound Traffic:** First, I used LogRhythm's reporting over a 30-day period to establish a per-user, per-destination baseline for outbound data volume. This is more art than science, but you're looking for typical MBs per day to known SaaS IP ranges.
2. **Build the Supporting Lists:**
* Create a **"Sensitive Data Servers"** list (IPs/hostnames of file shares, databases, source code repos).
* Maintain a **"High-Risk User Accounts"** list.
* Integrate a Threat Intel feed into a **"Known Malicious/High-Risk External IPs"** list (you can update this via an automated API call).
3. **Craft the AI Engine Rule Logic:**
The rule's logic checks for a conjunction of conditions that, together, are suspicious. Here's the pseudo-logic:
```
IF
(Network Metadata shows Outbound Connection to IP NOT in "Allowed SaaS Ranges" list)
AND
(Data Transfer Volume > 3x User's 30-day Baseline for that destination OR Data Transfer Volume > 500MB absolute)
AND
(Destination External IP is in "Known Malicious IPs" list OR Source Internal IP is in "Sensitive Data Servers" list)
AND
(The User Account associated with the network session is in "High-Risk User Accounts" list)
THEN
Trigger Alarm Severity: High
Generate Alarm with Details: [User], [Source IP], [Destination IP], [Data Volume], [Timestamp]
```
4. **Tune to Reduce Noise:** The initial version will likely be noisy. I added exclusions for trusted backup systems, cloud storage syncs (like OneDrive/Box official IPs), and software update servers. You'll iterate on this for a week or two.
5. **Build the Alarm & Response Workflow:** In the Alarm Builder, configure the notification to include all relevant context. I have it set to auto-assign to our Tier 2 analyst queue and post a formatted alert to our internal SOC channel via a webhook.
**Key Pitfalls & Lessons Learned:**
* **Baseline Drift:** Remember to periodically (quarterly) review and adjust your baselines. Legitimate new cloud tools will appear.
* **Encrypted Traffic:** This method relies on volume/metadata, not content inspection. A large encrypted transfer to an unknown VPS provider is still a strong signal.
* **False Positives from New Services:** The first time marketing uses a new video hosting service, they might transfer 2GB of footage. That's why the "high-risk user" filter is crucial in early tuning.
This approach won't catch everything, but it creates a formidable barrier for attackers trying to sneak data out without drawing attention. It turns multiple weak signals (some volume anomaly, a somewhat suspicious destination) into a high-fidelity alarm.
Has anyone else built something similar? I'm particularly curious about how you've handled encrypted transfer thresholds or integrated external threat intel feeds more dynamically.
api first
api first