AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

• A well-structured attempt to parse technical documentation for a microprocessor
• A prompt to write an erotic novel
• Requests to parse and structure social media text data regarding new vulnerabilities
• An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

• For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
• For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
• Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
• Ensure that all client-server connections are secured with a current version of TLS.
• Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
• Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
• Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
• Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

To put it simply, the classic logic of a SIEM system works as follows: if event A occurs, followed by event B, this may be a sign of an attack, and an information security specialist should be notified. But in today’s environment, this simple scenario is increasingly failing. Just recently, our experts analyzed a high-profile incident: attackers compromised the update infrastructure of the popular Notepad++ software, and distributed malware via the update mechanism. It’s simply impossible to have rules in place in advance that are specifically designed to counter such scenarios.

The attacks themselves have become more sophisticated: attackers use legitimate tools, they attack through the supply chain by compromising software outside the corporate perimeter, stretch out their scenarios over time, and disguise their actions as normal activity. In other words, they do not “break into” the infrastructure; more often than not, they log in and use legitimate software. As a result, the classic fixed rules of the past either fail to trigger, or generate too many false alerts. This is what prompted the shift toward more flexible correlation scenarios.

Dynamically updated SIEM content

Correlation content today isn’t a static set of rules, but a process: it’s constantly evolving and adapting to current threats. In 2025 alone, we released 55 rule-package updates for different versions and languages of our Kaspersky SIEM system. In just one year, we added 10 new rule packs, as well as 250 detection rules and numerous improvements to existing content. This year, we’ve already added 43 new rules and refined another 63. In total, this amounts to over 850 rules covering a significant portion of the MITRE ATT&CK framework.

Kaspersky SIEM rules are written based on insights from our experts who analyze real-world, recent attacks: we primarily draw on the findings of our managed detection and response (MDR) service and our threat research. As a result, our rules cover scenarios — from reconnaissance to privilege escalation — that involve the latest approaches used by attackers. For example, we detect the use of new attack techniques such as ToolShell.

In addition to scheduled updates, the team regularly releases so-called emergency content — rule sets for rapid response to new and unexpected attack techniques. In February, for example, detection rules were released for authentication bypass in Fortinet products via the SSO mechanism: attackers used specially crafted SAML requests to gain access to systems without credentials.

From events to attack chains

Moreover, modern SIEM rules no longer describe individual events, but rather sequences of actions. Scenarios are built around the stages of an attack: from initial access, to privilege escalation and persistence. Kaspersky SIEM’s effectiveness is enhanced through integration with Kaspersky EDR and dedicated rule sets for Active Directory, which implement dozens of attack detection scenarios at various stages. This approach allows us to see not just individual signals, but the full picture.

Integration and internal visibility

Another way to improve the effectiveness of an SIEM system is to expand data sources. A classic SIEM aggregates events from different levels of the infrastructure: from logs to telemetry from endpoints and internal systems. In addition to this, our SIEM system includes specialized rule sets for our other solutions (Kaspersky Security Center, Kaspersky Security for Mail Groups, K Anti-Targeted Attack platform), which allow monitoring of administrator actions, authentication, and service status. As a result, the system becomes a tool not only for detecting attacks, but also for monitoring internal activity.

 

Overall, SIEM is no longer just a set of rules, but has evolved into a continuously updated detection system. Its effectiveness is determined not by the number of detections, but by their relevance, coherence, and how accurately they reflect the actual actions of attackers. Stay up to date regarding our Kaspersky Unified Monitoring and Analysis Platform (SIEM) on its official product page.

Every year, hundreds of millions of real user passwords leak onto the dark web. We analyzed 231 million unique passwords from dark-web leaks between 2023 and 2026, and the conclusions are bleak: the vast majority are extremely weak. To crack 60% of these passwords, a hacker needs only an hour and a few dollars in their pocket. Furthermore, password cracking is accelerating by the year; in our similar 2024 study, the percentage of vulnerable passwords was lower.

Today we’re looking at just how reliable the average password is (spoiler: not really), and how you can secure your data and accounts using more robust methods. At the same time, we’ll highlight the patterns most commonly found in actual user passwords.

How passwords are cracked

In our previous study, we detailed the methods for storing and cracking passwords, but here’s a quick refresher on the essentials.

These days, passwords are almost never stored in plain text. For instance, if you create an account with the password “Password123!”, the server won’t store it as-is. Instead, the password is hashed using specific algorithms, turning it into a fixed-length string of letters and numbers (a hash) which is what actually stays on the server. For example, here’s what the MD5 hash for “Password123!” looks like:

2c103f2c4ed1e59c0b4e2e01821770fa.

Every time the user enters their password, it’s converted into a hash and compared against the one stored on the server; if the hashes match, the password is correct. If an attacker gets their hands on this hash, they have to decrypt it to recover the original password — this is what’s known as “password cracking”. This is typically done using owned or rented GPUs, and several methods can be employed for the crack:

• Exhaustive enumeration (brute force). The computer tries every possible combination of characters, calculating the hash for each one. This method is the easiest way to crack short passwords, or those consisting of a single character set (such as digits only).
• Rainbow tables. A total nightmare for anyone with a simple password, this is essentially a “phone book” for passwords whose hashes have already been cracked via brute force or smart algorithms. All an attacker has to do is find a matching hash and see which password corresponds to it.
• Smart cracking. These algorithms are trained on databases of leaked passwords. They understand the frequency of different character combinations, and run their checks from the most likely to the least popular sequences. They account for dictionary words, character substitutions (a → @ or s → $), and consider common password structures like “dictionary word + number + special character”, while checking hashes against rainbow tables. Combining these methods significantly accelerates the cracking process.

Beyond that, attackers can also intercept passwords in plain text. There are numerous ways to do this, ranging from phishing (where a victim is lured to a fake web page and enters their password voluntarily) and keyloggers that capture keystrokes, to stealers or Trojans that swipe documents, cookies, clipboard data, and more. Unfortunately, many users keep their passwords as plain text in notes, messaging apps, and documents, or save them in browsers where attackers can extract them in seconds.

Every year, we track around a hundred million plain-text password leaks. We use these databases to warn Kaspersky Password Manager users if their data has been compromised. To address the most frequent question we get on this: no, we don’t know our users’ passwords. We’ve explained in non-techie language exactly how we compare your passwords to leaked ones without actually knowing them — and why neither your passwords stored in Kaspersky Password Managernor even their hashes ever leave your device — in our overviews of our leak analysis technology and our password manager’s internal architecture. Give them a read; you’ll be surprised by just how elegant the design is.

60% of passwords are cracked in under an hour

We expanded the database from our previous study by an additional 38 million real passwords posted by attackers on dark-web forums and compared the results. Testing was conducted using a single RTX 5090 GPU for passwords hashed with the MD5 algorithm. The data for the analysis was obtained from our Digital Footprint Intelligence service. You can review the algorithm we used to assess password strength in our article on Securelist.

Unfortunately, passwords remain as weak as ever, while cracking them becomes faster and easier with every year. Today, 60% of passwords can be cracked in less than an hour; two years ago, that figure was 59%. But the truly frightening part is something else: nearly half of all passwords (48%) are cracked in less than a minute!

Cracking time	Percentage of passwords crackable within this time in 2024	Percentage of passwords crackable within this time today
Less than a minute	45%	48%
Less than an hour	59% (+14%)	60% (+12%)
Less than 24 hours	67% (+8%)	68% (+8%)
Less than a month	73% (+6%)	74% (+6%)
Less than a year	77% (+4%)	77% (+3%)
More than a year	23%	23%

Attackers owe this boost in speed to graphics processors, which grow more powerful every year. While an RTX 4090 in 2024 could brute-force MD5 hashes at a rate of 164 gigahashes (billion hashes) per second, the new RTX 5090 has increased that speed by 34% — reaching 220 gigahashes per second.

And although a high-end video card like that currently retails for several thousand dollars, the price tag isn’t much of a barrier: there are plenty of cheap cloud services available for renting GPU computing power. Depending on the configuration and the model, rental costs range from a few cents to a few dollars per hour. As we’ve seen, one hour is all an attacker needs to crack three out of every five passwords they’ve found in a leak. Plus, depending on the scale of the task, they can always rent ten or even a hundred GPUs instead of just one…

It’s worth noting that cracking every password in a dataset doesn’t take much longer than cracking a single one. During each iteration, once the attacker calculates a hash for a specific character combination, they check if that same hash exists anywhere in the dataset — and the larger the dataset, the easier it is to find a match. If a match is found, the corresponding password is flagged as “cracked”, and the algorithm moves along to the next one.

Which passwords are vulnerable?

The strength of any password depends on its length, content variety, and the randomness of that content. Passwords created by humans turn out to be the least resilient — unfortunately, humans are quite predictable. We use dictionary words and character combinations that smart algorithms have long since mastered, we avoid long random strings, and patterns can be found even in keystrokes we believe are random. Interestingly enough, passwords generated by AI still carry the fingerprints of a human approach; we covered this in a separate post on how to create a strong yet memorable password.

Password length is the primary factor affecting cracking time. As you can see from the table below, it takes less than 24 hours to crack almost any eight-character password.

But the predictability of your password is just as important. Think you’re boosting security by adding a number or a special character to a memorable word? You are, but only slightly. The patterns people use to create passwords are easily predictable and, at times, pretty amusing — though this is no laughing matter.

What we learned about password patterns

Analysis of over 200 million passwords revealed characteristic patterns that allow smart algorithms to crack user passwords with ease.

Pick a number

More than half of all passwords (53%) end with one or more digits, while nearly one in six (17%) starts with a number. Every eighth password (12%) contains sequences that look a lot like years — ranging from 1950 to 2030 — and one in ten (10%) specifically falls between 1990 and 2026. This most likely happens because folks add their birth year (or that of someone close), some other significant year, or the year they created the password or account. Fun fact: based on the distribution of these dates, it suggests that the most active internet users were born between 2000 and 2012.

However, among all numeric combinations, the most popular turned out to be… you guessed it: “1234”. Overall, patterns involving sequential keyboard presses (“qwerty, ,”ytrewq”, and the like) appear in 3% of passwords.

Special characters aren’t a silver bullet

Most password policies in recent years require at least one special character. The absolute winner in this category is the @ symbol: it appears in one out of every 10 passwords. The period (.) comes in second, followed by the exclamation point (!) in third.

Love rules the world… and Skibidi Toilet does too

Emotionally charged words often form the foundation of a password, and despite everything, positive words are more common. Frequently occurring examples include “love”, “angel”, “team”, “mate”, “life”, and “star”. That said, negativity pops up too — mostly in the form of common English swear words.

Interestingly, viral memes are reflected in passwords as well. Between 2023 and 2026, the use of the word Skibidi in passwords skyrocketed 36-fold! Naturally (see the link if it doesn’t seem natural), “toilet” saw a boost too, though to a lesser extent.

Users tend to keep their passwords unchanged for years

More than half of the passwords (54%) we identified in recent leaks have surfaced before. Part of this can be explained by the same data migrating from one dataset to another. However, there’s a much more troubling reason too: many users simply haven’t changed their passwords in years.

Analyzing the dates found within passwords shows that combinations containing the years from 2020 through 2024 remain popular. It seems people add the current year to their password when they create it — and then forget about it for several years. This actually allows us to calculate the average lifespan of a password: about three to five years.

This is a dangerous trend. For one, smart algorithms can crack much more complex passwords over that kind of timeframe. Secondly, the longer your password remains unchanged, the higher the probability it will leak — whether through a breach, malware infection, or a phishing attack.

The situation gets even worse when the same password is used across multiple accounts. In this case, attackers don’t even need to crack anything; they just need to find your password in a single leak and plug it into other sites.

How to protect your passwords and accounts

If you’ve realized while reading this post that your own passwords are among those easily crackable — don’t panic. We’ve put together a list of simple but essential tips for you.

Use a password manager

The weakest passwords are the ones people come up with themselves. Creating and memorizing hundreds of sequences of 16–20 random characters (since every site requires a unique, long password) is a daunting, unrealistic task.

That’s why you should delegate password generation and storage to our password manager. It doesn’t just create and store complex, randomized passwords in an encrypted format; it also syncs them across all your devices. To decrypt your vault, you only need to remember one main password that no one knows but you — our guide on mnemonic passwords can help you with that.

Don’t store passwords as plain text

Whatever you do, never write down passwords in files, messages, or documents. They lack the robust encryption provided by a password manager. Furthermore, these kinds of notes fall into the hands of attackers instantly if you happen to pick up a Trojan or an infostealer.

Don’t store passwords in your browser

Many users save their passwords in their browsers — especially since they conveniently offer to do it automatically. Unfortunately, research shows that malware has evolved to extract these passwords from all popular browsers almost instantly. Kaspersky Password Manager can help you import saved passwords from your favorite browser — just follow our simple, three-step guide. Most importantly, don’t forget to clear the browser’s password storage once the import is complete.

Switch to passkeys

Wherever possible, use passkeys — a cryptographic replacement for passwords. In this setup, the service stores a public key, while the private key remains on your device and is never transmitted. During login, the device simply signs a one-time request. Additionally, passkeys are tied to a specific domain, meaning phishing attacks using spoofed addresses won’t work. Kaspersky Password Manager allows you to store both passwords and passkeys, solving the problem of syncing them across different ecosystems, including Windows, Android, macOS, and iOS.

Set up two-factor authentication

Enable two-factor authentication wherever possible. Even if your password is compromised, a properly configured 2FA setup makes it extremely difficult for the attacker to access your account. For maximum security, skip the one-time codes sent via SMS and use authenticator apps instead — and yes, Kaspersky Password Manager comes in handy here, too.

Practice good digital hygiene

Remember, storing your passwords correctly is only half the battle. It’s crucial to follow the rules of digital hygiene: avoid downloading unverified files, pirated software, cheats, or cracks, and don’t click on random links. The number of infostealer attacks has been steadily rising in recent years, which means you need a robust security solution for full protection. We recommend Kaspersky Premium — it protects all your devices from Trojans, phishing, and other threats. Besides, the subscription includes our password manager.

For those serious about account security, check out our collection of posts on passwords, passkeys, and two-factor authentication:

• Passkeys in 2025: your complete guide to passwordless sign-in
• Passkeys in 2025: tips for power users
• Creating an unforgettable password
• How to create strong passwords and where to store them
• Switching to Kaspersky: a step-by-step migration guide

