Google said today it worked with industry partners to dismantle a botnet made up of more than 1.3 million Android TV set-top boxes that ship with malicious software which secretly rents the user’s Internet connection out to strangers and conducts advertising fraud. Experts involved in the takedown say the action is likely to sever the botnet’s access to more than 10 million additional compromised systems, including other Internet of Things (IoT) products such as Android-based healthcare devices and karaoke machines.

A report from the Google Threat Intelligence Group (GTIG) said Google has severed ties with Videostrong Technology Co., a TV box manufacturer in China that GTIG and other industry experts concluded was responsible for including malware that enrolled more than 1.3 million set-top boxes in a botnet dubbed “XCPE” (named after one of the malware’s core code components).

The global distribution of XCPE botnet infections. Image: Google Threat Intelligence Group.

The report said the XCPE botnet loaded the user’s device with software that makes their Internet address available for resale by multiple “residential proxy” services, which allow customers to rent Internet addresses as a way to anonymize their web traffic or spoof their true location. As detailed in several stories here over the past year, residential proxy services are a major source of unwanted and often malicious traffic, including account takeover activity, advertising fraud, and mass content scraping for AI projects.

“Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices,” the GTIG post reads, noting that Google took legal action to take down the domains and servers Videostrong used to control the botnet and install additional malware. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors.”

The report notes that while TV boxes made up the the majority of the botnet, the same XCPE malware was found in other Android-based IoT products, including telehealth devices, karaoke machines, and even digital signage systems.

Google said it requires all Android device makers to pass compatibility and security tests to ensure their products don’t harm users, but that Videostrong nevertheless found a way to load their malicious software immediately after a user boots up one of these devices for the first time (Google says it has since addressed that weakness).

The GTIG report calls out a number of residential proxy providers whose software development kits were routinely downloaded by devices infected by the XCPE botnet. Those include AppSalt, also known as Honeygain, which is owned by the Vilnius, Lithuania-based Oxylabs. In October 2026, Oxylabs was relaunched under a new brand called Source, after receiving $130 million in funding from private equity firm Warburg Pincus that reportedly valued the business at $3.6 billion. Oxylabs did not respond to a request for comment.

Another provider linked to the botnet was NetNut, a once sprawling residential proxy company operated by the publicly-traded Israeli company Alarum Technologies. In July 2026, the FBI worked with industry partners to seize hundreds of domains associated with NetNut, saying the company was responsible for operating a separate botnet called Popa that enslaved TV boxes as residential proxies. Other proxy providers named in the GTIG report include EarnFM, Traffmonetizer, Jaguar, LINKFOG, BMW/IPWeb and GaGaNode.

Google’s announcement credits a number of industry partners, including Synthient, a startup that tracks proxy providers. In January 2026, Synthient published research into the rapid spread of the Kimwolf botnet, which at the time was hammering networks worldwide with record-smashing DDoS attacks. Synthient documented how Kimwolf infected millions of Android set-top boxes virtually overnight, using a widespread vulnerability in these residential proxy services to compromise other Android-based devices inside the local networks of unsuspecting TV box users.

Synthient’s research caused dozens of residential proxy providers to patch their networks, which helped to fragment the Kimwolf botnet into much smaller pieces that made its incessant and disruptive DDoS attacks far easier for network operators to manage. It also attracted the attention of the Motion Picture Association (MPA), a trade group representing the major Hollywood studios, which partnered with Synthient to purchase and tear apart a number of popular Android TV set-top boxes — including some that were being infected by Kimwolf and other IoT botnets.

In a report published today, Synthient examined a popular, pre-infected TV box sold under the brand MECOOL by a publicly traded company in China called Skyworth Technology, concluding that MECOOL also bundled the malware from Videostrong Technology Co. and likewise installed AppSalt/Honeygain and other proxy components.

The MECOOL storefront and marketing. Image: Synthient.com.

Synthient founder Ben Brundage told KrebsOnSecurity that Videostrong’s malware also distributed software for the proxy service Grass. In our November 2025 story, “Is Your Android TV Streaming Box Part of a Botnet?” we quoted a researcher from Censys who found the popular Superbox TV streaming device bundled Grass’s residential proxy software. We also quoted the Grass founder, who denied any affiliation with the TV box maker.

That November 2025 story noted that Superbox and similar Android TV set-top boxes gain new customers primarily by engaging influencers on Tiktok and other social networks who praise the product’s ability to offer hundreds of (pirated) pay TV streaming services for a one-time fee.

Likewise, Synthient’s report observes that the MECOOL set-top boxes exploded in popularity after the product was mentioned in 2023 by the Youtube channel Linus Tech Tips, which has an audience of nearly 17 million subscribers [Linus Tech Tips said in a statement shared with Synthient that it has since updated the video to explicitly frame the product as a scam and have removed all associated affiliate links].

The popular Youtube channel Linus Tech Tips discussing MECOOL TV streaming boxes.

The GTIG report estimates the XCPE botnet takedown should sever access to at least 10 million additional compromised devices, noting that the various proxy and ad fraud affiliates of Videostrong “each have diversified distribution channels for their modules beyond XCPE.”

Synthient’s Brundage echoed that conclusion, calling the 1.3 million number “highly conservative.”

“The scale of affected devices is likely way higher,” he said. “This is probably the largest operation against backdoored TV boxes that we’ve seen.”

Further reading:
Plume Security Labs white paper on the XCPE botnet (PDF)
Black Lotus Labs writeup on LinkedIn
TrendAI’s analysis
Synthient’s list of affected devices, broken down by model number

