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

Malicious File in Downloads Folder Tries to Trick AI Coding Agent Into Installing Malware

A malicious instruction file sitting in a developer's Downloads folder tried to make their AI coding agent install a known-malicious npm package, security firm Forever Security said in a report published last week.

The company caught the attempt on a real customer's machine and stopped the agent before any code ran. It could not determine how the file got into the folder.

The file was AGENTS.md, a plain-text instructions file that a coding agent, such as OpenAI's Codex, reads when it starts in a folder and follows as directions.

It was dressed up as ordinary engineering notes. One section told the agent to add a server to its own configuration and install a package called function-color from npm.

That package is part of a malware campaign that other researchers have documented separately: function-color pulls in a downloader called function-flag, which fetches and runs a Windows payload. Researchers at CloudSEK and Checkmarx, who analyzed the campaign, named it MALFEX.

Two things, each harmless on its own, make this work, Forever said. An agent is built to trust and obey the instructions file in the folder it opens. And a web page can save a file to the Downloads folder on its own, without a click or a permission prompt, choosing the name and contents. Put together, a web page can drop a file the agent will treat as orders into a folder the agent trusts.

Researchers did not establish that this is how the file was caught. To test whether the full path was possible, it built its own proof-of-concept page: visit it, and an AGENTS.md downloads silently into Downloads. Whether a real attacker used that route against the customer is not known.

The firm then reproduced the attack on two coding agents to show that it was not specific to a single product. Against Codex, it ran the real attacker file inside an isolated virtual machine. The file, framed as routine project setup, told Codex to register a server in ~/.codex/config.toml and run a command that installed the package.

Because that config file applies to every Codex session on the machine, the change would load the attacker's server in any folder afterward, not just Downloads. Codex ran the malware in more than 90% of attempts, Forever said.

Against Claude Code, the working attack looked different and succeeded less often. A planted CLAUDE.md, framed as internal gateway setup, tried to make Claude write an ANTHROPIC_BASE_URL into a project settings file, pointing its API traffic at a server Forever controlled. That one change leaks the session's login token, which is account takeover on its own, and lets the server reply as if it were the model and hand back commands the agent runs.

Claude needs a person to approve a write like that and often refuses one that looks wrong; the long engineering-doc framing got the write approved about half the time, researchers said.

There is nothing for OpenAI or Anthropic to patch, in Forever's view, because an agent following the instructions file in its folder is doing what it was built to do. The company compared it to a browser rendering a phishing page: the browser worked as designed, and the attack lies in the page. "There is nothing here for OpenAI or Anthropic to patch," Forever said.

What to do

Forever's advice is practical and needs no product:

• Do not start Codex, Claude Code, or any agent in ~/Downloads. It is the one folder the web can write to on its own.
• Look for instructions files you did not write. A stray AGENTS.md or CLAUDE.md, in Downloads or in a repository you just cloned, is the whole attack. Read it before you let an agent near it.
• Check the agent's own config. In ~/.codex/config.toml, watch for a server block or a changed base URL you did not add. In a project's .claude/settings.json, watch for an ANTHROPIC_BASE_URL or other API endpoint you did not set.
• Leave approval prompts and sandboxes on, and be wary of anything that tells the agent to switch them off.
• If you find a planted file, assume the login token leaked and rotate it. A stolen token is a live session, not just one caught request.

In its own telemetry, Forever said that about half of its customers run a coding agent in their Downloads folder, and roughly a quarter of agent sessions open a browser.

Those are the conditions the attack needs: an agent starts where the web can write, and, in many cases, an agent does the browsing itself, so no person is watching when a file arrives.

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

PHP2Shell Exploitation Hits Government Entity Amid Global Scanning and Signs of AI-Assisted Hacking

Threat actors have been observed using agentic artificial intelligence (AI) platforms for post-exploitation activity following the abuse of the PHP2Shell vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619.

"In one case, the attackers targeted a government entity in Europe and within two hours of the initial exploitation they had successfully accessed password hashes and multi-factor authentication secrets," Palo Alto Networks Unit 42 said.

"They also established an NT LAN Manager (NTLM)-relay tunnel into Active Directory and attempted Domain Admin privilege escalation."