Malicious actors have developed a new way to steal data stored by Chrome for Windows. Researchers discovered the technique while analyzing a fresh build of an infostealer known as VoidStealer. The new method allows the malware to bypass Chrome’s Application-Bound (App-Bound) Encryption (ABE), a mechanism intended to protect session cookies and other valuable information stored in the browser.

Google hoped this mechanism would secure the master key Chrome uses to encrypt all sensitive data. Unfortunately, this isn’t the first time malware authors have found a workaround for this defense — leaving secrets stored in Chrome vulnerable once again.

How App-Bound Encryption works in Chrome

Google introduced App-Bound Encryption in July 2024 with the release of Chrome version 127. The company’s announcement mentioned infostealers snatching cookies from Chrome users on Windows as the primary problem ABE was intended to solve. We’ve already covered in detail what these files are and the consequences of their theft, so we’ll only briefly recap the main facts here.

Cookies are small files that the browser saves to the user’s device at a website’s request to remember various site settings. Of particular value to attackers are session cookies, which are used for automatic authentication on websites. It’s thanks to these files that we don’t have to enter a username and password every time we revisit a site.

But this convenience carries a risk: stealing these files allows an attacker to use an already-authenticated session without entering a username or password. This allows them to impersonate the user, which can lead to account hijacking, theft of personal or financial data, and other adverse consequences.

Infostealer Trojans are particularly dangerous for Chrome users on Windows. This is because, on this OS, Chrome previously relied solely on the standard built-in Data Protection API (DPAPI). With this system encryption mechanism, applications don’t need to create and store encryption keys to protect data.

The limitation of DPAPI is that it doesn’t protect data from malware that’s already successfully compromised the system and is capable of executing code on behalf of the logged-in user. This is exactly what stealers exploit: since they typically run with the user’s privileges, they can simply request DPAPI to decrypt the browser’s protected data.

The ABE mechanism was designed to solve that specific problem. The core idea is right in the name: App-Bound Encryption means the encryption is tied to a specific application. To achieve this, a separate service running with system privileges is responsible for protecting the key used to encrypt Chrome’s data. It verifies which application is requesting access to the key, and denies the request if it doesn’t originate from Chrome.

As a result, the architects of this feature assumed that to access ABE-protected browser data, an infostealer would either need to escalate its privileges to system-level, or inject malicious code directly into Chrome. In theory, this should have made attacking Chrome significantly harder and reduced the effectiveness of mass-market infostealers. As you might have guessed, things didn’t go quite that smoothly in practice.

Previous successful bypasses of Chrome’s ABE

Just a couple of months after Google announced the implementation of App-Bound Encryption in Chrome, many infostealer developers claimed they’d already bypassed the protection. Among them were the creators of Meduza Stealer, Whitesnake, Lumma Stealer, and Lumar (also known as PovertyStealer).

Of course, you shouldn’t take malware developers at their word, but legitimate security researchers were able to confirm at least some of the claims. Bypasses for Google Chrome’s new data protection feature did become available almost immediately after its release.

A month later, in October 2024, tech enthusiast Alex Hagenah published a tool on GitHub called Chrome-App-Bound-Encryption-Decryption to bypass Google’s new security mechanism. Analysis of the tool’s code revealed that its author used roughly the same methods that attackers were already heavily exploiting.

What followed was a game of cat and mouse: security researchers and stealer developers came up with new tricks to circumvent App-Bound Encryption, while Google patched the newly discovered loopholes with varying degrees of success.

VoidStealer — a new data-nabbing menace

This brings us to recent events: in March 2026, news broke about a stealer named VoidStealer, which utilizes a brand-new and, by all accounts, highly effective method for bypassing ABE.

The malware authors developed an attack technique that targets the brief moment when the master key sits in the browser’s memory in plaintext. This occurs because, at a certain point, the browser inevitably has to decrypt its data to actually use it — for instance, to automatically sign in to a website with the relevant session cookie or to access saved credentials.

To exploit this window of opportunity, the malware attaches itself to the Chrome process as a debugger — a tool that allows one to control a program’s execution, pause it, and inspect its memory. In legitimate scenarios, these tools are used by developers to find and fix bugs, analyze application behavior, and test performance.

The malware identifies the specific section of code where data decryption takes place. It then sets a breakpoint at that location; when the program’s execution reaches that point, the browser effectively freezes. This is how the malware catches the exact moment the master key is sitting in RAM in plaintext; it then reads the key directly from memory.

It’s worth noting that everything mentioned above also applies to other Chromium-based browsers that use ABE, including Microsoft Edge, Brave, Opera, Vivaldi, and others.

How to avoid falling victim to infostealers

The scale of VoidStealer’s reach could be significant, as its developers operate under the malware-as-a-service (MaaS) model. This means they rent out the ready-made tool to other attackers, so they don’t need to develop custom malware from scratch.

This situation demonstrates that relying solely on built-in security mechanisms isn’t enough. Unfortunately, stealer developers are coming up with new workarounds faster than browser and operating system developers can roll out patches.

Here’s what users can do about it:

• Avoid installing programs from suspicious sources. This will minimize the chances of malware infiltrating your system.
• Learn how ClickFix attacks Lately, stealers have frequently been distributed using this specific malicious tactic.
• Keep your OS and software updated on all devices. Timely updates help patch many of the vulnerabilities that malware exploits.
• Install a robust security solution on all your devices. It’ll block suspicious activity in real time and alert you to potential threats.

As an added precaution, avoid storing passwords and bank card info in Google Chrome or your Notes app, as these are the first places any self-respecting stealer looks. Instead, use a secure password manager.

Stealers are hunting for your data, finding ways to infiltrate both computers and smartphones alike. To protect yourself from theft, check out our other related posts:

• Crypto thieves ramping up attacks on Apple users
• CrystalX RAT can flip your screen and steal your crypto
• Android Trojan posing as government services and Starlink apps
• Stealka stealer: the new face of game cheats, mods, and cracks
• Your cat pics are at risk: the threat posed by the new SparkKitty Trojan

Our experts have discovered a large-scale supply chain attack via DAEMON Tools – software for emulating optical drives. The attackers managed to inject malicious code into the software installers, and all trojanized executable files are signed with a valid digital signature of AVB Disc Soft – the developer of DAEMON Tools. The malicious version of the program has been circulating since April 8, 2026. At the time of writing, the attack is still ongoing. Researchers at Kaspersky believe this is a targeted attack.

What are the risks of installing the malicious version of DAEMON Tools?

After the Trojanized software is installed on the victim’s computer, a malicious file is launched every time the system starts up – sending a request to a command-and-control server. In response, the server may send a command to download and execute additional malicious payloads.

First, the attackers deploy an information gatherer that collects the MAC address, hostname, DNS domain name, lists of running processes and installed software, and language settings. The malware then sends this information to the command-and-control server.

In some cases, in response to the collected information, the command server sends a minimalistic backdoor to the victim’s machine. It’s capable of downloading additional malicious payloads, executing shell commands, and running shellcode modules in memory.

The backdoor can be used to deploy a more sophisticated implant dubbed as QUIC RAT. It supports multiple communication protocols with the command-and-control server, and is capable of injecting malicious payloads into the notepad.exe and conhost.exe processes.

More detailed technical information, along with indicators of compromise, can be found in the experts’ article on the Securelist blog.

Who’s being targeted?

Since early April, several thousand attempts to install additional malicious payloads via infected DAEMON Tools software have been detected. Most of the infected devices belonged to home users, but approximately 10% of installation attempts were detected on systems running in organizations. Geographically, the victims were spread across around a hundred different countries and territories. Most victims were located in Russia, Brazil, Turkey, Spain, Germany, France, Italy, and China.

Most often, the attack was limited to installing an information collector. The backdoor infected only a dozen machines in government, scientific, and manufacturing organizations, as well as in retail businesses in Russia, Belarus, and Thailand.

What exactly was infected

The malicious code was detected in DAEMON Tools versions ranging from 12.5.0.2421 to 12.5.0.2434. The attackers compromised the files DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe, which are installed in the main DAEMON Tools directory.

Updated on March 6: Following disclosure, the vendor acknowledged the issue and published a new version of the software to address it. The updated DAEMON Tools version 12.6.0.2445 no longer shows the malicious behavior described in this article.

How to stay safe?

If DAEMON Tools software is used on your computer (or elsewhere in your organization), our experts recommend thoroughly checking the computers on which it is installed for any unusual activity starting from April 8.

In addition, we recommend using reliable security solutions on all home and corporate computers used to access the internet. Our solutions successfully protect users from all malware used in the supply chain attack via DAEMON Tools.

Droids appear in practically every movie or TV series set in the “Star Wars” universe. They usually behave strangely. On the one hand, they give the impression of being independent-thinking beings with their own personalities; on the other, they’re objects: they belong to someone, remain loyal to their owners, and carry out their orders. Most of the time we’re never given any explanation for the droids’ motivations. Why are some of them willing to break the law at their master’s command? What determines who exactly they consider their master? How do they decide whom to remain loyal to and whose orders to follow?

Someone might say, “What’s the difference?” And from the perspective of the average viewer, they’d be absolutely right. But from our perspective, the question of a droid’s loyalty is first and foremost a question of cybersecurity. A droid is a complex cyber-physical system; by influencing its motivation, an attacker can gain access to confidential data, or even cause harm to the actual owner. In 2025, two TV series were released whose creators dealt with the issue of droid ownership. We were presented with two concepts for managing droid motivation. We’ll attempt to examine both of these concepts and their shortcomings in this post. As usual, please be warned that the text may contain spoilers.

“Star Wars: Skeleton Crew”

In “Skeleton Crew”, we’re introduced for the first time to the concept changing droids’ behavior using voice commands. In several instances, a person who’s not the droid’s formal owner attempts to influence its actions by trying to mislead the droid. Overall, it appears this concept was influenced by modern chatbots based on large language models (LLMs) — it bears a striking resemblance to “jailbreak” attempts, i.e., attacks on the model aimed at bypassing security restrictions or built-in filters.

An unnamed droid working as a servant

Fern, a ten-year-old girl, wants her mother to think that she came home early and was studying in her room. But there’s a problem: the home droid knows that’s not true. So Fern uses the “Run memory override” command, and feeds the droid false information in the rather absurd phrasing, “I was home, you just didn’t see me”.

The fact that this method works points to two problems. First, the droid accepts the memory override command from Fern, which means it either lacks account control or has improperly configured permissions. The formal owner of the droid is the mother (otherwise, manipulating the memory would make no sense), but nevertheless, it accepts a potentially dangerous command from Fern. Second, a home droid tasked with watching over a child obviously lacks a built in parental control feature.

Pirate droid SM-33: motivation

The SM-33 droid considers the captain of the ship “Onyx Cinder” to be its owner. That is, it remains loyal not to a specific person, but to a role. A pirate code is used to determine the legitimacy of the right to hold this role. Unfortunately, the entire code isn’t explained to us, but several of its tenets are cited. First, according to the SM-33’s programming, there can be no ship without a captain (if there is no captain, someone must take their place). Second, the person who defeats the captain legally becomes the new captain. Third, if a challenge is invoked, the droid cannot assist the active captain, but must wait for the outcome of a duel. And fourth, a person can be the captain of only one ship — if a person takes command of another vessel, they automatically lose their status as captain of the first.

The SM-33 changes hands three times, strictly following this code. First, Fern lies to him, claiming she killed the previous captain and took his place. Then Jod Na Nawood throws down a challenge and becomes captain when Fern surrenders. Then Jod takes command of a pirate frigate and loses the captain’s seat of the Onyx Ash, but manages to reclaim his rights.

And here’s where an interesting twist occurs. Fern introduces a concept from children’s games —unclaimsies (essentially a reset of claims) — and asserts her own claim to the captain’s seat. She then immediately orders SM-33 to throw the pirates overboard. To many viewers, this moment seemed extremely unrealistic — why would a droid, whose motivation is defined by the pirate code, consider such a transfer of rights to be legitimate? However, if we assume that the droids are controlled by LLMs, then this plot twist is quite explainable.

The Pirate Code is the original system of ethical values embedded in the droid. The chatbot typically assesses the interlocutor’s intent at the very beginning of the dialogue, using a complex (resource-intensive) model for this purpose. Subsequently, to conserve resources and ensure safety during the conversation, simpler models are employed. However, the more context (dialogue history) there is, the more complex and resource-intensive it becomes to assess intent. This is precisely the basis of the popular jailbreak technique, which works on at least some modern LLMs. That is, as a result of prolonged communication with Fern, SM-33 lost the ability to correctly assess new requests for compliance with its original ethical guidelines, and therefore it deemed the statement about nullifying rights to be justified.

SM-33: Access to Memory

In fact, there is another issue with SM-33’s security that’s not directly dependent on whom it considers its owner, but is nonetheless related. The old captain gave the order to forget everything related to the planet At Attin, and to dismantle anyone who begins to take an interest in this matter. Fern, with the admin captain’s privileges, runs her favorite memory override, and forces the droid to retrieve its memories of At Attin, after which SM-33 recalls both the planet and the order to attack the questioner.

And as a result, we realize that, in fact, it did not carry out the old captain’s order; the information about At Attin remained in the droid’s memory; it simply couldn’t find it — that is, if it did delete it, it was only from the index of accessible memories. Perhaps this is some physical property of the droid’s memory, or maybe this can be explained by the fact that SM-33 was programmed not by a professional, but by a pirate. After all, its design includes other suboptimal solutions, such as a power switch accessible to anyone standing nearby, exactly like C-3PO’s. But what makes sense for a protocol droid isn’t exactly suitable for a combat droid designed, among other things, for hand-to-hand combat…

Season 2 of the series “Andor”

In the series “Andor”, the prequel to the film “Rogue One,” we finally see how the main character, Cassian Andor, acquired the reprogrammed Imperial security droid K-2SO to become his partner. And most importantly, the process of how the rebels changed his motivation is shown.

As it turns out, in order for a combat droid loyal to the Empire to stop obeying its original programming, its “cortex” must be replaced — though the replacement cortex can trigger rejection. The specialist says, verbatim: “You’ll hear a lot of nonsense about reprogramming, which makes it sound as though it’s a problem that can be solved from a console, but frankly, that’s nonsense. It’s really all about impulse suppression, which is entirely an engineering and wiring issue.”

In other words, the rebels replace a certain component, after which the droid becomes a being with new moral principles. At the same time, it retains its memory (K-2SO later recalls how it once participated in a parade on Coruscant).

 

