{
	"id": "378d4ac0-87f4-493d-9450-026fba7b514c",
	"created_at": "2026-04-06T01:29:52.557184Z",
	"updated_at": "2026-04-10T03:23:51.297332Z",
	"deleted_at": null,
	"sha1_hash": "6c691fba9bae6f7b5b658dc1e6f07dc526db28b0",
	"title": "Shining some light on the DarkGate loader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2134051,
	"plain_text": "Shining some light on the DarkGate loader\r\nBy Telekom Security\r\nPublished: 2023-08-25 · Archived: 2026-04-06 00:16:25 UTC\r\nAnalysis and Report by Fabian Marquardt (@marqufabi)\r\nRecently, Telekom Security CTI was made aware via trust groups in which we are engaged about a new malware\r\ncampaign that is distributed via phishing emails. The malspam campaign used stolen email threads to lure victim\r\nusers into clicking the contained hyperlink, which downloaded the malware.\r\nAttention to this malware campaign was also fueled by a false attribution of one of the malware samples to\r\nEmotet. Even though this attribution later turned out as a false positive match of an automated detection rule, it\r\ncaused the security research community to focus on this new campaign.\r\nInitial analysis quickly revealed significant similarity to the DarkGate malware, based on the use of a similar\r\ninitial infection routine (AutoIt scripts) and the observed C2 communication protocol, which matched past\r\nanalyses of the same malware family. Further analysis confirmed this initial attribution, since embedded strings\r\nand contained functionality clearly identified the sample as part of the DarkGate malware family.\r\nFurther analysis of the sample revealed detailed insights on DarkGate’s functionality, specifically the builtin\r\nevasion techniques, the malware configuration and its features. Our results align with other recent publications\r\nabout DarkGate. Furthermore, we provide an approach for configuration extraction that in our eyes is more robust\r\nand flexible than the existing ones.\r\nWe also collected and summarized available information about the actor who is apparently the sole developer of\r\nDarkGate. This actor advertised the DarkGate malware on several cybercrime forums and posted information\r\nabout the features of the malware that match our analysis results. Furthermore, the actor posted several demo\r\nvideos, which show details of the DarkGate backend panel.\r\nThe current spike in DarkGate malware activity is plausible given the fact that the developer of the malware has\r\nrecently started to rent out the malware to a limited number of affiliates. Before that, the malware was only used\r\nprivately by the developer. It can be expected that the introduction of the MaaS program will lead to more frequent\r\nmalware campaigns involving DarkGate malware, meaning that the malware will likely pose as an ongoing threat\r\nin the months and years to come.\r\nInfection Chain Overview\r\nDuring the last weeks, Telekom Security observed an infection chain where the initial payload was delivered via\r\nan MSI installer file. Victims would get this file by clicking a link that is contained in a phishing message that they\r\nreceived. This link initially points to what is likely a traffic distribution system (TDS). If the requirements set by\r\nthe attacker are met, the TDS will redirect the victim user to the final payload URL for the MSI download. When\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 1 of 19\n\nthe user opens the downloaded MSI file, the DarkGate infection is triggered. The details of the infection process\r\nwill be described later on.\r\nAdditionally, Telekom Security observed samples of a different campaign where the initial payload was delivered\r\nas a Visual Basic script. In this case, we do not know how exactly the initial payload was delivered to the victim\r\nuser. The script, which is obfuscated and contains decoy/junk code, eventually invokes the curl binary that\r\ncomes pre-installed with Windows to download the AutoIt executable and script file from an attacker-controlled\r\nserver. Thereafter, the infection chain works exactly as in the other campaign described in this document.\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 2 of 19\n\nInitial payloads\r\nMSI variant\r\nIn the campaign where the initial payload was delivered as an MSI file, the file seems to be generated by the\r\nSoftware “MSI Wrapper” by www.exemsi.com, as can be seen from file Metadata:\r\nApplication Verifier x64 External Package - UNREGISTERED - Wrapped using MSI Wrapper from\r\nwww.exemsi.com\r\nFor this infection chain, the initial payload is self-contained, meaning that all further payloads are embedded into\r\nthe file and that no further payloads need to be pulled from external sources to complete the DarkGate infection.\r\nSpecifically, the file contains an AutoIt executable and a corresponding script which is executed by the installer.\r\nVBS variant\r\nFor the campaign where the initial payload was delivered as a VBS file, the sample contained a lot of garbage\r\nfunctions, which can be seen in the screenshot below. The real infection code is hidden in several strings, which\r\nare additionally obfuscated by inserting random junk sequences. After removing this obfuscation layer, the script\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 3 of 19\n\nlogic is easily readable and rather simple. The script will spawn a cmd.exe shell using ShellExecute and use\r\nthe curl binary that is shipped by default in current Windows installations to download an AutoIt executable and\r\na corresponding AutoIt script. Both files will be placed in a newly created folder on the C:\\ drive. Notably, in at\r\nleast one case we observed that the script was copying the curl binary to the new folder and invoking it from\r\nthere, which is most likely an attempt of the threat actor to evade existing EDR detection rules.\r\nAutoIt script analysis\r\nThe AutoIt script is bundled with the .au3 file extension which is usually used for plain-text scripts. Instead it\r\ncontains a pre-compiled script, which would typically use the .a3x extension. We can see that it is a compiled\r\nscript from the magic bytes AU3!EA06 , which for some reason are not at the start of the file, but follow a long\r\nsequence of base64-encoded data (we will come back to that below!).\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 4 of 19\n\nThe script can be decompiled using myAut2Exe (a pre-compiled binary can be found here) after renaming the file\r\nfrom .au3 to .a3x . Analysis of the decompiled script shows that the sole purpose of the script is to execute a\r\nshellcode that is contained as a hex-encoded string:\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 5 of 19\n\nThe screenshot above only shows an excerpt of the complete sequence to create the shellcode string. This string is\r\nthen decoded to binary data and written to a newly allocated memory area using the BinaryToString and\r\nDllStructCreate function calls. Finally, two commands are executed. These commands are obfuscated as hex-encoded strings. Decoding these strings reveals their purpose, which is to make the newly allocated memory area\r\nexecutable with VirtualProtect and call the shellcode using CallWindowProc :\r\nDllCall(\"kernel32.dll\", \"BOOL\", \"VirtualProtect\", \"ptr\", DllStructGetPtr($MFCKuCoyGW), \"int\", BinaryLen($MzrsVi\r\nDllCall(\"user32.dll\", \"lresult\", \"C\"\u0026chr(97)\u0026\"llWindowProc\", \"ptr\", DllStructGetPtr($MFCKuCoyGW), \"hwnd\", 0, \"ui\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 6 of 19\n\nWe will later on see that extraction and analysis of this shellcode is actually not required if we are only interested\r\nin the final DarkGate malware payload. However, in the following part we will quickly go over the remaining\r\ninfection chain steps to give a brief overview of the complete process.\r\nShellcode analysis\r\nThe shellcode embeds a PE file in the form of stack strings, as can be seen in the screenshot below (characteristic\r\nMZP header at the start of the constructed string). The sole purpose of the shellcode is to load and eventually\r\nexecute this PE file. We did not analyze all details of this process. Instead we emulated the shellcode to the point\r\nwhere the complete PE file was written to the stack and then dumped the corresponding memory section for\r\nfurther analysis.\r\nInitial dropper/loader analysis\r\nThe PE file extracted from the previous step is rather small (~15 KB). When executing it in our sandbox, we were\r\npresented with the following error message. Apparently, the file is some sort of loader that requires an additional\r\nresource to function properly.\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 7 of 19\n\nWhen tracing the loader with a debugger, it became evident that it was trying to locate and read the .au3 script\r\nfile described above. If the .au3 file was found, the program execution continued and it was visible that the\r\nloader accessed the base64-encoded sequences present in the script file to decode and execute yet another PE file.\r\nAs other researchers already described the specifics of this process are as follows: In the script file, there exist\r\nseveral base64 strings that are separated with a | character. The loader will use the second of these strings to\r\ncompute a single byte XOR key. The third base64 string contains the final payload, which is the DarkGate\r\nmalware sample. After performing the base64 decoding, the loader applies the XOR key and a final NOT\r\noperation to reveal the decrypted PE file.\r\nIt should be noted that this process can easily be implemented by researchers to allow for static decryption of\r\nDarkGate malware samples that make use of this encryption process. Futhermore, due to the use of just a single\r\nbyte XOR key, there is a very limited number of possible permutations of the encrypted PE file. This can be\r\nhelpful for several reasons:\r\n1. To implement YARA rules to hunt/detect DarkGate payloads encrypted with the AU3 technique: We have\r\ncreated a script that calculates all 256 possible permutations of the characteristic MZ header.\r\n2. To perform brute-force decoding of encrypted DarkGate payloads: If the file is padded in some way or\r\nsome of the specifics of the decryption process change, we are still able to decrypt the payload by just\r\nprobing all 256 possible permutations and checking the result for expected characteristic patterns.\r\nObviously, such brute-force processes can also yield false positive results. Hence careful validation of the\r\ndecrypted payloads is required.\r\nDarkGate Malware Analysis\r\nWith the steps described above we are able to unpack the main payload binary, which is the DarkGate malware\r\nitself. The sample is programmed and compiled using Delphi. When reverse engineering the sample, Ghidra\r\ninitially was not able to reconstruct the used Delphi library functions and objects. Using the Dhrake project (which\r\nuses the output generated by Interactive Delphi Reconstructor (IDR)) greatly helped to make the decompiled\r\nsample more readable.\r\nFor reversing the sample, we had the following main objectives:\r\nFind out how the C2 server and other configuration data can be extracted\r\nIdentify defense evasion mechanisms and anti-analysis techniques used by the malware\r\nGet a general overview of the malware’s capabilities\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 8 of 19\n\nTwo strings to rule them all?\r\nOur analysis of the unpacked/decrypted DarkGate malware sample revealed that beside some human-readable\r\nstrings there exist a lot of base64-encoded strings. However, it was not possible to reveal any meaningful content\r\nby applying standard base64 decoding. As other researchers already pointed out the string encryption uses base64,\r\nbut with a non-standard alphabet/table. The binary contains multiple functions that receive the encoded string and\r\nthe alphabet as an input and will output the decoded string.\r\nNotably, there are two different alphabets which are used for different purposes: One alphabet is used to decode\r\ndifferent strings used throughout the binary, whereas the other alphabet is used solely for decoding of the sample\r\nconfiguration.\r\nOur analysis of further DarkGate samples shows that at least one of the alphabet strings changes frequently.\r\nHence, to provide a robust string and configuration decoder, we need to identify the used alphabet for each\r\nanalyzed sample. We could of course do this by searching for the relevant functions in each binary and extracting\r\nthe referenced strings, but this would be error-prone even if only small parts of the code or build process change.\r\nSo instead we can make use of the characteristics of the strings in question: These strings will always have the\r\nsame length and contain each character of the base64 alphabet exactly once. Basically we are looking for strings\r\nthat are different permutations of the same characters. We can easily implement this by first searching for potential\r\ncandidates with a regular expression like [A-Za-z0-9+/=]{64} and then checking which candidate contains each\r\nexpected character exactly once, which we implemented by simply sorting all characters of the string and\r\ncomparing the result to a given reference string. This is a robust approach that successfully identified the two\r\ncustom alphabet strings for all samples that we have analyzed.\r\nExtracting and parsing the configuration\r\nOnce we have found a way to decode the encoded base64 strings, accessing and dumping the malware\r\nconfiguration is rather trivial: Configuration data is contained in two different strings. While one of the strings\r\nholds the addresses of the used C2 servers, the other one is a key-value list that contains all other configuration\r\nparameters and flags.\r\nEach configuration value is given as a numeric key in the range of 0 to 20, e.g. the flag that controls\r\nstartup/persistence behavior is set using either 1=No or 1=Yes . Through reverse engineering we identified the\r\npurpose of most of the used flags and values. Our configuration extractor performs a translation of all known flags\r\nto a more human-readable format and outputs the result in JSON format:\r\n{\r\n \"anti_analysis\": false,\r\n \"anti_debug\": false,\r\n \"anti_vm\": false,\r\n \"c2_ping_interval\": 4,\r\n \"c2_port\": 7891,\r\n \"c2_servers\": [\r\n \"http://80.66.88.145\"\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 9 of 19\n\n],\r\n \"check_disk\": true,\r\n \"check_ram\": true,\r\n \"check_xeon\": false,\r\n \"crypter_au3\": true,\r\n \"crypter_dll\": false,\r\n \"crypter_rawstub\": false,\r\n \"crypto_key\": \"bIWRRCGvGiXOga\",\r\n \"flag_14\": 4,\r\n \"flag_18\": true,\r\n \"flag_19\": true,\r\n \"internal_mutex\": \"bbbGcB\",\r\n \"min_disk\": 50,\r\n \"min_ram\": 4096,\r\n \"rootkit\": true,\r\n \"startup_persistence\": true\r\n}\r\nThe meanings of each flag are as follows:\r\nanti_analysis (6) and anti_vm (3) - Enable checks for the presence of typical hardware/driver\r\nidentifiers that are used by common sandbox and VM solutions.\r\nanti_debug (17) - Enables periodic checking of whether or not a debugger is attached to the process.\r\nc2_ping_interval (16) - Sets the initial sleep interval that is used between two “pings” to the C2 server.\r\nThis value is adaptive and can be changed through various functions of the C2 protocol.\r\nc2_port (0) - Sets the port to use for C2 communication. Since the actual addresses of the C2 servers are\r\nstored in a different string, the same port is used for all configured servers.\r\nc2_servers - Not part of the key-value list, but stored in a separate string. Multiple servers can be stored\r\nand are separated with the | character\r\ncheck_disk (5) and check_ram (8) - Enables checking of a minimum disk/RAM size. If enabled, the\r\nvalues of min_disk (4) and min_ram (7) will be used.\r\ncheck_xeon (9) - Enables checking of the CPU to determine whether or not a Xeon processor is used.\r\ncrypter_au3 (13), crypter_dll (12) and crypter_rawstub (11) - Configure which packing/crypting\r\nmechanism is used for the sample. These flags are used in quite a number of different functions (rootkit,\r\npersistence, self-update, …) to trigger the appropriate program logic that applies to each mechanism.\r\ncrypto_key (15) - Used in the C2 communication protocol to encrypt submitted data. We did not yet\r\nperform a detailed analysis of this.\r\ninternal_mutex (10) - Name of the mutex that is used apparently to synchronize different threads or\r\nprocesses of the DarkGate malware. We did not yet perform a detailed analysis of this.\r\nrootkit (2) - Enables different mechanisms to inject the malware code into other processes using process\r\nhollowing techniques.\r\nstartup_persistence (1) - Enables persistence functions of the malware that can write a copy of the\r\nmalware code to disk and create registry run keys.\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 10 of 19\n\nFor flags where we do not yet know their purpose, we simply maintain the numerical value as flag_XX in the\r\nconfiguration output.\r\nMonitoring for specific combinations of configuration flags could be a potential approach to trace and identify\r\ndifferent campaigns or affiliates of the malware. For example, one can see that the following configuration\r\nobtained from another DarkGate sample is quite different to the configuration above.\r\n{\r\n \"anti_analysis\": false,\r\n \"anti_debug\": false,\r\n \"anti_vm\": false,\r\n \"c2_ping_interval\": 32,\r\n \"c2_port\": 80,\r\n \"c2_servers\": [\r\n \"http://a-1bcdn.com\",\r\n \"http://avayacloud.com.global.prod.fastly.net\",\r\n \"http://intranet.mcasavaya.com\"\r\n ],\r\n \"check_disk\": false,\r\n \"check_ram\": false,\r\n \"check_xeon\": false,\r\n \"crypter_au3\": true,\r\n \"crypter_dll\": false,\r\n \"crypter_rawstub\": false,\r\n \"crypto_key\": \"nqSRmVfSEQwfgo\",\r\n \"flag_14\": 32,\r\n \"flag_18\": true,\r\n \"flag_19\": true,\r\n \"internal_mutex\": \"dEcCaG\",\r\n \"min_disk\": 100,\r\n \"min_ram\": 4096,\r\n \"rootkit\": true,\r\n \"startup_persistence\": true\r\n}\r\nFurther DarkGate capabilities and TTPs\r\nIn the following paragraphs, we will summarize further findings of our analysis regarding the capabilities and\r\nTTPs of the DarkGate malware.\r\nPersistence\r\nIf enabled, the malware will write a copy of itself to disk and create a registry run key to persist execution between\r\nreboots.\r\nPrivilege Escalation\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 11 of 19\n\nFor tasks such as the deletion of system restore points the malware can elevate to SYSTEM privileges.\r\nDefense evasion\r\nAs already described above, the sample contains multiple functions to evade typical analysis tools. When the\r\ncorresponding features are enabled and the sample detects an environment that matches one of the checks, it will\r\nsimply terminate the process.\r\nAdditionally, the malware will look for multiple well-known AV products and may alter its behavior depending on\r\nthe result. The found AV product will also be communicated back to the C2 server.\r\nThe malware may also masquerade its presence and inject itself into legitimate Windows processes depending on\r\nthe used configuration.\r\nCredential Access\r\nThe malware contains multiple functions to steal passwords, cookies or other confidential data from the victim\r\nsystem. Targeted programs range from web browsers to email software and also other software such as Discord or\r\nFileZilla. Notably, the malware uses multiple legitimate freeware tools published by Nirsoft to extract confidential\r\ndata.\r\nDiscovery\r\nThe malware is able to query different data sources to obtain information about the operating system, the logged\r\non user, the currently running programs and other things. This information will be sent to the C2 server and is\r\navailable in the threat actor’s panel.\r\nCollection\r\nIn addition to the mechanisms already described above, the malware may also collect arbitrary files from the\r\nvictim system when requested through the C2 channel.\r\nCommand and Control\r\nAfter some initialization functions, the malware proceeds to a function that we identify as the “C2 main loop”. In\r\nthis loop, the malware periodically polls the C2 server for new instructions, executes the received commands, and\r\nfinally sends back the results to the C2 server.\r\nEach command is identified by a numerical value and the C2 main loop that we analyzed contains well over 100\r\ndifferent commands. We did not analyze thoroughly all of the contained commands and functions, but to give a\r\nrough overview most commands fall in one of the following categories:\r\nInformation gathering: Collect system information or other relevant data\r\nSelf-management: Start or stop malware components, control malware settings\r\nSelf-update: Update the malware, download additional components\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 12 of 19\n\nStealer: Steal data from various programs and data sources\r\nCryptominer: Start, stop and configure cryptominer\r\nRAT: Initiate VNC connection, capture screenshots, execute commands\r\nFile management: Browse directories, download files from victim system\r\nBelow one can see an excerpt of some exemplary functions triggered by different commands.\r\nDarkGate Panel\r\nThe developer provided several short videos where some of the backend panel functions are shown. Initially, the\r\ndeveloper opened the “stub builder” through the menu button of the main window. Through several tabs, affiliates\r\ncan set the different configuration options of the malware:\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 13 of 19\n\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 14 of 19\n\nIn addition, there exists an “LNK exploit builder” to disguise the true nature of the malicious content:\r\nWhen the developer executed the built malware in their virtual machine, the victim system became visible in the\r\npanel:\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 15 of 19\n\nThe different commands that can be executed on the victim system are available through a context menu:\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 16 of 19\n\nFinally, the developer provided a short demo of the integrated file manager to view directory contents on the\r\nvictim system:\r\nActor information\r\nA user who goes by the handle RastaFarEye has been advertising DarkGate Loader on the xss.is and\r\nexploit.in cybercrime forums since June 16, 2023. The user seems to be the sole developer of the malware and\r\nstates that more than 20.000 hours of work have been invested since 2017 to develop the project.\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 17 of 19\n\nThe actor is offering different pricing models (1 day = 1k USD, 1 month = 15k USD, 1 year = 100k USD) and\r\nclaims that the price will likely be raised in the future. In addition, the actor seems to limit access to at most 10\r\naffiliates (“slots”) to “keep this project private”.\r\nThe actor advertises DarkGate as the “ultimate tool for pentesters/redteamers” and that it has “features that you\r\nwon’t find anywhere”. In addition, the actor proclaims many times that the tool is completely undetected by\r\ncommon AV products.\r\nAfter initial publication, the actor frequently provided updates about bug fixes, new features and other changes.\r\nContact addresses\r\nThe actor has provided the following contact addresses:\r\nE-Mail: coding_guru@exploit.im\r\nTox: 09B950550CAD95899AC17C0B1384CD55C9BD81396B19EFFE2E80839D641D3221860ADEA89733\r\nTelegram: https://t.me/evtokens\r\nLanguages and location\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 18 of 19\n\nThe actor posted on the xss.is and exploit.in cybercrime forums mainly in English and also developed the\r\npanel and malware in English language. However, from some observed grammatical errors it can be assumed that\r\nEnglish is not the actor’s native language.\r\nWhen the actor received questions in Russian language, they were able to provide answers in Russian language,\r\ntoo. The actor also used cyrillic alphabet for their username Растафарай on Telegram, which can be\r\ntransliterated to Rastafarai.\r\nApart from many English strings, the DarkGate samples we analyzed also contain some Spanish strings, such as\r\nfor example administrador de tareas (task manager). In addition, demo videos posted by the actor show that the\r\nsystem locale and keyboard layout is set to Spanish. The videos also show that the victim VM maintained by the\r\nactor connects to the panel with an IP address from Spain. However, this address likely belongs to a VPN or\r\nanonymization service.\r\nIoCs\r\nDarkGate C2 servers\r\n149.248.0.82\r\n179.60.149.3\r\n185.143.223.64\r\n185.8.106.231\r\n45.89.65.198\r\n5.34.178.21\r\n80.66.88.145\r\n89.248.193.66\r\na-1bcdn.com\r\navayacloud.com.global.prod.fastly.net\r\ndrkgatevservicceoffice.net\r\nintranet.mcasavaya.com\r\nonlysportsfitnessam.com\r\nreactervnamnat.com\r\nsanibroadbandcommunicton.duckdns.org\r\nxfirecovery.pro\r\nAnalyzed Sample\r\nThe analysis results of this report are mainly based on the following sample. Results were confirmed by checking\r\nother samples found via hunting queries.\r\nSHA256 6e068b9dcd8df03fd6456faeb4293c036b91a130a18f86a945c8964a576c1c70 (Link to MalwareBazaar)\r\nSource: https://github.security.telekom.com/2023/08/darkgate-loader.html\r\nhttps://github.security.telekom.com/2023/08/darkgate-loader.html\r\nPage 19 of 19\n\n  https://github.security.telekom.com/2023/08/darkgate-loader.html    \nThe different commands that can be executed on the victim system are available through a context menu:\n   Page 16 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://github.security.telekom.com/2023/08/darkgate-loader.html"
	],
	"report_names": [
		"darkgate-loader.html"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775438992,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6c691fba9bae6f7b5b658dc1e6f07dc526db28b0.pdf",
		"text": "https://archive.orkl.eu/6c691fba9bae6f7b5b658dc1e6f07dc526db28b0.txt",
		"img": "https://archive.orkl.eu/6c691fba9bae6f7b5b658dc1e6f07dc526db28b0.jpg"
	}
}