LevelBlue’s Response to Black Basta Ransomware:

Executive Summary

Between December 2024 and February 2025, the LevelBlue MDR team saw over a dozen attempts and a handful of successful intrusions by threat actors (TAs). Internally, we broadly attribute these attacks to the Black Basta ransomware gang. As outlined by other cybersecurity researchers’ reporting of similar tactics, techniques, and procedures (TTPs) observed; there is a high probability that this activity is from affiliate groups or initial access brokers. The information presented below is a compilation of notes, details, recommendations, and guidance provided to our customers in the last couple of months resulting from dozens of opened investigations and incident response engagements. By taking or recommending system and enterprise changes outlined, organizations can greatly reduce their attack surface, implement a stronger defense-in-depth security model, as well as more quickly detect and thus contain an intrusion by this ever-prevalent threat and many others like it. Read the full whitepaper here.

Initial Access

The TA starts by email bombing specific users in the environment. This can range anywhere from a couple hundred to thousands of spam and junk emails. They then follow up this activity by reaching out to these users via a phone call or a Microsoft Teams message, with chats named some variation of “Help Desk”. The TA tells the user that they have noticed the spam emails and will need access to their machine to remedy the issue. The most common tool used to gain initial access to a victim machine is Microsoft’s Quick Assist, which is pre-installed on Windows 10 and higher. The TA provides the victim a code to use when establishing the connection – once input, the TA will have remote access to the machine and begin establishing persistence after the Quick Assist session is ended. In every case where we observed the execution of Quick Assist, a zip archive was created within the Downloads folder. In reviewing some cases, we’ve observed that the TA has started password protecting zip folders containing tools, but these initial files are not password protected. During the last customer intrusion we responded to, two .cab files were inside the zip, and within the .cab files were the legitimate OneDriveStandaloneUpdater.exe along with a malicious DLL file to be sideloaded and additional files needed for lateral movement.

Figure 1: Creation of a zip archive using cmd exe during the Quick Assist session. The TA extracts the files from the archive with tar:

tar xf wsqf418x4324.zip -C "C:\Users\[REDACTED]\AppData\Local\Temp"

Next, the TA expands the two cab files that were inside:

• expand -i "C:\Users\[REDACTED]\AppData\Local\Temp\symssdifdsook.cab" -F:* "C:\Users\[REDACTED]\AppData\Local\Microsoft\OneDrive"
• expand "C:\Users\[REDACTED]\AppData\Local\Temp\difjsfhcx.cab" -F:* "C:\Users\[REDACTED]\AppData\Local\Microsoft\OneDrive"

After the two .cab files are deleted, the OneDriveStandaloneUpdater is executed from the \OneDrive\ folder and it sideloads wininet.dll from the same directory. DLL sideloading occurs because of DLL search order hijacking – the DLLs of an executable are usually loaded from a specific location or from memory. However, if the application has not specified the location of the DLL and it is not in memory, it will load them in this order:

1. The directory from which the application is loaded.
2. C:\Windows\System32
3. C:\Windows\System
4. C:\Windows
5. The current working directory
6. Directories in the system PATH environment variable
7. Directories in the user PATH environment variable

Because this particular application does not specify the path of the DLLs to be loaded, the wininet.dll within the \OneDrive\ folder is loaded, putting the malicious code into memory. The DLL sideloading technique with OneDriveStandaloneUpdater.exe has been observed in every instance the threat actor was able to gain access via Quick Assist. More recently, we have seen wininet.dll leveraged and have also previously seen winhttp.dll. It may also be possible for the threat actor to also use the following imported DLLs:

With the implant running and a new scheduled task to ensure OneDriveStandaloneUpdater.exe runs on startup, the TA now has one avenue of persistent access to the victim machine and the Quick Assist connection is closed out.

Recommendations

• Implement a Microsoft Teams configuration only allowing whitelisted/federated domains to reach out to your internal users. Another step would be to disable incoming and outgoing chats and calls with Skype users (unless needed for business continuity).
• Remove Quick Assist from all end-user machines unless explicitly required for business and IT services. Our customers have been leveraging GPO and CCM to remove the application, as well as blocking domains related to the Quick Assist service:
  • remoteassistance.support.services.microsoft.com
  • *.relay.support.services.microsoft.com
• Follow guidance in the Persistence section of this report on preventing the download and execution of remote monitoring and management (RMM) software, as this TA will have victims download other tools if Quick Assist is not available.
• Educate users on this threat vector and provide guidance on processes your internal IT team will take before reaching out to them (either through Teams or over the phone), or a verification process that is to be followed. Threats that require the victim to copy and paste commands, either as a drive-by compromise or via phishing/vishing are on the rise; a consideration here would be limiting the ability of end-users running commands in command prompt or PowerShell.

For indicators of compromise in initial access, as well as a deep-dive into the following stages of a Black Basta attack: Discovery, Credential Access, Lateral Movement, Persistence, and Exfiltration, as well as our expert guidance on containment and remediation, be sure to download our comprehensive whitepaper here.