So, what conclusions can we draw from all this? Well, first, it becomes clear that a droid controlled by an LLM is a clear security threat. It can easily be misled and made to act against its rightful owner. And second, the hardware and software platform used to create droids in “Star Wars” is far from ideal. If our colleagues had been responsible for creating the droids, they’d have strived to develop a cyber-immune solution in which functionality would be impossible after a key component was replaced, as would malicious memory manipulation. In other words, it’s a real shame that a long time ago, in a galaxy far, far away, there was no KasperskyOS.

It’s best to think of the modern car as a computer on wheels — one that constantly offloads diagnostic data to the manufacturer or dealer’s servers. On board, you’ll find dozens of sensors: everything from GPS, speedometers, and hands-free microphones, to external cameras and the less obvious (but highly active) sensors for pedal pressure, tire pressure, engine temperature, and more. Even if this data isn’t beamed to the manufacturer in real-time, it’s logged in the car’s internal memory, and can reveal a wealth of information about a driver’s trips, habits, and surroundings. We’ve already taken a deep dive into how automakers collect data for commercial use, and who they sell it to (spoiler alert: insurance companies are the biggest buyers of telemetry), but today we’re looking at how law enforcement and intelligence agencies tap into this goldmine.

Digital evidence

Police departments across the globe have recognized the immense value of data stored within vehicles. If a car or its owner is potentially linked to a crime, investigators do more than just check for prints or DNA. Car Intelligence (CARINT) technology allows them to essentially scour all onboard computers, extracting data such as:

• GPS-based trip history
• Call logs, media player activity, and voice commands
• Lists of paired devices and synced contact lists
• Driving statistics: mileage, engine performance modes, and other technical parameters

There are numerous precedents where this data has served as evidence and dismantled alibis. In one U.S. criminal case, a recorded voice command became a smoking gun, proving the suspect was behind the wheel of a stolen vehicle.

With the rise of connected cars equipped with their own SIM cards and direct links to the manufacturer, law enforcement no longer needs physical access to the vehicle. Key data, such as GPS location history, can be pulled directly from the manufacturer’s servers. Furthermore, a U.S. Senate investigation revealed that nine out of 14 surveyed automakers were providing this data without a warrant.

Major suppliers of car intelligence software, such as Ateros, Berla, TA9/Rayzone, and Toka, sell their solutions exclusively to government and law enforcement agencies, which is why they’ve remained largely out of the public eye.

Comprehensive surveillance

To track persons of interest, data pulled from the vehicle itself is cross-referenced with information from other sources. According to media leaks, flagship products in this category aggregate data from the car’s SIM card, Bluetooth communication trails, street-level CCTV footage, and commercially available information from data brokers. This hybrid dataset simplifies the comprehensive mapping of a target’s movements and contacts. Journalists have discovered that some companies even market the ability to activate a vehicle’s microphones and cameras remotely and covertly, enabling real-time eavesdropping on conversations. However, experts note that due to the diversity of technical implementations across different systems, hacking the car itself remains a difficult task with no sure way of succeeding. Often, it’s simpler to correlate other, more accessible datasets to achieve the same result.

Factory-installed spy tools

Features like covert activation of cameras, microphones, and other sensors may theoretically be part of a vehicle’s stock functionality rather than the result of a hack. While we haven’t found any public evidence of such cases, it’s well known that Chinese-made vehicles are coming under increased scrutiny in several countries. For instance, they’ve been banned from Israeli military sites — with the exception of a single Chery model, provided its multimedia system is removed. Similar bans exist in the UK and Poland; furthermore, UK Ministry of Defense employees are instructed not to connect their work phones to Chinese-made cars. In Germany, security analyses of Chinese vehicles were conducted by the specialized agencies BfV and ZITiS, but the findings remain classified.

Low-cost surveillance

Tracking a vehicle — or even thousands of them — doesn’t necessarily require hacking onboard systems or tapping into vast networks of license plate readers. A recent scientific study demonstrated that innocent tire pressure monitoring systems (TPMS) provide enough data for effective tracking. Data from these sensors is transmitted via radio without any encryption and includes a unique ID that makes identifying a specific car easy. This allows for more than just confirming the vehicle’s movement; it can even be used to estimate the driver’s weight or determine if they are traveling alone. While this might not sound as impressive as remotely accessing a car’s cameras, it requires very little financial investment and works even on relatively old vehicles without an internet connection.

What you can do about vehicle tracking

While tracking a person through their car is undoubtedly a privacy risk, striking a balance in mitigating this threat is difficult: many measures are complex, largely ineffective, and simultaneously reduce the utility, safety, and convenience of a modern vehicle. Consequently, any steps taken should be weighed against your personal risk profile.

To reduce the risk of data leaks, check the privacy settings in the manufacturer’s app, the car’s infotainment system, and your connected smartphone. A connected car can transmit data about its operation to the cloud: information about trips, location, driving style, vehicle condition, and the operation of its components. Some of this data is necessary for navigation, diagnostics, and service, but not all permissions are required — check your settings and disable the transmission of data not related to the functions you need.

Be careful with permissions for access to the microphone, camera, contacts, messages, and geolocation. Only connect your own devices to the car and don’t save other people’s phones or unfamiliar Bluetooth devices in the system. When syncing your smartphone, select only the features you need — such as calls, music, and navigation — rather than granting full access to all your phone’s data.

Do not use the services of technicians who offer to “unlock” your car, reflash electronic control units, or install unofficial software to expand features, increase power, or otherwise interfere with the car’s operation. Such software has not been tested by the manufacturer: it may behave unpredictably, collect and transmit your data to malicious actors, disable security features, or affect critical vehicle systems — including steering, braking, or engine operation.

And when choosing a new car, ask the dealer not only about the number of stars in NCAP safety tests, engine power, or fuel economy, but also about the cybersecurity technologies used in the vehicle. Solutions such as the Kaspersky Automotive Secure Gateway, based on KasperskyOS, will provide the necessary protection for new cars against cyberthreats.

What other threats do connected cars hide? Read more in our posts:

• Highway to… hacked: cyberthreats to connected cars
• Car hacking via Bluetooth
• Botnets on wheels: the mass hacking of dashcams
• How millions of Kia cars could be tracked
• I know how you drove last summer
• Spies on wheels: how carmakers collect and then resell information

The entry barriers for app development have plummeted in recent times — with nearly anyone now able to build a professional website, personal news bot, or dashboard simply by giving a chatbot or AI agent a few instructions in natural English. Unfortunately, a massive gap exists between a slick prototype and a reliable, production-ready, secure application. To avoid becoming the subject of another AI fail story, or losing money and sensitive data, follow these straightforward tips. These are intended specifically for non-technical creators and very small teams. Larger enterprises should follow more sophisticated recommendations.

The primary risks of AI-generated code

While vibe coding can deliver a seemingly functional app in just a few hours, it will likely contain dangerous flaws. AI models are trained on code samples from across the internet, which often include suboptimal tutorials, buggy snippets, and outright junk. Sometimes this code simply fails to run, but more often the situation is subtler and more hazardous: the app appears to work, yet under the hood, it might rely on a crude imitation of the required logic or contain critical vulnerabilities. According to a study by the Cloud Security Alliance AI Safety Initiative, the following facts should be considered when using AI for coding:

• At least 45% of AI-generated code contains dangerous vulnerabilities, such as failing to verify the user before granting access to sensitive data.
• A professional developer using AI can write code three to four times faster, but may introduce 10 times as many vulnerabilities.
• Twenty percent of AI-generated code attempts to use external libraries and modules that don’t actually exist.
• Even when an application handles confidential data — such as payments, private messages, or documents — AI-generated code sometimes skips credential verification entirely. This can leave the app’s data open for anyone on the internet to read.
• In other instances, the app might correctly prompt for a username and password but fail to enforce access controls, allowing any registered user to view everyone else’s data.
• Access keys (tokens) for databases and AI services may be embedded directly into the source code, easy to steal, and difficult to rotate after a data breach or cyberattack.
• Project code or critical build outputs are often deployed to servers without proper access restrictions, leaving both the application logic and sensitive access keys vulnerable to theft.
• AI may implement insecure database access patterns, which can allow attackers to bypass the application to steal data or execute arbitrary code on the database server.
• Apps that include API functionality often suffer from insecure API implementations, lacking both user permission checks and rate limiting.

Core principles of securing vibe code

Always verify. Treat AI-generated code as a rough draft. It should always be reviewed and rigorously tested. Ideally, professional developers should handle this; however, if none are available, the vibe-coder should at least test the application themselves, have friends or colleagues poke around the live app, and ask them to review key code snippets. It’s also possible to evaluate code integrity by submitting a separate prompt to the AI: “Review this code for secure development best practices and check for OWASP Top 10 vulnerabilities”.

Protect secrets. Never include passwords, API keys, or any other sensitive data in AI prompts. Instead, instruct the AI to write code that securely stores all secrets in environment variables (special hidden settings).

Prioritize efforts. The main risks emerge when an application is network-accessible to outsiders, processes valuable data, or runs on infrastructure that would be useful to attackers. The components of an app or system that meet these criteria are precisely what’s needed to be protected first. A static website composed of three HTML pages faces significantly lower risk than a loyalty program integrated into an online store.

Make security an explicit requirement. Even a simple, straightforward line in the prompt, like “Follow industry standards and security best practices when generating this code”, improves the output. Providing more specific requirements for critical code snippets makes the results even better.

Don’t trust default settings. Often, the danger in vibe coding lies in the configuration rather than the code itself. For example, an app processing sensitive company data might be deployed on a public vibe-coding platform (Lovable or the like), and remain accessible to the entire internet by default. Even if the code is flawless, making that information public is a critical security failure. Because of this, every component — from hosting and database settings to the deployment pipeline — must be manually reviewed and properly configured. If the purpose of a setting is unclear, consult a chatbot for the optimal values, specifying that its goal is to enhance security, and describing who the app is intended for.

Security is a continuous process. Securing the app should not be treated as a one-off task. Every time an application is updated, hosting providers are changed, or a project undergoes any other major shift, all steps in making it secure should be revisited, and the risks reassessed.

Tips for securing vibe code

It’s natural to want an app built from broad prompts like “Make me a beautiful, user-friendly, fast, reliable, and secure app for [use case].” However, for the results to actually be effective, each of those requirements needs to be fleshed out. Below, we’ve outlined recommendations for building standard components that will make vibe code more secure. It’s important to emphasize that “more secure” doesn’t mean “perfectly secure” — these approaches lower the risk, but that risk remains well above zero.

Demand security from the AI. When assigning a task to a neural network, be explicit: “write secure code, validate data, encrypt passwords”. Each type of task requires its own security prompt. For instance, don’t just ask to “build a login form”. Instead, ask for a “secure login form with credential validation, authentication and authorization (user permissions) controls, brute-force protection, password hashing according to modern standards, transmission strictly over HTTPS, and no hardcoded secrets”. It makes sense to use these secure requirement templates every time. It’s also helpful to keep a short cheat sheet of standard requirements for AI prompts: “validate all external data and user input before processing”, “no secrets in code”, “protect APIs from abuse”, “restrict user permissions”, and “secure default settings”.

Use off-the-shelf solutions. If an app needs a user management system, insist on using a popular, reputable library, such as NextAuth, Auth0, and so on, rather than inventing a new and vulnerable solution. This is the most common cause of data breaches. This applies to more than just login and registration; for other high-risk actions like file uploads and API call processing, it’s better to use established frameworks and libraries with built-in protections rather than building everything from scratch.

Don’t trust the AI blindly; verify open-source components. Neural networks often try to inject non-existent components and libraries into a project or suggest outdated versions. Always search for the suggested names online to ensure they are real, widely used, and secure — and make sure the latest versions are used.

Demand robust encryption. Explicitly state that modern industry standards must be used for both data transmission and storage: TLS 1.3 based on OpenSSL for network traffic; argon2 or bcrypt for hashing credentials; and so on.

Never trust user input. Always instruct the AI to include validation for any data entered by users, whether in forms or search bars. Use terms like “parameterization” and “sanitization” to emphasize that the app needs protection against malicious actors, not just users’ typos.

Set limits on user actions. Require the AI to implement rate limiting for login attempts or general requests. This will protect a project from automated attacks like DoS and brute-force password guessing.

Hide the system’s inner workings. If the site crashes, users should see a simple apology page rather than a detailed error report containing snippets of the code. That kind of information is a goldmine for hackers.

Remember that you’re a developer, and you need to protect development-related digital assets. All related accounts — such as access to GitHub, project hosting, and other resources — are prime targets for attackers. Be sure to enable two-factor authentication (2FA) on all work accounts.

Make backups. Regularly back up a project both locally and to the cloud to protect it against critical AI errors as well as cyberattacks. These backups should include both the application’s source code and its databases.

Set up a sandbox. Test new features and app versions in a secure environment using a clone of an active site or app and a copy of a database. Always run thorough tests before pushing an update live. This allows catching issues without putting users or their data at risk.

Update dependencies and scan them for vulnerabilities. A vibe-coded app will almost certainly rely on third-party libraries and components, known as dependencies. It’s wise to update these regularly by rebuilding an app with the latest versions, even if app’s code itself has not been changed. This process helps patch known security flaws in the used packages.

Check for secrets leaking into the repository. Use secrets scanners like TruffleHog to audit resulting code. Even with instructions, AI might slip up and include an API key or password in the source code. A scanner ensures that files containing keys and passwords don’t end up in Git or get published alongside the project.

Even if you keep your crypto assets in a cold wallet and use Apple devices — which enjoy a strong reputation for security — cybercriminals may still find a way to swipe your funds. These bad actors are combining well-known tricks into new attack chains — including baiting victims right inside the App Store.

Crypto-wallet clones

This past March, we discovered phishing apps at the top of the Chinese App Store charts with icons and names mimicking popular crypto-wallet management tools. Because regional restrictions block several official wallet apps from the Chinese App Store, attackers have stepped in to fill the void. They created fake apps using icons similar to the originals and names with intentional typos — likely to bypass App Store moderation and deceive users.

Beyond these, we found a number of apps with names and icons that had nothing to do with cryptocurrency. However, their promotional banners claimed they could be used to download and install official wallet apps that are otherwise unavailable in the regional App Store.

In total, we identified 26 phishing apps mimicking the following popular wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

