{
	"id": "7eeb4b4d-d1ee-4194-aae5-fc66a7c03262",
	"created_at": "2026-04-06T00:07:54.534453Z",
	"updated_at": "2026-04-10T13:12:36.164798Z",
	"deleted_at": null,
	"sha1_hash": "dcd432c8c4cbcc6137ec96b9761cf07b5ade0daf",
	"title": "TOITOIN Trojan: A New Multi-Stage Attack Targeting LATAM",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3268326,
	"plain_text": "TOITOIN Trojan: A New Multi-Stage Attack Targeting LATAM\r\nBy Niraj Shivtarkar, Preet Kamal\r\nPublished: 2023-07-07 · Archived: 2026-04-05 21:17:58 UTC\r\nAnalysis Of The Multi-Staged TOITOIN Infection Chain\r\nStage-1: Downloader module\r\nExamination of the TOITOIN downloader module reveals its intricate operations, including string decryption routines,\r\npath retrieval, log file creation, and the selection of random file names. Understanding the string decryption process\r\nemployed by malware is vital for defenders as it enables them to detect encrypted or obfuscated strings, analyze the\r\nattack, attribute it to specific threat actors, respond effectively, and develop mitigation strategies. The findings in this\r\nsection shed light on the downloader module's functionalities and provide valuable insights into the overall execution\r\nflow of the TOITOIN malware.\r\nDuring the analysis of the malware, specific attention was given to the downloader module. The path to the module's\r\nProgram Database (PDB) file was identified as\r\n\"F:\\Trabalho_2023\\OFF_2023\\LOAD_APP_CONSOLE_C_PLUS\\LOAD\\x64\\Release\\NAME.pdb.\"\r\nUpon execution, the downloader module initiates a String Decryption routine. Initially, the encrypted hex strings are\r\nconcatenated in reverse order, employing multiple heap allocations. The resulting concatenated encrypted hex string is\r\nthen passed as an argument to the decryption routine, as depicted in Figure 5 below.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 1 of 16\n\nFigure 5 - Illustrates the String decryption routine, showcasing the concatenation process.\r\nIn the decryption routine, the encrypted hex string undergoes a series of operations. Firstly, the string is reversed, and\r\nsubsequently, an XOR operation is performed between the N and N+1 byte, where N is incremented by 2 for each\r\noperation. To facilitate this process, a string decryptor was developed (Code: Appendix A) specifically for the string\r\ndecryption routine. Utilizing this string decryptor, the final concatenated encrypted hex string can be decrypted, revealing\r\na decrypted string in the pattern of \"@1-55: .\" Each of these encrypted hex strings is then individually decrypted using\r\nthe same string decryption function, based on the specific index value passed to the function according to the\r\nrequirements. Figure 6 shows the decryption of the encrypted hex strings using the string decryptor.\r\nFigure 6 - Overview of the string decryption routine, focusing on the decryption of the downloader URL.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 2 of 16\n\nOnce decrypted, the downloader module retrieves the paths to the 'Appdata', 'HomeDrive', and 'Username' of the\r\ninfected system by calling the getenv() function, with the decrypted strings \"appdata, homedrive, username\" as\r\narguments. The module then proceeds to create a log file named \".log\" within the \"AppData/Roaming\" directory. The\r\ncomputer name is obtained by invoking the GetComputerNameA() function.\r\nAdditionally, the downloader module selects a random file name from a collection of encrypted hex strings, shown below\r\nin Figure 7. These file names are decrypted dynamically using the same string decryption routine. The chosen file name is\r\nassigned to a signed executable responsible for sideloading the Krita Loader DLL. Further analysis of this process is\r\npresented in the subsequent sections.\r\nFigure 7 - Showcases a list of randomly generated file names.\r\nOnce a file name is selected, the downloader module proceeds to create a batch script in the temp directory with a\r\ndynamically generated name. The necessary information for the batch script, including the path to the temp directory,\r\nextensions, and content, is decrypted using the string decryption routine.\r\nUpon execution, the batch script writes and executes a VBScript within the temp directory. The VBScript, in turn, creates\r\na shortcut (.LNK) file in the startup folder. The name of the shortcut file, \"icepdfeditor.lnk,\" is dynamically set to the\r\npreviously selected random file name from the list. The TargetPath of the shortcut file is assigned as\r\n\"C:\\Users\\Public\\Documents\\knight\\icepdfeditor.exe,\" with the file name again set to the random selection from the\r\nlist. The VBScript, identified as \"rnTiucm.vbs,\" is subsequently deleted towards the end of this process.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 3 of 16\n\nFigure 8 - Batch script creating LNK file in the StartUp folder for persistence.\r\nThe above figure illustrates the batch script's creation of an LNK file in the StartUp folder, ensuring persistence on the\r\ncompromised machine. By placing the \"icepdfeditor.lnk\" shortcut in the StartUp folder, it executes every time the\r\nsystem restarts, subsequently launching \"icepdfeditor.exe\" in the Public Documents folder.\r\nFollowing this, the downloader module initiates the downloading routine, decrypting URLs dynamically using the string\r\ndecryption process, as shown in Figure 9 below. \r\nFigure 9 - String decryption routine (downloader URLs).\r\nThen in Figure 10 demonstrates the use of InternetOpenUrlA() and InternetReadFile() functions to retrieve encrypted\r\ndata containing multiple payloads for this complex attack, disguised here as mp3 files from the URL:\r\nhttp[:]//cartolabrasil[.]com/Homicidio[.]mp3/1-6.mp3.\r\nFigure 10 - Downloading multiple payloads from http[:]cartolabrasil.com.\r\nThe encrypted data is decrypted and reversed, and the resulting payloads are written to a newly created folder within the\r\nPublic Documents directory, as depicted in Figure 11.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 4 of 16\n\nFigure 11 - Multiple payloads downloaded in the public documents folder.\r\nIn Figure 11, it can also be observed that the encrypted payloads have dynamically generated filenames based on the\r\ncomputer name, username, etc.. The Loader DLL, \"ffmpeg.dll,\" has its filename decrypted using the string decryption\r\nprocess. The signed binary, \"icepdfeditor,\" is randomly selected from the list of file names dynamically, and the\r\nextensions are decrypted accordingly. Additionally, the downloader creates a configuration file with the ini extension\r\nnamed after the computer name in the Public Documents folder, containing details about the encrypted payloads.\r\nTowards the end of this process, the downloader generates a batch script in the \"AppData\\Roaming\" directory, named\r\nafter the computer name. Upon execution, this script restarts the system after a 10-second timeout, as depicted in Figure\r\n12 below. The content of the batch script is decrypted using the string decryption function.\r\nFigure 12 - Evades sandbox \u0026 executes the LNK file in the startup folder by restarting the system.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 5 of 16\n\nThe system reboot serves to evade sandbox detection since the malicious actions occur only after the reboot. Upon\r\nrestarting, the shortcut (.LNK) file, \"icepdfeditor.lnk,\" in the startup folder is automatically executed, triggering the\r\nexecution of \"icepdfeditor.exe\" from the Public Documents folder. \"icepdfeditor.exe\" is a valid signed executable by\r\n\"ZOHO Corporation Private Limited,\" downloaded alongside the other payloads. Figure 13 shows the execution of\r\n\"icepdfeditor.exe.\"\r\nFigure 13 - Signed binary by ZOHO Corporation downloaded alongside malicious payloads.\r\nUpon final execution, the signed binary, \"icepdfeditor.exe,\" sideloads the malicious Krita Loader DLL, \"ffmpeg.dll,\"\r\nfrom the current directory \"C:\\Users\\Public\\Documents\\\\\" taking advantage of the Windows Search and Load order to\r\nload the malicious Loader DLL instead of the legitimate DLL, as illustrated in Figure 14.\r\nFigure 14 - Signed Binary “icepdfeditor.exe” sideloads the malicious Krita Loader DLL “ffmpeg.dll”.\r\nStage-2: Krita Loader DLL (ffmpeg.dll)\r\nPDB Path: F:\\Trabalho_2023\\OFF_2023\\DLL_Start_OK\\x64\\Release\\DLL_Start_OK.pdb\r\nIn the analysis of the Krita Loader DLL (ffmpeg.dll), it is observed that the DLL reads encoded data from the .jpg file.\r\nThis encoded data is then dynamically reversed and decoded using a replacement routine. The replacement routine\r\nreplaces special characters with specific characters based on an algorithm, for example, replacing \"!\" with \"A\".\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 6 of 16\n\nFigure 15 - Showcases the decoding process of the DLL, involving reverse and replace functions.\r\nAs depicted in the preceding screenshot, the data is subsequently subjected to base64 decoding, resulting in the formation\r\nof a PE file. This PE file is then written to the temporary directory, utilizing a randomly generated file name, as illustrated\r\nin Figure 16.\r\nFigure 16 - Demonstrates the process of decoding the DLL through Base64 decoding.\r\nSubsequently, the decoded InjectorDLL is loaded into memory by the Krita Loader DLL using the LoadLibraryA()\r\nfunction. Control is then transferred by retrieving the address of the export function \"TEMP\" through the\r\nGetProcAddress() function.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 7 of 16\n\nFigure 17 - Illustrates the loading of the InjectorDLL via the LoadLibraryA() function.\r\nStage-3: InjectorDLL Module\r\nPDB Path: F:\\Trabalho_2023\\OFF_2023\\DLL_Start_IN\\x64\\Release\\DLL_START_IN.pdb\r\nOnce the InjectorDLL is loaded, it proceeds to read encoded data from another .jpg file. Similar to the Krita Loader\r\nDLL, the InjectorDLL dynamically reverses and decodes the data using a replacement routine that replaces special\r\ncharacters with specific characters based on a predefined algorithm. Subsequently, the data undergoes base64 decoding,\r\nresulting in the formation of the ElevateInjectorDLL module. This module is then injected into the remote process\r\n\"explorer.exe\" using a sequence of functions: OpenProcess, VirtualAllocEx, WriteProcessMemory, and\r\nCreateRemoteThread. The screenshot shown in Figure 18 below illustrates this injection process.\r\nFigure 18 - Demonstrates the injection of the ElevateInjectorDLL module into the remote process \"explorer.exe.\"\r\nStage-4: ElevateInjectorDLL Module\r\nPDB Path: F:\\Trabalho_2023\\OFF_2023\\DLL_Start_UP\\x64\\Release\\DLL_Start_UP.pdb\r\nOnce injected into the explorer.exe process, the ElevateInjectorDLL module performs initial checks. It verifies whether\r\nthe parent process is either \"explorer.exe\" or \"winlogon.exe\" and checks if the mutex \"explorer\" or \"winlogon\" has\r\nalready been created using the OpenMutexA() function. If the conditions are met, the module creates the mutex\r\n\"explorer\" or \"winlogon\" based on the parent process as shown in Figure 19 below. Subsequently, it executes the main\r\nroutine to carry out further actions.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 8 of 16\n\nFigure 19 - Showcases the process of checking the parent process, specifically verifying if it is either \"explorer\" or\r\n\"winlogon\".\r\nThis technique ensures that the module evades sandboxes by verifying the parent process. If the parent process does not\r\nmatch the expected value, the malicious code remains dormant and is not executed.\r\nIn this particular scenario, as the parent process is \"explorer.exe,\" the main routine is executed. Within this routine,\r\nspecific strings are base64 decoded. These strings contain the server address (191[.]252[.]203[.]222/Up/indexW.php) and\r\nthe paths of the target processes (explorer.exe and svchost.exe) where the subsequent injection stages will take place.\r\nAdditionally, the ElevateInjectorDLL checks whether the process is elevated. In this case, as the process is not elevated,\r\nthe DLL reads and decrypts another JPG file from the Public Documents folder. This decryption process forms the next\r\nstage module called \"BypassUAC.\" Subsequently, the module performs process hollowing to inject the BypassUAC\r\nmodule into another explorer.exe process that was previously spawned in a suspended state.\r\nFigure 20 - Demonstrates the injection of the BypassUAC module into the explorer.exe process when the process is not\r\nelevated.\r\nStage-5: BypassUAC Module\r\nPDB Path: F:\\\\Trabalho_2023\\\\OFF_2023\\\\EXE_BypassUAC\\\\x64\\\\Release\\\\BypassUAC.pdb\r\nThe BypassUAC Module is responsible for performing User Account Control (UAC) bypass, enabling the execution of\r\nthe Downloader module with administrator privileges.\r\nWhen the previously injected BypassUAC Module is executed within the remote process explorer.exe, it exits without\r\nexecuting the main routine under two conditions. Firstly, if the mutex \"explorer\" is not created, and secondly, if the\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 9 of 16\n\nmutex \"bypass\" is already created. However, if these conditions are not met, the module proceeds to create the \"bypass\"\r\nmutex before continuing its execution.\r\nFigure 21 - Depicts the process of opening and creating mutexes.\r\nIn the context of UAC bypass, the malware leverages the COM Elevation Moniker \"Elevation:Administrator!new:\"\r\nalong with specific elevated COM Objects. The purpose is to bypass the User Account Control (UAC) restrictions and\r\ngain elevated privileges on the system. To achieve this, the malware utilizes the CLSID {3AD05575-8857-4850-9277-\r\n11B85BDB8E09}, which provides functionalities related to copy, move, rename, delete, and link operations.\r\nAdditionally, the CLSID {BDB57FF2-79B9-4205-9447-F5FE85F37312} is employed, specifically designed for the\r\ninstallation of Internet Explorer add-ons. By exploiting these elevated COM Objects, the malware aims to elevate its\r\nprivileges and carry out malicious activities without being hindered by UAC restrictions.\r\nFigure 22 - Illustrates the UAC bypass technique achieved through the use of the COM Elevation Moniker.\r\nIn the process of UAC bypass, the malware utilizes the Copy/Move/Rename/Delete/Link COM Object. This COM Object\r\nserves the purpose of copying the \"cmd.exe\" file from the System32 Folder to the Temp directory with administrator\r\nprivileges. The copied file is then renamed as [1]bdeunlock.exe. This technique allows the malware to manipulate system\r\nfiles and execute commands with elevated privileges, facilitating further malicious activities.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 10 of 16\n\nFigure 23 - Depicts the operation of copying the \"cmd.exe\" file into the Temp directory with administrator privileges\r\nusing a COM Object.\r\nMoreover, the auto-elevating Internet Explorer Add-on Installer, known as \"IEInstal.exe,\" is triggered through the COM\r\nObject. This action aims to execute the signed binary \"icepdfeditor.exe\" with elevated privileges by spawning a new\r\nprocess named [1]bdeunlock.exe. The process is launched with specific arguments, namely \"/C start ,\" as indicated in\r\nFigure 24. This technique allows the malware to execute the signed binary with elevated permissions, enabling it to carry\r\nout malicious activities on the system.\r\nFigure 24 - Demonstrates the UAC bypass executed by the Internet Explorer Add-On Installer. This bypass enables the\r\nexecution of the Krita Loader DLL with elevated privileges.\r\nConsequently, the signed binary is executed with elevated privileges, facilitating the sideloading of the Krita Loader DLL\r\nonto the machine with administrative privileges.\r\nOnce the Krita Loader DLL is sideloaded with elevated privileges, it follows the same routine as previously discussed.\r\nHowever, in this instance, the ElevateInjectorDLL module, which previously injected the BypassUAC module, verifies\r\nwhether it has elevated privileges. If elevated privileges are present, the module decrypts the final TOITOIN Trojan and\r\ninjects it into the remote process \"svchost.exe,\" as depicted in the screenshot provided in Figure 25 below.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 11 of 16\n\nFigure 25 - Displays the injection of the TOITOIN Trojan into the svchost.exe process.\r\nStage-6: TOITOIN Trojan\r\nThe ElevateInjectorDLL injects the new Latin American Trojan, TOITOIN, into the remote process \"svchost.exe.\"\r\nUpon execution, the Trojan first reads the encoded .ini configuration file that was previously written in the Public\r\nDocuments folder by the Downloader module, as the captured screenshot in Figure 26 below shows.\r\nFigure 26 - Demonstrates the process of reading the INI configuration file.\r\nBelow, Figure 27 reveals the decoding process of the hex blob within the INI Configuration file. The hex blob is reversed\r\nand converted to ASCII format, unveiling its original content.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 12 of 16\n\nFigure 27 - Showcases the decoding process of the INI Configuration File.\r\nEach of the # hex strings undergoes further decoding using the same logic. In the Figure 28 screenshot below, the\r\ndecoded #1 hex string reveals the complete path and file name of the multiple payloads that were downloaded by the\r\nDownloader from http[:]//cartolabrasil[.]com.\r\nFigure 28 - Depicts the continued decoding process of the INI Configuration File.\r\nAdditionally, the #3 hex blob undergoes decoding using the aforementioned logic, resulting in another hex blob. This hex\r\nblob is then decrypted using a custom XOR logic, such as applying the XOR operation with the first two bytes (0D44 -\u003e\r\n(0x44 ^ 0x31) - 0x0D = \"h\"). ThreatLabz researchers developed a decryptor specifically for the INI Configuration file,\r\nas shown below in Figure 29.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 13 of 16\n\nFigure 29 - Showcases the INI Configuration Decryptor, which reveals the Command \u0026 Control (C\u0026C) URL.\r\nIn Figure 29, the decrypted value extracted from the INI Configuration file reveals the Command \u0026 Control (C\u0026C) URL:\r\nhttp[:]//afroblack[.]shop/CasaMoveis. However, during the analysis of a different corrected sample, a distinct C\u0026C\r\nserver was discovered: http[:]//contabilidademaio[.]servebeer[.]com/Robs/counter.\r\nThe final backdoor decrypts various strings, including C\u0026C URLs and other crucial information, using a custom XOR\r\ndecryption logic based on the INI configuration values of \"1\" or \"2\":\r\n5EBCDD2160A3E060F95B, 4644454647484786DF61 - /0202.php\r\nB9D91B5B9FC2C1035AFB, 07076684E60A094881C0 - /POST.php\r\n4980C50B4AB5D534A72BBD144483D7084A9D21B3164E8B88DA7BD9,\r\nD40CB117B6C1C1C115B629A13291C516B82AAD3E80D87493C70642 - http[:]//bragancasbrasil[.]com\r\n37AE12B71962A0FE01097390F01861BEC0C9C6CC - http://179[.]188[.]38[.]7\r\n1D7E85858489898A8B8C8E87EA0B6588E6017E96, 95F61C7A9BFE1F60A1E2277EE3027AFF7EF674AC -\r\n26/04/2023(TOITOIN)\r\nSome of the decrypted strings include paths to payloads, browser installations, and relevant dates.\r\nAdditionally, a substantial encrypted hex blob is decrypted using the same custom XOR decryption logic. This hex blob\r\nconsists of strings related to file paths, browser types, and timestamps. The TOITOIN Trojan employs these decrypted\r\nstrings in its operation:\r\n@36:C91756F9588E30A03F6E85DF7DD376E3094988D862B33249BC284E9E20A2359DC81DBD0157B42B92C6\r\n- \\Program Files\\Topaz OFD\\Warsaw\\core.exe\r\n@37:86D025A529BF2C - [Core]\r\n@38:5F8BF014BD2A - [64x]\r\n@39:204A4C4FF665 - [32x]\r\n@45:679F3E9C3590C41062FB5FFF5CF07C - Google\\Chrome\\\r\n@46:314F8F3B9533AE217087C1055BF051F864FB54F76CE362EB2BA12BA1 - Mozilla Firefox\\firefox.exe\r\n@47:748CCB71E76BE87FC2D3289133AE2F90C406538DC30D4C89C90D4340943C90 -  Internet\r\nExplorer\\iexplore.exe\r\n@48:1051F2538BCC1FBD006D8DCC034494C11FB116B528A13699F66DD40B -\r\nPrograms\\Opera\\launcher.exe\r\n@49:5C9D21A1389BCD0A4C99D97BD175E775D577ED518380D47CD0 - Programs\\Opera\\opera.exe\r\n@50:47A53E9032903595CA0E5B91C41DB32153F2528FC91C4CF16AE866F350F269FC558B88DC64F8 -\r\nMicrosoft\\Edge\\Application\\msedge.exe\r\n@51:AB364E82CB0D4886C91EA1CF - [Iexplorer]\r\n@52:1541B52F9031AF24B0 - [Chrome]\r\n@53:2EB8379723AC27A235A3 - [Mozzila]\r\n@54:5F8BEB6DE367F966 - [Opera]\r\n@55:5882F66AE077E5 - [Edge]\r\nThe Trojan fetches the Windows version by querying the ProductName registry key value, retrieves the environment\r\nvariable %homedrive% and the path to the Program Files directory, and determines whether the system is 32-bit or 64-\r\nbit.\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 14 of 16\n\nBased on the installed browsers, including Chrome, Edge, Opera, Mozilla Firefox, and Internet Explorer, the Trojan\r\nassigns specific values to each browser. It also checks for the presence of the Topaz OFD - Protection Module at the\r\nspecified path and sets the value \"[Core]\" accordingly.\r\nFurthermore, another encrypted hex blob is decrypted, containing strings related to certain variables, such as\r\nClienteD.php?1=, - (hyphen), Versao_DLL(, Data(, dd/mm/yyyy, and hh:mm:ss:\r\n@36:F5639735AF24A329BF3552F36DEC1D7F8D - \\ClienteD.php?1=\r\n@37:77A6E232 -  -\r\n@38:D7C6C2D31BB115B92AA8394CA9C4DD -  Versao_DLL(\r\n@39:2170ACFD73E56BFD17 - Data(\r\n@40:F266FB1AB61575DF68D07B - dd/mm/yyyy\r\n@41:EB65FC06429EE96CEE - hh:mm:ss\r\nLeveraging these decrypted strings, the Trojan assigns values to variables like AA1, AA2, AA3 \u0026 AA4, AA5, and AA10,\r\nusing the previously decrypted encoded format. For example, AA1 represents the computer name, AA2 represents the\r\nWindows version, AA3 \u0026 AA4 represent the installed browsers, AA5 represents the bit value (32x or 64x), and AA10\r\nrepresents the date (26/04/2023, in this case).\r\nAA1 - 0393948384C453D205F445B4355444 --\u003e DESKTOP-******* (Computer Name)\r\nAA2 - E6F696471636574654020313023777F646E69675 --\u003e Windows 10 Education (Windows Version)\r\nAA3 \u0026 AA4 - D556764654B5D5275627F6C607875694B5 --\u003e [Iexplorer][Edge] (Installed browsers \u0026 protection\r\nmodule)\r\nAA5 - D5874363B5 --\u003e [64x] (Bit)\r\nAA10 - 92E494F44594F4458233230323F24303F26323 --\u003e 26/04/2023(TOITOIN)\r\nAnalyzing and understanding these decrypted strings allows for a better understanding of the TOITOIN Trojan's\r\nconfiguration, the system it operates on, and the communication channels it utilizes for command and control.\r\nTOITOIN utilizes the decrypted strings in the following manner in order to gather the system \u0026 browser information:\r\n1. It fetches the Windows version by querying the ProductName value from the registry key:\r\nSOFTWARE\\Microsoft\\Windows NT\\CurrentVersion.\r\n2. It retrieves the environment variable %homedrive% using GetEnvironmentVariableW, which usually corresponds\r\nto the C:\\ drive.\r\n3. It determines whether the system is 32-bit or 64-bit and sets the value to [64x] or [32x] accordingly.\r\n4. It checks if specific web browsers are installed on the system by verifying the existence of corresponding folders and\r\nfiles. The checked browsers include Chrome, Edge, Opera, Mozilla Firefox, and Internet Explorer.\r\n5. Based on the installed browsers, it assigns specific values for each browser:\r\n[Iexplorer] for Internet Explorer\r\n[Chrome] for Chrome\r\n[Mozzila] for Mozilla Firefox\r\n[Opera] for Opera\r\n[Edge] for Microsoft Edge\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 15 of 16\n\n6. It checks whether the Topaz OFD - Protection Module is installed at the path \\Program Files\\Topaz\r\nOFD\\Warsaw\\core.exe. If the module exists, it sets the value \"[Core]\".\r\nBy leveraging these decrypted strings and performing these checks, the TOITOIN Trojan adapts its behavior based on the\r\nsystem's Windows version, installed browsers, and the presence of the Topaz OFD - Protection Module.\r\nSource: https://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nhttps://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region"
	],
	"report_names": [
		"toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region"
	],
	"threat_actors": [],
	"ts_created_at": 1775434074,
	"ts_updated_at": 1775826756,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dcd432c8c4cbcc6137ec96b9761cf07b5ade0daf.pdf",
		"text": "https://archive.orkl.eu/dcd432c8c4cbcc6137ec96b9761cf07b5ade0daf.txt",
		"img": "https://archive.orkl.eu/dcd432c8c4cbcc6137ec96b9761cf07b5ade0daf.jpg"
	}
}