How BIG-IP can help secure your network against malware (Maze and Cloud Snooper)

In the F5 SIRT and F5 Support, we are often asked how F5 products can be used to defend against threats like ransomware, malware and rootkits.

Threats like these can enter a target network through a multitude of vectors specific to the target endpoints – email spam campaigns, phishing and spear-phishing attacks, drive-by download vulnerabilities – but they can also enter the network through direct compromise of internet facing hosts.

It’s tempting to look at F5 products and think they aren’t designed to detect a malicious binary being injected into your network, and while (with the exception of ICAP virus scanning of files uploaded to a webserver) that might be true, it is definitely not true to think that F5 products can’t be used as part of a defence-in-depth strategy to protect yourself from both compromise and post compromise exploitation.

So let’s talk about a few ways you can bolster your network security using F5 products…

The BIG-IP itself

The first step is to understand that the BIG-IP is usually found sitting at the border of your network, therefore it is crucially important to protect the BIG-IP from compromise. If the BIG-IP is compromised then it doesn’t matter how good your Advanced WAF policies are or your AFM rulesets, the attacker has a neat jump-box which they can use to pivot into the rest of your network.

Fortunately, protecting yourself against exploit here is as simple as following a few basic principles:

• Don’t expose the management interface to the Internet (if at all possible)
• Ensure Self IP addresses have appropriate Port Lockdown settings
• Use strong passwords and definitely don’t leave the passwords at their defaults (fortunately, changing the passwords at installation is now mandated in recent versions)
• Monitor log files for suspicious activity (like unexpected logins)

If you absolutely must expose the management interface to the internet, be sure to set appropriate ACLs to restrict access to specific IP ranges.

All of which is documented in our Ask F5 article K13092

Protecting your (other) assets

Now that you’ve got the BIG-IP sorted, you can turn your attention to how the BIG-IP(s) in your infrastructure can help protect your internal assets.

As we discussed earlier malware can enter your network in a number of different ways, and a BIG-IP can help secure a number of those:

• Ensuring that your assets can only be accessed via the BIG-IP on ports you control immediately ensures you aren’t accidentally exposing SSH on your webserver, ruling out the possibility of an attacker simply brute-forcing credentials and uploading malware directly.
• The BIG-IP is (usually!) a full proxy right down to Layer 4, so any exploits or C2 channels that rely on quirks of TCP or utilise unusual header fields to transfer data will fail when the BIG-IP proxies and applies its own optimisations to the server-side flows
• Placing Advanced WAF in front of your internet-facing web services, configured with an appropriate policy, significantly reduces the possibility of an attacker exploiting a weakness in your web applications to upload a malicious payload (such as SQL Injection or shell command injection)
• The AFM IPS (in AFM 13.1.0 and later with an IPS subscription license) allows you to scan non-HTTP traffic for potentially malicious activity and take action
• BIG-IP APM allows you to secure access to potentially vulnerable protocols like RDP, better still, APM layered with Advanced WAF allows you to protect your VPN and secure endpoints against brute force attacks

Of course, it is true to say that BIG-IP products are not best placed to stop a user from clicking on a malicious link in an email, but the points above at least help close some of the vectors that malware can enter your network!

But, don’t stop there. I’m sure that as part of your day to day, you are on the look-out for IOCs to watch for that might indicate a problem within your network?

If you are inspecting your outbound traffic (with BIG-IP AFM or SSLO) then it’s a snap to add rules to those products that will alert you and/or block outbound C2 communication attempts from compromised clients!

A practical example – Cloud Snooper

Cloud Snooper first appeared in the news in February 2020 billed as “malware that sneaks into your Linux servers”. Reading the Sophos white-paper (links to a non-F5 resource) it becomes clear that the researchers aren’t sure what the original infection vector is here; they know that the key marker is a specific rootkit present on the hosts, but not how that rootkit got there in the first place.

Since there isn’t a specific initial infection vector, like most malware, we know that we need to think about everything from the previous two sections:

1. Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers
2. Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application

The white-paper tells us that the rootkit dropped initially is a local command-and-control system rather than the ultimate exploit; its job is to receive incoming C2 messages and arbitrate between those and malware subsequently installed.

It does that by sniffing all of the network traffic arriving at the compromised host and inspecting the TCP source port of every incoming packet. If the source port of the packet matches one of the ‘magic’ numbers hard-coded in the rootkit then it is treated as a command, otherwise it is simply ignored, and the host processes it as normal. So we've a third item to add to our list above:

• Pass inbound traffic through the BIG-IP in order to block incoming C2 messages destined for the rootkit on any potentially compromised or at-risk host

Good news! With even the default configuration in place there’s a good chance that the BIG-IP won’t preserve the TCP source port between the client side and the server side, especially on a system passing a reasonable amount of traffic. But you can go one step further – simply change the “Source Port” option on the Virtual Server from “Preserve” to “Change” and the BIG-IP will always try to change the source port! The C2 messages might arrive at the Virtual Server, but by the time they leave and head to the pool member they’ll be on a new port and the rootkit will completely ignore them.

