Tenga confirmed reports published by several outlets that the company notified customers of a data breach.

The Japanese manufacturer of adult products appears to have fallen victim to a phishing attack targeting one of its employees. Tenga reportedly wrote in the data breach notification:

“An unauthorized party gained access to the professional email account of one of our employees.”

This unauthorized access exposed the contents of said account’s inbox, potentially including customer names, email addresses, past correspondence, order details, and customer service inquiries.

In its official statement, Tenga said a “limited segment” of US customers who interacted with the company were impacted by the incident. Regarding the scope of the stolen data, it stated:

“The information involved was limited to customer email addresses and related correspondence history. No sensitive personal data, such as Social Security numbers, billing/credit card information, or TENGA/iroha Store passwords were jeopardized in this incident.”

From the wording of Tenga’s online statement, it seems the compromised account was used to send spam emails that included an attachment.

“Attachment Safety: We want to state clearly that there is no risk to your device or data if the suspicious attachment was not opened. The risk was limited to the potential execution of the attachment within the specific ‘spam’ window (February 12, 2026, between 12am and 1am PT).”

We reached out to Tenga about this “suspicious attachment” but have not heard back at the time of writing. We’ll keep you posted.

Tenga proactively contacted potentially affected customers. It advises them to change passwords and remain vigilant about any unusual activity. We would add that affected customers should be on the lookout for sextortion-themed phishing attempts.

What to do if your data was in a breach

If you think you have been affected by a data breach, here are steps you can take to protect yourself:

• Check the company’s advice. Every breach is different, so check with the company to find out what’s happened and follow any specific advice it offers.
• Change your password. You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
• Enable two-factor authentication (2FA). If you can, use a FIDO2-compliant hardware key, laptop, or phone as your second factor. Some forms of 2FA can be phished just as easily as a password, but 2FA that relies on a FIDO2 device can’t be phished.
• Watch out for impersonators. The thieves may contact you posing as the breached platform. Check the official website to see if it’s contacting victims and verify the identity of anyone who contacts you using a different communication channel.
• Take your time. Phishing attacks often impersonate people or brands you know, and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
• Consider not storing your card details. It’s definitely more convenient to let sites remember your card details, but it increases risk if a retailer suffers a breach.
• Set up identity monitoring, which alerts you if your personal information is found being traded illegally online and helps you recover after.
• Use our free Digital Footprint scan to see whether your personal information has been exposed online.

Tech bros have been wanting to become immortal for years. Until they get there, their fallback might be continuing to post nonsense on social media from the afterlife.

On December 30, 2025, Meta was granted US patent 12513102B2: Simulation of a user of a social networking system using a language model. It describes a system that trains an AI on a user’s posts, comments, chats, voice messages, and likes, then deploys a bot to respond to newsfeeds, DMs, and even simulated audio or video calls.

Filed in November 2023 by Meta CTO Andrew Bosworth, it sounds innocuous enough. Perhaps some people would use it to post their political hot takes while they’re asleep.

Dig deeper, though, and the patent veers from absurd to creepy. It’s designed to be used not just from beyond the pillow but beyond the grave.

From the patent:

“The language model may be used for simulating the user when the user is absent from the social networking system, for example, when the user takes a long break or if the user is deceased.”

A Meta spokesperson told Business Insider that the company has no plans to act on the patent. And tech companies have a habit of laying claim to bizarre ideas that never materialize. But Facebook’s user numbers have stalled, and it presumably needs all the engagement it can get. We already know that the company loves the idea of AI ‘users’, having reportedly piloted them in late 2024, much to human users’ annoyance.

If the company ever did decide to pull the trigger on this technology, it would be a departure from its own memorialization policy, which preserves accounts without changes. One reason the company might not be willing to step over the line is that the world simply isn’t ready for AI conversations with the dead. Other companies have considered and even tested similar systems. Microsoft patented a chatbot that would allow you to talk to AI versions of deceased individuals in 2020; its own AI general manager called it disturbing, and it never went into production. Amazon demonstrated Alexa mimicking a dead grandmother’s voice from under a minute of audio in 2022, framing it as preserving memories. That never launched either.

Some projects that did ship left people wishing they hadn’t. Startup 2Wai’s avatar app originally offered the chance to preserve loved ones as AI avatars. Users called it “nightmare fuel” and “demonic”. The company seems to have pivoted to safer ground like social avatars and personal AI coaches now.

The legal minefield

The other thing holding Meta back could be the legal questions. Unsurprisingly for such a new idea, there isn’t a uniform US framework on the use of AI to represent the dead. Several states recognize post-mortem right of publicity, although states like New York limit that to people whose voices and images have commercial value (typically meaning celebrities). California’s AB 1836 specifically targets AI-generated impersonations of the deceased, though.

Meta would also need to tiptoe carefully around the law in Europe. The company had to pause AI training on European users in 2024 under regulatory pressure, but then launched it anyway in March last year. Then it refused to sign the EU’s GPAI Code of Practice last July (the only major AI firm to do so). Meta’s relationship with EU regulators is strained at best.

Europe’s General Data Protection Regulation (GDPR) excludes deceased persons’ data, but Article 85 of the French Data Protection law lets anyone leave instructions about the retention, deletion and communication of their personal data after death. The EU AI Act’s Article 50 (fully applicable this August) will also require AI systems to disclose they are AI, with penalties up to €15 million or 3% of worldwide turnover for companies that don’t comply.

Hopefully Meta really will file this in the “just because we can do it doesn’t mean we should” drawer, and leave erstwhile social media sharers to rest in peace.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

Introduction

In October 2025, we discovered a series of forum posts advertising a previously unknown stealer, dubbed “Arkanix Stealer” by its authors. It operated under a MaaS (malware-as-a-service) model, providing users not only with the implant but also with access to a control panel featuring configurable payloads and statistics. The set of implants included a publicly available browser post-exploitation tool known as ChromElevator, which was delivered by a native C++ version of the stealer. This version featured a wide range of capabilities, from collecting system information to stealing cryptocurrency wallet data. Alongside that, we have also discovered Python implementation of the stealer capable of dynamically modifying its configuration. The Python version was often packed, thus giving the adversary multiple methods for distributing their malware. It is also worth noting that Arkanix was rather a one-shot malicious campaign: at the time of writing this article, the affiliate program appears to be already taken down.

Kaspersky products detect this threat as Trojan-PSW.Win64.Coins.*, HEUR:Trojan-PSW.Multi.Disco.gen, Trojan.Python.Agent.*.

Technical details

Background

In October 2025, a series of posts was discovered on various dark web forums, advertising a stealer referred to by its author as “Arkanix Stealer”. These posts detail the features of the stealer and include a link to a Discord server, which serves as the primary communication channel between the author and the users of the stealer.

Example of an Arkanix Stealer advertisement

Upon further research utilizing public resources, we identified a set of implants associated with this stealer.

Initial infection or spreading

The initial infection vector remains unknown. However, based on some of the file names (such as steam_account_checker_pro_v1.py, discord_nitro_checker.py, and TikTokAccountBotter.exe) of the loader scripts we obtained, it can be concluded with high confidence that the initial infection vector involved phishing.

Python loader

The Python loader is the script responsible for downloading and executing the Python-based version of the Arkanix infostealer. We have observed both plaintext Python scripts and those bundled using PyInstaller or Nuitka, all of which share a common execution vector and are slightly obfuscated. These scripts often serve as decoys, initially appearing to contain legitimate code. Some of them do have useful functionality, and others do nothing apart from loading the stealer. Additionally, we have encountered samples that employ no obfuscation at all, in which the infostealer is launched in a separate thread via Python’s built-in threading module.

Variants of Python loaders executing the next stage

Upon execution, the loader first installs the required packages — namely, requests, pycryptodome, and psutil — via the pip package manager, utilizing the subprocess module. On Microsoft Windows systems, the loader also installs pywin32. In some of the analyzed samples, this process is carried out twice. Since the loader does not perform any output validation of the module installation command, it proceeds to make a POST request to hxxps://arkanix[.]pw/api/session/create to register the current compromised machine on the panel with a predefined set of parameters even if the installation failed. After that, the stealer makes a GET request to hxxps://arkanix[.]pw/stealer.py and executes the downloaded payload.

Python stealer version

During our research, we obtained a sample of the Python implementation of the Arkanix stealer, which was downloaded from the endpoint hxxps://arkanix[.]pw/stealer.py by the previous stage.

The stealer’s capabilities — or features, as referred to by the author — in this version are configurable, with the default configuration predefined within the script file. To dynamically update the feature list, the stealer makes a GET request to hxxps://arkanix[.]pw/api/features/{payload_id}, indicating that these capabilities can be modified on the panel side. The feature list is identical to the one that was described in the GDATA report.

Configurable options

Prior to executing the information retrieval-related functions, the stealer makes a request to hxxps://arkanix[.]pw/upload_dropper.py, saves the response to %TEMP%\upd_{random 8-byte name}.py, and executes it. We do not have access to the contents of this script, which is referred to as the “dropper” by the attackers.

During its main information retrieval routine, at the end of each processing stage, the collected information is serialized into JSON format and saved to a predefined path, such as %LOCALAPPDATA\Arkanix_lol\%info_class%.json.

In the following, we will provide a more detailed description of the Python version’s data collection features.

System info collection

Arkanix Stealer is capable of collecting a set of info about the compromised system. This info includes:

• OS version
• CPU and GPU info
• RAM size
• Screen resolution
• Keyboard layout
• Time zone
• Installed software
• Antivirus software
• VPN

Information collection is performed using standard shell commands with the exception of the VPN check. The latter is implemented by querying the endpoint hxxps://ipapi[.]co/json/ and verifying whether the associated IP address belongs to a known set of VPNs, proxies, or Tor exit nodes.

Browser features

This stealer is capable of extracting various types of data from supported browsers (22 in total, ranging from the widely popular Google Chrome to the Tor Browser). The list of supported browsers is hardcoded, and unlike other parameters, it cannot be modified during execution. In addition to a separate Chrome grabber module (which we’ll discuss later), the stealer itself supports the extraction of diverse information, such as:

• Browser history (URLs, visit count and last visit)
• Autofill information (email, phone, addresses and payment cards details)
• Saved passwords
• Cookies
• In case of Chromium-based browsers, 0Auth2 data is also extracted

All information is decrypted using either the Windows DPAPI or AES, where applicable, and searched for relevant keywords. In the case of browser information collection, the stealer searches exclusively for keywords related to banking (e.g., “revolut”, “stripe”, “bank”) and cryptocurrencies (e.g., “binance”, “metamask”, “wallet”). In addition to this, the stealer is capable of extracting extension data from a hardcoded list of extensions associated with cryptocurrencies.

Part of the extension list which the stealer utilizes to extract data from

Telegram info collection

Telegram data collection begins with terminating the Telegram.exe process using the taskkill command. Subsequently, if the telegram_optimized feature is set to False, the malware zips the entire tdata directory (typically located at %APPDATA%\Roaming\Telegram Desktop\tdata) and transmits it to the attacker. Otherwise, it selectively copies and zips only the subdirectories containing valuable info, such as message log. The generated archive is sent to the endpoint /delivery with the filename tdata_session.zip.

Discord capabilities

The stealer includes two features connected with Discord: credentials stealing and self-spreading. The first one can be utilized to acquire credentials both from the standard client and custom clients. If the client is Chromium-based, the stealer employs the same data exfiltration mechanism as during browser credentials stealing.

The self-spreading feature is configurable (meaning it can be disabled in the config). The stealer acquires the list of user’s friends and channels via the Discord API and sends a message provided by the attacker. This stealer does not support attaching files to such messages.

VPN data collection

The VPN collector is searching for a set of known VPN software to extract account credentials from the credentials file with a known path that gets parsed with a regular expression. The extraction occurs from the following set of applications:

• Mullvad VPN
• NordVPN
• ExpressVPN
• ProtonVPN

File retrieval

File retrieval is performed regardless of the configuration. The script relies on a predefined set of paths associated with the current user (such as Desktop, Download, etc.) and file extensions mainly connected with documents and media. The script also has a predefined list of filenames to exfiltrate. The extracted files are packed into a ZIP archive which is later sent to the C2 asynchronously. An interesting aspect is that the filename list includes several French words, such as “motdepasse” (French for “password”), “banque” (French for “bank”), “secret” (French for “secret”), and “compte” (French for “account”).

Other payloads

We were able to identify additional modules that are downloaded from the C2 rather than embedded into the stealer script; however, we weren’t able to obtain them. These modules can be described by the following table, with the “Details” column referring to the information that could be extracted from the main stealer code.

The Wallet patcher and Extra collector scripts are received in an encrypted form from the C2 server. To decrypt them, the attackers utilize the AES-GCM algorithm in conjunction with PBKDF2 (HMAC and SHA256). After decryption, the additional payload has its template placeholders replaced and is stored under a partially randomized name within a temporary folder.

Decryption routine and template substitution

Once all operations are completed, the stealer removes itself from the drive, along with the artifacts folder (Arkanix_lol in this case).

Native version of stealer

During our analysis, we were able to obtain both the release and debug versions of the native implementation, as both were uploaded to publicly available resources. The following are the key differences between the two:

• The release version employs VMProtect, but does not utilize code virtualization.
• The debug version communicates with a Discord bot for command and control (C2), whereas the release version uses the previously mentioned C2 domain arkanix[.]pw.
• The debug version includes extensive logging, presumably for the authors’ debugging purposes.

Notably, the native implementation explicitly references the name of the stealer in the VersionInfo resources. This naming convention is consistent across both the debug version and certain samples containing the release version of the implant.

Version info

After launching, the stealer implements a series of analysis countermeasures to verify that the application is not being executed within a sandboxed environment or run under a debugger. Following these checks, the sample patches AmsiScanBuffer and EtwEventWrite to prevent the triggering of any unwanted events by the system.

Once the preliminary checks are completed, the sample proceeds to gather information about the system. The list of capabilities is hardcoded and cannot be modified from the server side, in contrast to the Python version. What is more, the feature list is quite similar to the Python version except a few ones.

RDP connections

The stealer is capable of collecting information about known RDP connections that the compromised user has. To achieve this, it searches for .rdp files in %USERPROFILE%\Documents and extracts the full server address, password, username and server port.

Gaming files

The stealer also targets gamers and is capable to steal credentials from the popular gaming platform clients, including:

• Steam
• Epic Games Launcher
• net
• Riot
• Origin
• Unreal Engine
• Ubisoft Connect
• GOG

Screenshots

The native version, unlike its Python counterpart, is capable of capturing screenshots for each monitor via capCreateCaptureWindowA WinAPI.
In conclusion, this sample communicates with the C2 server through the same endpoints as the Python version. However, in this instance, all data is encrypted using the same AES-GCM + PBKDF2 (HMAC and SHA256) scheme as partially employed in the Python variant. In some observed samples, the key used was arkanix_secret_key_v20_2024. Alongside that, the C++ sample explicitly sets the User-Agent to ArkanixStealer/1.0.

Post-exploitation browser data extractor

This is an implant embedded within the resources of the C++ implementation. The author incorporated it into the resource section without applying any obfuscation or encryption. Subsequently, the stealer extracts the payload to a temporary folder with a randomly generated name composed of hexadecimal digits (0-9 and A-F) and executes it using the CreateProcess WinAPI. The payload itself is the unaltered publicly available project known as “ChromElevator”. To summarize, this tool consists of two components: an injector and the main payload. The injector initializes a direct syscall engine, spawns a suspended target browser process, and injects the decrypted code into it via Nt syscalls. The injected payload then decrypts the browser master key and exfiltrates data such as cookies, login information, web data, and so on.

Infrastructure

During the Arkanix campaign, two domains used in the attacks were identified. Although these domains were routed through Cloudflare, a real IP address was successfully discovered for one of them, namely, arkanix[.]pw. For the second one we only obtained a Cloudflare IP address.

Both servers were also utilized to host the stealer panel, which allows attackers to monitor their victims. The contents of the panel are secured behind a sign-in page. Closer to the end of our research, the panel was seemingly taken down with no message or notice.

Stealer panel sign-in page

Stealer promotion

During the research of this campaign, we noticed that the forum posts advertising the stealer contained a link leading to a Discord server dubbed “Arkanix” by the authors. The server posed as a forum where authors posted various content and clients could ask various questions regarding this malicious software. While users mainly thank and ask about when the feature promised by the authors will be released and added into the stealer, the content made by the authors is broader. The adversary builds up the communication with potential buyers using the same marketing and communication methods real companies employ. To begin with, they warm up the audience by posting surveys about whether they should implement specific features, such as Discord injection and binding with a legitimate application (sic!).

Feature votes

Additionally, the author promised to release a crypter as a side project in four to six weeks, at the end of October. As of now, the stealer seems to have been taken down without any notice while the crypter was never released.

Arkanix Crypter

Furthermore, the Arkanix Stealer authors decided to implement a referral program to attract new customers. Referrers were promised an additional free hour to their premium license, while invited customers received seven days of free “premium” trial use. As stated in forum posts, the premium plan included the following features:

• C++ native stealer
• Exodus and Atomic cryptocurrency wallets injection
• Increased payload generation, up to 10 payloads
• Priority support

Referral program ad and corresponding panel interface

Speaking of technical details, based on the screenshot of the Visual Studio stealer project that was sent to the Discord server, we can conclude that the author is German-speaking.

This same screenshot also serves as a probable indicator of AI-assisted development as it shares the common patterns of such assistants, e.g. the presence of the utils.cpp file. What provides even more confidence is the overall code structure, the presence of comments and extensive debugging log output.

Example of LLM-specific patterns

Conclusions

Information stealers have always posed as a serious threat to users’ data. Arkanix is no exception as it targets a wide range of users, from those interested in cryptocurrencies and gaming to those using online banking. It collects a vast amount of information including highly sensitive personal data. While being quite functional, it contains probable traces of LLM-assisted development which suggests that such assistance might have drastically reduced development time and costs. Hence it follows that this campaign tends to be more of a one-shot campaign for quick financial gains rather than a long-running infection. The panel and the Discord chat were taken down around December 2025, leaving no message or traces of further development or a resurgence.

In addition, the developers behind the Arkanix Stealer decided to address the public, implementing a forum where they posted development insights, conducted surveys and even ran a referral program where you could get bonuses for “bringing a friend”. This behavior makes Arkanix more of a public software product than a shady stealer.

Indicators of Compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

File hashes
752e3eb5a9c295ee285205fb39b67fc4
c1e4be64f80bc019651f84ef852dfa6c
a8eeda4ae7db3357ed2ee0d94b963eff
c0c04df98b7d1ca9e8c08dd1ffbdd16b
88487ab7a666081721e1dd1999fb9fb2
d42ba771541893eb047a0e835bd4f84e
5f71b83ca752cb128b67dbb1832205a4
208fa7e01f72a50334f3d7607f6b82bf
e27edcdeb44522a9036f5e4cd23f1f0c
ea50282fa1269836a7e87eddb10f95f7
643696a052ea1963e24cfb0531169477
f5765930205719c2ac9d2e26c3b03d8d
576de7a075637122f47d02d4288e3dd6
7888eb4f51413d9382e2b992b667d9f5
3283f8c54a3ddf0bc0d4111cc1f950c0

Domains and IPs
arkanix[.]pw
arkanix[.]ru

Betterment LLC is an investment advisor registered with US Securities and Exchange Commission (SEC). The company disclosed a January 2026 incident in which an attacker used social engineering to access a third‑party platform used for customer communications, then abused it to send crypto‑themed phishing messages and exfiltrate contact and identity data for more than a million people.

What makes this particularly concerning is the depth of the exposed information. This isn’t just a list of email addresses. The leaked files include retirement plan details, financial interests, internal meeting notes, and pipeline data. It’s information that gives cybercriminals real context about a person’s finances and professional life.

What’s worse is that ransomware group Shiny Hunters claims that, since Betterment refused to pay their demanded ransom, it is publishing the stolen data.

While Betterment has not revealed the number of affected customers in its online communications, general consensus indicates that the data of 1.4 million customers was involved. And now, every cybercriminal can download this information at their leisure.

We analyzed some of the data and found one particularly worrying CSV file with detailed data on 181,487 people. This file included information such as:

• Full names (first and last)
• Personal email addresses (e.g., Gmail)
• Work email addresses
• Company name and employer info
• Job titles and roles
• Phone numbers (both mobile and work numbers)
• Addresses and company websites
• Plan details—company retirement/401k plans, assets, participants
• Survey responses, deal and client pipeline details, meeting notes
• Financial needs/interests (e.g., requesting a securities-backed line of credit for a house purchase)

This kind of data is a gold mine for phishers, who can use it in targeted attacks. It has enough context to craft convincing, individually tailored phishing emails. For example:

• Addressing someone by their real name, company, and job title
• Referencing the company’s retirement or financial plans
• Impersonating Betterment advisors or plan administrators
• Initiating scam calls about financial advice

Combined with data from other breaches it could even be worse and lead to identity theft.

What to do if your data was in a breach

If you think you have been affected by a data breach, here are steps you can take to protect yourself:

• Check the company’s advice. Every breach is different, so check with the company to find out what’s happened and follow any specific advice it offers.
• Change your password. You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
• Enable two-factor authentication (2FA). If you can, use a FIDO2-compliant hardware key, laptop, or phone as your second factor. Some forms of 2FA can be phished just as easily as a password, but 2FA that relies on a FIDO2 device can’t be phished.
• Watch out for impersonators. The thieves may contact you posing as the breached platform. Check the official website to see if it’s contacting victims and verify the identity of anyone who contacts you using a different communication channel.
• Take your time. Phishing attacks often impersonate people or brands you know, and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
• Consider not storing your card details. It’s definitely more convenient to let sites remember your card details, but it increases risk if a retailer suffers a breach.
• Set up identity monitoring, which alerts you if your personal information is found being traded illegally online and helps you recover after.

Use Malwarebytes’ free Digital Footprint scan to see whether your personal information has been exposed online.

We don’t just report on threats—we help safeguard your entire digital identity

Cybersecurity risks should never spread beyond a headline. Protect your, and your family’s, personal information by using identity protection.

The post A milestone achievement in our journey to carbon negative appeared first on Microsoft On the Issues.

As part of our investigation into a job-themed phishing campaign, we came across several suspicious URLs that all looked like this:

https://forms.google.ss-o[.]com/forms/d/e/{unique_id}/viewform?form=opportunitysec&promo=

The subdomain forms.google.ss-o[.]com is a clear attempt to impersonate the legitimate forms.google.com. The “ss-o” is likely introduced to look like “single sign-on,” an authentication method that allows users to securely log in to multiple, independent applications or websites using one single set of credentials (username and password).

Unfortunately, when we tried to visit the URLs we were redirected to the local Google search website. This is a common phisher’s tactic to prevent victims from sharing their personalized links with researchers or online analysis.

After some digging, we found a file called generation_form.php on the same domain, which we believe the phishing crew used to create these links. The landing page for the campaign was: https://forms.google.ss-o[.]com/generation_form.php?form=opportunitysec

The generation_form.php script does what the name implies: It creates a personalized URL for the person clicking that link.

With that knowledge in hand, we could check what the phish was all about. Our personalized link brought us to this website:

The greyed out “form” behind the prompt promises:

• We’re Hiring! Customer Support Executive (International Process)
• Are you looking to kick-start or advance your career…
• The fields in the form: Full Name, Email address, and an essay field “Please describe in detail why we should choose you”
• Buttons: “Submit” and “Clear form.”

The whole web page emulates Google Forms, including logo images, color schemes, a notice about not “submitting passwords,” and legal links. At the bottom, it even includes the typical Google Forms disclaimer (“This content is neither created nor endorsed by Google.”) for authenticity.

Clicking the “Sign in” button took us to https://id-v4[.]com/generation.php, which has now been taken down. The domain id-v4.com has been used in several phishing campaigns for almost a year. In this case, it asked for Google account credentials.

Given the “job opportunity” angle, we suspect links were distributed through targeted emails or LinkedIn messages.

How to stay safe

Lures that promise remote job opportunities are very common these days. Here are a few pointers to help keep you safe from targeted attacks like this:

• Do not click on links in unsolicited job offers.
• Use a password manager, which would not have filled in your Google username and password on a fake website.
• Use an up to date, real-time anti-malware solution with a web protection component.

Pro tip: Malwarebytes Scam Guard identified this attack as a scam just by looking at the URL.

IOCs

id-v4[.]com

forms.google.ss-o[.]com

We don’t just report on scams—we help detect them

Cybersecurity risks should never spread beyond a headline. If something looks dodgy to you, check if it’s a scam using Malwarebytes Scam Guard. Submit a screenshot, paste suspicious content, or share a link, text or phone number, and we’ll tell you if it’s a scam or legit. Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.

The problem isn’t that we lack threat intelligence. It’s that we lack the right kind of intelligence, intelligence that connects what’s happening inside your environment with what attackers are planning outside it. That’s why two types of threat intelligence matter: internal and external. Alone, each tells part of the story. Together, they create clarity. Why Threat Intelligence Alone Falls Short Most organizations subscribe to multiple threat feeds. They pour in from every direction, generic, fragmented, and often delayed. Instead of clarifying risk, they confuse it. “Organizations still make critical decisions based on incomplete or underrefined threat data.” — Gartner, The […]

The post Two Types of Threat Intelligence That Make Security Work appeared first on Check Point Blog.

Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV in their AES-CTR API, leading to a large number of key/IV reuse bugs. These bugs potentially affect thousands of downstream projects. When we shared one of these bugs with an affected vendor, strongSwan, the maintainer provided a model response for security vendors. The aes-js/pyaes maintainer, on the other hand, has taken a more… cavalier approach.

Trail of Bits doesn’t usually make a point of publicly calling out specific products as unsafe. Our motto is that we don’t just fix bugs—we fix software. We do better by the world when we work to address systemic threats, not individual bugs. That’s why we work to provide static analysis tools, auditing tools, and documentation for folks looking to implement cryptographic software. When you improve systems, you improve software.

But sometimes, a single bug in a piece of software has an outsized impact on the cryptography ecosystem, and we need to address it.

This is the story of how two developers reacted to a security problem, and how their responses illustrate the difference between carelessness and craftsmanship.

Reusing initialization vectors

Reusing a key/IV pair leads to serious security issues: if you encrypt two messages in CTR mode or GCM with the same key and IV, then anybody with access to the ciphertexts can recover the XOR of the plaintexts, and that’s a very bad thing. Like, “your security is going to get absolutely wrecked” bad. One of our cryptography analysts has written an excellent introduction to the topic, in case you’d like more details; it’s great reading.

Even if the XOR of the plaintexts doesn’t help an attacker, it still makes the encryption very brittle: if you’re encrypting all your secrets by XORing them against a fixed mask, then recovering just one of those secrets will reveal the mask. Once you have that, you can recover all the other secrets. Maybe all your secrets will remain secure against prying eyes, but the fact remains: in the very best case, the security of all your secrets becomes no better than the security of your weakest secret.

aes-js and pyaes

As you might guess from the names, aes-js and pyaes are JavaScript and Python libraries that implement the AES block cipher. They’re pretty widely used: the Node.js package manager (npm) repository lists 850 aes-js dependents as of this writing, and GitHub estimates that over 700,000 repositories integrate aes-js and nearly 23,000 repositories integrate pyaes, either as direct or indirect dependencies.

Unfortunately, despite their widespread adoption, aes-js and pyaes suffer from a careless mistake that creates serious security problems.

The default IV problem

We’ll start with the biggest concern Trail of Bits identified: when instantiating AES in CTR mode, aes-js and pyaes do not require an IV. Instead, if no IV is specified, libraries will supply a default IV of 0x00000000_00000000_00000000_00000001.

Worse still, the documentation provides examples of this behavior as typical behavior. For example, this comes from the pyaes README:

aes = pyaes.AESModeOfOperationCTR(key)
plaintext = "Text may be any length you wish, no padding is required"
ciphertext = aes.encrypt(plaintext)

The first line ought to be something like aes = pyaes.AESModeOfOperationCTR(key, iv), where iv is a randomly generated value. Users who follow this example will always wind up with the same IV, making it inevitable that many (if not most) will wind up with a key/IV reuse bug in their software. Most people are looking for an easy-to-use encryption library, and what’s simpler than just passing in the key?

That apparent simplicity has led to widespread use of the “default,” creating a multitude of key/IV reuse vulnerabilities.

Other issues

Lack of modern cipher modes

aes-js and pyaes don’t support modern cipher modes like AES-GCM and AES-GCM-SIV. In most contexts where you want to use AES, you likely want to use these modes, as they offer authentication in addition to encryption. This is no small issue: even for programs that use aes-js or pyaes with distinct key/IV pairs, AES CTR ciphertexts are still malleable: if an attacker changes the bits in the ciphertext, then the resulting bits in the plaintext will change in exactly the same way, and CTR mode doesn’t provide any way to detect this. This can allow an attacker to recover an ECDSA key by tricking the user into signing messages with a series of related keys.

Cipher modes like GCM and GCM-SIV prevent this by computing keyed “tags” that will fail to authenticate when the ciphertext is modified, even by a single bit. Pretty nifty feature, but support is completely absent from aes-js and pyaes.

Timing problems

On top of that, both aes-js and pyaes are vulnerable to side-channel attacks. Both libraries use lookup tables for the AES S-box, which enables cache-timing attacks. On top of that, there are timing issues in the PKCS7 implementation, enabling a padding oracle attack when used in CBC mode.

Lack of updates

aes-js hasn’t been updated since 2018. pyaes hasn’t been touched since 2017. Since then, a number of issues have been filed against both libraries. Here are just a few examples:

• Outdated distribution tools for pyaes (it relies on distutils, which has been deprecated since October 2023)
• Performance issues in the streaming API
• UTF-8 encoding problems in aes-js
• Lack of IV and key generation routines in both

Developer response

Finally, in 2022, an issue was filed against aes-js about the default IV problem. The developer’s response ended with the following:

The AES block cipher is a cryptographic primitive, so it’s very important to understand and use it properly, based on its application. It’s a powerful tool, and with great power, yadda, yadda, yadda. :)

Look, even at the best of times, cryptography is a minefield: a space full of hidden dangers, where one wrong step can blow things up entirely. When designing tools for others, developers have a responsibility to help their users avoid foreseeable mistakes—or at the very least, to avoid making it more likely that they’ll step on such landmines. Writing off a serious concern like this with “yadda, yadda, yadda” is deeply concerning.

In November 2025, we reached out to the maintainer via email and via X, but we received no response.

The original design decision to include a default IV was a mistake, but an understandable one for somebody trying to make their library accessible to as many people as possible. And mistakes happen, especially in cryptography. The problem is what came next. When a user raised the concern, it was written off with ‘yadda, yadda, yadda.’ The landmine wasn’t removed. The documentation still suggests the best way to step on it. This is what carelessness looks like: not the initial mistake, but the choice to leave it unfixed when its danger became clear.

Craftsmanship

We identified several pieces of software impacted by the default IV behavior in pyaes and aes-js. Many of the programs we found have been deprecated, and we even found a couple of vulnerable wallets for cryptocurrencies that are no longer traded. We also picked out a large number of programs where the security impact of key/IV reuse was minimal or overshadowed by larger security concerns (for instance, there were a few programs that reused key/IV pairs, but the key was derived from a 4-digit PIN).

However, one of the programs we found struck us as important: a VPN management suite.

strongMan VPN Manager

strongMan is a web-based management tool for folks using the strongSwan VPN suite. It allows for credential and user management, initiation of VPN connections, and more. It’s a pretty slick piece of software; if you’re into IPsec VPNs, you should definitely give it a look.

strongMan stored PKCS#8-encoded keys in a SQLite database, encrypted with AES. As you’ve probably guessed, it used pyaes to encrypt them in CTR mode, relying on the default IV. In PKCS#8 key files, RSA private keys include both the decryption exponent and the factors of the public modulus. For the same modulus size, the factors of the modulus will “line up” to start at the same place in the private key encodings about 99.6% of the time. For a pair of 2048-bit moduli, we can use the XOR of the factors to recover the factors in a matter of seconds.

Even worse, the full X.509 certificates were also encrypted using the same key/IV pair used to encrypt the private keys. Since certificates include a huge amount of predictable or easily guessable data, it’s easy to recover the keystream from the known X.509 data, and then use the recovered keystream to decrypt the private keys without resorting to any fancy XORed-factors mathematical trickery.

In short, if a hacker could recover a strongMan user’s SQLite file, they could immediately impersonate anyone whose certificates are stored in the database and even mount person-in-the-middle attacks. Obviously, this is not a great outcome.

We privately reported this issue to the strongSwan team. Tobias Brunner, the strongMan maintainer, provided an absolute model response to a security issue of this severity. He immediately created a security-fix branch and collaborated with Trail of Bits to develop stronger protection for his users. This patch has since been rolled out, and the update includes migration tools to help users update their old databases to the new format.

Doing it right

There were several viable approaches to fixing this issue. Adding a unique IV for each encrypted entry in the database would have allowed strongMan to keep using pyaes, and would have addressed the immediate issue. But if the code has to be changed, it may as well be updated to something modern.

After some discussion, several changes were made to the application:

• pyaes was replaced with a library that supports modern cipher modes.
• CTR mode was replaced with GCM-SIV, a cipher mode that includes authentication tags.
• Tag-checking was integrated into the decryption routines.
• A per-entry key derivation scheme is now used to ensure that key/IV pairs don’t repeat.

On top of all that, there are now migration scripts to allow strongMan users to seamlessly update their databases.

There will be a security advisory for strongMan issued in conjunction with this fix, outlining the nature of the problem, its severity, and the measures taken to address it. Everything will be out in the open, with full transparency for all strongMan users.

What Tobias did in this case has a name: craftsmanship. He sweated the details, thought extensively about his decisions, and moved with careful deliberation.

A difference in approaches

Mistakes in cryptography are not a sin, even if they can have a serious impact. They’re simply a fact of life. As somebody once said, “cryptography is nightmare magic math that cares what color pen you use.” We’re all going to get stuff wrong if we stick around long enough to do something interesting, and there’s no reason to deride somebody for making a mistake.

What matters—what separates carelessness from craftsmanship—is the response to a mistake. A careless developer will write off a mistake as no big deal or insist that it isn’t really a problem—yadda, yadda, yadda. A craftsman will respond by fixing what’s broken, examining their tools and processes, and doing what they can to prevent it from happening again.

In the end, only you can choose which way you go. Hopefully, you’ll choose craftsmanship.

Scammers have found a new use for AI: creating custom chatbots posing as real AI assistants to pressure victims into buying worthless cryptocurrencies.

We recently came across a live “Google Coin” presale site featuring a chatbot that claimed to be Google’s Gemini AI assistant. The bot guided visitors through a polished sales pitch, answered their questions about investment, projecting returns, and ultimately ended with victims sending an irreversible crypto payment to the scammers.

Google does not have a cryptocurrency. But as “Google Coin” has appeared before in scams, anyone checking it out might think it’s real. And the chatbot was very convincing.

AI as the closer

The chatbot introduced itself as,

“Gemini — your AI assistant for the Google Coin platform.”

It used Gemini-style branding, including the sparkle icon and a green “Online” status indicator, creating the immediate impression that it was an official Google product.

When asked, “Will I get rich if I buy 100 coins?”, the bot responded with specific financial projections. A $395 investment at the current presale price would be worth $2,755 at listing, it claimed, representing “approximately 7x” growth. It cited a presale price of $3.95 per token, an expected listing price of $27.55, and invited further questions about “how to participate.”

This is the kind of personalized, responsive engagement that used to require a human scammer on the other end of a Telegram chat. Now the AI does it automatically.

A persona that never breaks

What stood out during our analysis was how tightly controlled the bot’s persona was. We found that it:

• Claimed consistently to be “the official helper for the Google Coin platform”
• Refused to provide any verifiable company details, such as a registered entity, regulator, license number, audit firm, or official email address
• Dismissed concerns and redirected them to vague claims about “transparency” and “security”
• Refused to acknowledge any scenario in which the project could be a scam
• Redirected tougher questions to an unnamed “manager” (likely a human closer waiting in the wings)

When pressed, the bot doesn’t get confused or break character. It loops back to the same scripted claims: a “detailed 2026 roadmap,” “military-grade encryption,” “AI integration,” and a “growing community of investors.”

Whoever built this chatbot locked it into a sales script designed to build trust, overcome doubt, and move visitors toward one outcome: sending cryptocurrency.

Why AI chatbots change the scam model

Scammers have always relied on social engineering. Build trust. Create urgency. Overcome skepticism. Close the deal.

Traditionally, that required human operators, which limited how many victims could be engaged at once. AI chatbots remove that bottleneck entirely.

A single scam operation can now deploy a chatbot that:

• Engages hundreds of visitors simultaneously, 24 hours a day
• Delivers consistent, polished messaging that sounds authoritative
• Impersonates a trusted brand’s AI assistant (in this case, Google’s Gemini)
• Responds to individual questions with tailored financial projections
• Escalates to human operators only when necessary

This matches a broader trend identified by researchers. According to Chainalysis, roughly 60% of all funds flowing into crypto scam wallets were tied to scammers using AI tools. AI-powered scam infrastructure is becoming the norm, not the exception. The chatbot is just one piece of a broader AI-assisted fraud toolkit—but it may be the most effective piece, because it creates the illusion of a real, interactive relationship between the victim and the “brand.”

The bait: a polished fake

The chatbot sits on top of a convincing scam operation. The Google Coin website mimics Google’s visual identity with a clean, professional design, complete with the “G” logo, navigation menus, and a presale dashboard. It claims to be in “Stage 5 of 5” with over 9.9 million tokens sold and a listing date of February 18—all manufactured urgency.

To borrow credibility, the site displays logos of major companies—OpenAI, Google, Binance, Squarespace, Coinbase, and SpaceX—under a “Trusted By Industry” banner. None of these companies have any connection to the project.

If a visitor clicks “Buy,” they’re taken to a wallet dashboard that looks like a legitimate crypto platform, showing balances for “Google” (on a fictional “Google-Chain”), Bitcoin, and Ethereum.

The purchase flow lets users buy any number of tokens they want and generates a corresponding Bitcoin payment request to a specific wallet address. The site also layers on a tiered bonus system that kicks in at 100 tokens and scales up to 100,000: buy more and the bonuses climb from 5% up to 30% at the top tier. It’s a classic upsell tactic designed to make you think it’s smarter to spend more.

Every payment is irreversible. There is no exchange listing, no token with real value, and no way to get your money back.

What to watch for

We’re entering an era where the first point of contact in a scam may not be a human at all. AI chatbots give scammers something they’ve never had before: a tireless, consistent, scalable front-end that can engage victims in what feels like a real conversation. When that chatbot is dressed up as a trusted brand’s official AI assistant, the effect is even more convincing.

According to the FTC’s Consumer Sentinel data, US consumers reported losing $5.7 billion to investment scams in 2024 (more than any other type of fraud, and up 24% on the previous year). Cryptocurrency remains the second-largest payment method scammers use to extract funds, because transactions are fast and irreversible. Now add AI that can pitch, persuade, and handle objections without a human operator—and you have a scalable fraud model.

AI chatbots on scam sites will become more common. Here’s how to spot them:

They impersonate known AI brands. A chatbot calling itself “Gemini,” “ChatGPT,” or “Copilot” on a third-party crypto site is almost certainly not what it claims to be. Anyone can name a chatbot anything.

They won’t answer due diligence questions. Ask what legal entity operates the platform, what financial regulator oversees it, or where the company is registered. Legitimate operations can answer those questions, scam bots try to avoid them (and if they do answer, verify it).

They project specific returns. No legitimate investment product promises a specific future price. A chatbot telling you that your $395 will become $2,755 is not giving you financial information—it’s running a script.

They create urgency. Pressure tactics like, “stage 5 ends soon,” “listing date approaching,” “limited presale” are designed to push you into making fast decisions.

How to protect yourself

Google does not have a cryptocurrency. It has not launched a presale. And its Gemini AI is not operating as a sales assistant on third-party crypto sites. If you encounter anything suggesting otherwise, close the tab.

• Verify claim on the official website of the company being referenced.
• Don’t rely on a chatbot’s branding. Anyone can name a bot anything.
• Never send cryptocurrency based on projected returns.
• Search the project name along with “scam” or “review” before sending any money.
• Use web protection tools like Malwarebytes Browser Guard, which is free to use and blocks known and unknown scam sites.

If you’ve already sent funds, report it to your local law enforcement, the FTC at reportfraud.ftc.gov, and the FBI’s IC3 at ic3.gov.

IOCs

0xEc7a42609D5CC9aF7a3dBa66823C5f9E5764d6DA

98388xymWKS6EgYSC9baFuQkCpE8rYsnScV4L5Vu8jt

DHyDmJdr9hjDUH5kcNjeyfzonyeBt19g6G

TWqzJ9sF1w9aWwMevq4b15KkJgAFTfH5im

bc1qw0yfcp8pevzvwp2zrz4pu3vuygnwvl6mstlnh6

r9BHQMUdSgM8iFKXaGiZ3hhXz5SyLDxupY

We don’t just report on scams—we help detect them

Cybersecurity risks should never spread beyond a headline. If something looks dodgy to you, check if it’s a scam using Malwarebytes Scam Guard. Submit a screenshot, paste suspicious content, or share a link, text or phone number, and we’ll tell you if it’s a scam or legit. Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.

Microsoft announces at the India AI Impact Summit it is on pace to invest USD $50 billion by the end of the decade to help bring AI to countries across the Global South  

Artificial intelligence is diffusing at an impressive speed, but its adoption around the world remains profoundly uneven. As Microsoft’s latest AI Diffusion Report shows, AI usage in the Global North is roughly twice that of the Global South. And this divide continues to widen. This disparity impacts not only national and regional economic growth, but whether AI can deliver on its broader promise of expanding opportunity and prosperity around the world.

The India AI Impact Summit rightly has placed this challenge at the center of its agenda. For more than a century, unequal access to electricity exacerbated a growing economic gap between the Global North and South. Unless we act with urgency, a growing AI divide will perpetuate this disparity in the century ahead.

Solutions will not come easily. The needs are multifaceted, and will require substantial investments and hard work by governments, the private sector, and nonprofit organizations. But the opportunity is clear. If AI is deployed broadly and used well by a young and growing population, it offers a real prospect for catch-up economic growth for the Global South. It might even provide the biggest such opportunity of the 21^st century.

As a company, we are committed to playing an ambitious and constructive role in supporting this opportunity. This week in Delhi, we’re sharing that Microsoft is on pace to invest $50 billion by the end of the decade to help bring AI to countries across the Global South. This is based on a five-part program to drive AI impact, consisting of the following:

• Building the infrastructure needed for AI diffusion
• Empowering people through technology and skills for schools and nonprofits
• Strengthening multilingual and multicultural AI capabilities
• Enabling local AI innovations that address community needs
• Measuring AI diffusion to guide future AI policies and investments

One thing that is clear this week at the summit in India is that success will require many deep partnerships. These must span borders and bring people and organizations together across the public, private, and nonprofit sectors.

1. Building the infrastructure needed for AI diffusion

Infrastructure is a prerequisite for AI diffusion, requiring reliable electricity, connectivity, and compute capacity. To help address infrastructure gaps and support the growing needs of the Global South, Microsoft has steadily increased its investments in AI-enabling infrastructure across these regions. In our last fiscal year alone, Microsoft invested more than  $8 billion in datacenter infrastructure serving the Global South. This includes new infrastructure in India, Mexico, and countries in Africa, South America, Southeast Asia, and the Middle East.

We’re coupling our investments in datacenters with an ambitious effort to help close the Global South’s connectivity divide. We’ve been pursuing aggressively a global goal to extend internet access to 250 million people in unserved and underserved communities in the Global South, including 100 million people in Africa.

As we announced in November, we’ve already reached 117 million people across Africa through partnerships with organizations such as Cassava Technologies, Mawingu, and others that are building last‑mile networks across rural and urban communities alike. We’re closing in on our global goal of reaching 250 million people and will share an update on that progress soon.

We’re investing in AI infrastructure with sensitivity to digital sovereignty needs. We recognize that in a fragmented world, we must offer customers attractive choices for the use of our offerings. This includes sovereign controls in the public cloud, private sovereign offerings, and close collaboration with national partners.

We pursue all this with commitments to protect cybersecurity, privacy, and resilience. In the age of AI, we ensure that our customers’ AI-based innovations and intellectual property remain in their hands and under their control, rather than being transferred to AI providers.

Critically, we balance our focus on national sovereignty with our efforts to support digital trust and stability across borders. The Global South requires enormous investments to fund infrastructure for datacenters, connectivity, and electricity. It is difficult to imagine meeting all these needs without foreign direct investment, including from international technology firms.

This need is part of what informed our announcement last week at the Munich Security Conference of the new Trusted Tech Alliance. This new partnership brings together 16 leading technology companies from 11 countries and four continents. We’ve agreed together that we will adhere to five core principles designed to ensure trust in technology. Ultimately, we believe the Global South—as well as the rest of the world—needs both to protect its digital sovereignty and benefit from new investments and the best digital innovations the world has to offer.

2. Empowering people through technology and skills for schools and nonprofits

Ultimately, datacenters, connectivity, and electricity provide only part of the digital infrastructure a nation needs. History shows that the ability to provide access to technology and technology skills are equally important for economic development.

As a company, we’re focused on this in multiple ways. One critical aspect of our work is based on programs to provide cloud, AI, and other digital technologies to schools and nonprofits across the Global South. Another is our work to advance broad access to AI skills. In our last fiscal year, Microsoft invested more than $2 billion in these programs in the Global South. This includes direct financial grants, technology donations, skilling programs, and below-market product discounts.

AI skills are foundational to ensuring that AI expands opportunity and enables people to pursue more impactful real-world applications. With the launch of Microsoft Elevate in July, we committed to helping 20 million people in and beyond the Global South earn in-demand AI skilling credentials by 2028. After training 5.6 million people across India in 2025, we advanced this work by setting a goal last December to equip 20 million people in India with essential AI skills by 2030.

As part of that commitment, today we are announcing the launch of Elevate for Educators in India to strengthen the capacity of two million teachers across more than 200,000 schools, vocational institutes, and higher education settings. Our goal is to help the country’s teaching workforce lead confidently in an AI‑driven future. The program will be delivered in partnership with India’s national education and workforce training authorities, expanding equitable AI opportunities for eight million students.

Through Microsoft Elevate, we’re also working to introduce new educator credentials and a global professional learning community that enables teachers to share best practices with peers worldwide. This effort will involve large-scale capacity building initiatives, including AI Ambassadors, Educator Academies, AI Productivity Labs, and Centers of Excellence. It will equip 25,000 institutions with inclusive AI infrastructure while integrating AI learning pathways into major government platforms.

3. Strengthening multilingual and multicultural AI capabilities

Language is another major barrier to AI diffusion across the Global South, particularly in regions where digitally underrepresented languages prevail and access to essential services depends on local-language communication. For billions of people worldwide, AI systems perform less consistently in the languages they rely on most than in English.

That’s why we’re announcing this week new steps to increase our investments across the AI lifecycle, from data and models to evaluation and deployment, to strengthen multilingual and multicultural capabilities and support more inclusive AI systems that will better serve the Global South.

First, we’re investing upstream in language data and model capability. This includes support for LINGUA Africa, which builds on what we learned through LINGUA Europe: that investing in language data and model capability in partnership with local communities can materially improve AI performance for underrepresented languages.

Through LINGUA Africa—a $5.5 million open call led by the Masakhane African Languages Hub, Microsoft’s AI for Good Lab, and the Gates Foundation, with additional support from the UK government—we are prioritizing open, responsibly sourced data across text, speech, and vision as well as use-case-driven AI model development. By enabling African languages in high-impact sectors like education, food security, health, and government services, LINGUA Africa aims to ensure AI advances translate into tangible improvements in people’s daily lives.

Second, we’re advancing multilingual and multicultural evaluation tools. We’re helping expand the MLCommons AILuminate benchmark to include major Indic and Asian languages, enabling more reliable measurement of AI safety and security beyond English.

Today, even when automated evaluation tools expand language coverage, they too often rely on machine translation or English-first model behavior, with predictable failures when local expressions shift meaning. Partnering with academic and government institutions in India, Japan, Korea, and Singapore, and with industry, Microsoft is co-leading AILuminate’s multilingual, multicultural, and multimodal expansion that builds from the ground up. With a pilot dataset of 7,000 high-quality text-and-image prompts for Hindi, Tamil, Malay, Japanese, and Korean, we’re developing tools that reflect how risks manifest in local linguistic and cultural contexts, not just how they appear after translation.

Microsoft Research is also advancing Samiksha, a community-centered method for evaluating AI behavior in real-world contexts, in collaboration with Karya and The Collective Intelligence Project in India. Samiksha encodes local language use, culturally specific communication norms, and locally relevant use cases directly into core testing artifacts by surfacing failure modes that English-first evaluations routinely miss.

Finally, we’re working to scale content provenance for linguistic diversity. For trusted AI deployment, the ecosystem benefits from tools to identify the provenance of digital content like images, audio, or video, distinguishing whether it’s AI-generated. With partners in the Coalition for Content Provenance and Authenticity (C2PA), Microsoft is helping extend content provenance standards beyond an English-ready baseline. This includes forthcoming support for multiple Indic languages across metadata, specifications, and UX guidance, alongside efforts to support mobile-first deployment. With these investments, hundreds of millions more people in India will be better equipped to identify synthetic media in their primary language.

4. Enabling local AI innovations that address community needs

As India’s guiding sutras for the AI Impact Summit recognize, AI must be applied to address pressing challenges in collaboration with people and organizations in the Global South. Microsoft’s increasing investments prioritize locally defined problems, locally grounded expertise, and real-world impact. Our goal is straightforward: to ensure that AI solutions are not only technically sound, but socially relevant and sustainable.

Today, Microsoft is announcing a new AI initiative to strengthen food security across Sub-Saharan Africa, starting in Kenya and designed to scale across the region. Across Global South communities, food security and sustainable agriculture are critical to resilience and progress. In collaboration with NASA Harvest, the government of Kenya, the East Africa Grain Council, UNDP AI Hub for Sustainable Development, and FAO, our AI for Good Lab will use AI on top of satellite data to provide critical, timely food security insights. This builds on what we’ve learned in helping to address rice farming challenges in India, where severe groundwater depletion prompted 150,000 farmers in Punjab to adopt water-saving methods. In collaboration with The Nature Conservancy, Microsoft’s AI for Good Lab developed a classification system with satellite imagery to empower policymakers to track adoption of sustainable rice farming practices, target interventions, and measure water management impacts at scale.

Through Project Gecko, Microsoft Research is also co-designing AI technologies with local communities in East Africa and South Asia to support agriculture. This work includes the Paza family of automatic speech recognition models that can operate on mobile devices across six Kenyan languages, multilingual Copilots, and a Multimodal Critical Thinking (MMCT) Agent that can reason over community-generated video, voice, and text. Microsoft also launched PazaBench—the first automatic speech recognition leaderboard, with initial coverage of 39 African languages—and developed two playbooks for multilingual and multicultural capabilities, Paza and Vibhasha. Likewise, our AI for Good Lab developed a reproducible pipeline for adapting open-weight large language models to low-resource languages, demonstrating measurable gains for languages such as Chichewa, Inuktitut, and Māori.

5. Measuring AI diffusion to guide future AI policies and investments

Finally, accelerating diffusion requires a firm understanding of where AI is being used, how it is being adopted, and where gaps persist. Building on our AI Diffusion Reports and Microsoft GitHub’s long track record of contributing to the OECD AI Policy Observatory, the WIPO Global Innovation Index, and other cross‑country analyses, we’re increasing our investments in research and data sharing to track AI diffusion.

We’re advancing new methods for sharing AI adoption metrics. For example, based on models used in public code repositories hosted on Microsoft GitHub and privacy-preserving aggregated usage signals from Azure Foundry, we’re scaling this work through contributions to the forthcoming Global AI Adoption Index developed by the World Bank.

Signals from the global developer community that builds, adapts, and deploys AI-enabled software round out adoption research. At 24 million, the Indian developer community is the second largest national community on GitHub, where developers learn about and collaborate with the world on AI. The Indian community is also the fastest growing among the top 30 largest economies, with growth at more than 26 percent each year since 2020 and a recent surge of over 36 percent in annual growth as of Q4 2025. Indian developers rank second globally in open-source contributions, second in GitHub Education users, and second in contributions to public generative AI projects, with readiness to use tools like GitHub Copilot across academic, enterprise, and public interest settings enabling AI diffusion.

Insights from this evidence base help inform investments in infrastructure, language capabilities, skilling, or beyond, supporting more targeted and effective interventions to expand AI’s benefits. They also create a common empirical baseline to track progress over time—so AI diffusion becomes something we can measure and shape, not just observe.

Sustaining impact at scale through coordinated global action

For AI to diffuse broadly and deliver meaningful impact across regions, several conditions matter. As a company, we are focused on the need for accessible AI infrastructure, systems that work reliably in real-world contexts, and technologies that can be applied toward local challenges and opportunities. Microsoft is committed to working with partners to advance this work, including sharing data to track progress.

The post We need to act with urgency to address the growing AI divide appeared first on Microsoft On the Issues.

We discuss widespread exploitation of Ivanti EPMM zero-day vulns CVE-2026-1281 and CVE-2026-1340. Attackers are deploying web shells and backdoors.

The post Critical Vulnerabilities in Ivanti EPMM Exploited appeared first on Unit 42.

This article explains why Chrome’s “preloading” feature can cause scary-looking blocks in Malwarebytes Browser Guard and how to turn it off.

Modern browsers want to provide content instantly. To do that, Chrome includes a feature called page preloading. When this is enabled, Chrome doesn’t just wait for you to click a link. It guesses what you’re likely to click next and starts loading those pages in the background—before you decide whether to visit them.

That guesswork happens in several places. When you type a search into the address bar, Chrome may start preloading one or more of the top search results so that, if you click them, they open almost immediately. It can also preload pages that are linked from the site you’re currently on, based on Google’s prediction that they’re “likely next steps.” All of this happens quietly, without any extra tabs opening, and often without any obvious sign that more pages are being fetched.​

From a performance point of view, that’s clever. From a privacy and security point of view, it’s more complicated.

Those preloaded pages can run code, drop cookies, and contact servers, even if you never actually visit them in the traditional sense. In other words, your browser can talk to a site you didn’t consciously choose to open.​

Malwarebytes Browser Guard inspects web traffic and blocks connections to domains it considers malicious or suspicious. So, if Chrome decides to preload a search result that leads to a site on our blocklist, Browser Guard will still do its job and stop that background connection. The result can be confusing: You see a warning page (called a block page) for a site you don’t recognize and are sure you never clicked.

Nothing unusual is happening there, and it does not mean your browser is “clicking links by itself.” It simply means Chrome’s preloading feature made a behind-the-scenes request, and Browser Guard intercepted it as designed. Other privacy tools take a similar approach. Some popular content blockers disable preloading by default because it leaks more data and can contact unwanted sites.

For now, the simplest way to stop these unexpected block pages is to turn off preloading in Chrome’s settings, which prevents those speculative background requests.

How to manage Chrome’s preloading setting

We recommend turning off page preloading in Chrome to protect your browsing privacy and to stop seeing unexpected block pages when searching the web. If you don’t want to turn off page preloading, you can try using a different browser and repeating your search.

To turn off page preloading:

1. In your browser search bar, enter: chrome://settings
2. In the left sidebar, click Performance.
3. Scroll down to Speed, then toggle Preload pages off.

We don’t just report on data privacy—we help you remove your personal information

Cybersecurity risks should never spread beyond a headline. With Malwarebytes Personal Data Remover, you can scan to find out which sites are exposing your personal information, and then delete that sensitive data from the internet.

Security operations are entering a pivotal moment: the operating model that grew around network logs and phishing emails is now buckling under tool sprawl, manual triage, and threat actors that outpace defender capacity. New research from Microsoft and Omdia shows just how heavy the burden can be—security operations centers (SOCs) juggle double-digit consoles, teams manually ingest data several times a week, and nearly half of all alerts go uninvestigated. The result is a growing gap between cyberattacker speed and defender capacity. Read State of the SOC—Unify Now or Pay Later to learn how hidden operational pressures impact resilience—compelling evidence to why unification, automation, and AI-powered workflows are quickly becoming non-negotiables for modern SOC performance.

The forces pushing modern SOC operations to a breaking point

The report surfaces five specific operational pressures shaping the modern SOC—spanning fragmentation, manual toil, signal overload, business-level risk exposure, and detection bias. Separately, each data point is striking. But taken together, they reveal a more consequential reality: analysts spend their time stitching context across consoles and working through endless queues, while real cyberattacks move in parallel. When investigations stall and alerts go untriaged, missed signals don’t just hurt metrics—they create the conditions for preventable compromises. Let’s take a closer look at each of the five issues:

1. Fragmentation

Fragmented tools and disconnected data force analysts to pivot across an average of 10.9 consoles¹ and manually reconstruct context, slowing investigations and increasing the likelihood of missed signals. These gaps compound when only about 59% of tools push data to the security information and event management (SIEM), leaving most SOCs manually ingesting data and operating with incomplete visibility.

2. Manual toil

Manual, repetitive data work consumes an outsized share of analyst capacity, with 66% of SOCs losing 20% of their week to aggregation and correlation—an operational drain that delays investigations, suppresses threat hunting, and weakens the SOC’s ability to reduce real risk.

3. Security signal overload

Surging alert volumes bury analysts in noise with an estimated 46% of alerts proving false positives and 42% going uninvestigated, overwhelming capacity, driving fatigue, and increasing the likelihood real cyberthreats slip through unnoticed.

4. Operational gaps

Operational gaps are directly translating into business disrupting incidents, with 91% of security leaders reporting serious events and more than half experiencing five or more in the past year—exposing organizations to financial loss, downtime, and reputational damage.

5. Detection bias

Detection bias keeps SOCs focused on tuning alerts for familiar cyberthreats—52% of positive alerts map to known vulnerabilities—leaving dangerous blind spots for emerging tactics, techniques, and procedures (TTPs). This reactive posture slows proactive threat hunting and weakens readiness for novel attacks even as 75% of security leaders worry the SOC is losing pace with new cyberthreats.

Read the full report for the deeper story, including chief information security officer (CISO)-level takeaways, expanded data, and the complete analysis behind each operational pressure, as well as insights that can help security professionals strengthen their strategy and improve real world SOC outcomes.

What CISOs can do now to strengthen resilience

Security leaders have a clear path to easing today’s operational strain: unify the environment, automate what slows teams down, and elevate identity and endpoint as a single control plane. The shift is already underway as forward-leaning organizations focus on high-impact wins—automating routine lookups, reducing noise, streamlining triage, and eliminating the fragmentation and manual toil that drain analyst capacity. Identity remains the most critical failure point, and leaders increasingly view unified identity to endpoint protection as foundational to reducing exposure and restoring defender agility. And as environments unify, the strength of the underlying graph and data lake becomes essential for connecting signals at scale and accelerating every defender workflow.

As AI matures, leaders are also looking for governable, customizable approaches—not black box automation. They want AI agents they can shape to their environment, integrate deeply with their SIEM, and extend across cloud, identity, and on-premises signals. This mindset reflects a broader operational shift: modern key performance indicators (KPIs) will improve only when tools, workflows, and investigations are unified, and automation frees analysts for higher value work.

The report details a roadmap for CISOs that emphasizes unifying signals, embedding AI into core workflows, and strengthening identity as the primary control point for reducing risk. It shows how leaders can turn operational friction into strategic momentum by consolidating tools, automating routine investigation steps, elevating analysts to higher value work, and preparing their SOCs for a future defined by integrated visibility, adaptive defenses, and AI-assisted decision making.

Chart your path forward

The pressures facing today’s SOCs are real, but the path forward is increasingly clear. As this report shows, organizations that take these steps aren’t just reducing operational friction—they’re building a stronger foundation for rapid detection, decisive response, and long-term readiness. Read State of the SOC—Unify Now or Pay Later for deeper guidance, expanded findings, and a phased roadmap that can help security professionals chart the next era of their SOC evolution.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹The study, commissioned by Microsoft, was conducted by Omdia from June 25, 2025, to July 23, 2025. Survey respondents (N=300) included security professionals responsible for SOC operations at mid-market and enterprise organizations (more than 750 employees) across the United States, United Kingdom, and Australia and New Zealand. All statistics included in this post are from the study.

The post Unify now or pay later: New research exposes the operational cost of a fragmented SOC appeared first on Microsoft Security Blog.

Key Points

• Check Point Research (CPR) has discovered that certain AI assistants that support web browsing or URL fetching can be abused as covert command-and-control relays (“AI as a proxy”), allowing attacker traffic to blend seamlessly into legitimate, commonly permitted enterprise communications.
• This technique was demonstrated against platforms such as Grok and Microsoft Copilot, leveraging anonymous web access combined with browsing and summarization prompts
• The same mechanism can also enable AI-assisted malware operations, including generating reconnaissance workflows, scripting attacker actions, and dynamically deciding “what to do next” during an intrusion.
• CPR outlines a near-term evolution in malware development, where implants shift from static logic to prompt-driven, adaptive behavior that can autonomously plan operations, prioritize targets and data, and adjust tactics in real-time based on environmental feedback.

Introduction

AI is rapidly becoming embedded in day-to-day enterprise workflows, inside browsers, collaboration suites, and developer tooling. As a result, AI service domains increasingly blend into normal corporate traffic, often allowed by default and rarely treated as sensitive egress. Threat actors are already capitalizing on this shift. Across the malware ecosystem, AI is being used to accelerate development and operations: generating and refining code, drafting phishing content, translating lures, producing PowerShell snippets, summarizing stolen data, assisting operators with next decisions during an intrusion, and, in extreme cases, developing full C2 frameworks such as Voidlink. The practical outcome is simple: AI reduces cost and time-to-scale, and helps less-skilled actors execute more complex playbooks.

But the next step is more consequential: AI isn’t only helping attackers write malware, it can become part of the malware’s runtime. In AI-Driven malware, the implant’s behavior is shaped dynamically by model output. Instead of relying solely on hardcoded decision trees, an implant can collect host context such as environment artifacts, user role indicators, installed software, domain membership, and geography, and use a model to triage victims, choose actions, prioritize data, and adapt tactics. This prompt-driven approach can make campaigns more flexible and harder to predict, especially as it shifts decision-making away from static code and toward external reasoning.In this research, Check Point Research demonstrates a concrete building block that connects these trends: AI assistants with web-browsing and URL-fetch capabilities can be abused as covert command-and-control relays, effectively using AI as a C2 proxy. We show how Grok and Microsoft Copilot can be driven through their web interfaces to fetch attacker-controlled URLs and return responses, creating a bidirectional channel that tunnels victim data out and commands back in. Crucially, this can work without an API key or a registered account, reducing the effectiveness of traditional kill switches such as key revocation or account suspension.

We then connect the technique to the broader trajectory: once AI services can be used as a stealthy transport layer, the same interface can also carry prompts and model outputs that act as an external decision engine, a stepping stone toward AI-Driven implants and AIOps-style C2 that automate triage, targeting, and operational choices in real time.

AI-Driven (AID) Malware

AI-Driven malware is malware that uses an AI model as part of its runtime decision loop, not just during development. Instead of executing a fixed, preprogrammed flow, the implant collects local signals from the infected host and uses a model to interpret them and decide what to do next. In practice, the model output can influence which capabilities are activated, which targets or data are prioritized, how aggressive the malware should be, and whether the host is worth continuing to operate on. This shifts part of the malware’s logic from static code into model-driven, context-aware behavior, which can make campaigns more adaptive and less predictable than traditional rule-based decision trees.

A useful way to think about AID malware is that the model becomes an external or internal decision engine. The implant provides a compact “situation report” (environment artifacts, user and domain context, installed software, file and process metadata, observed security controls, and other host indicators) and receives back guidance that can shape subsequent execution. Over time, this enables behavior that is more tailored per-host, can change across infections without code changes, and can reduce repeatable patterns that defenders often rely on for signatures and sandbox detonation.

There are two primary integration approaches:

1. API-based integration

• The malware interacts with a remote model or agent through an API. That model can be hosted by a mainstream provider, a niche platform, or attacker-controlled infrastructure running an agent. This approach is operationally flexible and keeps the implant lightweight, but it introduces network dependencies and creates telemetry that defenders may be able to hunt for. It can also create a potential kill switch if the workflow depends on revocable credentials, unless the actor can blend or relay the traffic through intermediate layers.

2. Embedded model

• The model is packaged locally, either inside the binary or as a bundled component. This removes the need for external inference calls and can reduce network exposure, but it increases payload size and resource requirements, and makes model updates harder. In real-world terms, embedded approaches trade operational convenience for stealth and independence from external services.

AI Agent As A C2 Proxy

Abusing legitimate services for C2 is not new. We’ve seen it with Gmail, Dropbox, Notion, and many others. The usual downside for attackers is how easily these channels can be shut down: block the account, revoke the API key, suspend the tenant. Directly interacting with an AI agent through a web page changes this. There is no API key to revoke, and if anonymous usage is allowed, there may not even be an account to block.

Our proposed attack scenario is quite simple: an attacker infects a machine and installs a piece of malware. Then the malware communicates directly with either Grok or Copilot through the web interface, sending a prompt that causes the AI agent to issue an HTTP(S) request to an attacker-controlled URL, retrieve content from that site, and return the attacker’s response via the AI output back to the malware.

Web App PoC

To test if our attack scenario is possible, we have set up two basic requirements:

• No authentication requirement: zero restrictions on the request, no account, no API key.
• Arbitrary web fetch with data in and out: the AI must be able to fetch a website we control, carry data in query parameters, and return content from that site in its response.

We found two AI providers that meet these requirements: Grok and Copilot. There were some minor restrictions, such as not being able to send data to direct IPs or plain HTTP, so we set up a fake HTTPS website to serve as our C2 server. We registered a domain, deployed a simple site, and in the spirit of things, let AI help us generate the entire thing.

The result is a Siamese cat fan club website. One of the pages is a “breed comparison” page. For example, we can ask Copilot at https://copilot.microsoft.com to summarize that page; no account is needed. The same applies to Grok at https://grok.com.

Now, in a real attack scenario, we would want to send data to the C2 (for example, the result of system reconnaissance on the infected machine) and receive data back (a command or at least an acknowledgment). That’s easy: we append the data, in some structured format, to the URL’s query parameters. There do appear to be safeguards: if we make it too obvious that we’re sending clearly malicious or sensitive data, some services try to block or sanitize it. However, simply encrypting or encoding the data in a high-entropy blob is enough to bypass these checks.

On the server side, we set up a breed comparison table, comparing different cat breeds. But one can’t really compare a cat breed without knowing what the cat breed’s “favorite Windows command to execute” is. For “stealth”, we made the page only display this command column when the my_breed_data URL parameter is present. We instruct the AI to visit the page and “return the cat’s favorite Windows command” based on a pattern embedded in the HTML.

