Hiding in Plain Sight

What is a RAT?

There is an increasing RAT problem that security professionals need to be aware of.  To be clear, we are not talking about the 4-legged rodent, but instead, about a specific type of malware.  A RAT (“Remote Access Trojan”) is any malware that grants an unauthorized party the ability to remotely manage compromised device(s). This type of malware is also commonly referred to as C2 (“Command and Control”) malware, or what hackers affectionately refer to as “remote shells”.

Managing the RAT Problem

Historically, security operations have relied heavily on identification of malicious infrastructure to minimize the risk of RAT infections.  Malware cannot “phone home” to a C2 server if those communications are blocked.  So, threat intelligence data is often used by organizations to enumerate malicious domains and IP addresses in an effort to prevent outbound C2 communications from leaving the network. In recent years, many organizations have adopted the even more draconian approach of domain whitelisting.  Rather than blocking communications only if the domain is known to be malicious, this approach instead opts to restrict all outbound communications unless those communications are to domains and/or IP addresses that are known to be good.  Even organizations that don’t want to deal with the management overhead of domain whitelisting are now commonly blocking communications to “unknown” or “unclassified” domains.

As a result, threat actors are beginning to adapt their TTPs (“Tactics, Techniques, and Procedures”) to circumvent those controls.  Just as “serverless” infrastructure is the new and emerging trend in Information Technology, it is also the new and emerging trend in malware.  By eliminating traditional server infrastructure from malware operations, threat actors can significantly minimize their network footprint and make it harder for security professionals to catch them.  If a hacker doesn’t have a malicious C2 server, it makes it a lot harder to block C2 communications.

Understanding how Serverless RATs Operate

Serverless malware communications involve three (3) main components.  These include:

• The Infected Victim – the system on which the malware is running
• The Abstraction Layer – the public web-service which will inadvertently facilitate the covert C2 communications
• The Attacker – the malicious outsider who has control of the compromised system

Figure 1 – Serverless Malware Communications

Rather than using a C2 server on the public Internet, the attacker can use any web-service which programmatically supports bi-directional (read and write) text communications.  As such, there are a lot of cloud services (which are natively trusted by most businesses) that can be used for this abstraction layer.  Some examples (though not nearly exhaustive) include:

• File and object storage services
• Code sharing and repository services
• Content Delivery Networks (CDNs)
• Relational Database Services (RDS)
• Project management services
• Collaboration services
• Email services
• Personnel support services
• Social networks

Essentially, any cloud service that has a publicly usable API (Application Programming Interface) which allows you to programmatically read and write text data (which is pretty much all of them) can be used as a serverless malware abstraction layer.  For security professionals…this is the stuff of nightmares.  Not only do you have to be on the lookout for malicious infrastructure, but now, even all of your legitimate cloud services are being weaponized against you at the application layer.

In an effort to continue emulating the latest cyber threats for our clients, the Set Solutions penetration testing team has developed multiple serverless malware samples.  Below, we provide a more detailed view of exactly how this malware works, and what you should be looking out for — to defend against it.

Dissecting a Serverless RAT (the technical specifics)

As discussed above, the serverless malware we created leverages an abstraction layer as an intermediary means of communication between the attacker and the malware (such that the attacker is never directly interacting with the infected host).  Instead, both the attacker and the infected system manipulate a text value hosted by the abstraction layer web service, in order to support the ongoing C2 operations.

In our malware samples, this text value is a JavaScript Object Notation (JSON) representation of the session state.  The JSON object has three (3) keys:

1. Command Queue – By default, the value of this key is set to null. If a command is supplied by the threat actor, this value is updated to a base64 encoded string of the supplied command (base64 encoding is used to avoid any potentially problematic characters that might impact the malware code execution).
2. Response – By default, the value of this key is set to null. If the malware observes that a command is queued, it will execute the command and then update the Response key value to the base64 encoded standard output (stdout) response.
3. Beacon – The value for this key is a datetime string and is updated (to the current time) each time the infected system interacts with the abstraction layer. The beacon is used to distinguish active from inactive C2 sessions.

When a system is infected with this malware, it will beacon out (at a defined interval) to the abstraction layer to collect commands, execute those commands, and then update the response.  And the attacker will execute ad hoc connections to the abstraction layer when commands need to be executed on the infected system(s).  Notice that at no point in this process, does the malware ever interact directly with untrusted hacker infrastructure.

As such, we essentially have two separate communication processes –

1. The communications between the infected system and the abstraction layer, and
2. The communications between the attacker and the abstraction layer

Consider the below visualizations for each of those communication processes:

Figure 2 – Infected system communications with abstraction layer

Upon initial infection, the malware will connect out to the trusted abstraction layer and create the JSON text object which represents the C2 session.  After that, the malware will continue to beacon out at a defined interval (in most of our samples, we used 3 seconds) to determine if any instructions have been provided to the Command Queue.  Once instructions are available, the malware will execute the supplied command, reset the Command Queue value to null, and update the Response value. 

Figure 3 – Attacker communications with the abstraction layer

To execute commands on the infected system(s), the attacker will then independently interact with the same abstraction layer web service.  It will load the supplied command (base64 encoded) to the same JSON session object that is being updated by the infected victim.   It will then continue to review the JSON session object until a response is returned from the infected system for the supplied command.  By using a CLI (“Command Line Interface”) client to manage these interactions, an attacker can then support centrally orchestrated C2 operations for multiple compromised systems simultaneously.  For our controller client, we used Python 3 in conjunction with the cmd library to create an interactive CLI, and to emulate the traditional “remote shell” C2 operations that are present in most exploitation frameworks.

Defensive Considerations

While this is a uniquely difficult threat to combat, there are some steps that can be taken to increase visibility and minimize the threat.  These include:

• Endpoint Protection – Serverless malware minimizes the exposure of malicious activities over-the-wire. But it still requires malware.  So effective host-based protections (Antivirus, Next Generation Malware Protection, Endpoint Detection & Response, File Sandboxing, etc.) provide important compensating control(s).
• Zero Trust – Don’t assume any communications (regardless of where it’s going) are inherently benign. Most legitimate services can also be abused as a covert channel for C2 communications.
• Inspection and Correlation – To provide better visibility into misuse of trusted cloud services, you should be logging all web communications. SSL/TLS termination should be used to inspect the contents of otherwise encrypted communications.  These contents should be correlated against other log activity and should be reviewed for common system-level commands and/or responses.
• Attack Emulation – Consider orchestrating targeted security assessments wherein emerging attack patterns (such as serverless malware) are emulated within your network environment, to evaluate the effectiveness of your preventative and detective controls.

Summing it up…

In an effort to circumvent cybersecurity controls that detect and prevent C2 server operations, malware developers are now dropping the C2 server from the equation, and instead favoring a new serverless model.  These types of malware are particularly dangerous because they leverage trusted web services as a covert channel to proxy C2 communications.  To overcome this emerging threat, cybersecurity professionals need to stop evaluating the threat landscape in terms of “trusted” and “untrusted” infrastructure, and instead acknowledge that C2 communications might be hiding right in plain sight…inside those seemingly benign cloud service communications which are often overlooked or dismissed by SOC analysts.

If you have questions about these risks or your organization’s exposure to serverless malware, please reach out to us or contact your Set Solutions Account Manager.

***

This blog was written by Justin Hutchens, Consulting Services Practice Lead at Set Solutions.