{
	"id": "da80097e-e087-4dac-b6f6-9668e8b1844e",
	"created_at": "2026-04-06T00:10:24.577011Z",
	"updated_at": "2026-04-10T03:36:13.56613Z",
	"deleted_at": null,
	"sha1_hash": "6f40c9e8127244f9d77a2d25df60c43af42fbdb0",
	"title": "Review of the Virus.Win32.Virut.ce Malware Sample",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 795150,
	"plain_text": "Review of the Virus.Win32.Virut.ce Malware Sample\r\nBy Vyacheslav Zakorzhevsky\r\nPublished: 2010-06-10 · Archived: 2026-04-05 20:35:45 UTC\r\nIntroduction\r\nThis article is dedicated to the polymorphic virus known as Virus.Win32.Virut and to its ‘ce’ variant in particular.\r\nWhy call it Virut.ce?\r\nVirut.ce is one of the most widespread pieces of malware to be found on users’ computers. It infects executable\r\nfiles using the very latest techniques and that makes detecting and treating those files particularly difficult. The\r\ncurrent means by which most malicious files are actively spread is server-side polymorphism. Infecting files is not\r\nas popular as it used to be about five years ago. This is largely because the level of file emulation has improved\r\ngreatly. As such, you have to hand it to the authors of Virut.ce – they weren’t at all put off by the difficulties they\r\nfaced in trying to infect executable files.\r\nThe technology implemented in Virut.ce accurately reflects the very latest methods used to write malware. Anti-emulation and anti-debugging tools are widely used, such as the tick count received when using multiple rdtsc\r\ninstructions, series of GetTickCount API functions and the calling of multiple fake API functions.\r\nVirut is the fastest-mutating virus known, with a new variant appearing as often as once a week. This indicates\r\nthat its creators are closely monitoring antivirus databases so that they can take prompt action when a new Virut\r\nsignature is released. As soon as this happens, the creators modify the virus so that once again it is undetectable.\r\nInterestingly, the malicious program ensures that its latest version is downloaded to compromised computers by\r\ntaking advantage of infected HTML files as described below.\r\nThis article reviews the methods used to infect files. Obfuscation will also be covered as it is applied each time an\r\nexecutable file is infected. Additionally, the evolution of the virus’ components will be examined, from their\r\nemergence up until the present time. All of the statistics that appear in this article have been collected using\r\nKaspersky Lab’s own Kaspersky Security Network (KSN) technology.\r\nA brief review of statistics and propagation\r\nThe first Virut variant was called Virut.a and appeared back in mid-2006. From that moment on, the strain has\r\nevolved steadily, reaching Virut.q sometime in September 2007.\r\nVirut.q was quite popular at the time, but only rarely occurs these days. Its developers discontinued ‘support’ for it\r\nduring the second half of 2008, but then in the first week of February 2009, a new variant called Virut.ce\r\nappeared. It would seem that the creators of the virus spent the interim period perfecting new infection techniques,\r\nencryption algorithms and anti-emulation methods.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 1 of 18\n\nIt should be pointed out here that any reference to the terms ‘Virut’, ‘the virus’ etc. that appear later in the article,\r\nrefer to Virus.Win32.Virut.ce.\r\nAt present, the Virut.ce variant is the second most popular of all of the versions of Virus.Win32.*.* detected on\r\nusers’ computers.\r\nThe Top 20 most frequently detected viruses\r\nJanuary 2009 – May 2010\r\nFrom the graph below it can clearly be seen that the propagation acitivity of Virut.ce increases with time.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 2 of 18\n\nNumber of computers infected with Virut.ce\r\nMay 2009 – May 2010\r\nThe virus propagates through infected files, both executable and HTML, or smaller programs designed to crack\r\nlicensed software. Such programs generally include key generators (keygens) and direct file modification utilities\r\n(cracks). More specifically, Virut propagates as part of RAR/SFX archives with straightforward names like\r\n‘codename_panzers_cold_war_key.exe’ or ‘advanced_archive_password_recovery_4.53_key.exe’. Such archives\r\ninclude a copy of Virut, either in its original form, or in an infected file alongside the desired program.\r\nVirut’s functionality\r\nNow let us look at the most important feature – Virut’s payload. It is common knowledge that most malware\r\nprograms are exclusively designed for financial gain and Virut is certainly no exception. Effectively, it is a\r\nbackdoor which first attempts to infiltrate the address space of the ‘explorer.exe’ process (‘services.exe’,\r\n‘iexplore.exe’), then it connects to the irc.zief.pl and proxim.ircgalaxy.pl URLs via IRC-protocol and waits for\r\ncommands to arrive. The procedure looks quite conventional, as does the list of processes the virus attempts to\r\nterminate as shown in the screenshot below. This list includes processes belonging to antivirus programs such as\r\n‘nod32’, ‘rising’, ‘f-secure’ and a number of others.\r\nScreenshot showing part of the decrypted static body of Virut.ce\r\nand including the names of processes that are terminated by the virus\r\nInterestingly, the virus infects all of the *.htm, *.php and *.asp files stored on the victim computer. To do so, it\r\nadds the following line to them: ‘\u003ciframe src = http://jl.*****.pl/rc/ style = ‘display:none’\u003e’. This downloads the\r\nlatest version of Virut by exploiting a PDF-file vulnerability. This line may change from version to version within\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 3 of 18\n\nthe ‘ce’ variant. For example, the letter ‘u’ may be substituted by ‘\u0026#117’, which will not affect the browser in\r\nany way, but will prevent static signatures from working.\r\nGeneral discussion and method of infection\r\nVirut.ce uses EPO technology or rewrites the entry point as an infection technique. One or two polymorphic\r\ndecryptors are used in conjunction with it too.\r\nThe Entry Point Obscuring (EPO) technique works by preventing detection of the instruction to jump to the virus\r\nbody. Typically, this is implemented by replacing a random instruction in the program’s original code or the\r\nparameter of the jump instruction. Below is an example of how an instruction and the jump address can be\r\nsubstituted.\r\nThe term ‘rewriting the entry point’ implies modifying the PE header of the file being infected, specifically\r\nrewriting the AddressOfEntryPoint field in the IMAGE_NT_HEADERS32 structure. Consequently file execution\r\nwill start directly with the virus component.\r\nAs discussed earlier, the virus adds only one or two decryptors during infection – let us call them ‘Init’ and\r\n‘Main’. The Main decryptor is located in every file touched by Virut.ce, while the Init decryptor occurs only\r\noccasionally. Let us take a closer look at the function and general appearance of this decryptor.\r\nThe primary purpose of the Init decryptor is to decipher the first layer of the virus’ main body in order to hand\r\nover control to it. However, the bulk of the virus’ body remains encrypted even after this initial decryption has\r\noccurred. The Init decryptor is a small piece of code between 0x100 and 0x900 bytes long and contains many\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 4 of 18\n\npurposeless instructions that prevent static antivirus signatures from working. The decryptor is placed at the end of\r\na section of code if there is a sufficient number of zeros. The decryptor works as follows:\r\n1. 1 It writes the size of the encrypted section to the register;\r\n2. 2 Performs a logical/arithmetic operation on the encrypted section with a constant key;\r\n3. 3 Increments/decrements the pointer to the encrypted section;\r\n4. 4 Jumps back to instruction 2 until everything is decrypted.\r\nThe main body of the virus is 0x4000 to 0x6000 bytes in size and is located at the end of the last section, which is\r\nextended specifically for this purpose and flagged as write/read-accessible and executable.\r\nThus, four ways for possible infection exist:\r\nInit Decryptor + EPO:\r\nInit Decryptor + modifications to the EP:\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 5 of 18\n\nEPO only:\r\nRewriting the entry point only:\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 6 of 18\n\nThese four methods of contagion cover all the possible ways to infect a file or modify its structure.\r\nPrimary decryption of Virut.ce’s body\r\nBefore we go on to discuss the payload of the virus’ main body, let us look at the Init decryptor in a genuinely\r\ninfected file.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 7 of 18\n\nFragment of a file infected by Virus.Win32.Virut.ce which includes the Init decryptor\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 8 of 18\n\nThe disassembled code of the Init decryptor\r\nThe first of the screenshots above shows a fragment of an infected calc.exe file. The boundaries of the code\r\nsection are marked and the Init decryptor is highlighted also. The second screenshot shows the disassembled code\r\nof the Init decryptor. The four logical elements discussed above are shown in red ovals.\r\nIn this example, the ECX register is filled with multiple push/pop instructions and decrypted with the adc\r\ninstruction. However, this procedure has not always been the same. Virut.ce has evolved rapidly in the last year\r\nand so has the incorporated Init decryptor. If the virus body size written into the registry has been modified once\r\n(mov reg, dword changed to push dword; pop reg), the decryption procedure changes more than once (in date\r\norder):\r\n1. 1 ADD/SUB [mem], dword;\r\n2. 2 ROL/ROR [mem], byte;\r\n3. 3 ADC/SBB [mem], byte;\r\n4. 4 ADD/SUB [mem], byte;\r\n5. 5 ADD/SUB [mem], word;\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 9 of 18\n\n6. 6 ADC/SBB [mem], word;\r\n7. 7 ADC/SBB [mem], dword;\r\nNow that we have reviewed the general schemes by which infection occurs and the primary processing of the\r\nvirus’ main body, we can move on to reviewing the execution of the major part of Virut, which is always located at\r\nthe end of the last section.\r\nRestoring the original code\r\nThe code of the main body can be subdivided into three groups according to purpose: the restoration of the\r\noriginal function/entry point, the decryption of the static body and the execution of the payload.\r\nBefore we review each element, let us review the structure of the virus body and have a look at the associated part\r\nof the file.\r\nThe structure of the main body of Virut.ce\r\nAs can be seen in the picture, the main body added to the end of the code’s last section is made up of two types of\r\ncomponents: the encrypted static body and the executable code. The executable part contains a code which\r\nperforms anti-emulation, restores the original entry point and/or function and decrypts the static body. It is\r\nscattered over the main body and may be located at the top or bottom or be split in two. Interestingly, the\r\nexecutable part is also heavily obfuscated. This complicates detection as there are no static elements in the original\r\nfile and a static element is obviously encrypted using different keys and/or algorithms, as will be demonstrated in\r\nthe discussion below.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 10 of 18\n\nFile fragment containing the main body of Virus.Win32.Virut.ce\r\nThe above picture shows a screenshot of a fragment of a file infected with Virus.Win32.Virut.ce. The executable\r\npart of the virus’ main body is highlighted with a red oval; it can also be identified visually as it contains a lot of\r\nzero bytes. In this instance, the virus has not used the Init decryptor during the infection process; otherwise, all of\r\nthe sections would look similar and be encrypted.\r\nLet us now look at the block dedicated to restoring the file’s original part. The logic of this block may be\r\nrepresented as follows:\r\n1. 1 CALL [address with a small increment];\r\n2. 2 Store the original contents of the registers;\r\n3. 3 Add the address pointing to kernel32.dll to the EBX register;\r\n4. 4 Calculate the pointer to the address of the instruction following CALL in item 1;\r\n5. 5 Perform an arithmetic/logical operation on the address obtained in instruction 4.\r\nIt should be noted that the virus uses the EPO technique only if it identifies an API-function being called from\r\nkernel32.dll. This function call may be identified by the calls through either the 0x15FF or 0xE8 opcodes, with a\r\nsubsequent JMP instruction (0x25FF). If such a function is identified it is replaced with the JMP instruction\r\n(0xE9) which leads to instruction 1 in the previous diagram. Then the address of the replaced function from\r\nkernel32.dll is placed into the EBX register. If only the entry point has been modified, the value at [ESP + 24] is\r\nplaced into the EBX register – this is the address for the application to return to kernel32.dll. Later on, the value\r\nstored in this register will be used to obtain the addresses of exported DLL functions. If the EPO technique is\r\nused, the value at [ESP + 20] will contain the address of the instruction following the call of the patched API-function; otherwise it will contain the address of the original entry point.\r\nIf obfuscation is excluded, the simplest way to restore the entry point and/or function will appear as follows\r\n(assume the GetModuleHandleA function was replaced):\r\nCALL $ + 5\r\nPUSHAD\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 11 of 18\n\nMOV EBX, [GetModuleHandleA]\r\nXOR [ESP + 20h], Key\r\nThis code is completely in line with the general logic of the entire block. Now, let us see how all of these stages\r\nhave changed over time. The only stage we will not dwell on is the second operation (save the original contents of\r\nthe registers) as it is always implemented by the PUSHAD instruction.\r\nLet us review each of the block’s logical elements in detail.\r\nThe first stage – the CALL instruction – has not changed much over time. Originally, it looked like CALL $ + 5,\r\nlater CALL $ + 6(7,8), then CALL $ + 0xFFFFFFFx, which is a call ‘backwards’ . It may seem that this operation\r\nis of little importance and can be scrapped, but that is not true. This address is used to restore the entry\r\npoint/original function as well as to address the decryption keys and the start of the static code. We will mention\r\nthis address again when we discuss the Main decryptor.\r\nStage 3 is modified more often than stage 1 and may be implemented in several ways:\r\nMOV EBX, [ApiFunc]/MOV EBX, [ESP + 24h];\r\nPUSH [ApiFunc]/[ESP + 24h]; POP EBX;\r\nSUB ESP, xxh; PUSH [ESP + 24h + xx]; POP EBX;\r\nLEA EBX, [ESP + xxh]; MOV EBX, [EBX + 24h – xx];\r\nADD ESP, 28h; XCHG [ESP – 4], EBX;\r\nThis list of examples is by no means exhaustive, but gives a general understanding of how this stage evolved with\r\ntime. Additionally, intermediate manipulations of the ESP and EBX registers occur.\r\nLet us review the last stage, which restores the address of the original entry point or the patched CALL instruction.\r\nThis stage is modified every two or three weeks.\r\nAfter the PUSHAD instruction is called, the ESP register – the indicator to the stack – will be decremented by\r\n0x20 and so ESP + 20h will store a value supplied by the last CALL instruction. An arithmetic/logical operation is\r\napplied to this value and the required figure is obtained.\r\nBelow are some of the possible sequences of operation that perform the actions described above:\r\nXOR/AND/OR/ADD/SUB [ESP + 20h], const;\r\nMOV [ESP + 20h], const;\r\nLEA EBP, [ESP + x]; MOV/OR/ADD/SUB/XOR EBP, const; XCHG [EBX + 20h – x], EBP;\r\nMOV EBX, ESP; PUSH const; POP [EBX + 20h];\r\nPUSH const; POP [ESP + 20h].\r\nAgain, this list is not exhaustive, but gives an understanding of the overall trend. Various intermediate operations\r\nare added.\r\nThe screenshot below presents a fragment of an infected file which contains all of the operations described above\r\nhighlighted in red ovals.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 12 of 18\n\nScreenshot of a file infected with Virus.Win32.Virut.ce,\r\ncontaining a code to restore the original entry point\r\nFor clarity, the above code examples did not include obfuscation. However, obfuscation is used extensively in all\r\nof the file sections added by the virus, including the Init decryptor and the entire executable part of the main body.\r\nIt is obfuscation that completely blocks static signatures from detecting the virus as it radically modifies the\r\nappearance of the code without changing its performance. Below are some examples of junk instructions which do\r\nnot perform any meaningful operations and are only used to obfuscate the code:\r\nXCHG reg1, reg2; XCHG reg2, reg1; (used together)\r\nSUB reg1, reg2; ADD reg1, reg2; (used together)\r\nMOV reg, reg; OR reg, reg; AND reg, reg; XCHG reg, reg; LEA reg, [REG];\r\nCLD, CLC, STC, CMC, etc.\r\n‘reg1’ and ‘reg2’ stand for different registers; ‘reg’ stands for the same register within a single expression\r\nArithmetic/logical operations with an arbitrary second operand:\r\nADC reg, const; SBB reg, const; XOR reg, const; etc.\r\nIn the screenshots below, elements of obfuscation are highlighted in red ovals:\r\nScreenshots containing code of the virus’ main body with obfuscation elements shown in ovals\r\nThe screenshot on the left shows very clearly that junk instructions make up some 70-80% of the entire code.\r\nThe examples above present some cases of obfuscation that occur most often and are not exhaustive. As the virus\r\nevolves, new obfuscation techniques evolve alongside it.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 13 of 18\n\nWe have reviewed the first stage of execution of the virus’ main body. We will not dwell on the stages that\r\nimplement various anti-emulation and anti-debugging techniques and move straight on to the Main decryptor.\r\nDecrypting the main body\r\nThe execution of the decryption code starts after the virus completes its initial activities such as restoring the\r\npatched code, creating a specifically named object and obtaining the addresses of the functions to be used from\r\nsystem DLLs and anti-cycles.\r\nIf the Main decryptor is viewed in a disassembler, its code will appear utterly meaningless, as the RETN\r\ninstruction is called which hands over control to a randomly chosen position. Before the main decryption process\r\nstarts, the RETN instruction (0C3h) is replaced with CALL (0E8h). This is accomplished by an instruction which\r\nmay typically look like this:\r\nADD/SUB/XOR [EBP + xx], bytereg\r\nIn the above, EBP points to the address of the instruction following CALL and bytereg is one of the byte registers.\r\nWe can therefore consider that the decryption cycle starts after RETN is changed to CALL. Next follows the\r\ndecryption cycle which is just as obfuscated as the rest of the virus’ body is. Not only are a large number of\r\nalgorithms used, but many of them are more complex than those used within the Init decryptor. Typically, between\r\ntwo to six logical/arithmetic operations are used in combination. In algorithms, the EDX register contains the\r\ndecryption key and the EAX register contains the virtual address where the static body starts. The registers contain\r\ninstructions which may look like this:\r\nMOVZX/MOV dx/edx, [ebp + const]\r\nLEA eax, [ebp + const]\r\nThe EBP register contains the address which follows the CALL instruction; this address was mentioned earlier\r\nwhen we reviewed the first stage of the logical scheme which restores the original part of the file. The instructions\r\nperforming these two operations have also been modified with time, but we will not discuss them here.\r\nThe algorithms in use are very diverse so we will only provide examples of the most interesting ones:\r\nROL DX, 4\r\nXOR [EAX], DL\r\nIMUL EDX, EDX, 13h\r\nADD [EAX], DL\r\nROL DX, 5\r\nIMUL EDX, 13h\r\nXOR [EAX], DH\r\nADD [EAX], DL\r\nXCHG DH, DL\r\nIMUL EDX, 1Fh\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 14 of 18\n\nXOR [EAX], DH\r\nXCHG DH, DL\r\nADD [EAX], DH\r\nIMUL EDX, 1Fh\r\nXOR [EAX], DL\r\nADD [EAX], DH\r\nIMUL EDX, 2Bh\r\nXCHG DH, DL\r\nThe instructions used changed from version to version, but no clear trend can be observed: relatively simple\r\nalgorithms were replaced by more complex ones, which in turn were replaced by simpler ones again. It appears\r\nthat the virus creator’s ultimate goal was to use an algorithm that could better resist possible brute force attempts.\r\nThis may well account for the continuous changes to the algorithms, as well as the irrationality of those changes.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 15 of 18\n\nA disassembled fragment of the Main decryptor\r\nThe screenshot above contains a fragment of the Main decryptor’s disassembled code. The meaningful (non-junk)\r\ninstructions discussed above are highlighted in red ovals. Some junk operations are also present here for\r\nobfuscation purposes.\r\nTo continue the discussion regarding the execution of the infected file, let us move on to the execution of the\r\nmalicious payload contained within the decrypted static body. It typically starts with a CALL instruction to a\r\nnearby cell in order to calculate the virtual address of the beginning of the executable code and use it later on for\r\naddressing.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 16 of 18\n\nThe virus’ decrypted static body\r\nThe screenshot above shows the virus’ decrypted static body. The lines highlighted by the red ovals carry specific\r\nparts of the malicious payload. For example, ‘JOIN’ and ‘NICK’ are IRC commands, ‘irc.zief.pl’ and\r\n‘proxim.ircgalaxy.pl’ are remote IRC servers that Virut attempts to contact; ‘SYSTEMCurrentControlSet\r\nServicesSharedAccess ParametersFirewallPolicy StandardProfileAuthorizedApplications List’ is the registry key\r\ncontaining the list of trustworthy programs for the Windows firewall.\r\nConclusion\r\nVirut.ce is interesting for the variety of file infection mechanisms that it uses, as well as its polymorphism and\r\nobfuscation techniques. However, its malicious payload is quite commonplace. This version of Virut was the first\r\nto combine all of the aforementioned malicious techniques into a single piece of malware. Some malicious\r\nprograms may be heavily obfuscated, others may employ a wide range of anti-emulation techniques, but Virut.ce\r\ncombines all of these in one package. This article provides a detailed account of these malicious techniques.\r\nThe article is not an attempt at a complete description of Virut.ce, nor is it intended to be. We could have gone\r\ndeeper into how the virus communicates with the IRC server, or examined more closely the details of how files\r\nare infected, but this time we deliberately dwelt on Virut’s basic mechanisms. Additionally, publishing a detailed\r\ndescription of the anti-emulation techniques would be irresponsible as malware writers could then exploit this\r\ninformation.\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 17 of 18\n\nAssessing the virus’ future is quite a difficult task. As of April-May 2010, no new versions of Virut.ce have been\r\ndetected; however, this does not mean that its evolution has stopped. It is quite possible that the virus writers have\r\ntaken a break in order to develop further changes to the virus that could render it immune to current antivirus\r\nproducts.\r\nCurrently, all of Kaspersky Lab’s products are able to successfully detect and treat Virus.Win32.Virut.ce and as\r\nsoon as a new variant is detected, its signature will be added to the Kaspersky Lab antivirus databases.\r\nWe hope that this article will be of assistance to virus analysts and those interested in the study of malware. These\r\ndays, anti-emulation and anti-debugging techniques are commonly used in most malicious programs that\r\npropagate by means of server-side polymorphism. An awareness of the technologies implemented in Virus.ce\r\nhelps to broaden our understanding of many other malicious programs, including polymorphic viruses employing\r\nsimilar methodologies.\r\nSource: https://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nhttps://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/"
	],
	"report_names": [
		"36305"
	],
	"threat_actors": [
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434224,
	"ts_updated_at": 1775792173,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6f40c9e8127244f9d77a2d25df60c43af42fbdb0.pdf",
		"text": "https://archive.orkl.eu/6f40c9e8127244f9d77a2d25df60c43af42fbdb0.txt",
		"img": "https://archive.orkl.eu/6f40c9e8127244f9d77a2d25df60c43af42fbdb0.jpg"
	}
}