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. 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=100Is "Xmaker" the new “TrickLoader”?
Overview During November of 2015, the Dyre banking Trojan, which was very prolific at the time and targeted countless financial institutions worldwide, vanished from the wild almost overnight. It was only during February of 2016 that the announcement was made that Russian authorities had arrested most of the gang that was operating the Dyre banking Trojan. (Reference: http://www.reuters.com/article/us-cybercrime-russia-dyre-exclusive-idUSKCN0VE2QS) Since then, nothing was heard from the actors behind Dyre, but it has been speculated that members of the Dyre gang which managed to avoid arrest by the Russian authorities have been integrated into other cybercrime gangs. During September of 2016 a new breed Malware has surfaced, calling itself “TrickBot”, which shares some similarities with Dyre. Among these similarities are a similar loader, similar encryption and decryption routines, and similar structure of the configuration files. (Reference: http://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html) However, it is lacking Dyre’s extensive Command and Control infrastructure, it’s also missing some of the modules that were present in Dyre such as SOCKS and VNC, and the coding style looks different from Dyre’s. TrickBot still appears to be a work-in-progress, doing little to hide its presence on an infected system. One interesting fact is that trickbot’s requests to its C2 servers contain easily identifiable User-Agent strings such as “TrickLoader” and “BotLoader”: (Example: https://www.reverse.it/sample/2c4eab037c37b55780cce28e48d930faa60879045208ae4b64631bb7a2f4cb2a?lang=en#http-traffic ) TrickBot’s Configuration and capability changes During the past few months trickbot is evolving rapidly add constantly adding capabilities, targeted entities, and upgrading its version number. Version 1000002: Initial samples of trickbot started to surface in Virus Total at around august 2016: Related md5s: · 38503c00be6b7f7eeb5076c0bd071b4c · bf621ef7e98047fea8c221e17c1837b8 · 0804499dba4090c439e580f5693660e0 · e4a8dc8fd08d4f65a68d0a40e2190c70 On the 15 th of October 2016, Fidelis Threat Researcher Jason Reaves publishes an analysis of the new trickbot malware. The analyzed sample was shown to be version 1000002: http://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html this version included the following “modules”: · systeminfo – responsible for grabbing system data · injectDll32 – responsible for browser injections The only method of injection in this version was “dynamic injects” which was implemented in a very similar to Dyre’s dynamic (“server side”) injects - https://devcentral.f5.com/s/articles/dyre-presents-server-side-web-injects Version 1000003: On the 24 th of October 2016, Independent Researcher @hasherezade published a detailed analysis of the trickbot malware which has advanced it's configuration to version 1000003: https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/ On the 25 th of October 2016, ASERT analysts publish insights regarding the methodologies used to initially distribute TrickBot: https://www.arbornetworks.com/blog/asert/trickbot-banker-insights/ Version 1000005: On the 7 th of November 2016, F5 Researchers Julia Karpin, Shaul Vilkomir-Preisman, and Anna Dorfman report updates to trickbot, which advanced to version 1000005: https://f5.com/about-us/news/articles/little-trickbot-growing-up-new-campaign-22790 The new version added new targeted entities, modified the configuration structure, and added a new method of browsers injections - static injects (AKA "redirects") which again, is very similar to Dyre’s static injects. Version 1000007: Version 1000007 of trickbot expanded its target list a bit more as described here: https://f5.com/about-us/news/articles/trickbot-now-targeting-german-banking-group-sparkassen-finanzgruppe-23630 Version 1000009: On the 30 th of November 2016, Version 1000009 of trickbot adds a new "mailsearcher" module: This new module has its own configuration settings: And its own C2 server IP address: The main functionality of the mailsearcher module is: · Traversal over all files in all drives in the system · Comparing their file extensions to the following list: · Creating an http connection with the user agent “KEFIR!” · Sending information over that connection in the following URL format: IP-ADDRESS/GROUP-ID/CLIENT-ID/send/ (client-id information was stripped out in this screenshot) Additionally, it changed its User-Agent header from "TrickLoader" and “BotLoader” to "Xmaker": (client-id information was stripped out in this screenshot) Another example of the changed User-Agent header can be seen here: (Example: https://www.hybrid-analysis.com/sample/3bf7d98b2fede6512fa2f5d5423a3e3b93a2ed357d2112bcadde751765bdb505?environmentId=100&lang=en#http-traffic ) On the 5 th of December 2016, Version 1000009 of trickbot adds a few more targets to its static inject ("redirects") targeted entity list. Shifting from the initial focus on dynamic injections to redirect attacks. This is an interesting shift, as the Dyre Malware had the opposite shift while it was active (it first introduced static injections and only after it shifted to dynamic injections) Related md5s: · 46ffaa075dd586a6f93a4d26a2431355 · 1c8ea23e2892c4c7155c9f976c6e661d · 26992865a2ae96ed48df8ddfc7223a13 Version 1000010: On the 6 th of December 2016, Version 1000010 of TrickBot several more previously untargeted banks in Australia and New Zealand, as well as several Singapore banks to target list – which were not previously targeted at all. This version also adds an Indian bank to the target list – again, previously not targeted at all. Related md5: · 52cab07e1a41e68bd2793a37ba04d270 Conclusion TrickBot is an example of a malware which is currently in an active development mode, and is constantly changing and adding capabilities. Its Authors are clearly trying to replicate Dyre’s capabilities and structure. We suggest to keep a close eye on its evolvements and prepare ourselves to the threats that is may pose to the security of our users.Lock Down Your Login
Last week we talked about WebSafe and how it can help protect against phishing attacks with a little piece of code. This is important since malware can steal credentials from every visited web application from an infected machine. This time we’re going to look at how to protect against credential grabbing on a BIG-IP APM login page with WebSafe encryption layer. You’ll need two modules for this, BIG-IP APM and of course, WebSafe Fraud Protection Service. The goal is to protect the laptop from any malware that grabs sensitive login credentials. In this case, the malware would be configured to grab the login page along with the username and password parameter fields. Command and control could also be set to retrieve any credentials from the infected machine at certain intervals, like every 5 minutes. The first goal would be to encrypt the password. Within your BIG-IP admin GUI, you would navigate to Security>Fraud Protection Service> Anti-Fraud Profiles>URL List. APM’s logon page usually ends with ‘/my.policy’. Create then click that URL to open the configuration page and enable Application Layer Encryption. And select the Parameters tab to configure the fields you want to protect. In this case it is password and username. In the screen grab, you can see ‘Obfuscate’ is selected and to both ‘Encrypt’ and ‘Substitute Value’ for the password field. Now when the user goes to the page, a bit a JavaScript is injected in the page to protect the specified fields. If you run a httpwatch or wire shark on the page, you’ll see that the values for those parameters are obfuscated. This makes it incredibly difficult for the bad actor to determine the correct value. And if the malware also grabs the password, since we set that to encrypt, all they get is useless information. At this point, the BIG-IP will decrypt the password and pass on the traffic to appropriate domain controller for verification. This is a great way to protect your login credentials with BIG-IP. If you’d like to see a demonstration of this, check out F5’s Security Specialist Matthieu Dierick’s demo video. Pretty cool. ps
