Transport Layer Security has been one of the greatest contributors to the privacy and security of Internet communications over the past decade. The TLS cryptographic protocol is used to secure an ever-increasing portion of the Internet’s web, messaging and application data traffic. The secure HTTP (HTTPS) web protocol, StartTLS email protocol, Tor anonymizing network, and virtual private networks such as those based on the OpenVPN protocol all leverage TLS to encrypt and encapsulate their contents—protecting them from being observed or modified in transit.

1. See Full List On Community.sophos.com
2. Sophos Central Admin: How To Resolve The Malware Or Potentially Unwanted Applications In Quarantine Alert
3. Sophos Malware Protection
4. Sophos Vs Malware

Malware detection - All scheduled and on-demand scans in Sophos Anti-Virus detect malware if it is present on the computer. False positive malware detections are very rare. When Sophos Anti-Virus detects a malware file (with the prefix W32/, /Troj, /Mal/, etc.) you should treat it as a real threat unless you are absolutely sure that the file is. Malware detection - All scheduled and on-demand scans in Sophos Anti-Virus detect malware if it is present on the computer. False positive malware detections are very rare. When Sophos Anti-Virus detects a malware file (with the prefix W32/, /Troj, /Mal/, etc.) you should treat it as a real threat unless you are absolutely sure that the file is.

Over the past decade, and particularly in the wake of revelations about mass Internet surveillance, the use of TLS has grown to cover a majority of Internet communications. According to browser data from Google, the use of HTTPS has grown from just over 40 percent of all web page visits in 2014 to 98 percent in March of 2021.

It should come as no surprise, then, that malware operators have also been adopting TLS for essentially the same reasons: to prevent defenders from detecting and stopping deployment of malware and theft of data. We’ve seen dramatic growth over the past year in malware using TLS to conceal its communications. In 2020, 23 percent of malware we detected communicating with a remote system over the Internet were using TLS; today, it is nearly 46 percent.

There’s also a significant fraction of TLS communications that use an Internet Protocol port other than 443—such as malware using a Tor or SOCKS proxy over a non-standard port number. We queried against certificate transparency logs with the host names associated with malware Internet communications on ports other than 443, 80, and 8080, and found that 49 percent of the hosts had TLS certificates associated with them that were issued by a Certificate Authority (CA). A small fraction of the others manually checked used self-signed certificates.

But a large portion of the growth in overall TLS use by malware can be linked in part to the increased use of legitimate web and cloud services protected by TLS—such as Discord, Pastebin, Github and Google’s cloud services—as repositories for malware components, as destinations for stolen data, and even to send commands to botnets and other malware. It is also linked to the increased use of Tor and other TLS-based network proxies to encapsulate malicious communications between malware and the actors deploying them.

Google’s cloud services were the destination for nine percent of malware TLS requests, with India’s BSNL close behind. During the month of March 2021, we saw a rise in the use of Cloudflare-hosted malware—largely because of a spike in the use of Discord’s content delivery network, which is based on Cloudflare, which by itself accounted for 4 percent of the detected TLS malware that month. We reported over 9,700 malware related links to Discord; many were Discord-specific, targeting the theft of user credentials, while others were delivery packages for other information stealers and trojans.

In aggregate, nearly half of all malware TLS communications went to servers in the United States and India.

We’ve seen an increase in the use of TLS use in ransomware attacks over the past year, especially in manually-deployed ransomware—in part because of attackers’ use of modular offensive tools that leverage HTTPS. But the vast majority of what we detect day-to-day in malicious TLS traffic is from initial-compromise malware: loaders, droppers and document-based installers reaching back to secured web pages to retrieve their installation packages.

To gain insight into how usage of TLS in malware has changed, we took a deep dive into our detection telemetry to both measure how much TLS is used by malware, identify the most common malware that leverage TLS, and how those malware make use of TLS-encrypted communications. Based on our detection telemetry, we found that while TLS still makes up an average of just over two percent of the overall traffic Sophos classifies as “malware callhome” over a three-month period, 56 percent of the unique C2 servers (identified by DNS host names) that communicated with malware used HTTPS and TLS. And of that, nearly a quarter is with infrastructure residing in Google’s cloud environment.

