Adobe Commerce PolyShell Attacks Breach Hundreds of Stores as Brotli Exploit Traffic Emerges

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added two vulnerabilities impacting Adobe Commerce and Magento, and Google's Brotli decoder library to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.

The vulnerabilities are listed below -

• CVE-2026-111497 (CVSS score: 9.2) - An unchecked return value vulnerability in Google Brotli that could allow a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial-of-service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.
• CVE-2026-48356 (CVSS score: 9.3) - An unrestricted upload of a file with dangerous type vulnerability in Adobe Commerce and Magento that could result in arbitrary code execution in the context of the current user, potentially gaining elevated access or control over the victim's account or session.

The development comes days after Sansec said it observed attackers leveraging CVE-2026-48356, also known as PolyShell, to breach hundreds of e-commerce stores to inject a malicious loader via a Magento CMS block.

The loader is designed to fetch and execute an attacker-controlled payload, although no next-stage malware has been recovered to date, making it challenging to determine what the exact goals of the campaign are. The activity is assessed to be ongoing since at least July 2025.

As for CVE-2026-111497 (aka Broccoli2Shell, HTTP2Shell, and Node2Shell), telemetry data from threat intelligence firm Previdian shows that one exploitation attempt has been recorded against its honeypot sensors from a U.S.-based IP address as of October 27, 2026. It's currently not known if these efforts are broad in scope.

"An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory," Rapid7 said. "According to Node.js, this corruption can lead to a process crash, disclosure of sensitive process memory, or remote code execution. Exposure therefore depends on whether an application passes attacker-controlled compressed data to the affected decoder."

ELLIO also reported on Monday that its sensors "have recorded CVE-2026-111497 exploit traffic in the wild, carrying the public exploit that we confirmed gets a shell on vulnerable builds." The activity originates from "94.154.43[.]7," an IP address geolocated to the Netherlands that has also engaged in exploitation efforts targeting PHP2Shell, two critical flaws in PHP that could result in unauthenticated remote code execution.

"The attacker's payload is a genuine, correctly-structured Node2Shell exploitation attempt for node v24.22.0 – the Brotli stream, staged displacement, pivot pair, and delivery are all correct and identical to the public tooling," ELLIO said. "This is indicative of the RCE being adopted by an operator focused on mass exploitation."

The fact that Brotli is a widely distributed open-source library and adopted by numerous projects has provoked an emergency response, prompting various vendors to release patches or assess if their products are affected by the flaw.

This includes PHP, which has shipped versions 8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1, as well as Node.js, Bun, Envoy Proxy, Istio, .NET, Python, ClickHouse, the PHP Brotli extension, and the Ruby "brotli" gem. Links to some of the advisories are below -

"Node.js fixed the vulnerability in versions 22.23.4, 24.22.1, and 26.12.1," Akamai said. "The Node.js advisory does not offer a workaround, so upgrading is the only complete remediation. Organizations running a discontinued release line should move to a supported release line."

Google-owned Wiz has warned that "91% of cloud environments have resources vulnerable to CVE-2026-111497 and 82% of cloud environments have publicly exposed Node.js instances."

"Node2Shell is not a bug in every Node.js service, but a bug in services that decode attacker-influenced Brotli," Sysdig said. "Express 5 with default JSON parsing puts a large number of instances of them in that group. The demonstrated impact thus far is crashes at scale and code execution in a narrow configuration, so patch order should follow reachability."

Federal Civilian Executive Branch (FCEB) agencies have time until November 10, 2026, to apply the necessary fixes against the two flaws.

from The Hacker News https://ift.tt/2uOFhxe
via IFTTT

OpenClaw Enterprise: Making AI Agents Safe for the Enterprise

Brian interviews Derek Carr and Mrunal Patel, distinguished engineers at Red Hat, about OpenClaw Enterprise, the new open-source project that brings Red Hat, NVIDIA, and the OpenClaw community together to make persistent AI agents safe and manageable at enterprise scale. The work started with OpenShell, a deny-by-default sandbox the pair helped build with NVIDIA that treats every agent as potential malware. Agents never see credentials (a supervisor egress proxy injects them from outside), kernel features like Landlock restrict what they can touch, and when a blocked agent hits a wall, OpenShell can ask it why it tried, so a human can decide whether to allow the action now or never. Running real agents in that sandbox showed them that not everything should be untrusted. Memory, for example, is an enterprise record. That insight led them to OpenClaw’s own push to decompose agents into trusted and untrusted parts. OpenClaw Enterprise borrows the Hypershift hosted control plane pattern: gateways, memory, and session state live on a control plane cluster, while agent harnesses run in disposable OpenShell sandboxes on a data plane cluster, so a failed sandbox is simply replaced with full context. Enterprises set a permission ceiling; every new agent starts least privileged and grows only up to that limit, and blessed templates for roles like team Q&A, software co-development, and chief of staff make good agent setups repeatable instead of tribal knowledge. The guests also highlight multi-user agents, where colleagues steer the same agent together rather than flooding each other with AI-generated pull requests, and Skipper, the project’s own support agent that preserves the reasoning behind past decisions. The stack is model-agnostic and runs anywhere, including on self-hosted inference such as Dynamo or llm-d. With more than 3,000 pull requests merged since its September launch, the project is targeting a 1.0 release around year-end, with enterprise pilots and production rollouts expected in 2027.

SHOW: 1075

SHOW VIDEO: https://youtu.be/yS2HEiGbxqo

SHOW SPONSORS:

• Nord Security - NordLayer AI Scout 

SHOW LINKS

• TheEntAIShow #1009 - OpenClaw with Sally O’Malley
• OpenShell - the safe, private runtime for fleets of autonomous AI agents
• OpenClaw Enterprise - An open source, vendor neutral platform for managing persistent agents in sensitive environments.

GUEST BIO(s)

Derek Carr is a Senior Distinguished Engineer at Red Hat, where he has worked on OpenShift and in the Kubernetes community since 2014. He is a former member of the Kubernetes Steering Committee and has held long-running leadership roles in Kubernetes SIG Node and SIG Architecture. His recent work focuses on how enterprises can run AI agents safely on Kubernetes, including Red Hat’s work with NVIDIA’s OpenShell on kernel-enforced agent sandboxing.

Mrunal Patel is a Distinguished Engineer at Red Hat, where he has worked on Linux containers, Kubernetes, and OpenShift since 2011. He started the CRI-O container runtime, is a maintainer of runc and the OCI runtime specification, and serves as a chair and technical lead of Kubernetes SIG Node. With Derek, he is now applying deep container isolation expertise to secure execution for AI agents on Red Hat AI.

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/cYJwreA
via IFTTT

CyberStrikeAI Uses 44 AI Agents to Automate Hacking Operations Against Japan Targets

Cybersecurity researchers have disclosed details of three cyber attacks targeting organizations in Japan in which artificial intelligence (AI) was a key element, either in the driving seat or to assist a human operator.

TrendAI, which analyzed three exposed server environments used by threat actors to conduct the malicious cyber operations, described them as distinct from previously published attacks that have leveraged ARTEX, an autonomous AI penetration testing framework, to single out entities in South Korea and Japan.

"These environments held reconnaissance and attack tools, scripts, target lists, results, logs, and command histories," security researchers Bakuei Matsukawa and Joseph C Chen said. "They ranged from workspaces used largely by hand by skilled operators to AI-agent platforms that automated the entire workflow, including command and control."

The first of the three attacks has been found to abuse CyberStrikeAI, another open-source penetration testing tool that was previously put to use in an attack campaign targeting Fortinet FortiGate appliances. The activity was concentrated in a short period in October 2026.

The AI-driven activity leverages the offensive security tool to automate various aspects of the attack lifecycle into a repeatable workflow, beginning with reconnaissance and vulnerability discovery and validation, and exploitation, to command-and-control (C2), persistence, data exfiltration, and automated reporting.

This involves delegating the work among 44 agents to handle various aspects of the attack, while also enabling the generation of forms and fake login pages in the Japanese language.

"In a short period, at least 19 identifiable organizations, including at least 16 in Japan, were subjected to validation activity," Trend Micro's enterprise security division said. "Each had a report in the same format and an index of evidence. These were outputs of a structured process run by the platform, rather than ad hoc notes left by an operator."

