In the past 5 years, we’ve demonstrated countless supply chain attacks in production CI/CD pipelines for virtually every company we’ve tested, with several dozen successful compromises of targets ranging from small businesses to Fortune 500 companies across almost every market and industry.
In this presentation, we’ll explain why CI/CD pipelines are the most dangerous potential attack surface of your software supply chain. To do this, we’ll discuss the sorts of technologies we frequently encounter, how they’re used, and why they are the most highly privileged and valuable targets in your company’s entire infrastructure. We’ll then discuss specific examples (with demos!) of novel abuses of intended functionality in automated pipelines which allow us to turn the build pipelines from a simple developer utility into Remote Code Execution-as-a-Service.
Is code-signing leading your team into a false sense of security while you programmatically build someone else’s malware? Is it true that “any sufficiently advanced attacker is indistinguishable from one of your developers”? Have we critically compromised nearly every CI/CD pipeline we’ve ever touched? The answer to all of these questions is yes.
Fortunately, this presentation will not only teach you exactly how we did it and the common weaknesses we see in these environments, but also share key defensive takeaways that you can immediately apply to your own development environments.
While using macros for malicious purposes is nothing new, this tool provides a suite of payloads ideal for initial recon and footholds that will not burn other methods of attack. MacAttack is a framework that generates payloads for use in Excel and includes client/server communication to perform dynamic alterations at runtime and collate received data. The payloads included in MacAttack cover a number of areas that have not been published before, including a new stealth technique for hiding payloads, methods for retrieving a user’s hash, and performing common recon/early stages attacks such as As-Rep roasting, retrieving documents, browser credentials, password spraying the domain, enumerating users, and domain fronting. The client/server communication and GUI will allow for dynamic checks such as only allowing a password spray to run once or once within a certain time period even if multiple targets enable the payload at the same time, and will provide a visual representation of the enumerated information. Part of the benefit of this tool is that this information is retrievable from a “zero foothold” position – a phishing campaign may be detected or blocked – but this does not burn any existing beacons and the potential rewards can be as great as multiple sets of credentials for users and relevant authentication portals. Microsoft are rolling out changes to macros that have still not been fully deployed by the time of the deadline – and research into these changes and impacts will be included in the discussion. It looks like these changes will only affect O365 to begin with and will include a “recommended policy” to implement.
Monkey365 is a multi-threaded plugin-based PowerShell module to help assess the security posture of not only Microsoft 365, but also Azure subscriptions and Azure Active Directory. It contains multiple controls and currently supports CIS, HIPAA, GDPR, as well as custom security rules.
Matt Nash (NCC Group) & Mauricio Tavares (Privacy Test Driver)
DEF CON 30 – Crypto & Privacy Village
August 11-14 2022
New year, new challenges to privacy.
You are in a public event, or a coffee shop. Did a notification just tell you about a sale nearby? Why is this app showing ads for the car you rented and told your friend about? Is Santa Claus the only one who knows if you’ve been naughty or nice? “Maybe if I run a VPN I will be safe.” This is wishful thinking at best; it only helps to deal with some privacy attacks. You see, smart phones are little snitches. By design.
They listen to you. They know where you go, what you purchase, and who you interact with. And they never sleep or take vacations.
You can fight back. You can regain (at least some) control of your privacy! But it will not be done buying some magic software and pressing the EZ button. Some assembly is required.
If you are willing to roll up your sleeves and take your brave pill, join us in this workshop as we show how to build your Android phone with the balance between privacy, security, and convenience that fits your comfort level.
Attendees will come out of this workshop with a privacy mindset:
Appreciating the privacy and security implications of using a smart phone in general — specifically consumer Android devices.
Knowing how to achieve different levels of privacy in their phones and understanding the costs and benefits of each approach.
Understanding what “attribution of traffic” tying IP to a person through a VPN is.Finding out which apps are privacy-respecting, and how to contain untrusted apps that may be a “must have”.
Who should take this workshop:
Privacy-conscious smartphone users who would like to understand and control what their phones share about them.
Audience Skill Level:
Entry level, if you have studied the instructions and are prepared to hit the ground running. Or if your team is willing to help you out. We will NOT be able to wait for you to install 374 OS updates, download and install VirtualBox, and then build a Linux VM.
An understanding of basic Linux commands.
Be comfortable with the idea of installing an aftermarket firmware/OS (“ROM”) on a mobile device. Soft/hard “bricking” is a possibility, so having a spare phone may be a good investment.
Cybersecurity has a diversity problem. We all know this. Executives and managers believe that filling job roles and enacting diversity initiatives is where the work begins and ends. Even though we are aware of this diversity problem, we’ve only just begun to start the conversation of how “bias” directly impacts hiring practices and cyber operations themselves. Our lack of observation of our bias’ has also made most of us blind to the bias that exist within our security tools and operations. To be fair, social engineering is the one, if not only, place where we bend and manipulate bias to our will. But I believe we should do the same within our operation’s as a whole. In 2018, Joy Buolamwini’s began to research and call out algorithmic bias and its impacts. Through Joy and Timnit Gebru’s research, the tech community has finally started to acknowledge the real world implications of biased algorithms. As humans, we tend to “believe what we think”. It’s not common practice for most humans to question or challenge their thought bubbles. Most humans are aware that a thought doesn’t necessarily equate to being factual in reality but the action of diving deeper seems to be staved off by our ego’s and credulous brains. I’d argue that our ‘inaction’ to dive deeper into our own personal bias’ is a precursor to writing biased code or tools and affects cyber operations in general which therefore contributes to a continuing cycle of cyber operations embedded with bias.
Written by Chris Anley, Chief Scientist, NCC Group
This paper collects a set of notes and research projects conducted by NCC Group on the topic of the security of Machine Learning (ML) systems. The objective is to provide some industry perspective to the academic community, while collating helpful references for security practitioners, to enable more effective security auditing and security-focused code review of ML systems. Details of specific practical attacks and common security problems are described. Some general background information on the broader subject of ML is also included, mostly for context, to ensure that explanations of attack scenarios are clear, and some notes on frameworks and development processes are provided.
Authored by Alberto Segura (main author) and Rolf Govers (co-author)
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 application is 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.
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.
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]
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.
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.
In March 2022, DFINITY engaged NCC Group to conduct a security and cryptography review of a threshold ECDSA implementation, which follows a novel approach described in the reference paper entitled “Design and analysis of a distributed ECDSA signing service” and available on the IACR ePrint archive at https://eprint.iacr.org/2022/506. The threshold ECDSA protocol will be deployed into the architecture of the Internet Computer. The ability for canisters to perform threshold signature generation and verification will facilitate the integration of the Internet Computer with other blockchains using ECDSA signatures, including Bitcoin and Ethereum.
The project methodology primarily relied upon manual code review supported by dynamic interaction with the test cases, as well as review of the supporting reference paper. Following this review, in early May 2022, NCC Group performed a retest of the findings uncovered during the initial engagement. That follow-up engagement also included the review of a short pull request incorporating changes to the underlying encryption scheme.
The Public Report for this review may be downloaded below:
Congratulations to NCC Group researcher Jeremy Boone, who was recently recognized for both the Highest Quality Report, as well as the Most Eligible Reports, as an invited researcher to the Intel Circuit Breaker program!
This month, members of NCC Group will be presenting their technical work & training courses at the following conferences:
NCC Group, “Training: Mastering Container Security,” to be presented at 44CON (June 13-15 2022)
NCC Group, “Training: Google Cloud Platform (GCP) Security Review,” to be presented at 44CON (June 13-16 2022)
Jennifer Fernick (NCC Group), Christopher Robinson (Intel), & Anne Bertucio (Google), “Preparing for Zero-Day: Vulnerability Disclosure in Open Source Software”, to be presented at Linux Security Summit North America (June 23-24 2022)
Jennifer Fernick (NCC Group) & Christopher Robinson (Intel), “Securing Open Source Software – End-to-End, at Massive Scale, Together,” to be presented at the Open Source Summit North America 2022 – Global Security Vulnerability Summit (June 23-24 2022)
Jose Selvi, “Cybersecurity, Intrusion Detection, & Machine Learning,” to be presented at Valencia 2022 Summer School – Challenges in Data Science: Big Data, Biostatistics, Artificial Intelligence, & Communications (June 27-July 1 2022)
Containers and container orchestration platforms such as Kubernetes are on the rise throughout the IT world, but how do they really work and how can you attack or secure them?
This course takes a deep dive into the world of Linux containers, covering fundamental technologies and practical approaches to attacking and defending container-based systems such as Docker and Kubernetes.
In the 2022 version of the course the trainers will be focusing more on Kubernetes as it emerges as the dominant core of cloud native systems and looking at the wider ecosystem of products which are used in conjunction with Kubernetes.
Ever more enterprises are moving their operations to the cloud, with customer adoption of Google Cloud Platform (GCP) steadily increasing. How can you ensure your cloud environment is secure?
NCC Group’s GCP security review training is a four-day course dedicated to security consultants and cloud architects interested in learning the principal elements of an environment based in Google’s cloud. It will discuss the techniques and tools necessary to perform a thorough security review and provide an understanding of the major risks, along with security best practices.
The course includes:
An introduction to GCP for people new to the platform, including general concepts and a comparison with other cloud providers
How to interact with GCP through the Cloud Console, CLI tool and SDK
An extensive discussion on the Identity and Access Management services with samples of policies and interesting attacks vectors
A review of networking in GCP, including typical topologies and common issues
A detailed look at the core services for computation, storage, databases, security and logging & monitoring
Tools which can help assess and secure GCP deployments
Open source software (OSS) is incredibly powerful – and while that power is often used for good, it can be weaponized when OSS projects contain software security flaws that attackers can use to compromise those systems, or even the entire software supply chains that those systems are a part of. The Open Source Security Foundation is an open, cross-industry group aimed at improving the security of the open source ecosystem. In this presentation, members of the OpenSSF Vulnerability Disclosure working group will be sharing with open-source maintainers advice on how to handle when researchers disclose vulnerabilities in your project’s codebase – and we’ll also take any questions you have about this often mysterious topic!
Open source software is a significant part of the core infrastructure in most enterprises in most sectors around the world and is foundational to the internet as we know it. It also represents a massive and profoundly valuable attack surface. Each year more lines of source code are created than ever before – and along with them, vulnerabilities. In this presentation, we’ll share key lessons learned in our experience coordinating the industry-wide remediation of some of the most impactful vulnerabilities ever disclosed, present a threat model of the many unmitigated challenges to securing the open source ecosystem, share new data which illustrates just how fragile and interdependent the security our core infrastructure can be, debate the challenges to securing OSS at scale, and speak unspoken truths of coordinated disclosure and where it can fail. We will also discuss the Open Source Security Foundation (OpenSSF) and share guidance for how members of the security community can get involved and contribute meaningfully to improving the security of OSS – especially through coordinated industry-wide efforts.
The cybersecurity industry is facing many new challenges related with the amount of data they have to manage. In the “at scale” era, the traditional signature-based approach is no longer a solution by itself. In this talk, we will see an example of how we could use machine learning to achieve a false positive reduction in intrusion detection systems..
Editor's Note: This security assessment was conducted by a team of our consultants, one of whom, Victor Hora, tragically and unexpectedly passed away a few weeks ago. As we publish this report, we miss our dear colleague immensely and celebrate Victor's life and his wonderful influence on the world. He was a talented security consultant, beloved colleague, and friend to all, who made the world a better place through his kindness, his joy, and - as we see in this publication - his commitment to using his deep technical talents to help serve others and protect the most vulnerable.May his memory serve as an everlasting reminder of the many ways our joy and talent can be used to help others and leave the world a better place than we found it.
From September 28th through October 23rd, 2020, Lantern – in partnership with the Open Technology Fund – engaged NCC Group to conduct a security assessment of the Lantern client. Lantern provides a proxy in order to circumvent internet censorship. This assessment was open ended and time-boxed, providing a best-effort security analysis in a fixed amount of time. Source code was provided to the engagement team.
In the winter of 2022, NCC Group was asked to re-evaluate several findings after remediation efforts had been completed for Lantern, which are also included in this Public Report.
Scope & Limitations
NCC Group’s evaluation included:
This application is intended for use in countries where the Internet is censored and therefore its threat model includes risks related to attribution and privacy attacks beyond just software security vulnerabilities. Included in that threat model are well-resourced attackers with advanced capabilities such as reading or modifying HTTP/HTTPS traffic unbeknownst to the targets. Testing was performed on a production version of the client made available at https://getlantern.org/.
NCC Group achieved adequate coverage of the Go code, which forms the backbone of the Lantern client. Some related components were not evaluated:
Server-side components were not in scope for the assessment.
The project relies on many third-party libraries. These libraries were not thoroughly evaluated.
The Public Report for this review may be downloaded below:
This honour, recognized quarterly by the Microsoft Researcher Recognition Program, is offered to security researchers who have discovered and shared security vulnerabilities in Microsoft products under coordinated vulnerability disclosure.
Juan Garrido received this recognition for finding and reporting issues such as:
Client Access Rules Bypass in Exchange Online
Network location Bypass for SharePoint Online
XSS in Teams dial in web application
Congratulations to Juan Garrido, as well as all of the MSRC Office Security Researcher Leaders for 2022 Q1!
Juan has also written several technical books and security tools including VOYEUR and AZUCAR, has been recognized by Microsoft as MVP for over five years, and has spoken at many renowned conferences including RootedCon, DEFCON, GsickMinds, BlackHat, BSides and Troopers.
In April and May 2022, NCC Group Cryptography Services engaged in a security and cryptography assessment reviewing Microsoft’s contributions to the go-cose library, a Go library implementing signing and verification for CBOR Object Signing and Encryption (COSE), as specified in RFC 8152. This library focuses on a minimal feature set to enable the signing and verification of COSE messages using a single signer, aka “sign1”. The purpose of this assessment was to identify cryptographic vulnerabilities and application-level security issues that could adversely affect the security of the go-cose library.
The Public Report for this review may be downloaded below:
Vendor: Bluetooth SIG, Inc.
Vendor URL: https://www.bluetooth.com
Versions Affected: Specification versions 4.0 to 5.3
Systems Affected: Any systems relying on the presence of a Bluetooth LE connection as confirmation of physical proximity, regardless of whether link layer encryption is used
Author: <Sultan Qasim Khan> <sultan.qasimkhan[at]nccgroup[dot]com>
Risk: An attacker can falsely indicate the proximity of Bluetooth LE (BLE) devices to one another through the use of a relay attack. This may enable unauthorized access to devices in BLE-based proximity authentication systems.
Many products implement Bluetooth Low Energy (BLE) based proximity authentication, where the product unlocks or remains unlocked when a trusted BLE device is determined to be nearby. Common examples of such products include automotive Phone-as-a-Key systems, residential smart locks, BLE-based commercial building access control systems, and smartphones and laptops with trusted BLE device functionality. The possibility of relay attacks against BLE proximity authentication has been known for years, but existing public relay attack tooling (based on forwarding GATT requests and responses) introduces detectable levels of latency and is incapable of relaying connections employing link layer encryption. Thus, products commonly attempt to prevent relay attacks by imposing strict GATT response time limits and/or using link layer encryption. Some systems also try to block signal amplification relay attacks through various localization techniques involving triangulation.
NCC Group has developed a tool for conducting a new type of BLE relay attack operating at the link layer, for which added latency is within the range of normal GATT response timing variation, and which is capable of relaying encrypted link layer communications. This approach can circumvent the existing relay attack mitigations of latency bounding or link layer encryption, and bypass localization defences commonly used against relay attacks that use signal amplification.
If an attacker can place a relaying device within signal range of a target BLE device (Victim Device A) trusted for proximity authentication by another device (Victim Device B), then they can conduct a relay attack to unlock and operate Victim Device B.
Neither normal GATT response latency nor successful communications over an encrypted link layer can be used as indications that a relay attack is not in progress. Consequently, conventional mitigations to prior BLE relay attacks are rendered ineffective against link layer relay attacks.
NCC Group has developed a tool for conducting a new type of Bluetooth Low Energy (BLE) relay attack that can forward link-layer responses within a single connection event and introduces as little as 8 ms of round-trip latency beyond normal operation. As typical connection intervals in proximity authentication system are 30 ms or longer, added latency can generally be limited to a single connection event. With further straightforward refinement of the tool, it would be possible to guarantee that the added response latency is one connection event or less for any connection interval permissible under the Bluetooth specification.
Real BLE devices commonly require multiple connection events to respond to GATT requests or notifications and have inherent variability in their response timing. Thus, the latency introduced by this relay attack falls within the range of normal response timing variation.
Since this relay attack operates at the link layer, it can forward encrypted link layer PDUs. It is also capable of detecting encrypted changes to connection parameters (such as connection interval, WinOffset, PHY mode, and channel map) and continuing to relay connections through parameter changes. Thus, neither link layer encryption nor encrypted connection parameter changes are defences against this type of relay attack.
The Bluetooth Core Specification does not make any claims of relay attack resistance. Furthermore, Section 6 of the Proximity Profile (v1.0.1, updated in 2015) explicitly warns of the possibility of relay attacks, noting that proximity indicated by a BLE connection “should not be used as the only protection of valuable assets.” However, many members of the Bluetooth SIG have produced BLE proximity authentication systems intended for security critical applications, and some make claims of relay attack resistance while still being at risk. Makers of such systems and their applications are also commonly promoted ,,, on the Bluetooth SIG Blog despite the documented risks.
NCC Group recommends that the SIG proactively advise its members developing proximity authentication systems about the risks of BLE relay attacks. Moreover, documentation should make clear that relay attacks are practical and must be included in threat models, and that neither link layer encryption nor expectations of normal response timing are defences against relay attacks. Developers should be encouraged to either require user interaction on the mobile device to authorize unlock, or adopt a time-of-flight based secure ranging (distance bounding) solution using technologies such as Ultra-Wide Band (UWB). For existing systems where hardware modification is not feasible, NCC Group recommends that end users be educated about the risks of relay attacks and presented with an option to disable passive entry functionality that relies on inferred proximity alone. Risk can also be reduced by disabling passive unlock functionality when the user’s mobile device has been stationary for more than a minute (as measured by accelerometer readings).
April 4, 2022: Disclosure to Bluetooth SIG
April 19, 2022: Response from Bluetooth SIG confirming that relay attacks are a known risk, and that more accurate ranging mechanisms are under development.
April 19, 2022: Follow up message to Bluetooth SIG clarifying certain details of relay attack based on questions from the SIG.
May 15, 2022: Advisory released to public
Jeremy Boone for his support and guidance throughout the research process developing this attack.
About NCC Group
NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate & respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.
During the autumn of 2021, Google engaged NCC Group to perform a review of the Android 12 Enterprise API to evaluate its compliance with the Security Technical Implementation Guides (STIG) matrix provided by Google.
This assessment was also performed with reference to the Common Criteria Protection Profile for Mobile Device Fundamentals (PPMDF), from which the STIG was derived.
Due to the limited nature of the testing, certain elements of the STIG requirements are expected to be covered separately either via FIPS 140-2 or Common Criteria Evaluation.
The Public Report for this review may be downloaded below:
This month, members of NCC Group will be presenting their work at the following conferences:
Juan Garrido, “Microsoft 365 APIs Edge Cases for Fun and Profit,” to be presented at RootedCon (March 10-12 2022)
Jennifer Fernick (NCC Group), Christopher Robinson (Intel), & Anne Bertucio (Google), “Preparing for Zero-Day: Vulnerability Disclosure in Open Source Software,” to be presented at FOSS Backstage (March 17-18 2022)
Alma Rinasz, “You Got This: Stories of Career Pivots and How You Can Successfully Start Your Cyber Career,” to be presented at WiCys 2022 (March 17-19 2022)
James Chambers , “Reversing the Pokémon Snap Station without a Snap Station”, to be presented at ShmooCon (March 24-26 2022)
In this talk we describe and demonstrate multiple techniques for circumventing existing Microsoft 365 application security controls and how data can be exfiltrated from highly secure Microsoft 365 tenants which employ strict security policies.
That is, Microsoft 365 tenants with application policies to restrict access to a range of predefined IP addresses or subnets, or configured with Conditional Access Policies, which are used to control access to cloud applications. Assuming a Microsoft 365 configuration has enforced these types of security policy, we show how it can be possible to bypass these security features and exfiltrate information from multiple Microsoft 365 applications, such as OneDrive for Business, SharePoint Online, Yammer or even Exchange Online.
Open source software is incredibly powerful – and while that power is often used for good, it can be weaponized when open-source projects contain software security flaws that attackers can use to compromise those systems, or even the entire software supply chains that those systems are a part of. The Open Source Security Foundation is an open, cross-industry group aimed at improving the security of the open source ecosystem. In this presentation, members of the OpenSSF Vulnerability Disclosure working group will be sharing with open-source maintainers advice on how to handle when researchers disclose vulnerabilities in your project’s codebase – and we’ll also take any questions you have about this often mysterious topic!
Part 1 of this presentation will give an overview of the basics of Coordinated Vulnerability Disclosure (CVD) for open-source software maintainers, including some basics about security vulnerabilities, how to communicate securely and write patches without leaking vulnerability information, what you can expect during a disclosure with a researcher, and how to handle challenging scenarios like when you can’t patch, when a vulnerability is already being exploited by a threat actor in the wild, or when a vulnerability impacts many downstream dependencies.
Part 2 of this presentation will include a discussion about vulnerability disclosure best practices, pitfalls, and challenges. We will also welcome questions from the audience – ask us anything about dealing with vulnerabilities in open source!
A panel of four women, none started in cybersecurity, and all have successfully pivoted to the industry, will be moderated by another cybersecurity professional who also has her own story to share, she had a long career gap and then returned to cybersecurity. Emphasis and care were given to put together a diverse panel with a variety of backgrounds, experiences, and also a belief in #ShareTheMic. Two panelists are veterans and two panelists are BIPOC. Each panelist has her own story, but there are common threads of collaboration, curiosity, and determination. Questions will be carefully crafted in order to deliver a nuanced perspective to the audience. The hope is that the conference attendees have takeaways regarding representation (they can see themselves in the panel) as well as concrete ideas for how to pivot (if applicable), start in cyber, and be successful in the industry. The panel will end with time for a question and answer session this way attendees will have time for any questions they might have as well as the ability to network and get to know the panelists more. All panelists are involved in WiCySand encouraging women in tech and women in cybersecurity, so part of the focus of the panel will be to encourage the attendees that they too can be successful wherever they are in their journey. You’ve got this!
Back in 1999 when the original Pokémon Snap was released for Nintendo 64, one of its coolest features was that you could head to a local Blockbuster and use a “Snap Station” to print out stickers of the photos you took in-game. Snap Stations are now rare collector’s items that few have access to, rendering the printing feature inaccessible.
Learning that they consisted of a Nintendo 64 console hooked up to a printer via video cables and a controller port, I set out to reverse engineer Pokémon Snap to see if I could restore the print functionality without access to the original kiosk hardware. This project involved a combination of software and hardware reverse engineering, facilitated by using an FPGA to make a physical link interface for Nintendo’s proprietary Joy Bus protocol. The resulting FPGA- based tool can also be used to simulate and interface with other peripherals, such as the Transfer Pak accessory which can be used to dump Game Boy cartridge data.
This presentation will demonstrate the reverse engineering and tooling processes, including tips on how hackers with a software background can go from following basic FPGA tutorials to creating real world hardware hacking tools.
During October 2021, O(1) Labs engaged NCC Group’s Cryptography Services team to conduct a cryptography and implementation review of selected components within the main source code repository for the Mina project. Mina implements a cryptocurrency with a lightweight and constant-sized blockchain, where the code is primarily written in OCaml. The selected components involved the client SDK, private/public key functionality, Schnorr signature logic and several other related functions. Full access to source code was provided with support over Discord, and two consultants delivered the engagement with eight person-days of effort.
The Public Report for this review may be downloaded below: