{
	"id": "e1767b07-4654-4a32-a774-80e7f7bc52f6",
	"created_at": "2026-04-06T00:19:31.189516Z",
	"updated_at": "2026-04-10T03:24:23.517732Z",
	"deleted_at": null,
	"sha1_hash": "a5b65263e5d3ddc8ea4f3c0c398d617e79aaf70d",
	"title": "New DarkGate Variant Uses a New Loading Approach",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 197173,
	"plain_text": "New DarkGate Variant Uses a New Loading Approach\r\nBy Leandro Fróes\r\nPublished: 2023-11-01 · Archived: 2026-04-05 22:28:49 UTC\r\nSummary\r\nIn the past month, the Netskope Threat Labs team observed a considerable increase of SharePoint usage to deliver\r\nmalware caused by an attack campaign abusing Microsoft Teams and SharePoint to deliver a malware named\r\nDarkGate.\r\nDarkGate (also known as MehCrypter) is a malware that was first reported by enSilo (now Fortinet) in 2018 and\r\nhas been used in multiple campaigns in the past months. Since its recent update announcement in an underground\r\nforum, several campaigns have been conducted to deliver the malware using different methods, such as phishing\r\nand SEO poisoning.\r\nDarkGate appeals to many attackers because of its broad feature set, which includes HVNC, keylogging,\r\ninformation stealing, and downloading and executing other payloads. DarkGate can be used as a starting point for\r\nbigger attacks, including Ransomware infections.\r\nNetskope Threat Labs recently identified a new DarkGate variant delivered via MSI using a loading approach\r\nbased on Cobalt Strike Beacon’s default shellcode stub. Correlating the analyzed samples with findings from other\r\nresearchers, we could determine that this is part of a new version of the DarkGate malware. Let’s take a closer\r\nlook:\r\nInfection analysis\r\nThe infection starts via a fake invoice email delivering a PDF document to the victim. The PDF file contains a\r\nDocuSign template that is used as an attempt to lure the user to open a document to be reviewed:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 1 of 18\n\nExample of the malicious document sent to the victim\r\nOnce the user clicks on the fake document a CAB file is downloaded. The CAB file contains an internet shortcut\r\nthat once executed downloads an MSI file to the infected machine:\r\nInternet shortcut leading to the MSI download\r\nOnce the user executes the MSI file a whole chain of loading mechanisms starts using the files presented in\r\nanother CAB file inside the MSI:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 2 of 18\n\nCAB file content\r\nStage 1 – DLL Side-Loading\r\nThe chain starts via the execution of the windbg.exe binary present in the CAB file. The DLL side-loading\r\ntechnique is used here in order to execute a fake version of the dbgeng.dll DLL file. Since windbg.exe imports\r\nfunctions from dbgeng.dll, this DLL will be included in its import table, causing the Windows loader to map the\r\nDLL into windbg.exe’s address space and then execute the DllMain function:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 3 of 18\n\nView of Windbg.exe dependencies in the Import Table using DIE\r\nThe dbgeng.dll is written in the Delphi programming language and has the internal name of SideLoader.dll, a\r\ncommon name observed in several DarkGate DLLs. It also contains export functions required for different\r\nbinaries, such as windbg.exe and KeyScramblerLogon.exe, which was also observed being abused to side-load\r\nmalicious DLLs. \r\nIn the KeyScramblerLogon.exe case, the side-loaded DLL is named KeyScramblerIE.dll and that is also written in\r\nDelphi. The loading methods and decoding algorithm are slightly different from the version presented in this blog,\r\nwhich abuses the WinDbg binary.\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 4 of 18\n\nGeneral overview and Export Table view from the fake dbgeng.dll\r\nUpon execution of its DllMain function dbgeng.dll reads the content of a file named data.bin, present in the same\r\ndirectory, and decodes it using a custom base64 approach using the\r\n“zLAxuU0kQKf3sWE7ePRO2imyg9GSpVoYC6rhlX48ZHnvjJDBNFtMd1I5acwbqT+=” alphabet. This\r\napproach is the same used in other variants of DarkGate.\r\nThe decoded content results in a PE file (also written in Delphi) with a shellcode at the end of the file. The\r\nexecution flow will then be redirected to the base address (first byte of the DOS header) of the decoded file.\r\nThe DOS Header bytes of this file contains a tiny snippet that is responsible for calculating the base address of the\r\ncurrent decoded file, adding the RVA of the decoded shellcode to the base address and then calling it via a “call\r\neax” instruction:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 5 of 18\n\nExample of the execution being redirected to the decoded file DOS Header using x64dbg\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 6 of 18\n\nCall to the decoded shellcode entry\r\nThe technique employed here is very similar to the Cobalt Strike Beacon’s default shellcode stub, which is usually\r\nemployed to call the Beacon’s ReflectiveLoader export function.\r\nThe called shellcode then prepares the file to be executed performing actions such as resolving its Import Address\r\nTable. The LoadLibraryA and GetProcAddress Windows API functions are resolved by hash using the CRC32\r\nalgorithm and then used to resolve the IAT.\r\nThe execution flow is then transferred to the stage 2 entry point:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 7 of 18\n\nStage 2 file entrypoint\r\nStage 2 – Another Delphi loader\r\nThe actions performed by this stage is very similar to the first one. The difference here is that the file read and\r\ndecoded is the data2.bin file. Also, instead of being decoded all at once the malware first tries to find the\r\noccurrence of the “splitres” string in the file and then splits it in two parts. After the malware obtains the two parts\r\nit decodes both using the same custom base64 approach.\r\nThe first decoded part results in the AutoIt.exe binary and the second part is an AutoIt script that will be named\r\nscript.au3. The use of AutoIt files is a well-known approach used by DarkGate actors.\r\nA directory named “tmpa” is created under “C:\\”, both files are written to it, and then the CreateProcessA function\r\nis called to execute the AutoIt script using AutoIt.exe:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 8 of 18\n\nC:\\tmpa directory content\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 9 of 18\n\nAutoIt.exe being used to run the script.au3 script\r\nStage 3 – The AutoIt script\r\nThe executed AutoIt script is responsible for constructing a PE file and executing it via the same DOS header\r\napproach. The DOS header shellcode is executed by using a callback function passed to the EnumWindows API\r\nfunction. \r\nOnce we decode the AutoIt script, we can see the commands responsible for the loading process are encoded in\r\nhexadecimal. The decoded commands were added as comments in the screenshot below to demonstrate the\r\nmentioned actions:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 10 of 18\n\nAutoIt script content with the important commands commented\r\nOnce the callback function is called, the same loading process occurs and the loader shellcode transfers the\r\nexecution to another Delphi binary. The small difference in this case is that instead of going directly to the DOS\r\nheader snippet, the callback function first goes to a kind of gate that would jump to the DOS header:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 11 of 18\n\nDOS Header snippet transferring the execution to the loader shellcode\r\nStage 4 – Again a Delphi loader\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 12 of 18\n\nDecoded Delphi file overview\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 13 of 18\n\nStage 4 entrypoint\r\nLike the stage 2 payload, this payload will also look for a specific pattern in a file, but instead of an external file it\r\nsearches in the script.au3 script content. It looks for the “AU3!EA06” string (a known AutoIt script signature).\r\nUsually this signature would be in the beginning of the file but in this case there’s another occurrence in the file.\r\nOnce this string is found, the first 8 bytes next to the signature will be collected and saved for usage later:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 14 of 18\n\nOccurrence of the AutoIt signature followed by a 8 bytes key value\r\nThe content next to the saved 8 bytes buffer is read and a multi-byte XOR operation is performed against it using\r\nthe buffer as a XOR key. The result of this operation is the DarkGate final payload:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 15 of 18\n\nMulti-byte operation resulting in the final Darkgate payload\r\nDuring the investigation we observed different XOR keys used for different payloads. The following is a list of\r\nsome of the obtained keys:\r\nSHA256 XOR key\r\n1fb6b8bed3a67ee4225f852c3d90fd2b629f2541ab431b4bd4d9d9f5bbd2c4b7 vJDAbKIz\r\n567d828dab1022eda84f90592d6d95e331e0f2696e79ed7d86ddc095bb2efdc8\r\n99f25de5cc5614f4efd967db0dae50f20e2acbae9e98920aff3d98638b9ca1f1\r\nde3f49e68c45db2f31d1cc1d10ff09f8cfce302b92a1f5361c8f34c3d78544e5\r\nELkMtLfA\r\n68952e8c311d1573b62d02c60a189e8c248530d4584eef1c7f0ff5ee20d730ab RmDbBDsf\r\nd4e766f81e567039c44ccca90ef192a7f063c1783224ee4be3e3d7786980e236 xfNwSUCl\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 16 of 18\n\nSHA256 XOR key\r\n5e94aa172460e74293db106a98327778ae2d32c6ce6592857a1ec0c581543572 tCFMLSBD\r\nExactly like the other stages, the execution flow will be transferred to the decoded file DOS header which will call\r\nthe loader shellcode entry, and then the shellcode will call the DarkGate payload entry point:\r\nDarkGate final payload entrypoint\r\nThe following is an example of the configuration extracted from the DarkGate payload:\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 17 of 18\n\nDarkGate configuration example\r\nIn order to facilitate the final DarkGate payload extraction Netskope Threat Labs created a script to automate this\r\nprocess.\r\nNetskope Detection\r\nNetskope Threat Protection\r\nWin32.Trojan.TurtleLoader\r\nWin32.Trojan.DarkGate\r\nNetskope Advanced Threat Protection provides proactive coverage against this threat.\r\nGen.Malware.Detect.By.StHeur indicates a sample that was detected using static analysis\r\nGen.Malware.Detect.By.Sandbox indicates a sample that was detected by our cloud sandbox\r\nConclusions\r\nAlthough DarkGate is a threat created years ago it has been very active recently. Several campaigns involving\r\ndifferent delivery and loading methods have been used, as well as new malware features being added, which\r\nrequires a lot of action from the security community. Netskope Threat Labs will continue to track how the\r\nDarkGate malware evolves and its TTP.\r\nIOCs\r\nAll the IOCs related to this campaign, scripts, and the Yara rules can be found in our GitHub repository.\r\nSource: https://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nhttps://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.netskope.com/jp/blog/new-darkgate-variant-uses-a-new-loading-approach"
	],
	"report_names": [
		"new-darkgate-variant-uses-a-new-loading-approach"
	],
	"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
		}
	],
	"ts_created_at": 1775434771,
	"ts_updated_at": 1775791463,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a5b65263e5d3ddc8ea4f3c0c398d617e79aaf70d.pdf",
		"text": "https://archive.orkl.eu/a5b65263e5d3ddc8ea4f3c0c398d617e79aaf70d.txt",
		"img": "https://archive.orkl.eu/a5b65263e5d3ddc8ea4f3c0c398d617e79aaf70d.jpg"
	}
}