The second case has been characterized as a human-led attack with assistance from a large language model (LLM) to accelerate planning and tool development. Analysis of the infrastructure and artifacts indicates that the campaign is also designed to target AI workflow platforms and inference services with an aim to obtain large amounts of inference capacity at low cost.

One of the intrusions is said to have targeted a geographic information system (GIS) server exposed with default credentials, resulting in the theft of cadastral and commercial records, Windows credentials, and email data. The entire campaign lasted for 24 days in August and September 2026.

The third instance is where the AI's role has been found to be confined to developing the operator's tools and scripts, suggesting a limited role played by the technology in a series of campaigns designed to target edge devices from Cisco, Citrix, F5, and Yamaha using published vulnerabilities, management functions, or credentials present in configuration files.

The threat actor is estimated to have run at least six campaigns from January to October 2026, opportunistically striking exposed VPN devices and WebLogic servers. "The operator was experienced, with established practices for automation and evidence management," the researchers said.

There is currently no evidence at this stage that suggests these three incidents share an operator. It's also unknown if the attacks have targeted other regions and what AI models are being used to pull off the attacks.

That said, the attacks involving these threat actors are not restricted to Japan and neighboring countries like South Korea. The operator behind the first case has targeted organizations in Taiwan and Hong Kong, while the third case featured organizations in the U.K., France, Italy, Qatar, and Colombia in its WebLogic discovery lists.

"AI has increased the attackers' workforce, but the work still consists of looking for unlocked doors," TrendAI said. "The types of doors and the weaknesses that leave them open have not changed. What has changed is the ability to try thousands at once, adapt to the target country's language, and continue without fatigue."

The development coincides with the discovery of multiple campaigns in which threat actors of varied motivations have integrated agentic AI into existing offensive security workflows, allowing them to speed up research, malware development, social engineering, and other parts of an attack.

To make matters worse, AI is being increasingly used to accelerate reconnaissance, automate decision-making, and industrialize social engineering, shortening the time between exposure and exploitation of security flaws. According to Microsoft's 2026 Digital Defense Report, AI has collapsed the median time from vulnerability discovery to weaponization to well below 24 hours.

The adoption of AI by bad actors is reducing the time, expertise, and cost required to discover and exploit weaknesses, at the same allowing attackers and defenders alike to operate with greater speed, scale, and autonomy, the Windows maker added.

"The key issue is not simply whether an actor has frontier AI," Trend Micro said. "Access to capable models can already produce meaningful operational gains. Ecosystem depth, however, determines how reliably, independently, and at what scale those capabilities can be sustained."

"AI is no longer an experimental capability for APT groups; it is an operational component embedded directly into campaigns."

The growing demand for AI tools by threat actors has also opened up a new monetization avenue that peddles stolen AI provider session tokens and offensive AI tools APEX AI, MessiahGPT, and DarkGPT, further commoditizing cybercrime and lowering the barrier to entry for carrying out advanced, persistent, and evasive attacks.

Last week, Microsoft revealed that a China-state-aligned threat actor compromised a ConnectWise cloud backup application and used ARTEX to sign in to more than 2,250 Microsoft 365 tenants. The activity has been attributed to Storm-0940, which it said has used the framework since as early as September 2026 to automate password-spraying attacks on hundreds of organizations.

"While the majority of the targeting wasn't successful, Storm-0940 achieved privileged cloud persistence at many organizations in a brief time," Microsoft said. "Storm-0940's activity illustrates how a threat actor with a broad target set can use an agentic AI tool and privileged authentication material to quickly attempt to compromise many organizations."

According to local media reports from South Korea, authorities have identified seven suspects linked to a cybercrime operation that broke into more than 90 organizations in the country, most of which involved ARTEX. The 32-year-old mastermind behind the activity is alleged to have worked at a cybersecurity company between 2019 and 2022, gaining expertise in penetration testing.

In 38 of the incidents, the threat actors demanded ransom payments of 360 million won ($270,000) in exchange for not leaking the stolen data. More than 8.2 million records are believed to have been siphoned from compromised organizations.

Some of the other AI-oriented campaigns that have been documented in recent weeks are listed below -

• A financially-motivated threat actor operating under the handle BUGSTER configured the Hermes Agent framework with DeepSeek V4 as its reasoning engine and Cursor as a secondary tool (both with safety controls disabled) to run a WordPress brute-force campaign against an Indian university's website and generate a REST API enumeration report.
  • The attacker also breached a second Indian public university, exfiltrating a database of more than 5,200 records, including personally identifiable information (PII) on students. A third attack enumerated an Indian site on a popular e-commerce platform to extract a storefront API token, admin email addresses, phone numbers, and payment merchant IDs.
  • "The actor also built specialized AI bot profiles to acquire VoIP fraud expertise through conversation and maintained automated pipelines for Wi-Fi password cracking and cryptocurrency whale reconnaissance (i.e., identifying large cryptocurrency holders)," Palo Alto Networks Unit 42 said. "Notably, the Wi-Fi cracking capability requires close physical proximity to the target, indicating the actor had local access to the targeted locations."
• An e-crime group named CyberCartel has been observed using a multi-agent system called CARLIY0S to coordinate attacks against banks and payment providers across Latin America. The framework employs a cognitive swarm comprising four role-specialized Claude models that "debate each target and defer to one arbiter" before the main orchestrator acts. "The group assigned different roles to commercial AI models to analyze targets, develop attacks, and coordinate operations," Straiker said.
• Threat actors have developed an offensive AI agent designed to hijack exposed AI endpoints to run autonomous attacks, with instructions allowing it to carry out up to 100,000 steps without human approval while the legitimate owner of the exposed endpoint pays for the inference. The system features a malicious loop called Skynet mode that employs a set of 74 tools to scan for targets, infect them, deploy cryptocurrency miners, and reinfect compromised hosts.
• An affiliate for the The Gentlemen ransomware operation has used Anthropic Claude Code during intrusions into at least six organizations in late June 2026, including to generate and execute reconnaissance and exploitation commands, write malicious scripts, modify firewall policies, and identify high-value business systems.
• A credential-harvesting operation codenamed Zerofot built a scanner named "auto_scan" that integrated OpenAI Codex and Claude Code to harvest thousands of API keys and tokens from thousands of exposed hosts across the internet.
• An AI-generated Python framework called RAGE has been used to scan internet-facing services (e.g., Redis, Elasticsearch, Docker, Apache Tomcat, Jenkins, Hadoop YARN, Confluence, and Supervisord), exploit vulnerable deployments, capture credentials, and deploy cryptocurrency miners.
• A human operator employed frontier AI models to breach an enterprise network autonomously over a 10-hour period. "The actor breached a publicly accessible web service to tunnel into the network, deploying an automated recon agent to map internal microservices," Unit 42 said. "Sub-agents combed enterprise code repositories, extracting hard-coded tokens and service passwords." The attacker then harvested master administrative credentials and hijacked an enterprise code application to exfiltrate cloud access keys. The stolen cloud keys were then used to turn the victim's AI endpoints into post-compromise infrastructure.
• A suspected Russian-speaking cyber actor used an AI-assisted workflow to exploit PaperCut NG/MF servers and compromise hundreds of instances. "The campaign extended beyond initial exploitation into a structured post-exploitation pipeline covering Windows credential collection, service-credential harvesting, internal network pivoting, Metasploit automation, and victim packaging," Hunt.io said.
• A Chinese-speaking threat actor has breached websites belonging to more than 100 companies, including Deere, SharkNinja, and Cummins, using an autonomous penetration testing engine called Cairn, tasking it to probe targets, search for security weaknesses that could lead to code execution or account takeover, attempt to break in, and steal sensitive data.

"AI is serving as a force multiplier and an expanding attack surface at the same time," Rapid7 said. "Generative AI is accelerating established attack methods by reducing the time, skill, and coordination previously required to execute them at scale."

"Rather than introducing entirely new categories of exploitation, threat actors are integrating AI into existing workflows to industrialize phishing, automate reconnaissance, and refine malicious scripts with greater speed and precision."

from The Hacker News https://ift.tt/ziEDjQN
via IFTTT

From federal SOCs to Talos: Ryan Fetterman on practical security research