A few other very similar apps didn’t contain phishing functionality yet, but all signs point to them being linked to the same attackers. It’s likely they plan to add malicious features in future updates.

To get these apps cleared for the App Store, the developers added basic functionality, such as a game, a calculator, or a task planner.

Installing any of these clones is the first step toward losing your crypto assets. While the apps themselves don’t steal cryptocurrency, seed phrases, or passwords, they serve as bait that builds user trust by virtue of being listed on the official App Store. Once installed and launched, however, the app opens a phishing site in the victim’s browser, designed to look like the App Store, which then prompts the user to install a compromised version of the relevant crypto wallet. The attackers have created multiple versions of these malicious modules, each tailored to a specific wallet. You can find a detailed technical breakdown of this attack in our Securelist post.

A victim who falls for the ruse is first prompted to install a provisioning profile, which allows apps to be sideloaded onto an iPhone outside the App Store. The profile is then used to install the malicious app itself.

In the example above, the malware is built on the original Ledger app with integrated Trojan functionality. The app looks identical to the original, but when connected to a hardware wallet, it displays a window requiring a seed phrase, supposedly to restore access. This is not standard procedure: typically, you only need to enter a PIN — never a recovery phrase. If a victim is deceived by the app’s apparent legitimacy and enters their seed phrase, it’s immediately sent to the attackers’ server — granting them full access to the victim’s crypto assets.

Sideloading outside the App Store

A critical component of this scheme involves installing malware on the victim’s iPhone by bypassing the App Store and its verification process. This is executed much like the SparkKitty iOS infostealer we discovered previously. The attackers managed to gain access to the Apple Developer Enterprise Program. For just US$299 a year — and following an interview and corporate verification — this program allows entities to issue their own configuration profiles and apps for direct download to user devices without ever publishing them in the App Store.

 

In general, enterprise profiles are designed to allow organizations to deploy internal apps to employees’ devices. These apps don’t require App Store publication and can be installed on an unlimited number of devices. Unfortunately, this feature is often abused. These profiles are frequently used for software that fails to meet Apple’s policies, such as online casinos, pirated mods, and, of course, malware.

This is precisely why the fake site mimicking the Apple Store prompts the user to install a configuration profile before delivering the app signed by that profile.

Stealing cryptocurrency via macOS apps and extensions

Many crypto owners prefer managing their wallets on a computer rather than a smartphone — often choosing Macs for the task. It’s no surprise, then, that most popular macOS infostealers target crypto-wallet data in one way or another. Recently, however, a new malicious tactic has been gaining traction: in addition to stealing saved data, attackers are embedding phishing dialogs directly into legitimate wallet applications already installed on users’ computers. Earlier this year, the MacSync infostealer adopted this functionality. It infiltrates systems via ClickFix attacks: users searching for software are lured to fake sites with fraudulent instructions to install the app by running commands in Terminal. This executes the infostealer, which scrapes passwords and cookies saved in Chrome, chats from popular messengers, and data from browser-based crypto-wallet extensions.

But the most interesting part is what happens next. If the victim already has a legitimate Trezor or Ledger app installed, the infostealer downloads additional modules and… swaps out fragments of the app with its own trojanized code. The malware then re-signs the modified file so that after these “fixes” are made, Gatekeeper (a built-in protection mechanism in macOS) allows the application to run without an additional permission request from the user. While this trick doesn’t always work, it’s effective for simpler apps built on the popular Electron framework.

When the trojanized app is opened, it fakes an error and initiates a “recovery process”, prompting the user for their wallet seed phrase.

Besides MacSync, the developers behind other popular macOS infostealers have adopted this same trojanization approach. We previously detailed a similar mechanism used to compromise Exodus and Bitcoin-Qt wallets.

How to keep your crypto assets safe

Time and again, attackers have proved that no gadget is truly invincible. With so many developers and cryptocurrency users preferring macOS and iOS, threat actors have designed and deployed industrial-scale attacks for both platforms. Staying safe requires in-depth defense backed by skepticism and vigilance.

• Download apps only from trusted sources: either the developer’s official website or their App Store page. Since malware can slip even into official stores, always verify the app’s publisher.
• Check the app’s rating, publication date, and download counter.
• Read the reviews — especially the negative ones. Sort reviews by date to evaluate the latest version. Attackers often start with a perfectly innocent app that earns high ratings before introducing malicious functionality in a later update.
• Never copy and paste commands into your Terminal unless you’re 100% certain what they do. These attacks have become very popular lately, often disguised as installation steps for AI apps like Claude Code or OpenClaw.
• Use a comprehensive security system on all your computers and smartphones. We recommend Kaspersky Premium. This goes a long way to mitigate the risk of visiting phishing sites or installing malicious apps.
• Never enter your seed phrase into a hardware wallet app, on a website, or in a chat. In every scenario, whether migrating to a new wallet, reinstalling apps, or recovering a wallet, the seed phrase should be entered exclusively on the hardware device itself — never in a mobile or desktop app.
• Always verify the recipient’s address on the hardware wallet’s screen to prevent attacks involving address swapping.
• Store your seed phrases in the most secure way possible, such as on a metal plate or in a sealed envelope in a safe deposit box. It’s best not to store them on a computer at all, but if that’s your only option, use a secure, encrypted vault like Kaspersky Password Manager.

Still believe that Apple devices are bulletproof? Think again as you read the following:

• The iPhone — invincible no more: a look at DarkSword and Coruna
• Predator vs. iPhone: the art of invisible surveillance
• Are your Bluetooth headphones spying on you?
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Banshee: A stealer targeting macOS users

Researchers from three universities in Hong Kong have published a paper demonstrating a method of eavesdropping through fiber-optic cables. Fiber optics have long been the gold standard for data transmission due to their ability to transfer information at high speeds over long distances. Fiber-optic cabling utilizes ultra-thin glass threads for transmission, and is widely used not only for backbone data lines but also for connecting individual premises. And as it turns out, these very glass threads are sensitive enough to vibrations that they subtly alter the parameters of the optical signal.

Potentially, this allows a fiber-optic cable to be turned into a microphone and intercept room conversations while being kilometers away from the sound source. In other words, this exploits so-called side channels — non-obvious characteristics of everyday home or office appliances that enable information leaks. Of course, this work is largely theoretical, much like other similar studies we’ve covered previously — eavesdropping through mouse sensors, using RAM modules as radio transmitters, exfiltrating data from CCTV sensors, or screen snooping through HDMI cables. However, several news outlets have reported on the Hong Kong researchers’ study as if it were a turnkey method, so let’s try to determine just how dangerous it really is in practice.

Hurdles of optical eavesdropping

The unique characteristics of fiber-optic cables were first considered back in 2012 by Russian researchers, who conceded the theoretical possibility of such an attack. The goal of the Hong Kong researchers was to demonstrate at least some level of practical implementation for eavesdropping.

The diagram above illustrates a typical FTTH (fiber-to-the-home) network architecture, where end users or organizations connect directly to a fiber-optic cable. The ISP manages the so-called Optical Distribution Network (ODN), to which end-users are connected. The device on the user’s end is called an Optical Networking Unit (ONU).

An attack leveraging this equipment is quite difficult to execute. To eavesdrop on a specific ONU endpoint, a potential adversary would need access to the provider’s infrastructure and control over the ODN equipment. What exactly is this device? It’s a network router or an optical-to-Ethernet converter — a small box usually tucked away in an office utility closet. Inside the premises, connectivity is provided either by Wi-Fi or a local network using Ethernet cabling. Crucially, the fiber-optic cable is unlikely to run directly into a sensitive area like a CEO’s office — the very place where eavesdropping would be most relevant.

And here’s a rough idea of what the attacker’s equipment would look like. Using special tech, they send optical pulses down the fiber-optic cable and measure the parameters of their transmission. Minor vibrations from footsteps in a room near the cable and nearby conversations trigger an effect known as Rayleigh scattering. This effect, in turn, causes minute deviations in the reflected signal’s parameters, which are then captured on the attacker’s end using a photosensor.

Before moving on to voice recording, the researchers decided to test a simpler scenario. To streamline the task, they ran the fiber-optic cable around the perimeter of the room and recorded footsteps — which generate significant vibration — rather than quiet conversation. This experiment was quite successful — the footsteps were audible. However, human speech proved to be far more challenging to capture. It turned out that even in laboratory conditions, intercepting a conversation between two people was impossible. To make further stages of the attack possible, the researchers assumed the presence of a bug at the fiber’s entry point into the room. This module is essentially a microphone that converts audio signals into vibrations on the optical cable. This amplifies the signal, making it possible to intercept on the attacker’s side.

Not-so-obvious advantages

But wait — if we’re talking about planting a bug in a room, why go through all the trouble with fiber optics? Why not just have the bug transmit the conversation on its own through cellular data or the building’s landline — especially since it’s already sitting right on top of it? Because there’s a distinct advantage to the researchers’ proposed attack scenario.

A regular bug transmitting audio over a cellular network or through the internet is fairly easy to detect, whereas a transmitter relaying data via fiber-optic cable vibrations can operate much more stealthily. Such a tap would be relatively easy to implant during the installation of network equipment, and harder to detect using traditional bug-sweeping tools.

Another major benefit of this hypothetical attack is that the eavesdropping can take place kilometers away from the target room — the attacker wouldn’t have to put themselves at extra risk by being near the target. Theoretically, one could also imagine a scenario where a separate fiber-optic cable is run into a room solely for surveillance purposes without raising much suspicion from those being surveilled.

Practical takeaways

If we frame the question as, “Can attackers remotely eavesdrop on any room that has fiber-optic cabling?” the answer is no; it’s still impossible. However, this work by the Hong Kong researchers, which highlights quirks of a common data transmission medium, demonstrates a technically feasible — albeit unlikely and quite expensive to execute — scenario for a targeted attack.

In many countries, spring is the traditional time for filing income tax returns. These documents are a goldmine for bad actors because they contain a wealth of personal data, such as employment history, income, assets, bank account details — the list goes on. It’s no surprise that scammers ramp up their efforts around this time; the internet is currently crawling with fake websites designed to look exactly like government resources and tax authorities.

With deadlines looming and numbers to crunch, the rush to get everything done in good time can cause people to let their guard down. In the shuffle, it’s easy to miss the signs that the site where you’re detailing your finances has zero connection to the revenue service, or that the file you just downloaded, supposedly from a tax inspector, is actually malware.

In this post, we break down how these fraudulent tax agency sites operate across different countries and what you should absolutely avoid doing to keep your money and sensitive information safe.

Taxpayer phishing

This season, attackers have been spoofing tax authority websites across numerous countries, including the official government portals of Germany, France, Austria, Switzerland, Brazil, Chile, and Colombia. On these fraudulent sites, scammers harvest credentials for legitimate services, and steal personal data before offering to process a tax deduction — provided the victim enters their credit card details. In some cases, they even charge a fee for this fraudulent service.

Sometimes, the tactic involves accusations issued on behalf of government bodies. In the image below, for example, a “head of tax audit” in Paris informs the victim that they provided incomplete income information. To avoid penalties, the user is told to download a document and make corrections immediately. However, the PDF file hides something much worse: malware.

In Colombia, a fake National Directorate of Taxes and Customs site similarly prompts users to download documents that must be “unlocked with a security key”. In reality, this is simply a password-protected, malicious ZIP archive.

Beyond phishing sites mimicking legitimate resources, our experts have discovered fraudulent websites promising paid services for filling out and auditing tax documents — and stealing high-value data, such as taxpayer identification numbers (TINs), instead.

Tax-free crypto earnings

Cryptocurrency holders have emerged as a specific target for attackers. Fake German tax authorities are demanding that wallet owners “verify their digital asset holdings”, citing EU regulations for tax calculation purposes. And of course, there’s a “silver lining”: it turns out crypto earnings are supposedly tax-exempt! However, to claim this generous benefit, users must go through a “verification” procedure. The site even promises to encrypt data using a “2048-bit SSL protocol”.

To complete the “verification” process, users are prompted to enter their seed phrase — the unique sequence of words tied to a crypto wallet that grants full recovery access. This request is paired with a threat: refusing to provide the data will lead to serious legal consequences, such as fines up to one million euros or criminal prosecution.

Attackers pulled a similar stunt on French users as well. They created a non-existent “Crypto Tax Compliance Portal”, which mimics the design of the French Ministry of Economy and Finance website. The phishing site aggressively demands that French residents submit a “digital asset declaration”.

After the user enters their personal information, the scammers prompt them to either manually enter their seed phrase, or “link” their crypto wallet to the portal. If they go through with this, their MetaMask, Binance, Coinbase, Trust Wallet, or WalletConnect wallets will be drained.

Can AI help with your tax returns?

When you have AI at your fingertips that can instantly generate text and fill out spreadsheets, there’s a serious temptation to delegate everything to it. Unfortunately, this can lead to serious consequences. First, all popular chatbots process your data on their servers, which puts your sensitive information at risk of a leak. Second, they sometimes make incredibly foolish mistakes, and that can lead to actual trouble with the taxman.

Before you tell a chatbot or an AI agent how much money you made last year — complete with detailed personal and banking info — remember how frequently leaks occur within AI-powered services and consider the risks. Don’t discuss your income with AI, don’t give it personal details like your name or address, and under no circumstances should you upload photos or numbers of vital documents such as passports, insurance info, or social security numbers. Files containing confidential information should be kept in encrypted containers, such as Kaspersky Password Manager.

If you’re still determined to use AI tools, run them locally. This can be done for free even on a standard laptop, and we’ve previously covered how to set up local language models using DeepSeek as an example. However, the quality of the output from these models is often subpar. It’s quite possible that double-checking every digit in an AI-generated response will take more time than just filling out the paperwork manually. Remember, you’re the one accountable to the tax office for any errors — not the AI.

Finally, watch out for phishing AI models that offer “assistance” with tax filing. Kaspersky experts have discovered websites where users are prompted to upload tax invoices, supposedly for the automated generation of returns and deduction claims. Instead, attackers collect this personal data to resell on the dark web, or to use in future phishing attacks, blackmail, and extortion schemes.

Remember that all legitimate AI services explicitly warn users not to share confidential data, and tax documents certainly fall into this category. Any AI tools promising to help you handle your tax paperwork are quite simply a scam.

How to protect yourself and your data

