{
	"id": "a5383d71-ecf5-416d-a4a5-304004ade153",
	"created_at": "2026-04-06T00:06:46.034032Z",
	"updated_at": "2026-04-10T13:12:04.81772Z",
	"deleted_at": null,
	"sha1_hash": "ef1b11c031709b4839ebc368c2294c6d512a2f94",
	"title": "TrickBot: A Closer Look",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2428253,
	"plain_text": "TrickBot: A Closer Look\r\nBy Keysight\r\nArchived: 2026-04-05 16:05:35 UTC\r\nIn early November, the Cybersecurity and Infrastructure Security Agency (CISA) released an advisory warning\r\nadministrators in the healthcare and public sector that TrickBot is being used to disturb healthcare services by\r\nlaunching ransomware attacks and by stealing data. This month, Threat Simulator released a TrickBot assessment\r\ncovering the malware's kill chain. In this post, we'll take a close look at the installation phase of the TrickBot\r\ninfected document that inspired the assessment.\r\nProcess tree for the sample under analysis.\r\nSample.doc Analysis (SHA-1: c2f948d866ff4dfa8aaebda5507c7d606ac9fb28)\r\nThe sample is a .doc file, an older file type for Microsoft Word, also known as Microsoft Word 97-2003 format.\r\nThis file type may contain Visual Basic for Applications (VBA) macros.\r\nThe document convinces the target to click Enable Editing and Enable Content. This is common for malicious\r\nmacro enabled documents to bypass security prompts and run the macro code embedded within it.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 1 of 15\n\nThe document contains the Document_Close event procedure. Upon closing of the document, the\r\nDocument.Close event will fire and the Document_Close procedure will be called. This will evade sandboxes that\r\ndo not close the document during analysis.\r\nThe Document_Close procedure will delay execution for 2 seconds and then proceed to call the function\r\nResetCalcD. ResetCalcD will call another function named UniqueValues.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 2 of 15\n\nThe UniqueValues function will first create the directory \"C:\\Artrite\\Final_Joana\\\"\r\nThen, UniqueValues will create the file \"C:\\Artrite\\SarilumabSAR153191.part\" and fill it with VBScript\r\ncomments.\r\nFinally, UniqueValues will create the file \"C:\\Artrite\\SarilumabSAR153191.vbe\" and fill it with VBScript\r\ncomments along with the value of the caption \"luinpedrnass.dados.Caption.\" The caption contains the next stage\r\npayload, a VBScript file.\r\nAfter the call to ResetCalcD, the Document_Close procedure will create an Excel.Application object. As a result,\r\nsvchost.exe will spawn a process for excel.exe. This will mask the calling process, winword.exe in this case, and\r\nwill make tracking the process tree and kill chain of the malware more difficult.\r\nNext, the DisplayAlert property is set to False. This will prevent UI pop-ups from being presented to the user.\r\nFinally, the DDEInitiate method is called. This method will launch an application if the target system has the\r\nDynamic Data Exchange Server Launch Trust Center setting enabled. This setting is no longer enabled by default.\r\nIf configured to do so, DDEInitiaite will cause excel.exe to launch cmd.exe with the command-line:\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 3 of 15\n\nFinally, wscript.exe will execute the next stage, C:\\Artrite\\SarilumabSAR153191.vbe.\r\ntl;dr: The malicious document will use the Document_Close VBA macro to drop and execute a VBE file upon\r\nclosing the document.\r\nSarilumabSAR153191.vbe Analysis\r\nThe script file contains double base64 encoded data in a variable named tData.\r\ntData is decoded using the function DecodeBase64_1.\r\nDecodeBase64_1 uses the Microsoft.XMLDOM object to decode base64 encoded data and uses the Adodb.Stream\r\nobject to write the decoded contents to “C:\\Artrite\\Final_Joana\\WhatAreTopFacts.rtc”\r\nThere is minor obfuscation using the Chr function to hide the strings \"b64\" and \"bin.base64\"\r\nThe data is then decoded a second time with a similar base64 decoding function and once again saved to\r\n“C:\\Artrite\\Final_Joana\\WhatAreTopFacts.rtc”\r\nFinally, an Excel DDE is used once again to launch the next stage, WhatAreTopFacts.rtc (a 32-bit DLL file), using\r\nrundll32.exe\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 4 of 15\n\ntl;dr: SarilumabSAR153191.vbe will drop and execute a 32-bit DLL file using rundll32.exe.\r\nWhatAreTopFacts.rtc Analysis\r\nWhatAreTopFacts.rtc is a DLL that exports the function DllRegisterServer.\r\nIt is odd that the malware author chose to name the exported function DllRegisterServer while not taking\r\nadvantage of the LoLBins that utilize that exported function. (msiexec.exe, odbcconf.exe)\r\nThe DllRegisterServer function will deobfuscate the strings \"LdrFindResource_U\" and \"LdrAccessResource\".\r\nNext, DllRegisterServer will dynamically resolve the API functions ntdll!LdrFindResource_U and\r\nntdll!LdrAccessResource before calling LdrFindResource_U and LdrAccessResource to fetch the contents of a\r\nresource embedded within the resource section of the binary.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 5 of 15\n\nThe embedded resource has an entropy value of 7.99613 bits per byte. The high entropy suggests that the resource\r\nis encrypted data.\r\nDllRegisterServer will then copy the resource data into freshly allocated PAGE_EXECUTE_READWRITE\r\nmemory.\r\nDllRegisterServer will go onto decrypt the resource data using a dynamically derived key and an XOR based\r\nencryption/decryption routine.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 6 of 15\n\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 7 of 15\n\nFinally, DllRegisterServer will execute the decrypted resource data. The resource data turns out to be encrypted\r\nshellcode.\r\ntl;dr: WhatAreTopFacts.rtc will decrypt and execute encrypted shellcode embedded as a resource.\r\nWhatAreTopFacts.rtc Shellcode Analysis\r\nAt the tail end of the shellcode there is an embedded Portable Executable (PE) file. The embedded PE is a DLL.\r\nThe shellcode begins by using the (JMP)/CALL/POP technique to get the base address of the shellcode. The base\r\naddress is then used to calculate the start and end address of the embedded PE.\r\nIn the shellcode, there is a function that gets a pointer to the PEB and walks the linked list of loaded modules.\r\nThis function implements a common shellcode technique that resolves Windows API functions by using a\r\nprecomputed value using a ROR 13 based hash function.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 8 of 15\n\nThe shellcode will then use the above function to resolve the APIs necessary to load a PE from memory.\r\nThese APIs will be used to load the PE in memory.\r\ntl;dr: The shellcode will load and execute a DLL from memory.\r\nWhatAreTopFacts.rtc Embedded DLL 1 Analysis\r\nThere is an embedded PE within this DLL. The embedded PE is a DLL.\r\nFirst, this DLL dynamically resolves the API function kernel32!GetNativeSystemInfo.\r\nNext, the DLL parses the embedded PE's headers and calculates the PE’s size.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 9 of 15\n\nAfterwards, VirtualAlloc is used to allocate memory at the PE's preferred base address. If memory allocation fails,\r\nthen memory is allocated again, this time letting the OS decide the allocated memory address.\r\nNext, the DLL allocates heap memory for a custom struct and initializes it.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 10 of 15\n\nNext, the DLL copies the PE's headers into the allocated memory region.\r\nThe headers are then used to load the PE's sections into memory.\r\nThe DLL will then go onto perform base relocation, if necessary.\r\nNext, the libraries in the PE's import table will be loaded.\r\nAfterwards, the image base address in the PEB is set to the base address of the next stage PE.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 11 of 15\n\nFinally, the entry point of the next stage PE will be called.\r\nThis DLL is a reflective loader.\r\nThe custom struct from earlier can be used to find the source of this reflective loader implementation. Googling\r\nthe following will lead to a fork of the MemoryModule project:\r\nThe simularity struct definitions suggests that this DLL uses a derivative of the MemoryModule project.\r\nStruct definition from MemoryModule\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 12 of 15\n\nReversed struct definition\r\nThe only significant differences between reflective loader implementations were:\r\nA custom implementation of the C Run-time Library's (CRT) realloc function is used. This is a necessary\r\nsince the CRT's realloc function requires that the CRT is initialized, which it will not be in this case.\r\nGetNativeSystemInfo is dynamically resolved instead of imported\r\nThe image base addresses in the PEB is updated\r\ntl;dr: This DLL will load and execute the next stage DLL from memory using MemoryModule.\r\nWhatAreTopFacts.rtc Embedded DLL 2 Analysis\r\nThis DLL is similar but slightly different to the DLL from the previous stage. The custom struct no longer has a\r\nfield for VirtualAlloc and VirtualFree. This correlates with revisions of MemoryModule prior to commit\r\nd88817fb.\r\nIt is odd that two different versions of the same project are used within the same sample.\r\nThe next stage DLL is launched by calling its DllRegisterServer exported function.\r\ntl;dr: This DLL will load and execute the next stage DLL from memory using MemoryModule (again).\r\nWhatAreTopFacts.rtc Embedded DLL 3 Analysis\r\nFirst, the DLL will allocate PAGE_EXECUTE_READWRITE memory using obfuscated values for the constants:\r\nMEM_COMMIT and PAGE_EXECUTE_READWRITE.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 13 of 15\n\nThen, encrypted shellcode is decrypted using an XOR based encryption/decryption routine.\r\nAfter decryption, the shellcode will be executed using the API function CreateThread.\r\nFinally, the DLL waits 3 seconds for the shellcode to finish before exiting the rundll32 process.\r\ntl;dr: this DLL will decrypt and execute shellcode using the CreateThread.\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 14 of 15\n\nWhatAreTopFacts.rtc Embedded DLL 3 Shellcode Analysis\r\nIn the last part of the installation phase, self-unpacking shellcode is used to create a new 64-bit wermgr.exe\r\nprocess in the suspended state using kernel32!CreateProcessInternalW.\r\nThen, the shellcode transitions the current 32-bit process (rundll32.exe) context into a 64-bit context. This context\r\nswitch will bypass popular API monitoring tools that only hook 32-bit ntdll APIs for WoW64 processes.\r\nAfter switching context, code is injected into the suspended process using the Process Hollowing technique.\r\nFinally to complete installation, the main thread of the wermgr.exe process is resumed.\\\r\nSource: https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nhttps://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/12/21/trickbot_a_closerl-TpQ0.html"
	],
	"report_names": [
		"trickbot_a_closerl-TpQ0.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434006,
	"ts_updated_at": 1775826724,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ef1b11c031709b4839ebc368c2294c6d512a2f94.pdf",
		"text": "https://archive.orkl.eu/ef1b11c031709b4839ebc368c2294c6d512a2f94.txt",
		"img": "https://archive.orkl.eu/ef1b11c031709b4839ebc368c2294c6d512a2f94.jpg"
	}
}