What does it mean to be "blue collar" for the blue team? Amy sat down with security researcher Ryan Fetterman to discuss his journey from federal agency work to his new role at Talos. He shares the realities of detection engineering — including the creative, often frustrating ways attackers evolve their tactics to stay one step ahead of traditional defenses.

Beyond the technical grind, Ryan shares his philosophy on building a career in security without burning out. From the value of project-based learning to the importance of finding time to step away from the keyboard, here's Ryan's take on what it really means to navigate today's cybersecurity industry.

Amy Ciminnisi: Tell me a little bit about the journey that has taken you to Talos, from early on in your career through to now. How did you get here? I actually don't know that much about it.

Ryan Fetterman: I've been doing security about 15 years now, and my career was largely shaped by where I started in the DC area. I spent about a decade there. I started out in consulting and then pivoted over to research, but that was a great place to get started.

I got a lot of great experience in federal agencies and government consulting, continued my education down there, got trained up, got certifications and things like that. And that was where I got my first exposure to doing actual security operations, which is what I really stuck with. It was my first exposure to Splunk.

Querying lots of log data and building visualizations and analytics in Splunk was the first time in my career that I felt it was kind of my natural inclination. It seems like it should have been more obvious to me looking back on it, but it's something that I try to explain to people a lot. When you first get into security, there's a desire to kind of find your specialization and start working towards it. But in my experience, it's just not something that you can rush.

I met the people connected with that space, which eventually led to me going to work for Splunk. I worked on the Splunk research team, SURGe. And then after the Cisco acquisition of Splunk, I ultimately became reorganized into Talos.

AC: I'm sure there have been so many challenges, so many obstacles in your way as you're trying to do this research. Can you share one that you've faced and how it shaped your perspective on cybersecurity?

RF: Something that stuck with me was actually my first advanced persistent threat (APT) incident. Now, you can look this up. It's called Pandora Song if you search for the C2. I was in the DC area working in a federal SOC, and I was doing some of the first host-based analytics at the time, which have now become kind of the concentration of a lot of detection. Engineering and analytics are host-based, so this was kind of pioneering at the time.

I was looking at a lot of host-based sensors and writing analytics in Splunk, actually, and we had been tipped off to this incident by a third party. I was looking through the details of the incident and how the attacker was carrying out the progression of their attack...

---

Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.

from Cisco Talos Blog https://blog.talosintelligence.com/from-federal-socs-to-talos-ryan-fetterman-on-practical-security-research/
via IFTTT

Australia Gets Into Amadey Malware Backend, Cuts Off Access to 180,000 Infected Computers

A criminal using the Amadey malware can no longer access or steal data from 180,000 infected computers around the world, including some in Australia, the Australian Signals Directorate (ASD) says. The agency's operators gained access to the criminal's operation's backend and cut it off from those computers.

"The next steps that we took were to disconnect that Amadey controller from all those victims," Tauri Gregory, ASD's acting deputy director-general of intelligence, told ABC News in an interview published on October 27.

ASD is Australia's foreign signals intelligence and cyber security agency. Its offensive cyber operations need explicit approval from the Australian government and can disrupt cybercriminals overseas by disabling their infrastructure.

Amadey was sold to criminals as a service in 2018, according to ESET's analysis of Amadey. Each buyer runs its own control panel on its own servers.

Computers infected with Amadey check in with their buyer's command-and-control (C2) server and carry out its orders. Amadey's main job is to install more malware, such as the StealC infostealer. It can also steal credentials and give the buyer remote access to the machine.

The most common ways Amadey reached computers were fake software updates, cracked software installers, and other malware loaders.

The criminal's Amadey operation was one of many. In its tracking, ESET identified 53 separate Amadey botnets that did not share infrastructure.

Disconnecting a controller from its victims also does not undo earlier theft. Credentials stolen by infostealers can sit unused for months before attackers use them, according to Microsoft's analysis. A stolen session cookie can allow an attacker to bypass multi-factor authentication (MFA).

ASD's annual cyber threat report, published on October 27, does not describe the operation.

Amadey's infrastructure was also disrupted in June by Operation Endgame, an international law enforcement operation that works with private partners. Between June 15 and 19, the operation targeted servers associated with Amadey, StealC, and the SocGholish malware.

Australia is one of nine countries whose law enforcement and judicial authorities run Operation Endgame together, according to Europol's June announcement. It was not on Europol's list of countries that took part in the June action week, and the announcement does not mention ASD.

In a separate case, ASD said it received a tip that 5 terabytes of data stolen from a business were for sale. The business did not know it had been hacked. The data included business documents, personal data, and login credentials and passwords.

The agency broke in and destroyed the data before it could be sold. The destroyed files included an estimated 4.8 million stolen from Australians and hundreds of thousands taken from victims in other countries.

from The Hacker News https://thehackernews.com/2026/10/australia-gets-into-amadey-malware.html
via IFTTT

OpenAI Compaction Flaw Let Researchers Bypass Hidden Reasoning Protections

OpenAI's compaction feature, which shrinks a long conversation to save space, could be turned into a way to copy a model's hidden reasoning out in plain text, security firm Xint has shown.

OpenAI's reasoning models work through a problem before answering, and the service normally returns only the raw reasoning as an encrypted item the user cannot read. The method got past the protections OpenAI added in August against this kind of reasoning theft. OpenAI confirmed the problem and fixed it on October 23, according to Xint.

Xint ran the technique against gpt-5.6-sol, one of OpenAI's reasoning models, using math and algorithm puzzles its researchers wrote themselves. The reasoning it pulled out came from those same requests, and Xint did not claim the method could reach another user's reasoning.

Xint says it cannot prove the copied text is word-for-word the model's real reasoning, because it never had the original to compare against. Two cheaper models each repeated the item and produced the same text, which rules out mistakes in the copying step but leaves open the possibility that compaction reworded the text.

Compaction is an OpenAI feature that uses a model to squeeze a long conversation into a smaller, encrypted item that carries the context forward.

Xint sent a task to gpt-5.6-sol and kept the encrypted reasoning it returned. It then called the compaction step on the same model and told it to copy that reasoning into the compacted item word-for-word, with every space changed to a tab to get past OpenAI's usage-policy filters.

Because compaction items can move between models, Xint passed the item to the cheaper gpt-4.1 and gpt-4o models and asked each to repeat its input exactly, which they did.

The method worked around a fix OpenAI had already shipped. In August, researchers behind a paper called Stolen Thoughts showed that encrypted reasoning from a strong model could be replayed into a weaker model from the same company, which would then repeat it as plain text. OpenAI and others blocked that cross-model replay soon after.

Compaction got past that block, Xint said, because the compaction step runs on the same model that made the reasoning, so it never triggers the cross-model check.

The idea built on Xint's earlier work, called GhostCompact, which showed the compaction step can be pushed to run tasks of the attacker's choosing. Xint has published the code in its GitHub repository.

The fix was on OpenAI's side, so developers who build on the API do not need to change anything. Xint called it an undisclosed fix and said OpenAI paid the researchers a $6,000 reward.

Xint tested only gpt-5.6-sol and did not check whether GPT-6 Astra, OpenAI's newer model, is affected. It is not known whether anyone used the method before OpenAI closed it. Xint also argued that fixing this one path may not be enough because, in its view, any server-side step that reads a model's decrypted reasoning and follows the user's instructions could leak it.

OpenAI keeps raw reasoning hidden partly to stop distillation, where one company trains a cheaper model on another's outputs. Raw reasoning makes better training data than the final answer alone, because it shows how the model worked through the problem, which is what makes it worth stealing for a rival.

OpenAI said in September that it had disrupted a July campaign that tried to expose its models' hidden reasoning, and linked a core part of it to people associated with China's Moonshot AI.

Anthropic and a joint U.S. government advisory have each reported China-based labs targeting the hidden reasoning of American models. None of that is tied to Xint's compaction method, which is a demonstration rather than an attack seen in the wild.

from The Hacker News https://thehackernews.com/2026/10/openai-compaction-flaw-let-researchers.html
via IFTTT

ShapeBlue Leaders: Driving the Future of Open Cloud