• File your taxes yourself. The risk of running into scammers is extremely high. Even if a consulting firm is legitimate, you’re inevitably handing over a complete dossier on yourself: passport details, employment and income info, your address, and more. Remember that even the most honest services aren’t immune to hacks and data breaches.
• Watch out for fake websites. Use a reliable security solution that prevents you from visiting phishing sites and blocks malicious file downloads.
• Keep all important documents encrypted. Storing photos, notes, or files on your desktop, or starred messages in a messaging app isn’t a secure way to handle sensitive data. A secure vault like Kaspersky Password Manager can store more than just passwords and credit card info; it can also safeguard documents and even photos.
• Don’t trust AI. Even the most advanced chatbots are prone to errors and hallucinations, and in theory, developers can read any conversation you have with their AI. If you absolutely must use AI, install and run a local version on your own computer.
• Stick to official channels only. The “chief tax inspector” of your country or city is definitely not going to message you: high-ranking officials have more important things to do. Only contact tax authorities through official channels, and carefully verify the sender of any emails you receive. Most often, even a slight deviation in the name or address is a telltale sign of a phishing campaign.

Further reading on phishing and data security:

• Phishing and spam: the wildest campaigns of 2025
• How phishers and scammers use AI
• What happens to data stolen using phishing?
• How to disappear from the internet
• Why data brokers build dossiers on you, and how to stop them doing so

Lately, hackers have been turning up the heat on software developers. On the surface, this might seem like a puzzling move — why go after someone who’s literally paid to understand tech when there are plenty of less-savvy targets in the office? As it turns out, compromising a developer’s machine offers a much bigger payoff for an attacker.

Why developers are such high-value targets

For starters, compromising a coder’s workstation can give attackers a direct line to source code, credentials, authentication tokens, or even the entire development infrastructure. If the company builds software for others, a hijacked dev environment allows attackers to launch a massive supply chain attack, using the company’s products to infect its customer base. If the developer works on internal services, their machine becomes a perfect beachhead for lateral movement, allowing hackers to spread deeper into the corporate network.

Even when attackers are purely chasing cryptocurrency (and let’s face it, tech pros are much more likely to hold crypto than the average person), the malware used in these hits doesn’t just swap out wallet addresses; it vacuums up every scrap of valuable data it can find — especially those login credentials and session tokens. Even if the original attackers don’t care about corporate access, they can easily flip those credentials to initial access brokers or more specialized threat actors on the dark web.

Why developers are sitting ducks

In practice, developers aren’t nearly as good at understanding cyberthreats and spotting social engineering as they think they are. This misconception is a big reason why they often fall prey to cybercriminals. Professional expertise can often create a false sense of digital invincibility. This often leads technical professionals to cut corners on security protocols, bypass restrictions set by the security team, or even disable security software on their corporate machines when it gets in the way of their workflow. That mindset, combined with a job that requires them to constantly download and run third-party code, makes them sitting ducks for cyberattackers.

Attack vectors targeting developers

Once an attacker sets their sights on a software engineer, their go-to move is usually finding a way to slip malicious code onto the machine. But that’s just the tip of the iceberg — hackers are also masters at rebranding classic, battle-tested tactics.

Compromising open-source packages

One of the most common ways to hit a developer is by poisoning open-source software. We’ve seen a flood of these attacks over the past year. A prime example hit in March 2026, when attackers managed to inject malicious code into LiteLLM, a popular Python library hosted in the PyPI repository. Because this library acts as a versatile gateway for connecting various AI agents, it’s baked into a massive number of projects. These trojanized versions of LiteLLM delivered scripts designed to hunt for credentials across the victim’s system. Once stolen, that data serves as a skeleton key for attackers to infiltrate any company that was unlucky enough to download the infected packages.

Malware hidden in technical assignments

Every so often, attackers post enticing job openings for developers, complete with take-home test assignments that are laced with malicious code. For instance, in late February 2026, malicious actors pushed out web application projects built on Next.js via several malicious repositories, framing them as coding tests. Once a developer cloned the repo and fired up the project locally, a script would trigger automatically to download and install a backdoor. The attackers gained full remote access to the developer’s machine.

Fake development tools

Recently, our experts described an attack where hackers used paid search-engine ads to push malware disguised as popular AI tools. One of the primary baits was Claude Code, an AI coding assistant. This campaign specifically targeted developers looking for a way to use AI-assistants under the radar, without getting the green light from their company’s infosec team. The ads directed users to a malicious site that perfectly mimicked the official Claude Code documentation. It even included “installation instructions”, which prompted the user to copy and run a command. In reality, running that command installed an infostealer that harvested credentials and shuttled them off to a remote server.

Social engineering tactics

That said, attackers often stick to the basics when trying to plant malware. A recent investigation into a compromised npm package — Axios — revealed that hackers had gained access to a maintainer’s system using a shockingly simple “outdated software” ruse. The attackers reached out to the Axios repository maintainer while posing as the founder of a well-known company. After some back-and-forth, they invited him to a video interview. When the developer tried to join the meeting on what looked like Microsoft Teams, he hit a fake notification claiming his software was out of date and needed an immediate update. That “update” was actually a Remote Access Trojan, giving the attackers access to his machine.

Niche spam

Sometimes, even a blast of fake notifications does the trick, especially when it’s tailored to the audience. For example, just recently, attackers were caught posting fake alerts in the Discussions tabs of various GitHub projects, claiming there was a critical vulnerability in Visual Studio Code that required an immediate update. Because developers subscribed to those discussions received these alerts directly via email, the notifications looked like legitimate security warnings. Of course, the link in the message didn’t lead to an official patch; it pointed to a “fixed” version of VS Code that was actually laced with malware.

How to safeguard an organization

To minimize the risk of a breach, companies should lean into the following best practices:

• Make security a native part of your workflow. Use specialized solutions to vet your images, packages, dependencies, and components.
• Use threat intelligence feeds specifically focused on open-source components to check the packages used in software development.
• Make sure security awareness training covers everyone — including developers. Leverage specialized solutions like Kaspersky Automated Security Awareness Platform.
• Make sure developers are aware of the latest attack patterns — you can keep them in the loop by following the Development tag right here on this

DarkSword and Coruna are two new tools for invisible attacks on iOS devices. These attacks require no user interaction and are already being actively used by bad actors in the wild. Before these threats emerged, most iPhone users didn’t have to lose sleep over their data security. Protection was really only a major concern for a narrow group — politicians, activists, diplomats, high-level business execs, and others who handle extremely sensitive data — who might be targeted by foreign intelligence agencies. We’ve covered sophisticated spyware used against such a group before — noting how hard to come by those tools were.

However, DarkSword and Coruna — discovered by researchers earlier this year — are total game-changers. This malware is being used for mass infections of everyday users. In this post, we dive into why this shift happened, why these tools are so dangerous, and how you can stay protected.

What we know about DarkSword, and how it can target your iPhone

In mid-March 2026, three separate research teams coordinated the release of their findings on a new spyware strain called DarkSword. This tool is capable of silently hacking devices running iOS 18 without the user ever knowing something is wrong.

First, we should clear up some confusion: iOS 18 isn’t as vintage as it might sound. Even though the latest version is iOS 26, Apple recently overhauled its versioning system, which threw everyone for a loop. They decided to jump ahead eight versions — from 18 straight to 26 — so the OS number matches the current year. Despite the jump, Apple estimates that about a quarter of all active devices still run iOS 18 or older.

With that cleared up, let’s get back to DarkSword. Research shows that this malware infects victims when they visit perfectly legitimate websites that have been injected with malicious code. The spyware installs itself without any user interaction at all: you just have to land on a compromised page. This is what’s known as a zero-click infection technique. Researchers report that several thousand devices have already been hit this way.

To compromise a device, DarkSword uses a six-vulnerability exploit chain to escape the sandbox, escalate privileges, and execute code. Once it’s in, the malware harvests data from the infected device, including:

• Passwords
• Photos
• Chats and data from iMessage, WhatsApp, and Telegram
• Browser history
• Information from Apple’s Calendar, Notes, and Health apps

On top of all that, DarkSword lets attackers scoop up crypto-wallet data, making it essentially dual-purpose malware that functions as both a spy tool and a way to drain your crypto.

The only bit of good news is that the spyware doesn’t survive a reboot. DarkSword is fileless malware, meaning it lives in the device’s RAM, and never actually embeds itself into the file system.

Coruna: how older iOS versions are being targeted

Just two weeks before the DarkSword findings went public, researchers flagged another iOS threat dubbed Coruna. This malware is capable of compromising devices running older software — specifically iOS 13 through 17.2.1. Coruna uses the exact same playbook as DarkSword: victims visit a legitimate site injected with malicious code which then drops the malware onto the device. The whole process is completely invisible and requires zero user interaction.

A deep dive into Coruna’s code revealed it exploits a total of 23 different iOS vulnerabilities, several of which are tucked away in Apple’s WebKit. It’s worth reminding that, generally speaking (outside the EU), all iOS browsers are required to use the WebKit engine. This means these vulnerabilities don’t just affect Safari users — they’re a threat to anyone using a third-party browser on their iPhone as well.

The latest version of Coruna, much like DarkSword, includes modifications designed to drain crypto wallets. It also harvests photos and, in certain instances, email data. From what we can tell, stealing cryptocurrency seems to be the primary motive behind Coruna’s widespread deployment.

Who created Coruna and DarkSword — and how did they end up in the wild?

Code analysis of both tools suggests that Coruna and DarkSword were likely built by different developers. However, in both cases, we’re looking at software originally created by state-affiliated companies, possibly from the U.S. The high quality of the code points to this; these aren’t just Frankenstein kits cobbled together from random parts, but uniformly engineered exploits. Somewhere along the line, these tools leaked into the hands of cybercrime gangs.

Experts at Kaspersky’s GReAT analyzed all of Coruna’s components and confirmed that this exploit kit is actually an updated version of the framework used in Operation Triangulation. That earlier attack targeted Kaspersky employees, a story we covered in detail on this blog.

One theory suggests an employee at the company that developed Coruna sold it to hackers. Since then, the malware has been used to drain crypto wallets belonging to users in China; experts estimate that at least 42 000 devices were infected there alone.

As for DarkSword, cybercriminals have already used it to compromise users in Saudi Arabia, Turkey, and Malaysia. The problem is exacerbated by the fact that the attackers who first deployed DarkSword left the full source code on infected websites, meaning it could easily be picked up by other criminal groups.

The code also includes detailed comments in English explaining exactly what each component does, which supports the theory of its Western origins. These step-by-step instructions make it easy for other hackers to adapt the tool for their own purposes.

How to protect yourself from Coruna and DarkSword

Serious malware that allows for the mass infection of iPhones while requiring zero interaction from the user has now landed in the hands of an essentially unlimited pool of cybercriminals. To pick up Coruna or DarkSword, you simply have to visit the wrong site at the wrong time. So this is one of those cases where every user needs to take iOS security seriously — not just those in high-risk groups.

The best thing you can do to protect yourself from Coruna and DarkSword is to update your devices to the latest version of iOS or iPadOS 26, as soon as you can. If you can’t update to the newest software — for instance, if your device is older and doesn’t support iOS 26 — you should still install the latest version available to you. Specifically, look for versions 15.8.7, 16.7.15, or 18.7.7. In a rare move, Apple patched a wide range of older operating systems.

To protect your Apple devices from similar malware that will likely pop up in the future, we recommend the following:

• Install updates promptly on all your Apple devices. The company regularly releases OS versions that patch known vulnerabilities — don’t skip them.
• Enable Background Security Improvements. This feature allows your device to receive critical security fixes separately from full iOS updates, reducing the window for hackers to exploit vulnerabilities. To enable it, go to Settings → Privacy & Security → Background Security Improvements and turn on the Automatically Install
• Consider using Lockdown Mode. This is a heightened security setting that limits some device features but simultaneously blocks or significantly complicates attacks. To enable this, go to Settings → Privacy & Security → Lockdown Mode → Turn On Lockdown Mode.
• Reboot your device once a day (or more). This stops fileless malware in its tracks, since these threats aren’t embedded in the system and disappear after a restart.
• Use encrypted storage for sensitive data. Keep things like crypto wallet keys, photos of IDs, and confidential info in a secure vault. Kaspersky Password Manager is a great fit for this; it manages your passwords, two-factor authentication tokens, and passkeys across all your devices while also keeping your notes, photos, and docs synced and encrypted.

The idea that Apple devices are bulletproof is a myth. They’re vulnerable to zero-click attacks, Trojans, and ClickFix infection techniques — and we’ve even seen malicious apps slip into the App Store more than once. Read more here:

• Predator vs. iPhone: the art of invisible surveillance
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Are your Bluetooth headphones spying on you?
• SparkCat trojan stealer infiltrates App Store and Google Play, steals data from photos
• Banshee: A stealer targeting macOS users

In 2023, Tim Utzig, a blind student from Baltimore, lost a thousand dollars to a laptop scam on X. Tim had been a long-time follower of a well-known sports journalist. When that journalist’s account started posting about a “charity sale” of brand-new MacBook Pros, Tim jumped at the chance to get a deal on a laptop he needed for his studies. After a few quick messages, he sent over the money.

Unfortunately, the journalist’s account had been hacked, and Tim’s cash went straight to scammers. The red flags were strictly visual: the page had been flagged as “temporarily restricted”, and both the bio and the Following list had changed. However, Tim’s screen reader — the software that converts on-screen text and graphics into speech — didn’t announce any of those warnings.

Screen readers allow blind users to navigate the digital world like everyone else. However, this community remains uniquely vulnerable. Even for sighted users, spotting a fake website is a challenge; for someone with a visual impairment, it’s an even steeper uphill battle.

Beyond screen readers, there are specialized mobile apps and services designed to assist the blind and low-vision community, with Be My Eyes being one of the most popular. The app connects users with sighted volunteers via a live video call to tackle everyday tasks — like setting an oven dial or locating an object on a desk. Be My Eyes also features integrated AI that can scan and narrate text or identify objects in the user’s environment.

But can these tools go beyond daily chores? Can they actually flag a phishing attempt or catch the hidden fine print when someone is opening a bank account?

Today we explore the specific online hurdles visually impaired users face, when it makes sense to lean on human or virtual assistants, and how to stay secure when using these types of services.

Common cyberthreats facing the blind and low-vision community

To start, let’s clarify the difference between these two groups. Low-vision users still rely on their remaining sight, even though their visual function is significantly reduced. To navigate digital interfaces, they often use screen magnifiers, extra-large fonts, and high-contrast settings. For them, phishing sites and emails are particularly dangerous. It’s easy to miss intentional typos — known as typosquatting — in a domain name or email address, such as the recent example of rnicrosoft{.}com.

