What is HTML Field Obfuscation?
And why do you need to know, anyway? I am so glad you asked! A great deal of app security focuses on the server-side component. Whether comprised of multiple microservices fronted by an API or a monolith, there is no question that a significant source of breaches occurs at the app. This is due to vulnerabilities in the platform, app frameworks (think Spring, Express, or Struts) or application code itself. Many of these apps still present a traditional HTML interface. Even if it’s using Angular or Bootstrap or some other JavaScript framework to create the real-time, interactive experience users crave, it still relies on good old HTML to solicit input from users. Many client-side attacks count on this, and exploit the markup language to great success. Interestingly, F5 Labs research found in its analysis of breaches over the past decade that 86% of the time, apps and identities were the initial target. When most folks hear “identities” it conjures up images of LDAP or ADS or perhaps more modern methods like OAuth. The reality is that before any of that comes into play, first the actual data that comprises an identity – username and password – must be collected. To do that, developers use an HTML element called “input”. The tag “input” is what tells the browser to render a text box so you can enter your credentials. To help keep passwords hidden from prying eyes (that guy reading over your shoulder right now), HTML includes the ability to further specify the type of input you’re looking for. By declaring an “input” element of type “password”, you get some default behavior that automagically masks entered characters. In raw HTML, it looks like this: input type=password name=credential_part_two> Now, that’s cool and all, but attackers know this. MItB (Man In the Browser) attacks inject scripts (or exploit other browser and HTML behaviors) to attach themselves to these fields and slurp up the credentials as users type them in. That’s obviously a Very Bad Thing™ that we want to prevent. Anti-fraud application services are designed to prevent scripts or browser extensions from successfully stealing credentials in this way. To do that, they can use a technique known as HTML Field Obfuscation (HFO). To understand how it works, first you have to see how an exchange normally works. The user requests the login page, and as part of the response, a form is returned containing the elements needed to collect credentials. You can see they are clearly labeled and easily identifiable. Before you get all angrified at developers, remember that a significant concern – especially in the enterprise – is the sustainability of software. That means it has to be clear and written in such a way that when the next wet-behind-the-ears developer is handed the application, they can follow the code and its logic and modify and/or maintain it. We are conditioned not to obfuscate variables precisely because it makes code difficult to follow and more complex than it already is. So please, try not to punch the next developer you see because of this. They’re just following coding standards. Now, obviously the naming and use of HTML types to identify credentials can make it extremely easy for malicious scripts, extensions, etc… to find exactly what they desire most: the credentials. So what we need to do is obfuscate the fields before it reaches the client, and hopefully prevent scanners, skimmers, and loggers from being able to figure out where the credentials are. We do this by inserting an anti-fraud application service into the mix. Essentially, it’s going to act as a proxy to mediate exchanges between the client and the target application and do some magic on the data to obfuscate field names. This is intended to confuse and frustrate attempts to leech off credentials. The request is made exactly the same, and passed on to the application. On the response, the anti-fraud application service quietly replaces specified HTML elements with encrypted versions using a designated private key. It then passes the modified HTML back to the client. The client renders the page as it should and the user sees no difference in the user interface. Only the HTML names have been modified, which only impact client-side scripts and frameworks. The modified page includes a script that ensures that client-side frameworks operate as expected. This technique is designed to confound attacks that rely on identifying target data based on its associated named HTML elements. IT prevents scripts and extensions from latching onto those fields and siphoning off the information. There also exist advanced techniques based on HFO that go beyond just encrypting field values, including the addition of “decoy fields” to distract attackers. No, HFO is not infallible. But it can stop lazy scripts and attacks that rely on easily identifiable field names to extract their digital bounty. HFO allows for frequent, dynamic changes of highly-sensitive form fields without the costs and time associated with modifying the application itself. This maintains the integrity (and sustainability) of the application code whilst providing a layer of protection against attempted theft of sensitive data. Although HFO and related techniques are often tightly associated with protecting financial-related applications, the reality is that all credentials are highly sought-after data today no matter what type of app or service they are for. The credential crisis is real, and so is the need to protect consumers and customers from having their credentials pilfered by malicious actors. Stay safe out there!
Dyre Malware Analysis
Dyre, also known as Dyreza, is a banking Trojan that was first seen around June 2014. With the combination of its ability to steal login credentials by browser hooking and bypassing SSL, its man-in-the-middle (MITM) proxy server, and its Remote Access Trojan (RAT) capabilities, Dyre has become one of the most dangerous banking Trojans. The Dyre Trojan is designed to steal login credentials by grabbing the whole HTTPS POST packet, which contains the login credentials sent to a server during the authentication process, and forwarding it to its own server. The malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup windows, and JavaScript/HTML injections. After all the information has been acquired by the attacker, he can remotely access the victim’s computer using a built-in VNC (Virtual Network Computing) module and perform transactions, data exfiltration, and more. How it works malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup Malware behavior on a Win7-32bit system Surprisingly, the malware behaves differently on Win7-32bit, most likely due to security implementation differences. The method of registering itself as a system service is implemented on WinXP and 64bit systems (tested on Win7-64bit). On Win7-32bit, Dyre operates more similarly to the known Zeus malware by injecting code in the Explorer.exe process and operating from there. Man-In-The-Middle (MITM) Attack When a user enters his bank’s URL in the browser line, the Trojan is triggered and forwards the URL to the corresponding proxy server as stated in its configuration file. · The MITM proxy server forwards requests to the banks and disguises itself as the real user. · The returning response from the bank is intercepted by the proxy server. · Instead of the real response, the user receives a fake login page which is stored on the proxy server, and contains scripts and resources from the real bank’s page. The scripts and resources are stored in folders named after the unique port configured for each bank. · The information entered by the user is sent to the proxy server and then forwarded to the real bank server, allowing the attacker to log in instead of the user and perform operations on his behalf. The fake login page The fake page contains a script called main_new - , which is responsible for handling the objects presented to the user on the fake page and performing the MITM attack. The fake page contains an array of configuration parameters in the header. Some of the more interesting ones are: · ID. The unique identification of the bank, which is the same as the port number in the configuration file. · Incorrect login error. On each login attempt to the bank, the proxy server will forward the request to the real bank’s server and perform the authentication. If the authentication fails, it will also present an error to the user on the fake page. · Block message. If the MITM attack succeeds, the attacker is able to perform a transaction and block the user from accessing his account. This parameter stores the presented message. The F5 Solution Real-time identification of affected users - F5 WebSafe and MobileSafe are able to detect the user is affected by a Trojan and that the information provided by it to the customer is also sent to an unauthorized drop zone. Identification of malicious script injection – once downloaded to the client’s browser, WebSafe and MobileSafe make sure there has been no change to the site’s HTML. If such a change is detected, the customer is notified immediately. Protection against Trojan-generated money transfers - the combination of recognizing affected users, encrypting information, and recognizing malicious scripts is key to disabling Trojans from performing unauthorized actions within the account. WebSafe and MobileSafe detect the automatic attempts and intercept them. Malware research - F5 has a dedicated Trojan and malware R&D team that searches for new threats and new versions of existing ones. The team analyzes the programming techniques and methodologies used to develop the malware in order to keep the F5 line of products up to date and effective against any threat. To get the full technical detailed Malware analysis report click here. To download the executive summary, click here.
CloudBleed: Guess What? There was 0-day protection
About CloudBleed If you aren’t familiar with CloudBleed, take a moment to read the following articlesto get an understanding how it was found, what happened, and what PII/PCI data was (possibly) leaked: Vulnerability Disclosure from Tavis Ormandy (@taviso), a security researcher at Google Incident Response from CloudFlare 3rd party assessment from Ryan Lackey (@octal) In some of the examples shown by Tavis, or by digging into cached sites on less popular search engines, you can see how usernames, passwords, sessions, credit card info, etc could be seen in clear text despite the use of HTTPS (TLS1.2). A simplification of the flow would look like this: Request: Client >=====> CloudFlare >=====> Origin Web Server Response: Client <=====< CloudFlare <=====< Origin Web Server Despite the fact that the client is utilizing HTTPS, CloudFlare has the ability to terminate the secure connection since it has the private key. This is essentially the content (PII or PCI) that was being cached if certain conditions occurred on the CloudFlare reverse proxy. 0-day Protection Against CloudBleed So, what is the 0-day protection and what is it all about? Application Layer Encryption is a feature from F5 that would have left researchers scratching their heads when looking at the cached content. First things first, let’s dynamically encrypt sensitive parameter names using Application Layer Encryption. But really, what does that mean? Let’s take a deeper look. In all examples I will be using Google Chrome. Let’s say you have login pagewithoutApplication Layer Encryption. If I were to right click on the Password box and choose Inspect, I would see something like this: As you can see from the red boxes, the parameters for my username and password arelogandpwd. We can all agree that this is in human readable format (HRF). If I were to do the exact same thingwithApplication Layer Encryption, I would see this: In the screen shot above there are 3things I would like to focus your attention on: Both name=log and name=pwd are no longer in HRF. Notice in the first red box that there is a slight purple hue over the value? That’s the dynamic part of Application Layer Encryption. Every few seconds the valueswill change. This is done on the client side, not the server side. That value will never repeat and is completely unique to the user’s session. We also removed the element IDs, id=”user_login” and id=”user_pass”. With Application Layer Encryption turned on, every user will have a unique value for name=log and name=pwd moving forward. We can also turn upthe security a notch by inserting decoy fields to further confuse the bad guys. Decoy fields are only seen in the raw code and do not change the end users experience. As you can see above, there are additional IDs which makes it very difficult to pull apart in a replay attack. But Brian, what about the values being sent!?!!? Let’s look at a data submissionwithoutApplication Layer Encryption from the browservia the network tools in Chrome: As you can see from the picture above, the username is briandeitch and the password is test. Although this is sent via HTTPS, CloudFlare has the private key and this is the type of data that could have been cached by search engines. Yikes! Same exercise but this timewithApplication Layer Encryption: Decoy fields turned off: Decoy fields turned on: As you can see from the form data, both the parameter names and values have been dynamically encrypted on the client side. Let’s say this data was leaked by CloudFlare and cached by a search engine. Couple of points: These substituted and encrypted values are single use, meaning a replay attack wouldn’t work. Good luck reverse engineering any of this. Application Layer Encryption uses private/public key technology and this key, unlike the private key for the SSL Certificate, isn’t hosted on CloudFlare. This means the payload (form data shown above, you know the values for the username and password) is completely encrypted to CloudFlare (or any other proxy for that matter). In addition, the decoy fields are sent as well. Good luck deciphering which fields are mapped to the actual application(s). Personally, my favorite part ofApplication Layer Encryption is that is requires no change to my back end application. This solution requires no installation or modification to the end users web browser, is 100% client-less, and transparent to the end user. At the end of the day, you can still rely on HTTPS for transport layer security however Application Layer Encryption steps up your overall security posture by using cleverobfuscation andencryption to protect your datawhen there is a proxy (MITM device) between your customers andapplication(s). Lastly,Application Layer Encryption is a feature within F5 WebSafe. F5 has taken a complex security enhancement and created a point and click solution to easily protect your application(s). Configuring Application Layer Encryption Step 1: By creating a profile, specify the URIs you want protected. *Note: You are able to use wildcard URIs as well. Step 2: Add theparameters you want protected. The Encrypt checkbox is how we secure the username and password valuesthat are being sent. By encrypting the values, this will prevent replay attacks as the values can only be used once. TheSubstitute Value checkboxsubstitutes the parameter’s value with a random value in the web application while the form is being filled. This also prevents browser based malware fromcapturing keystrokes as they are being entered. The Obfuscatecheckbox encrypts the parameter’s name attribute. Step 2a: If you would like to insert decoy fields to further mess with the bad guys, you don’t have to be a rocketscientist. Relax, it is just a checkbox. Step 3: Associate the new profile to theapplication. That’s it! You have successfully configured and secured your application with Application Layer Encryption. Special thanks to BAM, Todd Morton, Chad Fazio, Jeffery McFerson, Joe Martin, and Ted Byerly for their contributions on this article.
Mazar Bot Overview
Discovered in early 2016, Mazar Bot is spread by sending SMS text messages, via a URL shortener service. Mazar Bot targetedmultiple banks specifically in the German-Austrian region according to attacks that wereencountered in early July 2017. This malware, seen on Android devices,permits itself to access the following device permissions: From Spam to Infection Mazar Bot is used in spam campaigns to gain access to users within a specific region, much like spear phishing. In many cases, the attack isspread via SMS, fake webpages, or email spam. First the malware tricks the user into clicking the link, and then immediately after, the user will face a login page request designed specifically formobile devices. Once the malware has received the needed login information itdisplays installation info and gives an explanation on how to use and install the upcoming application. At this stage users can still question why they should be downloading another app. In order to hide from this suspicion, a php file named “apk-playstore.php” provides some assistance. Mazar Botexplains to the user how to download and use the app. Prompts the user to press the specific link button Gives screen shots that walk through the installation...this allowsthe device to install the application from unknown sources Runsthe application immediately after installation Infection Chain After the malicious application is installed on the end user device, it asks to activate it as device administrator. In most cases the malicious application icon would be deleted and Command and Control communication will commence immediately afterwards. The ongoing communication between device and server would pull device information and look for specific targeted applications. The second stage of communication grants a user infected device with a unique ID for Database maintenance and support of campaign activity. The moment the user would interact with a legitimate bank application, Mazar Bot will cause an overlay and would display another fake page for harvesting more credentials. Interesting observation: Mazarbot (in each of the phishing campaigns) has created tailor-made applications designed specifically to attack a designated bank/organization. For each targeted application, it also creates a specific subdomain, probably for masking and tricking users which were connected to the fake login site. Strings, the C&C connection The interesting part of the apk containssome specific C&C related strings. These strings give an overview of the malware behavior and abilities that it contained. The combination of strings highly support the claim that fraudsters behind the malware plan each campaign specifically for a bank application per campaign. The features presented in the string represent device control and communication interception, allowing access into device cached memory, grabbing personal data, sending SMS, locking device, putting device into sleep mode, reporting and logging all Input/output actions, maintenance of this configuration is represented by unique ID, given by the server. Accepting Credit Cards Additionally, in the strings section, fraudsters are trying their luck by targeting Google play. The overlay that will popup to the user in mid interaction with Google play or Whatsapp, will ask for: Card number CVC Expiration Month+Year Card holder name Credit card type Phone number First, Last Name Phishing SitesStatistics Researched by Kyle Paris According to attacks we've encountered in early July,there wasn't anydistinctive region target for hacked servers. The interesting patterns we did identifywere compiled from groups of 8-10 phishing links with every attack.Each link main domain was slightlydifferent, either by number or a letter, while the subdomain and subfolder remained the same. Here is a table comparing phishing links groups with theirdomain name: Group 1 Group 2 update9091.pw id78087.pw update9092.pw id78086.pw update9093.pw id78080.pw update9094.pw id78084.pw update9095.pw id78083.pw update9096.pw id78088.pw update9097.pw id78085.pw update9098.pw id78089.pwIs "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.F5 Anti-Fraud Solutions: Frictionless Protection for the Masses
Anti-Fraud Solutions: Why F5? In 2013, F5 Networks grew its security portfolio to include advanced Anti-Fraud services with the acquisition of the Israeli-based security company Versafe. At the RSA Conference in San Francisco this week, we have a section of our F5 booth dedicated to the Anti-Fraud solution where we are talking about the technology, answering questions and demonstrating the capabilities all week. If you cannot make it to the conference or even if you attended but missed us at our booth, that’s not a problem. I’ll fill you in on some of the details. First, just walking around the RSA Conference, it’s clear that there is no shortage of anti-fraud solutions on the market. The number is mind blowing and continuously growing. As new threats emerge, new technologies are introduced to combat them. But if you look at the approaches each company takes, they are often quite different. So that begs the question: why F5? Well, from a feature and function standpoint, we cover a wide range of web-based fraud detection and protection capabilities. The WebSafe solution, which protects web-based applications, safeguards against various forms of malicious activity including phishing attacks, Man-In-The-Middle, Man-In-The-Browser and Trojan activity such as web injections, form hijacking, page modifications and transaction modification. But what makes the solution unique is that it enables 100% coverage of the user base in a completely clientless manner, without impacting the user experience. We inject our obfuscated code via an iRule, into the web application code as part of the response data. In other words, the solution is completely frictionless, which is key differentiator number one. And because the solution leverages common browser-based technologies, we protect users who are navigating from all types of devices: laptops, PCs, tablets, smart TVs, mobile devices, etc. As long as the user is navigating with a standard web browser, they will be protected. This is key differentiator number two. From a deployment standpoint, today the WebSafe solution is implemented via an iRule on an F5 device (either physical or virtual), so there is no need to introduce changes to the web applications our customers are looking to protect from online fraud. This saves time when deploying the solution because there is no need to engage web development resources which are often outsourced or already engaged in critical projects. Our ability to deploy without these web application changes equates to savings and is key value proposition number three. As a matter of fact, many F5 customers can leverage their current F5 investment and deploy the Anti-Fraud services on their existing infrastructure, requiring no additional hardware investment: differentiator number four. Lastly, WebSafe provides protection against online fraud without a client install and with no change in the online users’ experience. Introducing CAPTCHAs, popups, etc is often too intrusive to the end user, so we are looking to protect the users without introducing friction in the process. Summary If you are at the RSA Conference, stop by booth 1801. We would be happy to demonstrate our Anti-Fraud solution and help to enhance your fraud protection capabilities. If you are not at RSA, look for further details here. We will be posting more details about F5’s Anti-Fraud solutions throughout the coming weeks.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.Domain name holders hit with personalized, malware-laden suspension notices
This according to Zeljka Zorz, HNS Managing Editor from Help Net Security. In his article, Zeljka mention that new email spam campaign has been spotted targeting domain name holders, trying to trick them into downloading malware on their systems. The email is likely to fool some recipients, as it contains the valid domain registration and the recipient's full name, which the attackers must have harvested online, via the “whois” query. The sender's email address is also spoofed to make it look like the sender is the domain registrar. Those who get fooled and download and execute the file linked in the email will get saddled with malware - most likely a Trojan downloader, which will then proceed to download additional malware. Below is the spam e-mail that was sent: Subject: [Domain name] Suspension Notice Dear Sir/Madam, The following domain names have been suspended for violation of the Melbourne IT Ltd Abuse Policy: Domain Name: [domain name] Registrar: Melbourne IT Ltd Registrant Name: [Registrant name matching whois] Multiple warnings were sent by Melbourne IT Ltd Spam and Abuse Department to give you an opportunity to address the complaints we have received. We did not receive a reply from you to these email warnings so we then attempted to contact you via telephone. We had no choice but to suspend your domain name when you did not respond to our attempts to contact you. Click here [LINK] and download a copy of complaints we have received. Please contact us by email at mailto:abuse@melbourneit.com.au for additional information regarding this notification. Sincerely, Melbourne IT Ltd Spam and Abuse Department Abuse Department Hotline: 480-124-0101 According to the article, the most targeted registrars are Melbourne IT and Dynadot that already notified their clients of this campaign. In their official notification Dynadot states that “We have recently become aware of fake abuse notifications being sent out to our customers. The abuse messages look like they are being sent from our abuse@dynadot.com email; however, these messages are NOT being sent from us and should be disregarded. If you receive one of these emails or an email that you think may not be from us, do not click on any links, reply directly to the email, or call the number listed in the email". To read Melbourne IT public announcement click here. F5 SOC is familiar with this spam campaign as well with many others that come and go almost every day. This attack vector is very common in the hacktivists communities that using Social Engineering to lure victims into opening links and/or attachments in e-mail messages in order to broader their botnet pools and inititate DDoS attacks, money transfer, identity theft and more. On a day to day basis, F5 mitigates online identity theft by preventing phishing, malware, and pharming attacks in real time with advanced encryption and identification mechanisms enabling financial organizations working online to gain control over areas that were once virtually unreachable and indefensible, and to neutralize local threats found on customers’ personal computers, without requiring the installation of software on the end user side. If you would like to learn more about F5 fraud protection, read the WebSafe datasheet as well as the MobileSafe datasheet. To learn more about F5 Security Operation Centers, read the F5 SOC datasheet. Click here to read the original article by Help Net Security.
Yuck a RAT infestation! How concerned are you?
You’ve gotta hate RATs! They are the most disgusting and opportunistic survivors of all time. RATs dwell amongst us occupying our area of activity, causing great damage, viruses and losses. It may sound as if I am speaking of the wild species Rattus Rattus (the common black rat) that invades and spreads disease, but you know that I am not. Like the animal, Remote Access Trojan (RAT) malware bring about deep concern and anxiety. RATs compromise computers, using back door technology to gain administrative control. This form of malware is intended to gain computer access, redistribute itself, establish a botnet, and do serious damage. The success of RAT usages enables criminals to steal from or wreak havoc on an individual or an entire company. Are you bothered or concerned about RATs too? With RATs ‘cyber thieves’ gain unsuspected control over a victim’s computer to execute malicious exploits. It monitors behavior; accesses confidential information; alters or locks files systems and more. Furthermore, RATs allow cybercriminals to steal valuable information including your identity and even execute fraud. Primarily used to exploit credit cards, personal information and bank accounts, RATs have also become known as a weapon for extortion, where bad actors take valuable files, photos and videos for blackmail or ransom. As you can imagine, tools of this type are extremely dangerous. Bad actors are very focused on efforts to develop, enhance and update under ground software, which is then given away free or sold on the black market to even the most inexperienced hackers for free or as little as $20[1]. Certainly, there are some more advanced RATs that go for $300 or more. According to one Dell report, attackers are always looking for RATS, and willing to pay a premium for those that are easily available and fully undetectable by anti-virus software and antimalware programs. Common RATs we’ve seen today Back Orifice Blackshade PC Invader Beast Heseber BOT AlienSpy Dark Comet Havex KjW0rm Sakula As an essential element of today’s attackers toolset, RATs are most effective in their purpose and totally invisible to the victim. RAT’s can be spread to victims outside of IT/Security control, most often via spam, spear phishing and social engineering attacks. Each victim computer can then be used to infect others computers (or networks), collecting valuable information stored, infiltrating corporate data systems and instrumenting the building of dangerous network of cyber-soldiers. Sound interesting? Generally RATs have capabilities that enable them to open legitimate ports, mimic remote administrative tools commonly used by IT organizations, and employ sophisticated techniques that evade security measures. They are contained inside heavily packed binaries that are dropped in the later stages of the malware’s payload execution, making them the very hard to detect using anti-virus and anti-malware programs. Scary isn’t it. A RAT that has also enabled criminals to permeate your infrastructure could have infected the very computer upon which you are reading this blog post. Where is the challenge with security? So what do you do about RATs? What protective actions should you take? Antivirus software seems to be the popular first choice of defense against all malware types. Although such solutions may detect viruses, many more complex and stealthy crypter forms of malware can escape antivirus scans and sandboxing. Operations or Security may also be a bit challenged at identifying and protecting against remote administrative Trojans before they cause substantial damage. Some organizations lack sufficient security/fraud expertise or a skilled team to conduct ongoing proactive research to discover malware or to thoroughly analyze it. Maintaining visibility into attacks on client-devices is an even greater challenge for many companies and may be a point of contention, as to who is responsible, if it will be dependent upon end-user involvement or if it is even necessary. As you ponder this keep in mind, RATs affect no one specific, but everyone, as the monetization of credentials and information continue to increase in value. Stopping RATs in their tracks To take action and fight off RATs, many leading organizations are turning to technologies adopted by the retail, and financial services industries to protect against online fraud. Such solutions go beyond anti-virus solutions to provide real-time visibility into compromised client-devices and threats targeting customer end-users. These companies do not want to be burdened with managing security for every device, but want to be assured all users are protected. Using JavaScript code injected into each session, fraud detection solutions like WebSafe easily detect the presence of Trojans and specifically identify backdoor connections without client-side install or end-user involvement. Admins are then alerted of the risk and can immediately take action to mitigate any threats. Furthermore, login page form fields can be obfuscated and credentials encrypted while data is still active in the browser. Spyware becomes useless at capturing confidential login information that is not fully protected by SSL. F5 WebSafe is unique from other anti-fraud solutions in its ability to detect RATs and even other notorious malware types like Dyre. Read more about WebSafe to understand how it can be used to protect your organization against employee credential theft. Remember, RATs are everywhere, nesting and growing in numbers. As with any pest infestation it is vitally important to recognize its presence of RATs early, exterminate them and protect your self from any resurgence. Visit F5 Web Fraud Protection Solution page for more information on F5 WebSafe and talk to an F5 rep about today. Feel free to shoot me a line to share your experience with RATs infecting your user-base and the complexity of such you’ve encountered. [1] Article: “Driving in the illegal underground hacking market”, Security Affair December 2014. A recap of the Dell Dell Secure Works Counter Threat Unit (CTU) published a new report on the evolution of the hacking underground marketplaces.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