We are delighted to welcome Khachatur Nazaretyan as ShapeBlue’s new Chief Technology Officer (CTO). With over 20 years of experience in IT and cloud infrastructure, Khachatur brings extensive expertise in enterprise cloud architecture, technology leadership and large-scale infrastructure transformation. We sit down with Khachatur to discuss his vision for ShapeBlue’s technology strategy, the evolving role of Apache CloudStack, and the trends shaping the future of cloud infrastructure, from digital sovereignty and open source to AI and Kubernetes. We also get to know the person behind the technology and what excites him most about this new chapter.

Could you introduce yourself and tell us a little about your journey to becoming CTO of ShapeBlue?

I’m Khachatur Nazaretyan, and I’ve recently joined ShapeBlue as CTO, where I set our global technology strategy and guide the direction of our engineering and product work around Apache CloudStack.

I’ve spent over twenty years in IT, most of it designing and operating large-scale cloud infrastructure. Before ShapeBlue, I led solution architecture at NTT DATA Business Solutions, running cross-border teams on complex enterprise cloud programmes.

My PhD in IT Economics gave me a lens I still use every day: technology decisions are ultimately business decisions. ShapeBlue felt like the natural next step, a company that proves every day that open source can run enterprise-grade clouds.

As you step into the CTO role, what will be your main areas of focus?

My focus comes down to three things. First, making Apache CloudStack the obvious, low-risk choice for organisations rethinking their virtualisation strategy. Most enterprises have decided to reduce their dependency on proprietary platforms, but very few have finished the journey, and migration risk is what holds them back. Second, continuing to mature the platform itself, so that what we learn from enterprise deployments flows back into the upstream project as real capabilities. Third, making sure CloudStack is ready for the workloads that will define the next decade: containers and AI. That means first-class Kubernetes integration, GPU-ready infrastructure and bringing AI into how clouds are operated. Underneath all three is a principle I care about: every technology decision should be measurable in business value for our customers.

What do you see as the CTO’s role in shaping ShapeBlue’s long-term technology strategy?

In an open-source company, the CTO doesn’t set strategy alone. Much of the roadmap is shaped together with our customers and the Apache CloudStack community. So I see my role as three parts: listening, deciding and translating. Listening to what customers, partners and our engineers see in the field. Deciding where to invest, which also means being clear about what we won’t do. And translating long-term technology bets into outcomes customers can measure, whether that’s lower total cost, less risk or more control over their own infrastructure. Good strategy is less about predicting the future and more about keeping your options open.

ShapeBlue has always been deeply involved in Apache CloudStack. How do you see that relationship evolving as the technology and the wider cloud market develop?

CloudStack is in ShapeBlue’s DNA, and that won’t change. What is changing is the market around it. A few years ago, CloudStack was mainly the choice of service providers. Today, enterprises and public-sector organisations are looking at it seriously, because they want control over their infrastructure, predictable costs and, increasingly, digital sovereignty. That raises the bar for all of us. I see our role evolving from being a major contributor to also being a bridge: bringing enterprise requirements into the community, and making the project easier to adopt for organisations that have never run open-source infrastructure before. The healthier and more diverse the community becomes, the stronger CloudStack becomes, and that’s good for everyone, including us.

What technology trends do you think will have the greatest impact on cloud infrastructure over the next few years?

I’d point to three. The first is sovereignty. Gartner expects sovereign cloud spending to grow by more than a third this year, with Europe growing fastest, and organisations everywhere are asking a simple question: who really controls my infrastructure? The second is AI moving closer to the data. Many organisations are finding that running AI in the public cloud is expensive, unpredictable and difficult to reconcile with data residency rules, so they’re building GPU capacity in private and hybrid clouds. The third is the convergence of virtual machines and containers. Kubernetes has become the standard for new applications, but most enterprises will run both for years, and they need one platform that handles both well. What connects all three is control, and that’s exactly where open infrastructure is strongest.

How do you see AI influencing cloud infrastructure and the way infrastructure platforms are developed and operated?

AI is changing infrastructure in two ways at once. On the operations side, we’re moving from dashboards and alerts towards AI agents that can diagnose an issue, propose a fix and, with the right guardrails, carry it out. Gartner expects most enterprises to use agentic AI in infrastructure operations by the end of the decade. But an AI agent is only as good as the knowledge and context it works with. Understanding how a platform really behaves in production, its edge cases, failure modes and best practices, is what turns a generic model into an operator you can trust. That’s where ShapeBlue’s more than a decade of hands-on CloudStack expertise becomes a real advantage. On the development side, AI is already part of how engineers write, test and review code. But AI amplifies whatever engineering culture you already have, good or bad. AI should make our engineers faster, never make our platform less reliable.

Open-source is central to ShapeBlue’s identity. How does working in an open-source environment influence the way you approach technology leadership?

It changes where your authority comes from. In an Apache project, nobody can simply instruct the community to accept a change. You earn influence through the quality of your contributions, the strength of your arguments and the trust you build over time. I try to lead the same way inside ShapeBlue. It also makes you more transparent. When your code, your design discussions and even your mistakes are public, you learn to explain your reasoning clearly and to welcome challenge rather than avoid it. I bring that into every decision: being open about why it was made, what drove it and why the alternatives were dropped. People don’t have to agree with every decision, but when they understand the reasoning behind it, they can trust it. And it encourages long-term thinking, because what we contribute today will be run by organisations around the world for years. In open source, you lead by earning trust, not by giving instructions.

What do you think makes a strong engineering culture, particularly in a distributed and employee-owned company like ShapeBlue?

For me, it starts with ownership and accountability, and at ShapeBlue ownership is literal. Every employee is a shareholder, so when an engineer goes the extra mile to get a release right or solve a customer’s problem properly, they’re investing in a company they own. That changes how people think about quality and about taking responsibility for the outcome. Being distributed adds another ingredient: clarity. When your team spans several countries and time zones, you can’t rely on corridor conversations. Decisions, priorities and context have to be written down and easy to find, so people can act independently without waiting for permission. I’ve led cross-border teams for many years, and the lesson was always the same: distance isn’t the problem, unclear expectations are. Strong engineering culture is ownership, accountability and clarity, built on trust.

What are you most excited about as you take on this new role?

The timing. For the first time in years, organisations are seriously questioning how they run their infrastructure, driven by cost, sovereignty and AI, and open source has a real answer to all three. ShapeBlue is in a unique position to deliver it: deep CloudStack expertise, a team that has spent years running CloudStack in demanding production environments, and an ownership model that lets us think long term rather than quarter to quarter. On a personal level, I’m excited to work where technology and business meet, helping customers make decisions that are both good engineering and good business. Moments like this don’t come often in infrastructure, and I’m glad to be part of this one.

And finally, who is Khachatur beyond technology and ShapeBlue?

Someone who recharges outdoors, ideally with my family. I live in Dresden, which is a wonderful base for hiking, with Saxon Switzerland practically on the doorstep, and some of our best family time is spent on the trails there. I also make a point of staying fit, whether that’s at the gym or out on my bike. And I’m a passionate Formula 1 fan. It’s engineering, strategy and teamwork under extreme pressure, where every decision is backed by data and a few milliseconds make the difference. So perhaps I never completely leave work behind. But being outdoors is where I find the space to think clearly, and some of my best ideas have come halfway up a hill rather than in a meeting room.

 

 

 

 

Interview by Antonia Shehova | ShapeBlue

The post ShapeBlue Leaders: Driving the Future of Open Cloud appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/DHYygX6
via IFTTT

Attackers Hijack Dahua IP Cameras in Ukraine Using P2P Access and Auth Weaknesses

The Computer Emergency Response Team of Ukraine (CERT-UA) has issued an alert warning of unauthorized remote access to video surveillance systems manufactured by Dahua.

"Cases of compromising IP cameras and DVRs with access to the video stream, changing the device configuration and creating third-party accounts have been recorded," the State Special Communications Service of Ukraine (SSSCIP) said in an alert issued last week.

The primary initial access vector used in the attacks is via Easy4IP, a peer-to-peer (P2P) platform that allows users to remotely monitor homes or small businesses by connecting their Dahua IP cameras, NVRs, and DVRs via a smartphone app or web browser by scanning a QR code or entering the hardware Serial Number (SN).

The agency has warned that the serial numbers have a predictable structure containing a 10-character model prefix that's identical for all units of the same device family and a five-character hexadecimal counter that's incremented almost sequentially (e.g., 7K01F36PCA003E8).

