Examining traffic patterns can help spot malware such as Razy on users’ systems
Note: Periodically, security researchers on the Cato Networks Research Lab publish internal findings gained while hunting threats on customer networks. These are security insights driven by networking data—something that’s only become practical with the convergence of networking and security data in secure access service edge (SASE) platforms.
Cato Research Lab team has developed a massive data warehouse built from the metadata of every flow of every customer across its global, private backbones. This data warehouse is enriched with threat intelligence feeds and other security sources, providing what for many companies is the first comprehensive networking and security repository.
This blog brings data-driven insights based on the findings from this massive data warehouse to help improve your company’s own security. In this post, we hear from Tal Ben Zvi, security analyst at Cato Networks, who just completed work in detecting and remove previously undetected Razy malware.
With more work being done in web browsers, browser extensions are providing a wide attack surface for attackers to run malicious code, leak information, mimic legitimate extensions to extend infection and gain further permissions to user systems. These extensions look innocent, pretending to solve bugs for users. All the while, they perform malicious activity in the background, even infecting other legitimate browser extensions in their favor.
Anti-virus (AV) systems are of little help. Even leading AV systems often fail to distinguish between legitimate browser actions and malicious ones. We know because Cato Research Labs recently detected Razy malware on a customer’s desktop that was reported as being clean even after running a full AV scan with a leading AV system.
If an AV system won’t detect Razy, how can you? Do what we did: Examine network traffic patterns. We’ve used this technique to identify malicious bot on customer networks. You can do something similar to find Razy on your network.
Razy Malware – A High-Level Overview
Razy malware is an MS-Windows based malware, immensely popular in the wild. It operates by installing a malicious web browser extension that manipulates the web browser. Razy malware is spotted in many cases targeting Google Chrome and Mozilla Firefox users. The most common infections occur via malicious links that impersonate an innocent domain, luring the victim to install an “innocent” toolbox, which results in an installation of a malicious web-browser extension.
Once deployed, the infected web browser will display malicious ads while browsing the web. These ads may lead the victim to make unwanted cryptocurrency transactions and the like (see Figure 1).
Fig. 1: Razy will cause infected browsers to display malicious ads, like this one (in Russian), while browsing the web.
Endpoint Security Solutions Fail to Detect Razy
By embedding Razy in a browser extension, attackers bypass most AV systems. For one, AV systems rely on signature-based detection to accelerate threat identification. But threats like Razy use various techniques to obscure any signature.
What’s more, AV engines need to run inline on minimal resources, which limits them to using fixed heuristic signatures that only read elements of the file, such as the file or the file extension. As such, they have a difficult time differentiating between legitimate browser actions and malicious ones.
The bottom line: Browser extensions provide a wide attack surface for attackers to run malicious code, leak information, mimic legitimate extensions to extend infection and gain further permissions. Many malicious browser extensions in the wild pretend to solve bugs for users and look very innocent while performing malicious activity in the background and even infecting other legitimate browser extensions in their favor.
What You Can Do to Spot Razy
Razy uses various techniques to avoid detection by a signature-based system but the malware can’t change its network behavior. It still needs to communicate back with a command-and-control server. You can detect this and other communication by examining the attributes of your network flows.
Start by looking for network traffic terminating at unpopular or unusual destinations. The theory here is that most users browse to known or popular domains and applications. As such, network flows terminating at unpopular destinations are one indicator of malicious activity.
Cato maintains a massive data warehouse of all metadata from all traffic flows from all users of every customer, amounting to about a terabyte of data a week. Machine learning algorithms analyze this metadata on multiple levels; one such level is the frequency users visit various domains. Overwhelmingly we see user flows terminating at very popular domains (Google, Amazon, etc.) or applications (SAP, O365 etc.).
We’ve also seen how malware traffic terminates at less popular domains. Intuitively, that makes sense—attackers often change domains of their command-and-control servers to avoid URL filters classifying them as malicious.
Of course, a low popularity score alone doesn’t mean domain is malicious. The domain could be a new legitimate domain or even a private one that is unpopular but not malicious. That’s why you need to investigate further.
While investigating traffic terminating at domains with low popularity, look for very predictable traffic. Razy malware, like many types of malware, will communicate regularly with the command-and-control server. This period may be spread out across days even weeks, but it will be very predictable unlike traffic from a legitimate user.
Examine the Client
We found that the traffic flow is far too periodic for a human—our malware alarms should start sounding. The source may have an infection, but how do you prove the infection? Remember, our customer’s endpoint security solution couldn’t detect Razy even after a full scan. Should they just trust that we (or you) are right? Hardly.
Dive into the endpoint and look for IoCs (Indicators of Compromise) proving an infection. You’ll want to extract logs and configuration information from the infected client. Look into the operating system for information such as start-up registry keys, logon events, installed applications, prefect files and browser extension data. At Cato, we have customers run a PowerShell script that gathers this information, but you can do much of that on your own (or find third-party tools that can help).
Chrome Extension Configuration File
While analyzing the extracted logs from the infected host, look at the Google Chrome extensions configuration file. Razy will obfuscate the name of malicious Chrome Extension to avoid detection by the endpoint security solution. For example, in our case, the extension identifier is shown as “pkedcjkdefgpdelpbcmbmeomcjbeemfm”. Following an OSINT (Open-source intelligence) investigation, we can see that this extension identifier has many associations with Razy malware.
Pop Up Ads
Finally, diving further into the extension’s Google Chrome configuration file, we see that it offers pop up ads in different languages designed to attract users to click on links to malicious URLs.
At this point, we have a high degree of certainty that we’re look at an infected host—despite what the endpoint security system tells us.
How Can Enterprises Protect Themselves?
Security teams always should block and investigate traffic to low popularity destinations exhibiting periodic traffic patterns. By examining configuration details of the browser they’ll be able to validate for certain if Razy malware exists on their endpoints. As for the future, preventing users from installing unknown software and browser extensions will go a long way to stopping attackers from using Razy to compromise your network.