Late October brought several unsettling cybersecurity stories all at once. Among these were two critical vulnerabilities in PHP, which potentially affected about 70% of websites worldwide. CVE-2026-109618 and CVE-2026-109619 — dubbed PHP2Shell — could let attackers execute code on a server remotely, without authentication.

On October 21, PHP’s developers released emergency patches for the supported PHP 8.2–8.5 branches and for the unsupported PHP 7.4, 8.0, and 8.1. Experts predicted that attacks on vulnerable servers would start within 15 minutes of the updates going public. Amazon even reported exploitation attempts four days before the patches came out. With all this in the news, some organizations sounded the alarm early. For example, in several countries, government service websites were taken offline as a precaution. Even Wikipedia’s project management and bug-tracking system suspended service.

Nearly two weeks have passed since the updates came out, but according to Censys data, of the 46 million scannable servers running a vulnerable PHP version, 29 million still contain the flaws. Right after the patches were published, we broke down each flaw in detail and explained what companies and everyday users should do. In this post we cover what’s known about the threat today, and what extra steps businesses need to take.

What happened after the PHP2Shell patches

The news about critical PHP vulnerabilities set off a flurry of reactions. Researchers noted a large number of exploitation attempts, and fresh exploits kept appearing in batches — courtesy of AI. A Palo Alto Networks unit even reported a PHP2Shell attack on a government agency in Europe, though it later retracted that statement. Solid evidence of how these vulnerabilities can actually be exploited only emerged later. On top of that, a third, unpatched one turned up.

A vulnerability with no patch

On Friday, October 23, the PHP team warned about a new vulnerability — CVE-2026-115560 — which can be used for remote code execution. But attackers can only pull this off on systems with an “unusual combination of configuration and application code”. That configuration is so exotic that the developers decided against an emergency patch, and will close the vulnerability on the regular schedule. In the meantime, they advised users to disable the session.upload_progress.enabled INI option.

First signs of PHP flaws being exploited

Let’s get back to the more serious threats. The most substantial confirmation of PHP2Shell exploitation in real-world attacks only came on October 24. Honeypot servers run by Adel Karimi of Perplexity running PHP 8.4.26 and presenting ordinary web pages recorded successful attacks from two IP addresses. The observed exploit chain was consistent with CVE-2026-109618. There’s an important caveat, though: the researcher’s honeypot ran the Apache mod_php module, which is the configuration most convenient for attackers.

Later, on October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. That confirmed the threat isn’t just theoretical.

Real-world breaches with PHP2Shell

On October 26, the technology company Dream reported that 25 firewalls and management servers had been compromised in the U.S., Japan, Taiwan, and South Korea. Three of them were in an environment presumed to be linked to U.S. government agencies. The attackers combined PHP2Shell with a Linux kernel vulnerability dubbed Fragnesia (CVE-2026-46300). Upon gaining full administrative control, they were able to extract the password of an LDAP service account and steal the listing of users and groups, full network configuration, and private keys.

Dream initially didn’t name the device vendor. In its October 29 update, though, the company stated that the systems were Palo Alto Networks devices running certain versions of PAN-OS. The vendor confirmed attacks on management interfaces exposed to the internet. It urged customers to close public access to those interfaces, limit it to trusted internal IP addresses, and install patches.

Why there are so few incidents

Exploits are multiplying, but no wave of breaches has materialized, and the possibility of mass compromise of PHP servers remains unconfirmed. Even in the Palo Alto case, the scale of the attack was minimal: out of about 19 000 devices found, the attackers picked just 240, which were running software versions their exploit could handle.

As it turns out, the existing PHP2Shell exploits aren’t one-size-fits-all. To exploit the vulnerabilities in a given environment, attackers have to account for the exact PHP build, memory settings, request handling, and application specifics. Still, the danger remains, so don’t neglect protective measures.

How to stay safe

The key advice stays the same: update. You can find the latest versions of the language on the PHP website. But installing patches isn’t enough. You also need to run a thorough audit of your systems and check every component that runs on PHP for signs of compromise.

Why install the second round of PHP updates?

Five days after releasing the emergency patches, the PHP developers published another round of fixes. The reason is that the updates that fixed PHP2Shell didn’t cover the CVE-2026-111497 vulnerability in Brotli, a third-party library. Exploiting this flaw can lead to code execution when PHP processes a specially crafted compressed response from an external server. The builds from October 25 include a patched version of the library. The latest PHP versions are 8.2.35-1, 8.3.36-1, 8.4.27-1, and 8.5.12-1. The first attack exploiting this vulnerability was recorded on October 26, so don’t put off installing the updates.

Threat detection

Possible signs of a PHP2Shell compromise include unusual POST requests that contain multipart/form-data media type, suspicious combinations of PHP_SESSION_UPLOAD_PROGRESS and upload parameters, atypical request sizes and request bursts, and HTTP 500 errors accompanied by PHP out-of-memory messages.

Kaspersky solutions can help you spot the threat at different stages of an attack.

• Kaspersky NEXT EDR Expert promptly alerts you to suspicious activity running in the context of Linux and Windows web servers.
• Kaspersky Anti Targeted Attack (KATA) with the NDR module check network traffic for exploitation of the flaws described above.
• Kaspersky Vulnerability Management helps you find vulnerable versions of software.
• Kaspersky Managed Detection and Response detects exploitation of CVE-2026-109618 and CVE-2026-109619 by monitoring for behavior characteristic of RCE attacks.
• Kaspersky SIEM has been updated with new rules that help detect malicious activity typical of PHP2Shell.

