{ "id": "399e7079-d0ff-40dd-87a1-96a9c84bee82", "created_at": "2026-04-06T00:17:35.800718Z", "updated_at": "2026-04-10T03:37:16.908919Z", "deleted_at": null, "sha1_hash": "ee504d606a87973d55e4b904d8a10e16c2277212", "title": "Analyzing a Brute Ratel Badger", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2375784, "plain_text": "Analyzing a Brute Ratel Badger\r\nPublished: 2022-07-09 · Archived: 2026-04-06 00:03:34 UTC\r\nNow a days Brute Ratel (sometimes called the “Angry Monkey C2”) seems to be a hot topic within the\r\ninformation security community. There’s been lots of drama surrounding the author (ParanoidNinja), rumors of\r\nthe C2 being backdoored, and even some blog posts from well known and respected individuals within the\r\nsecurity community indicating that the C2 framework is potentially being used by APT29 (aka the Russian State\r\nSponsored groups).\r\nSo, with all these controversies, where do we go from here? Well, validating the claim that the C2 Framework is\r\nbackdoored can be quite difficult to prove as that would involve me spending several thousand dollars to acquire\r\nthe framework itself… So, that’s not exaclty feasable. I can however get the next best thing. A Brute Ratel\r\nBeacon, or Agent (or as they like to call it, a “Badger”).\r\nAcquiring a Badger for Analysis\r\nHow can we do this exactly? Fortunately, I have a VirusTotal Enterprise license! This means we can pull down\r\n(download) a publicly tagged “Brute Ratel” sample from the community. To do so, we’re going to use a search for\r\nsomething like Comment:\"Brute Ratel\" and see if we get any hits…\r\nSuprise Suprise, we got six hits! Let’s go with the most obvious one, badger_x64.exe (SHA256 Sum:\r\n3ad53495851bafc48caf6d2227a434ca2e0bef9ab3bd40abfe4ea8f318d37bbe).\r\nLab Setup\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 1 of 14\n\nFor this lab, we will be using REMWorkstation + REMnux. Here’s a diagram that breaks down the lab setup:\r\nREMWorkstation has the IP Address of 192.168.128.12\r\nREMNux has the IP Address of 192.168.128.10\r\nDefault Gateway has the IP Address of 192.168.128.2\r\nREMNUx can route to 192.168.128.2, but the route is not configured.\r\nIf REMNux is configured to route to the Default Gateway, outbound traffic to the internet is allowed\r\nIn addition:\r\nREMNux will have an iptables rule that will accept all and any traffic going into it.\r\nREMNux will be running FakeDNS and iNetSim\r\nREMNux will be running WireShark\r\nREMWorkstation will be running Fiddler\r\nAnd thats our lab!\r\nDynamic Analysis - Malware Detonation\r\nNow that we have our sample acquired, and you’re familiar with my lab setup, let’s double click some EXEs!\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 2 of 14\n\nSo, right off the bat, we can see some beacons to 156.65.186.50 over HTTPS. Looking at these requests in Fiddler,\r\nwe can see that the sample is using the user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)\r\nAppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 with no extra headers.\r\nThis is suprisingly bare. Let’s pivot over to iNetSim and see whats going on over there.\r\nOn that side, we can see a little bit more. The file that the “Badger” requested is /admin , and there is also some\r\nPOST data that we missed!\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 3 of 14\n\nLet’s see if we can find that in Fiddler… Unfortunately, I could not find the request in Fiddler, I’ll have to revert\r\nand redetonate the sample in a bit…\r\nEdit: Fiddler actually caused some issues w/ cutting the POST data off to inetsim :(.\r\nProcmon/ProcDot Analysis\r\nFor now - Let’s move over to ProcMon and ProcDot and see what the badger is looking for.\r\nStarting out, this is an absolutely massive graph. Let’s start from the top and work our way down.\r\nAt the top:\r\nIt appears that the badger is first checking to see if there are any registry keys correlated to a proxy on the system.\r\nSince no proxies are in place, BRC4 likely foudn nothing.\r\nOn the far right, we can see a couple of cached web page responses saved to disk. If you’d like to read that data -\r\nall it contains is the iNetSim HTTP Response.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 4 of 14\n\nMoving on down the graph, we can see another read attempt on another registry key relating to proxies:\r\nOne interesting thing I’d like to point out is the Badger is leveraging a bunch of ThreadCreates and ThreadOpens\r\nto potentially confuse AV or EDR.\r\nZooming out, all the black diamons are all new threads and Thread ID Numbers.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 5 of 14\n\nScrolling down a bit more, this pattern continues. More Threads being created to read registry keys relating to\r\nproxies:\r\nBack to iNetSim\r\nNow that we know a bit more about what the program is trying to do, let’s go back to iNetSim and read the POST\r\ndata from the Web Server.\r\nAll of the POST data is stored in /var/lib/inetsim/postdata/* . I hope that helps someone in the future… :)\r\nLet’s bring the input into CyberChef and decode the Base64.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 6 of 14\n\nSearching for Encryption in APIMonitor\r\nInteresting! The POST Data is encrypted. I think I know a trick or two that could help us decode this. To do so,\r\nwe’ll need to hop into API Monitor and hook into the process and observe the API Calls the badger is performing.\r\nWe’re looking for a call to Microsoft’s Cryptographic API or a call to the HTTP APIs as we know some\r\ncryptographic function performs before the POST data is sent…\r\nBy searching for a common Windows API (RtlUTF8ToUnicodeN), we can quickly find where some data\r\nconversion is taking place to give us a good starting point of reference.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 7 of 14\n\nLooking at the CallStack, we see some lovely Windows API calls that look very close to what we need. Since\r\nsome sort of technique is being used to dynamically resolved the APIs needed is being used, let’s back off of\r\nAPIMonitor and move over to a Debugger.\r\nPivoting to x64Dbg\r\nI have setup x64Dbg to use counter-antidebugging techniques using ScyllaHide, so if there are any techniques\r\nimplemented, we won’t have to worry about them.\r\nAfter letting the program run for a while, I set a breakpoint on a couple of the common HTTP APIs. We got a hit\r\non InternetOpenW; in my suprise, in the stack window, here we are. We have the unencrypted data starting at us!\r\nIt appears to be some JSON that looks like so:\r\n\"desktop-2c3Iqh0\",\r\n\"wver\":\"x64/10.0\",\r\n\"arch:\"x64\",\r\n\"bld\":\"16322\",\r\n\"p_name\":\"\u003cbase64 blob\u003e\",\r\n\"uid\":\"REM\",\r\n\"pid\":\"\"\r\n}\r\nThe Base64 glob is still relatively interesting to me, p_name, could this mean program_name? Let’s decode it!\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 8 of 14\n\nIt appears so! I set a BreakPoint earlier in the stack and let the execution flow to see if I could extract any more\r\ninformation from the Badger, doing so did yeild some extra results!\r\nWe have an auth token now and a more complete JSON blob.\r\n{\r\n\"cds\": {\r\n\"auth\":\"2K4TBS7L9GK2C205\"\r\n},\r\n\"mtdt\": {\r\n\"h_name\":\"DESKTOP-2C3IQH0\",\r\n\"wver\":\"x64/10.0\",\r\n\"arch\":\"x64\",\r\n\"bld\":\"16322\",\r\n\"p_name\":\"\u003cbase64 blob\u003e\",\r\n\"uid\":\"REM\",\r\n\"pid\":\"\"\r\n}\r\n}\r\nUnfortunately, our analysis stops here as we don’t have a live C2 server to observe interactions with. Though, we\r\ncould explore how the badger interacts with the C2 server if we carefully observe how the badger parses the\r\nresponse from the C2 server. There is definately some hardcoded commands that we would be able to use to\r\nmanipulate the badger itself with iNetSim.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 9 of 14\n\nI would have liked to have caught the Windows API that actually encodes/encrypts this data, so I could write a\r\nsmall decoder for the information if you have the badger; but it appears that wasn’t meant for tonight :(\r\nBasic Static Analysis\r\nSo, this section is going to be much shorter than the last, as I’ve already found the interesting C2 related data;\r\nNow, we’re going to play an interesting game of “How good is Brute Ratel’s Obfuscation Techniques”! The\r\nanswer isn’t very good.\r\nTo start, we’re going to chuck the EXE into Cyberchef and look at some of the clear text ASCII values.\r\nHTTP Request Information\r\nSo, right off the bat, it’s not looking so good. We can see a lot of interesting strings; we can see a lot of the HTTP\r\nPOST information broken up into various strings. For example:\r\n/logi\r\nAppleWeb\r\nKit/537\r\n65.186.5\r\n159\r\n443\r\nSome of these strings are incredibly meaningful! For example, putting together the bits 159.65.186.50 gives away\r\nour command and control server, and 443 gives away the port! How interesting…\r\nWindows APIs\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 10 of 14\n\nLooking a little bit lower, we can see some of the Windows APIs the program uses as well. They appear to be\r\njumbled up, but still readable to the human eye.\r\nVirtualProtect\r\nGetLastError\r\nGetModuleHandleW\r\nGetProcAddress\r\nThe more you keep looking, the more you see the pattern.\r\nHTTP POST Data\r\nInterestingly enough, you can actually find a lot of the HTTP POST Data that we had to work oh so hard to\r\nreverse engineer to find…\r\narch\r\nbld\r\nfname\r\nh_name\r\nContinuing our search, we may be able to learn more about the badgers capabilities. Looking at the screenshot\r\nabove, towards the bottom, we can make out “Download Failed”. Perhaps this badger has the ability to upload\r\nfiles to the server? Let’s keep digging.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 11 of 14\n\nBadgers like LDAP!\r\nIt looks like the badger uploads PNG/image files to the C2 server. It also makes some queries to LDAP as well\r\nand will communicate with the Global Catalog. If it can’t, it’ll spit out some binding errors.\r\nSearching lower down the list, we can see some of the information it collects, like Password Expiration, if the\r\npassword never expires, and if there is a bad password supplied.\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 12 of 14\n\nThe Badger is Self Aware?\r\nContinuing our string-hunt, here’s one of the most interesting sets of strings… Badger itself is embedded as a\r\nstring in the binary :facepalm:\r\nI’ve already loaded up the binary into Ghidra and there’s a whole lot of nothing. It seems to be a bit beyond my\r\nskill level to reverse engineer in a classic sense, so I’ll have to do some more research on my own time to figure\r\nout if I can post a followup showing off the actual binary internals.\r\nMisc Findings\r\nHere are some interesting things I found that I wanted to include in the post, but couldn’t easily write into the flow\r\nof the post. I still think this is worth mentioning.\r\nPUNYCode! The thing I forgot existed?\r\nHere is an interesting String Compare after executing a HTTP Request; it asppears that this badger is checking to\r\nsee if some of the response headers contain xn-- . This may be a sign that a threat actor is spoofing a common\r\ndomain like Google.com to http://xn--ggle-0nda.xn--om-ubc/ , which displays just like the normal domain\r\ndoes! Browser settings can be configured to always display xn–, though some by default will render the link as\r\nnormal. Thanks to @ShitSecure for pointing this out \u003c3\r\nTraffic Generation to windowsupdate.com\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 13 of 14\n\nAnother interesting aspect of this badger is that it periodically reaches out to ctldl.windowsupdate.com . I\r\noriginally thought this was Windows being Windows, but it turns out that this is hardcoded within the binary. This\r\nis likely a cloaking mechanism to throw off AV/EDR/Sandboxes.\r\nI hope you all enjoyed :) ~Ronnie\r\nSource: https://blog.spookysec.net/analyzing-brc4-badgers/\r\nhttps://blog.spookysec.net/analyzing-brc4-badgers/\r\nPage 14 of 14", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.spookysec.net/analyzing-brc4-badgers/" ], "report_names": [ "analyzing-brc4-badgers" ], "threat_actors": [ { "id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e", "created_at": "2024-06-04T02:03:07.956135Z", "updated_at": "2026-04-10T02:00:03.689959Z", "deleted_at": null, "main_name": "IRON HEMLOCK", "aliases": [ "APT29 ", "ATK7 ", "Blue Kitsune ", "Cozy Bear ", "The Dukes", "UNC2452 ", "YTTRIUM " ], "source_name": "Secureworks:IRON HEMLOCK", "tools": [ "CosmicDuke", "CozyCar", "CozyDuke", "DiefenDuke", "FatDuke", "HAMMERTOSS", "LiteDuke", "MiniDuke", "OnionDuke", "PolyglotDuke", "RegDuke", "RegDuke Loader", "SeaDuke", "Sliver" ], "source_id": "Secureworks", "reports": null }, { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb", "created_at": "2023-01-06T13:46:38.393409Z", "updated_at": "2026-04-10T02:00:02.955738Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "Cloaked Ursa", "TA421", "Blue Kitsune", "BlueBravo", "IRON HEMLOCK", "G0016", "Nobelium", "Group 100", "YTTRIUM", "Grizzly Steppe", "ATK7", "ITG11", "COZY BEAR", "The Dukes", "Minidionis", "UAC-0029", "SeaDuke" ], "source_name": "MISPGALAXY:APT29", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434655, "ts_updated_at": 1775792236, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ee504d606a87973d55e4b904d8a10e16c2277212.pdf", "text": "https://archive.orkl.eu/ee504d606a87973d55e4b904d8a10e16c2277212.txt", "img": "https://archive.orkl.eu/ee504d606a87973d55e4b904d8a10e16c2277212.jpg" } }