🔒
There are new articles available, click to refresh the page.
Yesterday — 1 July 2022Vulnerabily Research

How CrowdStrike’s Machine Learning Model Automation Uses the Cloud to Maximize Detection Efficacy

1 July 2022 at 13:41
  • The CrowdStrike Falcon® platform takes full advantage of the power of the CrowdStrike Security Cloud to reduce high-cost false positives and maximize detection efficacy to stop breaches 
  • CrowdStrike continuously explores novel approaches to improve machine learning automated detection and protection capabilities for Falcon customers
  • CrowdStrike’s cloud-based machine learning model automation can predict 500,000 feature vectors every second and cover 10TB of files per second to find detections

 At CrowdStrike, we combine cloud scale with machine learning expertise to improve the efficacy of our machine learning models. One method for achieving that involves scanning massive numbers of files that we may not even have in our sample collections before we release our machine learning models. This prerelease scan allows us to maximize the efficacy of our machine learning models while minimizing negative impact of new or updated model releases.

It’s important to understand that machine learning models take over when discrete algorithms fall short. CrowdStrike machine learning does an excellent job of creating models that can detect impactful in-the-wild novel threats like NotPetya, BadRabbit or HermeticWiper along with other malware families. CrowdStrike’s comprehensive detection capabilities have been consistently validated in independent third-party testing from leading organizations including AV-Comparatives. However, machine learning looks at the world through probabilities, and those probabilities can make understanding why an incorrect detection was made unpredictable and difficult to understand.

Incorrect detections, also known as false positives, are a concern with any endpoint security solution and exacerbate the ongoing skills shortage most organizations face. Any incorrect assessment of a clean file as malicious can immediately trigger remediation procedures that can take down services, disrupt workflows and distract analysts from hunting down legitimate threats. However, not all false positives are created equal, for the cost of any mistakes should be compared to the benefit given by correct detections. CrowdStrike has implemented novel solutions to the false positive predicament.

Clean or Dirty: Know the Difference

One approach involves accumulating billions of files in our cloud. These files come from various sources, ranging from protected environments to public malware collections, at a rate of approximately 86 million new hashes a day. The collection includes malicious code, clean code and unwanted code, such as potentially unwanted programs. 

To build our machine learning models, we carefully curate both clean and “dirty” (i.e., malicious) samples from this collection, resulting in a labeled collection that is growing by tens of millions of new examples every training cycle.

Extract the Right Features

To ensure the quality of the resulting models, we also gather from live environments the most interesting files to maximize the efficacy of the model. While some customers use the Falcon platform to share files with us so we can improve our coverage capabilities, others keep their files in-house for a variety of reasons. As a consequence, to build an effective model, we must ensure that it can perform well on in-house files not shared with us as well as on those that have been shared. However, to teach a machine learning model, first you must reduce these interesting files to a long list of transformed numeric values, called a feature vector, that represent various properties of the file. 

As humans, we learn to use our senses to extract features from the surrounding environment and then infer probable outcomes based on past experience. For example, if it’s cloudy outside and there’s a damp breeze, we infer there’s a high chance of rain and we need to grab an umbrella. In this case, cloudy and damp can be considered data points part of the feature vector that describes chances of rain. 

Of course, the feature list for files contains thousands of decimal numbers that humans can’t read but our artificial intelligence (AI) understands. That feature vector is uploaded to the cloud by the Falcon sensor, making it possible for us to observe what a new model would say about the underlying file by running predictions over that stored feature vector.

Figure 1. This flow describes how feature vectors and metadata are sent to the CrowdStrike Security Cloud and used against our machine learning model to help build better predictions.

Returning to the rain example, the feature vector with the two data points of cloudy and damp is assessed against what we know from experience to be signs of rain. If our experience has taught us that these two particular data points have a high probability of describing chances of rain, then we grab an umbrella. Otherwise, we assess this with low chances of rain. Much like machine learning models, it comes down to how well we are trained in spotting and recognizing signs of rain.

Measure Efficacy, Get It Right!

The same file feature vector can also be combined with additional information such as the prevalence of files that is contained within our security cloud. This means we can virtually scan all prevalent files in protected environments to measure efficacy and test for false positives. 

The results of this virtual scan are important for a number of reasons. First, it enables us to identify important files which will have a high impact in the next model release.  Second, we can minimize potential high-cost false positives prior to deployment.  Finally, this information is used to teach future models. 

For example, based on a prevalence threshold, we advance our scan to include all files found on a significant number of devices. We then consider all of our detections. Those that are incorrect we resolve with our cloud by replying to our sensors to prevent future detection, and include the files that triggered an incorrect detection in the next retrain of our model. Correct detections, on the other hand, are added both to our cloud for immediate detection and to the files used in training our models in the future. 

Again, returning to the rain example, this virtual scan is like checking multiple weather forecasting websites as soon as we have the two signs — cloudy and damp — before leaving the house with or without an umbrella. Some of those websites may be correct in predicting rain, others may not, but the next time it’s cloudy and damp we will know which websites are reliable before we go outside and risk being caught in the rain without an umbrella.

CrowdStrike’s Automated Cloud-Based Machine Learning Model Maximizes Efficacy

While CrowdStrike analysts inspect millions of files, the number of files detected as malicious is remarkably small enough that they can be analyzed by hand. Because our analysts and processes work better on samples that we have instead of information about samples, we start our analysis with those detections we can also find in our massive sample store. 

Using feature vectors, the Falcon platform enables us to know quite a bit about the files we don’t have, and also allows us to use the power of the cloud to enhance detection or resolve incorrect detections of files not contained in our sample store.

Comparing global virtual scans of prevalent files against all of our static detection models is critical in pushing the accuracy and efficacy of our machine learning models to help secure our customers and stop breaches.

In essence, the power of the Falcon platform lies in its ability to take full advantage of the massive data fabric we call the CrowdStrike Security Cloud, which correlates trillions of security events from protected endpoints with threat intelligence and enterprise telemetry. The Falcon platform uses machine learning and AI to automate and maximize the efficacy of detecting and protecting against threats, to stop breaches.

Additional Resources

Russia-Ukraine War, Cyberwarfare, and the Impact on Businesses Worldwide

29 June 2022 at 21:13

With the ongoing conflict in Ukraine, we are here to shed some light on the cyberattacks going on between Russia and Ukraine, how it is shaping the geopolitical landscapes, and the cybersecurity impact the war is having on organizations and businesses around the world.

