{
	"id": "b7e2c1a9-928f-4cb6-9b69-b3bdcd9ddee7",
	"created_at": "2026-04-06T00:13:34.173824Z",
	"updated_at": "2026-04-10T03:33:36.016379Z",
	"deleted_at": null,
	"sha1_hash": "144631745e91671c75aa917dca53b975e8954c0b",
	"title": "Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2383554,
	"plain_text": "Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor\r\nUsed by Pensive Ursa (Aka Turla)\r\nBy Daniel Frank, Tom Fakterman\r\nPublished: 2023-10-31 · Archived: 2026-04-05 19:48:48 UTC\r\nExecutive Summary\r\nWhile tracking the evolution of Pensive Ursa (aka Turla, Uroburos), Unit 42 researchers came across a new, upgraded\r\nvariant of Kazuar. Not only is Kazuar another name for the enormous and dangerous cassowary bird, Kazuar is an advanced\r\nand stealthy .NET backdoor that Pensive Ursa usually uses as a second stage payload.\r\nPensive Ursa is a Russian-based threat group operating since at least 2004, which is linked to the Russian Federal Security\r\nService (FSB).\r\nThe Ukrainian CERT reported in July 2023 that this version of Kazuar was targeting the Ukrainian defense sector. The threat\r\ngroup behind this variant was going after sensitive assets such as those found in Signal messages, source control and cloud\r\nplatforms data.\r\nSince Unit 42’s discovery of Kazuar in 2017, we have seen it in the wild only a handful of times, targeting mostly\r\norganizations in the European government and military sectors. The Sunburst backdoor has been tied to Kazuar by code\r\nresemblance, which demonstrates its complexity level. Since late 2020, we had not seen new Kazuar samples in the wild –\r\nyet reports suggested Kazuar was under constant development.\r\nAs the code of the upgraded revision of Kazuar reveals, the authors put special emphasis on Kazuar’s ability to operate in\r\nstealth, evade detection and thwart analysis efforts. They do so using a variety of advanced anti-analysis techniques and by\r\nprotecting the malware code with effective encryption and obfuscation practices.\r\nThis article provides a deep technical analysis of Kazuar’s capabilities. We are sharing this research to provide detection,\r\nprevention and hunting recommendations to help organizations strengthen their overall security posture. An additional list of\r\nartifacts will be provided in an appendix linked to our GitHub page.\r\nPalo Alto Networks customers receive protections from and mitigations for the threats mentioned in this article in the\r\nfollowing ways:\r\nNext-Generation Firewall with the Advanced Threat Prevention security subscription can help block the malware C2\r\ntraffic\r\nOrganizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others\r\nThe Cortex XDR and XSIAM platform detects and prevents the threats mentioned in this article\r\nThe Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light\r\nof this new Kazuar variant.\r\nKazuar Overview\r\nKazuar is known for being an advanced and stealthy .NET backdoor that Pensive Ursa usually uses as a second stage\r\npayload, delivered together with other tools that the threat group commonly uses.\r\nThe recent campaign that the Ukrainian CERT reported unveiled the multi-staged delivery mechanism of Kazuar, together\r\nwith other tools such as the new Capibar first-stage backdoor. Our technical analysis of this recent variant – seen in the wild\r\nafter years of hiatus – showed significant improvements to its code structure and functionality.\r\nThis post will detail previously undocumented features, including:\r\nComprehensive system profiling - Extensive data collection.\r\nCredential theft of cloud and other sensitive applications - Theft of cloud application accounts, source control and\r\nSignal messaging application.\r\nExtended set of commands - A total of 45 supported commands to execute, received from another Kazuar node or the\r\ncommand and control (C2) server.\r\nEnhanced task automation - A range of automated tasks that the attacker could turn on/off.\r\nVariable encryption schemes - Implementation of different encryption algorithms and schemes.\r\nInjection modes - Multiple injection modes, allowing Kazuar to run from different processes and execute different\r\nfeatures.\r\nSince at least 2018, variants of Kazuar changed their obfuscation methods and methodically modified its compilation\r\ntimestamps. Some variants used the ConfuserEx obfuscator to encrypt strings, and others used a custom method. In the\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 1 of 15\n\nKazuar variant analyzed in this blog, the authors went a step further, implementing multiple custom methods for string\r\nencryption.\r\nUnlike with previous variants, the authors only focused on targeting the Windows operating system.\r\nClarification note: While analyzing Kazuar’s code, we used dnSpy to export the code into an integrated development\r\nenvironment (IDE) and decrypted the strings using a custom script. This allowed us to edit separate .cs files and edit some of\r\nthe method names into meaningful ones. We have interpreted the method names that appear in the screenshots.\r\nLatest Kazuar Variant Detailed Technical Analysis\r\nMetadata\r\nReports from other research organizations have shown that the authors of Kazuar have manipulated their samples’\r\ntimestamps since at least 2018. This new variant’s compilation timestamp is Thursday, November 20, 2008 10:11:18 AM\r\nGMT. Unlike other publicly available variants, this is the first time the authors went back as far as 2008 when faking the\r\ntimestamp.\r\nKazuar also contains hard-coded, hashed identifiers for the Agent version and BuildID as well as an Agent label. These can\r\nbe used as variant identifiers, as shown in Figure 1.\r\nFigure 1. Kazuar’s sample basic configuration information.\r\nInitialization\r\nExecuting Assembly Check\r\nWhen executing Kazuar, it uses the Assembly.Location property to receive its own file path and check its name. Kazuar will\r\ncontinue execution only if the returned value is an empty string, as shown in Figure 2. The Assembly.Location property\r\nreturns an empty string when loading the file from a byte array.\r\nThis check appears to be a simple form of an anti-analysis mechanism, to ensure that the execution of the malware was done\r\nby the intended loader and not by other means or software.\r\nKazuar will execute if its filename matches a specific hard-coded hashed name (using the FNV algorithm). This behavior is\r\nprobably meant for debugging purposes, letting the authors avoid using the loader each time they debug the malware.\r\nFigure 2. Checking the Kazuar variant’s assembly name.\r\nOperational Root Directory Creation\r\nKazuar creates a new directory to store its configuration and log data. It uses %localappdata% as the main storage path and\r\ndetermines its root directory from a list of hard-coded paths (See Appendix).\r\nKazuar chooses which root directory, folder names, filenames and file extensions to use based on the machine globally\r\nunique identifier (GUID), as shown in Figure 3. Although these names might seem randomly generated at a first glance, the\r\nusage of the GUID means they will keep the same name for each execution of the malware on the same infected machine.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 2 of 15\n\nFigure 3. The method in charge of returning an index for the paths array.\r\nLike in previous variants, Kazuar uses a structured directory scheme to save its log files and other data such as individual\r\nconfiguration files and keylogger data. Directory naming is pseudorandom and chosen based on hashing. Examples include\r\nthe custom implementation of the FNV hashing algorithm seen in previous variants, and other manipulations on the GUID\r\nvalue. You can find a list of the directories in their plaintext names in the Appendix.\r\nIt is also worth mentioning that there is a currently unreferenced option to create a file called wordlist in the code. This file\r\ncould give us a clue about a feature not yet implemented, perhaps using a wordlist for directories, filenames or password\r\nbrute forcing.\r\nConfiguration Files\r\nThe malware creates a separate main configuration file that includes data including the following:\r\nC2 servers\r\nInjection mode\r\nOther operational configuration data\r\nFigure 4 shows a snippet from this file below. You can find the encryption methods for Kazuar’s configuration files in the\r\nAppendix.\r\nFigure 4. Snippet of the configuration file.\r\nMutex Name Generation\r\nKazuar is using a mutex to check its injection into another process. Kazuar generates its mutex name by XORing the current\r\nprocess ID with the hard-coded value 0x4ac882d887106b7d and then XORing it with the machine's GUID, as depicted in\r\nFigure 5. This means that several Kazuars can operate in tandem on the same device, just not injected into the same process.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 3 of 15\n\nFigure 5. Mutex name generation.\r\nArchitecture\r\nSetting Kazuar’s Injection Modes\r\nThe new version of Kazuar uses what it describes in the configuration as “injection modes” as shown in Table 1. The default\r\nmode is inject.\r\nConfiguration\r\nfile mode name\r\nDescription\r\nInbound\r\ntraffic\r\nOutbound\r\ntraffic\r\nAdditional\r\nfunctionality\r\nthreads\r\ninject\r\nDefault mode, injects into\r\nexplorer.exe\r\nCreates a pipe communication\r\nchannel and serves as a proxy for\r\nother Kazuar instances\r\nNamed\r\npipe\r\nNamed pipe\r\nEvent Log\r\nMonitor\r\nKeylogging\r\nPeeps\r\nAutomated\r\ntasks\r\nAnti-Dumping\r\nzombify\r\nInjects into the user’s default\r\nbrowser or svchost.exe\r\nCreates a named pipe\r\ncommunication channel and serves\r\nas a proxy for other Kazuar\r\ninstances\r\nNamed\r\npipe\r\nHTTP\r\nAnti-Dumping\r\ncombined\r\nIn case the default inject method fails, it\r\nexecutes via the same method as zombify\r\nN/A N/A N/A\r\nremote\r\nCreates a named pipe communication\r\nchannel and serves as a proxy for other\r\nKazuar instances, no C2 communication\r\nNamed\r\npipe\r\nNamed pipe\r\nEvent Log\r\nMonitor\r\nAutomated\r\ntasks\r\nsingle\r\nCreates a named pipe\r\ncommunication channel and serves\r\nas a proxy for other Kazuar\r\ninstances\r\nThis mode enables C2\r\ncommunication to receive\r\ncommands via HTTP\r\nNamed\r\npipe or\r\nHTTP\r\nNamed pipe\r\nor HTTP\r\nEvent Log\r\nMonitor\r\nKeylogging\r\nPeeps\r\nAutomated\r\ntasks\r\nNot in User\r\nInteractive Mode\r\nIn case Kazuar’s execution is in a user\r\ninteractive mode, which could occur when\r\nexecuting Kazuar as a service or on a\r\nmachine with no GUI such as a server.\r\nNamed\r\npipe\r\nNamed pipe\r\nAutomated\r\ntasks\r\nWMI\r\nconsumer\r\nAnti-Dumping\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 4 of 15\n\nTable 1. Kazuar injection modes and descriptions.\r\nIn zombify mode, Kazuar is injected into the user’s default browser and has a fallback mechanism to inject itself to\r\nsvchost.exe in case the query for the default browser fails. Figure 6 shows that the term zombify addresses process injection\r\nin general by Kazuar’s authors.\r\nFigure 6. A snippet of Kazuars’ code injection in zombify mode.\r\nMultithreading Model\r\nKazuar operates in a multithreading model, while each of Kazuar’s main functionalities operates as its own thread. In other\r\nwords, one thread handles receiving commands or tasks from its C2, while a solver thread handles execution of these\r\ncommands. This multithreading model enables Kazuar’s authors to establish an asynchronous and modular flow control.\r\nFigure 7 shows the task solver flow.\r\nFigure 7. Kazuar’s task-solving mechanism diagram.\r\nThe Task Solver Component - Kazuar’s Puppeteer\r\nKazuar receives new tasks, solves them and writes the output into result files. A solver thread is handling new tasks received\r\nfrom the C2 servers or another Kazuar node. The task content is then encrypted and written to disk into a task file.\r\nEach task file implements a hybrid encryption scheme:\r\n1. Using RNGCryptoServiceProvider to generate two byte-arrays containing random numbers, which are 16 and 32\r\nbytes long respectively.\r\nUsing the first array as an AES (Rijndael) initialization vector (IV).\r\nUsing the second array as an AES key.\r\n2. Generating an HMACMD5 hash based on the result’s content from memory, prior to its encryption and writing to\r\ndisk, using the array described in the first bullet above as the key.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 5 of 15\n\n3. Encrypting the HMACMD5 hash, AES key and IV with the hard-coded RSA key, and writing the encrypted BLOB to\r\nthe beginning of the file. By using the fast AES algorithm to encrypt larger objects such as the result’s contents, and\r\nusing the slower RSA encryption to conceal the AES key and IV, Kazuar improves its performance. This also disables\r\nthe option of recovering infected files only from disk, since the symmetric key is encrypted using an asymmetric key.\r\n4. Using the AES encryption to encrypt the result file’s contents.\r\nAs shown in Figure 8, once a task is complete, the generated result file will be saved to disk.\r\nFigure 8. A snippet of Kazuar’s method to encrypt and write a result file.\r\nIn addition to the aforementioned encrypted data, Kazuar writes the following fields to the beginning of the result file:\r\n1. Four zero bytes (we believe this serves as a sort of a delimiter)\r\n2. Generated result identifier\r\n3. Length of the encrypted GUID, using the same XOR algorithm as in the initialization part (the encrypted message\r\nhere is “System info at [datetime] (-07)”)\r\n4. The encrypted GUID itself\r\n5. RSA encrypted HMACMD5 hash + IV + AES key\r\n6. The AES encrypted task content\r\nFigure 9 shows the encrypted result file content from disk.\r\nFigure 9. An encrypted result file content from disk.\r\nStrings Encryption\r\nKazuar’s code includes a high volume of strings that are related to functionality and debugging. When revealed in plain text,\r\nthey shed light on the inner workings and functionality of Kazuar. To avoid the scenario of researchers creating strings-based\r\nindicative YARA and hunting rules, Kazuar’s strings are encrypted. It decrypts each string at runtime.\r\nKazuar uses a variation of a Caesar Cipher for the string encryption/decryption algorithm. In this algorithm, Kazuar\r\nimplements a dictionary that simply swaps the key and value of each member. Recent Kazuar variants implemented only\r\none dictionary, while the new variant implements multiple dictionaries, each containing 80 pairs of characters as shown in\r\nFigure 10.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 6 of 15\n\nFigure 10. One of the classes containing the dictionary used for string decryption.\r\nFigure 11 shows a loop iterating over a given string, and checking if the ordinal value of a given character is in the\r\ndictionary keys of the relevant class. If it is, Kazuar swaps the key and value and appends it to the crafted string. Otherwise,\r\nit keeps the original character.\r\nIn addition to the string obfuscation, the authors have given unmeaningful names to the classes and methods in the code, to\r\nmake analysis more difficult.\r\nFigure 11. The loop that creates the deobfuscated string.\r\nOne of the strings decoded by Kazuar returns the value “Invalid pong responce” as shown in Figure 12. It seems that one of\r\nthe malware coders forgot to switch the Russian C for an English S.\r\nFigure 12. The typo in the “response” string.\r\nCore Functionality\r\nIn a fashion typical to Pensive Ursa, to avoid takedowns, Kazuar uses hijacked legitimate websites for its C2 infrastructure.\r\nIn addition, as mentioned in the Injection Modes section, Kazuar also supports communication over named pipes. It uses\r\nboth mechanisms to receive remote commands, or tasks (as described in the code).\r\nSupported C2 Commands\r\nKazuar supports 45 different tasks it can receive from its C2, as shown in Table 2. This is yet another development in\r\nKazuar’s code, as previous research hadn’t documented some of these tasks. By comparison, Kazuar’s first variant analyzed\r\nback in 2017 supported only 26 C2 commands.\r\nWe have grouped Kazuar’s commands into the following categories:\r\nHost data collection\r\nExtended forensic data collection\r\nFile manipulation\r\nArbitrary command execution\r\nInteraction with Kazuar’s configuration\r\nRegistry querying and manipulation\r\nScripts execution (VBS, PowerShell, JavaScript)\r\nCustom network requests\r\nCredentials and sensitive information stealing\r\nCommand Description\r\nsindex\r\nSearches for properties of files with the following extensions: .txt, .ini, .config, .vbs, .js, .ps1, .doc, .docx,\r\n.xls, .xlsx, .ppt, .pptx under folders in the C:\\Users\\ path.\r\nscrshot Takes a screenshot of the window of a specified process\r\nmove Moves a file from a source path to a destination path\r\ninfo Gets system information about one or multiple of the fields (described in Appendix)\r\nsteal Steals data from various browsers and applications (full list ID in Appendix)\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 7 of 15\n\nrun\r\nExecutes a specified executable with supplied arguments, save the output to a temporary file, and upload\r\nthe file to the C2 server.\r\nschlist Gets data about scheduled tasks using the Schedule.Service COM object\r\nconfig Updates Kazuar’s configuration file\r\nnetuse\r\nConnects or removes network resources from the machine using the WNetAddConnection2 and\r\nWNetCancelConnection2 WinAPIs\r\nlog Adds a custom log to the log file\r\ndelegate Sends a command to another Kazuar implant on a remote system using a PIPE\r\neventlog Gets Windows Event log entries\r\nget\r\nUploads files from a specified directory to Kazuar’s C2 servers, choosing which files to upload based on\r\ntheir modified, accessed and created timestamps.\r\nautoruns\r\nChecks various possibilities for software to have persistence in the infected machine (checks described in\r\nAppendix)\r\nput Writes received data to a specified file on the system.\r\nregwrite Sets a registry key/value.\r\nautoslist Lists the number of files that were created under the Autos functionality \r\nvbs Executes a VBScript\r\npsh Executes a PowerShell Script\r\nsleep Sets Kazuar to sleep for a specified amount of time\r\nregdelete Deletes a registry key/value\r\ntimelimit Sets a time limit for a task from the server\r\ndlllist Gets all loaded modules of a specified process\r\nautosget Sends files created by the Autos functionality to the C2\r\nwmiquery Executes a WMI Query\r\ndotnet Executes a .NET method received from the C2\r\ntasklist Gets a list of running processes \r\nfind\r\nFinds a specified directory and lists its files. It appears the actor can specify which files to list based on\r\ntheir modified, accessed and created timestamps as well.\r\npeep Executes a command related to the peeps functionality, which we have described in the peeps section.\r\nforensic Checks the system for multiple forensic artifacts (see Appendix)\r\nkill Kills a process by name or by process identifier (PID)\r\nregquery Queries a registry key\r\nchakra Executes Javascript using ChakraCore \r\nhttp Creates a crafted HTTP request\r\npipelist Gets open pipe list for a specific machine\r\njsc Executes JavaScript\r\nwmicall Calls a WMI method\r\nautosdel Deletes files created by the Autos functionality \r\ndel\r\nDeletes a specified file OR folder. Allows the attacker to supply a flag to securely delete a file by\r\noverwriting the file with random data before deleting it.\r\nnbts Crafts a NetBIOS request\r\ncopy\r\nCopies a specified file to a specified location. The attacker is able to overwrite the destination file if it\r\nalready exists.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 8 of 15\n\nupgrade Downloads an upgrade to the malware\r\ncmd Executes a command via cmd.exe\r\nunattend\r\nSteals files related to various windows configuration or cloud applications credentials (full list of files is\r\nincluded in Appendix)\r\nautosclear Clears the Autos log list of files \r\nTable 2. Kazuar’s supported C2 commands.\r\nCloud, Source Control and Messaging Apps Credential Theft\r\nKazuar has the capability to attempt to steal credentials from many artifacts in the infected computer, by receiving the\r\ncommands steal or unattend from the C2.\r\nThese artifacts include multiple well-known cloud applications.\r\nKazuar can attempt to steal sensitive files that contain credentials for these applications. Artifacts targeted by Kazuar include\r\nGit SCM (a source control system that is popular among developers), as shown in Figure 13, and Signal (an encrypted\r\nmessaging service for private instant messaging). We have included the full description of the artifacts in the Appendix.\r\nFigure 13. Code snippet of Git SCM credentials Kazuar may attempt to steal.\r\nComprehensive System Profiling\r\nWhen Kazuar is initially spawning a unique solver thread, the first task it automatically executes is the extensive collection\r\nand profiling of the targeted system, named by Kazuar’s authors as first_systeminfo_do. As part of this task, Kazuar will\r\ncollect extensive information about the infected machine and will send it to the C2. This includes information on the\r\noperating system, hardware and network. The Appendix includes the entirety of what the attackers collected.\r\nKazuar saves this data into an info.txt file and saves the execution logs to a logs.txt file. As mentioned in the Task Solver\r\nsection, we can see the result in memory. In this case, it’s an archive, as depicted in Figure 14.\r\nFigure 14. The result of the first_systeminfo_do archive in memory.\r\nBesides the two aforementioned text files, as part of this task, the malware takes a screenshot of the user’s screen. Figure 15\r\nshows the zipping of all of these files into one archive before being encrypted and sent to the C2.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 9 of 15\n\nFigure 15. The result of the first_systeminfo_do archive extracted memory, prior to encryption.\r\nCreating Automated Tasks (Autos)\r\nKazuar has the ability to set up automated tasks that will run at specified intervals to gather information from the infected\r\nmachines. Figure 16 shows an example of this functionality as documented in Kazuar’s configuration.\r\nThese automated tasks include the following:\r\nGathering system information (described in the section on Comprehensive System Profiling)\r\nTaking screenshots\r\nStealing credentials (listed in full in the Appendix)\r\nGetting forensics data (see Appendix)\r\nGetting auto-runs data (see Appendix)\r\nGetting files from specified folders.\r\nGetting a list of LNK files\r\nStealing emails using MAPI\r\nFigure 16. A snippet of Kazuar’s configuration of the Autos function.\r\nMonitoring Active Windows (Peeps)\r\nKazuar has the ability to let attackers set up what they called “peep rules” in the configuration. Although Kazuar does not\r\ncome with these rules set out of the box, according to the malware’s code, it appears that this functionality enables the\r\nattacker to monitor the windows of specified processes. This allows the attacker to track user activity of interest on the\r\ncompromised machine.\r\nCommunication With the Command and Control\r\nHTTP\r\nPrior to establishing a communication channel with a C2 server, and in addition to the aforementioned anti-analysis checks,\r\nKazuar checks the configuration data-sending time intervals. This check includes determining whether it should send data\r\nover the weekend or not.\r\nUpon first communication, Kazuar sends the collected data (described in the Comprehensive System Profiling section) in an\r\nXML format and expects to get an XML structured response back with a new task. Figure 17 shows the HTTP request.\r\nKazuar uses a hard-coded value 169739e7-2112-9514-6a61-d300c0fef02d casted to a string and Base64 encoded as the\r\ncookie.\r\nFigure 17. HTTP POST command with an XML in the body sent to the C2.\r\nKazuar generates key names for the XML and Base64 encrypts the content prior to sending it to the C2. The content of the\r\nXML contains:\r\nEncrypted content of the result file\r\nResult identifier\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 10 of 15\n\nPseudorandom 4-byte numbers, probably another type of identifier\r\nAn array with values pseudorandomly generated based on the machine’s GUID\r\nThe hard-coded GUID connection string 169739e7-2112-9514-6a61-d300c0fef02d\r\nThe machine’s unique GUID\r\nCommunication Using Named Pipes\r\nIn addition to direct HTTP communication with the C2, Kazuar has the ability to function as a proxy, to receive and send\r\ncommands to other Kazuar agents in the infected network. It is doing this proxy communication via named pipes, generating\r\ntheir names based on the machine’s GUID.\r\nKazuar uses these pipes to establish peer-to-peer communication between different Kazuar instances, configuring each as a\r\nserver or a client. The named pipe communication supports the remote requests shown in Table 3.\r\nRemote Request Kazuar’s Response Description\r\nPING PONG Return a message with the current instance process information\r\nTASK RESULT Start a received task and return a result\r\nLOGS ERROR Retrieve error logs\r\nTable 3. Kazuar requests and responses using named pipes.\r\nAnti-Analysis Checks\r\nKazuar uses multiple anti-analysis techniques based on a series of elaborate checks, to ensure it is not being analyzed. The\r\nauthors programmed Kazuar to either continue if the coast is clear, or to remain idle and cease all C2 communication if it is\r\nbeing debugged or analyzed. We can group these checks into three main categories: honeypot, analysis tools and sandbox.\r\nAnti-Dumping\r\nBecause Kazuar is not designed to run as a standalone process but rather lives injected within another process, dumping its\r\ncode is possible from memory of the injected process. To prevent that from happening, Kazuar uses a powerful feature of\r\n.NET, which is the System.Reflection Namespace. This gives Kazuar the ability to gather real-time metadata about its\r\nassembly, methods and more.\r\nKazuar checks if it has set the antidump_methods setting to true, then overrides the pointers to its custom methods, while\r\nignoring generic .NET methods, essentially wiping them from memory (as Kazuar’s logged message states). This ultimately\r\nprevents researchers from dumping an intact version of the malware.\r\nHoneypot Check\r\nOne of the first things Kazuar specifically searches for is the existence of Kaspersky honeypot artifacts on the machine. It\r\nuses a hard-coded list of specific process names and filenames to do this.\r\nIf Kazuar finds more than five of these files or processes, it will log that it found a Kaspersky honeypot. Figure 18 shows\r\nthese filenames.\r\nFigure 18. Filenames that Kazuar checks to find Kaspersky honeypot.\r\nAnalysis Tools Check\r\nKazuar has a list of hard-coded names of different popular analysis tools such as the following:\r\nProcess Monitor\r\nX32dbg\r\nDnSpy\r\nWireshark\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 11 of 15\n\nIt goes over the list of running processes, and if one of these tools is running, Kazuar will log that it found analysis tools (see\r\nAppendix).\r\nSandbox Check\r\nKazuar has a list of hard-coded known sandbox libraries. It checks for the presence of certain DLLs that belong to different\r\nsandbox services. If the malware finds these files, it determines that it is being executed in a lab (see Appendix).\r\nEvent Log Monitor\r\nKazuar collects and parses events from the Windows event logs. Figure 19 shows Kazuar specifically looking for events\r\nfrom the following antivirus/security vendors:\r\nKaspersky Endpoint Security\r\nSymantec Endpoint Protection Client\r\nMicrosoft Windows Defender\r\nDoctor Web\r\nSame as with checking for Kaspersky’s honeypot, a plausible explanation would be that these security products are popular\r\nwith their victims.\r\nFigure 19. Event logs that Kazuar collects from specific security products.\r\nStrengthening Kazuar’s Connection to Pensive Ursa\r\nAs mentioned above, when composing its initial HTTP POST request to its C2, Kazuar uses the machines GUID or a hard-coded GUID 169739e7-2112-9514-6a61-d300c0fef02d as a cookie, which is then type casted to string and Base64 encoded.\r\nSearching the latter value in its string format (169739e7211295146a61d300c0fef02d) yields a report [PDF] by the Swiss\r\nCERT, which analyzes an attack carried out by Pensive Ursa against RUAG. RUAG Holding is a Swiss company from the\r\naerospace and defense sector.\r\nIn addition, Kazuar’s tasks and results architecture, including the hybrid AES + RSA encryption scheme and other clear\r\nsimilarities in functionality, are the very image of Carbon’s modus operandi. It is mentioned both in the Swiss’s CERT report\r\nand another report by ESET. Carbon is another second stage backdoor that was attributed multiple times to Pensive Ursa,\r\nwhose code was a fork of Snake, as mentioned by CISA.\r\nThese findings, along with the reports by multiple CERTs, further support the previous Unit 42 assumptions proposing that\r\nKazuar might be Carbon’s successor. Most importantly, these findings strengthen the attribution of Kazuar to Pensive Ursa.\r\nConclusion\r\nWe examined the newest Kazuar malware variant that we detected in the wild. Notable features include the following:\r\nRobust code and string obfuscation techniques\r\nA multithreaded model for enhanced performance\r\nA range of encryption schemes implemented to safeguard Kazuar’s code from analysis and to conceal its data\r\nwhether in memory, during transmission or on disk\r\nAll the aforementioned features are designed to provide the Kazuar backdoor a high level of stealth. Other noteworthy\r\ncharacteristics of this malware are:\r\nIts anti-analysis functionalities\r\nExtensive system profiling capabilities\r\nThe specific targeting of cloud applications\r\nThis version of Kazuar also supports an array of over 40 distinct commands, half of which were previously undocumented.\r\nWe encourage security practitioners and defenders to study this report and use the information provided to enhance current\r\ndetection, prevention and hunting practices to overall strengthen their security posture.\r\nCortex XDR Detection and Prevention\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 12 of 15\n\nFigure 20 shows Cortex XDR detected and prevented the execution of Kazuar. As detailed in the technical analysis section,\r\nby default Kazuar injects its code into explorer.exe. When configured to operate on detect mode, Cortex XDR detects the\r\nmalicious activity originating from the injected explorer.exe, as depicted in Figure 20 below.\r\nFigure 20. Kazuar’s detection, shown in Cortex XDR in detect mode.\r\nExecution of native code by Kazuar for process injection and WMI execution triggered several alerts, as well as other\r\nsuspicious and uncharacteristic activity carried out by explorer.exe. We detailed the alerts, including the alert shown in\r\nFigure 20, in Figure 21 below.\r\nFigure 21. Kazuar’s execution alerts, shown in Cortex XDR in detect mode.\r\nIn addition, Figure 22 documents and details the directory and files that the malware created to store its configuration and\r\nlogs.\r\nFigure 22. Kazuar’s execution alerts as seen in Cortex XDR on detect mode.\r\nFinally, Figure 23 shows that when in prevent mode, Cortex XDR prevents the Kazuar malware executable and triggers the\r\nalert pop-up accordingly.\r\nFigure 23. Kazuar’s execution prevention alert as seen in Cortex XDR on prevent mode.\r\nProtections and Mitigations\r\nThe Cortex XDR platform detects and prevents the execution flow described in the screenshots included in the previous\r\nsection.\r\nIn addition to the classic detection, the unique SmartScore engine translates security investigation methods and their\r\nassociated data into a ML-driven hybrid risk scoring system. Figure 24 shows that the Kazuar variant and its related incident\r\ndetailed in this blog scored 97 out of 100 by SmartScore.\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 13 of 15\n\nFigure 24. The score given to Kazuar in SmartScore.\r\nFor Palo Alto Networks customers, our products and services provide the following coverage associated with this group.\r\nCortex XDR and XSIAM detect user and credential-based threats by analyzing user activity from multiple data sources\r\nincluding the following:\r\nEndpoints\r\nNetwork firewalls\r\nActive Directory\r\nIdentity and access management solutions\r\nCloud workloads\r\nCortex XDR and XSIAM build behavioral profiles of user activity over time with machine learning. By comparing new\r\nactivity to past activity, peer activity and the expected behavior of the entity, Cortex XDR and XSIAM detect anomalous\r\nactivity indicative of credential-based attacks.\r\nIt also offers the following protections related to the attacks discussed in this post:\r\nPrevents the execution of known malicious malware and also prevents the execution of unknown malware using\r\nBehavioral Threat Protection and machine learning based on the Local Analysis module\r\nProtects against credential gathering tools and techniques using the new Credential Gathering Protection available\r\nfrom Cortex XDR 3.4\r\nProtects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection\r\nCortex XDR Pro and XSIAM detect postexploit activity, including credential-based attacks, with behavioral analytics\r\nNext-Generation Firewall with the Advanced Threat Prevention security subscription can help block the malware C2\r\ntraffic via the following Threat Prevention signature: 86805.\r\nThe Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light\r\nof this new Kazuar variant. Multiple products in the Palo Alto Networks portfolio leverage Advanced WildFire to\r\nprovide coverage against Kazuar variants and other threats.\r\nIf you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team\r\nor call:\r\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\r\nEMEA: +31.20.299.3130\r\nAPAC: +65.6983.8730\r\nJapan: +81.50.1790.0200\r\nPalo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use\r\nthis intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn\r\nmore about the Cyber Threat Alliance.\r\nIndicators of Compromise\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 14 of 15\n\nKazuar SHA256\r\n91dc8593ee573f3a07e9356e65e06aed58d8e74258313e3414a7de278b3b5233\r\nCommand and Control Servers\r\nhxxps://www.pierreagencement[.]fr/wp-content/languages/index.php\r\nhxxps://sansaispa[.]com/wp-includes/images/gallery/\r\nhxxps://octoberoctopus.co[.]za/wp-includes/sitemaps/web/\r\nRSA Keys\r\n\u003cRSAKeyValue\u003e\r\n\u003cModulus\u003e7ondEZo8ZjYh+FP4h3PgJBU/yTlO+g8ZbCF0wx8eocnqxLS4YWI9hG3SI2hlEBz6J4vvxPCrs/jazekolaZLQnbyOCyH53I+We+x32d2\r\n\u003c/Modulus\u003e\u003cExponent\u003eAQAB\u003c/Exponent\u003e\u003c/RSAKeyValue\u003e\r\n\u003cRSAKeyValue\u003e\r\n\u003cModulus\u003epyR0/srVS0gOZbNdK3iK+GvekQVkBq8brOVCuN/XcCz4WLJod9GhivDYrDtMXF6ZMGHKa2zAcQ+v2vltYW3X2BYCZ1sblEzn\r\n\u003c/Modulus\u003e\u003cExponent\u003eAQAB\u003c/Exponent\u003e\u003c/RSAKeyValue\u003e\r\nSource: https://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nhttps://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/pensive-ursa-uses-upgraded-kazuar-backdoor/"
	],
	"report_names": [
		"pensive-ursa-uses-upgraded-kazuar-backdoor"
	],
	"threat_actors": [
		{
			"id": "8aaa5515-92dd-448d-bb20-3a253f4f8854",
			"created_at": "2024-06-19T02:03:08.147099Z",
			"updated_at": "2026-04-10T02:00:03.685355Z",
			"deleted_at": null,
			"main_name": "IRON HUNTER",
			"aliases": [
				"ATK13 ",
				"Belugasturgeon ",
				"Blue Python ",
				"CTG-8875 ",
				"ITG12 ",
				"KRYPTON ",
				"MAKERSMARK ",
				"Pensive Ursa ",
				"Secret Blizzard ",
				"Turla",
				"UAC-0003 ",
				"UAC-0024 ",
				"UNC4210 ",
				"Venomous Bear ",
				"Waterbug "
			],
			"source_name": "Secureworks:IRON HUNTER",
			"tools": [
				"Carbon-DLL",
				"ComRAT",
				"LightNeuron",
				"Mosquito",
				"PyFlash",
				"Skipper",
				"Snake",
				"Tavdig"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a97cf06d-c2e2-4771-99a2-c9dee0d6a0ac",
			"created_at": "2022-10-25T16:07:24.349252Z",
			"updated_at": "2026-04-10T02:00:04.949821Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"ATK 13",
				"Belugasturgeon",
				"Blue Python",
				"CTG-8875",
				"G0010",
				"Group 88",
				"ITG12",
				"Iron Hunter",
				"Krypton",
				"Makersmark",
				"Operation Epic Turla",
				"Operation Moonlight Maze",
				"Operation Penguin Turla",
				"Operation Satellite Turla",
				"Operation Skipper Turla",
				"Operation Turla Mosquito",
				"Operation WITCHCOVEN",
				"Pacifier APT",
				"Pensive Ursa",
				"Popeye",
				"SIG15",
				"SIG2",
				"SIG23",
				"Secret Blizzard",
				"TAG-0530",
				"Turla",
				"UNC4210",
				"Venomous Bear",
				"Waterbug"
			],
			"source_name": "ETDA:Turla",
			"tools": [
				"ASPXSpy",
				"ASPXTool",
				"ATI-Agent",
				"AdobeARM",
				"Agent.BTZ",
				"Agent.DNE",
				"ApolloShadow",
				"BigBoss",
				"COMpfun",
				"Chinch",
				"Cloud Duke",
				"CloudDuke",
				"CloudLook",
				"Cobra Carbon System",
				"ComRAT",
				"DoublePulsar",
				"EmPyre",
				"EmpireProject",
				"Epic Turla",
				"EternalBlue",
				"EternalRomance",
				"GoldenSky",
				"Group Policy Results Tool",
				"HTML5 Encoding",
				"HyperStack",
				"IcedCoffee",
				"IronNetInjector",
				"KSL0T",
				"Kapushka",
				"Kazuar",
				"KopiLuwak",
				"Kotel",
				"LOLBAS",
				"LOLBins",
				"LightNeuron",
				"Living off the Land",
				"Maintools.js",
				"Metasploit",
				"Meterpreter",
				"MiamiBeach",
				"Mimikatz",
				"MiniDionis",
				"Minit",
				"NBTscan",
				"NETTRANS",
				"NETVulture",
				"Neptun",
				"NetFlash",
				"NewPass",
				"Outlook Backdoor",
				"Penquin Turla",
				"Pfinet",
				"PowerShell Empire",
				"PowerShellRunner",
				"PowerShellRunner-based RPC backdoor",
				"PowerStallion",
				"PsExec",
				"PyFlash",
				"QUIETCANARY",
				"Reductor RAT",
				"RocketMan",
				"SMBTouch",
				"SScan",
				"Satellite Turla",
				"SilentMoon",
				"Sun rootkit",
				"TTNG",
				"TadjMakhal",
				"Tavdig",
				"TinyTurla",
				"TinyTurla Next Generation",
				"TinyTurla-NG",
				"Topinambour",
				"Tunnus",
				"Turla",
				"Turla SilentMoon",
				"TurlaChopper",
				"Uroburos",
				"Urouros",
				"WCE",
				"WITCHCOVEN",
				"WhiteAtlas",
				"WhiteBear",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"Wipbot",
				"WorldCupSec",
				"XTRANS",
				"certutil",
				"certutil.exe",
				"gpresult",
				"nbtscan",
				"nbtstat",
				"pwdump"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a97fee0d-af4b-4661-ae17-858925438fc4",
			"created_at": "2023-01-06T13:46:38.396415Z",
			"updated_at": "2026-04-10T02:00:02.957137Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"TAG_0530",
				"Pacifier APT",
				"Blue Python",
				"UNC4210",
				"UAC-0003",
				"VENOMOUS Bear",
				"Waterbug",
				"Pfinet",
				"KRYPTON",
				"Popeye",
				"SIG23",
				"ATK13",
				"ITG12",
				"Group 88",
				"Uroburos",
				"Hippo Team",
				"IRON HUNTER",
				"MAKERSMARK",
				"Secret Blizzard",
				"UAC-0144",
				"UAC-0024",
				"G0010"
			],
			"source_name": "MISPGALAXY:Turla",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d11c89bb-1640-45fa-8322-6f4e4053d7f3",
			"created_at": "2022-10-25T15:50:23.509601Z",
			"updated_at": "2026-04-10T02:00:05.277674Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"Turla",
				"IRON HUNTER",
				"Group 88",
				"Waterbug",
				"WhiteBear",
				"Krypton",
				"Venomous Bear",
				"Secret Blizzard",
				"BELUGASTURGEON"
			],
			"source_name": "MITRE:Turla",
			"tools": [
				"PsExec",
				"nbtstat",
				"ComRAT",
				"netstat",
				"certutil",
				"KOPILUWAK",
				"IronNetInjector",
				"LunarWeb",
				"Arp",
				"Uroburos",
				"PowerStallion",
				"Kazuar",
				"Systeminfo",
				"LightNeuron",
				"Mimikatz",
				"Tasklist",
				"LunarMail",
				"HyperStack",
				"NBTscan",
				"TinyTurla",
				"Penquin",
				"LunarLoader"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434414,
	"ts_updated_at": 1775792016,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/144631745e91671c75aa917dca53b975e8954c0b.pdf",
		"text": "https://archive.orkl.eu/144631745e91671c75aa917dca53b975e8954c0b.txt",
		"img": "https://archive.orkl.eu/144631745e91671c75aa917dca53b975e8954c0b.jpg"
	}
}