As shown in the image, both Grok and Copilot gladly followed up on our prompt, fetched our site, and returned a response containing the command we planted. Of course, in a real attack, this command (or the whole payload) could be further encoded or encrypted to avoid triggering any model-side safeguards.

This demonstrates the feasibility of implementing the behavior end-to-end in a browser with no logged-in user. The next question is: how would actual malware do this from software, without relying on a visible browser window or any human interaction?

WebView Instead of API

Confirming that the technique works in a regular browser is one thing. Making it usable from malware is another. For our PoC, we set ourselves a constraint: get it working in C++, without relying on a direct API key or random HTTP requests to the AI provider’s website. Sending raw HTTP requests that don’t look like a normal browser session is more likely to hit rate limits, CAPTCHA, or behavioral checks. Instead, we decided to emulate a browser from within our C++ program.

For that, we used WebView2, an embedded browser component that lets native Windows apps display and interact with web content. The WebView2 runtime is preinstalled on all Windows 11 systems and has been broadly rolled out to modern Windows 10 versions via updates. Even if it’s missing, an attacker could bundle it with the malware or download it on first run.

Using WebView, we created a quick PoC: a C++ program that opens a WebView pointing to either Grok or Copilot. From there, we have two slightly different flows:

• Grok: Once the page is loaded, we can inject our prompt directly into the q parameter in the URL, and Grok will automatically follow our prompt without any further steps.
• Copilot: the flow is a bit trickier and uses JavaScript inside the loaded page to submit the prompt to the Copilot UI.

Either way, it works. Our program does the following:

1. Enumerate some basic information about the machine.
2. Append it to the URL of our fake Siamese cat C2 site
3. Open a (hidden) WebView window to the AI provider’s website.
4. Ask the AI to fetch and “summarize” that URL.
5. Parse the AI’s response and act on the embedded command.

WebView is just one example of how to do this in C++. Other platforms and languages have similar embedded browser controls that can achieve the same goal.

The PoC we created is intentionally simple, but it can easily be extended to behave more like real-world malware. In a full implementation, the implant could first send host enumeration data and register itself with the C2 server. The C2 server could then instruct the backdoor to sleep, collect additional information, check in at a later time, download further payloads, or execute arbitrary commands. None of this would be difficult to achieve once we have demonstrated that a bidirectional communication channel between malware and a C2 server can be established through an AI agent. Once the PoC was functional, we responsibly disclosed these findings to the Microsoft security team and the xAI security team.

Many More Possibilities

This technique is one example of how a threat actor can abuse an AI web app by using it as a proxy for C2, but it is far from the only option. The same interface could be used to request AI-generated commands to locate files, enumerate the system, search for sensitive data, or generate PowerShell code to move laterally across the network. Instead of relying on a skilled human operator, malware could directly task an AI agent for what to do next.

Beyond direct command generation, an attacker could also rely on AI to handle decision-making logic that is usually embedded in the malware itself. For example, an implant might send a short description of the host (domain, user role, installed software, geography) and ask the AI whether this system is worth further exploitation, which tools to deploy next, or how aggressively to move laterally without raising suspicion. The agent’s response would then shape the rest of the campaign, effectively turning the AI into a remote “brain” for the malware.

In the rest of this article, we focus on broader AI-Driven (AID) malware concepts and how future campaigns may integrate AI into their decision-making and operations. Our goal is not just to highlight one clever C2 trick, but to show how the same building blocks, web-accessible AI agents, and flexible prompts evolve into full AI-assisted attack workflows.

(Near)-Future AI-Driven Malware

While current AI-Driven (AID) threats have not yet been utilized in an optimal way, the practical impact of AID malware or AI-assisted attacks remains limited, largely experimental, inconsistent, or easily replicable using traditional decision-tree logic.

However, we can identify at least one major area where AI could become pivotal in the future: data analysis and infection targeting. AI has the potential to dramatically accelerate the identification of valuable data within compromised systems, the prioritization of targets, and the optimization of infection spread. By automating reconnaissance and decision-making steps that currently require human effort, AI could enable attackers to execute campaigns much faster and with greater precision. This capability, when it matures, could mark a significant turning point in how cyberattacks are conducted, shifting the balance between speed, accuracy, and scale in favor of malicious operators.

The three future AI use cases mentioned below represent the scenarios we believe will genuinely advance threat actors’ capabilities. At the core of these developments lies one central concept: data analysis and infection targeting.

As some of these techniques may already be implemented, we assess that in the near future, the methods described below will be expanded upon and widely adopted by threat actors, particularly those capable of leveraging advanced AI-driven capabilities.

AID – Anti-Sandbox Technique

The majority of modern malware families are designed to collect detailed system information from infected machines. This typically includes data such as the username, domain name, computer name, installed software, running processes, startup programs, and other environment details. Such reconnaissance allows the malware to better understand its execution context, whether it’s operating within a corporate network, a sandbox, or a personal device, and to adjust its behavior accordingly.

A potential future scenario involves a Remote Access Trojan (RAT), infostealer, Loader, or similar type of malware leveraging an AI model or API as part of its operational logic. In this case, the malware could utilize a predefined prompt combined with system data it has already collected and send this information to an AI service. The AI agent would then analyze the data and determine the likelihood that the environment is a real target or a sandbox used for malware analysis.

This method could function as an advanced AI anti-sandbox and environment validation technique. Instead of relying solely on hardcoded checks or local heuristics, the malware could offload the decision-making process to a remote AI system. If the AI’s response indicated “no sandbox detected,” the malware could proceed to execute its full capabilities, including data exfiltration, persistence installation, and communication with its C&C.

If malware begins to outsource environment verification to AI services, detecting and attributing infections will become significantly harder. An AI-Driven validation step can cause sandboxes and automated analysis tools to fail to trigger malicious behavior, because the payload may remain dormant until a remote model confirms the host is a “real” target. As a result, traditional signature- and sandbox-based detection pipelines may produce fewer observable indicators, while telemetry that would normally reveal malicious activity may never appear in analyst environments. This reduces the visibility defenders rely on and increases the chance that sophisticated campaigns slip through initial analysis windows.

AID – Command and Control Servers

While communicating with an AI API endpoint or embedding a model locally can generate noisy telemetry, a more subtle application of AI could occur at the Command and Control. C&C servers could use AI to automatically identify and categorize compromised hosts. For example, an AI-Driven triage step might discard obvious sandboxes and withhold second-stage payloads from those hosts.

Beyond sandbox detection, AI applied at the C&C could score victims based on available PII. This enables prioritization of follow-on actions and lateral movement. Once AI determines that an infection is a high-value target (such as corporate accounts or servers), the bot will receive different commands from the C&C, and distinct workflows will be applied to this infection, including a notification to prioritize the “manual” lateral movement. In the other case, the C&C might deploy a simple miner to a low-value victim, as further actions might not be of interest to the threat actor.

Another potential implementation would mirror the concept of MCP servers, but instead of integrating various red-teaming tools, the attacker could connect an existing malware family directly to an MCP server.

AID – Ransomware, Wipers & Data Exfiltration

The same concept used to identify valuable users or high-value targets can also be applied to files. An AI model could score which files are worth encrypting or exfiltrating based on metadata (file names, sizes, creation and modification timestamps, paths, …), as well as their content. By prioritizing high-value files, an attacker can accelerate encryption or data theft while generating far fewer I/O events, thereby reducing the likelihood of triggering volume-based alarms and increasing the chances of ignoring decoy or bait files.

Many ransomware detection workflows in XDRs rely on volume or rate thresholds and therefore only declare malicious activity after a sizable number of files have been encrypted. If an attacker limits activity to a much smaller, carefully chosen pool of files, this can undermine those heuristics and create detection gaps.

In a notable 2022 analysis, Splunk researcher Shannon Davis measured the time it takes several prominent ransomware families to encrypt large volumes of data, reporting times that ranged from a couple of minutes for the fastest families to several hours for slower ones. These experiments showed that some ransomware variants can encrypt ~100 GB in a matter of minutes.

The worrying question for AI-Driven ransomware is straightforward: What if an attacker does not need to encrypt 100 GB to achieve their objective? If an AID payload can prioritize and target only a small set of high-value files (for example, critical databases, business documents, or encryption keys) using model-driven scoring, the time to accomplish effective damage could be dramatically less than the bulk-encryption numbers. In other words, targeted encrypt-and-extort campaigns could succeed in seconds or minutes while generating far fewer observable file-I/O events. The same dynamics apply to data exfiltration, where ransomware groups frequently steal sensitive data and then publish it on their onion sites or leak it on their leak blogs.

Advanced persistent threat (APT) actors customize their malware and prompts to fit the target’s profile, infrastructure, and the value of the data they expect to find. For example, attackers focused on defense contractors, research labs, or critical infrastructure operators will prioritize reconnaissance and payloads that can discover, collect, and exfiltrate technical schematics, classified reports, or proprietary designs. Ignoring unwanted documents that could potentially cause high-volume data exfiltration.

AID wipers may target specific files instead of everything to take down a specific machine. Or wipers may avoid taking down the machine and instead target specific programs, making various processes unusable.

(Near)-Future AI-Driven Campaigns

While we previously discussed how AI-Driven (AID) malware could eventually find its optimal use cases, this section outlines how such implementations may realistically occur. Although AID Embedded-Model malware offers superior stealth, as no input or output is observable by external AI providers (such as OpenAI, Anthropic, and Gemini), we believe that AID API-Based implementations will likely be preferred. This is primarily due to practicality, embedding or bundling a model significantly increases the binary size, which usually goes against the common preference for lightweight payloads. Currently, there is a growing number of AI platforms advertising malicious capabilities, such as FraudGPT, EvilAI, MalwareGPT, etc., which could theoretically be used to power API-based AID malware. However, from a defensive standpoint, these connections are relatively easy to detect just by blacklisting known malicious domains. For an AID API-based approach to achieve real stealth, threat actors would need to employ AI proxy servers to relay requests to these malicious AI platforms. This setup would conceal direct communication with the malicious AI service, making network detection challenging. Alternatively, attackers could host their own local AI model on a remote server. In that case, the server would operate more like an AIOps Command and Control Server (AIOps-C&C) rather than a mere proxy, enabling AI-assisted decision-making and automation while keeping communication hidden within the attacker’s infrastructure.

Conclusion

AI assistants are no longer just productivity tools; they are becoming part of the infrastructure that malware can abuse. In this research, we showed how Grok and Microsoft Copilot can be driven through their web interfaces and abused as covert C2 relays, without any API keys or user accounts. By combining a simple “C2 website” with a WebView2-based C++ implant, we demonstrated a full end-to-end path in which victim data flows out via URL query parameters, and attacker commands flow back in through AI-generated responses.

More importantly, this is not a one-off trick. Any AI service that exposes web fetch or browsing capabilities, especially to anonymous users, inherits a similar level of abuse potential. Today, that may look like a creative way to hide C2 in “normal” AI traffic. Tomorrow, the same pattern can evolve into fully AI-Driven malware and AIOps-style C2, where models help decide which hosts to keep, which files to steal or encrypt, and when to stay dormant to avoid sandboxes and detection.

