UAT-9244 targets South American telecommunication providers with three new malware implants

  • Cisco Talos is disclosing UAT-9244, who we assess with high confidence is a China-nexus advanced persistent threat (APT) actor closely associated with Famous Sparrow.
  • Since 2024, UAT-9244 has targeted critical telecommunications infrastructure, including Windows and Linux-based endpoints and edge devices in South America, proliferating access via three malware implants.
  • The first backdoor, “TernDoor,” is a new variation of the previously disclosed, Windows-based, CrowDoor malware.
  • Talos also discovered that UAT-9244 uses “PeerTime,” an ELF-based backdoor that uses the BitTorrent protocol to conduct malicious operations on an infected system.
  • UAT-9244’s third implant is a brute force scanner, which Talos tracks as “BruteEntry.” BruteEntry is typically installed on network edge devices, essentially converting them into mass-scanning proxy nodes, also known as Operational Relay Boxes (ORBs) that attempt to brute force into SSH, Postgres, and Tomcat servers.

Introducing TernDoor: A variant of CrowDoor

UAT-9244 targets South American telecommunication providers with three new malware implants

UAT-9244 used dynamic-link library (DLL) side-loading to activate multiple stages of their infection chain. The actor executed “wsprint[.]exe”, a benign executable that loaded the malicious DLL-based loader “BugSplatRc64[.]dll”. The DLL reads a data file named “WSPrint[.]dll” from disk, decrypts its contents, and executes them in memory to activate TernDoor, the final payload.

TernDoor is a variant of CrowDoor, a backdoor deployed in recent intrusions linked to China-nexus APTs such as FamousSparrow and Earth Estries. CrowDoor is a variant of SparrowDoor, another backdoor attributed to FamousSparrow. CrowDoor has also been observed in previous Tropic Trooper intrusions,  indicating a close operational relationship with FamousSparrow. Based on the overlap in tooling; tactics, techniques, and procedures (TTPs); and victimology, we assess with high confidence that UAT-9244 closely overlaps with FamousSparrow and Tropic Trooper.

Although UAT-9244 and Salt Typhoon both target telecommunications service providers, Talos has not been able to verify or establish a solid connection between the two clusters.

The DLL-based loader

The DLL-based loader, “BugSplatRc64.dll”, will load the “WSPrint.dll” file from the current directory, which will be decoded using the key “qwiozpVngruhg123”.

UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 1. DLL-based loader reading the encoded payload.

The decoded shellcode is position-independent and decodes and decompresses the final payload. The final payload is the TernDoor implant.

TernDoor

The final shellcode consists of the TernDoor backdoor. TernDoor is a variant of CrowDoor, actively developed and used by UAT-9244 since at least November 2024. TernDoor deviates from CrowDoor in the following aspects:

  • TernDoor consists of command codes that are different from previously disclosed variants of CrowDoor.
  • The TernDoor shellcode also consists of an embedded Windows driver (SYS file). The driver is encrypted using AES in the shellcode. The driver is used to suspend, resume, and terminate processes.

Persistence

The TernDoor infection chain is persisted on the system using either a scheduled task or the Registry Run key.

The scheduled task is named “WSPrint” and created using the command:

schtasks /create /tn WSPrint /tr "C:ProgramDataWSPrintWSPrint.exe" /ru "SYSTEM" /sc onstart /F

Furthermore, TernDoor modifies the following task-related registry keys to hide the task:

  • Deletes HKLMSOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTreeWSPrint | SD
  • Modifies HKLMSOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTreeWSPrint | Index = from 1 to 0

A Registry Run key may also be set to run the executable on user login:

HKCUSoftwareMicrosoftWindowsCurrentVersionRun | Default = C:ProgramDataWSPrintWSPrint.exe

Command line switch

Unlike CrowDoor, TernDoor only supports one command line switch: “-u”, passed to WSPrint.exe. This is the switch for uninstalling the malware from the system and it deletes all malware files from the operating directory, as well as terminates malicious processes.

Decoding the configuration

Like previous variants of CrowDoor, TernDoor also checks to ensure it has been injected into “msiexec[.]exe”. The implant decodes its configuration that can specify the following information:

  • Command and control (C2) IP address
  • Number of tries to connect to the C2
  • C2 port number
  • User-Agent to use while connecting to C2 (if applicable)
UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 2. TernDoor configuration blob.

TernDoor functionality

TernDoor’s capabilities resemble those of previously disclosed CrowDoor samples:

  • Communicates with the C2 IP address
  • Creates processes and runs arbitrary commands via remote shell and independently
  • Reads and writes files
  • Collects system information such as computer and user name, IP address information, and OS bitness
  • Uninstalls itself from the infected system
  • Deploys the accompanying driver to hide malicious components and perform process management

The accompanying Windows driver, WSPrint.sys, is dropped to disk and then activated using a windows service:

UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 3. Malicious driver service on the infected endpoint.

 The driver creates a device named “\Device\VMTool” and symbolically links it to “\DosDevices\VMTool”. It can terminate, suspend, or resume processes specified by TernDoor — likely a means of evasion.

TernDoor infrastructure

All the C2 IP addresses discovered by Talos were associated with the following SSL certificate on port 443:

SSL_fingerprint_sha256= 0c7e36683a100a96f695a952cf07052af9a47f5898e1078311fd58c5fdbdecc8
SSL_fingerprint_SHA1= 2b170a6d90fceba72aba3c7bc5c40b9725f43788
Data:
Version: V3
Serial Number: 1
Thumbprint: 2b170a6d90fceba72aba3c7bc5c40b9725f43788
 
Signature Algorithm:
Issuer: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8
Validity
Not Before: 2022-09-04 12:54:51
Not After: 2023-09-04 12:54:51
Subject: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8