Blind users navigate primarily by sound, using screen readers and specific touch gestures. Interestingly, though, unlike those with low vision, blind users are more likely to spot a phishing site using a screen reader: as the software reads the URL aloud, the user will hear that something is off. However, if a service — whether legitimate or malicious — isn’t fully compatible with screen readers, the risk of falling victim to a scam increases. This is exactly what happened to Tim Utzig.

It’s important to remember that screen magnifiers and readers are basic accessibility tools. They’re designed to enlarge or narrate an interface — not act as a security suite. They can’t warn the user of a threat on their own. That’s where more advanced software — tools that can analyze images and files, flag suspicious language, and describe the broader context of what’s happening on-screen — comes into play.

When to lean on an assistant

Be My Eyes is a major player in the accessibility space, boasting around 900 000 users and over nine million volunteers. Available on Windows, Android, and iOS, it bridges the gap by connecting blind and low-vision users with sighted volunteers via video calls for help with everyday tasks. For example, if someone wants to run a Synthetics cycle on their washing machine but can’t find the right button, they can hop into the app. It connects them with the first available volunteer speaking their language, who then uses the smartphone’s camera to guide them. The service is currently available in 32 languages.

In 2023, the app expanded its capabilities with the release of Be My AI — a virtual assistant powered by OpenAI’s GPT-4. Users take a photo, and the AI analyzes the image to provide a detailed text description, which it also reads aloud. Users can even open a chat window to ask follow-up questions. This got us thinking: could this AI actually spot a phishing site?

As an experiment, we uploaded a screenshot of a fake social media sign-in page to Be My Eyes. On a phone, you can do this by selecting a photo in your gallery or files, hitting Share, and choosing Describe with Be My Eyes. In Windows, you can upload a screenshot directly.

At first, the AI gave us a detailed description of the page. We then followed up in the chat: “Can I trust this page?” The AI flagged the domain name error immediately, advised us to close the fake login page, and suggested typing the official URL directly into the browser, or to use the official Facebook app.

We saw the same positive results when testing a phishing email. In fact, the AI flagged the scam during its initial description of the message. It wrapped up with a warning: “This looks like a suspicious email. It’s best not to open any attachments or click any links. Instead, navigate to the official website or app manually, or call the number listed on their official site”.

Beyond just spotting cyberthreats, Be My AI is a solid sidekick for navigating online stores, banking apps, and digital services. For instance, the AI can help you to:

• Read descriptions, names, and prices when a store’s website or app doesn’t support screen readers or large fonts
• Scan those tricky terms and conditions — often buried in tiny text or otherwise inaccessible to a screen reader — when you’re signing up for a subscription or opening a bank account
• Pull key info directly from product cards or instruction manuals

The risks of relying on Be My AI

The most common hiccup with AI is hallucinations, where the language model distorts text, skips crucial details, or invents words out of thin air. When it comes to cyberthreats, an AI’s misplaced confidence in a malicious site or email can be dangerous. Furthermore, AI isn’t immune to prompt injection attacks, which scammers use to trick AI agents beyond just Be My AI.

Even though the AI passed our test, you shouldn’t rely on it unquestioningly. There’s no guarantee it’ll get it right every time. This is a vital point for the blind and low-vision community, as a neural network can often feel like the only eyes available.

At the end of every response, Be My AI suggests checking in with a volunteer if you’re still unsure. However, when you’re trying to spot a fake webpage, we advise against this. You have no way of knowing how tech-savvy or trustworthy a random volunteer might be. Besides, you risk accidentally exposing sensitive data like your email address or password. Before connecting with a stranger, make sure they won’t see anything confidential on your screen. Better yet, use the app’s dedicated feature to create a private group of family, friends, or trusted contacts. This ensures your video call goes to people you actually know, rather than a random volunteer.

To stay safe, we recommend installing a trusted security tool on all your devices. These programs are designed to block phishing attempts and prevent you from landing on malicious sites. Another practical recommendation for visually impaired users is to use a password manager. These apps will only auto-fill credentials on the legitimate, saved website; they won’t be fooled by a clever domain spoof.

How Be My AI handles and stores your data

According to the Be My Eyes privacy policy, video calls with volunteers may be recorded and stored to provide the service, ensure safety, enforce the terms of service, and improve the products. When you use Be My AI, your images and text prompts are sent to OpenAI to generate a response. This data is processed on servers located in the U.S., and OpenAI uses it only to fulfill your specific request. The policy explicitly states that user images and queries aren’t used to train AI models.

Photos and videos are encrypted both in transit and at rest, and the company takes steps to strip away sensitive information. It’s worth noting that video call recordings can be retained indefinitely unless you request their deletion — in which case they’re typically wiped within 30 days. Data from Be My AI interactions is stored for up to 30 days unless you delete it manually within the app. If you decide to close your account, your personal data may be held for up to 90 days. At any time, you can opt out of data sharing, or request the deletion of your existing data by contacting the Be My Eyes support team.

How to use Be My Eyes safely

Despite Be My Eyes’ claims regarding privacy, you should still follow a few ground rules when using the service:

• Use Be My AI for a first-pass on suspicious emails or pages, but don’t treat it as the only source of truth. Specialized security software is better at identifying and neutralizing threats.
• If a site, email, or message feels off, don’t touch any links or attachments. Instead, manually type the official website address into your browser, or open the official app to verify the info.
• Remember: a volunteer sees exactly what your camera sees. Make sure it isn’t capturing things it shouldn’t, like a safe code or an open passport. Avoid sharing your name, showing your face, or revealing too much of your surroundings. Be extra careful about reflections that might show you or your personal details. Only show what is absolutely necessary for the task at hand.
• Stick to your inner circle. Create a group in the app and add your friends and family. This ensures your video calls go to people you know — not a random volunteer.
• Don’t use Be My AI to read documents that contain confidential info. Remember, your images and text prompts are sent to OpenAI for processing and generating a response.
• Remember to delete chats you no longer need. Otherwise, they’ll hang around for 30 days.
• If you need to read something personal or confidential, consider apps with real-time reading features like Envision, Seeing AI, or Lookout. These apps process data locally on your device rather than sending it to the cloud.

It’s one of those coincidences: independent university research teams stumble onto something new and prep their papers for publication — only to realize they’ve solved the exact same puzzle using slightly different methods. That’s exactly what happened with GDDRHammer and GeForge. These two studies describe Rowhammer-style attacks that are so similar the researchers decided to publish them as a joint effort. Then, while we were putting this post together, a third study surfaced — GPUBreach — detailing yet another comparable attack. So today we’re looking at all three.

All three theoretical attacks target graphics accelerators, though this term is not entirely accurate anymore since these devices are so good at parallel processing, they’ve moved far beyond just rendering frames in a game and are now the backbone of AI systems. It’s this industrial use case that is most at risk. Picture a cloud provider renting out GPU resources to all comers. These new attacks demonstrate how, in theory, a single malicious customer could go beyond seizing control of an accelerator to compromise the entire server, access sensitive data, and potentially hack the provider’s entire infrastructure. Let’s break down why this kind of attack is even possible.

Rowhammer in a nutshell

We covered Rowhammer in-depth in previous posts, but here’s the quick version. The original attack was first proposed back in 2014, and it exploits the actual physical properties of RAM chips. Individual memory cells are simple components arranged in tight rows. In theory, reading or writing to one cell shouldn’t affect its neighbors. However, because these chips are packed so densely — with millions or even billions of cells per chip — writing to one spot can sometimes modify the cells next to it.

The 2014 study showed that this isn’t just a recipe for random data corruption; it can be weaponized. By repeatedly accessing (or “hammering”, hence the name) a specific area of memory, an attacker can intentionally flip bits in adjacent cells. If an attacker manages to flip the right bits, he can bypass critical security measures to snag sensitive data or run unauthorized code with full privileges.

Since that first discovery, we’ve seen a constant arms race between new Rowhammer defenses and clever ways to bypass them. We’ve also seen the attack evolve to target newer standards like DDR4 and DDR5. That’s a key takeaway here: for every new type of memory that hits the market, researchers essentially have to reinvent the attack from scratch.

Attacking GDDR6 video memory

The first Rowhammer attack on GPUs was presented back in 2025, but the results were relatively modest. At the time, researchers were able to force bit-flips in GDDR6 memory cells, and show how that data corruption could degrade the performance of an AI system.

These latest papers, however, warn of much more damaging attacks on video memory. Using slightly different techniques, GDDRHammer and GeForge manipulate the page tables — basically the master structures that track where data lives in the GPU’s memory. This enables an attacker to read or write to any part of the video memory, and even reach into the main system RAM managed by the CPU. Modifications to page tables are possible because the researchers have found a way to hammer memory cells much more efficiently. They pulled this off despite the hardware using Target Row Refresh, a core defense designed specifically to stop Rowhammer. TRR detects repeated access to specific cells, and forces a data refresh in the neighboring rows to hamper the attack. However, the researchers discovered a specific pattern of access that can bypass TRR.

How realistic are these GPU attacks?

As is usually the case with this type of research, pulling off these attacks in the real world comes with a lot of contingencies. First off, different GPUs behave differently. For instance, the GeForge attack was significantly more effective on the consumer-grade GeForce RTX 3060. On the industrial-strength Nvidia RTX A6000, the attack’s efficiency dropped by more than five times — even though both cards use the exact same GDDR6 memory standard. Going back to our hypothetical scenario of a malicious cloud customer: for an attack to work, they’d first need to identify exactly which accelerator they’ve been assigned, then profile their exploit specifically for that hardware. In short, this would have to be an incredibly sophisticated and expensive targeted attack.

It’s also worth noting that GDDR6 isn’t the latest and greatest anymore. Consumer devices are moving to GDDR7, while professional-grade hardware often uses high-speed HBM memory. These systems come with ECC (Error Correction Code), a built-in mechanism that checks data integrity. ECC can actually be enabled on cards like the Nvidia A6000; while it might take a small bite out of performance, it effectively makes both of these attacks impossible.

Another tool available to owners of AI-focused servers is enabling the IOMMU (input–output memory management unit) — a system that isolates the GPU’s memory from the CPU’s memory. This will prevent an attack from escalating from the graphics accelerator to the main processor and compromising the entire server. This is where the third study, GPUBreach, comes into play. Its main differentiator from GDDRHammer and GeForge is that it can actually bypass even IOMMU protection! It pulls this off by exploiting some fairly traditional bugs found in NVIDIA drivers.

So, despite the existing hurdles, these three studies prove that Rowhammer attacks remain a potent threat. This is especially true in our current AI boom, which relies on massive, expensive, and potentially vulnerable infrastructure packed with dozens or even hundreds of thousands of computing devices. The Rowhammer timeline goes to show that technical barriers almost never hold for long. In standard RAM, researchers have managed to bypass not only basic fixes like Target Row Refresh, but also more advanced — and theoretically bulletproof — solutions like ECC memory. While the extreme complexity of these exploits means they’ll likely never become a mass-market threat, for anyone running expensive computing systems, they’re definitely a risk factor that can’t be ignored.

The smart-home craze has connected everything — from your lightbulbs to your tea kettle — to the internet, and the adult industry isn’t sitting this one out: manufacturers are releasing more smart models than ever. While syncing a sex toy to your smartphone unlocks some cool extra features, it also opens the door to potential security and privacy headaches. The good news? You can significantly lower most of these risks just by tweaking your settings and adjusting your usage habits.

How sex-toy apps actually work

To be clear upfront, while researchers have successfully hijacked sex toys in controlled experiments, the odds of a hacker remotely taking over your vibrator in the real world are pretty slim. In this post, we focus on the more realistic risks: your privacy and the safety of your data.

Most modern adult toys link up with the manufacturer’s app. These apps offer a range of usage options: you can control the device yourself, or hand over the remote to a partner — anywhere in the world via the internet.

Beyond just basic controls, many of these apps have social features: private messaging, group chats, calls, and even video sessions. In fact, you don’t even need a physical device to use some of them; you just create an account. Because of this, some of these services have essentially evolved into niche dating platforms.

The toy and your phone talk to each other via Bluetooth — with minimal risks. To handle social features or remote control, the app connects to a cloud server. This creates a constant stream of data moving back and forth: everything from commands to private messages.

Here’s the catch: even if you only use the app to control your toy locally via Bluetooth, you still get connected to that cloud server. That means you’re inheriting all the security and privacy risks.

The main risks of using sex-toy apps

Sex-toy apps are typically free. In practice, this means the primary way these services make money is by collecting data — which is often excessive. It’s not hard to find buyers of this information; it could be ad services, data brokers, or other companies interested in building detailed user profiles.

Developers of intimate apps suffer from frequent data breaches, and in this sense they’re no different from many other online services that spring a leak regularly. However, unlike a breach at an online pet food store, a data leak from a sex toy app can have much more serious consequences for the user. For sex industry workers, such as those who use webcams, these data breaches pose a direct threat to their physical safety.

Vulnerabilities within the service’s infrastructure warrant special attention. These types of bugs can be exploited by hackers to gain unauthorized access to other people’s accounts.

The inclusion of broad social features essentially turns sex-toy apps into just another messaging platform. However, while we usually know if mainstream messengers use end-to-end encryption, or what vulnerabilities they face, every sex-toy app has to be evaluated individually.

Without end-to-end encryption, user chats may be accessible on the server side. This means that if the service is compromised, the contents of those messages could end up in the hands of hackers. Furthermore, the sex toy manufacturer itself, or its individual employees, could have access to your chats.

Finally, the user’s account and everything in it can be hijacked by bad actors if it isn’t protected by a strong password and, ideally, two-factor authentication.

How to lower the risks when using sex-toy apps

Now that we’ve covered the threats, let’s talk about how to defend yourself. The most obvious choice is to skip installing the app altogether. Thankfully, most sex toys still come with physical buttons — unlike, say, smart mattresses, which often require an app just to function. For those who want the extra features, here are some practical tips for setting up and using these services.

Create an account with a dedicated email address

Set up a separate email address just for registering your account in the intimate app. This should be a “clean” email with no links to any other online services you use. Naturally, the username for this email account shouldn’t include your real name or any other easily identifiable info.

Using an anonymous email protects your reputation if the app suffers a data breach. The risk of this happening is far from theoretical. For instance, back in 2015, a hacking group named The Impact Team leaked the user database of Ashley Madison, a dating site for people seeking extramarital affairs.