Surprise packages

Malware communications typically fall into three categories: downloading additional malware, exfiltration of stolen data, and retrieval or sending of instructions to trigger specific functions (command and control). All these types of communications can take advantage of TLS encryption to evade detection by defenders. But the majority of TLS traffic we found tied to malware was of the first kind: droppers, loaders and other malware downloading additional malware to the system they infected, using TLS to evade basic payload inspection.

It doesn’t take much sophistication to leverage TLS in a malware dropper, because TLS-enabled infrastructure to deliver malware or code snippets is freely available. Frequently, droppers and loaders use legitimate websites and cloud services with built-in TLS support to further disguise the traffic. For example, this traffic from a Bladabindi RAT dropper shows it attempting to retrieve its payload from a Pastebin page. (The page no longer exists.)

See Full List On Community.sophos.com

We’ve seen numerous cases of malware behaving this way in our research. The PowerShell-based dropper for LockBit ransomware was observed retrieving additional script from a Google Docs spreadsheet via TLS, as well as from another website. And a dropper for AgentTesla (discussed later in this report) also has been observed accessing Pastebin over TLS to retrieve chunks of code. While Google and Pastebin often quickly shut down malware-hosting documents and sites on its platform, many of these C2 sources are abandoned after a single spam campaign, and the attackers simply create new ones for their next attack.

Sometimes malware uses multiple services this way in a single attack. For example, one of the numerous malware droppers we found in Discord’s content delivery network dropped another stage also hosted on Discord, which in turn attempted to load an executable directly from GitHub. (The GitHub code had already been removed as malicious; we disclosed the initial stages of the malware attack to Discord, along with numerous other malware, who removed them.)

Malware download traffic actually makes up the majority of the TLS-based C2 traffic we observed. In February 2021, for instance, droppers made up over 90 percent of the TLS C2 traffic—a figure that closely matches the static C2 detection telemetry data associated with similar malware month-to-month from January through March of 2021.

Covert channels

Malware operators can use TLS to obfuscate command and control traffic. By sending HTTPS requests or connecting over a TLS-based proxy service, the malware can create a reverse shell, allowing commands to be passed to the malware, or for the malware to retrieve blocks of script or required keys needed for specific functions. Command and control servers can be a remote dedicated web server, or they can be based on one or more documents in legitimate cloud services. For example, the Lampion Portuguese banking trojan used a Google Docs text document as the source for a key required to unlock some of its code—and deleting the document acted as a kill-switch. By leveraging Google Docs, the actors behind Lampion were able to conceal controlling communications to the malware and evade reputation-based detection by using a trusted host.

The same sort of connection can be used by malware to exfiltrate sensitive information—transmitting user credentials, passwords, cookies, and other collected data back to the malware’s operator. To conceal data theft , malware can encapsulate it in a TLS-based HTTPS POST, or export it via a TLS connection to a cloud service API, such as Telegram or Discord “bot” APIs.

SystemBC

One example of how attackers use TLS maliciously is SystemBC, a multifaceted malicious communications tool used in a number of recent ransomware attacks. The first samples of SystemBC, spotted over a year ago, acted primarily as a network proxy, creating what amounted to a virtual private network connection for attackers based on SOCKS5 remote proxy connection encrypted with TLS—providing concealed communications for other malware. But the malware has continued to evolve, and more recent samples of SystemBC are more full-featured remote access trojans (RATs) that provide a persistent backdoor for attackers once deployed. The most recent version of SystemBC can issue Windows commands, as well as deliver and run scripts, malicious executables, and dynamic link libraries (DLLs)—in addition to its role as a network proxy.

SystemBC is not entirely stealthy, however. There’s a lot of non-TLS, non-Tor traffic generated by SystemBC—symptomatic of the incremental addition of features seen in many long-lived malware. The sample we recently analyzed has a TCP “heartbeat” that connects over port 49630 to a host hard-coded into the SystemBC RAT itself.

