{
	"id": "8b6f5bcb-ce14-4b10-9364-6f285b9faf66",
	"created_at": "2026-04-06T00:21:27.058903Z",
	"updated_at": "2026-04-10T03:38:20.653047Z",
	"deleted_at": null,
	"sha1_hash": "e71dd9a1927a199295797ed01c16432d6d873700",
	"title": "From BYOVD to a 0-day: Unveiling Advanced Exploits in Cyber Recruiting Scams - Avast Threat Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1052702,
	"plain_text": "From BYOVD to a 0-day: Unveiling Advanced Exploits in Cyber\r\nRecruiting Scams - Avast Threat Labs\r\nBy Luigino Camastra\r\nPublished: 2024-04-18 · Archived: 2026-04-05 23:13:48 UTC\r\nKey Points\r\nAvast discovered a new campaign targeting specific individuals through fabricated job offers. \r\nAvast uncovered a full attack chain from infection vector to deploying “FudModule 2.0” rootkit with 0-day Admin\r\n-\u003e Kernel exploit. \r\nAvast found a previously undocumented Kaolin RAT, where it could aside from standard RAT functionality, change\r\nthe last write timestamp of a selected file and load any received DLL binary from C\u0026C server. We also believe it was\r\nloading FudModule along with a 0-day exploit. \r\nIntroduction\r\nIn the summer of 2023, Avast identified a campaign targeting specific individuals in the Asian region through fabricated job\r\noffers. The motivation behind the attack remains uncertain, but judging from the low frequency of attacks, it appears that the\r\nattacker had a special interest in individuals with technical backgrounds. This sophistication is evident from previous\r\nresearch where the Lazarus group exploited vulnerable drivers and performed several rootkit techniques to effectively blind\r\nsecurity products and achieve better persistence. \r\nIn this instance, Lazarus sought to blind security products by exploiting a vulnerability in the default Windows driver,\r\nappid.sys (CVE-2024-21338). More information about this vulnerability can be found in a corresponding blog post. \r\nThis indicates that Lazarus likely allocated additional resources to develop such attacks. Prior to exploitation, Lazarus\r\ndeployed the toolset meticulously, employing fileless malware and encrypting the arsenal onto the hard drive, as detailed\r\nlater in this blog post. \r\nFurthermore, the nature of the attack suggests that the victim was carefully selected and highly targeted, as there likely\r\nneeded to be some level of rapport established with the victim before executing the initial binary. Deploying such a\r\nsophisticated toolset alongside the exploit indicates considerable resourcefulness. \r\nThis blog post will present a technical analysis of each module within the entire attack chain. This analysis aims to establish\r\nconnections between the toolset arsenal used by the Lazarus group and previously published research. \r\nInitial access \r\nThe attacker initiates the attack by presenting a fabricated job offer to an unsuspecting individual, utilizing social\r\nengineering techniques to establish contact and build rapport. While the specific communication platform remains unknown,\r\nprevious research by  Mandiant and ESET suggests potential delivery vectors may include LinkedIn, WhatsApp, email or\r\nother platforms. Subsequently, the attacker attempts to send a malicious ISO file, disguised as VNC tool, which is a part of\r\nthe interviewing process. The choice of an ISO file is starting to be very attractive for attackers because, from Windows 10,\r\nan ISO file could be automatically mounted just by double clicking and the operating system will make the ISO content\r\neasily accessible. This may also serve as a potential Mark-of-the-Web (MotW) bypass. \r\nSince the attacker created rapport with the victim, the victim is tricked by the attacker to mount the ISO file, which contains\r\nthree files: AmazonVNC.exe , version.dl l and aws.cfg . This leads the victim to execute AmazonVNC.exe .  \r\nThe AmazonVNC.exe executable only pretends to be the Amazon VNC client, instead, it is a legitimate Windows application\r\ncalled choice.exe that ordinarily resides in the System32 folder. This executable is used for sideloading, to load the\r\nmalicious version.dll through the legitimate choice.exe application. Sideloading is a popular technique among\r\nattackers for evading detection since the malicious DLL is executed in the context of a legitimate application.  \r\nWhen AmazonVNC.exe gets executed, it loads version.dll . This malicious DLL is using native Windows API functions in\r\nan attempt to avoid defensive techniques such as user-mode API hooks. All native API functions are invoked by direct\r\nsyscalls. The malicious functionality is implemented in one of the exported functions and not in DLL Main. There is no code\r\nin DLLMain it just returns 1, and in the other exported functions is just Sleep functionality. \r\nAfter the DLL obtains the correct syscall numbers for the current Windows version, it is ready to spawn an iexpress.exe\r\nprocess to host a further malicious payload that resides in the third file, aws.cfg . Injection is performed only if the\r\nKaspersky antivirus is installed on the victim’s computer, which seems to be done to evade Kaspersky detection. If\r\nKaspersky is not installed, the malware executes the payload by creating a thread in the current process, with no injection.\r\nThe aws.cfg file, which is the next stage payload, is obfuscated by VMProtect, perhaps in an effort to make reverse\r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 1 of 9\n\nengineering more difficult. The payload is capable of downloading shellcode from a Command and Control (C\u0026C) server,\r\nwhich we believe is a legitimate hacked website selling marble material for construction. The official website is\r\nhttps://www[.]henraux.com/ , and the attacker was able to download shellcode from\r\nhttps://www[.]henraux.com/sitemaps/about/about.asp\r\nIn detailing our findings, we faced challenges extracting a shellcode from the C\u0026C server as the malicious URL was\r\nunresponsive.  \r\nBy analyzing our telemetry, we uncovered potential threats in one of our clients, indicating a significant correlation between\r\nthe loading of shellcode from the C\u0026C server via an ISO file and the subsequent appearance of the RollFling , which is a\r\nnew undocumented loader that we discovered and will delve into later in this blog post. \r\nMoreover, the delivery method of the ISO file exhibits tactical similarities to those employed by the Lazarus group, a fact\r\npreviously noted by researchers from Mandiant and ESET. \r\nIn addition, a RollSling sample was identified on the victim machines, displaying code similarities with the RollSling\r\nsample discussed in Microsoft’s research. Notably, the RollSling instance discovered in our client’s environment was\r\ndelivered by the RollFling loader, confirming our belief in the connection between the absent shellcode and the initial\r\nloader RollFling . For visual confirmation, refer to the first screenshot showcasing the SHA of RollSling report code\r\nfrom Microsoft, while on the second screenshot is the code derived from our RollSling sample. \r\nImage illustrates the RollSling code identified by Microsoft. SHA:\r\nd9add2bfdfebfa235575687de356f0cefb3e4c55964c4cb8bfdcdc58294eeaca .\r\nImage showcases the RollSling code discovered within our targe. SHA:\r\n68ff1087c45a1711c3037dad427733ccb1211634d070b03cb3a3c7e836d210f .\r\nIn the next paragraphs, we are going to explain every component in the execution chain, starting with the initial RollFling\r\nloader, continuing with the subsequently loaded RollSling loader, and then the final RollMid loader. Finally, we will\r\nanalyze the Kaolin RAT, which is ultimately loaded by the chain of these three loaders. \r\nLoaders\r\nRollFling\r\nThe RollFling loader is a malicious DLL that is established as a service, indicating the attacker’s initial attempt at\r\nachieving persistence by registering as a service. Accompanying this RollFling loader are essential files crucial for the\r\nconsistent execution of the attack chain. Its primary role is to kickstart the execution chain, where all subsequent stages\r\noperate exclusively in memory. Unfortunately, we were unable to ascertain whether the DLL file was installed as a service\r\nwith administrator rights or just with standard user rights. \r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 2 of 9\n\nThe loader acquires the System Management BIOS (SMBIOS) table by utilizing the Windows API function\r\nGetSystemFirmwareTable . Beginning with Windows 10, version 1803, any user mode application can access SMBIOS\r\ninformation. SMBIOS serves as the primary standard for delivering management information through system firmware. \r\nBy calling the GetSystemFirmwareTable (see Figure 1.) function, SMBIOSTableData is retrieved, and that\r\nSMBIOSTableData is used as a key for decrypting the encrypted RollSling loader by using the XOR operation. Without\r\nthe correct SMBIOSTableData , which is a 32-byte-long key, the RollSling decryption process would be ineffective so the\r\nexecution of the malware would not proceed to the next stage. This suggests a highly targeted attack aimed at a specific\r\nindividual. \r\nThis suggests that prior to the attacker establishing persistence by registering the RollFling loader as a service, they had to\r\ngather information about the SMBIOS table and transmit it to the C\u0026C server. Subsequently, the C\u0026C server could then\r\nreply with another stage. This additional stage, called  RollSling , is stored in the same folder as RollFling but with the\r\n\".nls\" extension.  \r\nAfter successful XOR decryption of RollSling ,  RollFling is now ready to load decrypted RollSling into memory\r\nand continue with the execution of RollSling . \r\nFigure 1: Obtaining SMBIOS firmware table provider\r\nRollSling\r\nThe RollSling loader, initiated by RollFling , is executed in memory. This choice may help the attacker evade detection\r\nby security software. The primary function of RollSling is to locate a binary blob situated in the same folder as\r\nRollSling (or in the Package Cache folder). If the binary blob is not situated in the same folder as the RollSling , then\r\nthe loader will look in the Package Cache folder. This binary blob holds various stages and configuration data essential for\r\nthe malicious functionality. This binary blob must have been uploaded to the victim machine by some previous stage in the\r\ninfection chain.  \r\nThe reasoning behind binary blob holding multiple files and configuration values is twofold. Firstly, it is more efficient to\r\nhold all the information in a single file and, secondly, most of the binary blob can be encrypted, which may add another\r\nlayer of evasion meaning lowering the chance of detection.  \r\nRollsling is scanning the current folder, where it is looking for a specific binary blob. To determine which binary blob in\r\nthe current folder is the right one, it first reads 4 bytes to determine the size of the data to read. Once the data is read, the\r\nbytes from the binary blob are reversed and saved in a temporary variable, afterwards, it goes through several conditions\r\nchecks like the MZ header check. If the MZ header check is done, subsequently it looks for the “StartAction” export\r\nfunction from the extracted binary. If all conditions are met, then it will load the next stage RollMid in memory. The\r\nattackers in this case didn’t use any specific file name for a binary blob or any specific extension, to be able to easily find the\r\nbinary blob in the folder. Instead, they have determined the right binary blob through several conditions, that binary blob had\r\nto meet. This is also one of the defensive evasion techniques for attackers to make it harder for defenders to find the binary\r\nblob in the infected machine. \r\nThis stage represents the next stage in the execution chain, which is the third loader called RollMid which is also executed\r\nin the computer’s memory. \r\nBefore the execution of the RollMid loader, the malware creates two folders, named in the following way: \r\n%driveLetter%:\\\\ProgramData\\\\Package Cache\\\\[0-9A-Z]{8}-DF09-AA86-YI78-[0-9A-Z]{12}\\\\ \r\n%driveLetter%:\\\\ProgramData\\\\Package Cache\\\\ [0-9A-Z]{8}-09C7-886E-II7F-[0-9A-Z]{12}\\\\ \r\nThese folders serve as destinations for moving the binary blob, now renamed with a newly generated name and a \".cab\"\r\nextension. RollSling loader will store the binary blob in the first created folder, and it will store a new temporary file,\r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 3 of 9\n\nwhose usage will be mentioned later, in the second created folder.  \r\nThe attacker utilizes the \"Package Cache\" folder, a common repository for software installation files, to better hide its\r\nmalicious files in a folder full of legitimate files. In this approach, the attacker also leverages the \".cab\" extension, which\r\nis the usual extension for the files located in the Package Cache folder. By employing this method, the attacker is trying to\r\neffectively avoid detection by relocating essential files to a trusted folder. \r\nIn the end, the RollSling loader calls an exported function called \"StartAction\" . This function is called with specific\r\narguments, including information about the actual path of the RollFling loader, the path where the binary blob resides,\r\nand the path of a temporary file to be created by the RollMid loader. \r\nFigure 2: Looking for a binary blob in the same folder as the RollFling loader\r\nRollMid\r\nThe responsibility of the RollMid loader lies in loading key components of the attack and configuration data from the\r\nbinary blob, while also establishing communication with a C\u0026C server. \r\nThe binary blob, containing essential components and configuration data, serves as a critical element in the proper execution\r\nof the attack chain. Unfortunately, our attempts to obtain this binary blob were unsuccessful, leading to gaps in our full\r\nunderstanding of the attack. However, we were able to retrieve the RollMid loader and certain binaries stored in memory. \r\nWithin the binary blob, the RollMid loader is a fundamental component located at the beginning (see Figure 3). The first 4\r\nbytes in the binary blob describe the size of the RollMid loader. There are two more binaries stored in the binary blob after\r\nthe RollMid loader as well as configuration data, which is located at the very end of the binary blob. These two other\r\nbinaries and configuration data are additionally subject to compression and AES encryption, adding layers of security to the\r\nstored information.  \r\nAs depicted, the first four bytes enclosed in the initial yellow box describe the size of the RollMid loader. This specific\r\ninformation is also important for parsing, enabling the transition to the subsequent section within the binary blob. \r\nLocated after the RollMid loader, there are two 4-byte values, distinguished by yellow and green colors. The former\r\ncorresponds to the size of FIRST_ENCRYPTED_DLL section, while the latter (green box) signifies the size of\r\nSECOND_ENCRYPTED_DLL section. Notably, the second 4-byte value in the green box serves a dual purpose, not only\r\ndescribing a size but also at the same time constituting a part of the 16-byte AES key for decrypting the\r\nFIRST_ENCRYPTED_DLL section. Thanks to the provided information on the sizes of each encrypted DLL embedded in the\r\nbinary blob, we are now equipped to access the configuration data section placed at the end of the binary blob. \r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 4 of 9\n\nFigure 3: Structure of the Binary blob \r\nThe RollMid loader requires the FIRST_DLL_BINARY for proper communication with the C\u0026C server. However, before\r\nloading FIRST_DLL_BINARY , the RollMid loader must first decrypt the FIRST_ENCRYPTED_DLL section. \r\nThe decryption process applies the AES algorithm, beginning with the parsing of the decryption key alongside an\r\ninitialization vector to use for AES decryption. Subsequently, a decompression algorithm is applied to further extract the\r\ndecrypted content. Following this, the decrypted FIRST_DLL_BINARY is loaded into memory, and the DllMain function is\r\ninvoked to initialize the networking library. \r\nUnfortunately, as we were unable to obtain the binary blob, we didn’t get a chance to reverse engineer the\r\nFIRST_DLL_BINARY . This presents a limitation in our understanding, as the precise implementation details for the imported\r\nfunctions in the RollMid loader remain unknown. These imported functions include the following: \r\nSendDataFromUrl\r\nGetImageFromUrl  \r\nGetHtmlFromUrl\r\ncurl_global_cleanup\r\ncurl_global_init\r\nAfter reviewing the exported functions by their names, it becomes apparent that these functions are likely tasked with\r\nfacilitating communication with the C\u0026C server. FIRST_DLL_BINARY also exports other functions beyond these five, some\r\nof which will be mentioned later in this blog.  \r\nThe names of these five imported functions imply that FIRST_DLL_BINARY is built upon the curl library (as can be seen by\r\nthe names curl_global_cleanup and curl_global_init ). In order to establish communication with the C\u0026C servers, the\r\nRollMid loader employs the imported functions, utilizing HTTP requests as its preferred method of communication. \r\nThe rationale behind opting for the curl library for sending HTTP requests may stem from various factors. One notable\r\nreason could be the efficiency gained by the attacker, who can save time and resources by leveraging the HTTP\r\ncommunication protocol. Additionally, the ease of use and seamless integration of the curl library into the code further\r\nsupport its selection. \r\nPrior to initiating communication with the C\u0026C server, the malware is required to generate a dictionary filled with random\r\nwords, as illustrated in Figure 4 below. Given the extensive size of the dictionary (which contains approximately hundreds\r\nof elements), we have included only a partial screenshot for reference purposes. The subsequent sections of this blog will\r\ndelve into a comprehensive exploration of the role and application of this dictionary in the overall functionality of malware. \r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 5 of 9\n\nFigure 4: Filling the main dictionary \r\nTo establish communication with the C\u0026C server, as illustrated in Figure 5, the malware must obtain the initial C\u0026C\r\naddresses from the CONFIGURATION_DATA section. Upon decrypting these addresses, the malware initiates communication\r\nwith the first layer of the C\u0026C server through the GetHtmlFromUrl function, presumably using an HTTP GET request. The\r\nserver responds with an HTML file containing the address of the second C\u0026C server layer. Subsequently, the malware\r\nengages in communication with the second layer, employing the imported GetImageFromUrl function. The function name\r\nimplies this performs a GET request to retrieve an image. \r\nIn this scenario, the attackers employ steganography to conceal crucial data for use in the next execution phase. Regrettably,\r\nwe were unable to ascertain the nature of the important data concealed within the image received from the second layer of\r\nthe C\u0026C server. \r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 6 of 9\n\nFigure 5: Communication with C\u0026C servers \r\nWe are aware that the concealed data within the image serves as a parameter for a function responsible for transmitting data\r\nto the third C\u0026C server. Through our analysis, we have determined that the acquired data from the image corresponds to\r\nanother address of the third C\u0026C server.  Communication with the third C\u0026C server is initiated with a POST request.  \r\nMalware authors strategically employ multiple C\u0026C servers as part of their operational tactics to achieve specific\r\nobjectives. In this case, the primary goal is to obtain an additional data blob from the third C\u0026C server, as depicted in Figure\r\n5, specifically in step 7. Furthermore, the use of different C\u0026C servers and diverse communication pathways adds an\r\nadditional layer of complexity for security tools attempting to monitor such activities. This complexity makes tracking and\r\nidentifying malicious activities more challenging, as compared to scenarios where a single C\u0026C server is employed.\r\nThe malware then constructs a URL, by creating the query string with GET parameters (name/value pairs). The parameter\r\nname consists of a randomly selected word from the previously created dictionary and the value is generated as a random\r\nstring of two characters. The format is as follows: \r\n\"%addressOfThirdC\u0026C%?%RandomWordFromDictonary%=%RandomString%\"\r\nThe URL generation involves the selection of words from a generated dictionary, as opposed to entirely random strings. This\r\nintended choice aims to enhance the appearance and legitimacy of the URL. The words, carefully curated from the\r\ndictionary, contribute to the appearance of a clean and organized URL, resembling those commonly associated with\r\nauthentic applications. The terms such as \"atype\" , \"User\" ,” or \"type\" are not arbitrary but rather thoughtfully chosen\r\nwords from the created dictionary. By utilizing real words, the intention is to create a semblance of authenticity, making the\r\nHTTP POST payload appear more structured and in line with typical application interactions.  \r\nBefore dispatching the POST request to the third layer of the C\u0026C server, the request is populated with additional key-value\r\ntuples separated by standard delimiters “?” and “=” between the key and value. In this scenario, it includes: \r\n%RandomWordFromDictonary %=%sleep_state_in_minutes%?%size_of_configuration_data%\r\nThe data received from the third C\u0026C server is parsed. The parsed data may contain an integer, describing sleep interval, or\r\na data blob. This data blob is encoded using the base64 algorithm. After decoding the data blob, where the first 4 bytes\r\nindicate the size of the first part of the data blob, the remainder represents the second part of the data blob. \r\nThe first part of the data blob is appended to the SECOND_ENCRYPTED_DLL as an overlay, obtained from the binary blob. After\r\nsuccessfully decrypting and decompressing  SECOND_ENCRYPTED_DLL , the process involves preparing the\r\nSECOND_ENCRYPTED_DLL , which is a Remote Access Trojan (RAT) component to be loaded into memory and executed with\r\nthe specific parameters. \r\nThe underlying motivation behind this maneuver remains shrouded in uncertainty. It appears that the attacker, by choosing\r\nthis method, sought to inject a degree of sophistication or complexity into the process. However, from our perspective, this\r\napproach seems to border on overkill. We believe that a simpler method could have sufficed for passing the data blob to the\r\nKaolin RAT.  \r\nThe second part of the data blob, once decrypted and decompressed, is handed over to the Kaolin RAT component, while\r\nthe Kaolin RAT is executed in memory. Notably, the decryption key and initialization vector for decrypting the second\r\npart of the data blob reside within its initial 32 bytes.  \r\nKaolin RAT\r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 7 of 9\n\nA pivotal phase in orchestrating the attack involves the utilization of a Remote Access Trojan (RAT). As mentioned earlier,\r\nthis Kaolin RAT is executed in memory and configured with specific parameters for proper functionality. It stands as a\r\nfully equipped tool, including file compression capabilities.  \r\nHowever, in our investigation, the Kaolin RAT does not mark the conclusion of the attack. In the previous blog post, we\r\nalready introduced another significant component – the FudModule rootkit. Thanks to our robust telemetry, we can\r\nconfidently assert that this rootkit was loaded by the aforementioned Kaolin RAT, showcasing its capabilities to\r\nseamlessly integrate and deploy FudModule . This layered progression underscores the complexity and sophistication of the\r\noverall attack strategy. \r\nOne of the important steps is establishing secure communication with the RAT’s C\u0026C server, encrypted using the AES\r\nencryption algorithm. Despite the unavailability of the binary containing the communication functionalities (the RAT also\r\nrelies on functions imported from FIRST_DLL_BINARY for networking), our understanding is informed by other components\r\nin the attack chain, allowing us to make certain assumptions about the communication method. \r\nThe Kaolin RAT is loaded with six arguments, among which a key one is the base address of the network module DLL\r\nbinary, previously also used in the RollMid loader. Another argument includes the configuration data from the second part\r\nof the received data blob. \r\nFor proper execution, the Kaolin  RAT needs to parse this configuration data, which includes parameters such as: \r\nDuration of the sleep interval. \r\nA flag indicating whether to collect information about available disk drives. \r\nA flag indicating whether to retrieve a list of active sessions on the remote desktop. \r\nAddresses of additional C\u0026C servers. \r\nIn addition, the Kaolin RAT must load specific functions from FIRST_DLL_BINARY , namely: \r\nSendDataFromURL\r\nZipFolder\r\nUnzipStr  \r\ncurl_global_cleanup  \r\ncurl_global_init  \r\nAlthough the exact method by which the Kaolin RAT sends gathered information to the C\u0026C server is not precisely\r\nknown, the presence of exported functions like \"curl_global_cleanup\" and \"curl_global_init\" suggests that the\r\nsending process involves again API calls from the curl library. \r\nFor establishing communication, the Kaolin RAT begins by sending a POST request to the C\u0026C server. In this first\r\nPOST request, the malware constructs a URL containing the address of the C\u0026C server. This URL generation algorithm is\r\nvery similar to the one used in the RollMid loader. To the C\u0026C address, the Kaolin RAT appends a randomly chosen\r\nword from the previously created dictionary (the same one as in the RollMid loader) along with a randomly generated\r\nstring. The format of the URL is as follows: \r\n\"%addressOfC\u0026Cserver%?%RandomWordFromDictonary%=%RandomString%\"\r\nThe malware further populates the content of the POST request, utilizing the default \"application/x-www-form-urlencoded\" content type. The content of the POST request is subject to AES encryption and subsequently encoded with\r\nbase64. \r\nWithin the encrypted content, which is appended to the key-value tuples (see the form below), the following data is included\r\n(EncryptedContent) : \r\nInstallation path of the RollFling loader and path to the binary blob \r\nData from the registry key HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\r\nNT\\CurrentVersion\\Windows\\Iconservice \r\nKaolin RAT process ID \r\nProduct name and build number of the operating system. \r\nAddresses of C\u0026C servers. \r\nComputer name \r\nCurrent directory \r\nIn the POST request with the encrypted content, the malware appends information about the generated key and initialization\r\nvector necessary for decrypting data on the backend. This is achieved by creating key-value tuples, separated by “\u0026” and\r\n“=” between the key and value. In this case, it takes the following form: \r\n%RandomWordFromDictonary%=%TEMP_DATA%\u0026%RandomWordFromDictonary%=%IV%%KEY%\u0026%RandomWordFromDictonary%=%EncryptedContent%\u0026%RandomWordFromDi\r\nUpon successfully establishing communication with the C\u0026C server, the Kaolin RAT becomes prepared to receive\r\ncommands. The received data is encrypted with the aforementioned generated key and initialization vector and requires\r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 8 of 9\n\ndecryption and parsing to execute a specific command within the RAT. \r\nWhen the command is processed the Kaolin RAT relays back the results to the C\u0026C server, encrypted with the same AES\r\nkey and IV. This encrypted message may include an error message, collected information, and the outcome of the executed\r\nfunction. \r\nThe Kaolin RAT has the capability to execute a variety of commands, including: \r\nUpdating the duration of the sleep interval. \r\nListing files in a folder and gathering information about available disks. \r\nUpdating, modifying, or deleting files. \r\nChanging a file’s last write timestamp. \r\nListing currently active processes and their associated modules. \r\nCreating or terminating processes. \r\nExecuting commands using the command line. \r\nUpdating or retrieving the internal configuration. \r\nUploading a file to the C\u0026C server. \r\nConnecting to the arbitrary host. \r\nCompressing files. \r\nDownloading a DLL file from C\u0026C server and loading it in memory, potentially executing one of the following\r\nexported functions: \r\n_DoMyFunc\r\n_DoMyFunc2\r\n_DoMyThread (executes a thread)  \r\n_DoMyCommandWork  \r\nSetting the current directory.\r\nConclusion\r\nOur investigation has revealed that the Lazarus group targeted individuals through fabricated job offers and employed a\r\nsophisticated toolset to achieve better persistence while bypassing security products. Thanks to our robust telemetry, we\r\nwere able to uncover almost the entire attack chain, thoroughly analyzing each stage. The Lazarus group’s level of technical\r\nsophistication was surprising and their approach to engaging with victims was equally troubling. It is evident that they\r\ninvested significant resources in developing such a complex attack chain. What is certain is that Lazarus had to innovate\r\ncontinuously and allocate enormous resources to research various aspects of Windows mitigations and security products.\r\nTheir ability to adapt and evolve poses a significant challenge to cybersecurity efforts. \r\nIndicators of Compromise (IoCs) \r\nISO\r\nb8a4c1792ce2ec15611932437a4a1a7e43b7c3783870afebf6eae043bcfade30 \r\nRollFling\r\na3fe80540363ee2f1216ec3d01209d7c517f6e749004c91901494fb94852332b \r\nNLS files\r\n01ca7070bbe4bfa6254886f8599d6ce9537bafcbab6663f1f41bfc43f2ee370e\r\n7248d66dea78a73b9b80b528d7e9f53bae7a77bad974ededeeb16c33b14b9c56 \r\nRollSling\r\ne68ff1087c45a1711c3037dad427733ccb1211634d070b03cb3a3c7e836d210f\r\nf47f78b5eef672e8e1bd0f26fb4aa699dec113d6225e2fcbd57129d6dada7def \r\nRollMid\r\n9a4bc647c09775ed633c134643d18a0be8f37c21afa3c0f8adf41e038695643e \r\nKaolin RAT\r\na75399f9492a8d2683d4406fa3e1320e84010b3affdff0b8f2444ac33ce3e690 \r\nSource: https://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyb\r\ner-recruiting-scams/\r\nhttps://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://web.archive.org/web/20240418121020/https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/"
	],
	"report_names": [
		"from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams"
	],
	"threat_actors": [
		{
			"id": "34eea331-d052-4096-ae03-a22f1d090bd4",
			"created_at": "2025-08-07T02:03:25.073494Z",
			"updated_at": "2026-04-10T02:00:03.709243Z",
			"deleted_at": null,
			"main_name": "NICKEL ACADEMY",
			"aliases": [
				"ATK3 ",
				"Black Artemis ",
				"COVELLITE ",
				"CTG-2460 ",
				"Citrine Sleet ",
				"Diamond Sleet ",
				"Guardians of Peace",
				"HIDDEN COBRA ",
				"High Anonymous",
				"Labyrinth Chollima ",
				"Lazarus Group ",
				"NNPT Group",
				"New Romanic Cyber Army Team",
				"Temp.Hermit ",
				"UNC577 ",
				"Who Am I?",
				"Whois Team",
				"ZINC "
			],
			"source_name": "Secureworks:NICKEL ACADEMY",
			"tools": [
				"Destover",
				"KorHigh",
				"Volgmer"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "732597b1-40a8-474c-88cc-eb8a421c29f1",
			"created_at": "2025-08-07T02:03:25.087732Z",
			"updated_at": "2026-04-10T02:00:03.776007Z",
			"deleted_at": null,
			"main_name": "NICKEL GLADSTONE",
			"aliases": [
				"APT38 ",
				"ATK 117 ",
				"Alluring Pisces ",
				"Black Alicanto ",
				"Bluenoroff ",
				"CTG-6459 ",
				"Citrine Sleet ",
				"HIDDEN COBRA ",
				"Lazarus Group",
				"Sapphire Sleet ",
				"Selective Pisces ",
				"Stardust Chollima ",
				"T-APT-15 ",
				"TA444 ",
				"TAG-71 "
			],
			"source_name": "Secureworks:NICKEL GLADSTONE",
			"tools": [
				"AlphaNC",
				"Bankshot",
				"CCGC_Proxy",
				"Ratankba",
				"RustBucket",
				"SUGARLOADER",
				"SwiftLoader",
				"Wcry"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a2b92056-9378-4749-926b-7e10c4500dac",
			"created_at": "2023-01-06T13:46:38.430595Z",
			"updated_at": "2026-04-10T02:00:02.971571Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Operation DarkSeoul",
				"Bureau 121",
				"Group 77",
				"APT38",
				"NICKEL GLADSTONE",
				"G0082",
				"COPERNICIUM",
				"Moonstone Sleet",
				"Operation GhostSecret",
				"APT 38",
				"Appleworm",
				"Unit 121",
				"ATK3",
				"G0032",
				"ATK117",
				"NewRomanic Cyber Army Team",
				"Nickel Academy",
				"Sapphire Sleet",
				"Lazarus group",
				"Hastati Group",
				"Subgroup: Bluenoroff",
				"Operation Troy",
				"Black Artemis",
				"Dark Seoul",
				"Andariel",
				"Labyrinth Chollima",
				"Operation AppleJeus",
				"COVELLITE",
				"Citrine Sleet",
				"DEV-0139",
				"DEV-1222",
				"Hidden Cobra",
				"Bluenoroff",
				"Stardust Chollima",
				"Whois Hacking Team",
				"Diamond Sleet",
				"TA404",
				"BeagleBoyz",
				"APT-C-26"
			],
			"source_name": "MISPGALAXY:Lazarus Group",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "32a223a8-3c79-4146-87c5-8557d38662ae",
			"created_at": "2022-10-25T15:50:23.703698Z",
			"updated_at": "2026-04-10T02:00:05.261989Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Lazarus Group",
				"Labyrinth Chollima",
				"HIDDEN COBRA",
				"Guardians of Peace",
				"NICKEL ACADEMY",
				"Diamond Sleet"
			],
			"source_name": "MITRE:Lazarus Group",
			"tools": [
				"RawDisk",
				"Proxysvc",
				"BADCALL",
				"FALLCHILL",
				"WannaCry",
				"MagicRAT",
				"HOPLIGHT",
				"TYPEFRAME",
				"Dtrack",
				"HotCroissant",
				"HARDRAIN",
				"Dacls",
				"KEYMARBLE",
				"TAINTEDSCRIBE",
				"AuditCred",
				"netsh",
				"ECCENTRICBANDWAGON",
				"AppleJeus",
				"BLINDINGCAN",
				"ThreatNeedle",
				"Volgmer",
				"Cryptoistic",
				"RATANKBA",
				"Bankshot"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f32df445-9fb4-4234-99e0-3561f6498e4e",
			"created_at": "2022-10-25T16:07:23.756373Z",
			"updated_at": "2026-04-10T02:00:04.739611Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"APT-C-26",
				"ATK 3",
				"Appleworm",
				"Citrine Sleet",
				"DEV-0139",
				"Diamond Sleet",
				"G0032",
				"Gleaming Pisces",
				"Gods Apostles",
				"Gods Disciples",
				"Group 77",
				"Guardians of Peace",
				"Hastati Group",
				"Hidden Cobra",
				"ITG03",
				"Jade Sleet",
				"Labyrinth Chollima",
				"Lazarus Group",
				"NewRomanic Cyber Army Team",
				"Operation 99",
				"Operation AppleJeus",
				"Operation AppleJeus sequel",
				"Operation Blockbuster: Breach of Sony Pictures Entertainment",
				"Operation CryptoCore",
				"Operation Dream Job",
				"Operation Dream Magic",
				"Operation Flame",
				"Operation GhostSecret",
				"Operation In(ter)caption",
				"Operation LolZarus",
				"Operation Marstech Mayhem",
				"Operation No Pineapple!",
				"Operation North Star",
				"Operation Phantom Circuit",
				"Operation Sharpshooter",
				"Operation SyncHole",
				"Operation Ten Days of Rain / DarkSeoul",
				"Operation Troy",
				"SectorA01",
				"Slow Pisces",
				"TA404",
				"TraderTraitor",
				"UNC2970",
				"UNC4034",
				"UNC4736",
				"UNC4899",
				"UNC577",
				"Whois Hacking Team"
			],
			"source_name": "ETDA:Lazarus Group",
			"tools": [
				"3CX Backdoor",
				"3Rat Client",
				"3proxy",
				"AIRDRY",
				"ARTFULPIE",
				"ATMDtrack",
				"AlphaNC",
				"Alreay",
				"Andaratm",
				"AngryRebel",
				"AppleJeus",
				"Aryan",
				"AuditCred",
				"BADCALL",
				"BISTROMATH",
				"BLINDINGCAN",
				"BTC Changer",
				"BUFFETLINE",
				"BanSwift",
				"Bankshot",
				"Bitrep",
				"Bitsran",
				"BlindToad",
				"Bookcode",
				"BootWreck",
				"BottomLoader",
				"Brambul",
				"BravoNC",
				"Breut",
				"COLDCAT",
				"COPPERHEDGE",
				"CROWDEDFLOUNDER",
				"Castov",
				"CheeseTray",
				"CleanToad",
				"ClientTraficForwarder",
				"CollectionRAT",
				"Concealment Troy",
				"Contopee",
				"CookieTime",
				"Cyruslish",
				"DAVESHELL",
				"DBLL Dropper",
				"DLRAT",
				"DRATzarus",
				"DRATzarus RAT",
				"Dacls",
				"Dacls RAT",
				"DarkComet",
				"DarkKomet",
				"DeltaCharlie",
				"DeltaNC",
				"Dembr",
				"Destover",
				"DoublePulsar",
				"Dozer",
				"Dtrack",
				"Duuzer",
				"DyePack",
				"ECCENTRICBANDWAGON",
				"ELECTRICFISH",
				"Escad",
				"EternalBlue",
				"FALLCHILL",
				"FYNLOS",
				"FallChill RAT",
				"Farfli",
				"Fimlis",
				"FoggyBrass",
				"FudModule",
				"Fynloski",
				"Gh0st RAT",
				"Ghost RAT",
				"Gopuram",
				"HARDRAIN",
				"HIDDEN COBRA RAT/Worm",
				"HLOADER",
				"HOOKSHOT",
				"HOPLIGHT",
				"HOTCROISSANT",
				"HOTWAX",
				"HTTP Troy",
				"Hawup",
				"Hawup RAT",
				"Hermes",
				"HotCroissant",
				"HotelAlfa",
				"Hotwax",
				"HtDnDownLoader",
				"Http Dr0pper",
				"ICONICSTEALER",
				"Joanap",
				"Jokra",
				"KANDYKORN",
				"KEYMARBLE",
				"Kaos",
				"KillDisk",
				"KillMBR",
				"Koredos",
				"Krademok",
				"LIGHTSHIFT",
				"LIGHTSHOW",
				"LOLBAS",
				"LOLBins",
				"Lazarus",
				"LightlessCan",
				"Living off the Land",
				"MATA",
				"MBRkiller",
				"MagicRAT",
				"Manuscrypt",
				"Mimail",
				"Mimikatz",
				"Moudour",
				"Mydoom",
				"Mydoor",
				"Mytob",
				"NACHOCHEESE",
				"NachoCheese",
				"NestEgg",
				"NickelLoader",
				"NineRAT",
				"Novarg",
				"NukeSped",
				"OpBlockBuster",
				"PCRat",
				"PEBBLEDASH",
				"PLANKWALK",
				"POOLRAT",
				"PSLogger",
				"PhanDoor",
				"Plink",
				"PondRAT",
				"PowerBrace",
				"PowerRatankba",
				"PowerShell RAT",
				"PowerSpritz",
				"PowerTask",
				"Preft",
				"ProcDump",
				"Proxysvc",
				"PuTTY Link",
				"QUICKRIDE",
				"QUICKRIDE.POWER",
				"Quickcafe",
				"QuiteRAT",
				"R-C1",
				"ROptimizer",
				"Ratabanka",
				"RatabankaPOS",
				"Ratankba",
				"RatankbaPOS",
				"RawDisk",
				"RedShawl",
				"Rifdoor",
				"Rising Sun",
				"Romeo-CoreOne",
				"RomeoAlfa",
				"RomeoBravo",
				"RomeoCharlie",
				"RomeoCore",
				"RomeoDelta",
				"RomeoEcho",
				"RomeoFoxtrot",
				"RomeoGolf",
				"RomeoHotel",
				"RomeoMike",
				"RomeoNovember",
				"RomeoWhiskey",
				"Romeos",
				"RustBucket",
				"SHADYCAT",
				"SHARPKNOT",
				"SIGFLIP",
				"SIMPLESEA",
				"SLICKSHOES",
				"SORRYBRUTE",
				"SUDDENICON",
				"SUGARLOADER",
				"SheepRAT",
				"SierraAlfa",
				"SierraBravo",
				"SierraCharlie",
				"SierraJuliett-MikeOne",
				"SierraJuliett-MikeTwo",
				"SimpleTea",
				"SimplexTea",
				"SmallTiger",
				"Stunnel",
				"TAINTEDSCRIBE",
				"TAXHAUL",
				"TFlower",
				"TOUCHKEY",
				"TOUCHMOVE",
				"TOUCHSHIFT",
				"TOUCHSHOT",
				"TWOPENCE",
				"TYPEFRAME",
				"Tdrop",
				"Tdrop2",
				"ThreatNeedle",
				"Tiger RAT",
				"TigerRAT",
				"Trojan Manuscript",
				"Troy",
				"TroyRAT",
				"VEILEDSIGNAL",
				"VHD",
				"VHD Ransomware",
				"VIVACIOUSGIFT",
				"VSingle",
				"ValeforBeta",
				"Volgmer",
				"Vyveva",
				"W1_RAT",
				"Wana Decrypt0r",
				"WanaCry",
				"WanaCrypt",
				"WanaCrypt0r",
				"WannaCry",
				"WannaCrypt",
				"WannaCryptor",
				"WbBot",
				"Wcry",
				"Win32/KillDisk.NBB",
				"Win32/KillDisk.NBC",
				"Win32/KillDisk.NBD",
				"Win32/KillDisk.NBH",
				"Win32/KillDisk.NBI",
				"WinorDLL64",
				"Winsec",
				"WolfRAT",
				"Wormhole",
				"YamaBot",
				"Yort",
				"ZetaNile",
				"concealment_troy",
				"http_troy",
				"httpdr0pper",
				"httpdropper",
				"klovbot",
				"sRDI"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434887,
	"ts_updated_at": 1775792300,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e71dd9a1927a199295797ed01c16432d6d873700.pdf",
		"text": "https://archive.orkl.eu/e71dd9a1927a199295797ed01c16432d6d873700.txt",
		"img": "https://archive.orkl.eu/e71dd9a1927a199295797ed01c16432d6d873700.jpg"
	}
}