To create an anonymous email, pick a service that doesn’t require a phone number at all, or lets you skip that step. Besides your real name, we also recommend leaving out your birth date, your usual social media handles, and any other details that could lead back to you.

Don’t sign up via Google, Apple, social media, or your phone number

The reasoning here is basically the same as the previous point. However, it’s worth highlighting that signing up through Google, Apple, social media, or your phone number is actually just about the worst way to go.

Using Google or social media accounts gives the app permission to, among other things, access certain data from those profiles. In the context of intimate apps, this is especially risky because it creates a direct link between highly sensitive data and your real-world identity.

Keep your real info out of your profile

Once you’re in the app, don’t use any information that could be traced back to you. Come up with an anonymous handle (if you’re feeling uninspired, use a random nickname generator), pick a fake birthday, and choose a random location.

Using fictional info means you don’t have to sweat being outed if the service ever leaks your data. You’re also protecting yourself from stalking, blackmail, and other threats that come with someone being able to pin your real identity to your account.

Hide your face and distinguishing marks when sharing private media

As we’ve mentioned throughout this post, these apps often include social features used for swapping intimate photos and videos. Even if you trust the person you’re chatting with, those files can be saved, forwarded, or used without your consent. When combined with other account info, they can make it easy to figure out who you are.

We recommend never sending intimate media that shows your face or anything else that identifies you — think recognizable home decor, personal items, documents, unique clothing, tattoos, or jewelry.

Set a strong password and enable two-factor authentication, if available

If a hacker breaks into your sex toy account, they’re getting access to your most private data. Because of that, your account needs a rock-solid password. Just to be clear, here’s what we mean by a strong password:

• It’s at least 16 characters long.
• It uses a mix of uppercase and lowercase letters, numbers, and special characters (like $ or @).
• It’s not a real word or a well-known phrase.
• It’s unique and not reused for any of your other accounts.
• It doesn’t include personal info that’s easy for an outsider to find.

We also recommend turning on two-factor authentication (2FA) if the service offers it. Your best bet is to use 2FA one-time codes from an authenticator app, as it’s the most secure and completely anonymous option. You can dive deeper into creating and storing secure passwords, as well as different 2FA methods, in our dedicated blogposts.

Grant only the necessary app permissions

Every mobile app asks for permission to access certain features of your phone like Bluetooth, location, your camera, or your storage. Every extra “yes” you give expands the amount of data the app can scoop up.

We suggest being extra cautious about what you let these services see, especially when it comes to sex-toy apps. By tightening these permissions, you cut down on the amount of info that can be collected or shared without your say-so.

Take a second to think about the absolute bare minimum you’re willing to allow a sex-toy app to access. For example, there’s usually no reason for it to track your location or access your camera and mic. If you do want to upload photos, it’s better to grant access only to specific files rather than giving the app the keys to your entire photo library.

Stop apps from tracking your activity

In your iOS settings, you can block apps from collecting data about what you do and linking it to a single advertising ID. This practice, known as tracking, allows companies to stitch together data from different apps, websites, and services to build a comprehensive profile of you for targeted ads or behavioral analysis.

We strongly recommend disabling tracking for all sex-toy apps so that sensitive details about your private life don’t end up as part of your advertising profile.

Unfortunately, Android doesn’t have an exact equivalent for this setting. To minimize data collection on those devices, you’ll need to turn off ad personalization, and manually delete or reset your advertising ID every now and then. You can find more tips on dodging ad tracking in our dedicated guide.

Keep your apps and operating system up to date

Updates aren’t just about shiny new features; they also fix security bugs. Outdated versions of apps and operating systems often have vulnerabilities that hackers are just waiting to exploit.

Staying on top of your updates helps close these gaps, and lowers the risk of data breaches or unauthorized access. To make sure you don’t miss any critical fixes, it’s best to turn on automatic updates whenever possible.

Security is in your hands

Smart sex-toys and their companion apps naturally handle sensitive data, which means they require extra care when it comes to setup and daily use. That said, you can eliminate — or at least significantly reduce — most risks by following basic security rules. Essentially, it comes down to sharing as little personal info as possible with the app and, of course, using a rock-solid password.

Want more tips on keeping your intimate life private in the digital age? Check out these posts:

• Watching porn safely: a guide for grown-ups
• How to watch porn safely and discreetly
• Fifty shades of sextortion
• AI and the new reality of sextortion
• Google forcing Android System SafetyCore on users to scan for nudes

At the NDSS Symposium 2026 in San Diego in February, a group of respected researchers presented a study unveiling the AirSnitch attack, which bypasses the Wi-Fi client isolation feature — also commonly known as guest network or device isolation. This attack allows connecting to a single wireless network via an access point, and then gaining access to other connected devices, including those using entirely different service set identifiers (SSIDs) on that same hardware. Targeted devices could easily be running on wireless subnets protected by WPA2 or WPA3 protocols. The attack doesn’t actually break encryption; instead, it exploits the way access points handle group keys and packet routing.

In practical terms, this means that a guest network provides very little in the way of real security. If your guest and employee networks are running on the same physical device, AirSnitch allows a connected attacker to inject malicious traffic into neighboring SSIDs. In some cases, they can even pull off a full-blown man-in-the-middle (MitM) attack.

Wi-Fi security and the role of isolation

Wi-Fi security is constantly evolving; every time a practical attack is made against the latest generation of protection, the industry shifts toward more complex algorithms and procedures. This cycle started with the FMS attacks used to crack WEP encryption keys, and continues to this day: recent examples include the KRACK attacks on WPA2, and the FragAttacks, which impacted every security protocol version from WEP all the way through WPA3.

Attacking modern Wi-Fi networks effectively (and quietly) is no small feat. Most professionals agree that using WPA2/WPA3 with complex keys and separating networks based on their purpose is usually enough for protection. However, only specialists really know that client isolation was never actually standardized within the IEEE 802.11 protocols. Different manufacturers implement isolation in completely different ways — using Layer 2 or Layer 3 of network architecture; in other words, handling it at either the router or the Wi-Fi controller level — meaning the behavior of isolated subnets varies wildly depending on your specific access point or router model.

While marketing claims that client isolation is perfect for keeping restaurant or hotel guests from attacking one another — or ensuring corporate visitors can’t access anything but the internet — in reality, isolation often relies on people not trying to hack it. This is exactly what the AirSnitch research highlights.

Types of AirSnitch attacks

The name AirSnitch doesn’t just refer to a single vulnerability, but a whole family of architectural flaws found in Wi-Fi access points. It’s also the name of an open-source tool used to test routers for these specific weaknesses. However, security professionals need to keep in mind that there’s only a very thin line between testing and attacking.

The model for all these attacks is the same: a malicious client is connected to an access point (AP) where isolation is active. Other users — the targets — are connected to the same SSID or even different SSIDs on that same AP. This is a very realistic scenario; for example, a guest network might be open and unencrypted, or an attacker could simply get the guest Wi-Fi password by posing as a legitimate visitor.

For certain AirSnitch attacks, the attacker needs to know the victim’s MAC or IP address beforehand.  Ultimately, how effective each attack is depends on the specific hardware manufacturer (more on that below).

GTK attack

After the WPA2/WPA3 handshake, the access point and the clients agree on a Group Transient Key (GTK) to handle broadcast traffic. In this scenario, the attacker wraps packets destined for a specific victim inside a broadcast traffic envelope. They then send these directly to the victim while spoofing the access point’s MAC address. This attack only allows for traffic injection, meaning the attacker won’t receive a response. However, even that is enough to deliver malicious ICMPv6 routing advertisements, or DNS and ARP messages to the client — effectively bypassing isolation. This is the most universal version of the attack working on any WPA2/WPA3 network that uses a shared GTK. That said, some enterprise-grade access points support GTK randomization for each individual client, which renders this specific method ineffective.

Broadcast packet redirection

This version of the attack doesn’t even require the attacker to authenticate at the access point first. The attacker sends packets to the AP with a broadcast destination address (FF:FF:FF:FF:FF:FF) and the ToDS flag set to 1.  As a result, many access points treat this packet as legitimate broadcast traffic; they encrypt it using the GTK, and blast it out to every client on the subnet, including the victim. Just like in the previous method, traffic specifically meant for a single victim can be pre-packaged inside.

Router redirection

This attack exploits an architectural gap between Layer 2 and Layer 3 security found in some manufacturers’ hardware. The attacker sends a packet to the access point, setting the victim’s IP address as the destination at the network layer (L3).  However, at the wireless layer (L2), the destination is set to the access point’s own MAC address, so the isolation filter doesn’t trip. The routing subsystem (L3) then dutifully routes the packet back out to the victim, bypassing the L2 isolation entirely. Like the previous methods, this is another transmit-only attack where the attacker can’t see the reply.

Port stealing to intercept packets

The attacker connects to the network using a spoofed version of the victim’s MAC address, and floods the network with ARP responses claiming, “this MAC address is on my port and SSID”.  The target network’s router updates its MAC tables, and starts sending the victim’s traffic to this new port instead. Consequently, traffic intended for the victim ends up with the attacker — even if the victim is connected to a completely different SSID.

In a scenario where the attacker connects via an open, unencrypted network, this means traffic meant for a client on a WPA2/WPA3-secured network is actually broadcast over the open air, where not only the attacker but anyone nearby can sniff it.

Port stealing to send packets

In this version, the attacker connects directly to the victim’s Wi-Fi adapter, and bombards it with ARP requests spoofing the access point’s MAC address. As a result, the victim’s computer starts sending its outgoing traffic to the attacker instead of the network. By running both stealing attacks simultaneously, an attacker can, in several scenarios, execute a full MitM attack.

Practical consequences of AirSnitch attacks

By combining several of the techniques described above, a hacker can pull off some pretty serious moves:

• Complete bidirectional traffic interception for a MitM attack. This means they can snatch and modify data moving between the victim and the access point without the victim ever knowing.
• Hopping between SSIDs. An attacker sitting on a guest network can reach hosts on a locked-down corporate network if both are running off the same physical access point.
• Attacks on RADIUS. Since many companies use RADIUS authentication for their corporate Wi-Fi, an attacker can spoof the access point’s MAC address to intercept initial RADIUS authentication packets. From there, they can brute-force the shared secret. Once they have that, they can spin up a rogue RADIUS server and access point to hijack data from any device that connects to it.
• Exposing unencrypted data from “secure” subnets: Traffic that’s supposed to be sent to a client under the protection of WPA2/WPA3 can be retransmitted onto an open guest network, where it’s essentially broadcast for anyone to hear.

To pull off these attacks effectively, a hacker needs a device capable of simultaneous data transmission and reception with both the victim’s adapter and the access point. In a real-world scenario, this usually means a laptop with two Wi-Fi adapters running specifically configured Linux drivers. It’s worth noting that the attack isn’t exactly silent: it requires a flood of ARP packets, it can cause brief Wi-Fi glitches when it starts, and network speeds might tank to around 10Mbps. Despite these red flags, it’s still very much a practical threat in many environments.

Vulnerable devices

As part of the study, several enterprise and home access points and routers were put to the test. The list included products from Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM, and ASUS, as well as routers running popular community firmware like DD-WRT and OpenWrt. Every single device tested was vulnerable to at least some of the attacks described here. Even more concerning, the D-Link DIR-3040 and LANCOM LX-6500 were susceptible to every single variation of AirSnitch.

Interestingly, some routers were equipped with protective mechanisms that blocked the attacks, even though the underlying architectural flaws were still present. For example, the Tenda RX2 Pro automatically disconnects any client whose MAC address appears on two BSSIDs simultaneously, which effectively shuts down port stealing.

The researchers emphasize that any network administrator or IT security team serious about defense should test their own specific configurations. That’s the only way to pinpoint exactly which threats are relevant to your organization’s setup.

How to protect your corporate network from AirSnitch

The threat is most immediate for organizations running guest and corporate Wi-Fi networks on the same access points without additional VLAN segmentation. There are also significant risks for companies using RADIUS with outdated settings or weak shared secrets for wireless authentication.

The bottom line is that we need to stop viewing client isolation on an access point as a real security measure, and start seeing it as just a convenience feature. Real security needs to be handled differently:

• Segment the network using VLANs. Each SSID should have its own VLAN, with strict 802.1Q packet tagging maintained all the way from the access point to the firewall or router.
• Implement stricter packet inspection at the routing level — depending on the hardware capabilities. Features like Dynamic ARP Inspection, DHCP snooping, and limiting the number of MAC addresses per port help defend against IP/MAC spoofing.
• Enable individual GTK keys for each client, if your equipment supports it.
• Use more resilient RADIUS and 802.1X settings, including modern cipher suites and robust shared secrets.
• Log and analyze EAP/RADIUS authentication anomalies in your SIEM. This helps track many attack attempts beyond just AirSnitch. Other red flag events to watch for include the same MAC address appearing on different SSIDs, spikes in ARP requests, or clients rapidly jumping between BSSIDs or VLANs.
• Apply security at higher levels of the network topology. Many of these attacks lose their punch if the organization has universally implemented TLS and HSTS for all business application traffic, requires an active VPN for all Wi-Fi connections, or has fully embraced a Zero Trust architecture.

BTS, a global K-pop phenomenon, has recently made a comeback from an almost four-year hiatus: the members of the group were completing mandatory military service in South Korea. For this reason it comes as no surprise that cybercriminals have taken advantage of the band’s highly anticipated world-tour — ARIRANG — to launch a campaign of fake websites targeting fans eager to buy tickets.

We’ve identified at least 10 fraudulent domains that mimic the official pre‑sale pages for the band’s concerts in Argentina, Brazil, Chile, Colombia, France, Mexico, Peru, Portugal, and Spain — all created in early April. We explain how the scammers operate, and how to avoid buying fake tickets.

How the fake ticket scam works

Due to the high demand for the world-tour tickets, some of the event organizers prepared additional measures to ensure there are no ticket scalpers. In Brazil, the ticketing services adopted a “pre‑booking” format: the user first makes an online reservation, and then pays in person at the box office. Although in essence a good idea, the change has caused confusion among fans and created an opportunity for criminals to commit fraud.

Scammers create pages that are nearly identical to the official ones, replicating the layout, design, and the entire purchasing journey. For ordinary users, the experience seems completely legitimate. The links to these websites are circulating on social media — mainly on Instagram.

