Threat Simulation – Threat Intel

Intro

This article is number 6 of 8 in a series on testing Threat Hunting software to make sure that it’s configured correctly and working successfully. If you’ve not already read the “Threat Simulation Overview and Setup” article, start there and return here to test whether your Threat hunting platform can detect connections that are left open for hours.

 

What Traffic Are We Trying to Find?

Identifying a threat can be as simple as identifying internal systems that are communicating with a blacklisted IP address. In this example, we’ll do just that and confirm that the conversations are reported.

 

What Tools Are Needed

We can use any of the clients and servers we’ve used in previous checks – curl/wget and apache, ssh client and server, or dig and bind. If you have any of these set up from previous checks we can reuse them as is. The steps needed on the Internal and External systems are identical to the ones we’ve used before.

 

What to Set up on the Threat Hunting Platform

Since our External system should not be listed on any of the default blacklists, we’ll need to place its IP addresses in a manually created blacklist to test this feature. The steps needed will be different for each platform.

For AI-Hunter, see this article. You’ll want to place both IP addresses for the External system in

/etc/AI-Hunter/blacklist/ips.txt .

Leave your client and server running for a few hours.

 

What You Should See on the Threat Hunting Platform

You should start to see the External system showing up in the Threat Intel section of your Threat Hunting platform within a few hours.

How to Troubleshoot It If You Don’t

Confirm that the IP address you’re using as the External server matches the IP address you blacklisted on your Threat Hunting platform.

With tcpdump

If you are not seeing the External system reported as being on a Threat Intel list, check that the conversation is successfully being started on the Internal server (substitute the name of the Internal system’s ethernet port for eth0):

sudo tcpdump -i eth0 -qtnp '(host Ext4 or host Ext6)'

and if it is, run the same command on the External server (substitute the name of the External system’s ethernet port for eth0):

sudo tcpdump -i eth0 -qtnp '(host Ext4 or host Ext6) and not tcp port 22'

Within 10 minutes you should see at least one IPv4 or one IPv6 conversation on that port between the two pairs of IP addresses for those systems. If you don’t, see if there’s a firewall that’s blocking this traffic.

If you have command-line access to the Threat hunting system, run the same command there, changing “eth0” to the name of the interface that’s capturing traffic:

sudo tcpdump -i eth0 -qtnp ‘(host Ext4 or host Ext6)‘

If the traffic shows up on the Internal and External systems, but not when you run the sniffer command on the Threat hunting system, recheck that the Threat Hunting system is plugged into a span/mirror/copy port on a switch that sees the traffic from Internal to External.

 

Links to All Posts in “Threat Simulation” Series

1. Unexpected Protocol on Non-Standard Port
2. Long Connections
3. Client Signatures (User Agent)
4. DNS
5. Beacons
6. Threat Intel
7. Certificate Issues
8. Client Signatures (TLS Signature)