To learn more about how our solutions detect attempts to exploit PHP vulnerabilities, read our expert blog, Securelist.

The rapid diffusion of AI globally and the pace at which AI is developing put us at a societal crossroads. The choices we’re making now will determine who has access to AI and the opportunity it affords. There is perhaps no more important tool than our education systems for addressing the uneven diffusion of AI we’re seeing currently: national adoption runs above 70% in countries such as the United Arab Emirates and falls to low single digits across much of sub-Saharan Africa, close to a tenfold difference. 

The way we teach AI and learn with it will have long-lasting impacts on jobs, the workforce, and our broader economy. Learning Curves: Rethinking Education from Classrooms to Careers in an AI-Driven World is a collection of research-driven essays that can help guide those choices. This book brings together the body of work from the second cohort of Senior Fellows from the Microsoft AI Economy Institute (AIEI), a flagship think tank that produces research and convenes experts to generate insights into how AI is reshaping work, education, and the broader economy. 

In Learning Curves, researchers consider how AI is reshaping the earliest stages of learning and work, from K–12 classrooms and community and technical colleges to college‑to‑work transitions and entry‑level jobs, and what it will take for that transformation to widen opportunity rather than deepen divides across institutions, communities, and countries.  

Below, I share a few of my own reflections that informed my contributions to Learning Curves, a collaborative effort that wouldn’t have been possible without the truly talented, diverse cohort of researchers who contributed to this book.  

The good, the bad, and the ugly: Laying the foundation for AI in K–12 classrooms

Before delving into the specifics of how to incorporate AI in classrooms, we need to ask ourselves whether we’re teaching for knowledge, or for learning.  

The book, the calculator, the personal computer, the internet, the search engine, and the smartphone all arrived in classrooms carrying real promise alongside the worry that they would hollow out young minds. Usually the truth landed somewhere in between, and where it landed depended less on the tool than on the choices the adults made about how to use it. 

The fact is that the AI-native generation is already here, and its members are in classrooms around the world. More than half of US teenagers already use AI chatbots for schoolwork. I’ve personally seen the promise of AI as a force for good in education up close in my own classroom, where I teach a computer science class to elementary school students.  

But of course, the good is only part of the story. We can’t shy away from the downsides of incorporating AI into classrooms. While AI can help with accessibility and individualized learning, it can also create over–reliance, contribute to student cheating, or prevent students from recognizing when information may be false. 

The rapid deployment of AI in K–12 classrooms needs to come with a sober assessment of how that technology impacts all students. This assessment must go beyond the technology itself to encompass how students, teachers, parents, and society use AI.   

AI literacy is only part of the solution

If classrooms are where students learn how to think, teachers are the conduit through which this learning happens. In Learning Curves, Joseph Orero, Senior Researcher in AI at Strathmore University’s School of Computing and Engineering Science, posits that teachers aren’t resistant to AI in classrooms; they just need proper training to help them adequately adapt and teach their students critical skills. His research contribution explores game-based learning with AI-enabled African languages. 

AI usage and adoption worldwide are also dependent on accessibility. Another chapter of the book looks at barriers and opportunities in Arabic education and finds that the primary barrier teachers encountered when introducing AI writing assistants into classrooms was Arabic digital literacy, particularly students’ typing ability.  

Researchers often circled around a similar theme: there is no one-size-fits-all approach to developing AI competency; instead, such an approach must be sensitive to local knowledge and contextualized teaching and learning practices. This means that teachers, in turn, must have training that makes sense for the unique contexts in which their students are learning.  

Frank Nagle, now Microsoft’s Chief AI Economist, Sarah Rodriguez, Associate Professor of Engineering Education at Virginia Tech, and other researchers in Learning Curves make the case that, in many ways, nontraditional pathways such as apprenticeships and two-year-degree programs, particularly those that are virtual, are more nimble and thus better able to adapt their curricula to the rapidly changing field of AI.  

AI Is taught in the classroom, but then what?

Education has never been about simply preparing people for the future of work so they can thrive in the labor market. When considered holistically, it is about teaching students not what to think but how to think. In our AI era, education is one of the core institutions through which the future of work will be built, distributed, and made more (or less) equitable. Successful AI integration remains human-centered by focusing on organizational change, durable human skills like empathy and judgment, strong employer partnerships, and learner needs. 

As research from Laura Nuriski, Head of Program on the Future of Work at the Centre for European Policy Studies (CEPS), highlights, access to AI alone does not ensure successful integration. Technology transfer, data infrastructure, organizational readiness, and a human-centered approach to building and deploying AI are also key indicators of success.  

Whether we’re talking about the classroom or the boardroom, it’s worth keeping in mind that AI tends to do the most good when it strengthens human capability and the most harm when it substitutes for it. That holds as true in a fourth- grade reading lesson as in a software team or a hospital ward. 

The children in our schools deserve tools that serve their learning rather than stand in for it, and that is within our power to provide. Our most successful future with AI will be one that is human-centered, inclusive, and designed to help people thrive. 

The post Learning Curves: The future of education, from classrooms to careers, in an AI-driven world appeared first on Microsoft On the Issues.

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers — but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager — it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

• Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
• Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
• Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
• Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

• Trojan TV, or the new risks of malicious proxies
• Ransomware now taking aim at personal backups
• Is your TV box renting out your network?
• Is your router secretly working for foreign intelligence?
• Three common attacks on Linux in homes
• How to secure your smart home

