{ "id": "a90d02e8-a6f2-44fd-ae9a-d61fbfe8d2b2", "created_at": "2026-04-06T00:17:42.346491Z", "updated_at": "2026-04-10T03:38:03.300041Z", "deleted_at": null, "sha1_hash": "a7824688095cb4181cb50e8120885ad9f442737f", "title": "“Hey ESET, Wait for the Leak”: Dissecting the “OctoberSeventh” Wiper targeting ESET customers in Israel – Emanuele De Lucia", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1779352, "plain_text": "“Hey ESET, Wait for the Leak”: Dissecting the “OctoberSeventh”\r\nWiper targeting ESET customers in Israel – Emanuele De Lucia\r\nBy edelucia\r\nPublished: 2024-10-19 · Archived: 2026-04-05 18:25:31 UTC\r\nOn October 2024, attackers targeted Israeli organizations by exploiting a trusted source: ESET’s local partner,\r\nComsecure. Apparently they compromised Comsecure’s infrastructure and used it to send phishing emails\r\ndisguised as official communications from ESET.\r\nThese emails contained a malicious download link purported to be a legitimate tool but actually housed wiper\r\nmalware (I internally named OctoberSeventh) designed to disrupt data from victim systems.\r\nWhat makes this attack particularly interesting is the exploitation of an established partner of a globally trusted\r\ncybersecurity firm, leveraging the inherent trust that customers place in such relationships. By embedding wiper\r\nmalware in files that appeared coming from ESET, the attackers succeeded in distributing a destructive payload\r\nunder the guise of a routine security update.\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 1 of 6\n\nPhishing email sample\r\nThe motivation behind this attack appears to be geopolitically driven, given its exclusive focus on Israeli entities\r\nduring a time of heightened regional tension. In my opinion it illustrates the evolving sophistication of cyber\r\nthreat actors who not only rely on advanced malware but also on sophisticated social engineering and supply chain\r\ninfiltration techniques.\r\nINSIGHTS\r\nI tried to have a quick look to the code; the malware employs several self-defense mechanisms designed to thwart\r\nanalysis attempts. Their core purpose is to identify if the malware is being executed within a debugger and, if so,\r\nto trigger a controlled crash, effectively terminating the analysis session and hiding its malicious behavior.\r\nIt first probes the CPU’s capabilities, using IsProcessorFeaturePresent to determine if the __fastfail instruction\r\nis supported. This instruction, a low-level mechanism for triggering fast fail exceptions, provides a rapid method\r\nfor terminating a program. If the CPU supports __fastfail, the malware immediately utilizes it, causing an abrupt\r\nhalt to its execution and hindering any debugger’s ability to follow the code’s flow.\r\nIf the CPU does not support __fastfail, the malware resorts to a more direct approach, explicitly checking for a\r\ndebugger’s presence using the IsDebuggerPresent function. This Windows API function returns a clear indication\r\nof whether a debugger is attached to the malware’s process. Should a debugger be detected, the malware proceeds\r\nto construct a custom exception.\r\nThis custom exception is crafted to mimic a legitimate program crash while obscuring the true cause of the failure.\r\nThe malware first initializes a large buffer, v18, filling it with null bytes. It then writes specific values to this\r\nbuffer, mimicking the structure of a CONTEXT record, which holds processor register data and thread context\r\ninformation typically captured during exceptions. The malware populates this buffer with values from various\r\nregisters, including general-purpose registers (EAX, EBX, EDI, ESI, etc.), segment registers (CS, DS, ES, etc.),\r\nthe stack pointer (ESP), the instruction pointer (EIP), and the flags register (EFLAGS).\r\nTo trigger the exception, the malware calls RaiseException, using the exception code 0xE06D7363. This code,\r\nunlikely to be handled by any default exception handlers, ensures that the exception will be caught by the\r\nmalware’s top-level exception filter. This custom filter, designed to prevent interference from debugging tools, is\r\nlikely programmed to terminate the malware’s process upon encountering this specific exception, effectively\r\nhalting further analysis within the debugger.\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 2 of 6\n\nFollowing the sub_4025E0 initializes a security cookie (__security_cookie) using a combination of system time,\r\nprocess/thread IDs, and performance counter, may be used for integrity checks later on.\r\nThe cookie, crafted from a combination of system time retrieved using GetSystemTimeAsFileTime, process and\r\nthread IDs acquired via GetCurrentProcessId and GetCurrentThreadId, and performance counter readings\r\nobtained using QueryPerformanceCounter, acts as a fingerprint for the malware’s code. By incorporating these\r\nsystem values, the security cookie becomes highly unique to each infection.\r\nIt begins by dynamically resolving the base address of the “KERNEL32.DLL” module. This is achieved by\r\ntraversing the Process Environment Block (PEB), a system structure containing information about loaded\r\nmodules, and locating the entry for “KERNEL32.DLL.”\r\nThis approach avoids using the standard GetModuleHandle function, which could be easily hooked by security\r\nproducts, making the malware’s actions more difficult to trace.\r\nFurther decrypted strings reveal resolution calls to WinHttpOpen, WinHttpConnect, WinHttpOpenRequest,\r\nWinHttpSendRequest, WinHttpReceiveResponse and WinHttpCloseHandle.\r\nThese are all standard WinHTTP API functions for making web requests. It then constructs an HTTP GET\r\nrequest to www[.]oref[.]org[.]il/alerts/RemainderConfig_eng.json using hardcoded user agent string Mozilla/5.0\r\n(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0.\r\nIt then downloads the content of the JSON file and stores it in memory. If the download is successful it opens a\r\nfile named “EFsoIAEBEwpwcDoBGAYBORFPXlECQ11eVA==” (decrypted to “C:\\Users\\Public\\conf.conf“) in\r\nwrite mode “w”, copies itself under Users/Public and prepares the paths for file overwriting.\r\nAs seen, the malware utilizes a series of obfuscated strings, which are actually API function names encrypted\r\nusing a simple XOR cipher with the hardcoded key “Saturday, October 07, 2023, 6:29:00 AM.” Decrypting the\r\nstring “Hw4VET4NAwtNUjYi” reveals the LoadLibraryA function as well. See “Appendix” to get a script\r\nusefull to decrypt them.\r\nSTRINGS DECRYPTION ROUTINE\r\nThe string decryption routine within this wiper utilizes a custom XOR cipher implementation, augmented by a\r\ncharacter mapping technique. The function sub_401160 serves as the core decryption engine, accepting the\r\nencrypted string and a hardcoded key string (“Saturday, October 07, 2023, 6:29:00 AM“) as input. The initial\r\nstep involves Base64 decoding. The function determines the encoded data’s length by traversing the input string\r\nuntil it encounters a non-Base64 character, using the lookup table byte_41DE18 to identify characters outside the\r\nBase64 alphabet.\r\nA memory buffer, sized to hold the decoded bytes, is allocated. Decoding proceeds in blocks of four encoded\r\ncharacters, which are mapped to their numeric values via the byte_41DE18 table. These values are then bit-shifted\r\nand combined to generate three bytes of decoded data, which are written to the buffer. This process iterates until\r\nthe entire input string is decoded. Following Base64 decoding, the function allocates a second buffer to store the\r\ndecrypted string. The size of this buffer is calculated based on the decoded data’s length and the key string’s\r\nlength.\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 3 of 6\n\nThe XOR decryption operates on each byte of the decoded data. For each byte, using the decoded data’s index and\r\nthe key’s length, the index of the corresponding key character is determined. This ensures cyclic repetition of the\r\nkey string to match the decoded data’s length. The core XOR operation is then applied between the current\r\ndecoded byte and the ASCII value of the corresponding key character. This generates a single decrypted byte,\r\nwhich is written sequentially to the output buffer, forming the decrypted string character by character.\r\nThe function relies on the byte_41DE18 lookup table to optimize character-to-numeric value conversion,\r\neliminating the need for repeated calls to the ord function. This table-driven approach streamlines the XOR\r\noperation by providing readily available numeric values for each ASCII character. Upon completing the\r\ndecryption, sub_401160 null-terminates the output buffer, resulting in a valid C-style string containing the\r\ndecrypted data. This string is then returned to the calling function for use within the malware.\r\nCORE WIPER LOGIC\r\nThe function sub_4016C0 serves as the operational core of the wiper malware, orchestrating the files\r\nmanipulation and system disruption activities. Upon entering this function, the malware first initiates a short delay\r\nusing the Sleep function, pausing for 1000 milliseconds and enumerating drives using GetLogicalDrives.\r\nFollowing the malware calls sub_4015B0, which appears to lay as the groundwork for the wiper’s operations. The\r\nmalware proceeds to resolve the addresses of essential Windows API functions from “KERNEL32.DLL” and\r\n“User32.dll,” utilizing decrypted strings to mask its intentions. These functions include CreateFileW (decrypted\r\nfrom dword_D593C8), SetFileAttributesW (decrypted from dword_D593D0), CloseHandle (decrypted\r\nfrom dword_D59504), PostMessageW (decrypted from dword_D593E0), and SendMessageW (decrypted\r\nfrom dword_D593E4).\r\nAfter this, the malware enters its main operational loop supporting multi-threading. This loop forms the heart of\r\nthe wiper’s attack strategy, driving a continuous cycle of file destruction and system manipulation. Within each\r\niteration of the loop, the malware calls CreateFileW, creating handles to the targeted files and directories. With\r\nfile handles secured it calls the sub_408050.\r\nThis function, designed for data writing, overwrites the contents of the targeted files with large blocks of data,\r\neffectively rendering them unusable. Significantly, this initialization involves filling the buffer with null bytes\r\n(ASCII value 0) and random bytes could be used to disrupt the targeted files.\r\nA crucial observation pointing towards overwriting lies in the size parameter passed to sub_408050. This\r\nparameter appears to be directly related to the target file size, suggesting the wiper might be writing a stream of\r\nbytes equal to the file’s size, completely filling it and effectively obliterating the original data.\r\nTo further hide its actions, the malware employs SetFileAttributesW to potentially modify the attributes of the\r\naffected files. The wiper’s manipulation appears to extend beyond simple file overwriting as it also\r\nutilizes MoveFileWithProgressW (decrypted from dword_D59510) to potentially prevent an easy recovery.\r\nBefore returning, the malware displays the message “Hey ESET, wait for the leak.. Doing business with the\r\noccupiers puts you in scope!” by using MessageBoxA.\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 4 of 6\n\nATTRIBUTION\r\nDiffucult to say; My personal speculations are directed towards TA402\r\n(https://malpedia.caad.fkie.fraunhofer.de/actor/ta402) but I have no definitive evidence. Obviously, these cannot\r\nbe considered conclusive in attributing this attack 🙂 . TA402 is believed to be aligned with Palestinian espionage\r\ninterests, primarily targeting intelligence collection efforts.\r\nIoC\r\nSHA256: 2abff990d33d99a0732ddbb3a39831c2c292f36955381d45cd8d40a816d9b47a\r\nAPPENDIX\r\nPython script to decrypt internal malware strings:\r\nimport base64\r\ndef decrypt_string(encrypted_string, key_string):\r\n \"\"\"\r\n Author:\r\n Emanuele De Lucia\r\n \r\n What it does:\r\n Decrypts the given string using a XOR cipher with the logic of OctoberSeventh wiper.\r\n \r\n Args:\r\n encrypted_string: The string to decrypt.\r\n \r\n key_string: The key to use for decryption.\r\n Returns:\r\n The decrypted string.\r\n \"\"\"\r\n key_len = len(key_string)\r\n decrypted_bytes = bytearray()\r\n \r\n decoded_bytes = base64.b64decode(encrypted_string)\r\n \r\n for i, byte in enumerate(decoded_bytes):\r\n decrypted_bytes.append(byte ^ ord(key_string[i % key_len]))\r\n \r\n return decrypted_bytes.decode()\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 5 of 6\n\nencrypted_string = \"AxMbFhcXEkoeZiYRBxs=\"\r\nkey_string = \"Saturday, October 07, 2023, 6:29:00 AM\"\r\ndecrypted_string = decrypt_string(encrypted_string, key_string)\r\nprint(f\"Decrypted string: {decrypted_string}\")\r\nSource: https://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nhttps://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.emanueledelucia.net/hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel/" ], "report_names": [ "hey-eset-wait-for-the-leak-dissecting-the-octoberseventh-wiper-targeting-eset-customers-in-israel" ], "threat_actors": [ { "id": "e5cad6bf-fa91-4128-ba0d-2bf3ff3c6c6b", "created_at": "2025-08-07T02:03:24.53077Z", "updated_at": "2026-04-10T02:00:03.680525Z", "deleted_at": null, "main_name": "ALUMINUM SARATOGA", "aliases": [ "APT-C-23", "Arid Viper", "Desert Falcon", "Extreme Jackal ", "Gaza Cybergang", "Molerats ", "Operation DustySky ", "TA402" ], "source_name": "Secureworks:ALUMINUM SARATOGA", "tools": [ "BlackShades", "BrittleBush", "DarkComet", "LastConn", "Micropsia", "NimbleMamba", "PoisonIvy", "QuasarRAT", "XtremeRat" ], "source_id": "Secureworks", "reports": null }, { "id": "0ad97d64-7970-48ca-83f6-3635c66e315c", "created_at": "2023-11-21T02:00:07.400003Z", "updated_at": "2026-04-10T02:00:03.479189Z", "deleted_at": null, "main_name": "TA402", "aliases": [], "source_name": "MISPGALAXY:TA402", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "847f600c-cf90-44c0-8b39-fb0d5adfcef4", "created_at": "2022-10-25T16:07:23.875541Z", "updated_at": "2026-04-10T02:00:04.768142Z", "deleted_at": null, "main_name": "Molerats", "aliases": [ "ATK 89", "Aluminum Saratoga", "Extreme Jackal", "G0021", "Gaza Cybergang", "Gaza Hackers Team", "Molerats", "Operation DustySky", "Operation DustySky Part 2", "Operation Molerats", "Operation Moonlight", "Operation SneakyPastes", "Operation TopHat", "TA402", "TAG-CT5" ], "source_name": "ETDA:Molerats", "tools": [ "BadPatch", "Bladabindi", "BrittleBush", "Chymine", "CinaRAT", "Darkmoon", "Downeks", "DropBook", "DustySky", "ExtRat", "Gen:Trojan.Heur.PT", "H-Worm", "H-Worm RAT", "Houdini", "Houdini RAT", "Hworm", "Iniduoh", "IronWind", "Jenxcus", "JhoneRAT", "Jorik", "KasperAgent", "Kognito", "LastConn", "Micropsia", "MoleNet", "Molerat Loader", "NeD Worm", "NimbleMamba", "Njw0rm", "Pierogi", "Poison Ivy", "Quasar RAT", "QuasarRAT", "SPIVY", "Scote", "SharpSploit", "SharpStage", "WSHRAT", "WelcomeChat", "Xtreme RAT", "XtremeRAT", "Yggdrasil", "dinihou", "dunihi", "njRAT", "pivy", "poisonivy" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434662, "ts_updated_at": 1775792283, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a7824688095cb4181cb50e8120885ad9f442737f.pdf", "text": "https://archive.orkl.eu/a7824688095cb4181cb50e8120885ad9f442737f.txt", "img": "https://archive.orkl.eu/a7824688095cb4181cb50e8120885ad9f442737f.jpg" } }