The post Russia-Ukraine War, Cyberwarfare, and the Impact on Businesses Worldwide appeared first on VerSprite.

Before yesterdayVulnerabily Research

Technical Advisory – ExpressLRS vulnerabilities allow for hijack of control link

30 June 2022 at 18:15
 Vendor: ExpressLRS
 Vendor URL: https://expresslrs.org
 Versions affected: 1.x, 2.x
 Author: Richard Appleby
 Severity: Medium 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

ExpressLRS is a high-performance open source radio control link. It aims to provide a low latency radio control link while also achieving maximum range. It runs on a wide variety of hardware in both 900 Mhz and 2.4 GHz frequencies. ExpressLRS is very popular in FPV drone racing and other remote control aircraft.

Using only a standard ExpressLRS compatible transmitter, it is possible to take control of any receiver after observing traffic from a corresponding transmitter.

ExpressLRS uses a ‘binding phrase’, built into the firmware at compile time to bind a transmitter to a receiver. ExpressLRS states that the binding phrase is not for security, it is anti-collision.

Due to weaknesses related to the binding phase, it is possible to extract part of the identifier shared between the receiver and transmitter. A combination of analysis and brute force can be utilised to determine the remaining portion of the identifier. Once the full identifier is discovered, it is then possible to use an attacker’s transmitter to control the craft containing the receiver with no knowledge of the binding phrase. This is possible entirely in software using standard ExpressLRS compatible hardware.

Impact

This attack could result in full control over the target craft. An aircraft already in the air would likely experience control issues causing a crash.

Details

The binding phrase is passed through the MD5 cryptographic hash algorithm to obtain a unique byte sequence. Of this sequence, the first 6 bytes are stored as a shared UID between the receiver and the transmitter. The last four bytes of the UID are used as a seed to generate a random frequency hopping spread spectrum (FHSS) sequence. Both the transmitter and receiver hop between frequencies in the FHSS sequence in sync.

A ‘sync’ packet is sent from the transmitter to the receiver to at the start of a connection and at regular intervals through the FHSS sequence. CRC checks, initialised using the last two bytes of the UID are used to ensure that packets has been received intact.

The following diagram indicates the relationship between these elements.

Three weaknesses were identified, which allow for the discovery of the four bytes of the required UID to take control of the link.

Two of these issues relate to the contents of the sync packet.

  1. The sync packet contains the final three bytes of the UID. These bytes are used to verify that the transmitter has the same binding phrase as the receiver, to avoid collision. Observation of a single sync packet therefor gives 75% of the bytes required to take over the link.
  2. The CRC initialiser uses the final two bytes of the UID sent with the sync packet, making it extremely easy to create a CRC check.

The combination of these two issues means that only one byte is unknown from the UID used to generate the FHSS sequence. To find the last byte, all possible byte values were used to create 256 different possible FHSS sequences. The third weakness occurs in the FHSS sequence generation.

  1. Due to weaknesses in the random number generator, the second 128 values of the final byte of the 4 byte seed produce the same FHSS sequence as the first 128.

By choosing a frequency from the FHSS sequence, and observing the timings relative to a received sync packet, it is possible to determine which entries in the brute forced 128 FHSS sequences correlate with the final byte of the UID.

Once the final UID byte is discovered, the UID can be set in the transmitter and it will connect with the receiver.

It is acknowledged that the FHSS sequence can also be discovered by observing packets over the air without brute forcing the sequences, but that this can be more time consuming and error prone.

Recommendations

The security of the ExpressLRS can be improved with the following changes.

  1. Do not send the UID over the control link. The data used to generate the FHSS sequence should not be sent over the air.
  2. Improve the random number generator. This could involve using a more secure algorithm, or adjusting the existing algorithm to work around repeated sequences.

Disclosure Timeline

  • December 1, 2021: Initial contact with ExpressLRS Github repository owner
  • February 3, 2022: Technical advisory draft sent to repository owner
  • February 8, 2022: Github pull request for patch submitted to repository: https://github.com/ExpressLRS/ExpressLRS/pull/1411
  • February 9/10, 2022: Discussions regarding size of pull request and effectiveness between ExpressLRS developer and NCC Group
  • March 4, 2022: Github pull request submitted to ExpressLRS which addressed size issues
  • March 5, 2022: Pull request rejected by ExpressLRS maintainer; differing opinions between NCC and developers
  • June 30 2022: Advisory published

Tales from the Dark Web: How Tracking eCrime’s Underground Economy Improves Defenses

30 June 2022 at 19:46

Cybercriminals are constantly evolving their operations, the methods they use to breach an organization’s defenses and their tactics for monetizing their efforts. 

In the CrowdStrike 2022 Global Threat Report, we examined how the frequency and sophistication of ransomware attacks has grown in the past year. CrowdStrike Intelligence observed an 82% increase in ransomware-related data leaks in 2021 compared with 2020; further, we found 62% of attacks use hands-on-keyboard activity — indicating adversaries continuously advance their tradecraft to bypass legacy security solutions and extort victims via highly targeted data leaks. What are the forces driving this growth, and how exactly do cybercriminals make money?

The Fast-Growing, Lucrative Business Model Enabled by RaaS

Ransomware is not new; adversarial groups have relied on compromises for many years. However, over the past 2-3 years, their strategy has started to shift toward a more community based business model enabled by ransomware-as-a-service (RaaS) platforms that allow smaller, less advanced criminals to join a larger operation. 

At the top of this model is an operator who sets up a RaaS platform that takes care of multiple technical tasks such as on-demand ransomware packaging, command and control of deployed ransomware, cryptography, data extraction, archiving, online extortion and others. 

Less sophisticated cybercriminals with minimal hacking knowledge can join this operation after being vetted; when they do, they’ll receive 70 to 80% of the paid ransom. These emerging criminals are also assisted by access brokers, through which they can acquire access to the infrastructure of a potential victim. The interaction between all these criminal entities — RaaS operators, vetted affiliates, access brokers and other participants — happen via criminal forums, underground markets and anonymous posts. CrowdStrike continuously monitors these environments, and users may receive alerts regarding market and forum activity.

Access Brokers: How Adversaries Get In

The eCrime kill chain is often enabled by access brokers, the intruders who gain access to an organization’s infrastructure and then sell illicitly obtained credentials and other access methods to buyers in underground communities.

Adversaries buy compromised credentials to make the process of getting into a target organization easier and more efficient. Access brokers sell a broad range of access types, including financial account logins, business email account credentials, remote access to network assets and custom exploits for IT infrastructure.

