Of Ransom and Redemption: The 2021 Application Protection Report
The information security professional’s mission has gradually become extraordinarily complex. At times, this mission borders on contradiction. Quite often, responsibility for the various components that form an enterprise environment is spread not only among multiple teams within the enterprise but also among vendors, partners, and service providers. In this 2021 Application Protection Report by F5 Labs, Sander, Ray, Shahnawaz, and Malcom look at the breaches in the past year as a series of attacker techniques, explore the outcomes, and provide some recommendations for controls you can implement in your environment. Some Highlights Two-thirds of API incidents in 2020 were attributable to either no authentication, no authorization, or failed authentication and authorization. In 2020, four sectors—finance/insurance, education, health care, and professional/technical services—experienced a greater number of breaches than retail (the leader in 2018 and 2019), partly driven by the growth in ransomware. The most important controls are privileged account management, network segmentation, restricting web-based content, data backup, and exploit protection (i.e., WAF). DevCentral Connects featuring Sander Vinberg Or, if you prefer, listen to Jason & John talk to Sander, directly, on DevCentral Connects.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: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers 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: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers 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 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: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers Protect servers by placing them behind the BIG-IP and passing outbound traffic through inspection (AFM, SSLO) 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: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers 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 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.How Malware Evades Detection
Malware loves encryption since it can sneak around undetected. F5Labs 2018 Phishing & Fraud Report explains how malware tricks users and evades detection. With the cloning of legitimate emails from well-known companies, the quality of phishing emails is improving and fooling more unsuspecting victims. Attackers disguise the malware installed during phishing attacks from traditional traffic inspection devices by phoning home to encrypted sites. Let's light up how evasion happens & get your F5 Labs 2018 Phishing & Fraud Report today. psF5 Labs 2018 Phishing & Fraud Report
The F5 Labs 2018 Phishing & Fraud Report is out! In this report, the F5 Labs team specifically investigated the rise of phishing and fraud during the 'holiday shopping season,' beginning in October and continuing through January. Fraud and phishing attempts increase 50% right now, from October to January and phishing was the root cause of 48% of the data breaches that F5Labs investigated. It's important to check out the report because it explains how phishing works, how to defend yourself against phishing attacks and the importance of training employees to recognize malicious emails. Some of the crazy stats they found include 93% of phishing domains offered a secure (https) version of the site to appear more legitimate and 68% of malware sites used encryption certificates (https), meaning 68% of Command & Control servers use port 443. The crooks are going through the trouble of getting SSL certificates for their fake, but real looking sites. Take a look at some of these. Do any of these web logins look familiar? How about this one? Or maybe this one? If so then you need to check out the 2018 Phishing and Fraud report from F5 Labs because they were all fake. Attackers are getting so good at creating fake websites that impersonate the real thing, most people can’t tell the difference. One thing is for certain, employee click-through rates on phishing emails drop from 33% to 13% with security awareness training: 33% — 1-5 training events 28% — 6-10 training events 13% — 11 or more training events You can check out the Preview Video here and get your report at https://www.f5.com/labs ps
AppSec Made Easy: Credential Protection
Learn how to use the F5 Advanced Web Application Firewall to protect your credentials. Identities are the keys to our applications and criminals can steal them right from the browser. DataSafe protects the credentials at the most vulnerable point. See the entire AppSec Made Easy series.Lightboard Lessons: What is DDoS?
Over the last quarter, there were approximately 500 DDoS attacks daily around the world with some lasting as long as 300 hours. In this Lightboard Lesson I light up some #basics about DoS and DDoS attacks. ps Related: DDoS attacks in Q2 2017 DDoS attack - Distributed Denial of Service DDoS Attacks 101: Types, targets, and motivations Getting Started with BIG-IP Application Security Manager (ASM) Getting Started with BIG-IP Advanced Firewall Manager (AFM) Securing Apps with F5 Solutions Configuring BIG-IP Application Security Manager (ASM) Configuring BIG-IP Advanced Firewall Manager (AFM)Lightboard Lessons: What are Bots?
Humans account forless than 50% of internet trafficand the rest is spread between the good bots and bad ones. In this Lightboard Lesson, I light up some #basics about internet bots and botnets. ps Related: The Facts about Botnets The state of botnets in late 2015 and early 2016 What are bots? Configuring BIG-IP Application Security Manager (ASM)Encrypted malware vs. F5's full proxy architecture
Everyone knows that malware is a huge problem, and several recent studies (including one by our very own F5 Labs research center) have shown that nearly half of all malware is now encrypted. So, if all this malware is encrypted, then how do you go about finding it and stopping it if you can't even read it? This problem is critical to the security of web applications today and will be even more critical in the future as encrypted Internet traffic becomes more pervasive. There are two basic scenarios in which to categorize this situation: 1) inbound encrypted malware, and 2) outbound encrypted malware. What I'm calling "inbound" encrypted malware is when an attacker sends malicious traffic to your webserver in order to infect the server and/or a user accessing that server. The "outbound" encrypted malware is when a user in your organization visits an infected website and ultimately infects his/her computer with the malware from that infected site. Admittedly, the "outbound" encrypted malware situation is a huge problem and needs to be addressed, but for the purposes of this article, we will look at the "inbound" malware problem. When you configure a secure webserver (one that uses encryption), you have to generate and store the keys that are used for encryption. Those keys can be stored on the webserver itself, or they can be stored on a separate proxy device. Many organizations choose to use a proxy device because it is typically custom-built to handle cryptography operations much faster than standard webservers. This "handing off" of the crypto keys is called SSL offload. F5's BIG-IP is the best in the business at this. I won't go into all the marketing chatter about it, but suffice it to say, the BIG-IP is really, really good and fast at this. The SSL offload not only provides a faster encryption experience, but it also allows for a strategic point of control over your web traffic. The F5 BIG-IP also employs a full proxy architecture that allows full visibility of every single request to your web applications. When a user sends an HTTP request to your web application, the BIG-IP accepts that request on behalf of your webserver (in fact, the end user thinks he is talking directly to the webserver but he's really talking to the BIG-IP) and then tears down the request from layer 7 all the way down to layer 1 and then rebuilds the connection from layer 1 all the way back up to layer 7 before sending it on to the backend webserver. This is called a "full proxy" architecture because it establishes two completely independent connections...one with the client and one with the backend server. The reason this is important is that it allows the BIG-IP to inspect every single part of that request at every single layer to make sure it is legitimate traffic. If it's malware, the BIG-IP can reject it before it ever gets to the webserver. Check out the following diagram that shows the flow of the full proxy architecture: The full proxy allows for many other cool things as well (like using iRules to modify traffic in realtime at wire speed), but for the purposes of this discussion, it allows for the complete inspection of your traffic to ensure malware never reaches your webservers. By offloading SSL/TLS encryption onto the BIG-IP, you move the encryption point away from your webservers and onto the BIG-IP. From a BIG-IP configuration standpoint, you do this via the SSL profile where you actually load the encryption keys, certificates, etc. You can actually have one unique profile for the client-side connection and another, separate one for the server-side connection. This is cool as well because you can use two totally different encryption strengths, keys, etc for each side of the connection. Because the BIG-IP holds the encryption keys, it will decrypt all the web traffic and then have the ability to inspect the clear text traffic. Prior to decryption, there would be no way to feasibly inspect the traffic. When you offload all your SSL/TLS traffic onto the BIG-IP and let it inspect each request at every layer, you can free up your webservers to do what they do best...serve up those amazing web applications that we all love! Also, when an attacker sends encrypted malware to your webservers, the BIG-IP will decrypt it and stop it before it ever reaches your servers. Related Resources: SSL Ciphers Supported on BIG-IP SSL Profiles on BIG-IP (10-part article series)
Achtung! TrickBot!
TrickBot does not rest. Following the recent addition of its first targeted US-based bank, a new version of the malware has been spotted in the wild. Now in its 11th incarnation, TrickBot has expanded its ever growing target portfolio yet again – this time increasing its focus on Germany. Figure 1 – TrickBot configuration, showing its most recent version upgrade While previously TrickBot’s focus in Germany was distinctly on Sparkassen Finanzgruppe, this latest version now includes more previously untargeted financial institutions in Germany. Figures 2-7 – TrickBot Dynamic Webinject configuration snippets showing some of its recently added targets in Germany TrickBot continues to evolve rapidly, constantly adding targets and using varying techniques to pose an ever increasing risk to online banking users and financial institutions in multiple regions across the globe. Recent TrickBot malware sample MD5s: c044f4a710f3a0b1997a4470145677ea, 07df1af1c3b8c33df61ff4f3f07f3f54 VirusTotal links: https://www.virustotal.com/en/file/f560268063ab5a2104482937212f75714a55da680d50efe4c20b1a80b29a6e8f/analysis/ https://www.virustotal.com/en/file/05389e4a60b59cb6b4d4ebe959837441b4fbbb71dd17cac77778d8973b480a26/analysis/ Analysis links: https://www.hybrid-analysis.com/sample/05389e4a60b59cb6b4d4ebe959837441b4fbbb71dd17cac77778d8973b480a26?environmentId=100 https://www.hybrid-analysis.com/sample/f560268063ab5a2104482937212f75714a55da680d50efe4c20b1a80b29a6e8f?environmentId=100 References: TrickBot targets its first US bank - https://devcentral.f5.com/s/articles/malware/trickbot-targets-its-first-us-bank-24713 TrickBot targeting Sparkassen Finanzgruppe - https://f5.com/labs/articles/threat-intelligence/malware/trickbot-now-targeting-german-banking-group-sparkassen-finanzgruppe-24420 Review of TrickBots rapid evolution - https://devcentral.f5.com/s/articles/malware/is-xmaker-the-new-trickloader-24372TrickBot targets its first US bank
The latest arrival to the banking malware scene, and successor to the infamous Dyre Trojan continues to evolve. TrickBot previously targeted banks and businesses in Australia, New Zealand, Germany, UK, Ireland, Canada, India and Singapore. In a recent update, this list has now expanded to include The United States. Figure 1 – Map showing TrickBot’s global target distribution Figure 2 – TrickBot configuration snippet showing newly added US based target. TrickBot’s target tally now includes a total of 225 unique banking and business related URLs. While this is still a far cry from vast numbers of banks and businesses targeted by Dyre globally, this number is very likely to grow in the future as the malware’s authors are constantly increasing their target tally and continue to improve their malware with new features and abilities. A previous review of TrickBot’s rapid evolution can be found here: https://devcentral.f5.com/s/articles/malware/is-xmaker-the-new-trickloader-24372 TrickBot sample MD5: 5abea77ce54fc029151a524ff1d428f VirusTotal link: https://www.virustotal.com/en/file/554132df407db525382baceb43fc0804839592fbd7038ffcd0e3736119d37be2/analysis/ Analysis link: https://www.hybrid-analysis.com/sample/554132df407db525382baceb43fc0804839592fbd7038ffcd0e3736119d37be2?environmentId=100