The first TLS connection is an HTTPS request to a proxy for IPify, an API that can be used to obtain the public IP address of the infected system. But this request is sent not on port 443, the standard HTTPS port—instead, it’s sent on port 49271. This non-standard port usage is the beginning of a pattern.

SystemBC then attempts to obtain data about the current Tor network consensus, connecting to hard-coded IP addresses with an HTTP GET request, but via ports 49272 and 49273. SystemBC uses the connections to download information about the current Tor network configuration.

Next, SystemBC establishes a TLS connection to a Tor gateway picked from the Tor network data. Again, it uses another non-standard port: 49274. And it builds the Tor circuit to the destination of its Tor tunnel using directory data collected via port 49275 via another HTTP request. There, the progression of sequential ports ends, and in the sample we analyzed it tries to fetch another malware executable via an open HTTP request over the standard port.

The file retrieved by this sample, henos.exe, is another backdoor that connects over TLS on the standard port (443) to a website that returns links to Telegram channels—a sign that the actor behind this SystemBC instance is evolving tactics. SystemBC is likely to continue to evolve as well, as its developers address the mixed use of HTTP and TLS and the somewhat predictable non-standard ports that allow SystemBC to be easily fingerprinted.

AgentTesla

Like SystemBC, AgentTesla—an information stealer that can also function in some cases as a RAT—has evolved over its long history. Active for more than seven years, AgentTesla has recently been updated with an option to use the Tor anonymizing network to conceal traffic with TLS.

We’ve also seen TLS used in one of AgentTesla’s most recent downloaders, as the developers have used legitimate web services to store chunks of malware encoded in base64 format on Pastebin and a lookalike service called Hastebin. The first stage downloader further tries to evade detection by patching Windows’ Anti-Malware Software Interface (AMSI) to prevent in-memory scanning of the downloaded code chunks as they’re joined and decoded.

The Tor addition to AgentTesla itself can be used to conceal communications over HTTP. There is also another optional C2 protocols in AgentTesla that that could be TLS protected—the Telegram Bot API, which uses an HTTPS server for receiving messages. However, the AgentTesla developer didn’t implement HTTPS communications in the malware (at least for now)—it fails to execute a TLS handshake. Telegram accepts unencrypted HTTP messages sent to its bot API.

Dridex

Dridex is yet another long-lived malware family that has seen substantial recent evolution. Primarily a banking Trojan, Dridex was first spotted in 2011, but it has evolved substantially. It can load new functionality through downloaded modules, in a fashion similar to the Trickbot Trojan. Dridex modules may be downloaded together in an initial compromise of the affected system, or retrieved later by the main loader module. Each module is responsible for performing specific functions: stealing credentials, exfiltrating browser cookie data or security certificates, logging keystrokes, or taking screenshots.

Dridex’s loader has been updated to conceal communications, encapsulating them with TLS. It uses HTTPS on port 443 both to download additional modules from and exfiltrate collected data to the C2 server. Exfiltrated data can additionally be encrypted with RC4 to further conceal and secure it. Dridex also has a resilient infrastructure of command and control (C2) servers, allowing installed malware to fail over to a backup if its original C2 server goes down.

These updates have made Dridex a continuing threat, and Dridex loaders are among the most common families of malware detected using TLS—overshadowed only by the next group of threats in our TLS rogues’ gallery: off-the-shelf “offensive security” tools repurposed by cybercriminals.

Metasploit and Cobalt Strike

Offensive security tools have long been used by malicious actors as well as security professionals. These commercial and open-source tools, including the modular Cobalt Strike and Metasploit toolkits, were built for penetration testing and “red team” security evaluations—but they’ve been embraced by ransomware groups for their flexibility.

Over the last year, we’ve seen a surge in the use of tools derived from offensive security platforms in manually-deployed ransomware attacks, used by attackers to execute scripts, gather information about other systems on the network, extract additional credentials, and spread ransomware and other malware.