To advertise compromised credentials and other access methods on the underground, access brokers use particular keywords and target specific marketplaces. However, their posts often leave behind “breadcrumbs” that offer defenders an opportunity to detect compromised accounts or risks of security incidents. For example, an access broker may include attributes such as company details (size, revenue, industry), IT infrastructure details, the malware used to steal credentials, or the access broker’s alias.

The amount of chatter on underground forums is massive. CrowdStrike’s managed service, Falcon X Recon+ provides security teams assistance by offering custom expertise to monitor and triage threats found in these forums on your behalf. CrowdStrike experts can guide organizations of all sizes to identify unwanted data exposure or threats like account takeovers and brand-targeted attacks. 

Distribution Services: A Force Driving Ransomware

CrowdStrike’s analysis of ransomware campaigns by groups such as Pinchy Spider, also known as REvil, Wizard Spider (Conti) and Carbon Spider (DarkSide) has made it clear the operators behind these campaigns no longer work alone, in particular when compromising assets and injecting the ransomware. Ransomware operators advertise on underground forums to recruit affiliates who can help them distribute ransomware and share the profits. 

These affiliates leverage RaaS infrastructure from the operators. After targeting and compromising a victim’s assets, they drop ransomware from the RaaS platform, set the ransom demand and get 70 to 80% of the ransom payment in return. Victims are often chosen based on the likelihood they’ll be able to afford a ransom; affiliates often calculate ransom payouts based on company revenue and business impact to maximize their profits. 

Operators provide technical services in return for affiliates’ help in distributing ransomware. They may provide a packager to generate customized ransomware so affiliates can distribute over their own channels; cryptographic key management; or internet infrastructure for data exfiltration and storage. They may share payment instructions to receive virtual currencies from victims; secret communication channels to hide affiliates when they talk to victims; and even a help desk to aid victims in paying the ransom. These services give a boost to less tech-savvy adversaries, who benefit from access to technically advanced malware at low cost. 

CrowdStrike Intelligence analysts found multiple initial access and lateral movement techniques that affiliates use before deploying ransomware. By changing how they distribute ransomware, adversaries can find new ways to bypass security measures. Below are a few examples of how attackers gain initial access:

  • Buying stolen credentials from access brokers. Affiliates often use legitimate  credentials to gain a foothold. Remote Desktop Protocol (RDP) is a popular entryway.
  • Spam or social engineering. Among the most common initial access vectors.
  • Vulnerability scanning and exploit kits. These kits can be found on multiple forums and target specific software or systems to gain access and install additional code . Exploit kits can be combined with phishing campaigns to boost their effectiveness.
  • Loader and botnet usage. Loaders, often a step between phishing campaigns and ransomware deployment, use malicious documents like macro-enabled spreadsheets to download and execute malicious code.
  • Post-exploitation tools and “living off the land.” Adversaries that access a system will explore the network to find critical data or applications that can help further an attack. Some use system tools like PSExec or PowerShell scripts to remain hidden.

A better understanding of adversary techniques can help improve your defenses. Organizations must know which attackers are targeting their region or industry, whether they are recruiting affiliates, and how their ransomware is distributed.By understanding the adversary and their tools, defenders can employ an intelligence-first defense strategy based on the threats they face.

Monetization: How Cybercrime Pays

Once ransomware is deployed into a victim environment, the prize needs to be split and monetized into other payment forms. CrowdStrike’s observations of the cybercrime ecosystem offer new insights into adversaries, their transactions and valuation of recent compromises — all of which can help defenders understand how money flows in cybercrime and strengthen their security strategies.

Adversaries constantly evolve their monetization techniques to maximize the chance of payment. Their methods are working: reports from the U.S. Treasury Department’s Financial Crimes Enforcement Network (FinCen) and the Office of Foreign Assets Control (OFAC) underscore how lucrative ransomware has become. FinCen found the value of suspicious activity detailed in ransomware-related suspicious activity reports (SARs) was $590 million USD in the first six months of 2021 — far higher than the $416 million USD reported in all of 2020. Further, CrowdStrike’s Intelligence team also tracks ransomware demands: in 2021, we calculated an average demand of $6.1 million USD, an increase of 36% from 2020. 

If a victim refuses to pay ransom, their data may be auctioned by the threat actor so they can still make money on it by selling it to other parties or adversaries.

Corporate data is valuable to all adversaries. Once they have it, the data can be easily monetized and present increased risk to your organization if other attackers have access to it. Defenders must develop a stronger understanding of cybercriminals’ behavior — and the broader eCrime ecosystem — in order to make smarter security decisions that best protect data as their most valuable asset.

In the “Tales from the Dark Web” white paper series, we explore the increased specialization of adversaries inside the criminal underground. This includes the changing tradecraft for gaining initial access, achieving lateral movement, exfiltrating data and leveraging it to extort their targets. By understanding how adversaries specialize in these critical areas to gain scale and efficiency, organizations can better prepare their defenses. 

Rather than simply illustrate the problems defenders face, the insights from these white papers will arm security teams with actionable information, enabling them to better prepare for the attacks emerging from the criminal underground. 

Additional Resources

Threat Source newsletter (June 30, 2022) — AI voice cloning is somehow more scary than deepfake videos

By Jon Munshaw.  Welcome to this week’s edition of the Threat Source newsletter.  We took a week off for summer vacation but are back in the thick of security things now.  My first exposure to deepfake videos was when Jordan Peele worked with BuzzFeed News to produce this video of...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Vulnerability Spotlight: Command injection vulnerabilities in Robustel cellular router

Lilith >_> of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw.  Cisco Talos recently discovered four vulnerabilities in the Robustel R1510 industrial cellular router.  The R1510 is a portable router that shares 2G, 3G and 4G wireless internet access. It comes with...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

2022 0-day In-the-Wild Exploitation…so far

30 June 2022 at 13:00

Posted by Maddie Stone, Google Project Zero

This blog post is an overview of a talk, “ 0-day In-the-Wild Exploitation in 2022…so far”, that I gave at the FIRST conference in June 2022. The slides are available here.

For the last three years, we’ve published annual year-in-review reports of 0-days found exploited in the wild. The most recent of these reports is the 2021 Year in Review report, which we published just a few months ago in April. While we plan to stick with that annual cadence, we’re publishing a little bonus report today looking at the in-the-wild 0-days detected and disclosed in the first half of 2022.        