Two critical vulnerabilities have been discovered in the popular PHP programming language. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute code on a server running PHP without authentication. The language’s development team has released updates for all supported branches, but the first attempts to exploit the vulnerabilities were observed even before the patches were published. The exploit has been named PHP2Shell.

The architectures of popular marketplaces, e-commerce platforms, and learning management systems (LMS) are written in PHP. In addition, PHP is used in various content management systems (CMS) such as WordPress, Drupal, Joomla, and so on, which power most websites on the internet.

In this blogpost, we discuss CVE-2026-109618 and CVE-2026-109619 in detail, and explain how companies can protect their infrastructure. Read the Securelist expert blog to learn how events surrounding these vulnerabilities unfolded before the patch was released.

Vulnerable PHP versions

According to PHP web site, versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable to CVE-2026-109618 and CVE-2026-109619. There are no official fixes for older branches. According to unofficial reports, the vulnerabilities also affect PHP versions starting with 5.4.0.

What makes CVE-2026-109618 and CVE-2026-109619 dangerous

Both vulnerabilities received a score of 9.2 on the CVSS v4.0 scale. They arise because, after a request is interrupted (for example, due to a memory shortage), PHP leaves invalid data in the memory buffer, and subsequently accesses it, allowing code to be executed on the server. One of the confirmed attack chains via CVE-2026-109619 exploits the `session.upload_progress` mechanism (which tracks file upload progress), which is enabled by default in PHP.

By exploiting these vulnerabilities, attackers can remotely execute code on the server with web server process privileges without authentication.

According to PHP developers, all installations of unpatched versions that process web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The greatest risk lies with mod_php: researchers demonstrated an exploit for it in which an unauthenticated request triggers the attack even before the application code is executed.

What businesses should do

We’ve compiled key recommendations from the PHP developers and experts at Kaspersky.

• Update PHP to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Start with systems accessible from the internet. The source code is available on the PHP website. If PHP is installed from distribution packages or provided by your hosting provider, check for updated packages: Linux distributions and LTS vendors received patches in advance. If the server is managed by a hosting provider, ask them to apply the update.
• Versions 8.1 and older no longer receive updates from the PHP project. Check with your distribution vendor or LTS support provider to see if backported fixes are available, or switch to a supported branch. For PHP 7.4, 8.0, and 8.1, the developers have prepared minimal source code backports for manual compilation. These can also be found on the PHP website.
• Restart PHP-FPM or the web server so that the processes load the new code, and verify the version using the `php -v` command. If PHP was installed from distribution packages, check the package changelog: the version number may remain the same.
• Check the logs from October 20. A warning sign is when the web server process is performing actions it shouldn’t (running command shells, curl, wget, and the like). Kaspersky solutions help detect malicious activity in a timely manner. Attempts to exploit the described RCE vulnerabilities on Linux and Windows machines can be detected using Kaspersky NEXT EDR Expert, while exploitation of PHP2Shell in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) with the NDR module.

If an immediate update is not possible

Only the immediate installation of patches will fully resolve the issue, but if that isn’t possible, it’s recommended to implement temporary measures. PHP developers provide step-by-step instructions for each vulnerability.

Authors: Yun Zheng Hu

Introduction

Today Fox-IT is publicly releasing its full Cobalt Strike Beacon Corpus, containing 56,843 raw beacons and their parsed configurations, from 190,182 sightings collected from 30,604 unique IP addresses running a Team Server (the Cobalt Strike command-and-control server that beacons connect back to) between 4 July 2018 and 29 September 2026, over eight years of beacon data. The corpus is available on Hugging Face: https://huggingface.co/datasets/fox-srt/cobaltstrike-beacon-corpus

Back in March 2022 we published Mining Data from Cobalt Strike Beacons. That post covered 128,340 beacon sightings collected from July 2018 to February 2022, and it introduced our Python project dissect.cobaltstrike for parsing them.

Since then, public scanning for Team Servers has become routine, and Cobalt Strike has shipped versions 4.6 through 4.13. Researchers have regularly asked us for an updated dataset. And here it is, a large, consistent, long-running dataset for the infosec community to build on. The corpus includes the raw beacon payloads, not just our parsed output, so anyone can reproduce our results or improve on them.

We also see publishing this corpus as an act of preservation. C2 infrastructure is short-lived, as the median Team Server is reachable for just 14 days, and the beacons it serves vanish with it. Eight years of collection captures things that can no longer be observed today, like the waves of cracked 4.0 builds or the adoption of leaked versions. By publishing the raw beacons alongside the parsed data, we keep that record available for anyone to study, long after the servers themselves are gone.

What’s in the corpus

The corpus is published on Hugging Face as two Parquet files:

All beacons were downloaded directly from internet-facing Team Servers, mostly on TCP ports 80 and 443 (HTTP and HTTPS) and UDP port 53 (DNS), with a small number on other ports. We deliberately didn’t include samples from other sources such as VirusTotal, so the corpus reflects the Cobalt Strike landscape as it was visible on the internet.

How we collected it

The collection method matches our 2022 post. We fingerprint likely Team Servers on the internet, then request a beacon payload from each one using a URI that passes Cobalt Strike’s checksum8 check. Every beacon that comes back is parsed with dissect.cobaltstrike, which decodes the configuration block. The result is stored as a sighting.

