Gallia is an extendable pentesting framework with the focus on the automotive domain. The scope of gallia is conducting penetration tests from a single ECU up to whole cars, with the main focus on the UDS interface. Taking advantage of this modular design, the logging and archiving functionality was developed separately. Acting as a generic interface, the logging functionality implements reproducible tests and enables post-processing analyzer tasks. The rendered documentation is available via Github Pages.
Keep in mind that this project is intended for research and development usage only! Inappropriate usage might cause irreversible damage to the device under test. We do not take any responsibility for damage caused by the usage of this tool.
This work was partly funded by the German Federal Ministry of Education and Research (BMBF) as part of the SecForCARs project (grant no. 16KIS0790). A short presentation and demo video is available at this page.
ThePetitPotam vulnerability, combined withAD-CS relay, is one of the recent severe NTLM relay variations the CrowdStrike Identity Protection research team have seen, which indicates its high popularity. While the latest Microsoft security update — released on Patch Tuesday, May 10, 2022 — included a patch for the aforementioned vulnerability, it does not fully mitigate the issue. It does, however, change the requirements from being able to run the attack unauthenticated, to requiring any Active Directory account credentials to trigger the attack.
In this blog, we detail the fix, the remaining issues and an enhancement to Falcon Identity Protection’s existing NTLM relay detection, which detects exploitation of the PetitPotam vulnerability and similar authentication coercion techniques.
PetitPotam and NTLM Relay
NTLM relay has always been a popular attack technique. In the past, the biggest challenge was to solicit a user account to authenticate to an attacker-controlled machine; now it seems that endpoint authentication coercion mechanisms are gaining popularity.
The most popular targets, for obvious reasons, are domain controllers, as their high privileges make them a lucrative target for authentication relay attacks. The first authentication coercion mechanism involved thePrint Spooler service, while the newer one relies on the MS-EFSRPC protocol. The latter is also known as the PetitPotam attack. When combined with the insecure default configuration of the Active Directory Certificate Services (AD-CS), which does not enforce Extended Protection for Authentication (EPA), it could be deadly as it can lead to a full domain compromise in a few steps. An attacker could trigger a domain controller authentication by exploiting the PetitPotam vulnerability and relaying it to the AD-CS server to request a certificate for the domain controller account. Using this certificate, a malicious actor can then retrieve a TGT for the relayed domain controller account and perform any further operations using its high privileges (e.g., dump domain admin hashes).
One of the most severe issues with the PetitPotam vulnerability, prior to Microsoft’s latest security updates, was that an attacker could run the attack unauthenticated (i.e., only network access to the domain controller was required). The patch only partially mitigates the issue, meaning an attack is still possible.
As a workaround, Microsoft recommended to manually map certificates to Active Directory accounts or follow KB5014754 for other possible mitigations. Because of the issues caused by the patch, CISA warned against deploying it on domain controllers, which left many organizations wide open to the unauthenticated PetitPotam authentication coercion attack. On May 19, 2022, an out-of-band update was made available to fix the authentication failures caused by the latest security update.
It is important to note that thesecurity update states, “This security update detects anonymous connection attempts in LSARPC and disallows it,” which leaves the question: Does the coercion attack still work using an authenticated user?
Following some testing, it looks like the answer is yes!
While the PetitPotam vulnerability, when patched, will no longer work unauthenticated, it can still be abused by leveraging any Active Directory account credentials to trigger domain controller NTLM authentication, which can be relayed to a escalate to domain admin privileges if the required security settings are not enforced (as previously mentioned, EPA is not enforced by default on AD-CS servers).
Moreover, PetitPotam is no longer the newest authentication coercion method; the attack tool DFSCoerce, which abuses the MS-DFSNM protocol to trigger domain controller authentication, has since been released.
Because an authenticated user can still trigger an NTLM authentication from the domain controller, the NTLM relay attack vector remains relevant for domain controller accounts. This is why the NTLM relay detection capability of CrowdStrike Falcon Identity Threat Protection was enhanced to detect attempts to perform NTLM relay using domain controller credentials. The benefit of this detection is that it is not tied to any single authentication coercion method, but will detect a relay attack no matter if it is initiated by the PetitPotam vulnerability, the newer DFSCoerce tool or any coercion mechanism discovered in the future.
(Click to enlarge)
Watch this video on Falcon Spotlight to see how you can monitor and prioritize NTLM relay issues and other vulnerabilities within your environment, and this video to learn how Falcon Identity Threat Protection helps ensure comprehensive protection against identity-based attacks in real time.
Additional Mitigations
Though patching is an important first step against the latest NTLM relay vulnerabilities, it is not enough, as many unsecured defaults can leave your domain vulnerable. This is why we recommend following these steps:
Enforce Signing (SMB/LDAP) and Extended Protection for Authentication (EPA) for all relevant servers, especially the AD-CS servers, which are a common target of this attack.
Track any failed/successful NTLM relay attempts performed in your domain network. Using the enhanced detection capabilities of the CrowdStrike Falcon Identity Threat Protection, customers can now be alerted on NTLM relay attacks abusing domain controller accounts.
Disable NTLM. Because this is a potentially breaking change that requires a lot of time in most environments, start by disabling NTLM support on servers that may be targeted during a relay attack and are not sufficiently protected. For example, if for any reason you are unable to enforce EPA on the AD-CS server, disable incoming NTLM on that server to protect it from NTLM relay attacks.
Additional Resources
Learn more about popular attack techniques at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21!
Watch this video to see how Falcon Identity Threat Protection detects and stops ransomware attacks.
Learn how the powerful CrowdStrike Falcon platform provides comprehensive protection across your organization, workers and data, wherever they are located.
The threat presented by today’s adversaries is as pervasive as it is dangerous — eCrime and state-nexus actors alike are attempting to infiltrate companies and organizations of all sizes and across all verticals.
While technology is a powerful tool for performing routine or repeatable analysis, the only way to effectively hunt and contain sophisticated and determined cyber threat actors is to use the expertise and ingenuity of human threat hunters.
The Telescope and the Microscope: Two Sides of the Threat Hunting Coin
Threat hunting is an ever-evolving discipline that proactively tracks changes in adversaries’ behavior. It requires a broad awareness of the threat landscape — the telescopic view — and can be augmented by a deeper understanding of a customer’s pain points or areas of identified risk — the microscopic view. The most comprehensive threat hunting leverages both the telescopic and microscopic viewpoints, blending the insights gained from both perspectives to safeguard a customer’s assets from threats.
The CrowdStrike Falcon OverWatch team’s continuous hunting operations are driven by a world-class team of dedicated in-house threat hunters — individuals who are relentlessly committed to honing their craft and dedicated to the mission of stopping breaches. OverWatch analysts track the most stealthy and persistent hands-on-keyboard campaigns, actively hunting for that last 1% of malicious activity deliberately seeking to subvert technology-based controls.
Using patented hunting tools, OverWatch hunters leverage the power of the CrowdStrike Security Cloud to hunt across in excess of one trillion events a day — proactively searching for that malicious activity designed to blend in with the benign. Given the sheer breadth of information available to them, OverWatch analysts are skilled at identifying even the faintest signs of activity indicative of threat actor behavior and emerging threats, enabling customers to rapidly disrupt malicious behavior before its impact is felt.
The Power of Elite Tailored Threat Hunting
For organizations that are looking for an active partnership with their hunters, CrowdStrike offers OverWatch Elite — the personalized customer engagement add-on for CrowdStrike’s Falcon OverWatch managed threat hunting service.
OverWatch Elite builds on the continuous 24/7 human-led threat hunting provided by OverWatch, leveraging the ability to hunt across global telemetry to address areas of concern identified by customers. OverWatch Elite customers have access to an assigned threat analyst who provides a range of services to drive improved maturity across a customer’s internal security team. These services include expert coaching to support any in-house hunting efforts, regular threat updates, and a dedicated line of communication to address any queries or concerns as they arise. In partnership with their assigned analyst, customers can develop, operationalize and tune their threat hunting programs to ensure that supplementary threat hunts are tailored to their needs.
OverWatch Elite analysts build close partnerships with their assigned customers to develop a shared understanding of an organization’s unique structure and requirements. OverWatch Elite analysts are then able to tune their tools to the particular nuances found within a customer’s environment. In addition to addressing the customer’s needs, this fine-tuning enables all OverWatch analysts to more easily identify hands-on-keyboard activity and respond promptly to potential threats.
The fast, closed-loop communication between customers and the OverWatch Elite team allows for greater collaboration to address issues. Whether a customer has seen the news about a recent vulnerability or read an intelligence report about certain threat actors targeting companies in their sector, assigned analysts are available to listen and respond to these concerns by performing threat hunts tailored to address them.
Working Better Together
It is important to recognize that these two parts of OverWatch share a common mission: stopping breaches. OverWatch and OverWatch Elite analysts work hand-in-hand daily to ensure all customers are protected against those malicious hands-on-keyboard activities designed to evade detection. All teams under the OverWatch umbrella work together continuously to provide the best customer service possible.
OverWatch Elite Manager Gareth Willams puts it best: “You can’t look at the moon with a microscope and you can’t use a telescope to see small objects, but both give you a great field of vision.”
In addition to tailored threat hunting services, OverWatch Elite offers several additional features that truly make this a customer engagement-centric managed threat hunting service. Additional offerings include 60-minute call escalation for critical threats, which provides OverWatch Elite customers added peace of mind when it comes to rapidly disrupting adversary activity within their environments. OverWatch Elite customers are also invited to a private Slack channel where they can reach an OverWatch Elite analyst to respond with speed and confidence.
Learn more about hands-on-keyboard threats and the power of human-led threat hunting at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21!
Read more about the value 60-minute call escalation provides OverWatch Elite customers in this CrowdStrike blog.
Read more about how OverWatch uses the human element to augment technology to protect customers against both known and unknown threats in this CrowdStrike blog.
Authored by Alberto Segura (main author) and Rolf Govers (co-author)
Summary
Flubot is an Android based malware that has been distributed in the past 1.5 years in Europe, Asia and Oceania affecting thousands of devices of mostly unsuspecting victims. Like the majority of Android banking malware, Flubot abuses Accessibility Permissions and Services in order to steal the victim’s credentials, by detecting when the official banking applicationis open to show a fake web injection, a phishing website similar to the login form of the banking application. An important part of the popularity of Flubot is due to the distribution strategy used in its campaigns, since it has been using the infected devices to send text messages, luring new victims into installing the malware from a fake website. In this article we detail its development over time and recent developments regarding its disappearance, including new features and distribution campaigns.
Introduction
One of the most popular active Android banking malware families today. An “inspiration” for developers of other Android banking malware families. Of course we are talking about Flubot. Never heard of it? Let us give you a quick summary.
Flubot banking malware families are in the wild since at least the period between late 2020 and the first quarter of 2022. Most of its popularity comes from its distribution method: smishing. Threat Actors (TA) have been using the infected devices to send text messages to other phone numbers, stolen from other infected devices and stored in Command-and-Control servers (C2).
In the initial campaigns, TAs used fake Fedex, DHL and Correos – a local Spanish parcel shipping company – SMS messages. Those SMS messages were fake notifications which lured the user into a fake website in order to download a mobile application to track the shipping. These campaigns were very successful, since nowadays most people are used to buy different kinds of products online and receive that type of messages to track the shipping of the product. Flubot is not only a very active family: TAs have been very actively introducing new features, support for campaigns in new countries and improving the features it already had.
On June 1, 2022, Europol announced the takedown of Flubot in a joint operation including 11 countries. The Dutch Police played a key part in this operation and successfully disrupted the infrastructure in May 2022, rendering this strain of malware inactive. That was interesting period of time to look back at the early days of Flubot, how it evolved and became so notorious.
In this post we want to share all we know about this threat and a timeline of the most relevant and interesting (new) features and changes that Flubot’s TAs have introduced. We will focus on these features and changes related to the detected samples but also in the different campaigns that TAs have been using to distribute this malware.
The beginning: A new Android Banking Malware targeting Spain [Flubot versions 0.1-3.3]
Based on reports from other researchers, Flubot samples were first found in the wild between November and December of 2020. Public information about this malware was first published on 6 January 2021 by our partner ThreatFabric (https://twitter.com/ThreatFabric/status/1346807891152560131). Even though ThreatFabric was the first to publish public information on this new family and called it “Cabassous”, the research community has been more commonly referring to this malware as Flubot.
In the initial campaigns, Flubot was distributed using Fedex and Correos fake SMS messages. In those messages, the user was led to a fake website which was basically a “landing page” style website to download what was supposed to be an Android application to track the incoming shipping.
In this initial campaign versions prior to Flubot 3.4 were used, and TAs were including support for new campaigns in other countries using specific samples for each country. The reasons why there were different samples for different countries were: – Domain Generation Algorithm (DGA). It was using a different seed to generate 5.000 different domains per month. Just out of curiosity: For Germany, TAs were using 1945 as seed for the DGA. – Phone country code used to send more distribution smishing SMS messages from infected devices and block those numbers in order to avoid communication among victims.
There were no significant changes related to features in the initial versions (from 0.1 to 3.3). TAs were mostly focused on the distribution campaigns, trying to infect as many devices as possible.
There is one important change in the initial versions, but it is difficult to find the exact version in which this change was first introduced because there are some version without samples on public repositories. TAs introduced web injections to steal credentials, the most popular tactic to steal credentials on Android devices. This was introduced starting between versions 0.1 and 0.5, in December 2020.
In those initial versions, TAs increased the version number of the malware in just a few days without adding significant changes. Most of the samples – particularly previous to 2.1 – were not uploaded to public malware repositories, making it even harder to track the first versions of Flubot.
On these initial versions (after 0.5), TAs also introduced other not so popular features like the “USSD” one which was used to call to special numbers to earn money (“RUN_USSD” command), it was introduced at some point between versions 1.2 and 1.7. In fact, it seems this feature wasn’t really used by Flubot’s TAs. Most used features were the web injections to steal banking and cryptocurrency platform credentials and sending SMS features to distribute and infect new devices.
From version 2.1 to 2.8 we observed TAs started to use a different packer for the actual Flubot’s payload. It could explain why we weren’t able to find samples on public repositories between 2.1 and 2.8, probably there were some “internal” versions used to try different packers and/or make it work with the new one.
March 2021: New countries and improvements on distribution campaigns [Flubot versions 3.4-3.7]
After a few months apparently focused on distribution campaigns and not really on new features for the malware itself, we have found version 3.4 in which TAs introduced some changes on the DGA code. In this version, they reduced the number of generated domains from 5.000 to 2.500 a month. At first sight this looks like a minor change, but is one of the first changes to start distributing the malware in different countries in a more easy way for TAs, since a different sample with different parameters was used for each country.
In fact, we can see a new version (3.6) customized for targeting victims in Germany in March 18, 2021. Only five days later, another version was released (3.7), with interesting changes. TAs were trying to use the same sample for campaigns in Spain and Germany, including Spanish and German phone country codes split by newline character to block the phone number to which the infected device is sending smishing messages.
At the same time, TAs introduced a new campaign on Hungary. By the end of March, TAs introduced a new change on version 3.7: an important change in their DGA, since they replaced “.com” TLD with “.su”. This change was important for tracking Flubot, since now TAs could use this new TLD to register new C2’s domains.
April 2021: DoH and unique samples for all campaigns [Flubot versions 3.9-4.0]
It seems TAs were working since late March on a new version: Flubot 3.9. In this new version, they introduced DNS-over-HTTPs (DoH). This new feature was used to resolve domain names generated by the DGA. This way, it was more difficult to detect infected devices in the network, since security solutions were not able to check which domains were being resolved.
In the following images we show decompiled code of this new version, including the new DoH code. TAs kept the old classic DNS resolving code. TAs introduced code to randomly choose if DoH or classic DNS should be used.
The introduction of DoH was not the only feature that was added to Flubot 3.9. TAs also added some UI messages to prepare future campaigns targeting Italy. Those messages were used a few days later in the new Flubot 4.0 version, in which TAs finally started to use one single sample for all of the campaigns – no more unique samples to targeted different countries.
With this new version, the targeted country’s parameters used on previous version of Flubot were chosen depending on the victim’s device language. This way, if the device language was Spanish, then Spanish parameters were used. The following parameters were chosen: – DGA seed – Phone country codes used for smishing and phone number blocking
May 2021: Time for infrastructure and C2 server improvements [Flubot versions 4.1-4.3]
May starts with a minor update on version 4.0 – a change the DoH servers used to resolve DGA domains. Now instead of using CloudFlare’s servers they started using Google’s servers. This was the first step to move to a new version, Flubot 4.1. In this new version, TAs have changed one more time the DoH servers used to resolve the C2 domains. In this case, they introduced three different services or DNS servers: Google, CloudFlare and AliDNS. The last one was used for the first time in the life of Flubot to resolve the DGA domains.
Those three different DoH services or servers were chosen randomly to resolve the generated domains, to finally make the requests to any of the active C2 servers. These changes also brought a new campaign in Belgium, in which TAs used fake BPost app and smishing messages to lure new victims. One week later, new campaigns in Turkey were also introduced, this time in a new Flubot version with important changes related to its C2 protocol.
The first samples of Flubot 4.2 appeared on 17 May 2021 with a few important changes in the code used to communicate with the C2 servers. In this version, the malware was sending HTTP requests with a new path in the C2: “p.php”, instead of the classic “poll.php” path.
At first sight it seemed like a minor change, but paying attention to the code we realized there was an important reason behind this change: TAs changed the encryption method used for the protocol to communicate with the C2 servers. Previous versions of Flubot were using simple XOR encryption to encrypt the information exchanged with the C2 servers, but this new version 4.2 was using RC4 encryption to encrypt that information instead of the classic XOR. This way, the C2 server still supported old versions and new version at the same time:
poll.php and poll2.php were used to send/receive requests using the old XOR encryption
p.php was used to send and receive requests using the new RC4 encryption
Besides the new protocol encryption on version 4.2, TAs also added at the end of May support for new campaigns in Romania. Finally, on 28 May 2021 new samples of Flubot 4.3 were discovered with minor changes, mainly focused on the strings obfuscation implemented by the malware.
June 2021: VoiceMail. New campaign new countries [Flubot versions 4.4-4.6]
A few days after first samples of Flubot 4.3 were discovered – on May 31, 2021 and June 1, 2021 – new samples of Flubot were observed with version number bumped to 4.4. One more time, no major changes in this new version. TAs added support for campaigns in Portugal. As we can see with versions 4.3 and 4.4, it was common for Flubot’s TAs to bump the version number in just a few days, with just minor changes. Some versions were not even found in public repositories (e.g. version 3.3), which suggests that some versions were never used in public or just skipped and TAs just bumped the version. Maybe those “lost versions” lasted just a few hours in the distribution servers and were quickly updated to fix bugs.
In the month of June the TAs hardly made any changes related to features, but instead they were working on new distribution campaigns. On version 4.5, TAs added Slovakia, Czech Republic, Greece and Bulgaria to the list of supported countries for future campaigns. TAs reused the same DGA seed for all of them, so it didn’t require too much work from their part to get this version released.
A few days after version 4.5 was observed, a new version 4.6 was discovered with new countries added for future campaigns: Austria and Switzerland. Also, some countries that were removed in previous versions were reintroduced: Sweden, Poland, Hungary, and The Netherlands.
This new version of Flubot didn’t come only with more country coverage. TAs introduced a new distribution campaign lure: VoiceMail. In this new “VoiceMail” campaign, infected devices were used to send text messages to new potential victims using messages in which the user was lead to a fake website. This time a “VoiceMail” app was installed, which should allow the user to listen to the received Voice mail messages. In the following image we can see the VoiceMail campaign for Spanish users.
July 2021: TAs Holidays [Flubot versions 4.7]
July 2021 is the month with less activity. In this month, only one version update was observed at the very beginning of the month – Flubot 4.7. This new version came without the usage of different DGA seeds by country or device language. TAs started to randomly choose the seed from a list of seeds, which were the same seeds that were previously used for country or device language.
Besides the changes related to the DGA seeds, TAs also introduced support for campaigns in new countries: Serbia, Croatia and Bosnia and Herzegovina.
There was almost no Flubot activity in summer. Our assumption is the developers were busy with their summer holidays. As we will see in the following section, TAs will recover their activity in August and October.
August-September 2021: Slow come back from Holidays [Flubot versions 4.7-4.9]
During the first days of August, after TAs possibly enjoyed a nice holiday season, Australia was added to version 4.7 in order to start distribution campaigns in that country. Only a week later, TAs released the new version 4.8, in which we found some minor changes mostly related to UI messages and alert dialogs.
One more version bump for Flubot was discovered on September, when version 4.9 came out with some more minor changes, just like the previous version 4.8. This time, new web injections were introduced in the C2 servers to steal credentials from victims. Those two new versions with minor changes (not very relevant) seems like a relaxed come back to activity. From our point of view, the most interesting thing that happened in those two months is that TAs started to distribute another malware family using the Flubot botnet. We received from C2 servers a few smishing tasks in which the fake “VoiceMail” website was serving Teabot (also known as Anatsa and Toddler) instead of Flubot.
That was very interesting because it showed that Flubot’s TAs could be also associated with this malware family or at least could be interested on selling the botnet for smishing purposes to other malware developers. As we will see, that was not the only family distributed by Flubot.
October-November 2021: ‘Android Security Update’ campaign and new big protocol changes [Flubot versions 4.9]
During October and most part of November, Flubot’s TAs didn’t bump the version number of the malware and they didn’t do very important moves during that period of time.
At the beginning of October, we saw a campaign different from the previous DHL / Correos / Fedex campaigns or the “VoiceMail” campaign. This time, TAs started to distribute Flubot as a fake security update for Android. It seems this new distribution campaign wasn’t working as expected, since TAs kept using the “VoiceMail” distribution campaign after a few days.
TAs were very quiet until late November, when they finally released new samples with important changes in the protocol used to communicate with C2 servers. After bumping the version numbers so quickly at the beginning, now TAs weren’t bumping the version number even with a major change like this one.
This protocol change allowed the malware to communicate with the C2 servers without starting a direct connection with them. Flubot used TXT DNS requests to common public DNS servers (Google, CloudFlare and AliDNS). Then, those requests were forwarded to the actual C2 servers (which implemented DNS servers) to get the TXT record response from the servers and forward it to the malware. The stolen information from the infected device was sent encrypting it using RC4 (in a very similar way to the used in the previous protocol version) and encoding the encrypted bytes. This way, the encoded payload was used as a subdomain of the DGA generated domain. The response from C2 servers was also encrypted and encoded as the TXT record response to the TXT request, and it included the commands to execute smishing tasks for distribution campaign or the web injections used to steal credentials.
With this new protocol, Flubot was using DoH servers from well known companies such as Google and CloudFlare to establish a tunnel of sorts with the C2 servers. With this technique, detecting the malware via network traffic monitoring was very difficult, since the malware wasn’t establishing connections with unknown or malicious servers directly. Also, since it was using DoH, all the DNS requests were encrypted, so network traffic monitoring couldn’t identify those malicious DNS requests.
This major change in the protocol with the C2 servers could also explain the low activity in the previous months. Possibly developers were working on ways to improve the protocol as well as the code of both malware and C2 servers backend.
December 2021: ‘Flash Player’ campaign and DGA changes [Flubot versions 5.0-5.1]
Finally, in December the TAs decided to finally bump the version number to 5.0. This new version brought a minor but interesting change: Flubot can now receive URLs in addition to web injections HTML and JavaScript code. Before version 5.0, C2 servers would send the web injection code, which was saved on the device for future use when the victim opened one of the targeted applications in order to steal the credentials. Since version 5.0, C2 servers were sending URLs instead, so Flubot’s malware had to visit the URL and save the HTML and JavaScript source code in memory for future use.
No more new versions or changes were observed until the end of December, when the TAs wanted to say goodbye to the 2021 by releasing Flubot 5.1. The first samples of Flubot 5.1 were detected on December 31. As we will see in the following section, on January 2 Flubot 5.2 samples came out. Version 5.1 came out with some important changes on DGA. This time, TAs introduced a big list of TLDs to generate new domains, while they also introduced a new command used to receive a new DGA seed from the C2 servers – UPDATE_ALT_SEED. Based on our research, this new command was never used, since all the newly infected devices had to connect to the C2 servers using the domains generated with the hard-coded seeds.
Besides the new changes and features added in December, TAs also introduced a new campaign: “Flash Player”. This campaign was used alongside with “VoiceMail” campaign, which still was the most used to distribute Flubot. In this new campaign, a text message was sent to the victims from infected devices trying to make them install a “Flash Player” application in order to watch a fake video in which the victim appeared. The following image shows how simple the distribution website was, shown when the victim opens the link.
January 2022: Improvements in Smishing features and new ‘Direct Reply’ features [Flubot versions 5.2-5.4]
At the very beginning of January new samples for the new version of Flubot were detected. This time, version 5.2 introduced minor changes in which TAs added support for longer text messages on smishing tasks. They stopped using the usual Android’s “sendTextMessage” function and started to use “sendMultipartTextMessage” alongside “divideMessage” instead. This allowed them to use longer messages, split into multiple messages.
A few days after new sample of version 5.2 was discovered, samples of version 5.3 were detected. In this case, no new features were introduced. TAs removed some unused old code. This version seemed like a version used to clean the code. Also, three days after the first samples of Flubot 5.3 appeared, new samples of this version were detected with support for campaigns in new countries: Japan, Hong Kong, South Korea, Singapore and Thailand.
By the end of January, TAs released a new version: Flubot 5.4. This new version introduced a new and interesting feature: Direct Reply. The malware was now capable to intercept the notifications received in the infected device and automatically reply them with a configured message received from the C2 servers.
To get the message that would be used to reply notifications, Flubot 5.4 introduces a new request command called “GET_NOTIF_MSG”. As the following image shows, this request command is used to get the message to finally be used when a new notification is received.
Even though this was an interesting new feature to improve the botnet’s distribution power, it didn’t last too long. It was removed in the following version.
In the same month we detected Medusa, another Android banking malware, distributed in some Flubot smishing tasks. This means that, one more time, Flubot botnet was being used as a distribution botnet for distribution of another malware family. In August 2021 it was used to distribute Teabot. Now, it has been used to distribute Medusa.
If we try to connect the dots, it could explain the new “Direct Reply” feature and the usage of “multipart messages”. Those improvements could have been introduced due to suggestions made by Medusa’s TAs in order to use Flubot botnet as distribution service.
February-March-April 2022: New cookie stealing features [Flubot versions 5.5]
From late January – when we fist observed version 5.4 in the wild – to late February, almost one month passed until a new version was released. We believe this case is similar to previous periods of time, like August-November 2021, when TAs used that time to introduce a big change in the protocol. This time, it seems TAs were quietly working on new Flubot 5.5, which came with a very interesting feature: Cookie stealing.
The first thing we realized by looking at the new code was a little change when requesting the list of targeted apps. This request must include the list of installed applications in the infected device. As a result, the C2 server would provide the subset of apps which are targeted. In this new version, “.new” was appended to the package names of installed apps when doing the “GET_INJECTS_LIST” request.
At the beginning, the C2 servers were responding with URLs to fetch the web injections for credentials stealing when using “.new” appended to the package’s name. After some time, C2 servers started to respond with the official URL of the banks and crypto-currency platforms, which seemed strange. After analysis of the code, we realized they also introduced code to steal the cookies from the WebView used to show web injections – in this case, the targeted entity’s website. Clicks and text changes in the different UI elements of the website were also logged and sent to the C2 server, so TAs were not only stealing cookies: they were also able to steal credentials via “keylogging”.
The cookies stealing code could receive an URL, the same way it could receive a URL to fetch web injections, but this time visiting the URL it wasn’t receiving the web injection. Instead, it was receiving a new URL (the official bank or service URL) to be loaded and to steal the credentials from. In the following image, the response from a compromised website used to download the web injections is shown. In this case, it was used to get the payload for stealing GMail’s cookies (shown when the victim tries to open Android Email application).
After the victim logs in to the legitimate website, Flubot will receive and handle an event when the website ends loading. At this time, it gets the cookies and sends them to the C2 server, as can be seen in the following image.
May 2022: MMS smishing and.. The End? [Flubot versions 5.6]
Once again, after one month without new versions in the wild, a new version of Flubot came out at the beginning of May: Flubot 5.6. This is the last known Flubot version.
This new version came with a new interesting feature: MMS smishing tasks. With this new feature, TAs were trying to bypass carriers detections, which were probably put in place after more than a year of activity. A lot of users were infected and their devices where sending text messages without their knowledge.
To introduce this new feature, TAs added new request’s commands: – GET_MMS: used to get the phone number and the text message to send (similar to the usual GET_SMS used before for smishing) – MMS_RATE: used to get the time rate to make “GET_MMS” request and send the message (similar to the usual SMS_RATE used before for smishing).
After this version got released on May 1st, the C2 servers stopped working on May 21st. They were offline until May 25th, but they were still not working properly, since they were replying with empty responses. Finally, on June 1st, Europol published on their website that they took down the Flubot’s infrastructure with the cooperation of police from different countries. Dutch Police was the one that took down the infrastructure. It probably happened because Flubot C2 servers, at some point in 2022, changed the hosting services to a hosting service in The Netherlands, making it easier to take down.
Does it mean this is the end of Flubot? Well, we can’t know for sure, but it seems police wasn’t able to get the RSA private keys since they didn’t make the C2 servers send commands to detect and remove the malware from the devices. This means that the TAs should be able to bring Flubot back by just registering new domains and setting up all the infrastructure in a “safer” country and hosting service. TAs could recover their botnet, with less infected devices due to the offline time, but still with some devices to continue sending smishing messages to infect new devices. It depends on the TAs intentions, since it seems that the police hasn’t found them yet.
Conclusion
Flubot has been one of the most – if not the most – active banking malware family of the last few years. Probably this was due to their powerful distribution strategy: smishing. This malware has been using the infected devices to send text messages to the phone numbers which were stolen from the victims smartphones. But this, in combination with fake parcel shipping messages in a period of time in which everybody is used to buy things online has made it an important threat.
As we have seen in this post, TAs have introduced new features very frequently, which made Flubot even more dangerous and contagious. A significant part of the updates and new features have been introduced to improve the distribution capabilities of the malware in different countries, while others have been introduced to improve the credentials and information stealing capabilities.
Some updates delivered major changes in the protocol, making it more difficult to detect via network monitoring, with a DoH tunnel-based protocol which is really uncommon in the world of Android Malware. It seems that TAs have even been interested on selling some kind of “smishing distribution” service to other TAs, as we have seen with the association with Teabot and Medusa.
After one year and a half, Dutch Police was able to take down the C2 servers after TAs started using a Dutch hosting service. It seems to be the end of Flubot, at least for now.
TAs still can move the infrastructure back to a “safer” hosting and register new DGA domains to recover their botnet. It’s too soon to determine that was the end of Flubot. Time will tell what will happen with this Android malware family, which has been one of the most important and interesting malware families in the last few years.
Researchers discovered a new flaw in RARlab’s UnRAR utility, tracked CVE-2022-30333, that can allow to remotely hack Zimbra Webmail servers.
SonarSource researchers have discovered a new vulnerability in RARlab’s UnRAR utility, tracked as CVE-2022-30333, that can be exploited by remote attackers to execute arbitrary code on a system that relies on the binary, like Zimbra webmail servers.
Zimbra is an enterprise-ready email solution used by over 200,000 businesses, government and financial institutions.
“we discovered a 0-day vulnerability in the unrar utility, a 3rd party tool used in Zimbra. The vulnerability ultimately allows a remote attacker to execute arbitrary code on a vulnerable Zimbra instance without requiring any prior authentication or knowledge about it.” reads the post published by SonarSource researchers. “
“An attacker is able to create files outside of the target extraction directory when an application or victim user extracts an untrusted archive. If they can write to a known location, they are likely to be able to leverage it in a way leading to the execution of arbitrary commands on the system.”
The CVE-2022-30333 flaw in the unrar binary developed by RarLab is a File Write vulnerability that could be exploited by tricking victims into extracting maliciously crafted RAR archives.
The experts pointed out that In the case of Zimbra, threat actors could exploit this issue to access every email sent and received on a compromised email server. An attacker can fully compromise a server and install a backdoor and use the compromised machine as a pivot to target other systems withing the organization.
“The only requirement for this attack is that unrar is installed on the server, which is expected as it is required for RAR archive virus-scanning and spam-checking.” continues the report.
Below is the timeline for this issue:
Date
Action
2022-05-04
We report the bug in unrar to RarLab.
2022-05-04
We are already in communication with Zimbra about another issue. We give them a heads up about an upcoming security patch from RarLab and send them a Proof-of-Concept exploit to verify that the issue affects Zimbra
2022-05-04
RarLab confirms the issue.
2022-05-05
RarLab sends us a patch for review. We confirm the patch is effective the same day.
2022-05-06
RarLab releases version 6.12 of the binary on their website.
2022-05-07
We send a dedicated email to Zimbra regarding this issue and send the Proof-of-Concept exploit again.
2022-05-11
We notice a flaw in our Proof-of-Concept and send Zimbra more files to help them verify the issue.
2022-05-11
We notify Debian and Ubuntu package maintainers of the security issue.
2022-05-11
Zimbra notifies us that they were able to reproduce the vulnerability.
2022-05-25
We notify Zimbra of the planned release date for this blog post.
The issue stems from a symbolic link attack, threat actors could create a RAR archive containing a symlink that contains forward and backslashes (e.g., “..\..\..\tmp/shell”) to bypass current checks and extract it outside of the target extraction directory.
The flaw resides in a function that converts backslashes (‘\’) to forward slashes (‘/’) to RAR archives created on Windows to be extracted on Unix systems.
The attacker can exploit this flaw to write arbitrary files anywhere on the target filesystem, including writing a JSP shell into a web directory shell in Zimbra’s web directory.
“An attacker can achieve RCE impact via various means. We mentioned for example, that an attacker could write a JSP shell into a web directory. Luckily, most Zimbra instances have their services distributed across multiple servers and thus this path of exploitation is not possible on most installations. However, we have reported multiple different paths of exploitation that work on distributed installations.” concludes the report. “For this reason we recommend upgrading unrar immediately, even if your web server and mail server are not on the same physical machine.”
Horizon3.ai, a cybersecurity firm focused on autonomous penetration testing, announced today that Midsize Enterprise Services (MES), a brand of The Channel Company, has recognized Horizon3.ai on its 2022 MES Matters – Key Vendors Serving the Midmarket list.
to see how you can monitor and prioritize NTLM relay issues and other vulnerabilities within your environment, and 
