{ "id": "eb101d87-3fd6-4654-86c7-4fa4f7217115", "created_at": "2026-04-06T00:19:21.698394Z", "updated_at": "2026-04-10T03:35:12.360401Z", "deleted_at": null, "sha1_hash": "a5e5d9ad200f10e24fc5a27ff7118b2bc3aa0cc0", "title": "Cobalt: tactics and tools update", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2155037, "plain_text": "Cobalt: tactics and tools update\r\nBy Positive Technologies\r\nPublished: 2024-08-19 · Archived: 2026-04-05 19:24:39 UTC\r\nThe PT Expert Security Center (PT ESC) has been monitoring the Cobalt group since 2016. Currently the group targets\r\nfinancial organizations around the world. Two years ago, for example, their attacks caused over $14 million in damage. Over\r\nthe last four years, we have released several reports on attacks linked to the group.\r\nOver the last year, the group has not only modified its flagship tools CobInt and COM-DLL-Dropper in conjunction with the\r\nmore_eggs JavaScript backdoor, but also started using new methods to deliver malware and bypass security in the initial\r\nstages of the kill chain. As a group whose activities have long been of interest to security researchers all over the world, the\r\nattackers are highly motivated to stay one step ahead.\r\nFigure 1. Number of Cobalt attacks detected by PT ESC\r\nIn 2019, the group conducted an average of three attacks per month. Although we do not know whether the attacks were\r\nsuccessful, such frequency may indicate that the criminals possess substantial financial resources allowing them to maintain\r\ntheir infrastructure, update malware, and adopt new techniques.\r\nThe following histogram shows that in late 2019 the group started favoring CobInt over COM-DLL-Dropper.\r\nFigure 2. Number of attacks using COM-DLL-Dropper and CobInt in 2019\r\nThe more_eggs JavaScript backdoor is detected by the ETPro ruleset, including in public sandboxes, whereas CobInt traffic\r\ndoes not trigger security mechanisms. In addition, CobInt downloads the main library from the command and control (C2)\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 1 of 21\n\nserver directly to memory, while COM-DLL-Dropper saves to disk the obfuscated more_eggs, which is then executed in\r\nmemory. Therefore, COM-DLL-Dropper leaves more artifacts on the infected machine.\r\n1. European Central Bank phishing website\r\nIn late August 2019, we detected a CobInt attack that presumably targeted European financial institutions. We do not know\r\nwhether the attack was successful. CobInt was dropped by a custom NSIS installer. We detected three versions of the\r\ndropper: for Chrome, Firefox, and Opera. Each dropper contained the same CobInt version and a browser-specific installer.\r\nOnce launched, the dropper saved CobInt to the %TEMP% folder and then ran CobInt and the installer. Malware analysis\r\nproved that the droppers were distributed from the phishing website ecb-european[.]eu.\r\nFigure 3. Phishing website main page\r\nThe site was a copy of the European Central Bank website, except for a pop-up window that asked visitors to update the\r\nbrowser.\r\nFigure 4. Pop-up window on the fake ECB website\r\nVisitors who fell for the ruse downloaded the dropper to their computer. The page source code contained a link to the script\r\nthat displayed the pop-up window.\r\nFigure 5. Link to malicious script\r\nThe configuration strings in the script contain links for four droppers (we could not obtain the first one) and allow creating\r\nlinks for Safari, Edge, and Internet Explorer. The strings also show the window start time after loading the page, how many\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 2 of 21\n\ntimes the window will be shown to a user, type of device on which the window will be displayed, and which banner will be\r\nshown to the user. In addition, the script detects bots, crawlers, and spiders.\r\nFigure 6. Malicious script parameters\r\nHere are alternative windows contained in the script:\r\nFigure 7. Alternative window specified in the script parameters\r\nFigure 8. Alternative window specified in the script parameters\r\nWe do not know how the user landed on this website. Most likely, the user would be a victim of a phishing attack like many\r\nof those performed by Cobalt.\r\nThe framework in question is not unique. We believe that Cobalt purchased it on a darkweb forum. In an article from\r\nNovember 2019, Zscaler described a similar scenario for spreading NetSupport RAT. The framework was placed on\r\ncompromised sites, which showed visitors a corresponding pop-up window.\r\nIn yet another case, the malicious file Login_Details.img was also distributed from the site ecb-european[.]eu. Our\r\ncolleagues from Group-IB have provided a detailed analysis of the malware.\r\n2. Malicious VHD\r\nIn late December 2019, we detected another CobInt loader used by Cobalt. The loader container was unusual. It was a\r\nvirtual hard disk (VHD), presumably distributed by email.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 3 of 21\n\nThe VHD format was originally developed by Connectix for their Virtual PC product. Microsoft acquired the product in\r\n2003 and renamed it Microsoft Virtual PC. In 2005, the format became available to the public. Microsoft started using the\r\nVHD format in Hyper-V, the hypervisor-based virtualization technology. A VHD file may contain anything found on a\r\nphysical hard drive, such as disk partitions and a file system with folders and files.\r\nWindows 7 and newer systems include the ability to manually mount VHD files, such as via the MMC console. Starting\r\nwith Windows 8, a user can mount a VHD by simply double-clicking the file. A mounted VHD disk image appears to\r\nWindows just like a normal hard disk.\r\nIn September 2019, the CERT/CC Blog published an article about the danger of VHD files and their possible use as an\r\nattack vector. The researcher Will Dorman showed that neither antivirus software nor the Mark of the Web alerts users about\r\nthe potential harm of the contents of a VHD file downloaded from the Internet. Dorman created a malicious VHD container\r\nwith EICAR inside and uploaded the result to VirusTotal. The malware was not detected by any antivirus engines. A VHD\r\nfile is critical for operation of Hyper-V virtual machines. If this file is damaged or blocked, the virtual machine will not run.\r\nThis may explain the rarity, or even absence, of antivirus detection. In documentation, Microsoft recommends excluding\r\nVHD files from antivirus scanning (as automatically is the case in Windows Defender). Otherwise, Hyper-V is susceptible to\r\nissues.\r\nIt is possible that Cobalt used the findings of this research for their own purposes. Their VHD file was also not detected by\r\nany antivirus software when it first appeared on VirusTotal. Half a year later, the file was detected by just one antivirus\r\nengine, which is still very low.\r\nFigure 9. Cobalt VHD detection level at the moment of attack\r\nThe VHD contains two CobInt files. One file has two invalid Google certificates appended to it in order to reduce the odds\r\nof detection.\r\nFigure 10. Certificates appended to a CobInt file\r\nSince VHD is in essence a container with a file system, one can search for artifacts inside VHD files. For example, we found\r\nan image with text of a fake HSBC antifraud message in the unallocated space of a VHD file.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 4 of 21\n\nFigure 11. Image in unallocated space of a VHD file\r\nThe attackers may have inadvertently left the artifact when reallocating space in the container: the same image was used as\r\nthe CobInt icon and stored in the group's resources.\r\n2.1. CobInt analysis\r\nOnce the VHD is mounted, a user must manually run one of the files. The two files are identical in terms of functions. When\r\nrun, either of the CobInt files downloads the main library from the C2 server as an HTML file.\r\nThere are a few changes in comparison to the algorithm described by ProofPoint in 2018:\r\nFigure 12. Example of obfuscation of the main library\r\nFirst, all tags are removed and their contents are ignored.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 5 of 21\n\nFigure 13. Tag removal\r\nNext, periods, commas, and spaces are processed. All characters after these symbols are uppercased (the value 0x20 is\r\nsubtracted).\r\nFigure 14. Removing unnecessary characters and switching letters to uppercase\r\nNext, data is decoded from Base64 and decrypted by XOR with a 4-byte key that is initialized with the preceding value of\r\nthe decrypted data at each iteration. At each iteration, the current round's 4 bytes are subtracted from those of the previous\r\nround, after which the key is the 4-byte value of the input buffer of the previous round.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 6 of 21\n\nFigure 15. First XOR level\r\nOnce decryption finishes, the second-stage decryptor takes over. In essence, it consists of an XOR decryption cycle using a\r\n4-byte key that is the same for the entire stage. The output of this stage will be a .dll library, which is the payload.\r\nData decoded from Base64 is shown in Figure 16. A 4-byte preset for the first decryptor is highlighted in red and will remain\r\nthe same during the second stage. The rest of the data is highlighted in yellow.\r\nFigure 16. Data decoded from Base64\r\nThe picture changes after decryption (Figure 17). The encryption key is clearly visible due to a long series of zeros in the\r\nexecutable file that, after encryption, contain the keystream in pure form.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 7 of 21\n\nFigure 17. Data after removal of the first XOR level\r\nThe second decryption gives us a valid PE file (Figure 18). We could not figure out the purpose of the first eight bytes: they\r\nare not used anywhere in the loader.\r\nFigure 18. Deobfuscated library\r\n2.2. Main library analysis\r\nOnce an event is created and the necessary parameters are initialized, the domain is decrypted. Then the function for\r\ngenerating the remaining part of the address is called.\r\nFigure 19. Algorithm for generating remaining part of the address\r\nAfter the full C2 server address is generated, the library decrypts the necessary parameters to create HTTP fields, adds them\r\nto a request, and sends the request to the server. The server response contains plugins that the library loads into its address\r\nspace using ReflectiveLoader.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 8 of 21\n\n2.3. Decryption of plugins\r\nLike the main library, the plugins are sent by the server as HTML pages. The first stage of input transformation is similar to\r\nwhat happens during the library download. The difference is that all periods, commas, and spaces are ignored, and all\r\ncharacters are lowercased.\r\nAfter the initial transformation, the obtained data is decoded from a–z to 0x00—0xff. For this, a previously unseen decoding\r\nprocedure is used. It is based on transforming input values depending on the current value, previous value (in some cases),\r\nand values of the global counter.\r\nFigure 20. Plugin decoding algorithm\r\nThe decoding is followed by two decryption cycles.\r\nFigure 21. First decryption cycle\r\nThe first decryption key is in the application code, hard-coded at an offset that takes only two values.\r\nTo carry out the second decryption cycle, the last byte of data is read. This byte is the length of the encryption key for the\r\nsecond cycle. The file is read at this number of bytes (plus one) from the end. After the key is read, the data is decrypted,\r\nexcept for the key itself. In Figure 22, the key length is highlighted in red and the key itself is highlighted in yellow.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 9 of 21\n\nFigure 22. XOR key example\r\nThe last stage is decryption with a 4-byte key, which is also easily obtained by analyzing the series of zeros in the PE header.\r\nFigure 23. XOR key in encrypted data\r\nOur analysis detected two types of downloaded plugins: one that steals the names of running processes plus a screen capture\r\nmodule. Both plugins use standard WinAPIs to obtain data, as well as the same function as the main library in the export for\r\nreflective process loading.\r\n2.4. Traffic decryption\r\nThe library sends the data collected by the plugins to the server.\r\nHere is an example of traffic:\r\nFigure 24. Encoded data collected by plugin\r\nFirst, the traffic is encrypted by a randomly generated key of arbitrary length. The key is inserted into the packet with\r\nindication of its length.\r\nNext, the data is encrypted with a hard-coded 64-byte key, the same one that was used to decrypt the library. After that, the\r\nsame encoding algorithm is applied. An equals sign (=) and the generated sequence of 8 to 16 a–z characters are added to the\r\nbeginning.\r\nExample of decoded and decrypted traffic from the previous packet:\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 10 of 21\n\nFigure 25. Decoded data\r\nPacket creation and transformation function:\r\nFigure 26. Algorithm for creating packet with data\r\n3. BIFF macro\r\nIn March 2020, we detected an XLS document from Cobalt that downloaded and ran the COM-DLL-Dropper. The\r\ndocument contained the rather old Excel 4.0 macro format and was almost invisible to antivirus software (1 positive verdict\r\nout of 60 on VirusTotal).\r\nFigure 27. Number of antivirus verdicts on VirusTotal during first upload of the file with Excel 4.0 macro\r\nThis macro standard is 20 years old. The standard is peculiar in that the macro is stored in worksheet cells (not stored in a\r\nVBA project), and the worksheet itself can be hidden in Excel. The macro therefore will not be in a VBA stream, but in a\r\nBIFF (Binary Interchange File Format) record.\r\nIf we open the document in Excel, we see one worksheet and no VBA project macros. However, Excel all the same detects\r\nthe macro and blocks it from running.\r\nThe olevba3.py utility from oletools can be used to detect this macro.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 11 of 21\n\nFigure 28. Result of olevba3.py execution\r\nBy running the utility, we see that one of the document worksheets has the status \"very hidden\" and is of the Excel 4.0\r\nmacro type. Because of this status, the worksheet will be invisible in the Excel interface and, what's more, it cannot be made\r\nvisible from the interface either. It can only be made visible by Visual Basic or by manually modifying the document's bytes.\r\nThe BiffView utility provides a more workable view of the BIFF structure. After parsing the initial document, we see that a\r\npage named sygfdfdfdesie has the attribute \"very hidden.\" We change this parameter to 1 or 0 in a hex editor.\r\nFigure 29. Structure of malicious document worksheets\r\nWhen the initial document is opened in the Name Manager, one of the formulas runs automatically:\r\nFigure 30. Macro formula that runs when the document is opened\r\nThe initial formula launches a long chain of commands, such as CONCATENATE, RUN, CHAR, and CALL, which will\r\nlead to the loading and launch of COM-DLL-Dropper. The commands are scattered across the Excel cells, complicating\r\nanalysis.\r\nFigure 31. Macro formulas leading to loading and launch of COM-DLL-Dropper\r\n4. COM-DLL-Dropper analysis\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 12 of 21\n\nIn early April 2020, we detected a new version of COM-DLL-Dropper. Its functions are different from everything we had\r\nseen before. However, the more_eggs JavaScript backdoor payload remained the same.\r\nCobalt first started using COM-DLL-Dropper in the summer of 2017 and is still using it to deliver more_eggs, which is\r\ncontained in the dropper in encrypted and archived form.\r\nA few facts about the dropper:\r\nIt is written completely in PureBasic.\r\nIt uses numerous anti-analysis techniques.\r\nIt contains an encrypted and archived JavaScript loader, JavaScript backdoor, and a legitimate utility for modifying\r\nthe command line to launch more_eggs.\r\nIt has a built-in obfuscator for the hard-coded JavaScript backdoor and JavaScript loader\r\n4.1. PE file external structure\r\nAll the studied items are PE-DLL files to be registered by regsvr32. In addition to exports called by regsvr32, each sample\r\nhas different sets of exports typical of legitimate DLL files. Cobalt attempted to mask COM-DLL-Dropper by using third-party exports. Figure 32 shows the most popular exports used in the malware files (total of 249 unique exports).\r\nFigure 32. Most popular COM-DLL dropper exports\r\nThese exports contain stubs that generally do not actually do anything. Judging by the names of the exports, the droppers\r\nwere masked to resemble media application libraries. In 2019, the malware was updated with the DllInstall export, which is\r\nalso called by regsvr32, and the main dropper code was moved to the export.\r\nBefore describing the malware code, we should touch on the PureBasic code. The information we provide here is the result\r\nof analyzing malware samples. We did not study the compiler itself and therefore are forced to make certain assumptions.\r\nHowever, the described entities helped us in our analysis, which is why we are sharing them here. All the names in\r\nscreenshots were made up for the purposes of interpreting the malware code.\r\nOur analysis requires two entities: strings and object arrays. PureBasic strings are stored in a special buffer. They are\r\nallocated and released without using a system API. Figure 33 shows the process of string allocation. During program\r\ninitialization, a separate heap is created for strings by calling HeapCreate().\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 13 of 21\n\nFigure 33. String workings\r\nA common pattern for working with this entity is as follows:\r\n1. Allocate a string to storage from a constant.\r\n2. Operate on the string.\r\n3. Update the global string which is usually allocated on the heap. After the update is completed, move back the node\r\nindex. This operation is somewhat similar to pop().\r\nThe string storage structures do not allow storing the size of the added string. Instead, before starting any operation with the\r\nstring, the program saves the previous index of the node and then passes it to the update operation. The difference between\r\nthe indices is the string size.\r\nWe will not describe object arrays here in detail; suffice it to say that a special header before each array stores information\r\nabout the size, type, and number of elements. The header occupies 18h bytes. Therefore, the space allocated for the array of\r\nobjects can be calculated as size of element × number of elements + 18h.\r\nTo get a clearer picture, refer to this description of functions that are presented in the screenshots a bit later.\r\nTable 1 Function Description\r\nFunction Description\r\nObjectManager::AllocateObjectArray Object array is allocated\r\nObjectArray::ReleaseObjectArray\r\nObjectManager::FreeObject\r\nObject array is released\r\nObjectManager::GetStringObject\r\nObjectManager::ConcatenationWithStringObject\r\nCreate a string in storage\r\nObjectManager::PopStringObject Update global string\r\n4.2. Anti-analysis\r\nTo find the needed API functions, non-standard hash sums obtained from the functions' names are used. Each hash sum is\r\nobtained by taking the CRC32 value and then performing XOR with a constant. The samples have different constants. This\r\nis why Table 3 also includes CRC32 values without the constant-value XOR.\r\nThe new version of COM-DLL-Dropper has strings encrypted with the RC4 algorithm, whereas the older version used\r\nXOR.\r\nTable 2. Techniques used by the malware to complicate analysis\r\nTechnique Description\r\nKey bruteforce to decrypt strings\r\nStarting in April 2020, RC4 has been used instead of XOR. This technique\r\nuses a non-standard implementation of the Sleep function, which may\r\npostpone launch of the main malware functions in a sandbox.\r\nChecking for the /s /i string process in\r\nCommandLine\r\nThe check verifies that the process was launched via regsvr32.\r\nVerifying the process name and the\r\n.ocx extension\r\nThe extension and the process name are also checked with a non-standard\r\nhash function.\r\nVerifying the list of modules loaded\r\ninto the process\r\nThe check is performed using a custom hash function.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 14 of 21\n\nTechnique Description\r\nLoading of additional NTDLL image\r\ninto the process\r\nThis likely creates a trusted NTDLL image without NT API interception.\r\nChecking the values of registers Dr0–\r\nDr3\r\nNon-zero values in these registers indicate hardware breakpoints, and\r\ntherefore the debugger. The register values are accessed via NtGetContext().\r\nProcessDebugPort check NtQueryInformationProcess with relevant value is called.\r\nProcessDebugObjectHandle check NtQueryInformationProcess with relevant value is called.\r\nProcessDebugFlags check NtQueryInformationProcess with relevant value is called.\r\nChecking the parent process name The check is performed using a non-standard hash function.\r\nChecking the year set on the system\r\nThe current date is obtained by calling NtQuerySystemTime and\r\nRtlTimeToTimeFields.\r\nChecking the value of the environment\r\nvariable COMPUTERNAME\r\nThe computer name is checked for the hard-coded string \"FLAREVM\".\r\nTable 3. Strings and corresponding hash sums used in techniques\r\nHash sum CRC32 String\r\n0x322CD34E 0x322C4A66 .ocx\r\n0xF43AEA50 0xF43A7378 regsvr32.exe\r\n0x6FECDEE9 0x6FEC47C1 sbiedll.dll\r\n0x16430EDF 0x164397F7 cmdvrt64.dll\r\n0x2B256AC8 0x2B25F3E0 cmd.exe\r\n0xA82757CC 0xA827CEE4 cmstp.exe\r\n0xB3C6B186 0xB3C628AE msxsl.exe\r\nKey bruteforcing for string decryption is not \"complete.\" In fact, most of the key consists of a hard-coded prefix found in the\r\ncode. The end of the key is a decimal number. Therefore, key = prefix + number.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 15 of 21\n\nFigure 34. RC4 key bruteforce\r\n4.3. JavaScript generators\r\nThe dropper creates two files. The first is a JavaScript loader, and the second is a scriptlet containing the encrypted\r\nmore_eggs backdoor. Both scripts are generated.\r\nThe generation template is saved among malware samples. The inserted data varies. The template contains tokens and\r\nJavaScript parts that are concatenated in series. Figure 35 shows part of generation of the JavaScript loader and examples of\r\nthe used JavaScript parts.\r\nFigure 35. Generation of a part of the loader\r\nSeveral obfuscation templates are built into the generator:\r\nCompensatory disguising of constants\r\nGeneration of random variable names\r\nInsertion of encrypted strings\r\nEach generator contains a pool of names that are generated prior to starting creation of the script. These names are then used\r\nin JavaScript. Figure 35 shows a local variable named lpbobj_arraywcs__JSObjectPool. Figure 36 shows the pool\r\ninitialization cycle.\r\nFigure 36. Example of filling the pool of names used in the script\u003e\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 16 of 21\n\nEach name available to be used in the script contains two parts: a random prefix (which is created once for the entire script)\r\nand a random decimal number (limited to a set number of characters). Figure 37 shows the name generation scheme and the\r\nresult obtained in the script.\r\nFigure 37. Generation of names available to be used in the script\r\nNumeric constants are obfuscated with a function that applies a random arithmetic operation from a set hard-coded in the\r\nprogram and then inserts the opposite operation in the script. Thus, the inserted expression balances out the obfuscated\r\nconstant. The second arithmetic operation argument is also generated randomly from a hard-coded range of values.\r\nFigure 38. Generation of obfuscated constants\r\nThe payload is encoded using RC4 and Base91 and inserted in the script. The implementations of RC4 and the Base91\r\ndecoder are also inserted in the scripts.\r\n4.4. Persistence\r\nDepending on its rights in the system, the dropper entrenches itself on the infected machine using the following methods:\r\nBy using Task Scheduler\r\nBy using the registry key Environment\\UserInitMprLogonScript\r\nBy using the registry key Software\\Microsoft\\Windows\\CurrentVersion\\Run\r\nFor all three methods, the value written by the dropper is the same, containing the command for launching the JavaScript\r\nloader.\r\nFigure 39. Example of persistence via UserInitMprLogonScript\r\nTo configure a task created by the dropper, a special XML file is generated. Part of it is stored in the dropper in encrypted\r\nform, and another part is generated while running.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 17 of 21\n\nFigure 40. Decrypted part of XML\r\nFigure 41. Creating end for the XML file\r\nThe resulting XML file is saved with a random name consisting of hexadecimal characters. Subsequently, this XML file is\r\npassed to schtasks.exe as the /XML parameter value.\r\n4.5. Running the payload\r\nCOM-DLL-Dropper saves three files to disk:\r\nObfuscated JavaScript loader\r\nObfuscated JavaScript backdoor\r\nLegitimate utility for modifying the command line in order to launch the more_eggs JavaScript backdoor\r\nThe main backdoor is launched with the help of a known AppLocker bypass technique using the msxsl utility. The\r\ncommands look as follows:\r\n“C:\\Users\\\\AppData\\Roaming\\Microsoft\\msxsl.exe”\r\n“C:\\Users\\\\AppData\\Roaming\\Microsoft\\[javascript_downloader_name].txt”\r\n“C:\\Users\\\\AppData\\Roaming\\Microsoft\\[javascript_backdoor_name].txt”\r\n4.6. JavaScript backdoor functionality\r\nThe JavaScript backdoor saved to disk by the new COM-DLL-Dropper has version 6.6.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 18 of 21\n\nFigure 42. Backdoor header\r\nThis backdoor has been used by Cobalt since 2017. It is executed in memory and always has a low number of antivirus\r\nverdicts.\r\nThe main capabilities of the backdoor are as follows:\r\n1. Traffic encryption with RC4 and Base91\r\n2. Execution of operator commands (in this version, the more_eggs command that gave the backdoor its name was\r\nabsent):\r\nexec: download and run file (.exe or .dll)\r\ngtfo: uninstall\r\nmore_onion: run script\r\nvia_c: execute command using \"cmd.exe /C\"\r\nmore_time: execute command using \"cmd.exe /C\", with the result being saved to a temporary file. After that,\r\nthe file is read and deleted, and its contents are encoded with Base64 and sent to the server.\r\n3. Check of the process list for antivirus protection and researcher software by comparing CRC32 values (derived from\r\nthe name of each process, without extension and in lower case) against hard-coded values.\r\n4. Reconnaissance:\r\nDate of system installation\r\nInfected machine's IP address\r\nSystem type (server or desktop)\r\nWindows version (from XP to 10)\r\nConclusion\r\nCobalt keeps attacking financial organizations around the world, refining its TTPs, and inventing ever-more sophisticated\r\nways to bypass defenses. Due to quarantine-related measures, many employees of financial companies are now working\r\nremotely, outside the protection offered by corporate security solutions. Moreover, many threat actors are using COVID-19\r\nas a lure in their attacks, as the Higaisa group has done. It is possible that Cobalt, too, will try to weaponize such concern.\r\nAuthors: Denis Kuvshinov, Sergey Tarasov, Daniil Koloskov, PT ESC\r\nIndicators of compromise\r\nECB phishing\r\nType MD5 SHA1 SHA256\r\nBrowser\r\ndroppers\r\n152cd7014811ae8980981a825e5843b0 90f7d0b0f90aeadaeff1adf45db5dcc598dec8c4 2d02bbae38f4dba5485fbc2e38640898907ec\r\nf2712de0c8575ff32828c83cfbf75d4b e80ef396462fe651c3cdeb91651ac27799d2dab5 33ba8cd251512f90b7249930aee22d3f47255\r\na3391d1d3482553545d7c0111984abb6 1a371353c6a46ddea19d520d8ce3b5599a8ee9f1 9e8a99ad401ef5d2bb3aea3a463d85220f0e67\r\nCobInt f924c690f7bbaf60d56a446b7a66a43b 8ada87f00ed3afdd4dbdb07879ba6ebe4a2a9ffa b83d2c4f5c2bb562981a104d4e49cf2529109\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 19 of 21\n\nC\u0026C\r\necb-european[.]eu\r\ntimeswindows[.]com\r\nVHD\r\nType MD5 SHA1 SHA256\r\nVHD-file\r\nfce9fcd5fa337d020bd6758008221b81 e288b0410fb95060ce8c5527673978cb2ceffe05 3382a75bd959d2194c4b1a8885df93e8770f4eba\r\nCobInt 600154fcb03e775f007ef7b1547b169c 384a13abe42d249e354cd415c4bcbf01086deafb 0c85c1045899291cba47c7171599446642b8701\r\n6ec0edd1889897ff9b4673600f40f92f 4d50f1cae2acc8c92ff1f678fc1fdfdd1e770f24 64d16900fce924da101744edce28b9ee64819248\r\nC\u0026C\r\ntelekom-support[.]info\r\n45.80.69[.]34\r\nBIFF\r\nType MD5 SHA1 SHA256\r\nXLS-File\r\n36399ebf94f66529dc72d8b2844f43dd b912f222e79feadbcefe2d6ead5fab74b15b1f40 0aee265a022ee84e9c8b653e960559c9761a7362\r\nCOM-DLL\r\n862c19b2b4b6a7c97fb8627303b8f5d7 d3fc5f848d630ca2dc8e99b0d4dfe704b8ec1832 7122cf59f8a59f9a44f20fd4c83451c5c4313e002\r\nC\u0026C\r\ndownload.sabaloo[.]com\r\norigin.cdn77[.]kz\r\nNew COM-DLL dropper\r\nType MD5 SHA1 SHA256\r\nCOM-DLL\r\n47e7212b097b5cffa60903055e3c4d5a dfcd5692729e859f074b95720505f711ba7d14ac c1a633a940fc4c595ebbe36823fee1b02bfd75561\r\nС\u0026C\r\nmaps.doaglas[.]com\r\nMITRE TTPs\r\nTactic ID Name\r\nInitial Access T1193 Spearphishing Attachment\r\nT1192 Spearphishing Link\r\nExecution T1059 Command-Line Interface\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 20 of 21\n\nTactic ID Name\r\nT1117 Regsvr32\r\nT1204 User Execution\r\nT1064 Scripting\r\nPersistence T1037 Logon Scripts\r\nT1050 New Service\r\nT1053 Scheduled Task\r\nT1060 Registry Run Keys / Startup Folder\r\nDefense Evasion T1027 Obfuscated Files or Information\r\nT1220 XSL Script Processing\r\nDiscovery T1063 Security Software Discovery\r\nCommand And Control T1105 Remote File Copy\r\nSource: https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/\r\nPage 21 of 21", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/cobalt_upd_ttps/" ], "report_names": [ "cobalt_upd_ttps" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "873919c0-bc6a-4c19-b18d-c107e4aa3d20", "created_at": "2023-01-06T13:46:39.138138Z", "updated_at": "2026-04-10T02:00:03.227223Z", "deleted_at": null, "main_name": "Higaisa", "aliases": [], "source_name": "MISPGALAXY:Higaisa", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "30c9c492-afc6-4aa1-8fe6-cecffed946e0", "created_at": "2022-10-25T15:50:23.400822Z", "updated_at": "2026-04-10T02:00:05.350302Z", "deleted_at": null, "main_name": "Higaisa", "aliases": [ "Higaisa" ], "source_name": "MITRE:Higaisa", "tools": [ "PlugX", "certutil", "gh0st RAT" ], "source_id": "MITRE", "reports": null }, { "id": "c0cedde3-5a9b-430f-9b77-e6568307205e", "created_at": "2022-10-25T16:07:23.528994Z", "updated_at": "2026-04-10T02:00:04.642473Z", "deleted_at": null, "main_name": "DarkHotel", "aliases": [ "APT-C-06", "ATK 52", "CTG-1948", "Dubnium", "Fallout Team", "G0012", "G0126", "Higaisa", "Luder", "Operation DarkHotel", "Operation Daybreak", "Operation Inexsmar", "Operation PowerFall", "Operation The Gh0st Remains the Same", "Purple Pygmy", "SIG25", "Shadow Crane", "T-APT-02", "TieOnJoe", "Tungsten Bridge", "Zigzag Hail" ], "source_name": "ETDA:DarkHotel", "tools": [ "Asruex", "DarkHotel", "DmaUp3.exe", "GreezeBackdoor", "Karba", "Nemain", "Nemim", "Ramsay", "Retro", "Tapaoux", "Trojan.Win32.Karba.e", "Virus.Win32.Pioneer.dx", "igfxext.exe", "msieckc.exe" ], "source_id": "ETDA", "reports": null }, { "id": "2dfaa730-7079-494c-b2f0-3ff8f3598a51", "created_at": "2022-10-25T16:07:23.474746Z", "updated_at": "2026-04-10T02:00:04.623746Z", "deleted_at": null, "main_name": "Cobalt Group", "aliases": [ "ATK 67", "Cobalt Gang", "Cobalt Spider", "G0080", "Gold Kingswood", "Mule Libra", "TAG-CR3" ], "source_name": "ETDA:Cobalt Group", "tools": [ "ATMRipper", "ATMSpitter", "Agentemis", "AmmyyRAT", "AtNow", "COOLPANTS", "CobInt", "Cobalt Strike", "CobaltStrike", "Cyst Downloader", "Fareit", "FlawedAmmyy", "Formbook", "Little Pig", "Metasploit Stager", "Mimikatz", "More_eggs", "NSIS", "Nullsoft Scriptable Install System", "Pony Loader", "Ripper ATM", "SDelete", "Siplog", "SoftPerfect Network Scanner", "SpicyOmelette", "Taurus Builder", "Taurus Builder Kit", "Taurus Loader", "Terra Loader", "ThreatKit", "VenomKit", "cobeacon", "win.xloader" ], "source_id": "ETDA", "reports": null }, { "id": "c11abba0-f5e8-4017-a4ee-acb1a7c8c242", "created_at": "2022-10-25T15:50:23.744036Z", "updated_at": "2026-04-10T02:00:05.294413Z", "deleted_at": null, "main_name": "Cobalt Group", "aliases": [ "Cobalt Group", "GOLD KINGSWOOD", "Cobalt Gang", "Cobalt Spider" ], "source_name": "MITRE:Cobalt Group", "tools": [ "Mimikatz", "More_eggs", "SpicyOmelette", "SDelete", "Cobalt Strike", "PsExec" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434761, "ts_updated_at": 1775792112, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a5e5d9ad200f10e24fc5a27ff7118b2bc3aa0cc0.pdf", "text": "https://archive.orkl.eu/a5e5d9ad200f10e24fc5a27ff7118b2bc3aa0cc0.txt", "img": "https://archive.orkl.eu/a5e5d9ad200f10e24fc5a27ff7118b2bc3aa0cc0.jpg" } }