Authors: Georgy Khandozhko, Alexander Grigoryan, Vladislav Lunin.
Attack chain
In November 2024, employees of a Russian government agency discovered a phishing campaign and turned to the PT ESC IR team for assistance in investigating the malicious activity.
During the investigation, we determined that the attack was part of a phishing campaign orchestrated by the Cloud Atlas group and targeting employees of government agencies in Russia and Belarus. PT ESC had been tracking this phishing campaign since late October 2024, and all known affected organizations had been notified. We previously described the activity of the group in our report APT Cloud Atlas: Unbroken Threat.
The screenshots below show an example of a phishing email, purportedly sent by the Ministry of Communications and Informatization of the Republic of Belarus.
The emails were sent from @internet.ru addresses. A user can obtain such an email account when registering with the mail.ru service.
In the past, Cloud Atlas typically used documents related to the current geopolitical situation as bait. In this campaign, however, the documents were disguised as official requests for specific types of information, purportedly from various government agencies.
The malicious documents discovered during the incident investigation used a remote template injection technique (Template Injection).
The screenshots below showcase examples of decoy documents used by the attackers during the phishing campaign.
The link to a malicious template is embedded in the 1Table stream of the malicious DOC file.
At the time of the phishing campaign, antivirus tools were not able to detect the malicious documents.
When such a malicious document is launched, a template is downloaded from the attacker's server officeconfirm.technoguides[.]org. By the time the incident investigation began, this server was already inaccessible. However, based on the artifacts found on the infected hosts and judging by the antivirus tool triggers, we concluded that the downloaded template exploited a vulnerability in the Equation Editor component.
We also discovered that a similar DOC file had been checked on VirusTotal before: at the time when the file was uploaded, the command-and-control server was accessible, and the behavioral analysis results of the document were relevant.
During the behavioral analysis in the C2AE sandbox, a GET request to the C2 server was detected, and the server responded to it by returning an HTML Application (HTA) file. This request was made just seconds after requesting the malicious template.
In earlier attacks, Cloud Atlas also used HTA files to deliver other malicious tools to infected hosts. In particular, the analysis of activity on infected hosts revealed instances of malicious VB scripts being executed. These scripts were recorded in alternate data streams of files named AppCache***.log, located at %APPDATA%\Microsoft\Windows. VB scripts interact with a C2 server, which in this case is a Google Sheets document.
The command to execute the malicious script on the hosts under investigation was added to the autorun key of the Windows registry (HKCU:\Software\Microsoft\Windows\CurrentVersion\Run):
NcdAutoSetup - wscript /B "%APPDATA%\Microsoft\Windows\AppCache498625573823535133.log:AppCache 498625573823535133.vbs"The VB script under examination sent data about the infected user to a Google Sheets document via API. Following this, Visual Basic code, encrypted and stored in a different cell of the same sheet, was executed on the host. As a result of executing such commands, instances of other Cloud Atlas group tools were delivered to the infected hosts. In particular, the PowerShower backdoor was delivered; it executed commands received from the C2 server mehafon[.]com (for more details, see the "Malware analysis" section).
Traces of PowerShower persistence were also found in the autorun key:
Canon_upd - powershell -ep bypass -w 01 "%AllUsersProfile%\Canon\CanonHost.ps1"The same delivery method was also used for another malware, which used the DLL Side-Loading technique, disguising itself as components of Cisco Webex:
- %APPDATA%\Cisco\CiscoCollabHost.exe;
- %APPDATA%\Cisco\CiscoSparkLauncher.dll.
The legitimate but vulnerable file CiscoCollabHost.exe calls the SparkEntryPoint function of the CiscoSparkLauncher.dll library, which is located in the same folder. The folder also contains the payload file.
In the process of searching for similar malware samples, we found a library with a matching import hash (imphash). The malware itself acts as a loader for the main functional modules, which are stored on Yandex Disk. The loader persists in the system by creating a scheduled task named CiscoMngr:
<Actions Context="Author">
<Exec>
<Command>%APPDATA%\Cisco\CiscoCollabHost.exe</Command>
</Exec>
</Actions>
The entire infection chain can be visualized as follows:
Malware analysis
VBShower
The execution of VB scripts obfuscated in this manner has already been observed in earlier Cloud Atlas attacks. In particular, similar activity has been described in a F.A.C.C.T. report and in a Kaspersky APT report, which named the malicious script VBShower.
A key difference in the scripts we examine here is the use of Google Sheets as the C2 server, as opposed to traditional command-and-control servers in previous cases.
The original script looks as follows:
After deobfuscation, we see that the script reads the payload content, which is recorded in a file with the same name as the script file itself, but with a .dat extension. The payload itself is a set of bytes in hexadecimal format. The first two bytes are service bytes and are used in subsequent transformations.
Processing each payload byte, starting from the third, is carried out in one of two modes:
- XOR with the first byte of the payload followed by converting the result into the corresponding ASCII character
- Adding the hexadecimal representation of a byte to the resulting string in its original form
Each byte that is being processed is compared to the second byte of the payload file. If the values of these bytes are equal, the processing mode switches. Otherwise, the processing continues in the current mode.
As a result of payload decoding, the following string is formed, containing VB code executed via the Execute command:
The processing of data recorded in the Pbqb variable follows this algorithm:
- The string stored in the Pbqb variable is passed as the first argument to the AEFe data deobfuscation function; the result is executed using the Execute function.
- The second argument (tIOe) of the function is assigned the value of the variable yQT6, which equals 2. This variable is passed to the function by reference, and its value is modified within the function body.
- The tIOe argument specifies the index from which the substring will be read from the string variable passed to the first argument. Thus, the string stored in the variable Pbqb is read starting from the second character (the leading space is omitted).
- The first eight characters of the resulting substring are then read and fed into the QkuA function, which performs byte-by-byte decoding of the data from hexadecimal format into the corresponding ASCII characters.
- The decoded string is a decimal number that is converted into an Int data type, then multiplied by 2 and added to 8.
- The final value is used in the newly invoked decoding function and determines the length of the substring to be decoded.
- The substring is decoded using the QkuA function, after which the first four characters are removed. These characters correspond to the decimal representation of the number from which we previously obtained the length of the substring.
- The value of the second argument of the AEFe function is added to the number equal to the length of the substring. The resulting value determines the start index of the next decodable block.
Let's break down the algorithm with an example. The AEFe deobfuscation function receives the string Pbqb. After removing the leading space, the first eight characters appear as:
30303435This string is represented as a sequence of hexadecimal bytes (0×30 0×30 0×34 0×35), which decodes into the ASCII characters "0045″.
The string "0045″ is converted to an integer type. The resulting integer number is 45.
45 * 2 + 8 = 98.The first 98 characters of the original string are then read and decoded, producing the following string:
0045For uuHD=1 To 98:Execute AEFe(Pbqb,yQT6):NextThe first four characters are discarded, and the AEFe function outputs the following string, which will be executed as VB code:
For uuHD=1 To 98:Execute AEFe(Pbqb,yQT6):NextThis code indicates that the deobfuscation function will be called 98 more times. The value of the variable yQT6, which was initially 2, has increased by 98. This means that the next block of deobfuscated code starts at the 100th character of the original Pbqb string.
When the cycle is complete, the original string Pbqb is fully deobfuscated. The resulting VB code blocks are executed sequentially during the deobfuscation process.
The relevant code snippets are shown in the screenshots below:
The code performs the following operations:
- Read the values of the ProxyServer and ProxyEnable parameters for the registry key HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings and uses them in subsequent HTTP requests, if they are set.
- Extract the username and domain from the registry key HKCU:\Volatile Environment.
The following operations are then performed in an infinite loop:
- Check for the presence of the NcdAutoSetup parameter in the registry key HKCU:\Software\Microsoft\Windows\CurrentVersion\Run. If the value is not set, the current VB script execution string is written to it. This helps the malware to persist in the system.
- Write the compromised user's details in the first available cell of column A in the Google Sheets document, formatted as CURRENT_TIMESTAMP#USERNAME#DOMAINNAME.
- Read the hexadecimal data stored in column B, performing byte-by-byte XOR with the first byte of the payload (.dat file), and execute the decoded VB code. Upon completion of the executed code, replace the value in the corresponding cell with an entry in the format "done CURRENT_TIMESTAMP".
- Write the value of the variable "result" in the cell in column D of the same row, provided it is not empty. Within the script code itself, the variable "result" is not initially defined, but it can be set within the command body that is obtained from cell B in the previous step.
- Read data from a temporary TMP file located in the current folder, in blocks of 25,000 characters. Each character is encoded in hexadecimal representation, then encrypted using the XOR method with a key matching the second byte of the payload from the .dat file. The encryption result of the first block is recorded in column E, the second block in column F, and so on.
At the end of each cycle iteration, the script goes to sleep for a period of time equal to 2133767 ms + random_value (35+ minutes).
During our investigation of the compromised hosts, we were unable to locate any temporary files, probably because they had been deleted. However, we managed to recover their contents. These files contained, among other things, information about running processes and scheduled tasks in the system. Presumably, the temporary files stored the result of executing the VB code obtained from the Google Sheets document.
By comparing the timestamps in the document with the timestamps in MFT files, we concluded that other tools used by the attackers were delivered to the infected hosts as a result of the code execution.
Examination of PREFETCH files on a compromised host revealed that the cmd.exe process had interacted with a temporary file in an alternate data stream.
In addition to information about processes and tasks, the temporary files were found to store the extracted contents of the %APPDATA%\Cisco folder, including file names and file sizes.
At the time of the analysis, the file a.txt was not present on the infected hosts. However, judging by its size, its contents may match the executable file CiscoCollabHost.exe. The sizes of the payload files found on the compromised hosts also match, which may indicate the identical nature of these files.
Below is a code in VB.NET that decodes the payload and brings the malicious script to its final form.
Sub Main(args As String())
' Path to the payload file
datPayload = "C:\your_path\payload.dat"
content = File.ReadAllText(datPayload)
xorByte = Mid(content, 3, 2)
checkByte = Mid(content, 1, 2)
cond = True
For i = 5 To Len(content) Step 2
currentByte = Mid(content, i, 2)
Do
If currentByte = xorByte Then
cond = Not cond
currentByte = " "
Exit Do
End If
If cond Then
currentByte = Chr("&H" & checkByte Xor "&H" & currentByte)
End If
Loop While False
firtsDecodeStage = firtsDecodeStage + currentByte
Next
resArr = Split(firtsDecodeStage, Chr(34))
hexPayload = resArr(1)
payloadIndex = 2
Deobfuscate(hexPayload, payloadIndex)
For uuHD = 1 To 98
decodedChunk = Deobfuscate(hexPayload, payloadIndex)
Console.WriteLine(decodedChunk)
Next
End Sub
Function Deobfuscate(inputStr, ByRef ind)
nextBlockLength = CInt(Decode(Mid(inputStr, ind), 8)) * 2
Deobfuscate = Mid(Decode(Mid(inputStr, ind), nextBlockLength + 8), 5)
ind = ind + nextBlockLength + 8
End Function
Function Decode(inputStr, Length)
ReDim resultArr(Length)
For ind = 1 To Length Step 2
resultArr(ind) = Chr(CInt(Chr(38) + "H" + Mid(inputStr, ind, 2)))
Next
Decode = Join(resultArr, "")
End Function
Listing 1. Deobfuscation code for VBShower
PowerShower
The PowerShower backdoor used by the Cloud Atlas group was described in a Palo Alto report. The PowerShell script we discovered during our investigation is a modification of PowerShower. The script operates in an infinite loop, with each iteration beginning with a GET request to the C2 server.
If the server response begins with the letter "P", the content of the response is saved to a file named Firefox.zip in the AppData\Local\Temp folder of the current user. Otherwise, the content of the server response, which is in XML format, is saved to a file with a random name.
Next, the script reads the value of the annotation attribute of the xs element in the XML file, starting from the last character. Each character of the resulting string is compared with the characters of the key string: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/. If the characters match, the index of the corresponding character in the key string is converted to binary, with leading zeros added to make it six characters long. The output is added to the final string. Thus, the character A will correspond to the string 000000, the character B to 000001, and so on.
The resulting string, composed of zeros and ones, is then divided into blocks of eight characters each. If a block consists of eight zeros, it is skipped. Otherwise, the string of binary symbols is first converted into an integer value, and then into the corresponding ASCII character, which is added to the final string.
When the processing of all blocks is complete, the output is a string that is subsequently executed as PowerShell code. After executing the command, the script is supposed to delete the XML file containing the payload. However, we were fortunate to find several such files in the antivirus quarantine.
Below is an example of the content of one such file:
After decrypting the string in the annotation attribute, we will obtain the following PowerShell code:
$la = net accounts;[io.file]::WriteAllText($env:temp+"\sapp.xtx", $la);;;The result of the code execution, recorded in the file AppData\Local\Temp\sapp.xtx (the file name may vary in other instances of PowerShower), is sent to the server, after which the file is deleted from the system.
The code of the examined PowerShower sample is as follows:
The PowerShell code for decrypting the payload in the XML file is shown below:
function DecodeAnnotation($annotation) {
$customAlphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
$binaryString = ""
foreach ($char in $annotation.ToCharArray()) {
$index = $customAlphabet.IndexOf($char)
if ($index -ge 0) {
$binaryString += [Convert]::ToString($index, 2).PadLeft(6, '0')
}
}
$byteList = @()
for ($i = 0; $i -lt $binaryString.Length; $i += 16) {
$byte = $binaryString.Substring($i, [Math]::Min(16, $binaryString.Length - $i))
if ($byte.Length -eq 16) {
$byteList += [Convert]::ToByte($byte.Substring(0, 8), 2)
$byteList += [Convert]::ToByte($byte.Substring(8, 8), 2)
}
}
$decodedText = [System.Text.Encoding]::Unicode.GetString($byteList)
return $decodedText
}
function DecodeXmlFile($xmlFilePath) {
[xml]$xmlContent = Get-Content -Path $xmlFilePath -Raw
$annotationNodes = $xmlContent.Relationships.xs.annotation
if ($annotationNodes -eq $null) {
Write-Output "No annotation field found in the XML file."
return
}
$annotationString = ($annotationNodes[-1..-$annotationNodes.Length] -join '')
$decodedText = DecodeAnnotation $annotationString
return $decodedText
}
# Path to the payload file
$xmlFilePath = "C:\your_path\payload.xml"
$decodedAnnotation = DecodeXmlFile $xmlFilePath
Write-Output "Decoded annotation: $decodedAnnotation"
Listing 2. PowerShell code for decrypting the payload in the XML file
Dropper
CiscoSparkLauncher.dll is the first stager of Cloud Atlas malware. It decrypts and executes the payload contained in a file in the same folder.
The functionality of the dropper and malware modules, described in our article APT Cloud Atlas: Unbroken Threat in the malware analysis section, has remained virtually unchanged since then. The core module has undergone a minor functional change: unlike earlier versions, it now uses a statically linked Crypto++ library for cryptography, compression has been removed, and WebDAV of Yandex Disk is used for storing stolen data and malicious modules. The account pe9ov.sem@yandex.ru is used to access the storage. As in previous cases, the attackers uploaded a module to steal files from the infected device based on specific parameters, such as file paths and extensions.