Taken together, Cobalt Strike beacons and Metasploit “Meterpreter” derivatives made up over 1 percent of all detected malware using TLS—a significant number in comparison to other major malware families.

And all the rest

Potentially unwanted applications (PUAs), particularly on the macOS platform, also leverage TLS, often through browser extensions that connect surreptitiously to C2 servers to exfiltrate information and inject content into other web pages. We’ve seen the Bundlore use TLS to conceal malicious scripts and inject advertisements and other content into web pages, undetected. Overall, we found over 89 percent of macOS threats with C2 communications used TLS to call home or retrieve additional harmful code.

There are many other privacy and security threats lurking in TLS traffic beyond malware and PUAs. Phishing campaigns increasingly rely on websites with TLS certificates—either registered to a deceptive domain name or provided by a cloud service provider. Google Forms phishing attacks may seem easy to spot, but users trained to “look for the lock” alongside web addresses in their browser may casually type in their personally identifying data and credentials.

Traffic analysis

All of this adds up to a more than 100 percent increase in TLS-based malware communications since 2020. And that’s a conservative estimate, as it’s based solely on what we could identify through telemetry analysis and host data.

As we’ve noted, some use TLS over non-standard IP ports, making a completely accurate assessment of TLS usage impossible without deeper packet analysis of their communications. So the statistics sited in this report do not reflect the full range of TLS-based malicious communications—and organizations should not rely on the port numbers related to communications alone to identify potential malicious traffic. TLS can be implemented over any assignable IP port, and after the initial handshake it looks like any other TCP application traffic.

Even so, the most concerning trend we’ve noted is the use of commercial cloud and web services as part of malware deployment, command and control. Malware authors’ abuse of legitimate communication platforms gives them the benefit of encrypted communications provided by Google Docs, Discord, Telegram, Pastebin and others—and, in some cases, they also benefit from the “safe” reputation of those platforms.

We also see the use of off-the-shelf offensive security tools and other ready-made tools and application programming interfaces that make using TLS-based communications more accessible continuing to grow. The same services and technologies that have made obtaining TLS certificates and configuring HTTPS websites vastly simpler for small organizations and individuals have also made it easier for malicious actors to blend in with legitimate Internet traffic, and have dramatically reduced the work needed to frequently shift or replicate C2 infrastructure.

All of these factors make defending against malware attacks that much more difficult. Without a defense in depth, organizations may be increasingly less likely to detect threats on the wire before they have been deployed by attackers.

SophosLabs would like to acknowledge Suriya Natarajan, Anand Aijan, Michael Wood, Sivagnanam Gn, Markel Picado and Andrew Brandt for their contributions to this report.

Editor’s note (2020-04-30): As we learn more from our ongoing investigation, we will issue updates at the end of this article.

As we described last week in this KBA, Sophos and its customers were the victims of a coordinated attack by an unknown adversary. This attack revealed a previously unknown SQL injection vulnerability that led to remote code execution on some of our firewall products. As described in the KBA, the vulnerability has since been remediated.

This post is the result of many hours of research and reverse-engineering by SophosLabs and Sophos internal security teams, working in conjunction with product management to coordinate a hotfix and global response within two days of discovering this attack. In the spirit of transparency, we want to describe the nature of the attack and a detailed analysis of the malware based on our investigation and current understanding.

There was significant orchestration involved in the execution of the attack, using a chain of Linux shell scripts that eventually downloaded ELF binary executable malware compiled for a firewall operating system. This attack targeted Sophos products and apparently was intended to steal sensitive information from the firewall.

How the attack began

The infection process started when an attacker discovered, and exploited, a zero-day SQL injection remote code execution vulnerability. The exploit of this vulnerability resulted in the attacker being able to insert a one-line command into a database table.

This initial injected command triggered an affected device to download a Linux shell script named Install.sh from a remote server on the malicious domain sophosfirewallupdate[.]com. The command also wrote this shell script to the /tmp directory on the device, used the chmod program to designate the file as executable, and executed it.

