{
	"id": "9de4647e-fd10-4a51-81eb-156cdb847cb7",
	"created_at": "2026-04-10T03:20:52.430653Z",
	"updated_at": "2026-04-10T13:12:27.46014Z",
	"deleted_at": null,
	"sha1_hash": "6c741ed4f9c576ca15732de041381ccf1705dc93",
	"title": "Incident Response: Analysis of recent version of BRC4",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1333115,
	"plain_text": "Incident Response: Analysis of recent version of BRC4\r\nPublished: 2024-10-22 · Archived: 2026-04-10 02:57:59 UTC\r\nIntroduction\r\nDuring our latest incident response case we have discovered a recent sample of Brute Ratel C4 packed with\r\nThemida. BRC4 is a powerful Command and Control (C2) tool which allows to control targeted workstations\r\nthrough an executable agent. The objective of Themida is to protect code against reverse engineering.\r\nCurrently, C2 tools are used by attackers as much as pentesters. So, it’s always interesting to analyse and to fully\r\nunderstand them in order to find a way to detect them effectively and enrich the threat hunting phase.\r\nThis sample is a DLL from an archive that has been brought to the targeted machine. It was executed with the\r\ncommand line present into the following event:\r\nThe difficulties behind this sample were:\r\n• Unpack Themida\r\n• Defeat obfuscations and anti-debug techniques\r\n• Understand the different stages to reach configuration and data sent\r\nHere you’ll find a short explanation of the different stages:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 1 of 15\n\nThis article solely focuses on obfuscation techniques, configuration extraction and how data are encrypted before\r\nthey are sent to the server.\r\nTo briefly summarize, to pass the first stage, we used ScyllaHide plug-in on xDBG and we jumped in a specific\r\narea with read/execution rights at the time the DLL was loaded. In this area, we found symbols that allowed us to\r\nfind the loader of BRC4.\r\nThe second stage is just a loader of shellcode where ZwAllocateVirtualMemory, ZwProtectVirtualMemory,\r\nZwCreateThreadEx and NtWaitForSingleObject functions are used for self-injection. We save the shellcode\r\nwith system informer to get a new starting point for the analysis.\r\nThe third stage focuses on the first part of the shellcode with obfuscations and anti-debug techniques. It introduces\r\nthe last stage by self-injection with NtQueueApcThread.\r\nThe last stage is the most interesting part of the shellcode because it focuses on configuration and communication.\r\nIn the following article, I will use a first part to describe what obfuscation techniques were used in stages 2, 3 and\r\n4 and unpacking process of Themida. I will then describe how stage 4 retrieves the configuration, uses it to cypher\r\noutgoing data, and how we can automate retrieval of this configuration.\r\nUnpack of Themida\r\nFor the unpacking part we used ScyllaHide plug-in on x64DBG with Themida x86/x64 profile.\r\nWe found two different results for two types of execution: normal execution on the left and\r\nexecution with ScyllaHide on the right:\r\nName Win.dll\r\nSHA-256 4400750cbc597b7e0cec813dcaf66d00e83955a034591a5a6ba40547a045721b\r\nFile type PE64\r\nPacker Themida 3.x\r\nFor the unpacking part we used ScyllaHide plug-in on x64DBG with Themida x86/x64 profile.\r\nWe found two different results for two types of execution: normal execution on the left and execution with\r\nScyllaHide on the right:\r\nAfter the execution with ScyllaHide plugin, we found a memory area with execution right and we jumped on it:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 2 of 15\n\nDuring the analysis of this memory area, we finally found a main function, this function is our second stage:\r\nObfuscation \u0026 Anti-debug\r\nDuring our analysis we found obfuscations based on scraping, PEB parsing and API hashing on stage 2, 3 and 4.\r\nHere, a part of code of stage 3:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 3 of 15\n\nWe can find multiple functions, their role is:\r\nIntroducing anti-debug techniques\r\nLoad modules with PEB Parsing\r\nLoad pointers of functions with PEB parsing and API hashing\r\nBuild syscall routine\r\nResolve syscall ID with scraping\r\nAnti-debug\r\nAn anti-debug technique involving PEB parsing is used to compare the value at PEB+0xbc with 0x70. This code\r\nis encountered two times in the stage 3, it’s not evident to spot it, so we must analyse the code step by step.\r\nLoad modules with PEB Parsing\r\nThe pointer to the base address of each module is found with PEB parsing. In this case the program makes a loop\r\nin the _PEB_LDR_DATA structure to scrape these bytes: 0x5A4D. This technique is used to avoid calling direct\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 4 of 15\n\nfunctions such as LoadLibraryA which allows to load DLL.\r\nLoad pointers of functions with PEB parsing and API hashing\r\nTo resolve the pointers of the functions, the program parses the PEB structure and then makes a loop in the name\r\npointer table in IMAGE_EXPORT_DIRECTORY structure. A call on the hashing function is operated for each\r\nname in the table to find the correct function for the requested hash. Once the correct function is found, its pointer\r\nis obtained using the address table. You’ll find an article describing the process in a more detailed way here.\r\nBuild syscall routine\r\nTo be stealthier than its previous version, the program builds its own function to make a syscall. In an older\r\nversion, there were obfuscation techniques for the loading function and ID resolution, but at the end there was a\r\ndirect syscall advising us for an incoming self-injection.\r\nIn the capture below, the program builds a pointer to a custom code section to execute a syscall.\r\nResolve syscall ID with scraping\r\nThe code doesn’t use a direct syscall ID to be able to target enough workstations regardless of their version. The\r\nID of a syscall depends on the version and build number of the Operating System: with this technique, it’s not\r\nnecessary to obtain the OS version of the targeted workstations. All ID are presented on j00ru website. On the\r\nscreen below, we can see the specific section which resolved a syscall ID. The code scrapes a specific sequence of\r\nbytes to find out the correct position of the ID. This process depends on the function previously loaded with PEB\r\nparsing \u0026 API hashing:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 5 of 15\n\nFor a better understanding, on the screen above we have the function used to find syscall ID thanks to bytes\r\nsequence on the left. On the right, we have the code of NtAllocateVirtualMemory which allows us to understand\r\nwhy these following bytes are targeted: 0x4C, 0x8B, 0xD1 and 0xB8. The bytes 0x4C, 0x8B and 0xD1 are\r\nrespectively:\r\nMOV R10, RCX\r\nThe byte just after 0xB8 is the syscall ID, in normal execution this value is moved into EAX like that:\r\nMOV EAX, [SYSCALL ID]\r\nTo resume this part, the malware uses these techniques to be stealthier that allows it to evade detection against\r\nsecurity software.\r\nThese techniques allow to the malware to:\r\nHide functions into Import Address Table (IAT) to evade detection\r\nCounter dynamic analysis by stopping the program\r\nCounter userland detection by IAT hooking by using direct syscall\r\nLast stage\r\nThe last stage focuses on configuration extraction and encryption of data before they are sent to the C2 server. In\r\naddition, we can find obfuscation functions which loads DLL and function with symbols to communicate with C2\r\nserver. In our case, the BRC4 shellcode uses ws2_32.dll library, the HttpSendRequest function to send data and\r\nthe InternetReadFile function to read\r\ndata.\r\nDuring this stage, we can retrieve all BRC4 principal functions using the NOP value (0x90), because each\r\nfunction is separated from the other by NOP instructions. The number of NOP depends on the size of the\r\nfunctions, since the purpose of the NOP instructions is to correctly align the stack.\r\nBefore continuing, here a diagram explaining the process between the configuration and the encryption of data:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 6 of 15\n\nConfiguration extraction\r\nLike its previous version, the configuration is encrypted in RC4. The key and the encrypted configuration are\r\nfound at this precise moment during the last stage:\r\nShortly afterward, we can retrieve the configuration in clear text. Because it takes a lot of time to reverse all the\r\ncode until this moment, we prepared a configuration extractor based on specific patterns in the program’s memory.\r\nThe conditions to fulfil to be able to use our extractor program are:\r\nGet the BRC4 shellcode in the loader stage (real first stage, because Themida packer is an added stage by\r\nour adversary in this instance).\r\nGet this shellcode loader here for our configuration extraction process.\r\nGet the configuration extractor on Airbus Protect GitHub.\r\nThe configuration extractor is a python program which uses the Ctypes library to execute our shellcode through a\r\nloader. The handle of the new process is used to obtain memory areas with VirtualQueryEx. Here, we focus on\r\nmemory areas with these specific conditions:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 7 of 15\n\nif mbi.State == MEM_COMMIT and (\r\n mbi.Protect == PAGE_READWRITE or\r\n mbi.Protect == PAGE_READONLY ):\r\nEach matched memory area is saved in the same dump file. At the end of this function, the dump is used to extract\r\nthe key and the configuration by using these regexes:\r\nregex_sequences_forKey = [\r\n r\"(00){16}([1-9A-Fa-f]{1}[0-9A-Fa-f]{1}){8}([0-9A-Faf]{2}){8}(00){8}(..0001......)(00..)\",\r\n r\"(00){16}([1-9A-Fa-f]{1}[0-9A-Fa-f]{1}){8}([0-9A-Fa-f]{2}){8}(00){8}([0-9A-Faf]{2}){6}(0001)\",\r\n r\"(00){16}([1-9A-Fa-f]{1}[0-9A-Fa-f]{1}){8}([0-9A-Fa-f]{2}){8}(00){8}([0-9A-Faf]{2}){6}(0010)\"\r\n ]\r\nregex_sequences_forConfig = r\"(4883e4f04831c0505468)\"\r\nWe performed some tests on samples discovered on Virus Total with Yara rules created for this specific version of\r\nBRC4. These Yara rules are available in the Yara section of this article. Here, the results of our extractor on five\r\nsamples (each test is operated on the shellcode extracted from a DLL file):\r\nCase sample – 4400750cbc597b7e0cec813dcaf66d00e83955a034591a5a6ba40547a045721b\r\nsample 1 – 780b2b715aa33e8910479a671469ad27cc88a7ed513b83e43cf7a6a16f613013\r\nsample 2 – 04b47b5492f5b2086e4a6b3f2bef73eb15a51140a86bcd05417d00bf6875ffb6\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 8 of 15\n\nsample 3 – 9ec67f1914603e729a3b6bafe3a96cdc660717ca7dfb457290f68fc56dd0a5e2\r\nsample 4 – bd32cbb6c08eff7fc6aa0bfe2fd81ec467f70d9b726015859da39744271bbcb0\r\nEncryption of data\r\nBefore sending data to the C2 server, the program uses RC4 to encrypt them. The first request is just a simple\r\nJSON containing data about the victim, like a profile. The first request before encryption looks like this:\r\n{\r\n \"cds\": {\r\n\"auth\":\"[C2_PASSWORD]\"\r\n },\r\n \"mtdt\": {\r\n \"h_name\":\"[VICTIM_MACHINE_NAME]\",\r\n \"wver\":\"x64/100\",\r\n \"ip\":\"[VICTIM_MACHINE_IP], 0.0.0.0, 0.0.0.0\",\r\n \"arch\":\"x64\",\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 9 of 15\n\n\"bld\":\"17763\",\r\n \"p_name\":\"[PATH_OF_EXECUTABLE_IN_BASE64]\",\r\n \"uid\":\"[VICTIM_USERNAME]\",\r\n \"pid\":\"6992\",\r\n \"tid\":\"5448\"\r\n }\r\n}\r\nExplanation of data fields:\r\nC2_PASSWORD: password for C2 authentication\r\nVICTIME_MACHINE_NAME: the name of the victim machine\r\nVICTIME_MACHINE_IP: the IP address of the victim machine\r\nPATH_OF_EXECUTABLE_IN_BASE64: the path to the base64-encoded executable\r\nVICTIM_USERNAME: the session username of the victim machine\r\nRC4 encryption is operated by SystemFunction033 from cryptsp.dll:\r\nThis function is an alias of SystemFunction032 because both point to the same relative address:\r\nBased on ReactOS documentation, this function operates an RC4 encryption routine:\r\nNTSTATUS\r\nWINAPI SystemFunction032(struct ustring *data, const struct ustring *key)\r\n{\r\n RC4_CONTEXT a4i;\r\n rc4_init(\u0026a4i, key-\u003eBuffer, key-\u003eLength);\r\n rc4_crypt(\u0026a4i, data-\u003eBuffer, data-\u003eLength);\r\n return STATUS_SUCCESS;\r\n}\r\nTo remind you, here the decrypted configuration for our case:\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 10 of 15\n\n[+] Config txt -\u003e\r\n||2|1|0|100|||||||eyJjb29raWUiOiI=|In0=|eyJibG9iIjoi|In0=|eyJIVFRQIjoiU1VDQ0VTUyJ9|1|1|\r\n206.166.251.128|8081|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36\r\n(KHTML, like Gecko) Chrome/90.0.4430.93\r\nSafari/537.36|password|MJSBLHLU6B8VG7JP|/test.asp|Y29udGVudC10eXBlOiBhcHBsaWNhdGlvbi9vY\r\n3RldA==,cmVmZXJyZXI6IGdvb2dsZS5jb20=|d0cf9d2be1473579e729382f5c2e22c6453a93478a733b2f28\r\nf86078cec0889b\r\nIn this table you will find the elements that interest us and that will allow us to understand in a little more detail\r\nhow the data will be processed:\r\nC2 IP 206.166.251[.]128\r\nC2 PORT 8081\r\nHEADER PARAMETER 1 (user-agent)\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64)\r\nAppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/90.0.4430.93 Safari/537.36\r\nHEADER PARAMETER 2 (content-type)\r\ncontent-type: application/octet\r\n(Y29udGVudC10eXBlOiBhcHBsaWNhdGlvbi9vY3RldA==)\r\nHEADER PARAMETER 3 (referrer)\r\nreferrer: google.com\r\n(cmVmZXJyZXI6IGdvb2dsZS5jb20=)\r\nPASSWORD FOR AUTHENTICATION password\r\nPASSWORD TO ENCRYPT DATA TO\r\nSEND\r\nMJSBLHLU6B8VG7JP\r\nPAGE TO COMMUNICATE /test.asp\r\nIn this context, we know that the first request will be send to http[:]//206.166.251[.]128:8081/test.asp with the\r\nheader parameters provided in the table above. Before sending to the C2 server, the program will encrypt the data\r\nwith the password\r\n(MJSBLHLU6B8VG7JP) in the table and it will make this request with encrypted data:\r\nConclusion\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 11 of 15\n\nOur in-depth analysis of Brute Ratel allows us to highlight the complexity behind all techniques seen in this\r\narticle.\r\nWe explored various obfuscation techniques that complicate analysis for experts and detection by security\r\nsoftware. We also covered the importance of configuration, a key element of the program. This not only enables\r\nthe retrieval of agent configuration data, including the IP address and port of the command and control (C2)\r\nserver, but also the passwords used for authentication and encryption of data to be communicated to the server.\r\nFinally, we’ve set up a configuration extractor that allows us to quickly retrieve the agent’s key elements.\r\nYear after year, malware grows in complexity, and we must continue our research to help the community to detect\r\neffectively. We hope that the findings and tools presented in our research will help you.\r\nDetection\r\nYara\r\nimport \"pe\"\r\nrule stage_Loader {\r\n meta:\r\n author = \"Adams KONE\"\r\n company = \"Airbus PROTECT\"\r\n sharing = \"TLP:CLEAR\"\r\n category = \"MALWARE\"\r\n description = \"Loader’s stage\"\r\n \r\n strings:\r\n //Obfuscation technique\r\n //API hashing function\r\n $HashingFunction = {\r\n 31 D2 0F BE 01 84 C0 74 14 01 D0 48 FF C1 69 C0\r\n 01 04 00 00 89 C2 C1 EA 06 31 C2 EB E5 8D 04 D2\r\n 89 C2 C1 EA 0B 31 D0 69 C0 01 80 00 00 C3\r\n }\r\n //Obfuscation technique\r\n //Function to resolve syscall ID\r\n $getIdForSyscall = {\r\n 80 79 FF CC 74 58 45 85 C0 75 04 48 83 E9 20 44\r\n 8A 09 41 80 F9 E9 74 0A 44 8A 41 03 41 80 F8 E9\r\n 75 07 FF C2 45 31 C0 EB D7 31 C0 41 80 F9 4C 75\r\n 2F 80 79 01 8B 75 29 80 79 02 D1 75 21 41 80 F8\r\n B8 75 1B 80 79 06 00 75 17 0F B6 41 05 C1 E0 08\r\n 41 89 C0 0F B6 41 04 44 09 C0 01 D0 EB 02 31 C0\r\n C3\r\n }\r\n //Obfuscation technique\r\n //Function to forge a pointer to syscall, ret instructions.\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 12 of 15\n\n$getAddrToJumpToSyscallAndRetInstruction = {\r\n 48 89 C8 48 8D 51 14 80 38 0F 75 0C 80 78 01 05\r\n 75 06 80 78 02 C3 74 0A 48 FF C0 48 39 C2 75 E7\r\n 31 C0 C3\r\n }\r\n //Obfuscation technique\r\n //Hash of functions\r\n $ZwProtectVirtualMemory = { E0 0E BB 82 }\r\n $ZwAllocateVirtualMemory = { BF 06 3A E3 }\r\n $NtWaitForSingleObject = { 26 6E C2 E2 }\r\n $NtCreateThreadEx = { AA 5D F1 E5 }\r\n condition:\r\n (uint16(0) == 0x5a4d and uint16(uint16(0x3c)) == 0x4550) and all of them\r\n}\r\nrule Stage_BRC4_Part1 {\r\n meta:\r\n author = \"Adams KONE\"\r\n company = \"Airbus PROTECT\"\r\n sharing = \"TLP:CLEAR\"\r\n category = \"MALWARE\"\r\n description = \"First part of the shellcode’s stage\"\r\n \r\n strings:\r\n //Obfuscation technique\r\n //API hashing function\r\n $HashingFunction = {\r\n 0F BE 01 84 C0 74 39 31 D2 0F 1F 80 00 00 00 00\r\n 01 D0 48 83 C1 01 89 C2 C1 E2 0A 01 D0 89 C2 C1\r\n EA 06 31 C2 0F BE 01 84 C0 75 E5 8D 14 D2 89 D0\r\n C1 E8 0B 31 D0 89 C2 C1 E2 0F 01 D0 C3 0F 1F 00\r\n 31 C0 C3\r\n }\r\n //Obfuscation technique\r\n //Operation to check if the program is running in a debugger\r\n $AntiDebugViaPEBParsing = {\r\n 65 48 8B 14 25 60 00 00\r\n 00 0F B6 82 BC 00 00 00\r\n 83 E0 70 3C 70\r\n }\r\n condition:\r\n all of them\r\n}\r\nrule Stage_BRC4_Part2 {\r\n meta:\r\n author = \"Adams KONE, Airbus PROTECT\"\r\n company = \"Airbus PROTECT\"\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 13 of 15\n\nsharing = \"TLP:CLEAR\"\r\n category = \"MALWARE\"\r\n description = \"Stage of second part of shellcode\"\r\n \r\n strings:\r\n //Obfuscation technique\r\n //API hashing function\r\n $HashingFunction = {\r\n 31 D2 0F BE 01 84 C0 74 14 01 D0 48 FF C1 69 C0\r\n 01 04 00 00 89 C2 C1 EA 06 31 C2 EB E5 8D 04 D2\r\n 89 C2 C1 EA 0B 31 D0 69 C0 01 80 00 00 C3\r\n }\r\n//Obfuscation technique\r\n //Function to forge a pointer to syscall, ret instructions.\r\n $getAddrToJumpToSyscallAndRetInstruction = {\r\n 48 89 C8 48 8D 51 14 80 38 0F 75 0C 80 78 01 05\r\n 75 06 80 78 02 C3 74 0A 48 FF C0 48 39 C2 75 E7\r\n 31 C0 C3\r\n }\r\n //Obfuscation technique\r\n //Hash of functions\r\n $InternetOpenW = { 2E 8F 43 C1 }\r\n $InternetConnectW = { E8 60 1F 7F }\r\n $InternetCloseHandle = { 43 30 5C 03 }\r\n $HttpOpenRequestW = { A9 2D 8A 74 }\r\n $InternetSetOptionW = { 25 04 40 7A }\r\n $HttpAddRequestHeadersW = { 35 25 AF A5 }\r\n $HttpSendRequestW = { 80 7B 17 E8 }\r\n $HttpSendRequestA = { 3A 79 F2 E6 }\r\n $HttpQueryInfoA = { 27 AF D2 5D }\r\n $InternetReadFile = { 46 CE FE BC }\r\n $InternetQueryDataAvailable = { AE D7 26 30 }\r\n \r\n condition:\r\n all of them\r\n}\r\nIOCs\r\n4400750cbc597b7e0cec813dcaf66d00e83955a034591a5a6ba40547a045721b\r\nbd32cbb6c08eff7fc6aa0bfe2fd81ec467f70d9b726015859da39744271bbcb0\r\n780b2b715aa33e8910479a671469ad27cc88a7ed513b83e43cf7a6a16f613013\r\n206.166.251[.]128\r\n179.43.144[.]250\r\n213.215.163[.]51\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 14 of 15\n\nSource: https://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nhttps://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.protect.airbus.com/blog/incident-response-analysis-of-recent-version-of-brc4/"
	],
	"report_names": [
		"incident-response-analysis-of-recent-version-of-brc4"
	],
	"threat_actors": [],
	"ts_created_at": 1775791252,
	"ts_updated_at": 1775826747,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6c741ed4f9c576ca15732de041381ccf1705dc93.pdf",
		"text": "https://archive.orkl.eu/6c741ed4f9c576ca15732de041381ccf1705dc93.txt",
		"img": "https://archive.orkl.eu/6c741ed4f9c576ca15732de041381ccf1705dc93.jpg"
	}
}