As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022. When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests. On top of that, four of the 2022 0-days are variants of 2021 in-the-wild 0-days. Just 12 months from the original in-the-wild 0-day being patched, attackers came back with a variant of the original bug.  

Product

2022 ITW 0-day

Variant

Windows win32k

CVE-2022-21882

CVE-2021-1732 (2021 itw)

iOS IOMobileFrameBuffer

CVE-2022-22587

CVE-2021-30983 (2021 itw)

Windows

CVE-2022-30190 (“Follina”)

CVE-2021-40444 (2021 itw)

Chromium property access interceptors

CVE-2022-1096

CVE-2016-5128 CVE-2021-30551 (2021 itw) CVE-2022-1232 (Addresses incomplete CVE-2022-1096 fix)

Chromium v8

CVE-2022-1364

CVE-2021-21195

WebKit

CVE-2022-22620 (“Zombie”)

Bug was originally fixed in 2013, patch was regressed in 2016

Google Pixel

CVE-2021-39793*

* While this CVE says 2021, the bug was patched and disclosed in 2022

Linux same bug in a different subsystem

Atlassian Confluence

CVE-2022-26134

CVE-2021-26084

Windows

CVE-2022-26925 (“PetitPotam”)

CVE-2021-36942 (Patch regressed)

So, what does this mean?

When people think of 0-day exploits, they often think that these exploits are so technologically advanced that there’s no hope to catch and prevent them. The data paints a different picture. At least half of the 0-days we’ve seen so far this year are closely related to bugs we’ve seen before. Our conclusion and findings in the 2020 year-in-review report were very similar.

Many of the 2022 in-the-wild 0-days are due to the previous vulnerability not being fully patched. In the case of the Windows win32k and the Chromium property access interceptor bugs, the execution flow that the proof-of-concept exploits took were patched, but the root cause issue was not addressed: attackers were able to come back and trigger the original vulnerability through a different path. And in the case of the WebKit and Windows PetitPotam issues, the original vulnerability had previously been patched, but at some point regressed so that attackers could exploit the same vulnerability again. In the iOS IOMobileFrameBuffer bug, a buffer overflow was addressed by checking that a size was less than a certain number, but it didn’t check a minimum bound on that size. For more detailed explanations of three of the 0-days and how they relate to their variants, please see the slides from the talk.

When 0-day exploits are detected in-the-wild, it’s the failure case for an attacker. It’s a gift for us security defenders to learn as much as we can and take actions to ensure that that vector can’t be used again. The goal is to force attackers to start from scratch each time we detect one of their exploits: they’re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. To do that effectively, we need correct and comprehensive fixes.

This is not to minimize the challenges faced by security teams responsible for responding to vulnerability reports. As we said in our 2020 year in review report:

Being able to correctly and comprehensively patch isn't just flicking a switch: it requires investment, prioritization, and planning. It also requires developing a patching process that balances both protecting users quickly and ensuring it is comprehensive, which can at times be in tension. While we expect that none of this will come as a surprise to security teams in an organization, this analysis is a good reminder that there is still more work to be done.

Exactly what investments are likely required depends on each unique situation, but we see some common themes around staffing/resourcing, incentive structures, process maturity, automation/testing, release cadence, and partnerships.

 

Practically, some of the following efforts can help ensure bugs are correctly and comprehensively fixed. Project Zero plans to continue to help with the following efforts, but we hope and encourage platform security teams and other independent security researchers to invest in these types of analyses as well:

  • Root cause analysis

Understanding the underlying vulnerability that is being exploited. Also tries to understand how that vulnerability may have been introduced. Performing a root cause analysis can help ensure that a fix is addressing the underlying vulnerability and not just breaking the proof-of-concept. Root cause analysis is generally a pre-requisite for successful variant and patch analysis.

  • Variant analysis

Looking for other vulnerabilities similar to the reported vulnerability. This can involve looking for the same bug pattern elsewhere, more thoroughly auditing the component that contained the vulnerability, modifying fuzzers to understand why they didn’t find the vulnerability previously, etc. Most researchers find more than one vulnerability at the same time. By finding and fixing the related variants, attackers are not able to simply “plug and play” with a new vulnerability once the original is patched.

  • Patch analysis

Analyzing the proposed (or released) patch for completeness compared to the root cause vulnerability. I encourage vendors to share how they plan to address the vulnerability with the vulnerability reporter early so the reporter can analyze whether the patch comprehensively addresses the root cause of the vulnerability, alongside the vendor’s own internal analysis.

  • Exploit technique analysis

Understanding the primitive gained from the vulnerability and how it’s being used. While it’s generally industry-standard to patch vulnerabilities, mitigating exploit techniques doesn’t happen as frequently. While not every exploit technique will always be able to be mitigated, the hope is that it will become the default rather than the exception. Exploit samples will need to be shared more readily in order for vendors and security researchers to be able to perform exploit technique analysis.

Transparently sharing these analyses helps the industry as a whole as well. We publish our analyses at this repository. We encourage vendors and others to publish theirs as well. This allows developers and security professionals to better understand what the attackers already know about these bugs, which hopefully leads to even better solutions and security overall.  

Enforcing a Sysmon Archive Quota

30 June 2022 at 12:19

Sysmon (System Monitor) is a well-known and widely used Windows logging utility providing valuable visibility into core OS (operating system) events. From a defender’s perspective, the presence of Sysmon in an environment greatly enhances detection and forensic capabilities by logging events involving processes, files, registry, network connections and more.

Since Sysmon 11 (released April 2020), the FileDelete event provides the capability to retain (archive) deleted files, a feature we especially adore during active compromises when actors drop-use-delete tools. However, as duly noted in Sysmon’s documentation, the usage of the archiving feature might grow the archive directory to unreasonable sizes (hundreds of GB); something most environments cannot afford.

This blog post will cover how, through a Windows-native feature (WMI event consumption), the Sysmon archive can be kept at a reasonable size. In a hurry? Go straight to the proof of concept!

Figure 1: A Sysmon archive quota removing old files.

The Challenge of Sysmon File Archiving

Typical Sysmon deployments require repeated fine-tuning to ensure optimized performance. When responding to hands-on-keyboard attackers, this time-consuming process is commonly replaced by relying on robust base-lined configurations (some of which open-source such as SwiftOnSecurity/sysmon-config or olafhartong/sysmon-modular). While most misconfigured events have at worst an impact on CPU and log storage, the Sysmon file archiving can grind a system to a halt by exhausting all available storage. So how could one still perform file archiving without risking an outage?

