Identifying a compromised host in your environment is a common task for administrators in most network environments.   What about other local hosts currently communicating with a compromised IP addresses, that you are not yet aware of? It’s not just a question of detecting the communication but of how long it has been going on before you detect it.


A government agency sends you an email, informing you that your network has been communicating with a compromised host IP address and provides you with the IP address (e.g.  x.x.43.22).   How would you begin to mitigate that?  What other IPs have been compromised internally?    So many questions come to mind, but where to begin? If you have an Incident Response System in place you can begin to investigate communications with the outside IP on your network.

Step 1)

As a network security administrator tasked with the problem, we can search for that external IP address by using a report wizard to look at communications over all devices with that IP as a source during business hours.

Identifying Compromised Host
Identifying Compromised IP

Step 2)

Once we have confirmed this IP address has been communicating on the network, we can now see who internally has been in communication with.  We will click on the IP and apply a filter to view that IP as a Host Destination.  From the figure below, you’ll see that there is an employee who has been communicating with that host.

Compromised Host on our Network
Compromised Host on our Network

 Step 3)

Now that we have identified the compromised host, we can look to see what other computers this employee was communicating with within our internal network.

Internal Conversations with the Compromised Host
Internal Conversations with the Compromised Host

By applying the IP of the employee in question as a source or destination, we can see there are four internal IPs on our network that have been communicating with the compromised host during the same time period.

Armed with our own visibility of what activity is going on as a result of communication between our whole network and the compromised external IP address, we can now proceed to take counter measures.  Your network security policy may vary, but a prudent first step may be to take the PCs in question offline – i.e. don’t shut them down, but remove them from your own operational activity.  Perhaps you let the infection continue to attempt to identify its activities (isolated observance – like building the sandbox around the infection without interrupting it).

Regardless of how you choose to proceed to deal with the infection, you are able to inform the government agency that you have identified who may be infected by using your incident response system.


If you are interested in a technical overview of our Incident Response System to see how it would benefit in your environment, call one of representatives today to get one scheduled!

Austin Brooks

Austin is a QA Engineer in the R&D department at Plixer. He works on new report types and aids the front end team with changes to the user interface of Scrutinizer. He has worked in Tech Support as well as a Solutions Engineer for the sales team at Plixer before his move to Development. Austin graduated from UNH’s WSBE with a degree in International Business and speaks a bit of German. Outside of work, Austin spends his time honing his coding skills and does website design for friends and family. He enjoys skiing, hockey, playing and writing music as well as traveling to different countries.