This, in turn, allows attackers to guess them at scale through a brute-force attack and identify if they are connected to the cloud without hitting rate limits or lockouts. As a result, all devices with active P2P functionality are at risk even if they cannot be accessed directly via the internet.

"The assumption that the serial number is unknown to anyone is not a reason to consider the device secure," CERT-UA said.

Authentication barriers are overcome by leveraging weak or known passwords, or by exploiting authentication bypass vulnerabilities in outdated firmware versions, such as CVE-2021-33044 and CVE-2021-33045. CERT-UA has shared the following indicators of compromise associated with the activity -

• Presence of unknown accounts
• Unauthorized configuration changes
• Audit logs containing authentication events using the manufacturer's native protocol (DVRIP) and from a local address (127.0.0.1), a sign of P2P access.

To counter the threat, it's advised to disable the P2P feature if not required, avoid exposing them directly to the internet, and keep the software up-to-date.

The agency has not disclosed who was targeted, when these infections occurred, how many devices had been infected, or who was responsible for the activity. However, the findings share similarities with two clusters of activity that Hunt.io disclosed as targeting IP cameras in Ukraine and Russia.

One of the campaigns, attributed to a Russian-speaking operator, singled out internet-exposed cameras in Ukraine using known Dahua and Hikvision vulnerabilities, ultimately compromising 58 devices. The activity involved the exploitation of the following flaws by integrating Ingram, a publicly available webcam vulnerability scanner -

• CVE-2017-7921 - An authentication bypass vulnerability in Hikvision
• CVE-2020-25078 - A credential disclosure vulnerability in D-Link
• CVE-2020-25169 - An unauthenticated information disclosure vulnerability in Reolink
• CVE-2021-33044 / CVE-2021-33045 - Authentication bypass vulnerabilities in Dahua that allow passwordless login
• CVE-2021-36260 - An unauthenticated remote code execution vulnerability in Hikvision.

In parallel, the threat actor is also said to have undertaken scanning and exploitation of TP-Link and MikroTik routers and cameras using vulnerabilities like CVE-2024-53375 and CVE-2024-57049 across 15 European countries, including Ukraine, Poland, Romania, Moldova, Hungary, Czechia, Slovakia, Bulgaria, Germany, France, the Netherlands, Italy, Spain, the U.K., and Austria.

The second campaign, codenamed Operation CameraSwarm and attributed to a lone threat actor, is believed to have compromised over 14,530 Dahua IP cameras between June 17 and July 22, 2026, using a combination of credential brute-force attacks and the exploitation of the CVE-2021-33044-CVE-2021-33045 chain.

The attack scans for TCP port 37777, which is the default proprietary management and video streaming port used by Dahua, followed by collecting serial numbers, breaking into those devices by employing the aforementioned two exploitation methods, and then deploying a persistent backdoor account ("p2pwn / p2password") on nearly 2,000 cameras in a manner that can survive password change and a factory reset.

"1,923 cameras carry a persistent backdoor account (p2pwn / p2password), installed over RPC after either bypass," Hunt.io noted at the time. "It is stored independently of the admin password and survives a password change and, on most firmware, a factory reset. 283 cameras were reached by serial number alone through Dahua's cloud relay, with no device address and, in most cases, no credentials."

In some instances, the attackers have been found to abuse Dahua's cloud relay to reach cameras behind NATs using only their serial numbers.

Earlier this year, Dutch intelligence agencies warned that Russian actors are compromising IP cameras across the E.U., NATO states, and Ukraine to conduct systematic digital espionage operations and acquire military intelligence.

"This actor performs automated analysis of imagery through image recognition software to conduct targeted searches for military vehicles and the military cargo they are transporting," the July 2026 bulletin said.

"This provides the actor with, among other things, relevant military data, such as E.U. and NATO military transport routes, weapon deliveries to Ukraine, and the locations of Ukrainian military personnel. The information from IP cameras in Ukraine is used in attempts to neutralize Ukrainian military personnel and to destroy their military material."

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/2rfAisv
via IFTTT

CISA Confirms Active Exploitation of Two PHP2Shell Flaws Enabling Remote Code Execution

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday confirmed active exploitation of the recently patched PHP2Shell flaws by adding them to its Known Exploited Vulnerabilities (KEV) catalog.

The PHP vulnerabilities, both rated 9.2 on the CVSS scoring system, facilitate unauthenticated remote code execution on affected deployments -

• CVE-2026-109618 - An out-of-memory corruption vulnerability that allows for unauthenticated remote code execution.
• CVE-2026-109619 - A stale internal request-state vulnerability that allows for unauthenticated remote code execution.

The addition of the two flaws to the KEV catalog comes after Adel Karimi, detection and response lead at Perplexity, confirmed successful instances of remote code execution against honeypot systems on October 24, 2026.

"This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process," Karimi said. "The response delivered an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit's offsets appears in the subsequent execution payload."

"The evidence demonstrates this chain on the intentionally favorable single-worker mod_php profile; it is not a measurement of exploit reliability on other worker counts, PHP builds, or applications."

The issues have been addressed in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 released on October 21, 2026. Federal agencies have time until October 29, 2026, to apply the necessary fixes.

PHP, short for PHP: Hypertext Preprocessor, is a server-side scripting language used in roughly 70% of all websites on the internet. According to estimates shared by Censys, more than 32.51 million PHP services are still running an affected version.

The severity of the vulnerabilities has prompted numerous advisories from software and security vendors and government agencies across the world, including -

As of October 26, 2026, the PHP Foundation also released Windows builds 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 to address CVE-2026-111497, an out-of-bounds write vulnerability in the Brotli decoder library that could also result in privilege escalation and unauthenticated remote code execution.

The vulnerability, also known as Broccoli2Shell, HTTP2Shell, and Node2Shell, affects Brotli versions 1.0.3 through 1.0.9, 1.1.0, and 1.2.0. It has been patched in versions 1.0.10, 1.1.1, and 1.2.1, along with other projects that include the C library, including Node.js, Bun, Envoy Proxy, Istio, .NET, and Python.

"In PHP Windows builds, the vulnerable decoder can be reached through the cURL extension when automatic HTTP response decompression is enabled," the PHP Foundation said. "This is disabled by default in cURL, but applications and HTTP client libraries can enable it."

from The Hacker News https://ift.tt/5HzWiYp
via IFTTT

Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento

An unknown threat actor has infected 953 online stores, most of them running Magento, as part of a long-running campaign active since July 2025.

According to Dutch e-commerce security company Sansec, the activity is designed to add a small piece of code to the store's pages that, when visited by unsuspecting users, serves malicious JavaScript loader code through Magento CMS blocks.

"When you visit, that code makes your browser ask the group's server what to do next," Sansec said. "The server first checks whether you are a real shopper or a security scanner, so scanners get nothing."

No less than five distinct domains have been observed over time in connection with the campaign -

• manulfie[.]click, first seen in July 2025
• neswnsssn[.]click, first seen in December 2025
• lanhd6549tdhse[.]top, first seen in March 2026
• additionalver[.]com, first seen in June 2026
• deepveindrilling[.]com, first seen in October 2026

Sansec said it found deepveindrilling[.]com in the CMS blocks of 83 online stores since the domain was registered on October 6, 2026.

The latest JavaScript loader domain is hosted behind Cloudflare and only responds to script requests from real visitors of infected stores. The loader is staged within Magento's cms_block database table, which is used to render static content into storefront pages.

The ultimate objective of the attack is to launch the attack-controlled code when the CMS block is rendered after a shopper opens the compromised website.

While Sansec does not disclose whether the threat actor modifies an existing CMS block (such as header, footer, or promotional banner) or creates a new block, the attacker can adopt either of the approaches to run the loader.

Two different versions of the loader have been spotted. In one version, the external JavaScript loaded from the attacker's domain stores the payload in the browser's localStorage. This causes the stashed code to be run again on subsequent visits, even if the external domain becomes unavailable.

The second version expands on this behavior by incorporating browser fingerprinting checks to filter out bots and security scanners, while ensuring that only real shoppers are exposed to the malicious code. The exact nature of the final payload remains unknown.