The script (written to the appliance as x.sh) ran a series of SQL commands and dropped additional files into the virtual file system to lay the groundwork for the rest of the attack.

The Install.sh script, initially, ran a number of Postgres SQL commands to modify or zero out the values of certain tables in the database, one of which normally displays the administrative IP address of the device itself. It appears that this was an attempt to conceal the attack, but it backfired: On some appliances, the shell script’s activity resulted in the attacker’s own injected SQL command line being displayed on the user interface of the firewall’s administrative panel. In place of what should have been an address, it showed a line of shell commands.

This script also dropped at least two other shell scripts into the /tmp directory, and modified at least one shell script that is part of the firewall’s operating system to add a set of commands to the end of the script. This last script, in particular, is relevant because the malware modified services to ensure it ran every time the firewall booted up; it served as a roundabout persistence mechanism for the malware.

The three shell ELF game

The installer script, x.sh, dropped two completely new shell scripts, and modified an existing script that is part of the operating system.

One of the dropped shell scripts was named .lp.sh and its primary function was to connect to the malicious sophosfirewallupdate site, and download a Linux ELF executable file compiled to run on the firewall operating system named lp. The script wrote that downloaded file to /tmp with a filename of just b.

The b program, when run, deleted itself from the filesystem of the device, so it was only present in memory. It appeared in the process list as a program whose name, cssconf.bin, is one character off from a legitimate process that normally runs on a firewall, cscconf.bin. The highlighted process list below shows the malicious program as it would have appeared running on an infected firewall. It is also notable that it listed its parent process ID as 1, which the legitimate cscconf.bin would never have done.

While b was in memory, it repeated a series of tasks every 3 to 6 hours — a delay interval chosen at random the first time it ran, and reused thereafter.

First, b checked to see if it could make a connection to a machine with the IP address of 43.229.55.44. If the ELF couldn’t make a connection to that IP address, it attempted to resolve the IP address for the malicious domain sophosproductupdate[.]com.

Sophos Central Admin: How To Resolve The Malware Or Potentially Unwanted Applications In Quarantine Alert

If it resolved the IP for that domain, and DNS did not return a value of 127.0.0.1 as a result, then it downloaded another Linux ELF executable called Sophos.dat, which we’ll discuss in the next section.

Shell script number two dropped by the Install.sh/x.sh script was written to the /tmp directory with a filename of .pg.sh. Its main purpose was to download a second, different ELF executable, which was called bk on the webserver and was written to the filesystem with the name .post_MI.

Earlier we mentioned that Install.sh, the first stage dropper, ran a number of Postgres SQL commands. One of these commands modified a specific service value entry so that .post_MI executed whenever that service executed; this provided persistence by starting the malware at every reboot.

Sophos Malware Protection

This executable had limited functionality: It checked to see whether a file named .a.PGSQL (more on this in a minute) had been written to the /tmp directory, and if it didn’t find it, it attempted to download a shell script from the web server hosted at ragnarokfromasgard.com, called patch.sh. At the time we performed the analysis of the attack, this server wasn’t responding.

The third shell script is a modification of a shell script that is already part of the firewall’s internal operating system, named generate_curl_ca_bundle.sh. The Install.sh/x.sh script made a backup copy of the original (prepending a dot to the filename, .generate_curl_ca_bundle.sh) before it modified the original script to append code to the file. That code wrote out and dropped yet another shell script, /tmp/I (just a capital letter i).

The I script had two primary functions. First, it performed a “touch” of the /tmp/.a.PGSQL file (an act that, if the file did not exist, created it in the /tmp directory). The previously-mentioned .post_MI ELF executable checked to see if .a.PGSQL existed as part of its execution.

The I script then retrieved a shell script file named lc from the sophosfirewallupdate domain, and wrote that to the /tmp directory as .n.sh and executed it. This script replicated the same behavior as the .lp.sh script (mentioned above), and attempted to download and execute the b ELF executable from the malicious sophosfirewallupdate website. This download of b was the persistence mechanism, given that the b process deleted itself off disk as one of its first actions.