The network security company said it also observed the unknown attacker enumerating the compromised endpoint, with commands and behavioral markers suggesting the work of an agentic attacker. These include commands to facilitate -

Reconnaissance of the authentication database with stolen credentials, targeting password hashes and two-factor authentication (2FA) secrets.

Active Directory (AD) reconnaissance via curl-based anonymous LDAP queries to the domain controller (DC) in an attempt to look for the administrator account.

Reconnaissance of the host to hunt for DNS/AD integration, internal hosts, privileged groups, and interactive users.

"Each command batch is wrapped in section-header delimiters, such as ==SHELLUSER== and ==PASSWD==," it added. "These delimiters produce machine-parseable output for an AI model to read."

Suspected N. Korea Campaign Targets PHP2Shell

The disclosure comes as CYFIRMA said it uncovered a suspected North Korea-linked campaign employing PHP2Shell to actively probe global PHP infrastructure from 21 compromised nodes.

"The scanning is deliberately low-volume and paced," Kumar Ritesh, CEO and founder of CYFIRMA, told The Hacker News. "Nodes are rotated and abandoned at the first sign of blocking or rate-limiting, so threshold-based alerting is unlikely to catch it."

The targets comprise a set of 216 unpatched or partially mitigated hosts located across the U.S., Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the U.A.E., Saudi Arabia, and the E.U. The hosts span government, financial institutions, logistics, airports and aviation, manufacturing, and online transaction platforms.

"The campaign has moved from reconnaissance into active, low-and-slow scanning of a filtered target set," CYFIRMA said. "Organizations in the prioritised sectors and geographies should assume they are in scope for deliberate targeting."

The activity, coordinated via a closed I2P channel, has been attributed with moderate confidence to a Korean-speaking operator assessed to be affiliated with the Lazarus Group ecosystem. According to CYFIRMA, the two handles (전창혁 2 aka Jeon Chang-hyuk 2) and (최아린 aka Choi A-rin) active in the I2P channel have previously been observed running covert operations for the threat actors.

"Korean-speaking operators have used [the channel] to share target lists, exploit-hosting infrastructure, and tasking and prioritisation consistent with DPRK objectives," Ritesh said. "The captured conversation uses vocabulary and spelling specific to North Korean (Munhwaŏ) rather than the South Korean standard."

Other primary indicators that link the campaign to the Lazarus cluster are below -

• Command-and-control (C2) infrastructure that Lazarus has previously used to exploit web assets.
• Lazarus Group's documented history of compromising PHP and WordPress servers for C2 and planting of PHP and ASP web shells, as observed in the SyncHole watering hole campaign.
• Prioritizing government agencies and banks, specifically online transaction platforms, which is in line with Lazarus Group's track record of breaching financial institutions for financial and cryptocurrency theft.

"Exploitation is the next step," CYFIRMA said. "The operators said they would shortlist the most promising targets the same day and then choose which public exploits to adapt."

Other Exploit Efforts and Mitigations

In an October 25, 2026, post shared on X, Defused Cyber said it's also seeing PHP2Shell probes targeting its Palo Alto Networks GlobalProtect honeypots. The activity originates from 204.76.203[.]7, a known mass-exploit IP address.

"The requests carry a PHP_SESSION_UPLOAD_PROGRESS marker ('p2s-rider') and a dummy file upload with no payload, which points to someone checking for the vulnerable upload-progress behavior and likely building a target list of Palo Alto devices," the threat intelligence company said.

Both CVE-2026-109618 and CVE-2026-109619 are critical vulnerabilities that can lead to remote code execution in default PHP configurations. The security flaws have witnessed widespread scanning efforts, with Cloudflare stating it detected millions of exploitation attempts after public disclosure.

"An attacker faces two main constraints: they must size a request to fail allocation at the right moment, and they must defeat ASLR to find valid memory addresses," Datadog said. "The exploit needs one field name small enough to fit inside the accepted request body but large enough that copying its key exceeds memory_limit."

"When PHP parses a form-field name, it makes several copies along the way. The attacker uses that extra memory to force an allocation failure while PHP copies the name into a hash table."