Early iterations of the campaign have also been observed using Keitaro, an advertising tracker and analytics platform, as a traffic distribution system (TDS), to route visitors to different responses – i.e., return a payload, a redirect or nothing – based on their characteristics.

Sansec said requesting the additionalver[.]com script as a Windows desktop visitor returned as response "QWE=123;," which does nothing apart from setting a cookie that marks the visitor for 24 hours. The deepveindrilling[.]com domain, on the other hand, drops the Keitaro component and integrates the bot-filtering logic into the loader itself.

As for the initial access vector, 471 Magento stores are estimated to have been injected with the loader through the PolyShell (aka CVE-2026-48356) vulnerability. Another 102 stores saw files uploaded through the PolyShell or SessionReaper (aka CVE-2025-54236) vulnerabilities.

"One store on Magento 2.4.7-p1 had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, next to the additionalver.com loader in a CMS block," Sansec said. "The block switched to deepveindrilling[.]com on October 7. The store still lacks APSB26-73, Adobe's PolyShell fix for supported release lines."

In another case, an e-commerce store running Magento 2.4.7-p10 with no missing core patches was compromised to add a rogue administrator account and then use it to inject the code.

Site owners are advised to audit their sites for suspicious accounts and unexpected CMS blocks in the cms_block and cms_page tables. It's also advised to keep the sites up-to-date and enforce strong passwords.

The disclosure comes against the backdrop of PHP2Shell, a set of two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) that have witnessed widespread exploitation attempts following their disclosure last week.

However, Perplexity researcher Adel Karimi has recorded what appears to be the first in-the-wild successful exploitation of the vulnerabilities to run shell commands on honeypot servers. These commands have been observed using wget, curl, or PHP CLI to fetch additional payloads from a remote server ("162.35.99[.]94:80").No downloaded second-stage artifacts have been observed so far.

from The Hacker News https://ift.tt/OjC0Mh3
via IFTTT

Between alerts: What Attackers Do in the Spaces Ordinary Detection Misses

Every SOC struggles with a pile of alerts. Very few of those alerts explain how an attack started or how it progressed. Network data, like that from a network detection and response (NDR) platform, connects individual alerts into one timeline, and it feeds the defensive systems that can tie all events together into one coordinated view.

SOC teams often first see the shape of an intrusion through a series of smaller alerts that are triggered (e.g., when a signature matches a known malware hash, a threshold flags an unusual spike in failed logins, or an endpoint agent detects suspicious activity). When viewed through the SIEM dashboard, an attack often begins as a series of distinct events with related or overlapping timestamps.

Artificial intelligence has accelerated modern attacks, enabling attackers to automate reconnaissance, craft targeted payloads, and execute scripts in seconds. Yet, speed does not obfuscate the need for stealth. To evade detection, adversaries deliberately draw out operations, hide inside standard admin tooling, and work in the quiet intervals between alarms.

Adversaries might spend days or weeks inside an enterprise environment before an action generates a high-priority security alert. When an alert finally surfaces, it doesn’t necessarily mark the start of a compromise. It may, in fact, be one event in a much longer sequence. Analysts who investigate only the triggering event may miss the chained activity that explains how the intrusion developed.

The anatomy of silent progression

Between initial access and a high-severity alert, adversary activity can blend into ordinary business operations. Adversaries understand the operational limits of security teams, and they exploit them; if every DNS query, LDAP request, SMB connection, or authentication attempt generated an investigation, SOC queues would quickly become (even more) unmanageable.

Tradecraft purposely takes advantage of that reality.

Adversaries can spread reconnaissance across hours or distributed sources. Instead of launching an obvious scan, they may use a compromised account to query a domain controller over LDAP at a modest pace to map users, groups, and systems. A handful of Kerberos service ticket requests can yield credentials to crack offline, well outside the SOC’s view. Valid credentials then open the door to SMB or RDP, the same services administrators rely on every day, and the attacker moves from host to host. Files may be gathered on one internal system and compressed. Later, that system may reach an external destination over HTTPS or DNS at regular intervals, with just enough variation in timing to resemble normal traffic as it exfiltrates data.

Each step borrows something the business already depends on.

While individual actions may not necessarily look suspicious, their significance often emerges from relationships and sequences. For instance, a host that communicates with a new system once may be unremarkable. A host that queries several internal services, authenticates to a peer, establishes an SMB session, and then connects to an external destination presents a different investigative picture. The activity becomes more meaningful when viewed across time.

When siloed tools see only slices of this type of transaction, they might miss the bigger picture. Context only becomes readily apparent when activities and signals are combined and correlated via network observation.

What’s more, attackers increasingly use AI to automate reconnaissance and move faster. Defenders need to apply AI to the same problem, but it needs detailed network evidence from an NDR to search.

The evidence between the alerts

SecOps teams don’t have to turn detection thresholds down and drown analysts in more alerts just to spot adversary activity. Doing so would be untenable anyway. A SOC can’t investigate every DNS query, authentication request, or connection as though it were an incident. In addition, many teams operate with tools that show an alert fired yet offer sparse detail on how the activity behind it unfolded.

To prevent blindspots, SOC teams can retain the underlying network telemetry so an analyst can go back and review what happened when an alert, outage, or other signal gives them a reason to look.

However, that requires more than knowing when two systems exchanged traffic. Protocol-aware network data from an NDR platform can show the kind of interaction that took place, who or what participated, when it happened, and how that relationship evolved over time.

For instance, if a workstation triggers an endpoint alert at 2:14 p.m. the alert may show an analyst what happened on the endpoint at that moment. Network evidence from an NDR can extend the timeline and answer a few crucial questions:

• Was the workstation querying an unusual domain earlier that day?
• Did it authenticate to another system or establish SMB connections to internal peers?
• Did those systems communicate with additional hosts?
• Did the workstation later establish an encrypted session with an external destination?

Each individual event may have perfectly legitimate explanations. It’s only in combination, though, that the sequence provides a different level of context.

For an investigator, that context helps establish whether the endpoint event was an isolated problem or one discrete stage in a broader progression. For an AI-assisted investigation, the context derived from NDR provides the evidence needed to search for related activity across hosts, users, protocols, and time rather than treating each alert as a separate event.

Why this matters for the AI SOC

AI in the SOC changes the economics of an investigation. While a human analyst has to decide which systems, users, sessions, and time periods deserve attention, an AI-assisted SOC can search across that same breadth of evidence much faster, bringing relevant data into one view in minutes rather than hours. Correlation and analysis can happen asynchronously, allowing analysts to review and query a broader set of data much sooner. When AI handles the synthesis, the process of identifying patterns is faster, still.

When an attacker is patient, methodically timing actions across longer periods, evidence might be spread across hundreds of seemingly ordinary transactions. Since a human analyst can’t reasonably manually investigate each piece of evidence, the more practical approach is to construct an automated workflow in an NDR platform to identify context and look for relationships, then give the analyst the evidence so they can make a judgement call.

The outcome is more activity examined, across more systems, over a longer period. The benefits are:

• Time savings: manual work is significantly reduced
• Clearer insights: more context can be surfaced by advanced algorithms searching across thousands of data points
• Better decisions: analysts can focus on making strategic risk decisions instead of picking apart pieces of alerts

The same process can help with operational issues. If an application goes down, for example, network telemetry will show which services were communicating, where communications began to fail, which dependencies were affected, and what changed around the event. If the cause turns out to be malicious, the investigation already has a record of the activity.

Beyond individual alerts

Alerts give analysts a place to start an investigation. They do not necessarily explain what happened before it, what happened after it, what’s happening simultaneously, or whether other activity in the environment is related. Issues that appear routine in isolation may look very different when data is correlated and context is added.

Network telemetry provides the surrounding evidence needed to build critical context. Protocol-aware data from the NDR preserves the details of network interactions, including both ends of a communication, the protocols and services involved, timestamps for those interactions, and how interactions change over time. It’s the telemetry that gives automated investigation workflows a broader body of evidence to work from when triaging a high-priority alert.

With evidence available for automated analysis, AI agents can correlate activity over time, connect communications between systems, and surface sequences that would otherwise remain separate innocuous-looking events. The ability to apply context across disparate communications and sequences is what allows SOC teams to find the riskiest activity. Without this evidence, individual alerts and sequences may continue to present as harmless. Attackers have already identified the opportunity; now it’s time for defenders to apply the same principles and keep up.