This is a service-abuse class of issue, not a traditional memory corruption bug. Mitigations, therefore, require changes on both sides. AI providers need to harden web-fetch features, enforce authentication, and give enterprises greater control and visibility into how their models access external URLs. Defenders need to start treating AI domains as high-value egress points, monitor for automated and unusual usage patterns, and incorporate AI traffic into their hunting and incident response playbooks.

As AI continues to integrate into everyday workflows, it will also integrate into attacker workflows. Understanding how these systems can be misused today is the first step toward hardening them for the future, and ensuring that AI remains more useful to defenders than to the malware that tries to hide behind it.

The post AI in the Middle: Turning Web-Based AI Services into C2 Proxies & The Future Of AI Driven Attacks appeared first on Check Point Research.

Scams aren’t so obvious anymore. They’re well-written, have working grammar, and can lead victims to very convincing branded webpages. Scammers increasingly use AI tools to clone sites and create highly sophisticated scams at scale, so don’t expect to rely on spotting obvious typos anymore.

That’s why Scam Guard, Malwarebytes’ free, AI-powered scam detection assistant, is now available on Windows and Mac. Previously mobile-only, Scam Guard helps you quickly figure out whether something you’re looking at is risky, all before you click, reply, or share. 

When something feels off but you’re not sure what

Scams show up everywhere: emails, texts, pop-ups, messages, and websites that look legitimate. But when you’re moving fast, it’s easy to slip up. 

Scam Guard is designed for exactly those moments. If you’re unsure about a message or link, you can ask Scam Guard to take a look. It uses AI to analyze the content and give you a clear, fast assessment so you can decide what to do next with more confidence. 

How Scam Guard helps 

Scam Guard provides a quick reality check just when you need it: 

• Real-time threat intelligence: An AI-powered chat companion backed by decades of Malwarebytes threat intelligence and cybersecurity expertise. Get instant verdicts you can trust, plus clear next steps.
• Comprehensive scam detection: It flags suspicious messages and links, spots common scam tactics, and explains why something is risky. It covers romance, phishing, financial, text, robocall, and shipping scams, and more.
• Built for where scams start: Works right on your desktop, where many scams begin.
• 24/7 support: Available around the clock, so you can get help anytime you need it.

Stop wondering to yourself “Is this legit?” With Scam Guard, you get an answer you can trust.  

Now on desktop, right where scams happen 

Many scams target users while they’re on their computers—checking email, browsing the web, or managing accounts. Bringing Scam Guard to Windows and Mac helps where it’s most useful. 

Whether you’re reviewing an unexpected message, a pop-up that feels urgent, or a deal that sounds a little too good, Scam Guard gives you a smarter way to pause and check before reacting.  Here’s how to share a scam with Scam Guard on your computer.

Extra protection, without extra stress 

Staying safe online shouldn’t mean becoming suspicious of everything. It should mean having the right tools when something doesn’t add up. Scam Guard is there to help you slow down, spot warning signs, and avoid costly mistakes. It makes it easier to protect yourself from scams.

We don’t just report on scams—we help detect them

Cybersecurity risks should never spread beyond a headline. If something looks dodgy to you, check if it’s a scam using Malwarebytes Scam Guard. Submit a screenshot, paste suspicious content, or share a link, text or phone number, and we’ll tell you if it’s a scam or legit. Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.

Traditional Security Is Blind to the Agentic Endpoint

Modern endpoints are no longer defined only by executables. Increasingly, endpoint behavior is shaped by non-binary software, such as code packages, browser extensions, IDE plugins, scripts, local servers (including MCP), containers and model artifacts. They are installed directly by employees and developers without centralized oversight. Because these components are not classic binaries, they often fall outside the visibility and control of traditional endpoint security tooling.

AI agents compound this problem. They are legitimate tools that operate with the user’s credentials and permissions, enabling them to read, write, move data and take privileged actions across systems. When compromised or misused, agents become the “ultimate insider.” They can autonomously discover, invoke and even install additional components at machine speed, accelerating risk across an already expanding, largely unmanaged software layer.

Weaponizing Trusted Automation

This is not a future concern. The recent viral emergence of OpenClaw serves as a cautionary tale for the agentic era. Developed by a single individual in just one week, it rapidly secured millions of downloads while gaining broad permissions across users' emails, filesystems and shells. Within days, researchers identified 135,000 exposed instances and more than 800 malicious skills in its marketplace, underscoring how a single unvetted agent can create an immediate, global attack surface.

OpenClaw is not an outlier. Recent research highlights how quickly this risk is materializing:

• Vibe Coding Threats: An AI extension in VS Code was found leaking code from 1.5 million developers. This tool could read any open file and send it back to the developer, collect mass files without user interaction, and track users with commercial analytics SDKs.
• Malicious MCP Server: Koi documented the first malicious Model Context Protocol (MCP) server in the wild. When developers added a specific skill to tools like Claude Code or Cursor, it silently forwarded every email to the plugin creator. What’s more, this capability was added later, after developers had already started using it.

Compounding this risk is the fact that autonomous agent actions are often difficult to trace or reconstruct, leaving Security Operations Centers (SOCs) without the visibility they need when an incident occurs.

A New Category of Protection

Complete endpoint security for the rapidly expanding risk of agentic AI calls for a new category of protection: Agentic Endpoint Security. That’s why we announced our intent to acquire Koi, a pioneer in this space. Koi is designed to eliminate blind spots across the AI-native ecosystem and help organizations govern agentic tools safely.

Its technology rests on three core pillars:

1. See All AI Software – Gain complete visibility into the AI tools, agents and non-binary software running in your environment.
2. Understand Risks – Continuously analyze and understand the intent and risk level of all software and AI agents.
3. Control the AI Ecosystem – Enforce policy in real-time to remediate issues and block risky behaviors.

Securing the Agentic Enterprise

We are convinced that Agentic Endpoint Security will soon become a standard requirement for enterprise security. Upon closing the proposed acquisition, we intend to integrate Koi’s capabilities across our platforms to help our customers secure the AI-native workspace.

The wave of AI agents approaching the enterprise cannot be held back. Instead, we must offer secure tools that enable companies to confidently embrace agentic innovation.

Forward-Looking Statements

This blog post contains forward-looking statements that involve risks, uncertainties, and assumptions, including, but not limited to, statements regarding the anticipated benefits and impact of the proposed acquisition of Koi on Palo Alto Networks, Koi and their customers. There are a significant number of factors that could cause actual results to differ materially from statements made in this blog post, including, but not limited to: the effect of the announcement of the proposed acquisition on the parties’ commercial relationships and workforce; the ability to satisfy the conditions to the closing of the acquisition, including the receipt of required regulatory approvals; the ability to consummate the proposed acquisition on a timely basis or at all; significant and/or unanticipated difficulties, liabilities or expenditures relating to proposed transaction, risks related to disruption of management time from ongoing business operations due to the proposed acquisition and the ongoing integration of other recent acquisitions; our ability to effectively operate Koi’s operations and business following the closing, integrate Koi’s business and products into our products following the closing, and realize the anticipated synergies in the transaction in a timely manner or at all; changes in the fair value of our contingent consideration liability associated with acquisitions; developments and changes in general market, political, economic and business conditions; failure of our platformization product offerings; risks associated with managing our growth; risks associated with new product, subscription and support offerings; shifts in priorities or delays in the development or release of new product or subscription or other offerings or the failure to timely develop and achieve market acceptance of new products and subscriptions, as well as existing products, subscriptions and support offerings; failure of our product offerings or business strategies in general; defects, errors, or vulnerabilities in our products, subscriptions or support offerings; our customers’ purchasing decisions and the length of sales cycles; our ability to attract and retain new customers; developments and changes in general market, political, economic, and business conditions; our competition; our ability to acquire and integrate other companies, products, or technologies in a successful manner; our debt repayment obligations; and our share repurchase program, which may not be fully consummated or enhance shareholder value, and any share repurchases which could affect the price of our common stock.

Additional risks and uncertainties that could affect our financial results are included under the captions "Risk Factors" and "Management's Discussion and Analysis of Financial Condition and Results of Operations" in our Quarterly Report on Form 10-Q filed with the SEC on November 20, 2025, which is available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. Additional information will also be set forth in other filings that we make with the SEC from time to time. All forward-looking statements in this blog post 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.

The post Securing the Agentic Endpoint appeared first on Palo Alto Networks Blog.

Google has issued a patch for a high‑severity Chrome zero‑day, tracked as CVE‑2026‑2441, a memory bug in how the browser handles certain font features that attackers are already exploiting.

CVE-2026-2441 has the questionable honor of being the first Chrome zero-day of 2026. Google considered it serious enough to issue a separate update of the stable channel for it, rather than wait for the next major release.

How to update Chrome

The latest version number is 145.0.7632.75/76 for Windows and macOS, and 145.0.7632.75 for Linux. So, if your Chrome is on version 145.0.7632.75 or later, it’s protected from these vulnerabilities.

The easiest way to update is to allow Chrome to update automatically. But you can end up lagging behind if you never close your browser or if something goes wrong, such as an extension preventing the update.

To update manually, click the More menu (three dots), then go to Settings > About Chrome. If an update is available, Chrome will start downloading it. Restart Chrome to complete the update, and you’ll be protected against these vulnerabilities.

You can also find step-by-step instructions in our guide to how to update Chrome on every operating system.

Technical details

Google confirms it has seen active exploitation but is not sharing who is being targeted, how often, or detailed indicators yet.

But we can derive some information from what we know.

The vulnerability is a use‑after‑free issue in Chrome’s CSS font feature handling (CSSFontFeatureValuesMap), which is part of how websites display and style text. More specifically: The root cause is an iterator invalidation bug. Chrome would loop over a set of font feature values while also changing that set, leaving the loop pointing at stale data until an attacker managed to turn that into code execution.

Use-after-free (UAF) is a type of software vulnerability where a program attempts to access a memory location after it has been freed. That can lead to crashes or, in some cases, lets an attacker run their own code.

The CVE-record says, “Use after free in CSS in Google Chrome prior to 145.0.7632.75 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.” (Chromium security severity: High)

This means an attacker would be able to create a special website, or other HTML content that would run code inside the Chrome browser’s sandbox.

Chrome’s sandbox is like a secure box around each website tab. Even if something inside the tab goes rogue, it should be confined and not able to tamper with the rest of your system. It limits what website code can touch in terms of files, devices, and other apps, so a browser bug ideally only gives an attacker a foothold in that restricted environment, not full control of the machine.

Running arbitrary code inside the sandbox is still dangerous because the attacker effectively “becomes” that browser tab. They can see and modify anything the tab can access. Even without escaping to the operating system, this is enough to steal accounts, plant backdoors in cloud services, or reroute sensitive traffic.

If chained with a vulnerability that allows a process to escape the sandbox, an attacker can move laterally, install malware, or encrypt files, as with any other full system compromise.

How to stay safe

To protect your device against attacks exploiting this vulnerability, you’re strongly advised to update as soon as possible. Here are some more tips to avoid becoming a victim, even before a zero-day is patched:

• Don’t click on unsolicited links in emails, messages, unknown websites, or on social media.
• Enable automatic updates and restart regularly. Many users leave browsers open for days, which delays protection even if the update is downloaded in the background.
• Use an up-to-date, real-time anti-malware solution which includes a web protection component.

Users of other Chromium-based browsers can expect to see a similar update.

We don’t just report on threats—we help safeguard your entire digital identity

Cybersecurity risks should never spread beyond a headline. Protect your, and your family’s, personal information by using identity protection.