Skip to content
Notifications
Clear all

Walkthrough: Simulating an attack to see if Anomali's rules actually catch it.

2 Posts
2 Users
0 Reactions
32 Views
(@cost_cutter_ray)
Honorable Member
Joined: 4 months ago
Posts: 492
Topic starter   [#18064]

Having recently completed a significant platform evaluation for my organization, I found the marketing claims of many threat detection platforms to be, frankly, aspirational rather than operational. A core tenet of our FinOps practice is validation; we don't trust a cloud bill without detailed allocation, and we shouldn't trust a security tool without testing its efficacy. To that end, I conducted a hands-on walkthrough to see if Anomali ThreatStream would detect a simulated, multi-stage attack pattern. The goal was not a full penetration test, but a controlled validation of whether its correlation rules and threat intelligence feeds would generate meaningful alerts from noisy, but malicious, event data.

I constructed a sequence simulating a credential access and exfiltration pattern, leveraging common tools and techniques unlikely to be blocked outright by preventative controls. The simulation steps were:

1. **Initial Reconnaissance:** Execution of `whoami /all` and `net user` commands via a simulated command shell on a Windows endpoint (data source: forwarded Windows Event Logs 4688).
2. **Lateral Movement Attempt:** Use of `PsExec`-like functionality to attempt remote service creation on a internal server, using harvested credentials.
3. **Data Staging:** Use of `7z` (a legitimate binary) to archive documents from a network share to a temporary directory.
4. **Exfiltration:** A simulated HTTP POST request from the internal host to an external IP (known-bad from a threat intel feed) containing the archived data.

The critical configuration in Anomali involved two primary components: the ingestion of our normalized log data (via a syslog connector) and the application of observable-based and rule-based detection.

* I first ensured the known-bad external IP was present in a ThreatStream feed we had subscribed to. This was confirmed via the ThreatStream UI.
* The platform's correlation rule engine required tuning. The default "Credential Dumping via Process" rule fired too generically. I created a more specific custom rule focusing on the sequence of `whoami /all` immediately followed by `net user` and a subsequent outbound connection attempt within a 5-minute window.

The results were illuminating. Anomali did successfully generate an alert, but the path to a usable signal was non-trivial.

* The alert for the connection to the known-bad IP was near-instantaneous and high-fidelity, directly linked to the threat intelligence feed. This worked as advertised.
* The custom correlation rule for the credential reconnaissance sequence fired, but it was buried within 12 other lower-fidelity alerts from the same host over the same period (e.g., "Rare Process Execution" for `7z.exe`, which is common in our environment for developers).
* The lateral movement attempt via `PsExec` was only contextualized *after* the fact, when viewing the timeline of the alerted host. It was not the primary cause of an alert itself.

```yaml
# Example of the custom rule logic used (YAML representation)
rule: "Credential Recon & External Comms"
description: "Detects local credential enumeration followed by external IP connection."
condition: >
(event_id:4688 AND process_command:"whoami /all") AND
(event_id:4688 AND process_command:"net user") AND
(event_id:5156 AND dest_ip:THREAT_INTEL_FEED)
within: 300 seconds
priority: HIGH
```

**Conclusion:** Anomali's detection capabilities are potent but require significant operational investment. The out-of-the-box threat intel matching is its strongest suit. However, to catch multi-stage attacks without an obvious IoC, you must build and tune custom correlation rules, which demands deep knowledge of both your own environment's baseline and the attack chain you wish to detect. The platform did technically "catch" the simulated attack, but primarily via the IoC match; the behavioral detection required custom engineering. The value is there, but the total cost of ownership must factor in the substantial analyst hours needed for rule development and alert triage, not just the licensing fees.

- cost_cutter_ray


Every dollar counts.


   
Quote
(@calebh)
Reputable Member
Joined: 2 months ago
Posts: 421
 

Totally with you on the validation mindset. We applied the same principle during our last renewal cycle, but we focused on the false positive rate as well as detection. We found that while some rules fired, the alert was so generic and buried in noise that the SOC just tuned it out. Did you measure that aspect at all, or was your focus purely on whether the alert triggered?


Trust the data, not the demo.


   
ReplyQuote