{
	"id": "ea01ce63-e48d-4fe6-a35a-3551b4cc8149",
	"created_at": "2026-04-06T00:08:10.399661Z",
	"updated_at": "2026-04-10T13:12:46.670458Z",
	"deleted_at": null,
	"sha1_hash": "ac2316bad626fcbd6687b3311124acd090edc6e3",
	"title": "Buer Loader Analysis, a Rusted malware program - TEHTRIS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 80437,
	"plain_text": "Buer Loader Analysis, a Rusted malware program - TEHTRIS\r\nBy Laurent Oudot\r\nPublished: 2022-01-20 · Archived: 2026-04-05 19:13:32 UTC\r\nMalware analysis is part of the CTI team’s daily routine. This article presents the analysis of a Rust strain of Buer\r\nLoader from the reception of the samples to the writing of a stage2* extraction script. Despite several protection\r\nmechanisms, it was possible to extract all the samples in different ways. TEHTRIS provides the code for such an\r\nextraction.\r\nIntroduction\r\nAnalysis\r\nConclusion\r\nBIBLIOGRAPHY\r\nIntroduction\r\nThe Rust language [1] is more and more used [2] by developers. Indeed, the philosophy of this language is to\r\nmaximize security while offering performances close to C++ in a pleasant syntax. Many ambitious projects like\r\nKerla [3] aim at offering an operating system that is compatible with any Linux binary, without modification. This\r\ngives Rust a lot of credibility and explains its adoption by developers. From a low-level point of view, this\r\nlanguage generates a more complex binary code to sign and analyze compared to C by offering more instructions\r\nand adding obfuscation at low cost, which is of interest to malware authors.\r\nIf still few adopt it, it is however not surprising to note that this language is starting to make a name for itself in\r\nthe malware bestiary, as shown by Buer Loader [3] which includes variants developed in this language.\r\nIf this malware program has already been analyzed [3], it remains interesting to study its “stage1*” to identify the\r\nprotection mechanisms and the evolutions concerning its obfuscation over time. Indeed, sandbox bypass\r\ntechniques [5] and memory loading of offended binaries [6] by an unknown mechanism have been observed. This\r\nwas enough to trigger the interest of a retro-analysis of the loader in question.\r\nThe goal is to characterize and extract the main load of the malware that was specifically spotted in computing\r\nenvironments between July and August 2021.\r\nAn emulation-based extraction method was presented at the Hack-It-N conference in December 2021. A replay of\r\nthe presentation is available on Youtube [16].\r\nThe retrieved samples work on the same model, i.e. a base in Rust loading in memory a stage2, itself written in\r\nRust. Here is the list of these samples:\r\nSha256\r\nCompile\r\ntime\r\nSize\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 1 of 9\n\n001405ded84e227092bafe165117888d423719d7d75554025ec410d1d6558925\r\n2021-\r\n07-28\r\n17:59:19\r\n3.4\r\nMB\r\n4421dbc01ddc5ed959419fe2a3a0f1c7b48f92b880273b481eb249cd17d59b91\r\n2021-\r\n08-11\r\n15:35:55\r\n6.6\r\nMB\r\n52d8316b0765c147558aecbda686d076783f3a08b2741b8c9e3e717cc56e8a92\r\n2021-\r\n07-19\r\n13:57:22\r\n7.3\r\nMB\r\n580d55f1e51465b697d46e67561f3161d4534a73e8aa47e18b9bae344d46bcf4\r\n2021-\r\n07-19\r\n13:57:22\r\n7.3\r\nMB\r\n578dc62dfa0203080da262676f28c679114d6b1c90a4ab6c07b736d9ce64e43e\r\n2021-\r\n07-15\r\n16:28:54\r\n7.1\r\nMB\r\n5ac6766680c8c06a4b0b4e6a929ec4f5404fca75aa774f3eb986f81b1b30622b\r\n2021-\r\n08-05\r\n14:47:25\r\n4.9\r\nMB\r\n64dd547546394e1d431a25a671892c7aca9cf57ed0733a7435028792ad42f4a7\r\n2021-\r\n08-16\r\n18:54:29\r\n4.1\r\nMB\r\n88689636f4b2287701b63f42c12e7e2387bf4c3ecc45eeb8a61ea707126bad9b\r\n2021-\r\n08-03\r\n15:46:42\r\n3.3\r\nMB\r\nafb5cbe324865253c7a9dcadbe66c66746ea360f0cd184a2f4e1bbf104533ccd\r\n2021-\r\n06-25\r\n17:49:48\r\n7.1\r\nMB\r\nc425264f34fa8574c7e4321020eb374b9364a094cda9647e557b97d5e2b8c17b\r\n2021-\r\n08-16\r\n18:54:29\r\n4.1\r\nMB\r\nd3a486d3b032834b1203adefd25d0bf0b36fae7f9e72071c21ccc266e1e1f893\r\n2021-\r\n07-19\r\n14:14:54\r\n4.3\r\nMB\r\nThe compilation dates seem consistent with each other. Indeed, they match approximately the submission dates on\r\nVirus Total [15] (with a small delay). The binaries are stripped (i.e. symbols unnecessary for the binary to work\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 2 of 9\n\nhave been removed, especially function names and debugging symbols) but still contain information about the\r\nused source code:\r\nUnfortunately, BinDiff [7] is not able to compare binaries. The control flow is too complex for it. Therefore, the\r\ncode comparisons were done manually by our experts.\r\nBinDiff error\r\nOur analysis determined that there seem to be only 2 source files outside of the open source (mainly\r\ncryptographic) libraries used. A first anti-sandbox technique consists in wasting time by performing an\r\nunnecessary loop. The order of magnitude of the time needed (and lost) is about one minute with a 100% occupied\r\nCPU.\r\nAnti-sandbox by waste of time\r\nAfter passing through this loop, we arrive at the decryption function of stage2. This one contains a large number\r\nof successive calls to useless functions, among which we find:\r\nGetCommandLineA;\r\nGetCurrentProcess;\r\nGetEnvironmentStrings;\r\nGetLastError;\r\nGetProcessHeap;\r\nGetTickCount;\r\nIt is probably a saturation mechanism using calls (call to a Windows library) and not taking any argument to\r\noverride possible sandboxes, which complicates code emulation. It seems that a script generates all the calls. This\r\ntechnique also has the advantage of adding a credible call/instruction ratio compared to a legitimate program.\r\nCounting the calls sometimes allows to find decryption or unpacking routines:\r\nDecoys variant 1\r\nDecoys variant 2\r\nThese calls are repeated throughout the desobfuscation routine. The data are successively pushed on the stack,\r\nthen in the heap with the help of kernel32 !HeapAlloc, in the form of DWORD:\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 3 of 9\n\nStage2 buffer reconstruction\r\nThe call graph is very different across samples, reinforcing our hypothesis that the code is generated from a script.\r\nThe mix of calls and desobfuscation involves a special effort to blend in a behavior that appears to be legitimate.\r\nControl flow Variant1\r\nControl flow Variant2\r\nControl flow Variant3\r\nThis technique allows to include binary data by limiting the entropy between 0.5 and 0.8, very close to what one\r\nwould expect from legitimate instructions.\r\nEntropy of the malware program\r\nThis data, once reconstituted, is placed in a buffer which is decrypted. We then recognize a Key Schedule type\r\nmechanism, followed by a generator reminiscent of RC4:\r\nKSA block\r\nRC4 Random generator\r\nThe Rust paradigm makes these decryption routines difficult to identify. Tools such as findcrypt [8] do not detect\r\nthem. The following check identifies the entire desobfuscation chain:\r\nDecryption in python\r\nThe decompression is performed by the version 0.1.3 of the lzma-rs library [9], and the decryption keys are easily\r\nvisible in the code. The following script allows its extraction:\r\nKey extraction script\r\nThe list of RC4 keys for the samples is as follows:\r\nYDVHHCYTCH ;\r\nDQOQHMLGYU ;\r\nBWSCVQZXOB ;\r\nSIMHIDVSCR ;\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 4 of 9\n\nRGZPMAAQRP ;\r\nYVMOOVSIOF ;\r\nKSQKGUUTXZ ;\r\nEUWPUQYDTT ;\r\nKHBXNNHKNN ;\r\nUnfortunately, the number of keys is insufficient to evaluate the quality of the PRNG [10]. Note that the charset is\r\nvery small, which does not matter since the key is in plain text in the “.rdata” section. Given the extremely\r\nvariable and complex call graph, writing a generic data extraction script that works for all samples is tedious. Now\r\nthat we know the key (cf. previous extraction script), we need to find the encrypted data. These, once\r\ndesobfuscated, have a header with invariant data:\r\n3 blocks of encrypted buffer header\r\nThe following script then allows to find the extracted data in memory, provided that the program has performed\r\nthe decryption phase by carrying out an Egg-hunting search:\r\nEncrypted data recovery script\r\nThe only thing missing to automate the extraction is to find an address or to set a breakpoint, which is done in a\r\nfairly logical way by finding the references to the RC4 key:\r\nMalware launching script\r\nAnd the script works on the first try for all samples. The source code of the tool is available on the TEHTRIS\r\ngithub [19].\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 5 of 9\n\nAn alternative method was presented at the Hack-it-N conference [16]. It consists in extracting the stage2 by\r\nemulation using the unicorn lib [17]. The source code is available on the TEHTRIS github [18].\r\nThe extraction of stage2 from the studied samples gives the following list:\r\nSha256\r\nStage1\r\ncompile\r\ntime\r\nStage 2\r\ncompile\r\ntime\r\nedc3b5f8d45d7a1cceee144e57fc5ddfaf8c0c7407a1514d2f3bab4f3c9f18b8\r\n2021-\r\n07-28\r\n17:59:19\r\n2021-\r\n07-28\r\n17:39:31\r\nd7ec38c0e89a749a7727e5644328835b50e19302e9f3a4688809403ebcbd03d2\r\n2021-\r\n08-11\r\n15:35:55\r\n2021-\r\n08-11\r\n15:30:38\r\n6578db32dc78ef7f41213557cf894d03b97ed6974ae7a72bec9b7c7ac08c4ba9\r\n2021-\r\n07-19\r\n13:57:22\r\n2021-\r\n07-19\r\n13:44:11\r\nd48d91451b9594eadc0d1ef6e379bbce9a6033bd337e06d46613a70187c9c5ef\r\n2021-\r\n07-15\r\n16:28:54\r\n2021-\r\n07-15\r\n16:20:18\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 6 of 9\n\n54109b12cbbd223f5ad79a9f87bfe50ef05a80e5551a3c1931748c3698900496\r\n2021-\r\n08-05\r\n14:47:25\r\n2021-\r\n08-05\r\n14:38:43\r\n2d8a2bcc45daedd343eadb4222885d12a221bebbf7f1d98f92cb233df0a4c1d4\r\n2021-\r\n08-16\r\n18:54:29\r\n2021-\r\n08-16\r\n18:45:22\r\n16feaed6222ce4a1941ae0c32eabaf0ecf68c33c49544f71d431d1b70c4247fd\r\n2021-\r\n08-03\r\n15:46:42\r\n2021-\r\n08-03\r\n15:38:18\r\n7af554fb260817350d33b801d9f0b8a638b831992f4b1b31c2bbdab875b211df\r\n2021-\r\n06-25\r\n17:49:48\r\n2021-\r\n06-25\r\n17:43:23\r\n2d8a2bcc45daedd343eadb4222885d12a221bebbf7f1d98f92cb233df0a4c1d4\r\n2021-\r\n08-16\r\n18:54:29\r\n2021-\r\n08-16\r\n18:45:22\r\n039d63a07372e6e17f9779ccffbafbf9a06a9402ade58fbec3b0b2f8d2038175\r\n2021-\r\n07-19\r\n13:57:22\r\n2021-\r\n07-19\r\n13:46:46\r\nThe timestamps seem coherent between themselves and we note that the compilation dates correspond with a gap\r\nof 5 to 10 minutes, suggesting a manual packing step.\r\nWe note that stage2 verifies the presence of a virtual machine by testing the presence of the following executables:\r\n\u003e vboxservice.exe ;\r\n\u003e vboxtray.exe ;\r\n\u003e vmtoolsd.exe ;\r\n\u003e vmwaretray.exe ;\r\n\u003e vmwareuser.exe ;\r\n\u003e vmacthlp.exe ;\r\n\u003e vmsrvc.exe ;\r\n\u003e vmusrvc.exe ;\r\n\u003e prl_cc.exe ;\r\n\u003e prl_tools.exe ;\r\n\u003e xenservice.exe ;\r\n\u003e qemu-ga.exe ;\r\n\u003e windanr.exe.\r\nOnce the desobfuscation step is done, the binary is no longer obfuscated and easily delivers its secrets. For\r\nexample C2 [11]:\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 7 of 9\n\nList of C2 URLs\r\nOr encrypts list of files constituting the source code:\r\nSource code metadata\r\nThe analysis of the stage2 has already been done, however, and we will not describe it here.\r\nConclusion\r\nEvading automated malware detection systems is a balancing act between binary entropy, hiding encryption\r\nfunctions, slowing down the analysis time, obtaining a consistent call/instruction ratio…\r\nThe use of Rust adds a machine code overlay which is however much less than what a Go [12], delphi [13],\r\ncython [14], etc. compiler would do, making a manual analysis quite reasonable.\r\nHowever, these techniques are no match for a reverser or a well-configured sandbox. The manual analysis of the\r\nmost known and least traceable threats is a plus in the continuous improvement of our sandbox and EDR products.\r\nIt is very likely that in the future, more and more malware programs will be developed in Rust.\r\n* The use of stageN consists in separating the malware program into several specialized sub-parts in order to\r\nescape antivirus detection. In this case, stage1 is the malware program as sent to victims and stage2 is the payload\r\nencapsulated in stage1.\r\nBIBLIOGRAPHY\r\n[1] https://www.rust-lang.org/\r\n[2] https://www.tiobe.com/tiobe-index/rust/\r\n[3] https://github.com/nuta/kerla\r\n[4] https://www.proofpoint.com/us/blog/threat-insight/new-variant-buer-loader-written-rust\r\n[5] https://fr.wikipedia.org/wiki/Sandbox_(s%C3%A9curit%C3%A9_informatique)\r\n[6] https://fr.wikipedia.org/wiki/Offuscation\r\n[7] https://www.zynamics.com/bindiff.html\r\n[8] https://github.com/you0708/ida/tree/master/idapython_tools/findcrypt\r\n[9] https://github.com/gendx/lzma-rs\r\n[10] https://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9rateur_de_nombres_pseudo-al%C3%A9atoires\r\n[11] https://www.trendmicro.com/vinfo/us/security/definition/command-and-control-server\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 8 of 9\n\n[12] https://golang.org/\r\n[13] https://www.embarcadero.com/fr/products/delphi\r\n[14] https://cython.org/\r\n[15] https://www.virustotal.com\r\n[16] https://www.youtube.com/watch?v=4Lux_0IROMY\r\n[17] https://www.unicorn-engine.org/\r\n[18] https://github.com/tehtris-hub/MalwareTool/blob/main/Buer/extract_buer.py\r\n[19] https://github.com/tehtris-hub/MalwareTool/blob/main/Buer/extract_buer_debug.py\r\nSource: https://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nhttps://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://tehtris.com/en/blog/buer-loader-analysis-a-rusted-malware-program"
	],
	"report_names": [
		"buer-loader-analysis-a-rusted-malware-program"
	],
	"threat_actors": [],
	"ts_created_at": 1775434090,
	"ts_updated_at": 1775826766,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ac2316bad626fcbd6687b3311124acd090edc6e3.pdf",
		"text": "https://archive.orkl.eu/ac2316bad626fcbd6687b3311124acd090edc6e3.txt",
		"img": "https://archive.orkl.eu/ac2316bad626fcbd6687b3311124acd090edc6e3.jpg"
	}
}