Data exfiltration process

Note: This section describes our understanding of the data exfiltration capabilities of the malware at the time of publication of this article, but we have not discovered any evidence that the data collected had been successfully exfiltrated.

The steps involving the shell scripts and ELF binary executables apparently were done in order to bring the attack to the point where the malware downloaded and executed a file that had been named Sophos.dat on the remote server, saved to the filesystem as 2own.

This malware’s primary task appeared to be data theft, which it could perform by retrieving the contents of various database tables stored in the firewall, as well as by running some operating system commands. At each step, the malware collected information and then concatenated it to a file it stored temporarily on the firewall with the name Info.xg.

First, the binary attempted to retrieve the public-facing IP address where the firewall was installed. It did this first by querying the website ifconfig.me, and if that site was not reachable for some reason, it tried to do the same by contacting checkip.dyndns.org.

Next, it queried a number of data storage areas on the firewall to retrieve information about the firewall and its users.

This diagram below shows the capability of the malware to exfiltrate data. As of the date of publication, we have not discovered any evidence that the data collected had been successfully exfiltrated.

The malware demonstrated the capability to retrieve only firewall resident information, which may have included:

• The firewall’s license and serial number
• A list of the email addresses of user accounts that were stored on the device, followed by the primary email belonging to the firewall’s administrator account
• Firewall users’ names, usernames, the encrypted form of the passwords, and the salted SHA256 hash of the administrator account’s password. Passwords were not stored in plain text.
• A list of the user IDs permitted to use the firewall for SSL VPN and accounts that were permitted to use a “clientless” VPN connection.

The malware then queried an internal database of the firewall to retrieve a list of the IP address allocation permissions for the users of the firewall, as well as information about the appliance itself: What version of the operating system was running, what type of CPU and amount of memory was present on the device; how long it had been operational since the last reboot (the ‘uptime’); and the output of the ifconfig and ARP tables.

Once the malware wrote all this information to Info.xg, it then compressed it using the tar compression tool, and then used OpenSSL to encrypt the archive file. The attacker used the Triple-DES algorithm to encrypt the file, and for a pass phrase, the word “GUCCI” in all capital letters. The malware then intended to upload the encrypted file to a machine at the IP address 38.27.99.69, and then cleaned up its tracks by deleting the files temporarily created while it collected the information.

Remediation and response

Files associated with this attack have been added to the definition Linux/Agnt-G and domains and IP addresses have been flagged as malicious in the SophosXL domain reputation service.

A hotfix update has already been released to Sophos customers to patch the vulnerability used by the attackers to access the firewalls. If you don’t have automatic updates enabled on the firewall, please follow these instructions to enable them.

Since the attack was discovered, Sophos has taken a number of steps, which we can summarize as follows: SophosLabs blocked domains found in initial forensic analysis of the attack, and later identified and blocked additional domains and IP addresses associated with the attack. We notified customers about mitigation steps. We issued a telemetry update to firewalls; and we designed, developed, and tested a hotfix to mitigate the SQL injection and this attack, and then pushed the hotfix to supported devices. Sophos also has submitted a request for a CVE, and will add the CVE number to the knowledge base article once available. We have also taken additional actions that fall outside the scope of this article.

Sophos Vs Malware

There are a few steps Sophos customers can take to harden their environments and remediate an affected firewall appliance. These steps are kept up to date and outlined in the Sophos knowledge base entry on this issue.

Updated information

2020-04-30:

• We’ve since received a report that network activity to the 38[.]27[.]99[.]69 server was observed from multiple targeted firewalls during the attack. Again, we urge customers with impacted firewalls to reset passwords and to follow the remediation instructions contained in KBA135412.
• In addition to the SHA-256 form, an MD5 hash of the admin password was also stored on the firewall for the purposes of backward compatibility. A recently-issued hotfix to the firewall removed the additional hash.

Indicators of Compromise (IoCs)

File indicators

Network indicators

URLs

Domains

Additional suspicious domains

IPs

Filesystem paths