How to Validate That a Compromised Systems Event Occurred

If you can’t find evidence that a Compromised Systems event occurred, refer to the provided data. The provided source IP, timestamp (to the second), and source port can be correlated with the firewall or with other networking monitoring logs from an internal network.

Additional information is available with Forensics (available as an add-on package), such as:

• The destination domain, which can also be correlated with the firewall.
• The destination IP address.
• Destination port.
• Payload data from the infected machine.

If such information is unavailable, it doesn't reduce our confidence in the findings. The method used to collect the data (sinkhole) is uniform across our feeds.

Verify

Investigate the potential calibration differences between our data, our partner’s data, and your infrastructure. Our sinkholes observe outward traffic from the Network Address Translation (NAT). Learn more about why sinkholing provides substantial evidence of an event.

If the space can be routed (inbound/outbound), check the following:

• Verify that you have a full inventory of endpoints (laptop, phone, server, etc.) that are connected and are running in your corporate network.
• If you have guest/contractor traffic that’s commingled with the normal IP space and you have comprehensive monitoring in place for each of those endpoints, consider segmenting the traffic as a self-published company.
• If a system is malware testing and is commingled with normal traffic, please review our testing-related network policy.
• If you have a fully integrated and centralized archive/log management system that integrates MAC ⇔ DHCP ⇔ LAN ⇔ NAT records, check these logs to correlate the timestamp found on the reported event with the network traffic you observed.

  Since data is externally collected, we are unable to access information from behind firewalls.

• Run a traceroute both into and out of the interface from a public IP. Consider whether or not the IP space could have been routable in the past (during the time the event was reported) and confirm these findings with network logs.
• If you have packet capture turned on for the affected IP (both inbound and outbound), review the logs from the relevant time period. If not, set up packet capture for the interface to capture any traffic.

If you undertake this work and still find it to be inconclusive, please contact Bitsight Support. Our Data & Research team will open an investigation to review your case. We will schedule a call with you to discuss your findings and appropriate next steps.