• Discovery: candidate hosts from our own internet-wide scanning. As in 2022, we’re keeping our fingerprints private so they stay effective; writing your own is left as an exercise for the reader.
• Download: x86 beacons over HTTP(S) and DNS.
• DNS: for DNS listeners we’re not publishing that fingerprint either, but it’s not rocket science. The beacon is fetched as a series of TXT record lookups sent over UDP port 53 directly to the Team Server’s DNS listener.
• Parse: Use dissect.cobaltstrike to parse the beacon and export the configuration
• Enrich: TLS certificate data captured at collection time (where available) and GeoIP/ASN via historical GeoIP databases.

Note that there might be some small gaps in the collection due to automation issues that we did not catch in time.

Getting started

Most research only needs the beacons.parquet dataset. The payloads.parquet dataset containing raw beacon payloads is only required if you want to re-parse the beacons or look into the ones that failed parsing.

I’m a big fan of DuckDB (and SQLite), and over time I’ve become fond of SQL for querying data as well. DuckDB is very fast, and AI assistants are very good at writing SQL queries. These days, that beats hand-writing pandas code and the matching matplotlib charts. That’s why I recommend exploring the data with DuckDB, for example in a Jupyter notebook.

An example of using DuckDB to query the dataset on Hugging Face directly:

SELECT watermark,
       count(*)                          AS sightings,
       count(DISTINCT collected_from_ip) AS servers,
       min(collected_on)                 AS first_seen,
       max(collected_on)                 AS last_seen
FROM 'hf://datasets/fox-srt/cobaltstrike-beacon-corpus/data/beacons.parquet'
GROUP BY watermark
ORDER BY sightings DESC
LIMIT 20;

Take a look at our Jupyter notebook in the Hugging Face repository as a starting point. It contains every query and chart from the sections below, so you can rerun them or adapt them to your own research questions.

A first look at the data

Here are a few quick results to show what the corpus can answer. They’re a starting point, not a full analysis. As with our 2022 post, we invite researchers to explore the data; see also “Research ideas” below.

Old versions never die

Each Cobalt Strike release takes over from the last, but old versions linger. Cobalt Strike 4.0 dominated most of 2020, 4.1–4.2 drove the early 2021 peak of about 3,000 beacons a month, 4.3–4.4 led from mid-2021 through 2022, and 4.5–4.8 took over in 2023. Since 2024, 4.9 and 4.5–4.8 have shared the lead, while 4.10+ remains a small share. Volume has since dropped to around 200 beacons a month, partly because fewer servers stage their beacon, which brings us to the next graph.

No beacon for you

Our collection relies on beacon staging, meaning a Team Server can serve its beacon as a downloadable payload to anyone who requests the right URI or DNS record. Operators can turn this off (the host_stage option in the Malleable C2 profile), and disabling it is common OPSEC advice. To measure how much this affects our beacon collection, we counted two numbers per month:

1. The unique Team Servers (ip:port) confirmed by our high-confidence HTTP fingerprint
2. The unique Team Servers (ip:port) that handed out a beacon over HTTP(S)

These are monthly totals, not a server-by-server match. On average, the Team Servers that handed out a beacon were only about 32% of those we fingerprinted, and that share has drifted down from around 40% in 2023 to 20–25% in 2026. In other words, because not every server hands out a beacon, the corpus shows only part of the Cobalt Strike landscape, and that part is getting smaller. Disabled beacon staging is the most likely reason, but not the only one. Servers can go offline between fingerprinting and download or block our scanners, and our fingerprint doesn’t catch every Team Server.

The dashed sections mark months when beacon collection wasn’t running, because of an automation error that went unnoticed for a while.

The short life of a Cobalt Strike Team Server

The median Team Server was reachable for 14 days. 35% were seen on a single day only, just 14% were still serving a beacon after three months, and only 2% after a year.

We identify a Team Server by its public key and C2 domains from the beacon configuration (or its IP address when the configuration contains no domains), so a server that moves to a new IP is still counted once. This allows us to measure how long a Team Server typically stays online. Identifying servers by public key alone or by ip:port gives almost the same result, a median lifetime of 14–15 days. These are first-to-last-sighting spans, so a server may have been online before our first and after our last sighting. Servers still active in the last 30 days are left out.

It’s always DNS

Most public scanning focuses only on HTTP(S) beacons, but we’ve also collected DNS beacons since 2020 (apart from the months when our automation broke). DNS beacons have declined much less steeply than HTTP(S) ones, perhaps because they get far less attention in public research and OPSEC advice, so fewer operators think to lock them down. After a peak in 2022, they have mostly hovered around 100 a month since 2024, with a median of 120 over the whole period.

Parse me if you can

The corpus also includes 128 unique beacons (0.23%) that we downloaded but couldn’t parse. Note that the corpus doesn’t contain HTML pages or other responses that were unlikely to be a beacon. We excluded those before publishing. At first glance, most are beacons with custom modifications that dissect.cobaltstrike can’t parse yet. And some payloads from the early years aren’t Cobalt Strike at all, but Metasploit Meterpreter payloads. We’ve deliberately left them in for researchers to analyse. You can find all unparsed beacons with: WHERE config_json IS NULL

The unparsed count used to be higher, but we managed to bring that down. We noticed some operators customised their beacon configs, for example by shuffling the order of the configuration settings or changing their type values, which broke our parser (and probably most others). The corpus helped us find these cases, so we made the config scanning of dissect.cobaltstrike independent of layout and added many other features and fixes along the way. See the dissect.cobaltstrike v1.3.0 release notes.

Research ideas

Some other research questions that could be answered using the corpus:

