Many successful attacks today fly way under the radar of current intrusion detection methodologies. For example, foreign intelligence agencies and organized crime rings use targeted spear phishing techniques combined with fresh application exploits to gain a foothold inside of their quarry’s networks. Attackers maintain access to victimized organizations by installing simple, but effective code that “beacons” to one or more hosts outside of the organization under the control of the adversary.

“Beacon receiver hosts” are typically hard-coded into the malicious code as canonical hostnames that are pre-registered in advance of the initial attack – most often with free dynamic DNS hosting services. These hosting services are based overseas, which complicates effective law enforcement investigations. Embedding canonical DNS names vs. IP addresses in the beacon code allows attackers to change beacon receiver hosts on the fly. Attackers often register DNS names that look legitimate to decrease the possibility that they will be noticed within network traffic, host and security system logs.

Hosts infected with beacon Trojans often send only one packet every 1-24 hours, depending on how stealthy the adversary wishes to remain, but over a period of a year and considering the compromise of many hosts within an organization, a large amount of traffic can be exfiltrated. Attackers take advantage of less restrictive outbound firewall ACLS. Beacon Trojans use common outbound ports allowed even in fairly restrictive environments. Adversaries favor TCP 443, as many organizations rarely monitor it, or they do not have the technology to enforce RFC compliance (i.e. refusing to allow non-SSL egress traffic over TCP 443). Attackers incorporate control and data channel obfuscation within their malicious beacon code (i.e. XORing data before transmission). Sophisticated attackers may prefer obfuscation rather than encryption to avoid the scrutiny that encrypted communication channels may bring.

This session demonstrates how using statistical analyses and mathematical operations, it is possible to identify stealthy beacon traffic hiding in rivers of data. We show how to determine if your organization currently is being exploited by beacon Trojans (which many are, and do not know it), and how to build a monitoring infrastructure that will help you identify this type of activity as soon as it begins, rather than after the adversary has captured gigabytes of your data.