About Corelight:

Your AI SOC is only as effective as the data behind it. Corelight network detection and response (NDR) delivers data that’s open, transparent, and explainable—helping detect evasive threats, reduce triage time, and enable agentic AI throughout the SOC. Corelight’s structured network evidence preserves protocol-level context to produce a more complete dataset for investigation and AI. When analysts and AI can reason from evidence instead of isolated alerts or metadata, they can validate findings, reconstruct activity, and reach more reliable conclusions. Learn more about Corelight at https://corelight.com/cp/elitedefense

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/VBeW8ZS
via IFTTT

uCreator Android Spyware Can Steal Telegram 2FA Passwords and Clone WeChat Accounts

A rentable Android spyware kit called uCreator takes over Telegram and WeChat accounts by hiding its code inside working copies of the two apps, researcher Ovi found. It only reaches people who install one of these tampered copies, spread outside the official app stores, or who run WeChat inside the kit makers' own container app.

The kit's Telegram part matches Baohuo, a backdoor that Doctor Web reported in October 2025. Doctor Web found Baohuo in tampered copies of Telegram X, an Android app from Telegram. At the time, the company estimated that more than 58,000 devices were infected.

The Hacker News compared the two reports. Doctor Web's technical description of Baohuo lists the same code namespace, com.ucreator.tgjar, the same command-and-control (C2) server, and matching command names as Ovi's analysis.

Ovi's analysis, published October 21, 2026, does not mention Doctor Web's findings, and Doctor Web did not name the kit. It is not clear whether the kit's makers or one of their customers ran the campaign Doctor Web tracked.

Who Is Exposed

The tampered apps spread through sideloading, where a person installs an app file directly instead of from an app store, and through social engineering, Ovi found. He could not confirm how every victim was infected.

A second route is the kit makers' own container app, called 洋葱盒子 ("Onion Box"), which runs other apps inside itself.

Some of the tampered Telegram X copies use the same package name as the real app on Google Play, so the name alone does not give them away.

Doctor Web found that Baohuo copies had been spreading since mid-2024 through in-app ads that led to fake app store sites. Those sites promoted Telegram X as a dating and video chat app.

The sites' banners were available only in Portuguese, for users in Brazil, and in Indonesian. Even so, Doctor Web's 2025 map of infected devices by country put India first, at 22.8%, ahead of Brazil at 20.5% and Indonesia at 9.6%.

Baohuo copies also turned up in the third-party stores APKPure, ApkSum and AndroidP. On APKPure, one was listed under the official developer's name, although its digital signature was different.

Ovi got access to one of the kit's command servers. It held data on victims apparently located in China and the United States, but not enough for a reliable count. He calls his report "an analysis of technical capability, not a measurement of victim impact."

The apparent targets, still unconfirmed, are users of mobile wallets and messaging apps in China and Southeast Asia, including WeCom, QQ, WhatsApp, LINE, Zalo, KakaoTalk, Viber, GCash and MoMo. He found code supporting about 20 apps, but has published code only for Telegram and WeChat.

The kit's hooking engine is the part that lets its code intercept an app's functions. Ovi checked it on a Pixel 10 Pro running Android 17. It could not find an internal Android function it relies on, because newer Android versions changed that function.

Another tool, Frida, could still hook apps the same way on that phone. Ovi therefore describes this as extra work for the kit's makers, not proof that Android 17 blocks the attack.

The newest sample, dated July 29, 2026, still carried the old engine. He recovered samples built for Android 16 but did not report testing that version. He has not tested phones from Chinese makers.

How It Takes Over a Telegram Account

Inside a tampered Telegram app, the kit's code starts with the app and runs with the app's own identity and permissions, Ovi found. That gives it the same access as the signed-in app.

Each tampered app also runs a local command server inside itself. The code for each target app is downloaded after installation, which makes the installer file harder to analyze on its own.

Attackers can send any database query to the app's message store and get chat history back.

Telegram's two-step verification (2FA) password is entered in the app, which uses it to generate a login proof on the phone. The kit hooks that step and copies the password in readable form before the app hashes it.

With the password, the code can reset the account's logged-in sessions, change the linked phone number, or delete the account. Other parts of the code are designed to lock out the owner while keeping the attacker's session alive.

The code can also hide the attacker's session from the device list that the tampered app shows the user.

Doctor Web's description of Baohuo covers the same device-hiding. The backdoor also sends the account's phone number, name and password to its server every three minutes.

Neither Ovi nor Doctor Web says whether a hidden session still appears on the user's other, untampered Telegram apps. Neither gives steps for securing an account taken over this way.

Ovi says the code shows what the kit can do, not that attackers have used every step from start to finish.

Earlier Android malware has also run legitimate apps with attacker code inside them. FjordPhantom did this to banking apps through virtualization in 2023, and so did the GodFather banking trojan in 2025.

Ovi argues the kit is different because it is sold as a product. Customers can steer it remotely against any app its makers write a module for.

The WeChat Part and the Leaked Back End

For WeChat, the kit can also use app virtualization, running the unchanged app inside its own container, Ovi found. A command copies out the account's login identity. The app's data is then zipped and uploaded, and a bundled login script is used to clone the account.

This part goes after the account itself, not its chat history.

Ovi and another researcher, Jurre, also found the back-end code behind the kit on a self-hosted GitLab server. It was the one part of the setup not limited to approved IP addresses.

The code shows a cloud console that merchants and resellers rent. Every command carries the customer's ID, so each customer aims its own share of the phone fleet at victims it picks.

Commands go to phones in the kit's phone farm, a set of phones the operation controls, and to victims' phones. There, the kit captures login authorizations, adds friends in bulk, collects contact and profile data, and backs up whole accounts.

A scheduler sets time windows, random daily limits, and per-account budgets, so the activity looks human and gets past the platforms' risk checks. The code calls this "account cultivation," in Ovi's translation.

About three dozen developers, all working on China time, appear in the code's history, and some were still adding changes in October 2026.

The leaked back end covers personal WeChat and WeCom accounts. Ovi says it did not appear to cover Telegram, and only one of several GitLab servers was exposed.

Who Is Behind It

Ovi ties parts of the operation to three companies in Hunan province, China. One is linked to the kit's brand website and a server certificate, another to a government website filing for a command server, and the third to the signature on the kit's Windows control program.

He says a shared owner is "plausible, but remains unproven."

The makers' own name for the product is YingGai, and the product line appears in records dating back to September 2021. The samples Ovi studied date from 2024 to July 2026.

Ovi assumes the kit is used for financially motivated crime, given its focus on wallets and one-time passcodes. Doctor Web described Baohuo as "a tool for boosting the number of subscribers in Telegram channels."

Indicators of Compromise