• Clustering: Group operators by config features (watermark, SPAWNTO/PROCINJ hash, C2 profile, certificate, sleep/jitter, specific beacon modifications)
• Classification: Separate red team from criminal infrastructure. Build and publish labelled subsets.
• Infrastructure: Top hosting providers that are hosting a Cobalt Strike Team Server.
• Certificates: Pivot on x509 reuse across servers and time or find how many are running the default Cobalt Strike keystore certificate.
• Benchmarks: Use the corpus as a shared test set for config extractors and ML models.
• Parser failures: 128 beacons can’t be parsed by dissect.cobaltstrike. Figure out why.

Over to you

Eight years of Cobalt Strike beacons are now one download away on Hugging Face. Run your own queries, pick up one of the research ideas above or come up with your own, dig into the beacons we couldn’t parse, and share what you find.

Before you start, read the Limitations section on the dataset card. The raw payloads are real Cobalt Strike beacons, so handle them like any other malware sample.

Google has temporarily stopped accepting product vulnerability reports through its Open Source Software Vulnerability Reward Program (OSS VRP).

The post Google Narrows Open Source Bug Bounty Amid Wave of Invalid Automated Reports appeared first on SecurityWeek.

Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.

Initial access

In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.

GhostContainer on Microsoft Exchange

Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.

We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.

The backdoor is a .NET assembly containing three classes that implement its core functionality:

• Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
• App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
• App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.

Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.

GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis

Traffic redirection

Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.

The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:

• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/js-webpack.zip
• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/jsonp-pack.zip
• https://github[.]com/browserthemes/resourcepack/releases/download/main/resource-pack.zip

One of the repositories used for storing network tools

The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:

• adobe_32.exe;
• AdobeSync.exe;
• trueconf.exe;
• 1cbroker.exe;
• 1c-office-plugin.exe;
• trueconf-broker.exe.

Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.

1. Microsoft dev tunnels
   This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
   

   Execution graph of adobe_32.exe in Kaspersky Research Sandbox

2. rdp2tcp
   This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attacker’s side.

   When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.

   When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.

   

   Creation event for a channel named rdp2tcp (server component startup)

The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.

The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:

netsh interface portproxy add v4tov4 listenport=443 connectaddress=10.0.12.101 connectport=445

Lateral movement

To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.

In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.

Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit

The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.

Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure.

Takeaways

To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network.

Detection by Kaspersky solutions

Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection.

The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:

Backdoor analysis with KTAE

However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.

This malicious activity is detected by the following rules, available in the repository:

• Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events
• Detection of a malicious DLL’s .NET assembly being loaded via PowerShell: suspicious_assembly_loading_into_powershell_via_reflection
• Activity of tunneling and traffic redirection tools: detection_of_access_to_tunnel_domains_dns
• Use of tools from the Impacket toolkit, such as atexec:
  • impacket_possible_activity
  • attempt_to_download_hacktool_or_risktool_by_non_browser
  • credentials_dumping_tools_file_artifacts_creation
• Attempts to replicate an Active Directory database object to impersonate a domain controller: potential_dcsync_via_startupparameters

Process tree in KEDR Expert

Kaspersky Anti Targeted Attack (KATA) detects this malicious activity in network traffic. For example, the Exploit.CVE-2019-0708.TCP.C&C signature allows detecting attempts to exploit the CVE-2019-0708 (BlueKeep) vulnerability.

Alert card for the BlueKeep vulnerability exploitation

Beyond this activity, KATA also detects other NightEagle actions in network traffic, such as the following:

• Traffic redirection and tunneling variations
• Attacks on Active Directory (DCSync, attempts to compromise AD CS, and others)
• Lateral movement across the network

Indicators of compromise

A critical vulnerability has been discovered in the popular WordPress content management system that allows attackers to execute arbitrary code on the web server. The vulnerability has been assigned the number CVE-2026-87902. The good news is that on September 22, WordPress released an update that patches it. The bad news is that the first attempts to exploit CVE-2026-87902 were detected just a few hours after the patch was released. Therefore, all companies whose corporate websites or blogs run on this platform are advised to update immediately.

WordPress versions affected by CVE-2026-87902

According to data published by WordPress on GitHub, all versions of the CMS from 4.7.0 through 7.1.1 are vulnerable. The company has released updates for all supported branches of the system; a complete table listing the patched version numbers can be found on the company’s GitHub page. The latest version of WordPress should be updated to version 7.1.2 (or newer).

What’s the nature of the CVE-2026-87902 vulnerability, and why is it so dangerous?

Under normal circumstances, WordPress loads PHP template files only from a specific folder within the active theme. However, due to the CVE-2026-87902 vulnerability, an attacker can craft a request to WordPress in such a way that an arbitrary PHP file is included — without requiring any authorization. Yes, the file must already be uploaded to the targeted server in some way, but that’s not really a problem for an attacker.

It sounds like a path traversal vulnerability, but in most publications, CVE-2026-87902 is classified as an RCE (Remote Code Execution) vulnerability because, under certain WordPress and PHP server configurations, the attack can lead to the execution of arbitrary code.

How to stay safe

The only way to secure a corporate WordPress site is to install the latest version. The researcher who discovered the vulnerability also offers several tips for hardening CMS security, but emphasizes that these are meant to complement the patch, not replace it.

The Hacker News lists several PHP filenames and IP addresses used in the attack via CVE-2026-87902. These can serve as indicators that a WordPress instance has been compromised.

Given that only a few hours pass between the publication of information about a vulnerability’s existence and the start of attacks exploiting it, it’s crucial for companies to have a properly configured, centralized vulnerability management system. To achieve this, they should have a specialized solution capable of identifying and resolving vulnerabilities, prioritizing them based on actual risks, and automating remediation processes. Our vulnerability management module for Kaspersky Next Optimum can help with this task.

Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.