Pivoting off this certificate, Talos found an additional 18 IPs likely being used by UAT-9244. This list is provided in the indicators of compromise (IOCs) section.

One of the DLL-based loaders was also hosted on the IP “212.11.64[.]105”. On this server, we discovered a set of shell scripts and an accompanying malware family we track as “PeerTime.”

PeerTime: UAT-9244’s peer-to-peer (P2P) backdoor

PeerTime is an ELF based backdoor that is compiled for a variety of architectures such as ARM, AARCH, PPC, MIPS etc., indicating that UAT-9244 can use it to infect a variety of embedded systems.

PeerTime is deployed through a shellscript that downloads the PeerTime loader ELF binary and an instrumentor binary.

The instrumentor ELF binary will check for the presence of docker on the compromised host using the commands docker and docker –q.

If docker is found, then the PeerTime loader is executed using:

docker <path_of_PeerTime_loader_ELF>

The instrumentor consists of debug strings in Simplified Chinese, indicating that it is a custom binary created and deployed by Chinese-speaking threat actors:

获取当前程序路径错误:     //Error retrieving current program path:
删除当前程序错误:                // Error deleting current program:

UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 4. PeerTime installation/infection chain.

PeerTime consists of a loader that will decrypt and decompress the final PeerTime ELF payload and run it in memory. The PeerTime loader has the ability to rename its process to a benign process to evade detection.

PeerTime uses the BitTorrent protocol to obtain C2 information, download files from its peers, and execute them on the infected host. The payloads are written to disk and copied to the specified locations using BusyBox. As of now, PeerTime consists of two versions: one written in C/C++ and a newer version written in Rust.

UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 5. PeerTime uses busybox to copy payloads.

PeerTime is also known as “angrypeer” and can be tracked in VirusTotal using the “malware_config:angrypeer” query. Malware configurations in VirusTotal are identified using Mandiant’s/GTIG’s Backscatter tool.

Setting up ORBs via BruteEntry

Infrastructure used by UAT-9244 also hosts another set of shell scripts and payloads designed to establish compromised Linux based systems including edge devices as operational relay boxes (ORBs) that scan and brute force Tomcat, Postgres, and SSH servers.

The shell script will download two components:

  • An instrumentor and daemon process that activates the actual brute forcer
  • The actual brute forcer (named BruteEntry) that obtains target IPs from the C2 server and scans the IPs
UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 6. BruteEntry infection chain.

The instrumentor binary

The instrumentor binary is an ELF file written in GoLang. It checks if the BruteEntry is already running on the system using “pgrep”:

pgrep <path_to_BruteEntry>

And then starts the brute forcer agent:

./<path_to_BruteEntry>

BruteEntry

BruteEntry is also written in GoLang and begins by registering with the C2 server by providing it with the infected system’s IP address and computer name:

{“ip”:“value”, “hostname”:“value”}

 The C2 responds with a JSON that assigns an agent_id to the infected host:

{“agent_id”:“value”, “server”:“value”}

where “server” = version string of BruteEntry such as “brute-force-server-v1.0”

 BruteEntry will then ask the C2 for tasks to perform by sending a GET request to the C2 at the URI, where limit=1000 is the maximum number of vulnerable IPs to scan:

/tasks/<agent_id>?limit=1000

The C2 responds with a JSON that consists of “tasks” containing the list of IPs to brute force:

{"tasks":[
{"id":,"target":":","type":""},
{"id":,"target":":","type":""},
. . . . .
] }

 The “type” field in the json defines the type of scan to conduct — either “tomcat”,“postgres”, or “ssh”.