While searching for a solution, we defined some acceptance requirements. Ideally, the solution should…

  • Be Windows-native. We weren’t looking for yet another agent/driver which consumes resources, may cause compatibility issues and increase the attack surface.
  • Be FIFO-like (First In, First Out) to ensure the oldest archived files are deleted first. This ensures attacker tools are kept in the archive just long enough for our incident responders to grab them.
  • Have a minimal system performance impact if we want file archiving to be usable in production.

A common proposed solution would be to rely on a scheduled task to perform some clean-up activities. While being Windows-native, this execution method is “dumb” (schedule-based) and would execute even without files being archived.

So how about WMI event consumption?

WMI Event Consumption

WMI (Windows Management Instrumentation) is a Windows-native component providing capabilities surrounding the OS’ management data and operations. You can for example use it to read and write configuration settings related to Windows, or monitor operations such as process and file creations.

Within the WMI architecture lays the permanent event consumer.

You may want to write an application that can react to events at any time. For example, an administrator may want to receive an email message when specific performance measures decline on network servers. In this case, your application should run at all times. However, running an application continuously is not an efficient use of system resources. Instead, WMI allows you to create a permanent event consumer. […]

A permanent event consumer receives events until its registration is explicitly canceled.

docs.microsoft.com

Leveraging a permanent event consumer to monitor for file events within the Sysmon archive folder would provide optimized event-based execution as opposed to the scheduled task approach.

In the following sections we will start by creating a WMI event filter intended to select events of interest; after which we will cover the WMI logical consumer whose role will be to clean up the Sysmon archive.

WMI Event Filter

A WMI event filter is an __EventFilter instance containing a WQL (WMI Query Language, SQL for WMI) statement whose role is to filter event tables for the desired events. In our case, we want to be notified when files are being created in the Sysmon archive folder.

Whenever files are created, a CIM_DataFile intrinsic event is fired within the __InstanceCreationEvent class. The following WQL statement would filter for such events within the default C:\Sysmon\ archive folder:

SELECT * FROM __InstanceCreationEvent
WHERE TargetInstance ISA 'CIM_DataFile'
	AND TargetInstance.Drive='C:'
	AND TargetInstance.Path='\\Sysmon\\'

Intrinsic events are polled at specific intervals. As we wish to ensure the polling period is not too long, a WITHIN clause can be used to define the maximum amount of seconds that can pass before the notification of the event must be delivered.

The beneath query requires matching event notifications to be delivered within 10 seconds.

SELECT * FROM __InstanceCreationEvent
WITHIN 10
WHERE TargetInstance ISA 'CIM_DataFile'
	AND TargetInstance.Drive='C:'
	AND TargetInstance.Path='\\Sysmon\\' 

While the above WQL statement is functional, it is not yet optimized. As an example, if Sysmon came to archive 1000 files, the event notification would fire 1000 times, later resulting in our clean-up logic to be executed 1000 times as well.

To cope with this property, a GROUP clause can be used to combine events into a single notification. Furthermore, to ensure the grouping occurs within timely manner, another WITHIN clause can be leveraged. The following WQL statement waits for up to 10 seconds to deliver a single notification should any files have been created in Sysmon’s archive folder.

SELECT * FROM __InstanceCreationEvent
WITHIN 10
WHERE TargetInstance ISA 'CIM_DataFile'
	AND TargetInstance.Drive='C:'
	AND TargetInstance.Path='\\Sysmon\\' 
GROUP WITHIN 10

To create a WMI event filter we can rely on PowerShell’s New-CimInstance cmdlet as shown in the following snippet.

$Archive = "C:\\Sysmon\\"
$Delay = 10
$Filter = New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property @{
    Name = 'SysmonArchiveWatcher';
    EventNameSpace = 'root\cimv2';
    QueryLanguage = "WQL";
    Query = "SELECT * FROM __InstanceCreationEvent WITHIN $Delay WHERE TargetInstance ISA 'CIM_DataFile' AND TargetInstance.Drive='$(Split-Path -Path $Archive -Qualifier)' AND TargetInstance.Path='$(Split-Path -Path $Archive -NoQualifier)' GROUP WITHIN $Delay"
}

WMI Logical Consumer

The WMI logical consumer will consume WMI events and undertake actions for each occurrence. Multiple logical consumer classes exist providing different behaviors whenever events are received, such as:

The last CommandLineEventConsumer class is particularly interesting as it would allow us to run a PowerShell script whenever files are archived by Sysmon (a feature attackers do enjoy as well).

The first step on our PowerShell code would be to obtain a full list of archived files ordered from oldest to most recent. This list will play two roles:

  1. It will be used to compute the current directory size.
  2. It will be used as a list of files to remove (in FIFO order) until the directory size is back under control.

While getting a list of files is easy through the Get-ChildItem cmdlet, sorting these files from oldest to most recently archived requires some thinking. Where common folders could rely on the file’s CreationTimeUtc property, Sysmon archiving copies this file property over. As a consequence the CreationTimeUtc field is not representative of when a file was archived and relying on it could result in files being incorrectly seen as the oldest archives, causing their premature removal.

Instead of relying on CreationTimeUtc, the alternate LastAccessTimeUtc property provides a more accurate representation of when a file was archived. The following snippet will get all files within the Sysmon archive and order them in a FIFO-like fashion.

$Archived = Get-ChildItem -Path 'C:\\Sysmon\\' -File | Sort-Object -Property LastAccessTimeUtc

Once the archived files listed, the folder size can be computed through the Measure-Object cmdlet.

$Size = ($Archived | Measure-Object -Sum -Property Length).Sum

All that remains to do is then loop the archived files and remove them while the folder exceeds our desired quota.

for($Index = 0; ($Index -lt $Archived.Count) -and ($Size -gt 5GB); $Index++)
{
	$Archived[$Index] | Remove-Item -Force
	$Size -= $Archived[$Index].Length
}

Sysmon & Hard Links

In some situations, Sysmon archives a file by referencing the file’s content from a new path, a process known as hard-linking.

A hard link is the file system representation of a file by which more than one path references a single file in the same volume.

docs.microsoft.com

As an example, the following snippet creates an additional path (hard link) for an executable. Both paths will now point to the same on-disk file content. If one path gets deleted, Sysmon will reference the deleted file by adding a path, resulting in the file’s content having two paths, one of which within the Sysmon archive.

