NetEye Conference 2025: The Correct Analysis for Some Use Cases
During the NetEye Conference 2025, I discussed several analysis use cases where integrating threat intelligence information can help build a useful framework for further alert analysis. Below, I’ll share a possible analysis approach for each use case.
Case 1 – Alert about scan attempts from an AWS IP
SOC Analyst’s decision:
“Ouch, this IP is doing some nasty things! Let’s check AbuseIPDB!”
In the use case presented, the analyst (or several analysts from the same SOC) performs a check against the AbuseIPDB for the IP address that generated the alert. This action is repeated multiple times for the same IP address, thus making triage inefficient. Furthermore, is it correct to immediately treat the IP as malicious after a single blacklist match?
Correct analysis:
A SOC analyst should recognize that IPs from cloud service providers (like AWS, Azure, or Google Cloud) are often shared or dynamic. Scanning activity from such IPs might come from:
- Legitimate vulnerability scanners, pen tests, or researchers.
- Temporarily compromised virtual machines.
- Internal services using cloud infrastructure.
Before escalating, the analyst should correlate the IP with:
- Known cloud provider ranges (AWS public IP ranges).
- Threat actor infrastructure databases (e.g., C2s, malware campaigns).
- Internal asset and vulnerability management systems to see if the target system was already under test or exposure.
Valuable Threat Intelligence Data:
- IP reputation intelligence enriched with attribution (who owns it, type of service, known campaigns).
- Cloud provider metadata feeds (AWS IP ranges, DigitalOcean, etc.).
- Historical context (has the same IP appeared in known attacks or only in generic scans?).
- Correlation with known malware/C2 infrastructure from TI platforms (VirusTotal, MISP, ThreatFox, etc.).
Conclusion:
Instead of treating the AWS IP as inherently malicious, the analyst would have identified it as likely benign background noise or generic internet scanning, avoiding unnecessary escalation.
Case 2 – “Massive new data breach“
SOC Analyst’s decision:
“Notify all customers; they should reset their credentials immediately!”
Correct analysis:
Not all “breaches” are relevant. A competent analyst should verify whether the leaked data actually belongs to the organization or its customers.
Steps:
- Check what domain(s) the credentials belong to.
- Verify timestamp and source of the data (is it a new leak or recycled dump?).
- Cross-check email domains and hash formats with internal credential sets.
- If relevant, determine which accounts are impacted and take targeted actions.
Valuable Threat Intelligence Data:
- Data breach intelligence feeds (e.g., Have I Been Pwned, SATAYO, or internal dark web monitoring).
- Attribution metadata (time of breach, original source, associated threat actor, data type).
- Historical exposure correlation (same dataset republished?).
- Automated matching tools that map leaks to internal employee/customer email domains.
Conclusion:
Instead of causing unnecessary panic by notifying all customers, the analyst would have used breach intelligence to confirm whether any corporate or customer accounts were affected, limiting the response to verified cases.
Case 3 – “Critical zero-day on vendor X firewall“
SOC Analyst’s decision:
“Let’s down the internet connectivity of customer Y!”
Correct analysis:
A better approach requires assessing relevance, exposure, and exploitability before any drastic operational action.
Steps:
- Check whether vendor X’s product and version are actually in use at customer Y.
- Determine if public exploit code or exploitation in the wild exists.
- Evaluate whether mitigations or temporary workarounds are available from the vendor or CERTs.
- Prioritize patching and isolation based on threat intelligence severity and prevalence data.
Valuable Threat Intelligence Data:
- Vulnerability intelligence (e.g., CVE, CISA KEV catalog, EPSS score, vendor advisories).
- Exploit intelligence (is the exploit weaponized? linked to known campaigns?).
- Asset exposure data (inventory correlation to know which systems are vulnerable).
- Tactical/operational intelligence about active threat actors exploiting the vulnerability.
Conclusion:
Instead of disrupting business continuity, the analyst would have evaluated the true risk (vulnerable assets, exploit availability, mitigations) and recommended controlled actions such as patching or segmentation.
Case 4 – Alert on newly registered typosquatting domain
SOC Analyst’s decision:
“Block all traffic to/from that domain.”
Correct analysis:
While newly created, suspicious domains often deserve attention, they’re not all malicious. Some may be legitimate brand lookalikes or unrelated benign domains.
Steps:
- Verify the domain registration data (whois, registrar, creation date).
- Check DNS, SSL certificate, and hosting information — is it parked, inactive, or resolving to known malicious IPs?
- Search for the domain in threat intel feeds (passive DNS, malware sandboxes, C2 trackers).
- Assess brand impersonation or phishing campaigns linked to that domain.
Valuable Threat Intelligence Data:
- Domain intelligence (whois, passive DNS, SSL cert transparency logs).
- Phishing/typosquatting feeds (OpenPhish, PhishTank, URLhaus, etc.).
- Brand protection intelligence (alerts on lookalike registrations).
- Historical context (similar domains used by threat actors?).
Conclusion:
Instead of blocking blindly, the analyst would have validated whether the domain was actually malicious or merely suspicious, avoiding potential disruption to legitimate services.
Massimo Giaimo
Author