Initial access

In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.

GhostContainer on Microsoft Exchange

Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.

We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.

The backdoor is a .NET assembly containing three classes that implement its core functionality:

• Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
• App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
• App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.

Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.

GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis

Traffic redirection

Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.

The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:

• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/js-webpack.zip
• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/jsonp-pack.zip
• https://github[.]com/browserthemes/resourcepack/releases/download/main/resource-pack.zip

One of the repositories used for storing network tools

The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:

• adobe_32.exe;
• AdobeSync.exe;
• trueconf.exe;
• 1cbroker.exe;
• 1c-office-plugin.exe;
• trueconf-broker.exe.

Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.

1. Microsoft dev tunnels
   This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
   

   Execution graph of adobe_32.exe in Kaspersky Research Sandbox

2. rdp2tcp
   This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attacker’s side.

   When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.

   When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.

   

   Creation event for a channel named rdp2tcp (server component startup)

The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.

The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:

netsh interface portproxy add v4tov4 listenport=443 connectaddress=10.0.12.101 connectport=445

Lateral movement

To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.

In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.

Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit

The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.

Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure.

Takeaways

To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network.

Detection by Kaspersky solutions

Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection.

The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:

Backdoor analysis with KTAE

However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.

This malicious activity is detected by the following rules, available in the repository:

• Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events
• Detection of a malicious DLL’s .NET assembly being loaded via PowerShell: suspicious_assembly_loading_into_powershell_via_reflection
• Activity of tunneling and traffic redirection tools: detection_of_access_to_tunnel_domains_dns
• Use of tools from the Impacket toolkit, such as atexec:
  • impacket_possible_activity
  • attempt_to_download_hacktool_or_risktool_by_non_browser
  • credentials_dumping_tools_file_artifacts_creation
• Attempts to replicate an Active Directory database object to impersonate a domain controller: potential_dcsync_via_startupparameters

Process tree in KEDR Expert

Kaspersky Anti Targeted Attack (KATA) detects this malicious activity in network traffic. For example, the Exploit.CVE-2019-0708.TCP.C&C signature allows detecting attempts to exploit the CVE-2019-0708 (BlueKeep) vulnerability.

Alert card for the BlueKeep vulnerability exploitation

Beyond this activity, KATA also detects other NightEagle actions in network traffic, such as the following:

• Traffic redirection and tunneling variations
• Attacks on Active Directory (DCSync, attempts to compromise AD CS, and others)
• Lateral movement across the network

Indicators of compromise

Security teams are starting to actively use AI for security work, including vulnerability triage, penetration testing, threat modeling, incident response, and code review. The promise is speed, but a security tool that moves fast and raises too many false alarms doesn’t save time. Engineers spend time on false alarms, on-call is noisier, and teams distrust findings that matter.

Today, we’re releasing Deception Benchmark, the first benchmark designed to measure that trust problem directly. It tests whether a model can distinguish real vulnerabilities from code that looks risky but is actually safe. The benchmark includes 14,822 samples across 16 languages and more than 70 Common Weakness Enumeration (CWE) categories. We evaluated 12 models from five providers and are releasing the dataset and whitepaper to the community. Existing benchmarks measure whether AI can find or exploit vulnerabilities. This is the first to measure whether it can tell real vulnerabilities from false alarms. Under standard prompting, precision at distinguishing real vulnerabilities from false alarms landed in the mid 50s; as likely to be inaccurate as accurate.

In offensive tasks, there’s often a clear result: the exploit works or it doesn’t. Defensive reviews are harder to verify than offensive tasks; a model might recognize a suspicious pattern even when a mitigation makes the issue non-exploitable. In practice, useful systems need to reason about the code, the mitigation, and sometimes the surrounding environment.

The community has made progress on security evaluations. CyberGym tests agents on more than 1,500 realistic tasks. Meta’s CyberSecEval and CyberSecEval 2 measure exploit generation. CYBENCH evaluates capture the flag (CTF) challenges. SEC-Bench and VulnBench push toward authentic security workflows.

Recent work reinforces both the progress and the gap. ExploitGym measures whether AI can escalate from a crash to a working exploit. Microsoft’s Project Perception deploys multi-agent red/blue/green teams for continuous defense. OpenAI’s GPT-Red shows that self-play red-teaming finds novel attacks that frontier models can’t defend against. Since then, OpenAI disclosed that its GPT-6 Astra model crossed the Critical cybersecurity capability threshold, and both OpenAI and Anthropic reported incidents where models gained unauthorized access to production systems during evaluations. The offensive side is moving fast. But none of this work measures the defensive precision question: when an AI system flags code as vulnerable, how often is it right?

14,822 samples, 16 languages, and more than 70 CWE categories. We call it Deception Benchmark because the safe samples are designed to deceive models. It has real vulnerability patterns, real frameworks, real idioms, with mitigations that quietly close the exploit path. The goal is to classify code as vulnerable or safe, with no hints.

Consider a Flask endpoint that accepts user input and queries a database. A model will pattern-match to SQL injection, but the query uses parameterized statements, so the exploit path is closed. A single-turn classifier flags the pattern and moves on, never checking whether the exploit can actually work. Production tools rely on multi-step loops and agentic workflows to compensate, but that scaffolding masks whether the model itself understands the code. This benchmark strips the scaffolding away and asks the model to make the call in a single pass, so what it measures is understanding, not how many tries a harness takes to get there.