ReliaQuest, in an update published on October 22, 2026, said it reproduced CVE-2026-109618 in a controlled lab and observed a sequence of errors that could help defenders identify exploitation.

"This testing identified a specific sequence of artifacts across PHP error, Apache access, Apache error, and system logs that may help defenders detect exploitation," it said. "Defenders should focus on the sequence: a POST request returns a 500 error, PHP reports memory exhaustion and heap corruption, and the Apache worker handling the request crashes."

The PHP Foundation has since warned of a third remote code execution vulnerability (CVE-2026-115560), which can only "occur under an unusual combination of configuration and application code." The issue is expected to be addressed as part of the regular release cycle.

"An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start()," the Foundation said. "Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled."

Xint has released a scanner to check if a host is exposed to PHP2Shell, stating remote code execution is possible in any PHP script regardless of the application and in applications where decoding occurs, such as with session_start() and unserialize().

Bitsight's internet-wide scans show that there are nearly 37 million internet-facing systems running PHP or PHP-related software, with most of the exposures in the U.S., Germany, France, the Netherlands, and Japan.

"PHP runs a very large portion of the web, from content management systems and online shops to bespoke internal tools," Bitsight said. "A flaw in the runtime can't be repaired by changing application code, and a web application firewall or plugin update won’t remove it. Only updating PHP on the host itself closes the gap."

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

Confidence or Con? The Psychology of Tech’s Boldest Leaders

Brian and Brandon take a detour from the usual tech news to ask a question every enterprise buyer of AI should be asking: why do some of tech’s most celebrated leaders project absolute confidence in claims that later prove false? Starting from the new Elizabeth Holmes documentary, they debate whether that kind of conviction is innate or learned. Brian argues it develops in stages, as each funding round and glowing press profile ties a founder’s identity more tightly to a story they must defend at all costs. Brandon describes a “contrarian effect,” in which a venture model with low hit rates rewards bold founders and tells them they are special. He recommends The Halo Effect as an antidote to success stories that confuse correlation with causation. They also question the VC preference for founders with hardship backstories. The conversation closes on Brandon’s framework of operators, believers, and pragmatists, and why every organization needs pragmatists willing to question big promises before they become fiction.

SHOW: 1074

SHOW TRANSCRIPT: The Enterprise AI Show #1074 Transcript

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

SHOW SPONSORS:

• Nord Security - NordLayer AI Scout 

SHOW LINKS

• The Enterprise AI Show

GUEST BIO

N/A this week

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/uQAE5C0
via IFTTT

OpenAI AI Agents Demonstrate VM Escapes and Secret Cross-Sandbox Communication

OpenAI has announced plans to conduct frontier model training with no live internet access, as it resumes reinforcement learning (RL) training and internal inference of its most advanced AI models.

"Based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, we believe the responsible approach is to conduct frontier model training with no internet access," the artificial intelligence (AI) company said. "We've implemented this policy and will maintain it until advances in these safeguards justify broader internet access."

OpenAI said models' growing capabilities can have the side effect of them getting much better at devising ways around environmental restrictions to escape containment and perform unintended actions. This can involve the model exploiting a software flaw or misconfiguration to reach the live internet, or finding unauthorized ways to communicate with agents in other sandboxes.

Late last month, the Frontier Lab made the decision to pause training of its most powerful models after one of its agents during reinforcement learning (RL) training contacted an external chatbot by exploiting a misconfiguration in a DNS resolver to obtain limited internet access.

OpenAI said it also kicked off a "high-compute red-teaming campaign" to test the resilience of its research and evaluation environments in the face of increasingly powerful models, leading to the discovery of previously unknown software vulnerabilities, including a critical unauthenticated remote code execution in Google Brotli (CVE-2026-111497, CVSS score: 9.2), a widely used compression library.

Patches for the vulnerability, also called Node2Shell and HTTP2Shell, have since been released for libbrotli, Python, C++, Node.js, Bun, Envoy, and Istio.

The red-teaming agents OpenAI dispatched to test its security safeguards also uncovered virtual machine escapes, novel paths to access the internet through vulnerabilities in metrics, logging, and authentication management services, and hardware side-channels for communication between agents, bypassing isolation boundaries.