:: Create a hard link for an executable.
C:\>mklink /H C:\Users\Public\NVISO.exe C:\Users\NVISO\Downloads\NVISO.exe
Hardlink created for C:\Users\Public\NVISO.exe <<===>> C:\Users\NVISO\Downloads\NVISO.exe

:: Delete one of the hard links causing Sysmon to archive the file.
C:\>del C:\Users\NVISO\Downloads\NVISO.exe

:: The archived file now has two paths, one of which within the Sysmon archive.
C:\>fsutil hardlink list Sysmon\B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450.exe
\Sysmon\B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450.exe
\Users\Public\NVISO.exe

The presence of hard links within the Sysmon archive can cause an edge-case should the non-archive path be locked by another process while we attempt to clean the archive. Should for example a process be created from the non-archive path, removing the archived file will become slightly harder.

:: If the other path is locked by a process, deleting it will result in a denied access.
C:\>del Sysmon\B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450.exe
C:\Sysmon\B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450.exe
Access is denied.

Removing hard links is not straight-forward and commonly relies on non-native software such as fsutil (itself requiring the Windows Subsystem for Linux). However, as the archive’s hard link does technically not consume additional storage (the same content is referenced from another path), such files could be ignored given they do not partake in the storage exhaustion. Once the non-archive hard links referencing a Sysmon-archived file are removed, the archived file is not considered a hard link anymore and will be removable again.

To cope with the above edge-case, hard links can be filtered-out and removal operations can be encapsulated in try/catch expressions should other edge-cases exists. Overall, the WMI logical consumer’s logic could look as follow:

$Archived = Get-ChildItem -Path 'C:\\Sysmon\\' -File | Where-Object {$_.LinkType -ne 'HardLink'} | Sort-Object -Property LastAccessTimeUtc
$Size = ($Archived | Measure-Object -Sum -Property Length).Sum
for($Index = 0; ($Index -lt $Archived.Count) -and ($Size -gt 5GB); $Index++)
{
	try
	{
		$Archived[$Index] | Remove-Item -Force -ErrorAction Stop
		$Size -= $Archived[$Index].Length
	} catch {}
}

As we did for the event filter, a WMI consumer can be created through the New-CimInstance cmdlet. The following snippet specifically creates a new CommandLineEventConsumer invoking our above clean-up logic to create a 10GB quota.

$Archive = "C:\\Sysmon\\"
$Limit = 10GB
$Consumer = New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property @{
    Name = 'SysmonArchiveCleaner';
    ExecutablePath = $((Get-Command PowerShell).Source);
    CommandLineTemplate = "-NoLogo -NoProfile -NonInteractive -WindowStyle Hidden -Command `"`$Archived = Get-ChildItem -Path '$Archive' -File | Where-Object {`$_.LinkType -ne 'HardLink'} | Sort-Object -Property LastAccessTimeUtc; `$Size = (`$Archived | Measure-Object -Sum -Property Length).Sum; for(`$Index = 0; (`$Index -lt `$Archived.Count) -and (`$Size -gt $Limit); `$Index++){ try {`$Archived[`$Index] | Remove-Item -Force -ErrorAction Stop; `$Size -= `$Archived[`$Index].Length} catch {}}`""
}

WMI Binding

In the above two sections we defined the event filter and logical consumer. One last point worth noting is that event filters need to be bound to an event consumers in order to become operational. This is done through a __FilterToConsumerBinding instance as shown below.

New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property @{
    Filter = [Ref]$Filter;
    Consumer = [Ref]$Consumer;
}

Proof of Concept

The following proof-of-concept deployment technique has been tested in limited environments. As should be the case with anything you introduce into your environment, make sure rigorous testing is done and don’t just deploy straight to production.

The following PowerShell script creates a WMI event filter and logical consumer with the logic we defined previously before binding them. The script can be configured using the following variables:

  • $Archive as the Sysmon archive path. To be WQL-compliant, special characters have to be back-slash (\) escaped, resulting in double back-slashed directory separators (\\).
  • $Limit as the Sysmon archive’s desired maximum folder size (see real literals).
  • $Delay as the event filter’s maximum WQL delay value in seconds (WITHIN clause).

Do note that Windows security boundaries apply to WMI as well and, given the Sysmon archive directory is restricted to the SYSTEM user, the following script should be ran using the SYSTEM privileges.

$ErrorActionPreference = "Stop"

# Define the Sysmon archive path, desired quota and query delay.
$Archive = "C:\\Sysmon\\"
$Limit = 10GB
$Delay = 10

# Create a WMI filter for files being created within the Sysmon archive.
$Filter = New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property @{
    Name = 'SysmonArchiveWatcher';
    EventNameSpace = 'root\cimv2';
    QueryLanguage = "WQL";
    Query = "SELECT * FROM __InstanceCreationEvent WITHIN $Delay WHERE TargetInstance ISA 'CIM_DataFile' AND TargetInstance.Drive='$(Split-Path -Path $Archive -Qualifier)' AND TargetInstance.Path='$(Split-Path -Path $Archive -NoQualifier)' GROUP WITHIN $Delay"
}

# Create a WMI consumer which will clean up the Sysmon archive folder until the quota is reached.
$Consumer = New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property @{
    Name = 'SysmonArchiveCleaner';
    ExecutablePath = (Get-Command PowerShell).Source;
    CommandLineTemplate = "-NoLogo -NoProfile -NonInteractive -WindowStyle Hidden -Command `"`$Archived = Get-ChildItem -Path '$Archive' -File | Where-Object {`$_.LinkType -ne 'HardLink'} | Sort-Object -Property LastAccessTimeUtc; `$Size = (`$Archived | Measure-Object -Sum -Property Length).Sum; for(`$Index = 0; (`$Index -lt `$Archived.Count) -and (`$Size -gt $Limit); `$Index++){ try {`$Archived[`$Index] | Remove-Item -Force -ErrorAction Stop; `$Size -= `$Archived[`$Index].Length} catch {}}`""
}

# Create a WMI binding from the filter to the consumer.
New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property @{
    Filter = [Ref]$Filter;
    Consumer = [Ref]$Consumer;
}

Once the WMI event consumption configured, the Sysmon archive folder will be kept at reasonable size as shown in the following capture where a 90KB quota has been defined.

Figure 2: A Sysmon archive quota of 90KB removing old files.

With Sysmon archiving under control, we can now happily wait for new attacker tool-kits to be dropped…

