Skip to main content
This guide walks you through running your first threat simulation test and validating detection in your security infrastructure.

​
Before you begin

Ensure you have:
  • Installed Somnium and all dependencies
  • Permission to generate malicious traffic in your environment
  • Access to your firewall, IDS, or SIEM logs
  • Noted the IP address of the system running Somnium
Do not run Somnium on production networks without authorization. Only use in controlled test environments.

​
Run your first test

1

Launch Somnium

Start the interactive CLI:
cd Somnium
python3 main.py
You’ll see the main menu with nine test options:
#1 Test connection with known bad IPs.
#2 Test connection with known Phishing URLs.
#3 Test connection to TOR Exits Nodes.
#4 Test connection to live Malware distribution Urls
#5 Test connection to known Cryptomining domains.
#6 Test connection to Domain-Generated-Algorithm Domains.
#7 Test connection to Remote Desktop Management.(Anydesk,etc.)
#8 Test connection using known bad user agents.
#9 Generate DNS queries using DoH
#0 Exit.
Choice:
2

Select test #1 - Known bad IPs

Enter 1 and press Enter to test connections to known malicious IP addresses.Somnium will:
  1. Download threat feeds from Cisco Talos, EmergingThreats, and Mirai
  2. Select 15 random IPs from the combined lists
  3. Test connections on ports 80, 443, and 22
  4. Log all results to IP_Results.txt
Downloading Samples: 100%|████████████████| 3/3
Testing 15 samples from Cisco Talos, EmergingThreats and Mirai: 100%|████████████████| 15/15
Most connections will fail (timeout) because many malicious IPs are offline. This is expected - the goal is to test detection of the connection attempts, not successful connections.
3

Check the log file

Open IP_Results.txt in the Somnium directory:
cat IP_Results.txt
You’ll see timestamped entries for each connection attempt:
Timestamp:14:23:15 IP:185.220.101.67 : Port:80 test FAILED
Timestamp:14:23:20 IP:185.220.101.67 : Port:22 test FAILED
Timestamp:14:23:25 IP:185.220.101.67 : Port:443 test FAILED
Timestamp:14:23:30 IP:91.203.5.165 : Port:80 test FAILED
Timestamp:14:23:35 IP:91.203.5.165 : Port:22 test FAILED
Note the timestamps - you’ll use these to find the activity in your security logs.
4

Validate detection in your security tools

Use the timestamps from IP_Results.txt to search your security device logs.
# Search firewall logs for the test system IP
# Look for blocked/denied connections around the timestamps
grep "185.220.101.67" /var/log/firewall.log
Example of Suricata IDS detecting Somnium test trafficWhat to look for:
  • Firewall deny/block events for the malicious IPs
  • IDS/IPS signature alerts (ET INFO, Talos, etc.)
  • Proxy blocks or reputation-based denies
  • SIEM correlation rules triggering on threat intel matches

​
Understanding the results

​
Log file format

Each test generates a dedicated log file:
Log FileTest Type
IP_Results.txtKnown bad IP connections
URL_Results.txtPhishing URL tests
TOR_Results.txtTOR exit node connections
Malware_Results.txtMalware distribution URLs
Mining_Results.txtCryptomining domains
DGA_Results.txtDGA domain generation
RAT_Results.txtRemote access tool connections
Agent_Results.txtBad user-agent strings
DoH_Results.txtDNS over HTTPS queries

​
Success vs. failure

  • test SUCCESSFUL - Connection was established (rare, indicates IP/domain is still active)
  • test FAILED - Connection timed out or was refused (expected for most tests)
  • test DONE - Test completed (used for ping-based tests)
Even failed connections should be detected and logged by your security infrastructure. If you don’t see any alerts, you may have a visibility gap.

​
Run additional tests

Now try other threat scenarios: 
python3 main.py
# Enter: 2
# Downloads OpenPhish feed and tests 15 random phishing URLs
# Results saved to URL_Results.txt

​
Example workflow: Validate IDS signatures

Here’s a complete workflow for testing your IDS/IPS:
1

Run the known bad IPs test

python3 main.py
# Enter: 1
2

Get the first tested IP and timestamp

head -1 IP_Results.txt
# Example output:
# Timestamp:14:23:15 IP:185.220.101.67 : Port:80 test FAILED
3

Search IDS logs for alerts

# Suricata example
grep "14:23" /var/log/suricata/fast.log | grep "185.220.101.67"

# Expected: ET INFO, Talos, or other reputation-based alerts
4

Verify the signature triggered

If you see alerts like:
[**] [1:2520000:1] ET INFO Known Bad IP (Talos) [**]
Your IDS successfully detected the malicious connection attempt.
5

Document gaps

If no alerts appear:
  • Verify your IDS is monitoring the correct network segment
  • Check that threat intelligence feeds are enabled
  • Confirm signature updates are current
  • Test with other scenarios (phishing, malware URLs)

​
Common testing scenarios

​
Test firewall blocking

Goal: Confirm firewall blocks connections to known bad IPs
  1. Run test #1 (Known bad IPs)
  2. Check firewall deny logs for the destination IPs
  3. Verify the action is “DENY” or “BLOCK”

​
Test proxy URL filtering

Goal: Validate proxy blocks phishing and malware URLs
  1. Run test #2 (Phishing URLs) or #4 (Malware distribution)
  2. Check proxy logs for URL category blocks
  3. Look for categories like “Phishing”, “Malware”, or “Security”

​
Test SIEM threat correlation

Goal: Ensure SIEM creates alerts for threat intel matches
  1. Run any test (e.g., test #5 for cryptomining)
  2. Wait 5-10 minutes for log ingestion
  3. Check SIEM for correlation alerts
  4. Verify incident/ticket was created if configured

​
Test DNS visibility

Goal: Detect encrypted DNS (DoH) that bypasses controls
  1. Run test #9 (DNS over HTTPS)
  2. Check if your firewall/proxy detected the DoH queries
  3. Verify you have visibility into the encrypted DNS requests
Test #9 highlights a visibility gap in many networks. If you don’t detect DoH queries to Google/Cloudflare, you may have attackers tunneling DNS traffic without detection.

​
Troubleshooting

​
No log files generated

# Check write permissions
ls -la

# Verify current directory
pwd

# Run with explicit output
python3 main.py 2>&1 | tee somnium-output.txt

​
All tests show FAILED

This is expected - most malicious infrastructure is offline. The goal is to verify your security tools detect the attempts, not that connections succeed.

​
No alerts in security logs

Possible causes:
  • Security device isn’t monitoring the test system’s network segment
  • Threat intelligence feeds aren’t enabled
  • Logs aren’t being forwarded to SIEM
  • Time synchronization issues between systems
# Verify test system IP is correct
ip addr show

# Check timestamp alignment
date

# Confirm network path to security devices
traceroute <firewall-ip>

​
Next steps

Test scenarios

Detailed guide to all nine threat simulation tests

Integration guide

Integrate Somnium with your security infrastructure

Interpreting results

Parse and analyze Somnium results at scale

Data sources

Learn about threat intelligence feeds used by Somnium

Build docs developers (and LLMs) love

Get started for freeTalk to us