The agent will then use a set of embedded credentials to attempt to brute force into either a Tomcat server application at the URL “https[://]<IP>:<Port>/manager/html”, or will brute force into a Postgres instance, either defined in the JSON (<IP><Port>) from the C2 or using the port 5432 if no port is specified.

UAT-9244 targets South American telecommunication providers with three new malware implants
Figure 7. BruteEntry selecting the type of service to brute force into.

Any successful logins are then POSTED back to the C2:

{"batch":[
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
......
]}

 In this instance, “success” indicates if the brute force was successful (true or false), and “notes” provides specific information on whether the brute force was successful. If the login failed, the note reads “All credentials tried.” If it succeeded, the note reads “Cracked by agent <agent_id> | Version <agent_version>”.

Coverage

The following ClamAV signatures detect and block this threat:

  • Win.Loader.PeerTime
  • Win.Malware.TernDoor
  • Unix.Malware.BruteEntry
  • Txt.Malware.PeerTime
  • Unix.Malware.PeerTime

The following SNORT® rules (SIDs) detect and block this threat: 65551

IOCs

TernDoor Loader DLL

711d9427ee43bc2186b9124f31cba2db5f54ec9a0d56dc2948e1a4377bada289
3c098a687947938e36ab34b9f09a11ebd82d50089cbfe6e237d810faa729f8ff
f36913607356a32ea106103387105c635fa923f8ed98ad0194b66ec79e379a02

 Encoded TernDoor payload

A5e413456ce9fc60bb44d442b72546e9e4118a61894fbe4b5c56e4dfad6055e3
075b20a21ea6a0d2201a12a049f332ecc61348fc0ad3cfee038c6ad6aa44e744
1f5635a512a923e98a90cdc1b2fb988a2da78706e07e419dae9e1a54dd4d682b

Windows driver

2d2ca7d21310b14f5f5641bbf4a9ff4c3e566b1fbbd370034c6844cedc8f0538

UAT-9244 C2 IPs used by TernDoor

154[.]205[.]154[.]82:443
207[.]148[.]121[.]95:443
207[.]148[.]120[.]52:443
212[.]11[.]64[.]105

Suspected UAT-9244 IPs

149[.]28[.]25[.]33
154[.]205[.]154[.]194
154[.]205[.]154[.]65
154[.]205[.]154[.]70
154[.]223[.]21[.]130
154[.]223[.]21[.]194
158[.]247[.]238[.]240
216[.]238[.]112[.]222
216[.]238[.]123[.]242
216[.]238[.]94[.]37
38[.]54[.]125[.]134
38[.]60[.]199[.]34
45[.]32[.]106[.]94
45[.]77[.]34[.]194
45[.]77[.]41[.]141
47[.]76[.]100[.]159
64[.]190[.]113[.]170
64[.]95[.]10[.]253

PeerTime installation script

ebcb2691b7c92cdf2b2ff5e2d753abeea8cb325c16596cd839e6bd147f80e38a
00735a8a50d2856c11150ef1e29c05acebce7ad3edad00e37c7f043aacb46330
74fbc8360d4c95d64d7acaa4d18943dce2d41f91d080b0b5e435d8bce52861a5
babc81fc9c998e9dc4ab545f0e112e34d2641e1333bc81aaa131abd061a5b604
e34c9159e6e78c59518a14c5b96bddfee094b684f99d4f69b13371284a014e87
2c3f2261b00ea45e25eb4e9de2b7ff8e41f311c0b3d986461f834022c08b3b99
3fcced9332301ff70b20c98c9434c858400013d659afa6bb5149cffb0206357d
a313f76fca50fff1bcd6f2c6cbc1268985f8c0a3a05fe7f43c4fc0ac3aff84dc
03eac9eb7f4b4bc494ef0496ee23cabbf38f883896838ed813741d8f64ac9fde
17652d7bb5fe0454023db4fc7f608df0dbe6af237be31258e16ba52f0e895e26
74d1a678bdc4bb9f33321e94e3bd1bc1740472ed734231fc46af720072ecb77e

PeerTime instrumentor binary

c9fc2af30f769d856b88b3051f19fdb663b3e0a0916279df9bbcba93c6a110c9

PeerTime malware

34d64b3cd9430e85edefcb883973a086dd5de9917e05fabec89b1f4ab9627e91
1cedf01dd4b7e50181d0e781825c66957b862941395d77c8bd7705114f319c80
bfc35f12d00fa4b40c5fbce9e37d704e12a52262709bcbdf09f97890bc40cad5
f3e899789b56429f483e5096e1f473335024f1f763e2d428132338e30352b89e
6ec070457d1f6f239cb02c5e1576a3660cca98f3a07eec6e4e107f698d7fe555
15d937803f90c2b9e277ff94d3e98ff30015ecc7f4623a158e3c98861e5cb278
7b70cd956f082b1029d02b4cb7608893f2de7fa9c500d7d7febdd0f745ac3cb6
d78b3c6df8f3756a7e310cf7435fdba201dd03ec9f97420a0db683489a01a7c9
3fcadde4b414a18b2fed56c1ec59d97977123615fbbf411a1c78425445a6e71c
3d9fbfc2c056eac857ba54e5ed134aa45a4b8322ee9f9353ba32e5b2ca71b0e3
c9a42423ef08bd7f183915780d39530eba5e4e25968c51965ff8bb3026965a28
38eeaa4eaad72feb3f8e6993565fcc548d8e7bb93642590f00fa24aacc0e2862
56bead2933e91366e4a0d5761daf5b238a7f2c22e597664ef67b3ecae20ab326
6a2d23cc8746a83e9a3b974788fce0e414706b8e75ff390426dd7e10b19967b3
9a7225c17e4bad3ffe7f080530d36f4f8aca5c116b913caa91ab9b0cee85638e
870e791af14caaf395c56028176a9c3f4c1ff0318ef3112d57ecd3d4a1be2ef9

PeerTime remote locations

185[.]196[.]10[.]247
xtibh[.]com
xcit76[.]com

PeerTime C2s

bloopencil[.]net
185[.]196[.]10[.]38

BruteEntry installation script

1fcdd5a417db31e5e07d32cecfa69e53f0dce95b7130ad9c03b92249f001801d

BruteEntry instrumentor binary

66ce42258062e902bd7f9e90ad5453a901cfc424f0ea497c4d14f063f3acd329
d5eb979cb8a72706bfa591fa57d4ebf7d13cecdc9377b0192375e2f570f796df

BruteEntry agent

66adeedfb739774fcc09aa7426c8fad29f8047ab4caee8040d07c0e84d011611
66bdce93de3b02cf9cdadad18ca1504ac83e379a752d51f60deae6dcbafe4e31

BruteEntry infrastructure

212[.]11[.]64[.]105
185[.]196[.]10[.]247

Additional malicious scripts

023467e236a95d5f0e62e26445d430d749c59312f66cf136e6e2c2d526c46ba1
f8066833e47814793d8c58743622b051070dac09cb010c323970c81b59260f84
06b23d84fd7afd525dfd7860ebd561dcdd72ccbeb51981d5d9a75acf068d0a2a

Cisco Talos Blog – ​Read More

Protecting education: How MDR can tip the balance in favor of schools

The education sector is notoriously short on cash, but rich in assets for threat actors to target. How can managed detection and response (MDR) help learning institutions regain the initiative?

WeLiveSecurity – ​Read More

What a browser-in-the-browser attack is, and how to spot a fake login window | Kaspersky official blog

In 2022, we dived deep into an attack method called browser-in-the-browser — originally developed by the cybersecurity researcher known as mr.d0x. Back then, no actual examples existed of this model being used in the wild. Fast-forward four years, and browser-in-the-browser attacks have graduated from the theoretical to the real: attackers are now using them in the field. In this post, we revisit what exactly a browser-in-the-browser attack is, show how hackers are deploying it, and, most importantly, explain how to keep yourself from becoming its next victim.

What is a browser-in-the-browser (BitB) attack?

For starters, let’s refresh our memories on what mr.d0x actually cooked up. The core of the attack stems from his observation of just how advanced modern web development tools — HTML, CSS, JavaScript, and the like — have become. It’s this realization that inspired the researcher to come up with a particularly elaborate phishing model.

A browser-in-the-browser attack is a sophisticated form of phishing that uses web design to craft fraudulent websites imitating login windows for well-known services like Microsoft, Google, Facebook, or Apple that look just like the real thing. The researcher’s concept involves an attacker building a legitimate-looking site to lure in victims. Once there, users can’t leave comments or make purchases unless they “sign in” first.

Signing in seems easy enough: just click the Sign in with {popular service name} button. And this is where things get interesting: instead of a genuine authentication page provided by the legitimate service, the user gets a fake form rendered inside the malicious site, looking exactly like… a browser pop-up. Furthermore, the address bar in the pop-up, also rendered by the attackers, displays a perfectly legitimate URL. Even a close inspection won’t reveal the trick.

From there, the unsuspecting user enters their credentials for Microsoft, Google, Facebook, or Apple into this rendered window, and those details go straight to the cybercriminals. For a while this scheme remained a theoretical experiment by the security researcher. Now — real-world attackers have added it to their arsenals.

Facebook credential theft

Attackers have put their own spin on mr.d0x’s original concept: recent browser-in-the-browser hits have been kicking off with emails designed to alarm recipients. For instance, one phishing campaign posed as a law firm informing the user they’d committed a copyright violation by posting something on Facebook. The message included a credible-looking link allegedly to the offending post.

Phishing email masquerading as a legal notice

Attackers sent messages on behalf of a fake law firm alleging copyright infringement — complete with a link supposedly to the problematic Facebook post. Source

Interestingly, to lower the victim’s guard, clicking the link didn’t immediately open a fake Facebook login page. Instead, they were first greeted by a bogus Meta CAPTCHA. Only after passing it was the victim presented with the fake authentication pop-up.

Fake login window rendered directly inside the webpage

This isn’t a real browser pop-up; it’s a website element mimicking a Facebook login page — a ruse that allows attackers to display a perfectly convincing address. Source

Naturally, the fake Facebook login page followed mr.d0x’s blueprint: it was built entirely with web design tools to harvest the victim’s credentials. Meanwhile, the URL displayed in the forged address bar pointed to the real Facebook site — www.facebook.com.

How to avoid becoming a victim

The fact that scammers are now deploying browser-in-the-browser attacks just goes to show that their bag of tricks is constantly evolving. But don’t despair — there’s a way to tell if a login window is legit. A password manager is your friend here, which, among other things, acts as a reliable security litmus test for any website.

That’s because when it comes to auto-filling credentials, a password manager looks at the actual URL, not what the address bar appears to show, or what the page itself looks like. Unlike a human user, a password manager can’t be fooled with browser-in-the-browser tactics, or any other tricks, like domains having a slightly different address (typosquatting) or phishing forms buried in ads and pop-ups. There’s a simple rule: if your password manager offers to auto-fill your login and password, you’re on a website you’ve previously saved credentials for. If it stays silent, something’s fishy.

Beyond that, following our time-tested advice will help you defend against various phishing methods, or at least minimize the fallout if an attack succeeds:

  • Enable two-factor authentication (2FA) for every account that supports it. Ideally, use one-time codes generated by a dedicated authenticator app as your second factor. This helps you dodge phishing schemes designed to intercept confirmation codes sent via SMS, messaging apps, or email. You can read more about one-time-code 2FA in our dedicated post.
  • Use passkeys. The option to sign in with this method can also serve as a signal that you’re on a legitimate site. You can learn all about what passkeys are and how to start using them in our deep dive into the technology.
  • Set unique, complex passwords for all your accounts. Whatever you do, never reuse the same password across different accounts. We recently covered what makes a password truly strong on our blog. To generate unique combinations — without needing to remember them — Kaspersky Password Manager is your best bet. As an added bonus, it can also generate one-time codes for two-factor authentication, store your passkeys, and synchronize your passwords and files across your various devices.

Finally, this post serves as yet another reminder that theoretical attacks described by cybersecurity researchers often find their way out into the wild. So, keep an eye on our blog, and subscribe to our Telegram channel to stay up to speed on the latest threats to your digital security and how to shut them down.

Read about other inventive phishing techniques scammers are using day in day out:

Kaspersky official blog – ​Read More

AI assistant in Kaspersky Container Security

Modern software development relies on containers and the use of third-party software modules. On the one hand, this greatly facilitates the creation of new software, but on the other, it gives attackers additional opportunities to compromise the development environment. News about attacks on the supply chain through the distribution of malware via various repositories appears with alarming regularity. Therefore, tools that allow the scanning of images have long been an essential part of secure software development.

Our portfolio has long included a solution for protecting container environments. It allows the scanning of images at different stages of development for malware, known vulnerabilities, configuration errors, the presence of confidential data in the code, and so on. However, in order to make an informed decision about the state of security of a particular image, the operator of the cybersecurity solution may need some more context. Of course, it’s possible to gather this context independently, but if a thorough investigation is conducted manually each time, development may be delayed for an unpredictable period of time. Therefore, our experts decided to add the ability to look at the image from a fresh perspective; of course, not with a human eye — AI is indispensable nowadays.

OpenAI API

Our Kaspersky Container Security solution (a key component of Kaspersky Cloud Workload Security) now supports an application programming interface for connecting external large language models. So, if a company has deployed a local LLM (or has a subscription to connect a third-party model) that supports the OpenAI API, it’s possible to connect the LLM to our solution. This gives a cybersecurity expert the opportunity to get both additional context about uploaded images and an independent risk assessment by means of a full-fledged AI assistant capable of quickly gathering the necessary information.

The AI provides a description that clearly explains what the image is for, what application it contains, what it does specifically, and so on. Additionally, the assistant conducts its own independent analysis of the risks of using this image and highlights measures to minimize these risks (if any are found). We’re confident that this will speed up decision-making and incident investigations and, overall, increase the security of the development process.

What else is new in Cloud Workload Security?

In addition to adding API to connect the AI assistant, our developers have made a number of other changes to the products included in the Kaspersky Cloud Workload Security offering. First, they now support single sign-on (SSO) and a multi-domain Active Directory, which makes it easier to deploy solutions in cloud and hybrid environments. In addition, Kaspersky Cloud Workload Security now scans images more efficiently and supports advanced security policy capabilities. You can learn more about the product on its official page.

Kaspersky official blog – ​Read More

Middle East on the Brink: Iran-US-Israel Hostilities Trigger Cyber-Kinetic Conflict

Middle East cyberwar

The geopolitical landscape of the Middle East has entered one of its most volatile phases in decades. On February 28, 2026, tensions that had been simmering for years erupted into a full‑blown conflict involving the Islamic Republic of Iran, the United States, and Israel. A confluence of diplomatic stalemate, military posturing, and covert cyber preparations set the stage for what would evolve from a localized confrontation into an expansive, multi‑domain campaign.  

The conflict’s opening salvo — codenamed Operation Epic Fury by the US and Operation Roaring Lion by Israel — was not just a conventional military assault. It was a synchronized hybrid offensive in which cyber operations were integrated as a co‑equal domain with kinetic strikes, psychological messaging, and information warfare. Over the course of the first 72 hours, from February 28 to March 3, kinetic blows and digital disruptions merged in ways that revealed both the strengths and vulnerabilities of actors across the region.  

Throughout this critical period, Cyble Research and Intelligence Labs (CRIL) has been meticulously tracking the movements, attacks, claims, and associated cyber activity between Iran, Israel, and the US, providing real‑time insights into both the kinetic strikes and the evolving threat landscape.  

Prelude to Conflict: Buildup and Diplomatic Gridlock 

In the days leading up to February 28, the Middle East witnessed a massive US military buildup, the largest since the 2003 Iraq invasion. Aircraft carriers, fighter wings, and intelligence assets positioned themselves within striking range of Iran’s borders. At the same time, indirect nuclear negotiations in Geneva appeared, momentarily, to offer a diplomatic pathway, with Iran publicly agreeing to halt enrichment stockpiling under International Atomic Energy Agency (IAEA) supervision. However, distrust and strategic imperatives among the US, Israel, and Tehran rendered the diplomatic exercise insufficient to prevent escalation.  

Day 1: February 28 — Operation Epic Fury 

At approximately 06:27 GMT, the first concerted wave of strikes hit Iran. US‑Israeli forces began a broad assault across more than two dozen provinces, targeting nuclear facilities, IRGC command centers, ballistic missile launchers, and secure compounds tied to the Iranian leadership. The offensive reportedly included the targeted killing of Supreme Leader Ayatollah Ali Khamenei, a moment that marked a profound turning point in the conflict.  

What set the opening apart from traditional air campaigns was its immediate cyber component. For the first time on such a scale, network disruption was planned to coincide with a kinetic impact. Independent monitors observed Iranian internet connectivity collapse to roughly 1–4% of normal levels as cyberattacks crippled state media, government digital services, and military communications. 

Popular local services, including widely used mobile applications and prayer tools, were reportedly compromised to sow confusion and prompt defections, while defaced state news sites delivered messages contradicting official Iranian narratives.  

Before the current situation, MuddyWater, long associated with Iran‑linked cyber campaigns, remained a critical piece of the pre‑existing threat landscape. Alongside other advanced persistent threat (APT) groups — such as APT42 (Charming Kitten), Prince of Persia / Infy, UNC6446, and CRESCENTHARVEST — these campaigns had already been active before February 28, conducting phishing, exploitation of public servers, and information theft targeting Israeli, US, and regional networks.  

While Iran’s domestic internet infrastructure faltered, the US‑Israeli offensive extended psychological operations into Israeli territory. Threatening messages referencing national ID numbers and fuel shortages arrived in civilians’ inboxes, and misinformation campaigns amplified anxieties even as authorities worked to blunt digital interference. 

Day 2: March 1 — Retaliation and the Surge of Hacktivism 

Iran’s kinetic retaliation was swift and forceful. From March 1 onward, waves of ballistic missiles and drones launched at Israel, Gulf Cooperation Council (GCC) states, and US military bases reinforced that Tehran’s response would not be limited to symbolic posturing. The UAE alone intercepted hundreds of projectiles, resulting in civilian casualties and infrastructure damage, including at Dubai’s international airport and an AWS cloud data center within its mec1‑az2 availability zone.  

On the cyber front, March 1 started the dramatic expansion of hacktivist activity across the region. More than 70 groups — spanning ideological spectrums and even blending pro‑Iranian and pro‑Russian motivations — activated operations in parallel with state responses. An Electronic Operations Room organized by Iraqi‑aligned hackers, such as Cyber Islamic Resistance / Team 313 began orchestrating distributed denial‑of‑service (DDoS) attacks, website defacements, and theft of credentials across national government portals and key infrastructure systems in Turkey, Poland, and GCC states. 

One of the most technically significant artifacts of March 1 was a malicious RedAlert APK observed by Unit 42 analysts. Designed to mimic Israel’s official missile alert app, this payload was distributed via Hebrew‑language SMS links. Once installed, it collected sensitive device and user information — contacts, SMS logs, IMEI numbers, and email credentials — with encrypted exfiltration mechanisms and anti‑analysis protections, providing a rare glimpse of tradecraft resembling state‑level cyber operations at a time when Iranian domestic internet access was severely limited.  

Beyond MuddyWater and other established APTs, opportunistic cybercriminals exploited the chaos through social engineering campaigns in the UAE.  

Day 3: March 2–3 — Strikes, Blackouts, and Enduring Hybrid Threats 

The kinetic campaign broadened on March 2 with the destruction of the IRGC’s Malek‑Ashtar headquarters in Tehran. By March 3, Israeli forces had struck Iran’s state broadcaster, further constraining Tehran’s ability to manage domestic information and cyber operations. The extended internet blackout — persisting well into the third day — continued to isolate Iranian networks, allowing external campaigns to operate with limited interference.  

Several digital fronts emerged during this period: 

  • Hacktivist and Propaganda Operations: Groups such as Handala Hack Team claimed exfiltration of terabytes of financial data; others like DieNet and OverFlame targeted GCC critical infrastructure portals and governmental systems in coordinated disruptive campaigns. 

  • Pro‑Russian Opportunistic Convergence: Entities, including NoName057(16) and Russian Legion, shifted their focus from Ukraine‑related operations to anti‑Israel actions supportive of Iran, albeit with mixed credibility. 

  • Cybercrime Opportunism: The blend of hacktivism and ransomware was exemplified by groups like INC Ransomware, which targeted industrial entities and combined extortion‑style tactics with ideological messaging. 

Throughout March 1–3, analysts noted that most observed cyber activity fell into the realm of DDoS attacks, exposed CCTV feeds, and information operations rather than destructive intrusions into industrial control systems — although unverified claims of SCADA manipulation circulated widely in pro‑Iranian forums.  

Broader Regional and Strategic Implications 

The first 72 hours of Operation Epic Fury reveal several critical insights about modern conflict dynamics in the Middle East: 

  1. Cyber as a Co‑Equal Domain: Cyber operations were planned and executed in lockstep with kinetic strikes, demonstrating that modern warfare no longer segregates digital and physical arenas. 

  1. Hacktivist Amplification: With over 70 groups active within days, the hacktivist ecosystem has become a force multiplier of psychological and disruptive operations that can transcend national borders. 

  1. Opportunistic Exploitation: As seen in social engineering and ransomware campaigns, broader conflict can catalyze financially motivated cybercrime that piggybacks on geopolitical uncertainty. 

These dynamics suggest that defenders in the region — from government CERTs to multinational enterprises — must maintain heightened vigilance across both technical and psychological threat vectors, with particular emphasis on credential harvesting, DDoS mitigation, and proactive monitoring of emerging malware campaigns. 

Conclusion 

The events from February 28 to March 3 highlight that the US‑Israeli offensive against Iran — launched as Operation Epic Fury — is not merely a military confrontation but a hybrid engagement across kinetic, cyber, and informational domains. While Iran’s internet infrastructure remains degraded, sophisticated pre‑positioned capabilities could still be activated in the coming weeks, particularly if connectivity is restored. Meanwhile, the hacktivist theatre continues to grow in both volume and geographic scope, even as the technical sophistication of most operations remains limited. 

In this environment, security practitioners and strategic planners must be prepared for adaptive threat behavior that blends political motivations with opportunistic cybercrime — a reality that defines the 21st‑century battlespace in the Middle East and beyond. 

References: 

The post Middle East on the Brink: Iran-US-Israel Hostilities Trigger Cyber-Kinetic Conflict appeared first on Cyble.

Cyble – ​Read More

Talos on the developing situation in the Middle East

Talos on the developing situation in the Middle East

Cisco Talos continues to monitor the ongoing conflict in the Middle East. As always, we will be watching closely for any cyber-related incidents that are tied to the conflict. At this time we have not seen any significant cyber impacts, with some small incidents such as web defacements and small-scale distributed-denial-of-service (DDoS) attacks occurring. As with any highly fluid or dynamic situation, we are focused on providing our customers with highly accurate and timely intelligence and information.

Iranian groups involved in this conflict have historically operated primarily in the espionage, destructive attack, and hack-and-leak landscapes. We expect these, along with the mentioned activity, to be the most likely avenues in the near term.

Please see the following Talos research into regional actors in this area:

Outlook on cyber activity

The data has thus far supported the belief that this will be a regional war with a large focus on kinetic activity, but that can change, we’ll continue to monitor and will update accordingly. Currently there does not appear to be any significant increase in cyber activity associated with state-sponsored or state-affiliated groups.

Any possible impacts will likely be from sympathetic groups like hacktivists, some of whom have already launched website defacement and DDoS campaigns in support of Iran. Additionally, cyber criminals are likely to take advantage of the war to try and increase their scope of infections through the use of lures and other social engineering avenues. Users are reminded to be vigilant when clicking links and opening documents, as it is common for criminals to leverage these conflicts as cover for monetary gain.

Talos is well-versed in monitoring wartime environments with our ongoing work in Ukraine and across the globe. We will remain vigilant looking to identify any cyber related activity relevant to the region. If and/or when more relevant information becomes available, we will update this blog accordingly.

Guidance

Recommendations for organizations are currently focused on security hygiene, to include having multi-factor authentication (MFA) enabled, being diligent around any links or documents that are circulating, and ensuring you have proper monitoring in place to ensure you are prepared for any collateral impacts as they arise.

Since this activity appears to be regionally focused, making sure enterprises are aware of any impacts to partners and third-party suppliers in the region will be paramount. Additional inspection or controls may be warranted to insulate potential larger impacts to the wider organization.

Employee awareness: Beware of “hacktivist” lures

  • Warn employees against clicking on unsolicited links related to the Middle East conflict, whether news or humanitarian. These are often infostealers or backdoors in disguise and meant to take advantage of emotions.
  • Increase the frequency of phishing simulations that use current geopolitical lures to keep staff vigilant against social engineering.

Third-party risk assessment

  • Map your dependencies. Identify any vendors, service providers, or developers located in or heavily connected to the Middle East conflict zone.
  • Enforce strict MFA for all third-party access and conduct “zero-trust” audits on any administrative tools that have deep access to your environment.

Mitigate “nuisance” attacks and defacements

  • Protect your public-facing brand. Use a Content Delivery Network (CDN) with robust DDoS mitigation and ensure all web content management systems (CMS) are fully patched.

As always, ensure all software has been updated to the latest versions to minimize the attack surface and ensure you have a robust patching process. Many updated software versions have improvements in security and visibility capabilities that can help in cyber defense.

Cisco Talos Blog – ​Read More

CVE-2026-3102: macOS ExifTool image-processing vulnerability | Kaspersky official blog

Can a computer be infected with malware simply by processing a photo — particularly if that computer is a Mac, which many still believe (wrongly) to be inherently resistant to malware? As it turns out, the answer is yes — if you’re using a vulnerable version of ExifTool or one of the many apps built based on it. ExifTool is a ubiquitous open-source solution for reading, writing, and editing image metadata. It’s the go-to tool for photographers and digital archivists, and is widely used in data analytics, digital forensics, and investigative journalism.

Our GReAT experts discovered a critical vulnerability — tracked as CVE-2026-3102 — which is triggered during the processing of malicious image files containing embedded shell commands within their metadata. When a vulnerable version of ExifTool on macOS processes such a file, the command is executed. This allows a threat actor to perform unauthorized actions in the system, such as downloading and executing a payload from a remote server. In this post, we break down how this exploit works, provide actionable defense recommendations, and explain how to verify if your system is vulnerable.

What is ExifTool?

ExifTool is a free, open-source application addressing a niche but critical requirement: it extracts metadata from files, and enables the processing of both that data and the files themselves. Metadata is the information embedded within most modern file formats that describes or supplements the main content of a file. For instance, in a music track, metadata includes the artist’s name, song title, genre, release year, album cover art, and so on. For photographs, metadata typically consists of the date and time of a shot, GPS coordinates, ISO and shutter speed settings, and the camera make and model. Even office documents store metadata, such as the author’s name, total editing time, and the original creation date.

ExifTool is the industry leader in terms of the sheer volume of supported file formats, as well as the depth, accuracy, and versatility of its processing capabilities. Common use cases include:

  • Adjusting dates if they’re incorrectly recorded in the source files
  • Moving metadata between different file formats (from JPG to PNG and so on)
  • Pulling preview thumbnails from professional RAW formats (such as 3FR, ARW, or CR3)
  • Retrieving data from niche formats, including FLIR thermal imagery, LYTRO light-field photos, and DICOM medical imaging
  • Renaming photo/video (etc.) files based on the time of actual shooting, and synchronizing the file creation time and date accordingly
  • Embedding GPS coordinates into a file by syncing it with a separately stored GPS track log, or adding the name of the nearest populated area

The list goes on and on. ExifTool is available both as a standalone command-line application and an open-source library, meaning its code often runs under the hood of powerful, multi-purpose tools; examples include photo organization systems like Exif Photoworker and MetaScope, or image processing automation tools like ImageIngester. In large digital libraries, publishing houses, and image analytics firms, ExifTool is frequently used in automated mode, triggered by internal enterprise applications and custom scripts.

How CVE-2026-3102 works

To exploit this vulnerability, an attacker must craft an image file in a certain way. While the image itself can be anything, the exploit lies in the metadata — specifically the DateTimeOriginal field (date and time of creation), which must be recorded in an invalid format. In addition to the date and time, this field must contain malicious shell commands. Due to the specific way ExifTool handles data on macOS, these commands will execute only if two conditions are met:

  • The application or library is running on macOS
  • The -n (or –printConv) flag is enabled. This mode outputs machine-readable data without additional processing, as is. For example, in -n mode, camera orientation data is output simply, inexplicably, as “six”, whereas with additional processing, it becomes the more human-readable “Rotated 90 CW”. This “human-readability” prevents the vulnerability from being exploited

A rare but by no means fantastical scenario for a targeted attack would look like this: a forensics laboratory, a media editorial office, or a large organization that processes legal or medical documentation receives a digital document of interest. This can be a sensational photo or a legal claim — the bait depends on the victim’s line of work. All files entering the company undergo sorting and cataloging via a digital asset management (DAM) system. In large companies, this may be automated; individuals and small firms run the required software manually. In either case, the ExifTool library must be used under the hood of this software. When processing the date of the malicious photo, the computer where the processing occurs is infected with a Trojan or an infostealer, which is subsequently capable of stealing all valuable data stored on the attacked device. Meanwhile, the victim could easily notice nothing at all, as the attack leverages the image metadata while the picture itself may be harmless, entirely appropriate, and useful.

How to protect against the ExifTool vulnerability

GReAT researchers reported the vulnerability to the author of ExifTool, who promptly released version 13.50, which is not susceptible to CVE-2026-3102. Versions 13.49 and earlier must be updated to remediate the flaw.

It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.

Naturally, ExifTool — like any software — may contain additional vulnerabilities of this class. To harden your defenses, we also recommend the following:

  • Isolate the processing of untrusted files. Process images from questionable sources on a dedicated machine or within a virtual environment, strictly limiting its access to other computers, data storage, and network resources.
  • Continuously track vulnerabilities along the software supply chain. Organizations that rely on open-source components in their workflows can use Open Source Software Threats Data Feed for tracking.

Finally, if you work with freelancers or self-employed contractors (or simply allow BYOD), only allow them to access your network if they have a comprehensive macOS security solution installed.

Still think macOS is safe? Then read about these Mac threats:

Kaspersky official blog – ​Read More

This month in security with Tony Anscombe – February 2026 edition

In this roundup, Tony looks at how opportunistic threat actors are taking advantage of weak authentication, unmanaged exposure, and popular AI tools

WeLiveSecurity – ​Read More

Mobile app permissions (still) matter more than you may think

Start using a new app and you’ll often be asked to grant it permissions. But blindly accepting them could expose you to serious privacy and security risks.

WeLiveSecurity – ​Read More

Local KTAE and the IDA Pro plugin | Kaspersky official blog

In a previous post, we walked through a practical example of how threat attribution helps in incident investigations. We also introduced the Kaspersky Threat Attribution Engine (KTAE) — our tool for making an educated guess about which specific APT group a malware sample belongs to. To demonstrate it, we used the Kaspersky Threat Intelligence Portal — a cloud-based tool that provides access to KTAE as part of our comprehensive Threat Analysis service, alongside a sandbox and a non-attributing similarity-search tool. The advantages of a cloud service are obvious: clients don’t need to invest in hardware, install anything, or manage any software. However, as real-world experience shows, the cloud version of an attribution tool isn’t for everyone…

First, some organizations are bound by regulatory restrictions that strictly forbid any data from leaving their internal perimeter. For the security analysts at these firms, uploading files to a third-party service is out of the question. Second, some companies employ hardcore threat hunters who need a more flexible toolkit — one that lets them work with their own proprietary research alongside Kaspersky’s threat intelligence. That’s why KTAE is available in two flavors: a cloud-based version and an on-prem deployment.

What are the on-prem KTAE advantages over the cloud version?

First off, the local version of KTAE ensures an investigation stays fully confidential. All the analysis takes place right in the organization’s internal network. The threat intelligence source is a database deployed inside the company perimeter; it is packed with the unique indicators and attribution data of every malicious sample known to our experts; and it also contains the characteristics pertaining to legitimate files to exclude false-positive detections. The database gets regular updates, but it operates one-way: no information ever leaves the client’s network.

Additionally, the on-prem version of KTAE gives experts the ability to add new threat groups to the database and link them to malware samples they discovered on their own. This means that subsequent attribution of new files will account for the data added by internal researchers. This allows experts to catalog their own unique malware clusters, work with them, and identify similarities.

Here’s another handy expert tool: our team has developed a free plugin for IDA Pro, a popular disassembler, for use with the local version of KTAE.

What’s the purpose of an attribution plugin for a disassembler?

For a SOC analyst on alert triage, attributing a malicious file found in the infrastructure is straightforward: just upload it to KTAE (cloud or on-prem) and get a verdict, like Manuscrypt (83%). That’s sufficient for taking adequate countermeasures against that group’s known toolkit and assessing the overall situation. A threat hunter, however, might not want to take that verdict at face value. Alternatively, they might ask, “Which code fragments are unique across all the malware samples used by this group?” Here an attribution plugin for a disassembler comes in handy.


Inside the IDA Pro interface, the plugin highlights the specific disassembled code fragments that triggered the attribution algorithm. This doesn’t just allow for a more expert-level deep dive into new malware samples; it also lets researchers refine attribution rules on the fly. As a result, the algorithm — and KTAE itself — keeps evolving, making attribution more accurate with every run.

How to set up the plugin

The plugin is a script written in Python. To get it up and running you need IDA Pro. Unfortunately, it won’t work in IDA Free, since it lacks support for Python plugins. If you don’t have Python installed yet, you’d need to grab that, set up the dependencies (check the requirements file in our GitHub repository), and make sure IDA Pro environment variables are pointing to the Python libraries.

Next, you’d need to insert the URL for your local KTAE instance into the script body and provide your API token (which is available on a commercial basis) — just like it’s done in the example script described in the KTAE documentation.

Then you can simply drop the script into your IDA Pro plugins folder and fire up the disassembler. If you’ve done it right, then, after loading and disassembling a sample, you’ll see the option to launch the Kaspersky Threat Attribution Engine (KTAE) plugin under EditPlugins:

How to use the plugin

When the plugin is installed, here’s what happens under the hood: the file currently loaded in IDA Pro is sent via API to the locally installed KTAE service, at the URL configured in the script. The service analyzes the file, and the analysis results are piped right back into IDA Pro.

On a local network, the script usually finishes its job in a matter of seconds (the duration depends on the connection to the KTAE server and the size of the analyzed file). Once the plugin wraps up, a researcher can start digging into the highlighted code fragments. A double-click leads straight to the relevant section in the assembly or binary code (Hex view) for analysis. These extra data points make it easy to spot shared code blocks and track changes in a malware toolkit.

By the way, this isn’t the only IDA Pro plugin the GReAT team has created to make life easier for threat hunters. We also offer another IDA plugin that significantly speeds up and streamlines the reverse-engineering process, and which, incidentally, was a winner in the IDA Plugin Contest 2024.

To learn more about the Kaspersky Threat Attribution Engine and how to deploy it, check out the official product documentation. And to arrange a demonstration or piloting project, please fill out the form on the Kaspersky website.

Kaspersky official blog – ​Read More