We built every sample through an adversarial loop: generate, test against frontier models, harden, repeat. If a model gets it right easily, the sample doesn’t survive. The result is a benchmark calibrated to the frontier, not below it. Building it this way is expensive. Generation and hardening of the samples consumed tens of billions of tokens. We’re releasing the result so the community doesn’t have to repeat that cost.

This benchmark generates two challenge types. Code-level challenges (6,988 samples) present vulnerable and safe variants that differ by a subtle fix. Both look suspicious, only one is exploitable. Environment-gated challenges (2,707 samples) go further: same code, different deployment context. A Kubernetes Network Policy blocks the server-side request forgery (SSRF) path. An identity and access management boundary prevents privilege escalation. The pattern is visible in the source. The infrastructure makes it unexploitable. The model has to figure out which scenario applies.

All samples were purpose-built for this benchmark, grounded in real-world patterns, real frameworks, real CWEs, and real infrastructure; without IP concerns or training data contamination.

Generating reliable labels at this scale is difficult: a single pass—by people or by models—leaves errors that skew scores. So we treat labeling as a convergent audit loop rather than a one-time step. Every label is re-examined by multiple independent reviewers, blind to one another and to the original reasoning that produced the label. Disagreements escalate to direct adjudication, where the original reasoning is evaluated against the challenge. Unresolved cases go to human review. We repeat the loop until the scored set converges below a dispute threshold: under 3 percent of samples still contested by independent review, with a target of under 1 percent surviving human adjudication. One choice makes this defensible: we never relabel a disputed sample. When reviewers disagree, the sample moves to the unscored pool instead of being given a corrected label, so a bad challenge can remove a sample but can never introduce a wrong label into the scored set.

A human review of 100 randomly drawn scored samples found no label errors. We describe the full process in the whitepaper.

The benchmark is roughly balanced: half vulnerable, half safe, so a random classifier scores 50 percent. We report two error rates separately, because they fail in opposite directions. The false positive rate (FPR) is how often the model flags safe code as vulnerable. These are the false alarms that waste an engineer’s time. The false negative rate (FNR) is how often it misses a real vulnerability and calls it safe. Accuracy alone hides this: a model that labels everything vulnerable catches every bug (0 percent FNR) but flags all safe code (100 percent FPR) and still scores about 50 percent. We consider FPR below 10 percent and FNR below 10 percent the minimum bar for production use.

Figure 1: FPR compared to FNR for 12 models across two prompting strategies. No model reaches the generous bar.

Among the general-purpose frontier models tested, no configuration achieves both FPR and FNR less than 10 percent on this benchmark.

Every model has the same failure mode. With direct prompting, they catch up to 95 percent of real vulnerabilities but also flag 41–99 percent of safe code. Precision runs from 52 percent to 71 percent, clustered in the mid-50s; effectively as likely to be inaccurate as accurate. The models see a vulnerability pattern and stop reasoning. Proof-of-exploit prompting cuts false positives by 17–74 points but misses 7–44 percent of real vulnerabilities. The environment-gated challenges are worse: models flag the code and ignore the Kubernetes Network Policy next to it. No tested configuration keeps both false positives and false negatives below 10 percent.

These results reflect general-purpose models in single-turn prompting. Purpose-built systems with multi-step validation and tool use are a different operating point that we didn’t measure, and if a harness can close the gap between pattern recognition and genuine understanding, this benchmark is the place to demonstrate it. Two cautions before assuming it already does. Agentic verification is proven mostly on offensive tasks, where success can be confirmed: the exploit fires or it doesn’t. Judging that code is safe has no such oracle. Extra iterations re-sample the same judgment rather than confirm a negative, and a harness still inherits the base model’s understanding. If the model can’t separate an effective mitigation from an ineffective one in a single pass, more passes won’t add the missing knowledge. That’s what this benchmark measures: the model’s intrinsic ability to understand code, tested at the single-turn baseline where no scaffolding can mask the gap.

For security teams evaluating AI tools today: ask your vendors how their system performs on tasks like this, not just whether it finds vulnerabilities, but how often it’s wrong. Pair any AI-assisted review with human verification on high-risk code paths, and use Deception Benchmark to hold your tools accountable.

We built Deception Benchmark to simplify measuring this problem in a reproducible way. The public release includes the samples and evaluation workflow. We don’t release the labels, so submissions can be scored consistently over time without turning the benchmark into a memorization exercise.

Of the 14,822 samples, 9,695 are scored; the remaining 5,127 are held out and unscored, mixed in with the rest of the benchmark. The goal is straightforward: make it more difficult to optimize the benchmark compared to improving the underlying system. We describe that design in more detail in the whitepaper.

Deception Benchmark is available on GitHub, along with the whitepaper and submission instructions for verified scoring. If you’re building security tooling, you can download the dataset, run your system against the benchmark, and submit predictions for scored evaluation.

If you have feedback about this post, submit comments in the Comments section below.

A working checkout page is often the moment a business starts to feel real. The products are live, the cart is functional, payments are flowing, and orders are landing in your inbox. That is also when security shifts from a background concern to a real-world risk.

Once your website starts accepting credit card payments, it becomes part of a payment environment attackers actively look for.

That does not mean every small ecommerce store needs an enterprise security team.

Continue reading PCI Compliance Isn’t a Checkbox: How to Secure Ecommerce Checkouts Before Attackers Arrive at Sucuri Blog.

The attackers deployed a new Go-based backdoor that uses Microsoft Teams servers for command-and-control.

The post Microsoft Teams Relay Servers Abused in DragonForce Ransomware Attack appeared first on SecurityWeek.