Want to go one step further and ensure that C2 traffic never reaches the server at all? BIG-IP AFM has you covered; just create a Network Firewall rule to deny all traffic with a source port of 1010, 2020, 6060, 7070, 8080 or 9999, assign the rule to a Rule List, assign the Rule List to a Network Firewall Policy and then assign that Network Firewall policy to any Virtual Servers you’re concerned about or even to all traffic passing through the BIG-IP. As the original white-paper notes, regular clients don’t normally use source ports below 32768 so legitimate traffic shouldn’t be affected – but simply by assigning a logging profile with Network Firewall logging enabled will let you see what’s being denied by the rule.

See the following chapters in the manual (BIG-IP Network Firewall: Policies and Implementations) for your version for more information:

Configuring BIG-IP Network Firewall Policies

Local Logging with the Network Firewall

If you don’t have AFM, we’ve still got you covered. A simple iRule attached to a Virtual Server provides a simple way to block incoming Cloud Snooper C2 communications:

when CLIENT_ACCEPTED {
 switch -- [TCP::client_port] {
   1010 -
   2020 -
   6060 -
   7070 -
   8080 -
   9999 {
     # Uncomment the following to log locally, which should be used for debugging purposes only
     # log local0. "Reject possible Cloud Snooper C2 message from [IP::client_addr] with source port [TCP::client_port]"
     reject
   }
   default {
     # Not a Cloud Snooper C2 connection, continue as normal
   }
 }
}

 

Of course, an iRule doesn’t come with the many advantages of AFM's Network Firewall Policies – it’s more computationally expensive, there isn’t simple access to remote logging compatible with leading SIEM systems, and it isn’t as easily administered if needs change. But, still, it’s there and it’s an excellent option – the F5 SIRT makes regular use of iRules in order to stop the bleeding and get customers back up and running in a pinch!

Cloud Snooper Conclusion

In brief, to protect against Cloud Snooper:

1. Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers
2. Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application
3. Pass inbound traffic through the BIG-IP in order to block incoming C2 messages destined for the rootkit on any potentially compromised or at-risk host, setting the "Source Port" option to "Change" on the appropriate Virtual Server or use a Network Firewall ruleset or iRule to block incoming connections with a TCP source port of 1010, 2020, 6060, 7070, 8080 or 9999

Example 2 – Maze

The Maze ransomware has been in the news regularly since January 2020 and shares a lot of traits with previously identified ransomware – infection is likely to be through vectors such as phishing, brute force access to network infrastructure like RDP or compromising internet-facing hosts.

One thing that is new (but not unique) with Maze is what it does with the data once it’s in; it doesn’t just encrypt files, it syphons them off, so the target is not only being coerced into paying to regain access to their data, but also to avoid their data being exposed on the internet.

So, everything we discussed in the previous sections applies equally well to Maze as Cloud Snooper or any other malware infection, with the only difference being we aren't looking for inbound C2 messages but rather outbound data exfiltration:

1. Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers
2. Protect servers by placing them behind the BIG-IP and passing outbound traffic through inspection (AFM, SSLO)
3. Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application

It’s currently thought that Maze exfiltrates this data en-masse via outbound FTP connections, so protecting against that threat using F5 products is as simple as passing your outbound traffic through a Virtual Server and using Network Firewall policies or iRules to block all outbound FTP or to block or alert on outbound traffic destined to one of the published IOC IP addresses for Maze.

Maze Conclusion

In brief, to protect against Maze:

1. Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers
2. Protect servers by placing them behind the BIG-IP and passing outbound traffic through inspection (AFM, SSLO), blocking outbound FTP connections from any sensitive hosts to prevent Maze from exfiltrating data
3. Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application

Conclusion

Admit it, you skipped right down to this section, didn’t you? It’s OK – we are all busy people, I understand!

Here’s my five-bullet BIG-IP takeaway:

• Ensure you secure your BIG-IP first; failure to do so renders anything else you do moot. Follow the steps in K13092!
• Simply placing your servers behind a BIG-IP makes many attacks significantly harder to pull off, by virtue of the BIG-IPs full-proxy architecture
• If it serves HTTP, put Advanced WAF in front of it
• Put AFM in front of everything, including your internal clients accessing the internet!
• If you can’t use one of the products, iRules are your friend and can help you stop inbound and outbound threats

And, finally, my general advice five-bullet takeaway – things that apply equally to F5 products and general-purpose computing:

• Never expose the management interface of anything directly to the internet; if you must, use ACLs to restrict access
• Visibility is king; you need visibility of traffic in and out of your network to watch for IOCs. If you can’t use F5 products (Advanced WAF, AFM and SSLO have excellent reporting capabilities) then use something and pipe all that data into an SIEM
• Patch in a timely manner
• Don’t use weak, insecure or previously leaked passwords
• Did I mention never exposing the management interface to the internet yet?

Those ten things, the first five of which are covered in more detail in the article above, will go a long way to ensuring the security of your network and your assets. Of course, the BIG-IP and good security practices can't obviate the need for good endpoint security, MFA for your users and so on, but you'll at least have squashed a significant amount of attack surface.