Zscaler Blog
Get the latest Zscaler blog updates in your inbox
SubscribeTechnical Analysis of Xloader Versions 6 and 7 | Part 1
Introduction
Xloader is a malware family that is the successor to Formbook with information stealing capabilities targeting web browsers, email clients, and File Transfer Protocol (FTP) applications. The malware is also able to deploy second-stage payloads to an infected system. The author of Xloader regularly adds new functionality to target more applications and features to increase the volume of data collection that can be sold or used in further attacks. With each update, Xloader’s code includes increasingly complex layers of encryption and obfuscation to complicate analysis. Previously, Zscaler ThreatLabz examined version 4.3 of Xloader, which introduced multi-layer code encryption to conceal its key components.
This blog is a two-part series that provides a technical analysis on updates to Xloader in versions 6 and 7. The first part of this series covers the malware’s latest obfuscation techniques to evade detection and hinder analysis. The second part of this blog series will examine the command-and-control (C2) communication.
Key Takeaways
- Formbook, introduced in 2016, was rebranded as Xloader in early 2020. After that, Xloader adopted a Malware-as-a-Service (MaaS) model, renting command-and-control (C2) infrastructure to cybercriminals.
- Xloader is a malware family that steals data from a variety of targeted applications such as web browsers, email clients, and File Transfer Protocol (FTP) applications.
- Xloader can be leveraged to download and execute second-stage payloads.
- Xloader versions 6 and 7 include additional obfuscation and encryption layers meant to protect critical code and information to defeat signature-based detection and complicate reverse engineering efforts.
- Xloader has introduced techniques that were previously observed in SmokeLoader, including encrypting parts of code at runtime and NTDLL hook evasion.
Technical Analysis
In the following sections, we provide a detailed analysis of Xloader, focusing on the malware’s behavior, obfuscation, and anti-analysis techniques.
Behavior
Persistence
Xloader establishes persistence by making a copy of itself in a subdirectory under %APPDATA%
(or %PROGRAMFILES%
if the user has sufficient privileges) with the following format:
%APPDATA%\<3-8 alphanumeric characters starting with an uppercase letter>\<6-16 lowercase alphanumeric characters>.exe
Xloader then adds an entry in the Windows registry, either under the Run
key or, if that fails, under the Policies
key as follows:
\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\
\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
Xloader’s entry is placed in either the HKCU
(HKEY_CURRENT_USER
) or HKLM (HKEY_LOCAL_MACHINE
) registry hive, based on the user's privileges. The name of the entry is randomly generated with 5-12 uppercase alphanumeric characters. The registry value will then be set to the path of the Xloader executable in the %APPDATA%
or %PROGRAMFILES%
directory.
Process injection
The figure below is a high-level view of how Xloader injects into multiple processes to evade antivirus and endpoint security software.
Figure 1: A high-level view of how Xloader injects malicious code into target processes.
Xloader first creates a new instance of its own executable through process hollowing. Next, Xloader injects the next stage into the explorer.exe
process to establish network communication. In this case, Xloader uses the asynchronous procedure call (APC) queue technique to inject an x64 shellcode. Xloader uses the native API NtQueueApcThread
instead of higher-level APIs, likely to evade antivirus hooks. The original and hollowed Xloader processes will then terminate.
Finally, Xloader launches an executable file in the SysWOW64 Windows directory that will also be targeted for code injection. Xloader uses a combination of the Windows API functions including CreateProcessInternal
, NtCreateSection
, NtMapViewOfSection
, and NtResumeThread
to inject code into the remote target process. The code injected into explorer.exe
and the code injected in the SysWOW64 process run concurrently and use shared memory sections to communicate.
The list of target executable filenames in the SysWOW64 directory varies across different samples and versions. In one sample of Xloader version 6.2, the list of executables included the following:
SearchFilterHost.exe
Isv.exe
UserAccountControlSettings.exe
systeminfo.exe
SyncHost.exe
print.exe
sdiagnhost.exe
fixmapi.exe
msiexec.exe
takeown.exe
systray.exe
net1.exe
In a sample from Xloader 7.5, the following target executable filenames were identified:
nslookup.exe
srdelayed.exe
makecab.exe
setx.exe
runonce.exe
auditpol.exe
notepad.exe
setupugc.exe
AtBroker.exe
RMActivate_isv.exe
mountvol.exe
dfrgui.exe
Xloader will choose the first entry in the executable filename list. However, if the executable is not found in the Windows SysWOW64 directory, it will then proceed to the next entry in the list until one of the executables is located.
Code obfuscation
In the following sections, we examine Xloader’s custom encryption and obfuscation layers.
Previous versions of Xloader had two types of encrypted functions that we refer to as the following:
NOPUSHEBP
: The function’s entire code is encrypted.PUSHEBP
: These functions start with the well-known push ebp prologue followed by encrypted code.
Many of Xloader’s encryption layers continue to use an encryption algorithm that uses a combination of RC4 and two rounds of adjacent byte subtraction. However, in Xloader versions 6 and 7, an additional encryption layer has been added to the NOPUSHEBP
functions as shown in the figure below.
Figure 2: A high-level diagram for Xloader versions 6 and 7, which leverage three main functions to decrypt and execute critical parts of code.
Xloader executes three main functions: Main Function 1, Main Function 2, and Main Function 3. Each function implements a decryption routine for subsequent encrypted functions. The most noteworthy of these is Main Function 3, which itself is dynamically decrypted through multiple layers, and responsible for decrypting a new additional encryption layer on top of the NOPUSHEBP
encrypted functions.
Main Function 1
Main Function 1 is responsible for establishing persistence on the victim’s computer by copying itself to the appropriate directories and modifying the necessary registry keys explained in the previous section. In addition, Main Function 1 decrypts and calls Main Function 2 as explained below.
Main Function 1 uses an egg-hunting technique that searches for two DWORD ID values to locate the memory address range of the encrypted Main Function 2. Note that all of these DWORD values in Xloader are calculated dynamically at runtime by performing an XOR operation with hardcoded values to evade static signature-based detection. The first layer of the code is decrypted using Xloader’s RC4 and subtraction algorithm using a 20-byte key stored in the malware’s global configuration. Once the first layer is decrypted, another DWORD value is used to delineate the end of the second encryption layer. The key to decrypt the second layer is the same DWORD value used to mark the beginning of the first encryption layer (padded with zeros until the length is 20).
Once the code is decrypted, the function prologue bytes 55 8B EC
are written at the beginning of the decrypted code and 4 no-op (NOP) opcodes are written at the end.
A Python implementation of the Main Function 1 decryption code is shown below:
# The malware keeps a common 0x14 len key at configobj + 0x410
# This offset could change from one sample to another
id_find_encode = get_hardcoded_id_find_encode(binary)
key_layer1 = keys['keys_0x14_stored_in_configobj'][0x410]
id_end_layer1 = get_hardcoded_id_end_layer1(binary)
id_end_layer2 = get_hardcoded_id_end_layer2(binary)
key_layer2 = padding(id_find_encode)
if id_find_encode in binary:
encode_base = binary.index(id_find_encode) + 4
if id_end_layer1 in binary and id_end_layer2 in binary:
# Decrypt layer 1
end_layer1 = binary[encode_base:].index(id_end_layer1) + encode_base
decode_layer1 = rc4_sub(binary[encode_base:end_layer1], key_layer1)
# Add layer 1 decrypted code
binary = binary[:encode_base] + decode_layer1 + binary[end_layer1:]
# Decrypt layer 2
end_layer2 = binary[encode_base:].index(id_end_layer2) + encode_base
decode_layer2 = rc4_sub(binary[encode_base:end_layer2], key_layer2)
# Add layer 2 decrypted code
binary = binary[:encode_base] + decode_layer2 + binary[end_layer2:]
# Add the function prologue and NOPs
start = encode_base
end = end_layer1
if end_layer2 > end_layer1:
end = end_layer2
decrypted_code = binary[start:end]
decrypted_function = b"\x55\x8B\xEC" + decrypted_code + b"\x90\x90\x90\x90"
return decrypted_function
Main Function 2
Main Function 2 executes Xloader’s main loop that calls the functions that communicate with the C2 server and steal data from the victim’s computer. The function also decrypts and calls Main Function 3.
The decryption code in Main Function 2 is similar to Main Function 1 with two layers decrypted by Xloader’s RC4 and subtraction algorithm. The first layer is decrypted using the key stored in the global configuration and the second layer is decrypted using a 20-byte key that is constructed dynamically (rather than using the DWORD ID value used to mark the beginning of the first encryption layer).
Main Function 3
As mentioned previously, Main Function 3 is primarily responsible for decrypting a new encryption layer on top of NOPUSHEBP
functions. Main Function 3 uses another egg-hunting technique to search for these encrypted blocks. For example, in the sample 66ebf028ab0f226b6e4c6b17cec00102b1255a4e59b6ae7b32b062a903135cc9
, Xloader leverages 7 DWORD IDs used to find the beginning of the encrypted blocks, and another 7 IDs used to locate the end of the encrypted blocks. Each block is decrypted using Xloader’s RC4 and subtraction algorithm with a key obtained from the malware’s global configuration. Note that after each block is decrypted, the code is still encrypted in the NOPUSHEBP
functions.
Encrypted NOPUSHEBP functions
The decryption process of NOPUSHEBP
functions remains the same as previous versions with the only exception being how the IDs and decryption keys are dynamically calculated.
The following code shows a Python implementation of Xloader’s NOPUSHEBP
function decryption:
# Find the required seeds and xor keys from the binary
nopushebp_tag1_seed = get_nopushebp_tag1_seed(binary)
nopushebp_tag2_seed = get_nopushebp_tag2_seed(binary)
xor_key_tags = get_xor_key_tags(binary)
nopushebp_key_seed = get_nopushebp_key_seed(binary)
nopushebp_key_xor = get_nopushebp_key_xor(binary)
# Calculate the limit tags and key
nopushebp_tag1 = xor(nopushebp_tag1_seed, xor_key_tags)
nopushebp_tag2 = xor(nopushebp_tag2_seed, xor_key_tags)
nopushebp_key = xor(nopushebp_key_seed, nopushebp_key_xor)
# Decrypt the function
if nopushebp_tag1 in binary and nopushebp_tag2 in binary:
enc = binary.split(nopushebp_tag1)[1].split(nopushebp_tag2)[0]
decrypted_function = b"\x55\x8B\xEC" + \
rc4_sub(enc, nopushebp_key) + \
b"\x90\x90\x90\x90"
Version 7.5 of Xloader introduced a slight modification to decrypt NOPUSHEBP
functions with the construction of the RC4 keys and some functions contain multiple layers of encryption.
Encrypted PUSHEBP functions
Xloader’s PUSHEBP
functions are very similar to prior versions, with additional complexities added in version 7.5 that leverage XOR operations to derive the RC4 key.
Code encryption on API calls
Xloader now encrypts its own code before calling critical APIs, like ZwSetThreadContext
, involved in process injection, as shown in the figure below.
Figure 3: Code protection technique prior to calling ZwSetThreadContext
in Xloader 6.2.
Once the API returns, the original code is decrypted again. This is likely a mechanism designed to thwart analysis platforms that generate memory dumps when specific system calls are executed (for example, memory allocation, process creation, etc.), since the important parts of the code will remain encrypted. A similar technique is implemented in modern versions of SmokeLoader's stager component, which decrypts code blocks when needed and re-encrypts them after use.
Data obfuscation
Previous versions of Xloader stored all critical information (for example, the encrypted strings and the encryption keys) in a set of static encrypted data blocks that we called PUSHEBP
data blocks because the encrypted data was preceded by a push ebp prologue.
In Xloader versions 6 and 7, encrypted PUSHEBP
data blocks no longer exist. When the malware requires a string, key, seed, or constant, the value is constructed dynamically. As a result, there are no hardcoded keys in the malware code.
String obfuscation
In previous versions of Xloader, the malware’s encrypted strings were contained in an encrypted PUSHEBP
data block. In the new versions, there are dedicated functions that build, decrypt, and return each string, as shown in the figure below.
Figure 4: Function to decrypt the COMPUTERNAME
string in Xloader 6.2.
All of these functions operate by pushing the encrypted string on the stack. Xloader then calls a function that initializes a 20-byte key. The key is then used to decrypt the string using Xloader’s RC4 and subtraction algorithm.
Stack strings
In addition to the encrypted strings described above, Xloader builds some plaintext strings on the stack through NOPUSHEBP
functions. Since the code itself in these functions is encrypted and protected, the strings are too.
API obfuscation
Earlier versions of Xloader used two encrypted PUSHEBP
data blocks that contained tables of 32-bit cyclic redundancy check (CRC32) values for Windows API function names. In versions 6 and 7, these PUSHEBP
data blocks have been removed. Now, each CRC32 value is created by its own specific code block.
There are two main types of functions that calculate the CRC32 values for Windows API function names. One function requires a seed and an encrypted CRC32, while the other function only requires an encrypted CRC32 value. These functions are described below.
The first API resolution function dynamically builds each API CRC32 value from two parameters. The functions maintain a consistent code structure with two parameters consisting of a 1-byte XOR key and an encrypted CRC32 DWORD value as shown in the figure below.
Figure 5: Algorithm to derive the API hash using a seed and an encrypted CRC32 value in Xloader 6.2.
In the example above, an XOR operation is performed with a 20-byte seed (15 2B 13 8F 74 EB 03 60 8E 08 48 EA 8F 61 89 7D 9E A4 A6 C1
) and a hardcoded byte (0x48
). Another XOR operation is performed using the result and the 1-byte XOR key provided to the function. This generates the decryption key, which is then used by Xloader’s RC4 and subtraction algorithm to decrypt the API function name's CRC32 value.
In other cases, the API CRC32 value is calculated with inline code (instead of a dedicated function). In these cases, only the RC4 encrypted CRC32 value is provided as an argument to a function that builds a 20-byte RC4 key dynamically (with 5 DWORDs encoded by a single XOR key). Xloader’s RC4 with subtraction algorithm is then used to decrypt the final API CRC32 value.
Xloader then computes the CRC32 value for each export function name (converted to lowercase) and the previously calculated CRC32 to locate the address of each required API function.
NTDLL hook evasion
Xloader versions 6 and 7 load a copy of ntdll and call the library’s API functions through the copy instead of the original library. This ensures that if breakpoints are set on the exported functions of the library or if a monitoring tool attempts to perform hooks, they will be unable to properly trace Xloader’s behavior. This technique is used by other malware families including SmokeLoader.
Xloader obfuscation evolution
The table below outlines the obfuscation techniques used in Formbook and various versions of Xloader.
Technique | V2 | V4 | V6/V7 |
---|---|---|---|
RC4 with subtraction encryption | Yes | Yes | Yes |
Custom lookup table decryption algorithm | Yes | Yes | No |
PUSHEBP data blocks | Yes | Yes | No |
PUSHEBP code blocks with plaintext limit IDs | Yes | No | No |
PUSHEBP. code blocks with encrypted limit IDs | No | Yes | Yes |
PUSHEBP decryption with XOR key passed by caller | No | No | No/Yes |
NOPUSHEBP code blocks Key from PUSHEBP data blocks | No | Yes | No |
NOPUSHEBP code blocks with egg-hunting | No | No | Yes |
NOPUSHEBP code blocks with dynamic key | No | No | Yes |
NOPUSHEBP code blocks Two RC4 with subtraction layers Key 1 built dynamically Key 2 from global config | No | No | No/Yes |
Strings in PUSHEBP data blocks | Yes | Yes | No |
Stack-based string obfuscation | No | No | Yes |
Decoy C2s stored as encrypted strings | Yes | Yes | Yes |
Decoy C2s encrypted with additional layers | Yes
| Yes | Yes |
Real C2 in PUSHEBP data blocks | Yes | Yes | No |
Real C2 among the encrypted strings | No | No | Yes |
C2 keys in data blocks | Yes | Yes | No |
C2 keys built dynamically | No | No | Yes |
API CRC values in PUSHEBP data blocks | Yes | Yes | No |
API CRCs encrypted with RC4 and subtraction | No | No | Yes |
Table 1: Comparison of Xloader obfuscation techniques by version.
As the table above demonstrates, Xloader continues to add new layers of encryption and obfuscation with each new release to complicate manual and automated analysis. Xloader now contains multiple layers of encryption for code, strings, constants, and API hashes. Furthermore, the Xloader author has implemented additional measures over time to decrypt critical information only when necessary, and scattered code and data across multiple sections. Xloader’s encryption algorithms have also been changed significantly over time from a custom encryption algorithm that used a lookup table to an algorithm that leverages RC4 and subtraction. These modifications are designed to better evade detection by endpoint security software and stay one step ahead.
To Be Continued
In Part 1 of this series, we explored the obfuscation techniques used in the latest versions of Xloader 6 and 7, focusing on how the malware conceals its code and data. In Part 2, we will shift our attention to the encryption mechanisms of its network protocol and the parameters that facilitate Xloader’s communication.
Zscaler Coverage
Zscaler's multilayered cloud security platform detects Xloader and Formbook, as well as various other types of cyberthreats, at multiple levels, as shown below:
Figure 6: Zscaler Cloud Sandbox report for Xloader 6 and 7.
Indicators Of Compromise (IOCs)
Sample | Variant | Version |
---|---|---|
66ebf028ab0f226b6e4c6b17cec00102b1255a4e59b6ae7b32b062a903135cc9 | Xloader | 6.2 |
88909cd27a422da91a651e87f493d16beff1f0e03adcc035f2835a2a25e871e7 | Xloader | 6.2 |
4ad101eef336dc2467ffaf584b272aa82f26711bfba4e2e29e8ad7c6d62bc6ae | Xloader | 7.5 |
362207c53645346df6f36cf3f7792e5fc4655895b35a6e3477e218e0e0007be9 | Xloader | 7.5 |
b1fb20d5857d1ca65dbacd6cb100dc2d7da8eb7ce54d4faeebafb2bbb212beca | Xloader | 7.5 |
Network indicators
Sample | C2 |
---|---|
66ebf028ab0f226b6e4c6b17cec00102b1255a4e59b6ae7b32b062a903135cc9 | www.iwin[.]exposed/ir6g/ |
www.ok2yu[.]us/ir6g/ | |
www.zwetststuren[.]cfd/ir6g/ | |
www.fraternize[.]org/ir6g/ | |
www.mc9uh8d70[.]site/ir6g/ | |
www.scwspark[.]com/ir6g/ | |
www.royalkredit[.]online/ir6g/ | |
www.bkexclusivecars[.]net/ir6g/ | |
www.moncoop[.]coop/ir6g/ | |
www.tehranrizcomputer[.]com/ir6g/ | |
www.sazekents[.]cfd/ir6g/ | |
www.xediedie[.]icu/ir6g/ | |
www.eeja[.]uk/ir6g/ | |
www.mscfoundation[.]info/ir6g/ | |
www.brighterhomesdecor[.]com/ir6g/ | |
www.efidence[.]com/ir6g/ | |
www.tk254kr6rwr7mjtru[.]com/ir6g/ | |
www.haycoches[.]com/ir6g/ | |
www.electra-airways[.]info/ir6g/ | |
www.happiluv[.]com/ir6g/ | |
www.goog1evip15[.]com/ir6g/ | |
www.womenscalshion[.]com/ir6g/ | |
www.lenaguillemette[.]com/ir6g/ | |
www.jamesgadzikmd[.]com/ir6g/ | |
www.kavanzi[.]com/ir6g/ | |
www.tupinkeept[.]cfd/ir6g/ | |
www.portfutures[.]asia/ir6g/ | |
www.cgm-logistics[.]org/ir6g/ | |
www.dutch-wildlife[.]shop/ir6g/ | |
www.dsisarl[.]com/ir6g/ | |
www.haftplicht[.]com/ir6g/ | |
www.roundhaygardenscene[.]com/ir6g/ | |
www.alace5[.]com/ir6g/ | |
www.sathyfe[.]com/ir6g/ | |
www.electronicraw[.]com/ir6g/ | |
www.earn50k[.]com/ir6g/ | |
www.arasymimbi[.]com/ir6g/ | |
www.lriz[.]site/ir6g/ | |
www.pinnaclebyte[.]info/ir6g/ | |
www.avolci[.]com/ir6g/ | |
www.am8pw[.]us/ir6g/ | |
www.projectimprov[.]com/ir6g/ | |
www.energeticfranchise[.]top/ir6g/ | |
www.devocionmusic[.]com/ir6g/ | |
www.markthing[.]site/ir6g/ | |
www.myhosting[.]co[.]in/ir6g/ | |
www.solar-windturbine[.]life/ir6g/ | |
www.flusznwrldwide[.]com/ir6g/ | |
www.lifedrawingbristol[.]co[.]uk/ir6g/ | |
www.weberze[.]com/ir6g/ | |
www.getmylinks[.]cc/ir6g/ | |
www.aspasskeoffice[.]homes/ir6g/ | |
www.uxzl[.]site/ir6g/ | |
www.carpmaxxbait[.]online/ir6g/ | |
www.dumpstedoctorca[.]com/ir6g/ | |
www.revelationfithub[.]com/ir6g/ | |
www.cuffbow[.]com/ir6g/ | |
www.hk9[.]xyz/ir6g/ | |
www.lollybowly[.]com/ir6g/ | |
www.aarunifoodcrafters[.]com/ir6g/ | |
www.jarvisandbrown[.]com/ir6g/ | |
www.gattosat[.]icu/ir6g/ | |
www.xfgqbh[.]site/ir6g/ | |
www.mag-flex[.]com/ir6g/ | |
4ad101eef336dc2467ffaf584b272aa82f26711bfba4e2e29e8ad7c6d62bc6ae | www.trisixnine[.]net/0057/ |
www.softillery[.]info/cyhg/ | |
www.easestore[.]shop/qflp/ | |
www.yu35n[.]top/kejj/ | |
www.yourhomecopilot[.]online/gctn/ | |
www.fastr[.]live/gsjn/ | |
www.dto20[.]shop/efvy/ | |
www.aromavida[.]net/4rlw/ | |
www.crochetpets[.]online/vand/ | |
www.queima[.]shop/mdoj/ | |
www.nojamaica[.]net/g7eq/ | |
www.komart[.]shop/b2t1/ | |
www.livemarkat[.]live/8h0p/ | |
www.d27dm[.]top/ptbb/ www.rtpgaruda888resmi[.]xyz/u8o7/ | |
www.chalet-tofane[.]net/3bhs/ | |
www.platinumkitchens[.]info/dquo/ | |
www.eslameldaramlly[.]site/nlx0/ | |
www.theproselytizer[.]net/od1n/ | |
www.amitayush[.]digital/93j5/ | |
www.030002304[.]xyz/d7z8/ | |
www.aaavvejibej[.]bond/lh0g/ | |
www.useanecdotenow[.]tech/vera/ | |
www.bayarcepat19[.]click/q1x3/ | |
www.bluegirls[.]blog/g1ze/ | |
www.wdeb18[.]top/kv48/ | |
www.weatherbook[.]live/tfj4/ | |
www.pachuco[.]supply/7gdu/ | |
www.childlesscatlady[.]today/2kmz/ | |
www.kabaribukota[.]press/nr90/ | |
www.federall[.]store/afqz/ | |
www.inf30027group23[.]xyz/xzfm/ | |
www.allthingsjasmin[.]com/pbmf/ | |
www.ntn[.]solar/fcmy/ | |
www.torex33[.]online/pvct/ | |
www.resumeyourway[.]info/vn92/ | |
www.kx507981[.]shop/q3r9/ | |
www.ohio-adr[.]net/j0y4/ | |
www.serverplay[.]live/6b8s/ | |
www.meg21c[.]top/3jg0/ | |
www.rockbull[.]pro/0tt2/ | |
www.trapkitten[.]website/y6hh/ | |
www.44ddw[.]top/3e3b/ | |
www.ngmr[.]xyz/4muf/ | |
www.sansensors[.]info/ip84/ | |
www.allsolar[.]xyz/cph9/ | |
www.bismarckrecovery[.]com/kp5k/ | |
www.vegastinyhomes[.]net/f2tm/ | |
www.airbatchnow[.]online/ekgk/ | |
www.huemanstudio[.]today/0ob6/ | |
www.rtpngk[.]xyz/yd3l/ | |
www.mechecker[.]life/b6h1/ | |
www.lojashelp[.]video/ao78/ | |
www.tracy[.]club/rwcg/ | |
www.limitlesssky[.]org/50p5/ | |
www.luismoreno[.]monster/06xo/ | |
www.dhkatp[.]vip/4qrw/ | |
www.hentaistgma[.]net/j6o1/ | |
www.promasterev[.]shop/zjp0/ | |
www.pethut[.]shop/wrhe/ | |
www.polarmuseum[.]info/m8hf/ | |
www.greekhause[.]org/tn42/ | |
www.wdcb30[.]top/s7v2/ | |
www.everycreation[.]shop/nsev/ |
Was this post useful?
Get the latest Zscaler blog updates in your inbox
By submitting the form, you are agreeing to our privacy policy.