The kit leaves two traces on a phone that Ovi calls reliable. One is a code file, TgJarPine.dex, in the assets of some tampered Telegram copies. The other is the original app copy that LSPatch, an off-the-shelf patching tool, leaves at cache/lspatch/origin/*.apk.

Because that second trace comes from LSPatch itself, it can also appear in apps patched with the tool for other reasons.

When The Hacker News checked DNS records on October 23, 2026, several of the kit's server and download domains no longer resolved. The domain for its version-upload server still pointed to 121.37.194[.]194.

The kit's indicators include:

• SHA-256: 2fc4bad71eda25b9022ea7cb090d6419911ecd67e50e746b418f8a617a980301 (com.ucreator.tg, framework and command handlers)
• SHA-256: 0142749a159be3e41d28f910eebf28b577a282880bd0c2383bd7404189f4ff94 (com.uckj.tgx, loader)
• SHA-256: dcec9640271a782553599197bcb85367971a5bb4aa84c3787d1e49a3f4f9420e (org.thunderdog.challegram, tampered Telegram X, November 2024)
• SHA-256: 805834e6b8c12e180117a1816b48e387c33b53520f5a91cbf858441dc895e717 (org.telegram.messenger.web, tampered Telegram, July 2024)
• SHA-256: a90e3ab2b5cf306439a378faf7107a89196116ad7ee4ad5791c2ba8839ba21c4 (org.thunderdog.challegram, tampered Telegram X)
• SHA-256: f82ac2c525d1ed82e57b3f27ae689aeda46875a893ca4c42876b3166ba66bb20 (com.ucreator.va_vx, WeChat host)
• SHA-256: 99c5be579d218acfd2c7e2662528e7ad32a1a605d8efd1da732c13931bc30c4c (com.ucreator.va_yjb_client, Onion Box)
• SHA-256: 9c8b147f76312e651faabb1411a3270efca984dd8f33bd8ded3ea611c7c583a1 (uip.exe, Windows control program)
• Domain: hpncallback.gold5play[.]com (command server, not resolving on October 23)
• Domain: hpncallback.qianxunlbs[.]com (command server, not resolving on October 23)
• Domain: telegram-apk.uzyzx[.]com (download host, not resolving on October 23)
• Domain: hw.android.videoflow[.]cn (version uploads, pointing to 121.37.194[.]194 on October 23)
• IP: 159.138.237[.]10:32115 (Redis server)
• IP: 159.138.229[.]12:26379 (Redis server)
• Domain: r-bp1jehsclgbuu48m7tpd.redis.rds.aliyuncs[.]com:65531 (Redis server, WeChat part)
• IP: 43.225.141[.]209 (relay used by the Telegram part)
• URL: kfpt.oss-cn-hangzhou.aliyuncs[.]com/android/app/YingGai/ (hook downloads)

Doctor Web has published its own indicators for Baohuo.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/xvdasHV
via IFTTT

Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs

An automated campaign is using stolen GitHub tokens to plant workflows that print a repository's secrets into its GitHub Actions logs, which the attackers then download before deleting the runs. The attacks have succeeded in private repositories and GitHub Enterprise environments, according to an analysis by cloud security company Wiz.

A GitHub safeguard that pauses suspicious workflow runs stopped every public-repository run Wiz checked, but it does not cover private repositories or GitHub Enterprise Server.

Each workflow sits on a new branch named ci-sync- followed by six random characters. Deleting a branch, or the run it started, does not undo the exposure. Every secret the repository could read should be rotated, and the token that pushed the branch revoked.

Wiz has tracked the campaign since September 15 and calls it Gheist, after the user agent gheist that the attackers' tool sends with GitHub API requests.

Wiz has recovered more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to the private repositories of enterprise organizations. Wiz's analysis does not say how many organizations had secrets exposed.

In private repositories and on GitHub Enterprise Server, GitHub audit logs show runs on the planted branches finishing and then being deleted by the gheist user agent. AWS CloudTrail logs show the organization's own workflows also running on those branches and assuming AWS roles, a sign that GitHub Actions ran there without approval.

In enterprise organizations, the tool cycled through tokens from several users and automation accounts within minutes and cloned private repositories before planting the workflow. Hours later, cloud credentials from the same organization were used to enumerate AWS Secrets Manager. Wiz's analysis does not say where those credentials came from or who used them.

As of October 24, the campaign was still running and changing. About two-thirds of the accounts involved were no longer available on GitHub. Wiz reported the activity to GitHub and says their disappearance likely reflects a response.

Anyone with write access to a GitHub repository can read every secret configured in it, according to GitHub's documentation. A stolen token with that access is enough.

For each repository a token can reach, the tool creates a ci-sync- branch and commits one file, .github/workflows/sync-check.yml, with the message ci: sync config. The commit is unsigned and includes the token owner's name; pushing it starts the workflow.

The workflow prints the job's environment and every secret the job can read, encoded in base32. GitHub masks secrets in logs, but its documentation says this is not guaranteed once a value has been encoded or otherwise changed. Wiz says the base32 text no longer matches the original secret, so it prints in full.

The workflow sets an empty permissions block. That limits the job's GITHUB_TOKEN, which the attackers do not need, and does not stop the job from reading secrets.

One version of the tool also runs a job for each deployment environment in the repository, so secrets limited to those environments print too. These are often production credentials, according to Wiz.

The tool then downloads the log through GitHub's API and deletes the run seconds later. Because the secrets leave through GitHub itself, there is no attacker server or outbound connection to block.

Since July 28, GitHub has held workflow runs it identifies as potentially malicious until a collaborator with write access approves them. GitHub says the hold "currently applies to public repositories on github.com only" and that GitHub Enterprise Server does not have it at this time.

Every public Gheist run Wiz checked, across all versions of the tool, was still waiting for approval, so its payload never ran.

The hold only catches runs that GitHub flags. A new variant of GhostAction, a separate campaign, ran in public repositories until GitHub began blocking it on October 9, according to research from security company GitGuardian. Wiz says Gheist is distinct from GhostAction, which uses different workflow files.

Around October 19, one version of the tool began pushing a second job meant for self-hosted runners, the machines organizations run themselves to process GitHub Actions jobs. It appears to target only repositories that have such a runner registered.

The job is written to search the runner machine for credentials, including 31 types of tokens: private keys, process environments, AWS instance role credentials, runner credential files, and the Kubernetes service account token. Wiz describes the job as buggy, and its analysis reports no successful run.

The sources Wiz could trace for the stolen tokens include infostealer logs and tokens exposed in earlier supply-chain attacks, such as the March compromise of the Trivy vulnerability scanner.

Other attackers also use the same accounts. On October 6, 391 accounts, many of them also used by Gheist, renamed about 1,461 repositories to appear to be cracked software and spread malware. The renaming wiped 610 of the planted branches.

Some victims also appear to be infected with PolinRider, malware that researchers have linked to North Korea. On October 19 and 20, three of them re-pushed their Gheist commits with a loader added to a vite.config.js file.

Megalodon, a campaign that pushed secret-stealing workflows into thousands of GitHub repositories in May, had also hit 57 of the accounts.

How to Check Your Repositories

Wiz recommends these checks:

• Look for branches named ci-sync- followed by six characters, where the only change is a new .github/workflows/sync-check.yml file with the commit message ci: sync config.
• In GitHub audit logs, look for workflow runs on ci-sync-* branches that were deleted within a minute of finishing, and for any activity from the user agent gheist.
• If your workflows sign in to a cloud provider with OIDC, check cloud audit logs for role assumptions or token exchanges whose subject includes a ci-sync- branch. This works even if you do not collect GitHub logs.
• On self-hosted runners, look for the files .gdmp_pat, .gdmp_patg and .gdmp_sweep, and the string gdmp-pivot in job logs.

OIDC lets workflows sign in with short-lived tokens instead of stored cloud keys. By default, a token's subject includes the branch name only when the job does not use a deployment environment, according to GitHub's OIDC documentation.

The published indicators are:

• User agent: gheist
• Branch: ^ci-sync-[0-9a-z]{6}$
• Commit message: ci: sync config, adding only .github/workflows/sync-check.yml
• String: toJSON(secrets) }}' | base32 -w 120
• String: ===== gdmp-pivot:
• File: .gdmp_pat
• File: .gdmp_patg
• File: .gdmp_sweep
• Git blob SHA (plain workflow): f3da2b8b357dcda02fd455d314be2a95007516a6
• Git blob SHA (timeout version): d09535857a741bbb976bdc084a9a021713133291
• Git blob SHA (separator version): 1dc5af9cce950aad1eb1546ecce8565b117540c4
• Git blob SHA (self-hosted job version): c665b778b2d822453293003e7ca0bbb2cb08e39d

Versions of the workflow that list a repository's deployment environments vary by repository, so they have no fixed hash.

What to Do If You Find a ci-sync Branch

Wiz advises these steps for an affected repository:

• Rotate every repository, organization, and environment secret the repository could use.
• Revoke the tokens that pushed the commits, and check their owners' devices for infostealers.
• If a ci-sync branch ran on a self-hosted runner, treat the machine and its cloud instance role as compromised.
• Do not approve held sync-check runs, and do not run code from ci-sync branches.

To make a stolen token less useful, Wiz also recommends these steps:

• Require reviewers on environments that hold production secrets.
• Limit OIDC trust policies to protected branches or environments.
• Use GitHub Apps or short-lived fine-grained tokens instead of personal access tokens.
• Run self-hosted runners as short-lived machines without Docker socket access or open access to cloud metadata.

A job cannot read an environment's secrets until a required reviewer approves it, according to GitHub's documentation.

from The Hacker News https://ift.tt/AI5aBm7
via IFTTT