CSAM: Be Wary of False Beacons

Published: 2014-10-13
Last Updated: 2014-10-13 14:03:34 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

[This is a guest diary published on behalf of Chris Sanders]

Hunting for evil in network traffic depends on the analysts ability to locate patterns and variances in oceans of data. This can be an overwhelming tasks and relies on fundamental knowledge of what is considered normal on your network as well as your experienced-based intuition. These dark waters are navigated by finding glimmers of light and following them where they lead you by carefully investigating all of the data sources and intelligence in your reach. While hunting the adversary in this manner can yield treasure, following some of these distant lights can also land you in the rocks.

One scenario that often puts analysts in murky waters occurs when they chase patterns of network traffic occurring over clearly visible intervals. This periodic activity often gets associated with “beaconing”, where analysts perceive the timing of the communication to mean that it may be the result of malicious code installed on a friendly system.

As an example, consider the flow records shown here:

 

figure 1
Figure 1 (click on image for full size)

If you look at the timestamps for each of these records, you will see that each communication sequence occurs almost exactly one minute from the previous. Along with this, the other characteristics of the communication appear to be similar. A consistent amount of data is being transferred from an internal host 172.16.16.137 to an external host 173.194.37.48 each time.

So, what’s going on here? Less experienced analysts might jump to the conclusion that the friendly device is compromised and that it is “beaconing” back out to some sort of attacker controlled command and control infrastructure. In reality, it doesn’t take a lot of research to determine that the mysterious external entity is a Google hosted IP address. In this case, this traffic actually represents the periodic updating of a Google Finance stock ticker.

Figure 2
Figure 2 (click on image for full size)

As analysts, we are taught to identify patterns and hone in on those as potential signs of compromise. While this isn’t an entirely faulty concept, it should also be used with discretion. With dynamic content so prevalent on the modern Internet, it is incredibly common to encounter scenarios where devices communicate in a periodic nature. This includes platforms such as web-based e-mail clients, social networking websites, chat clients, and more.

Ultimately, all network traffic is good unless you can prove it’s bad. If you do need to dig in further in scenarios like this, try to make the best use of your time by looking for information you can use to immediately eliminate the potential that the traffic is malicious. This might include some basic research about the potentially hostile host like we did here, immediately pivoting to full PCAP data to view the content of the traffic when possible, or by simply examining the friendly host to determine which process is responsible for the connection(s). The ability to be selective of what you choose to investigate and to quickly eliminate likely false positives is the sign of a mature analyst. The next time you are hunting through data looking for evil, be wary when your eyes are drawn towards “beaconing” traffic.

Chris Sanders
Twitter: @chrissanders88
Blogs: http://www.appliednsm.com & http://www.chrissanders.org

Keywords:
2 comment(s)

Comments

Hi,

Trying not to state the obvious but want to move myself along to becoming a more mature Analyst. The financial ticker conclusion came after reviewing the internal machine and finding this application installed, correct? Appreciate the story and keep up the good work.
Hey Tim!

In this case, we are starting with flow data so we only have the "who, when, and where". We can build on this data by digging into the "who" a bit more and doing a lookup to determine that Google owns the external IP address we see in the data. Now, we want to find out the "what happened" so we can make an analysis decision on the "why we think this traffic is bad". An initial thought might be to pivot to full PCAP data, but in this case the communication is encrypted (it is occurring over SSL port 443), so that probably won't help. One way to figure out what might be going on is to look at proxy logs associated with the friendly host and match the timestamps to what is shown in the flow data. This should yield the actual URLs being referenced (in this case, the Google Finance URL). If proxy logs are not available, you could determine what is going on by looking at the browser history on the device and syncing up timestamps with the flow data to see that the google finance site was visited around this time period. Now that we know what happened (the traffic was generated by visiting google), we can answer "Why do we think this traffic is bad?" with "We no longer think that."


Hope this helps!

Chris

Diary Archives