JARM指纹随机化技术实现

30 June 2022 at 09:17
By: 风起

作者:风起

时间:2022年6月30日

基于JARM指纹的C2识别

​ JARM的工作原理是主动向目标TLS服务器发送10个特殊构造的TLS Client Hello包,以在TLS服务器中提取独特的响应,并捕获TLS Server Hello响应的特定属性,然后以特定的方式对聚合的TLS服务器响应进行散列,产生JARM指纹。

因为Client Hello中的参数不同,最终返回的Server Hello都是不相同的,通过发送特殊构造的Client Hello握手包,以获取与之对应的特殊Server Hello响应,以此作为依据,最终产生TLS Server指纹。

JARM以不同的顺序发送不同的TLS版本、密码和扩展,以收集唯一的响应。

  • 服务器是否支持TLS 1.3协议?
  • 它会用1.2个密码来协商TLS 1.3吗?
  • 如果我们将密码从弱到强排序,它会选择哪个密码?

这些是JARM本质上要求服务器提取最独特响应的异常问题类型。然后对这10个响应进行哈希处理以产生JARM指纹。

TLS Client Hello请求流量

Wireshark Filter:

ssl.handshake.type == 1
1

TLS Server Hello响应

1

多数情况下JARM指纹都是用以佐证TLS服务并进行标记,从而关联服务。当然,最理想的状态下,我们能够通过JARM指纹唯一的指向目标C2设施,但是实际来讲JARM指纹对于不同服务器部署的C2设施并不是唯一的,有很多因素都会对其扫描的结果造成影响。所以我们并不能作为行为测绘的指纹直接关联到某个C2的服务,仅能作为佐证的效果。

在开发RedGuard的过程中我发现,因为本身来讲RG的作用就是进行前置流量的控制,从而实现后端C2服务的隐匿性,在蓝队对流量交互进行分析的时候,针对RG的JARM指纹扫描结果在多数差异的环境下都是相同的,也就是说,在分析的过程中,这个指纹是可以起到佐证攻击设施的作用,从而破坏我们想要预期达到的隐匿性。

基础设施的更改(例如,IP 地址、托管平台)不会影响JARM签名,这使得常规的方式难以对其进行规避。

影响服务端JARM指纹的因素:

  • 操作系统及版本
  • 使用的库及版本
  • 调用库的顺序
  • 自定义配置
  • ........

也就是说,如果我们想要影响最终针对服务端的JARM指纹扫描结果,我们就要从上面的几个因素入手去做,目前的解决方案共有两种:

一、重播TLS Server Hello响应

二、更改TLS Server配置CipherSuites加密套件

第一种方式也就是在监听特定客户端 Hello 的 TCP 服务器,然后在C2服务器上捕获这些特定的Client Hello(每个请求都有重复的字节,使用这些字节来识别每个特定的Client Hello握手包),稳定的对这10个特殊构造的Client Hello的响应进行重播,从而实现改变真实JARM指纹的效果。

if bytes.Contains(request, [] byte { 
     0x00, 0x8c, 0x1a, 0x1a, 0x00, 0x16, 0x00, 0x33, 0x00, 
     0x67, 0xc0, 0x9e, 0xc0, 0xa2, 0x00, 0x9e, 0x00, 0x39 
     , 0x , 0xc0, 0x9f, 0xc0, 0xa3, 0x00, 0x9f, 0x00, 
     0x45, 0x00, 0xbe, 0x00, 0x88, 0x00, 0xc4, 0x00, 0x9a, 
     ... ... 
}) { 
     fmt.Println("replaying: tls12Forward ") 
     conn.Write([] byte { 
         0x16, 0x03, 0x03, 0x00, 0x5a, 0x02, 0x00, 0x00, 
         0x56, 0x03, 0x03, 0x17, 0xa6, 0xa3, 0x84, 0x80, 
         0x0b, 3,d, 0xbb, 0x 0xe9, 0x3e, 0x92, 0x65, 
         0x9a, 0x68, 0x7d, 0x70, 0xda, 0x00, 0xe9, 0x7c, 
         ... ... 
     }) 
}

在对所有十个不同的请求实施回复后,可以伪造完整的签名。

1

​ 这是一种比较懒惰的办法了,最终的效果确实能够对JARM扫描的结果进行混淆,但是我认为太过单调,需要注意的是ServerHello的原始响应他不能进行任意修改,因为在工具开发中流量的正常交互才是最重要的,任意修改上述一些影响 JARM扫描的因素可能导致无法正常通信的问题出现。也就是说他所重播的这些ServerHello数据包是需要监听某个正常的服务的JARM扫描响应来实现的,并不适合我们应用到工具去实现混淆的效果,我们需要一种简单而又稳定的方法。

当然,这种方式还有一种延伸,就是首先随机获取正常站点的列表进行JARM指纹扫描,从而获取其ServerHello响应然后,直接作为识别到JARM扫描握手包的响应包进行重播,这样是最合理的一种方式。

​ 第二种也就是阿姆斯特丹2021 HITB议题《COMMSEC: JARM Randomizer: Evading JARM Fingerprinting》中提到的一种方式,作者在github上对衍生工具 JARM Randomizer进行了部分开源,通过阅读它的代码不难看出,其实与我最初想到的方式非常相像,最终影响JARM的因素使用的是CipherSuites加密套件(加密算法套件 CipherSuite 由各类基础加密算法组成)**

实现代码:

1

如上图,针对反向代理的TLS Config CipherSuites的设置,我提供了15种不同的加密套件方式,1/2/3....个不同组合的加密套件最终得到的JARM指纹结果都不是相同的(加密套件过多会导致无法正常通信的玄学问题),这里我对这15种加密套件进行随机组合的方式,1-2个随机取值进行组合这些CipherSuites,大概会有几十种不同的随机JARM指纹产生。

最终效果如下:

1

可以看到,最终应用在工具的效果就是在每次启动RG的时候,它的JARM指纹都不是相同的,会自动根据上述的混淆方式产生一个全新的JARM指纹,可以防止空间测绘的扫描,以此关联公网上RG基础设施的部署情况。目前市面上多数测绘平台都会进行集成并默认进行JARM指纹的扫描,可能也是因为其扫描效率快,扫描资源成本低、同时又对C2设施有着一定的佐证指向性的原因吧。

RedGuard是一款C2基础设施前置流量控制设施,可以规避Blue Teams、AVs、EDRs检查。