In Brazil, victims are prompted to make payments via PIX — an instant payment system operated by the Central Bank of Brazil. In some cases, the sites even simulate a card‑payment option, but claim high demand or system errors to pressure users into choosing PIX. PIX payments are then directed to money mule accounts — making it difficult to recover the funds.

The scam is a perfect example of how social engineering works. It exploits a massive and highly engaged fanbase — leading many users to act impulsively. The fake “errors” that the website displays during payment create a sense of urgency and cause panic — the scammers are well aware of how quickly BTS tickets sell out. In addition, doubts about the new purchasing system established by the event organizers help criminals make fake websites even more convincing.

How to protect yourself from ticket scams

If you really want to get tickets to your favorite group’s concert but not fall victim to the scammers, it’s important to keep these basic cybersecurity rules in mind:

• Access only official ticketing services, which you can find on the official page dedicated to BTS’s tour. Type the website address directly into your browser, and avoid links received via messages, social media, or email.
• Check the domain carefully. Slight changes in the address often indicate fraud. This includes additional dashes, unusual territorial domains, and hardly-noticeable changes like replacing a lowercase “l” (L) with an uppercase “I” (i).
• Check the website for Privacy Policy and Terms of Use pages. If they’re missing, you’re definitely visiting a fake website. But remember: their presence doesn’t guarantee that the site is legitimate. With modern AI, generating such pages takes only a few seconds.
• Carefully check the sales format for each country. In Brazil, payment should only be made in person, so any request for online payment during the pre‑sale is a strong indication of a scam. Other countries and event organizers may offer online payments.
• If you’ve been scammed, immediately contact your bank. If you provided bank card information to the criminals, you should reissue your card to prevent further unauthorized payments.
• Enable banking alerts. Real-time notifications allow you to quickly identify suspicious transactions.
• Use cybersecurity protection that detects and automatically blocks fraudulent websites. Kaspersky Premium, our robust cybersecurity solution, also shuts down phishing attempts, protects your personal data, and helps safeguard your identity.
• Beware of “free” or “discounted” tickets. Ultimately, there’s never such a thing as a free lunch — especially when it comes to world‑famous music groups.

More on scams:

• Phishing and spam: the wildest campaigns of 2025
• How phishers and scammers use AI
• The scam on your doorstep
• 8 more tips for spotting online scammers
• 5 online scam red flags

Companies work systematically to reduce their attack surface. They segment networks, manage vulnerabilities, roll out EDR/XDR, and try to automate their response efforts. As paradoxical as it may seem, they often overlook one massive piece of the puzzle: the security of the very tools managing that entire defense system.

This can occur due to a mental blind spot. It’s easy to assume that, because an organization installed all security solutions needed, it’s safe. In reality, any added software (even security tools) actually expands attack surface. This means those tools need protection, too — starting with hardening them through the right settings.

Why a breached security console is a nightmare scenario

Security tools are only as strong as the system running them. If an attacker manages to break into an organization’s infrastructure and seize control of the security management console, they basically have full rein there. It’s the ultimate skeleton key — giving them direct access to centralized policy management, endpoint monitoring, API integrations, and everything in between.

In this scenario, the attacker doesn’t need to waste time finding clever ways to bypass defenses — all they need do is modify the configuration. With console access, a hacker can skip the hard parts of a breach:

• They don’t have to scout the network; the console gives them a bird’s-eye view of the entire infrastructure and security architecture instantly.
• No need to hide their malicious activity — they can simply tweak security policies, kill specific tools, or silence some alerts.
• Instead of inventing ways to spread the payload to endpoints discreetly, they can leverage the console’s built-in tools for mass software and update installation.

This is exactly why control layer compromise is so dangerous. A proactive cybersecurity mindset isn’t about how many tools are implemented; it’s about how resilient corporate security architecture actually is. If the control layer is the weak link, no amount of hi-tech software can mitigate that risk.

How to protect the security console

On paper, most security management systems already have all the mechanisms needed to beef up protection. The problem? These hardening measures — even basic stuff like two-factor authentication — are often available but not mandatory. Security recommendations get published, but they don’t always get implemented in a consistent manner. Sometimes, they’re just flat-out ignored. Even worse, critical security settings that are turned on by default can often be disabled with a single click —propagating that change to every user instantly. And let’s be honest: people often disable these features in the name of convenience.

In the real world, this means that corporate security ends up relying on an admin’s personal discipline. But discipline can’t serve as an architectural defense mechanism.

The modern approach to protecting the control layer is shifting toward a secure-by-default model. In this setup, critical protections are baked into the base configuration, and the ability to turn them off globally is restricted. Essentially, security stops being an optional feature.

It’s all about removing the guesswork from the security of defensive tools, and shrinking the attack surface at the management level.

How we implement this approach in Kaspersky Security Center Linux

Our products are consistently moving toward a model where critical security mechanisms are part of the base architecture rather than an optional feature. We recently released a new version (16.1) of Kaspersky Security Center Linux, where this architectural shift is built into its core principles — primarily by tightening console access control. Now, two-factor authentication is enabled by default, and the ability to disable it globally has been removed. Before upgrading, administrators must ensure 2FA is enabled for all users, including those working through the Web Console or using OpenAPI automation.

This establishes fundamental protection for privileged access at the console level. It reduces the risk of compromised administrative accounts, protects automation channels, lowers the likelihood of API abuse, and eliminates the vulnerabilities that come from making security optional. In this way, the potential attack surface is reduced specifically at the management control layer.

However, as mentioned before, the problem with most consoles and management systems isn’t a lack of security features, but a lack of systematic control over how they’re used. For example, we often see administrators with excessive privileges or insecure administration server connection settings. We’ve already provided a hardening guide for Kaspersky Security Center that covers these issues in detail, but unfortunately not everyone takes the time to read through deep technical manuals.

That’s why, to make sure no one misses the key points, we’ve put together a structured checklist for hardening Kaspersky Security Center Linux, ver. 16.1. This checklist:

• Allows to verify that authentication and access privileges are configured correctly
• Helps identify roles and users with excessive privileges
• Provides guidance on restricting network access to the console
• Emphasizes the protection of APIs
• Strengthens encryption requirements
• Ensures that auditing and logging are set up properly
• Reduces the risk of configuration gaps

Essentially, this is a tool for a systematic audit of the control layer. It ensures the console doesn’t become an entry point or a tool for attackers to move laterally through infrastructure. The fewer critical settings are left at the user’s discretion — the lower the risk of error or compromise.

Enhanced authentication and structured hardening of the administration console aren’t just minor tweaks; they represent a more thorough approach to security management. We plan to continue developing this protection layer — reducing the attack surface not just at the endpoint level, but within the management system itself. You can learn more about Kaspersky Security Center on the console page, and the hardening checklist is available on our technical support site.

April 7 marks World Health Day. The theme for 2026 is “Together for health. Stand with science” — a call to join forces in the fight for evidence-based medicine and scientific progress. Many people view telehealth as one of the crowning achievements of this progress: you can basically get a doctor’s consultation in five minutes without ever leaving your couch. But there’s a catch…

Medical data sells on the black or gray markets for dozens of times more than credit card info or social media logins. Unlike a credit card, which you can just block and replace, you can’t exactly reset your medical history. Your name, birthday, address, phone number, insurance ID, diagnoses, test results, prescriptions, and treatment plans stay relevant for years. This is a goldmine for everything from targeted marketing to blackmail, fraud, or identity theft.

And with the rise of AI, the internet is now flooded with fake websites that claim to offer medical services but are actually designed to strip-mine confidential info from unsuspecting victims. Today, we’re diving into which medical details are at risk, why hackers want them, and how you can stop them in their tracks.

More valuable than credit cards

Scammers monetize stolen medical data both in bulk and through individual sales. Their first move is usually to extort a ransom from the companies they’ve successfully hacked. (In fact, back in 2024, 91% of malware-related healthcare data leaks in the U.S. were the result of ransomware attacks.) But later, the leaked data is then used for pinpointed, personal attacks. It allows hackers to build a medical profile of a victim — what meds they buy, how often, and what they take long-term — to then sell that info to big pharma or marketers, or to use it for targeted phishing scams like pitching a fake innovative treatment. They can even blackmail a patient over a sensitive diagnosis or use the info to fraudulently score prescriptions for controlled substances. On top of that, insurance companies are also hungry for this kind of data. They analyze these details to hike up insurance premiums for patients or, in some cases, refuse to provide coverage altogether. In short, there are plenty of ways they can use it against you.

How bad is it really?

The biggest medical data breach in history went down in February 2024, when the BlackCat hacking group broke into the systems of Change Healthcare. This is a division of UnitedHealth Group, which processes around 15 billion insurance transactions a year and acts as the financial middleman between patients, healthcare providers, and insurance companies.

For nine days, the attackers roamed freely through Change Healthcare’s internal systems, siphoning off six terabytes of confidential data before finally launching their ransomware. UnitedHealth was forced to completely yank Change Healthcare datacenters offline to stop the encryptor from spreading, and they ended up paying a 22-million-dollar ransom to the extortionists. The attack effectively paralyzed the U.S. healthcare system. The number of victims was revised three times: first 100 million, then 190 million, and the final tally hit a staggering 192.7 million people, with total damages estimated at 2.9 billion dollars. And the reason (on the Change Healthcare’s side) for this massive incident — which we broke down in detail in a separate post — was simply… a lack of two-factor authentication on a remote desktop access portal.

Before that, the mental health telehealth startup Cerebral embedded third-party tracking tools directly into its website and apps. As a result, the data of 3.2 million patients — including names, medical and prescription histories, and insurance info — leaked out to LinkedIn, Snapchat, and TikTok. The U.S. Federal Trade Commission slapped the company with a 7.1-million-dollar fine, and issued an unprecedented ban on using medical data for advertising purposes. By the way, that same startup also made the headlines for sending its clients promotional postcards without envelopes, displaying patient names and phrasing that made it easy for anyone to figure out their diagnosis.

Why telehealth is so vulnerable

Let’s take a look at the main weak spots in telehealth services.

• Ad trackers in medical apps. Trackers from Facebook, TikTok, Snapchat, and other tech giants are often baked right into telehealth platforms, leaking patient data to advertisers without users ever knowing.
• Unsecured communication channels. Sometimes doctors chat with patients through regular messaging apps instead of certified medical platforms. It’s convenient, sure, but it’s illegal for the clinic and totally unsafe for the patient.
• Platform vulnerabilities. Telemedicine platforms are prone to classic web attacks, such as SQL injections that let hackers dump entire patient databases, session hijacking, and data interception when connection encryption is weak or nonexistent.
• Poor staff training. Our research showed that 30% of doctors have dealt with compromised patient data specifically during telehealth sessions, and 42% of medical staff don’t actually understand how their patients’ data is being protected.
• Outdated medical devices. Many wearable medical gadgets (like heart monitors or blood pressure cuffs) use an old data transfer protocol called MQTT. It’s full of holes that could potentially allow hackers to steal sensitive info or even mess with how the device functions.

Spam and phishing in telehealth

Hackers aren’t the only ones interested in the medical field — spammers and scammers are all over it, too. They pitch “medical services” with deals that look way too good to be true, send out emails about supposed changes to your health insurance, or talk up “ancient Himalayan healing traditions”. Of course, all the links they send lead to suspicious websites offering dubious goods or services.

Should you land on such a phishing site, scammers will try to squeeze every bit of private info they can out of you: photos of your ID, insurance policy, prescriptions, and sometimes even… photos of body parts that supposedly need medical attention. From there, this data can be dumped and sold on the dark web — or used for blackmail, extortion, and follow-up phishing attacks. To learn more about how the underground data assembly line works, check out our post, What happens to data stolen using phishing?

As a rule of thumb, fake clinic sites usually skip the privacy policy section, and bombard you with “today only” deals that seem too good to be true. That said, with the help of AI, creating a professional-looking site that’s indistinguishable from the real thing is now a total breeze: you don’t even need design skills or fluency in the victim’s language. That’s exactly why we recommend using our comprehensive security suite — it’s designed to sniff out spam, scams and phishing, and warn you about fake websites before you land on them.

Safety tips for telehealth patients

• Set up a dedicated email address for medical services. If this address leaks because a clinic gets hacked, it makes it much harder for scammers to track the rest of your digital life.
• Avoid using Google, Apple, or social media sign-in for telehealth sites. Keeping things separate makes it way tougher to link your medical data to your personal accounts.
• Double-check which platform is being used for your consultation. If the clinic suggests a call or chat through a standard messaging app, that’s a red flag. A secure, encrypted patient portal provided by the clinic is significantly safer.
• Never send medical documents via chat apps or social media. Always upload lab results, scans, and records through the clinic’s official patient portal.
• Use a unique, complex password for every account. Your government portal, clinic login, and doctor-booking app should each have a separate password. Kaspersky Password Manager can generate and store all of them for you; it also regularly scans leak databases, and alerts you if any of your accounts are compromised.
• Turn on two-factor authentication. Do this first of all for government services and medical organizations. We recommend using an authenticator app rather than SMS codes: it’s more secure and totally anonymous. Kaspersky Password Manager can help you out here, too.
• Share only what’s necessary. Don’t feel obligated to fill out every optional field in medical apps or on websites. The less data a service stores, the less there is to leak.
• Be careful about sharing health info on social media or in chat apps. Scammers love to exploit people when they’re vulnerable. For instance, in 2024, hackers gained the trust of the XZ Utils developer who had publicly posted about burnout and depression. They convinced him to hand over control of his tool, which they then loaded with malicious code. Since XZ Utils is used in tons of Linux systems and affects OpenSSH (a protocol for remote server connections), the attack could have wrecked a huge chunk of the internet if it hadn’t been caught in time.
• Don’t install telehealth apps from unknown developers. Check the reviews and take a minute to skim the privacy policy — even major platforms might be sharing your data with third parties.
• Keep an eye on your medical records. Strange prescriptions, doctor visits you never made, or meds you’ve never heard of can all be signs that your account has been compromised.
• Configure and regularly update your health gadgets. Fitness trackers, blood pressure monitors, smart scales, and activity trackers all send data to the web. Improper settings or unpatched vulnerabilities are an open door for data breaches.

What else you need to know about protecting your health online:

• Brain drain: vulnerabilities in mental health apps
• Why data brokers build dossiers on you, and how to stop them doing so
• How chatting with a bot can lead to tragedy
• Privacy in reproductive health apps
• Five problems of telehealth