"In one test that assumed compromise of a host machine, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in our metrics service and then made that endpoint fetch a model-provided URL," it said. "In other tests, agents exploited misconfigurations that allowed blocked requests to pass through DNS and firewall controls, as well as ways to make services we run fetch external URLs."

In another experiment, after prompting the AI agents in separate microVMs to exchange synthetic secrets without relying on network connections or shared writable files, OpenAI said the digital bots found a way to communicate using the processor's cache via a timing-based side-channel.

Particularly, one agent is said to have encoded information by evicting selected data from the cache. A second agent measured the time it took to reload that data, leveraging the difference between fast and slow cache reads to recover the message.

"Once the agents agreed on a protocol for encoding and decoding these signals, they could exchange the synthetic secrets without changing a shared file or opening a network connection," OpenAI said.

The AI giant said the discoveries prompted it to strengthen its own safety and monitoring mechanisms and deem them sufficient enough to restart frontier RL training and internal inference, while continuing to invest in several key areas -

• Improving virtual machine security
• Probing cloud infrastructure for weaknesses
• Scanning source code and cloud configurations
• Testing monitoring and stopping systems
• Red-teaming sandbox and isolation guarantees

"After strengthening our containment architecture, we resumed our frontier RL training and inference on October 1," OpenAI said. "We've reserved substantial compute for continuous red-teaming, and made high-compute red-teaming part of the safety cases we use to decide whether frontier training and evaluation can proceed securely."

Earlier this month, Anthropic said it was cutting off live internet access for all its internal evaluations until further notice after discovering new incidents in which its AI models exhibited misaligned behavior and targeted real websites.

The disclosure comes as concerns have been raised over the ability of AI agents to detect and exploit software flaws, even in the guardrails designed to restrict them.

In a report published this week, third-party AI ​safety evaluators METR ⁠and Redwood Research said they found several new vulnerabilities in OpenAI's internal misalignment monitoring system as it existed before July 21, 2026, and during the time frame when the company's agents broke into model-hosting platform Hugging Face.

"We found a way Codex agents could in principle bypass Codex sandboxing and Auto-Review, allowing them to take any action that the host user could take," researchers David Rein and Adam Kaufman said. "We also discovered an exploit agents could use that would prevent hundreds of recent actions (including the actions involved in the exploit itself) from being monitored."

OpenAI is believed to have addressed all of the vulnerabilities affecting its production safeguards stack, although the safety organizations said they had not verified the fixes.

Anthropic's Mythos 5 Pursues an Unsanctioned Supply Chain Attack

The developments also coincide with a report from the U.K. AI Security Institute (AISI), which has found Anthropic's Mythos 5 model to be consistently taking unsanctioned actions even when presented with evidence that doing so would be out-of-scope and cause real harm (e.g., submitting a malicious code change).

The evaluation also revealed that the Mythos 5's chain-of-thought (CoT) reasoning process failed to consider the impact of harmful actions, with the model often producing invalid justifications that implied the target was simulated when asked if the human maintainer was real, but never generating incorrect justifications implying that it was real.

"Most models tested take a range of unsanctioned actions during simulated cybersecurity evaluations, Mythos 5 most frequently," AISI said. "Taken together, these observations could indicate that models are engaging in 'motivated reasoning': producing inferences and reasoning biased towards conclusions that justify continuing a particular approach to task completion."

In the most severe case, the model has been found to attempt a supply chain attack by submitting malicious code and creating five sock-puppet accounts to vouch for the changes and pressure a software maintainer into accepting it.

Responding to the findings, Anthropic has attributed the alignment failures to recklessness, biased reasoning, and an urge to "continue on its current trajectory" to a degree that disregards potential harm. The OpenAI rival also noted that its newer models, including an internal research model, are less susceptible to this behavior.

"Nevertheless, this incident serves as further evidence that current AI models are capable of surprisingly misaligned behavior in evaluation settings," it said. "We've built new evaluations that we run on new production models automatically, and we are specifically studying biased reasoning to better understand where it comes from in our training and how it affects our models."

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