<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2180921&amp;fmt=gif">

Threats! What Threats? Malware Beacons and Stamus Security Platform

One of the first network-related indications of a botnet or peer-to-peer (P2P) malware infection is malware beaconing. This article provides an overview of malware beacons and reviews how the Stamus Security Platform (SSP) can help.

At Stamus Networks, we talk a lot about what we do to detect threats, but we don’t always emphasize which threats, how they work, and why they are harmful. This series -- Threats! What Threats? – seeks to change that.

What are malware beacons and why are they harmful?

An increasingly common way that attackers are avoiding detection after they have accessed a system is the use of command-and-control (C2) beaconing. In this context, beaconing is when malware communicates with an attacker’s C2 server to receive instructions on which tasks should be completed on the target machine. Attackers configure the frequency at which the malware calls home as well as the method for doing so.

HTTP/S, DNS, SSH, and SMTP, as well as common cloud services like Google, Twitter, and Dropbox are all common protocols used for command-and-control. Using these common protocols and services for C2 allow an attacker to evade detection by appearing like normal network traffic.

Beaconing can be difficult to detect and is often missed by many detection systems; however, its unique traits – with respect to packet size and frequency, which can be modeled by standard statistical and signal processing techniques – are the key to catching beacons and locating the malware that uses them.

While the beacon itself is not inherently harmful, the malware that uses beaconing to communicate with a C2 server can potentially cause data breaches (check back next week for more information on command-and-control servers). Detecting malware beaconing that happens at regular intervals is not overly difficult for most systems, but more advanced evasion methods are beginning to appear such as the SUNBURST supply chain compromise which communicated at very infrequent, randomized intervals and allowed attackers to remain undetected.

Thankfully, the Stamus Security Platform (SSP) is capable of detecting low frequency malware beaconing with a level of effectiveness not seen by many modern network-based detection systems. This is due to our use of advanced machine learning algorithms that aren’t restricted by time boundaries.

How does Stamus Security Platform help with malware beacons?

SSP helps SOC teams identify malware beacons on their network by analyzing traffic to generate something we call a Beacon Metric. This is a weighted score that prioritizes TLS servers exhibiting behavior patterns typically associated with beaconing traffic. Essentially, we highlight communications that display clear periodicity or flat byte and specific packet profiles.

C2 callback beacons communicate with pre-configured data amounts for every request and response, and they typically call back at regular intervals whether frequent or infrequent. More advanced beacons might have more randomization in their communication intervals, otherwise known as jitter. Despite increased efforts to avoid detection, SSP is still able to recognize jitter within network traffic. 

To calculate a Beacon Metric, SSP first profiles your organization's TLS traffic by performing a frequent item detection, and then excludes those findings from the analysis. All remaining connections are considered to be a potential beacon and statistical measurements are taken.

These measurements are used to assign each potential beacon a score of 0 to 100 which is then sorted on the tracking table. The higher the score is, the greater the likelihood is of that traffic being a malware beacon.

It is important to note that many legitimate, safe communications, like software updates, API calls, and telemetry services, sometimes exhibit beaconing patterns. SSP identifies known services by analyzing Server Name Indicators (SNI) and then deprioritizes those entries. Seeing them in the entry tab is normal because they could be indicating policy violations or other abnormal network findings.

All of this is performed automatically with machine learning. As traffic comes through the network, SSP analyzes those communications to look for patterns in the method and timing. Even infrequent and randomized beacons follow some sort of pattern. Because SSP does not restrict our algorithms with time boundaries, these communications are under constant analysis and the tracking table is continually updated. 

The image below shows the SSP Beacon overview screen

SSP Beacon overview screen

 

The overall Beacon Metric does not calculate the certainty of traffic being a beacon, but rather shows the likelihood and a relevant statistical measurement. The Beacon Metric is an excellent tool that should be used as a starting point for your investigation into potentially suspicious activity.

To investigate potential beacons we recommend that you take the following steps:

  • Investigate the TLS SNI values to determine if the domain is malicious or a known service. For example, is the domain for Microsoft Update services, or is it randomly generated? Is it from an unexpected/or unauthorized SNI?
  • Investigate and inspect the TLS issuer. Self-signed certificates or Let’s Encrypt are issuers that are often used by malicious servers.
  • Investigate the traffic profile to see if connections occur at specific intervals, skewed intervals, or if the data profile is flat.
  • For TLS v1.3, investigate the client, the server hosts, and JA3/JA3S profiles and if they are seen anywhere else on the network. You’ll want to find out when and how and which users are involved. Most importantly, you’ll want to identify what application service(s) are emitting those.
  • Pivot to the Host Insights screen (with a single click) to further review of the context surrounding the hosts involved in the transaction. 

See the image below of the Beacon detail screen which the analyst may use as the starting point for investigating suspected beacons.

Beacon detail screen to assist in analyst investigation

More information on Stamus Security Platform

Hopefully you now have a broad overview into what malware beaconing is, why it denotes harmful activity on your network, and how the Stamus Security Platform detects it. The Stamus Threat Research team is constantly making updates to our system to better detect malware beacons and all other types of threats. The detection method used to locate and analyze potential beacons - machine learning - is only one of the many methods we employ across a wide range of threat types.

If you would like to see a live demonstration of the Stamus Security Platform and see for yourself how the Beaconing Metric is used to spot threats on your network and optimize your network security, click on the button below to request a demo.

D. Mark Durrett

Mark is the chief marketing officer (CMO) at Stamus Networks, where he has responsibility for go-to-market strategy and execution. Mark started his career as an electrical engineer and worked in digital circuit design of networking and telecom hardware for over a decade. He has over 25 years of experience leading marketing, product management and engineering for technology companies. Mark has served as the senior product and marketing executive at Netsertive, Emerging Threats, Overture Networks, Bell and Howell, Covelight Systems and Hatteras Networks. Mark resides in North Carolina, USA.

Schedule a Demo of Stamus Security Platform

REQUEST A DEMO

Related posts

In the Trenches with NDR: NDR Discovers Crypto Wallet Stealer on U.S. University's Network

Tl:DR: A Large U.S. university lacked sufficient visibility into a large segment of its environment...

The Rise of Network Infrastructure Attacks and What to Do About Them

TL;DR: In recent months, CISA, MITRE, CVE.org, and others have announced critical vulnerabilities...

In the Trenches with NDR: K-12 School District Maximizes Visibility While Avoiding Alert Fatigue

TL;DR: An American school district needed to monitor over 5000 school-owned student devices, making...