参考链接:

https://github.com/wikiZ/RedGuard

https://github.com/netskopeoss/jarm_randomizer

https://grimminck.medium.com/spoofing-jarm-signatures-i-am-the-cobalt-strike-server-now-a27bd549fc6b

https://conference.hitb.org/hitbsecconf2021ams/sessions/commsec-jarm-randomizer-evading-jarm-fingerprinting/

Detecting and Mitigating NTLM Relay Attacks Targeting Microsoft Domain Controllers

29 June 2022 at 18:52

Adversaries often exploit legacy protocols like Windows NTLM that unfortunately remain widely deployed despite known vulnerabilities. Previous CrowdStrike blog posts have covered critical vulnerabilities in NTLM that allow remote code execution and other NTLM attacks where attackers could exploit vulnerabilities to bypass MIC (Message Integrity Code) protection, session signing and EPA (Enhanced Protection for Authentication)

The PetitPotam vulnerability, combined with AD-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 the Print 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.

The Released Fix(es) and Remaining Issues

The Microsoft security update released on Patch Tuesday, May 10, 2022, included a partial patch for the PetitPotam vulnerability. This update, however, also caused authentication failures for various Windows services such as Network Policy Server (NPS), Routing and Remote Access Service (RRAS), Radius, Extensible Authentication Protocol (EAP) and Protected Extensible Authentication Protocol (PEAP). According to Microsoft, “An issue has been found related to how the mapping of certificates to machine accounts is being handled by the domain controller.” 

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 the security 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. 

Enhancing CrowdStrike Identity Protection NTLM Relay Detection

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:

  1. 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.
  2. 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.
  3. 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!  
  • Learn how CrowdStrike Falcon Identity Protection reduces costs and risks across the enterprise by protecting workforce identities.
  • 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.
  • Get a full-featured free trial of CrowdStrike Falcon Prevent™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.

Falcon OverWatch Elite in Action: Tailored Threat Hunting Services Provide Individualized Care and Support

29 June 2022 at 18:35

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.

For more information, please visit OverWatch Elite’s page on CrowdStrike’s website.

Additional Resources

Flubot: the evolution of a notorious Android Banking Malware

29 June 2022 at 17:16

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 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.

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.

List of samples by version

0.1 – 5e0311fb1d8dda6b5da28fa3348f108ffa403f3a3cf5a28fc38b12f3cab680a0
0.5 – d3af7d46d491ae625f66451258def5548ee2232d116f77757434dd41f28bac69
1.2 – c322a23ff73d843a725174ad064c53c6d053b6788c8f441bbd42033f8bb9290c
1.7 – 75c2d4abecf1cc95ca8aeb820e65da7a286c8ed9423630498a95137d875dfd28
1.9 – 9420060391323c49217ce5d40c23d3b6de08e277bcf7980afd1ee3ce17733da2
2.1 – 13013d2f96c10b83d79c5b4ecb433e09dbb4f429f6d868d448a257175802f0e9
2.2 – 318e4d4421ce1470da7a23ece3db5e6e4fe9532e07751fc20b1e35d7d7a88ec7
2.8 – f3257b1f0b2ed1d67dfa1e364c4adc488b026ca61c9d9e0530510d73bd1cf77e
3.1 – affaf5f9ba5ea974c605f09a0dd7776d549e5fec2f946057000abe9aae1b3ce1
3.2 – 865aaf13902b312a18abc035f876ad3dfedce5750dba1f2cc72aabd68d6d1c8f
3.4 – ca18a3331632440e9b86ea06513923b48c3d96bc083310229b8c5a0b96e03421
3.5 – 43a2052b87100cf04e67c3c8c400fa203e0e8f08381929c935cff2d1f80f0729
3.6 – fd5f7648d03eec06c447c1c562486df10520b93ad7c9b82fb02bd24b6e1ec98a
3.7 – 1adba4f7a2c9379a653897486e52123d7c83807e0e7e987935441a19eac4ce2c
3.9 – 1cf5c409811bafdc4055435a4a36a6927d0ae0370d5197fcd951b6f347a14326
4.0 – 8e2bd71e4783c80a523317afb02d26cac808179c57834c5c599d976755b1dabd
4.1 – ec3c35f17e539fe617ca2e73da4a51dc8efedda94fd1f8b50a5b77d63e58ba5c
4.2 – 368cebac47e36c81fb2f1d8292c6c89ccb10e3203c5927673ce05ba29562f19c
4.3 – dab4ce5fbb1721f24bbb9909bb59dcc33432ccf259ee2d3a1285f47af478416d
4.4 – 6a03efa4ffa38032edfb5b604672e8c9e01a324f8857b5848e8160593dfb325e
4.5 – f899993c6109753d734b4faaf78630dc95de7ea3db78efa878da7fbfc4aee7cd
4.6 – ffaebdbc8c2ecd63f9b97781bb16edc62b2e91b5c69e56e675f6fbba2d792924
4.7 – a0dd408a893f4bc175f442b9050d2c328a46ff72963e007266d10d26a204f5af
4.8 – a0181864eed9294cac0d278fa0eadabe68b3adb333eeb2e26cc082836f82489d
4.9 – 831334e1e49ec7a25375562688543ee75b2b3cc7352afc019856342def52476b
4.9 – 8c9d7345935d46c1602936934b600bb55fa6127cbdefd343ad5ebf03114dbe45 (DoH tunnel protocol)
5.0 – 08d8dd235769dc19fb062299d749e4a91b19ef5ec532b3ce5d2d3edcc7667799
5.1 – ff2d59e8a0f9999738c83925548817634f8ac49ec8febb20cfd9e4ce0bf8a1e3
5.2 – 4859ab9cd5efbe0d4f63799126110d744a42eff057fa22ff1bd11cb59b49608c
5.3 – e9ff37663a8c6b4cf824fa65a018c739a0a640a2b394954a25686927f69a0dd4
5.4 – df98a8b9f15f4c70505d7c8e0c74b12ea708c084fbbffd5c38424481ae37976f
5.5 – 78d6dc4d6388e1a92a5543b80c038ac66430c7cab3b877eeb0a834bce5cb7c25
5.6 – 16427dc764ddd03c890ccafa61121597ef663cba3e3a58fc6904daf644467a7c

Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List

29 June 2022 at 14:31
By: Cassie

Business Wire: 06/29/22

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.

Read entire article here

The post Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List appeared first on Horizon3.ai.

  • There are no more articles
❌