Malvertising Sends Malware in Pieces, Then Makes the Browser Build the Executable

A malvertising operation dubbed SourTrade is making victims' browsers build the final Windows executable themselves, using a legitimate Bun runtime as its base instead of serving one complete malicious file from a fixed URL.

Confiant, which detailed the campaign on July 23, 2026, said it has operated since late 2024 and impersonated TradingView, Solana, and Luno to target retail traders and cryptocurrency investors across 12 countries in 25 languages.

Its landing pages fingerprint visitors, showing suspected researchers and bots an empty page while selected targets receive a convincing copy of the impersonated service. The defense against that is the ordinary one: install trading and wallet software from the vendor's own site, not from an ad.

The documented chain does not rely on a browser vulnerability or remove Mark of the Web (MotW). Confiant's analysis documents the delivery, not execution of the file inside the browser, and does not establish whether the final download starts automatically or requires a click.

The landing page begins preparing the delivery path without waiting for a download click. It registers a page-scoped ServiceWorker at /sw.js, then builds a SharedWorker from JavaScript already embedded in the page, so the worker source never appears as a separate fetch.

The SharedWorker requests /config, which returns a template, a secondary runtime URL, and session-specific random values. The browser retrieves and decompresses a clean Bun runtime from that second domain, purelogicbox[.]org in the published sample response.

Base64 blobs in the configuration supply the Portable Executable (PE) header, section table, and a .bun section containing malicious JavaScriptCore bytecode for app.js. Bun runs on Apple's JavaScriptCore engine and legitimately supports compiling applications and bytecode into standalone Windows executables.

The worker then generates a large pseudorandom byte stream using AES in counter mode (AES-CTR). It then follows the supplied template as a byte-copy recipe, combining selected ranges from the Bun runtime, the generated stream, and the attacker-controlled executable material.

Each victim can receive a different assembled file: rotating the seed and size in each /config response changes the hash while retaining the executable payload code. "No finished malware ever exists on the network," wrote Michael Steele of Confiant's threat intelligence team. No complete binary does, though the PE structures and the bytecode arrive as Base64 in /config.

Once assembled, the page passes the executable to the ServiceWorker as a readable stream. A hidden iframe navigates to a same-origin URL, and the worker returns the generated bytes with a Content-Disposition attachment header. The resulting MotW record identifies the landing page as the download source, not the separate domain that supplied the Bun runtime. MotW itself remains present.

The method evolved from activity Confiant tracked through April 30, 2026, when the pages loaded StreamSaver.js, an open-source streamed-download library, from its author's GitHub Pages address. That left the recorded download path pointing at the library's GitHub URL. The current pages keep its streaming architecture, including the streamsaver: message names, but no longer fetch it from GitHub.

Bitdefender documented the related TradingView malvertising cluster in September 2025, identifying its final payload as the stealer Check Point tracks as JSCEAL and WithSecure as WeevilProxy.

Confiant identifies shared campaign and executable characteristics but does not demonstrate that the three published samples carry that payload. The report also says Bitdefender found a modified Bun executable in this cluster.

The Hacker News found no mention of Bun in the September 2025 post Confiant links to, which names its loader detection Variant.DenoSnoop.Marte.1. Credential theft, keylogging, traffic interception, wallet theft, and remote-access capabilities documented in the earlier campaign therefore cannot yet be assigned to the current files.

The Hacker News has reached out to Confiant for clarification on its reference to Bitdefender's earlier findings and will update this story with any response.

There is no software patch to apply. The evasion is narrower than it first looks. Confiant's own practical-implications section puts it more modestly: unique per-session builds limit the value of simple hash-based detections. The attacker-controlled PE material and bytecode still cross the network.

Defenders should examine the whole chain, from the ad referral and cloaked landing page through the /config request, the secondary-domain runtime fetch, and the ServiceWorker download, rather than treating any single network or file artifact as decisive.

Confiant published three SHA-256 hashes and a list of malicious domains, 96 by The Hacker News' count. The firm named no actor and stopped its analysis at the moment the file lands on disk.

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

Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patched Available

Security firms ThreatBook and Imperva say attackers are targeting a critical flaw in Fastjson, Alibaba's JSON library for Java. In affected Spring Boot applications, a malicious JSON request can execute code without authentication, with the privileges of the Java process.

Tracked as CVE-2026-16723, the vulnerability carries an Alibaba-assigned CVSS score of 9.0. The confirmed chain requires Fastjson 1.2.68 through 1.2.83, a Spring Boot executable fat-JAR, a network-reachable path that sends attacker-controlled JSON to an affected parser, and SafeMode left at its disabled default. AutoType can remain disabled, and no classpath gadget is required.

As of July 25, Alibaba had not released a fixed Fastjson 1.x version. Organizations that cannot migrate immediately should enable SafeMode with -Dfastjson.parser.safeMode=true or use com.alibaba:fastjson:1.2.83_noneautotype. Alibaba lists migration to Fastjson2 as the long-term fix.

Alibaba published its advisory on July 21 following responsible disclosure by Kirill Firsov of FearsOff Cybersecurity. The maintainers described the vulnerability as requiring "no AutoType enablement" and "no classpath gadget." They verified the chain on Spring Boot 2.x, 3.x, and 4.x with JDK 8, 11, 17, and 21.

Firsov traced the issue to Fastjson's type-resolution path. An attacker-controlled @type value can be turned into a class-resource lookup. In a compatible Spring Boot fat-JAR, a crafted nested JAR path can fetch attacker-controlled bytecode. An @JSONType annotation in that resource can then be treated as a trust signal, allowing the class to pass Fastjson's type checks and load.

His technical analysis also describes a newer-JDK path that downloads a remote JAR and references it through /proc/self/fd.

The exploit depends on the Spring Boot executable fat-JAR loader. Alibaba lists plain non-fat JARs, generic uber-JARs, and Tomcat or Jetty WAR deployments as unaffected. Reachable entry points include JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class). Binding input to a fixed class is not sufficient when an object contains an Object or Map field where the payload can be nested.

ThreatBook said on July 22 that its platform had captured in-the-wild exploitation after adding detection support two days earlier. Its laboratory results were narrower: it reproduced full code execution in a Spring Boot fat-JAR on JDK 8, while its embedded Tomcat test produced only a remote JAR fetch or server-side request forgery.

Imperva reported activity against financial services, healthcare, computing, retail, and other organizations, primarily in the United States, with smaller volumes in Singapore and Canada. It said browser impersonators generated most requests, while Ruby and Go tools represented about 30% collectively.

Neither vendor published attack counts, raw requests, execution evidence, named victims, or confirmed compromises. Their reports establish observed exploit activity, not proof of successful code execution against a real-world target or a breach.

A July 23 CISA-ADP assessment nevertheless marked exploitation as none. The Hacker News confirmed on July 25 that the flaw was absent from CISA's current Known Exploited Vulnerabilities catalog. The available sources do not explain the mismatch.

The Hacker News also found no patched Fastjson 1.x artifact in the project's GitHub tags or Maven Central repository as of July 25. Version 1.2.83 remains the latest standard 1.x release, while 1.2.83_noneautotype remains the available restricted build.

Organizations should inventory direct and transitive Fastjson dependencies and inspect affected systems for suspicious @type values, nested JAR URLs, unexpected outbound connections, child processes, file changes, and web shells. Fastjson2 is not affected because it does not use the same resource-probing or annotation-based trust path.

The Hacker News has reached out to Alibaba for clarification on the affected versions and Fastjson 1.x patch plans, and to Imperva for details about the reported exploitation activity. We will update the story with any response.

Fastjson 1.2.83 was Alibaba's recommended upgrade for a separate AutoType bypass disclosed in 2022. That final 1.x release now sits inside the affected range for CVE-2026-16723.

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

DevMan RaaS Portal Centralizes Payload Builds, Victim Management, and Affiliate Payouts

The operators of the DevMan ransomware-as-a-service (RaaS) scheme are maintaining a dedicated web platform that offers affiliates the ability to build payloads, oversee earnings, and manage various aspects related to victims.

Swiss cybersecurity company PRODAFT is tracking the centrally administered RaaS operation under the name Funky Mantis.

"The portal combined build generation, finance, victim chat, support, victim records, teams, and payout functions," the company said in an extensive report shared with The Hacker News.

"The service integrated access brokerage or access distribution with ransomware deployment. Administrators offered country-specific 'networks,' asked whether an affiliate would use personal or program-supplied access, and imposed two-to-three-day completion windows."

Various analyses show that DevMan first emerged on the scene in April 2025 as an affiliate for Qilin, DragonForce, Apos, and RansomHub, before shifting to their own RaaS operation. The locker's DNA is "unmistakably DragonForce," Vectra AI noted back in October 2025, highlighting the ransomware's shared lineage.

In an interview with security researcher Jon DiMaggio published in October 2025, DevMan acknowledged that they worked with Conti and claimed they had developed a "specialized SCADA locker" to target an unnamed gas company that was designed to inflict progressive physical damage beyond encryption.

Per the threat actor, the malware would "push industrial control systems beyond their operating parameters, processors, memory, and thermal limits, forcing systems to ramp up and run hot until hardware failed."

"The threat actor is operating with a high-profile online presence and updating about developments, updates and general statements mainly in English and sometimes in Russian as well," the Israel National Cyber Directorate (INCD) said in a bulletin released last year. "They often 'brag' about their achievements, to the point where they post write-ups that describe the way they gained access and performed the attack."

DevMan's operations suffered a hit in June 2025 after a mysterious whistleblower calling themselves GangExposed publicly doxxed operator identities, causing a few affiliates to abandon the operation. DevMan also alleged that GangExposed attempted to extort them for 0.3 to 1 Bitcoin during their Telegram interactions.

According to statistics on Ransomware.Live, the group has claimed 184 victims to date, with no new victims reported after February 4, 2026. Nearly 50 victims are located in the U.S., with technology, healthcare, financial services, professional services, and government sectors accounting for the most targeted.

The affiliate portal associated with the operation, which originally revolved around builders, finance, victim chat, and help desk functions, has since received an upgrade. The third version ("v3) of the platform released in January 2026 comes with support for structured victim records, life cycle states, team creation, invitation controls, per-victim build options, deadline tracking, revenue fields, and shared operational access.

"This progression indicates an effort to formalize affiliate workflows and manage multiple intrusions through a common platform rather than relying only on chat-based coordination," PRODAFT said.

The cybersecurity company has identified five distinct roles within the DevMan operations -

• LARVA-367 - Administrator/owner and central coordinator
• LARVA-546 - Access coordinator named as an alternative point of contact for network access
• LARVA-547 - Senior operator
• LARVA-548 - Senior operator or coordinator
• LARVA-550 - Affiliate/operator who was credited for an installation in an actor-controlled group message

"Affiliates were added to corporate chat after producing a first victim and were assigned an experienced curator," PRODAFT said. "They could be removed after one month without a new victim. Team formation and disclosure of program affiliation required curator approval, which limited independent coordination and public association with the service."

The core management also reserves the right to take over a conversation if an affiliate behaves inappropriately or fails to adhere to a commitment. The governance model reduces affiliate autonomy, while giving the administrators the power to enforce operational tempo and protect their revenue.

The illicit proceeds obtained after successful extortion follow an 80-20% split, allowing the affiliate to earn a chunk of the profits. The v3 platform rules state that the ransom funds are sent to two wallets, one for the affiliate and one linked to the RaaS program.

DevMan's stated targeting policy allows affiliates to strike entities outside the CIS countries and Serbia. It also excludes CIS consulates and CIS-linked companies, and lifts a previous restriction on Saudi Arabia. Besides explicitly encouraging attacks against critical infrastructure, it instructs affiliates to request a separate encryptor for SCADA systems, corroborating their development on a specialized SCADA locker.

However, the policy forbids affiliates from attacking child-related healthcare businesses and intentional leaks of personal data belonging to people under the age of 18.

The latest version of the portal allows affiliates to create a locker for Windows, ESXi, or Linux. An analysis of the Windows version has identified functions related to privilege checking to determine if it's running as an administrator, security-control impairment, process and service termination, recovery inhibition, event log clearing, local and network-share discovery, lateral movement, multi-threaded encryption, ransom-note creation, and optional self-deletion.

The locker encrypts files with ChaCha20-Poly1305. Files up to and including 3 MiB are fully encrypted, while those above the threshold are partially encrypted by processing a 1 MiB chunk every 51 MiB.

"Organizations should prohibit service and backup accounts from interactive VPN login unless a documented operational requirement exists," PRODAFT said. "Remote access and privileged administration should use phishing-resistant MFA. Teams should rotate credentials exposed to VPN appliances, LDAP integrations, scripts, and backup tooling, with priority given to secrets that can grant local or domain administrative access."

Huntress Faces Insider Threat Allegations

The disclosure also comes at a time when Ben Folland, a former employee of security firm Huntress, accused another analyst of passing communications from U.S. law enforcement to DevMan. The incident is said to have taken place in December 2025.

In a subsequent blog post, Huntress CEO Kyle Hanslovan said the company is aware of "questionable, long-term threat actor communications" between a threat researcher who is still employed with the security firm and a cybercriminal, calling it "poor judgement."

"In one particular exchange, our current teammate disclosed to a threat actor that law enforcement had reached out to them about the threat actor," Hanslovan said. "While this disclosure was not illegal, it reflected poor judgment."

"As a result of the investigation, my team implemented more robust policies for our researchers, coached teammates on engaging with threat actors, and took appropriate administrative actions. While we haven't found evidence of illegal conduct, insider activity, or additional disclosures, we are continuing our investigation."

Holland, however, has disagreed with the assessment, stating that the employee's actions "meet the definition of an insider threat." The ex-Huntress employee also questioned Huntress if the analyst was permitted to engage with DevMan to "support active investigations."

Per Folland, the U.S. Federal Bureau of Investigation (FBI) is said to have contacted the Huntress employee to gather intelligence on DevMan. "She immediately forwarded the exact FBI communications to the threat actor, including screenshots containing FBI agent names," Folland said. "She informed DevMan that law enforcement was actively looking into him. She also refused to cooperate because they wanted DevMan."

"This was not just 'poor judgment,'" Folland continued. "This was a Huntress employee taking sensitive knowledge about a law enforcement approach and passing it directly to the person being investigated. If someone inside a bank warns a fraudster that police are investigating them, nobody would describe that as merely 'poor judgment.' They would call it what it is - an insider."

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

Researcher Publishes GitLab RCE PoC Letting Authenticated Users Run Commands as Git

Security researcher Yuhang Wu at depthfirst has published a working proof-of-concept (PoC) exploit that executes commands as git on an unpatched self-managed GitLab 18.11.3 server.

An ordinary authenticated user triggers it by committing two crafted Jupyter notebooks and requesting their diff. The chain needs no administrator rights, continuous integration (CI) runner access, victim interaction, or access to another user's project.

The public exploit is build-specific to GitLab 18.11.3 on x86-64; the underlying Oj bugs affect broader releases. The affected ranges are GitLab Community Edition (CE) and Enterprise Edition (EE) 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1.

The first fixed releases are 18.10.8, 18.11.5, and 19.0.2. Oj is a high-performance JSON parser for Ruby with substantial native C code.

Published gems 3.13.0 through 3.17.1 are vulnerable; 3.17.3 is the first published release containing both fixes. The flaws affect Free, Premium, and Ultimate. Ruby itself is not affected.

Successful exploitation runs as git. Its effective reach depends on deployment isolation, but may include source code, Rails secrets, service credentials, CI/CD data, and internal services reachable from the application. GitLab.com was patched by June 10.

Dedicated customers need no action. Self-managed operators should move to a supported release containing the fix. Helm and Operator users need to check the GitLab version inside the Webservice image, not only the chart or Operator version. depthfirst said it was unaware of in-the-wild exploitation as of July 24.

Neither the depthfirst disclosure nor GitLab's June 10 release notes list CVE identifiers or CVSS scores for the two chain bugs. Neither provides a temporary workaround; both direct self-managed operators to upgrade.

The Hacker News has asked GitLab about CVE status, classification, and exploitation evidence. It also asked depthfirst about exploit portability and whether a supported temporary mitigation exists. Responses are pending. depthfirst lists nine CVEs for other Oj flaws found in the same review.

GitLab's notebook renderer passes repository-controlled .ipynb JSON to Oj::Parser.usual.parse inside a long-lived Puma worker. That sends attacker-controlled notebook data into Oj's native parser state inside GitLab's application process.

depthfirst's technical analysis shows how one bug controls a callback pointer, while the other leaks a heap address needed to narrow the address space layout randomization (ASLR) search.

Oj stores nesting state in a fixed 1,024-byte stack but never checks whether the depth exceeds it. Deeply nested arrays can therefore write 0x01 bytes into adjacent parser state. The exploit corrupts buf.head, causing Oj to pass a forged interior pointer to realloc(). A later Ruby Array allocation reclaims the same 3,584-byte jemalloc region and overwrites p->start.

Oj allocates a 65,565-byte object key, truncates its length to 29 in a signed 16-bit field, and returns 29 bytes containing the live key-allocation pointer. GitLab carries that pointer into the rendered notebook diff, giving the exploit the address leak needed to narrow the ASLR search. On the profiled two-worker GitLab 18.11.3 installation, the search usually took five to ten minutes. The researchers projected one to two hours across the widest mature-worker range.

Two lexically ordered notebook files in one diffs_stream request keep both stages inside the same Puma worker, which reuses the process-global Oj parser. The first file corrupts the callback and raises an error that GitLab catches before continuing the diff. The next parse invokes the overwritten pointer and reaches system() through a build-specific gadget sequence.

The public demonstration packages the chain in a local GitLab 18.11.3 x86-64 lab and makes the Puma worker connect back as git.

depthfirst reported the Oj bugs on May 21, and the maintainer merged the fixes on May 27. Oj 3.17.3 shipped on June 4. The researchers reported the GitLab chain on June 5; depthfirst said GitLab confirmed it on June 8.

GitLab released the fixed versions on June 10 and resolved the report on July 17, according to depthfirst. A review by The Hacker News found GitLab listed the Oj 3.17.3 bump under bug fixes rather than in the security-fix table and did not describe the notebook-diff RCE chain.

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

Strong vs eventual consistency in 2026: how to choose the right guarantee

Should every workload use strong consistency now that distributed SQL has matured? Not necessarily. Different applications tolerate different failure modes. Our new article explores where strong consistency pays off, where eventual consistency still wins, and how AI changes the equation.

Two shoppers click Buy on the last item in stock at the same instant. Does the system take both orders? Or does the second shopper immediately see the item’s gone?

That’s the difference between strong and eventual consistency. For over a decade, the industry defaulted to eventual consistency because strong consistency simply couldn’t scale. In 2026, that assumption deserves another look. Distributed SQL has made strong consistency practical at scale, and AI pipelines have turned stale reads into production bugs you’ll actually care about.

Why the tradeoff changed in 2026

Around 2010s, the rules were simple: if you wanted to scale, you accepted eventual consistency. Today that tradeoff is far less rigid.

Distributed SQL databases can now give you strongly consistent reads across regions without giving up the scalability enterprises expect – Google Spanner and CockroachDB brought this architecture into the mainstream, TigerBeetle’s joined them more recently, and the list of workloads that genuinely need eventual consistency is shrinking faster than most teams want to admit.

In modern systems, it usually belongs at the storage or caching layer, not in the service or API layer. Treating it as a default for every workload is a mistake.

AI reopened the question from the other side. Retrieval pipelines and AI agents routinely write data and read it back seconds, or even milliseconds, later. That might be a newly generated embedding or stored memory. It might be the result of a tool invocation. On an eventually consistent system, the write may not be visible yet. A one-second delay you wouldn’t notice in a social media feed (where it probably doesn’t matter) suddenly becomes an AI agent that’s making decisions on incomplete information.

Storage is moving the same way. Amazon S3 moved to strong read-after-write consistency for all objects in 2020 (after years of eventual consistency) and added conditional writes in 2024. Stronger consistency guarantees are becoming the default wherever they solve real operational problems. You shouldn’t inherit eventual consistency just because it was yesterday’s best practice.

 

Figure 1. Comparison of strong and eventual consistency models.

 

What strong and eventual promise

Strong consistency (its formal name is linearizability) means that once a write’s acknowledged, every later read from any node returns that value. There are no stale reads. The system behaves as if there’s a single copy of the data even when three copies sit on three different machines.

Eventual consistency means writes are accepted immediately and copied out in the background. Replicas can disagree for a short window, but they converge once writes settle and replication keeps running. Eventual doesn’t mean wrong forever; it means briefly stale, and the length of that window is exactly what you’re trading on. You accept that tradeoff in exchange for lower latency and higher availability.

Weak consistency is the third model. It provides no guarantee that you’ll read the latest value at all. That’s perfectly acceptable for multiplayer games or live leaderboards where responsiveness matters more than precision. Eventual consistency sits between these two extremes. It offers predictable convergence without the strict guarantees of linearizability. Amazon’s product catalog illustrates eventual consistency well. A price update or review count may take a short time to appear everywhere, and customers rarely notice. The checkout and payment systems behind that same website are built differently because they can’t tolerate stale reads. Most large-scale systems naturally split workloads this way. None of these models is universally “better.” They just optimize for different balances. If you understand that, you can pick the right guarantee.

Enough theory.

On to the CAP theorem.

Model	Reads the latest write?	Latency	Availability under failure	Typical fit
Strong	Always	Higher	Lower, may go read-only	Ledgers, inventory, locks
Eventual	After a short delay	Lower	Higher	Feeds, caches, analytics
Weak	Not guaranteed	Lowest	Highest	Games, live dashboards

 

The tradeoff you cannot escape

No distributed system can simultaneously guarantee strong consistency, high availability, and partition tolerance during a network partition. That’s the essence of the CAP theorem. When partitions occur, a strongly consistent system may reject reads or writes to preserve correctness. The exact behavior depends on its design.

An eventually consistent system can keep serving requests and reconcile replicas afterward. In practice, MongoDB and HBase generally favor consistency, while Cassandra and DynamoDB favor availability. That said, CAP is often oversimplified. Real network partitions are relatively uncommon, and the familiar “pick two” explanation hides the tradeoff you’ll notice every day: latency.

PACELC makes this explicit: if there’s a partition, you choose between availability and consistency, and else, during normal operation, you choose between latency and consistency.

That second half matters far more in day-to-day operations. Even on a perfectly healthy network, a strongly consistent read usually waits for a quorum response. Those additional milliseconds are the ongoing cost you’ll pay for stronger guarantees.

How the guarantee gets enforced

Two mechanisms do most of the work behind the scenes: quorum protocols at the database layer and replication underneath.

Strong consistency typically relies on quorums. If the read quorum plus the write quorum exceeds the total number of replicas, every read is guaranteed to overlap with the latest successful write. That overlap prevents stale reads.

Imagine three replicas. If the system requires acknowledgments from two replicas for every write and consults two replicas for every read, those groups must always share at least one node. That shared replica contains the newest committed value, so stale reads can’t happen. This overlap is the core idea behind quorum-based consistency.

Replication determines how writes reach those replicas, and two approaches dominate: synchronous and asynchronous. Synchronous replication waits until every required copy acknowledges the write before reporting success, which provides strong consistency, although write latency is limited by the slowest participating replica. Asynchronous replication acknowledges the write immediately and replicates it afterward, so your application sees lower latency, but a node failure before replication completes can still lose the most recent writes, and that’s the price you pay for speed. Consensus protocols like Paxos and Raft coordinate this process by ensuring every node agrees on the order of operations. The implementations differ, but the practical takeaway is simple: reaching agreement requires additional network round trips.

Where strong consistency is non-negotiable

Some workloads treat a stale read as a bug that costs money or breaks safety.

Financial transactions are the obvious example.

A balance that still appears positive after funds have been withdrawn is stale data escaping into production.

So is an oversold airline seat.

A customer charged twice is the same problem.

Imagine two customers buying the final copy of a book within milliseconds of each other. Without strong consistency, both purchases succeed. Your operations team’s got to issue refunds and sincere apologies.

A subtler failure mode shows up in read-modify-write workflows. Marc Brooker’s AWS example is the classic illustration: an application creates a resource and immediately reads it back. If that read reaches a lagging replica (maybe in a different availability zone), the database responds as though the resource never existed. From the application’s perspective, time’s just moved backward.

Teams often try masking this with retry loops and arbitrary sleep intervals. Those workarounds add latency. They’ll still fail if the resource’s been genuinely deleted instead of simply delayed.

That’s why banking platforms and inventory systems willingly pay the latency cost of strong consistency. It’s also why Google Spanner introduced TrueTime to provide external consistency across regions, and why AWS built Aurora DSQL around strongly consistent reads.

Where eventual consistency is the right call

Strong consistency isn’t the answer everywhere. For many workloads, eventual consistency remains the most practical choice.

Netflix serves viewing history and recommendations from eventually consistent Apache Cassandra clusters. Profile data lives there too. If the “Continue Watching” row updates a few seconds late, you won’t notice. DNS works the same way.

Record changes propagate gradually across the Internet, yet the entire ecosystem’s designed around that behavior. Content delivery networks such as Cloudflare and Akamai intentionally cache slightly stale content at the edge. Users benefit far more from fast responses than from perfectly fresh assets. Analytics and reporting platforms make similar tradeoffs. They’ll choose availability over reading the newest possible byte.

Cost’s also a factor. Amazon DynamoDB prices eventually consistent reads at roughly half the cost of strongly consistent reads. If you can tolerate a few seconds of staleness, you’ll pay significantly less.

Strong consistency pushes cost the other way. Synchronizing replicas requires extra consensus traffic and CPU time, and it’ll burn more cross-region bandwidth too. If every read uses strong consistency by default, infrastructure costs go up even when the application’s gaining little from the stronger guarantee.

That’s why most modern architectures mix both models. Use strong consistency where stale data creates correctness problems. Eventual consistency fits where responsiveness and availability matter more than reading the absolute latest value, or where cost’s the deciding factor. Amazon S3’s move to strong read-after-write consistency is a good example of this principle. The company strengthened consistency exactly where it eliminated a class of bugs developers repeatedly encountered. Other parts of the architecture stayed optimized for scale.

The storage layer already made this choice for you

Most discussions of consistency stop at the database. In practice, your consistency guarantee’s only as strong as the storage beneath it.

If the block layer loses the last acknowledged write after a node failure, the strong consistency you configured one layer above becomes a promise the infrastructure can’t keep.

The familiar read-replica race has a storage equivalent (and it’s just as painful). Asynchronous block replication acknowledges a write before the secondary copy exists, so during failover the application can suddenly see data that’s older than what it’s already committed.

This is where synchronous mirroring matters. StarWind VSAN protects acknowledged writes by mirroring every write between two storage nodes and confirming it only after both copies are safely committed. A two-node deployment using the Heartbeat failover strategy can provide high availability without a separate witness node; the footprint stays small.

For larger heterogeneous estates, DataCore SANsymphony applies the same synchronous mirroring across mixed arrays for tier-one block workloads.

In practice, the decision’s straightforward. Match the storage guarantee to the workload. There’s little value in synchronously mirroring data that’s read once every quarter, yet placing a financial ledger on an eventually consistent storage tier makes equally little sense.

What AI and agentic workloads change

AI’s changed consistency from a database setting into an infrastructure decision. Agent and retrieval workflows are fundamentally read-modify-write loops (they’re the same pattern at a different scale). They might generate an embedding, store a memory, or record a tool result. Whatever they write, they’ll often query it immediately. On an eventually consistent vector store, that write won’t be searchable yet.

The reason’s usually the index. Approximate nearest neighbor (ANN) indexes are rebuilt incrementally. A newly inserted vector can remain invisible to similarity search for seconds or even minutes, even though the underlying database already stores it and would return it through a direct lookup. For a chatbot summarizing last quarter’s reports, that delay rarely matters. An autonomous agent acting on a record it created moments earlier faces a correctness bug. These often slip through testing because quick demos rarely expose the timing window.

If you’re on the infrastructure team, this quickly becomes a placement question. Real-time inference and agent memory are increasingly deployed close to the compute layer. That might be on-premises. It might sit at the edge. Dedicated AI clusters are another common target. As a result, the consistency guarantees provided by the underlying storage directly affect application behavior.

That doesn’t mean every AI workload needs strong consistency. It means identifying the handful of operations where an agent can’t safely act on stale state. Let retrieval, analytics, and other latency-sensitive paths benefit from eventual consistency.

It isn’t always binary: tunable consistency

Consistency isn’t always an all-or-nothing switch. Apache Cassandra lets you choose a consistency level for each operation. A single-replica read minimizes latency. Quorum reads provide strong enough guarantees for many workloads. Full agreement across every replica delivers the strongest consistency, but you’ll pay with higher latency and reduced availability. That flexibility means the same application can require strong consistency during checkout while serving product pages with eventually consistent reads.

Between those two extremes sit several useful middle-ground guarantees. Read-your-writes consistency ensures you’ll see your own updates. Monotonic reads prevent a session from moving backward in time. They stop the system from returning older versions of data after newer ones have already been observed.

Causal consistency’s particularly useful for collaborative applications. It preserves the order of related operations: a reply never appears before the message it’s responding to. Messaging platforms and social networks benefit from this behavior without paying the cost of global coordination, which is why you’ll often see it in threaded comment systems and shared document editors.

In practice, very few distributed systems need one consistency model everywhere – the checkout flow and the analytics pipeline have utterly different requirements, and that’s fine. These days, databases let you pick the right guarantee per operation. Pick per operation. Don’t pick once for the whole stack.

Matching the guarantee by workload

The same tradeoffs hit differently depending on what you’re running. No surprise there. A retail warehouse and a cardiac monitor don’t share the same constraints.

Financial services and e-commerce

Checkout flows keep strong consistency on the transaction path. You can’t afford a double-charge because a replica lagged behind.

Media and healthcare

Archives hold petabytes of cold objects, and eventual consistency on an object tier is the sensible, low-cost choice. Nobody’s waiting on an MRI from 2019 to propagate instantly.

SaaS and content platforms

Run eventual on the read path and reserve strong guarantees for the few operations that guard money or identity – billing, access control, that sort of thing. Most reads don’t need the newest byte immediately.

AI platforms

Lean eventual for bulk retrieval and analytics, and keep strong consistency only where an agent acts on state it just wrote. That’s rarer than most AI marketing suggests – usually it’s limited to narrow update paths in most stacks. (Most of the time the model’s just reading stale training data and nobody cares.)

Multi-site retail

You can run a two-node, synchronously mirrored cluster at each location. Failover keeps critical local state available without forcing every transaction through a distant regional round trip. It’s slower, but the register stays up when the WAN hiccups.

How to choose

Start with one question for every operation: what happens if this read’s a few seconds stale? If the answer involves money or safety, strong consistency is usually the right choice – those are exactly the domains where a stale read turns into a real incident that’s hard to unwind. Where nobody would notice, eventual consistency will likely give you better performance at lower cost.

From there, the checklist is short. Think in terms of single operations, not whole applications, and apply strong consistency only where it delivers measurable value. Use tunable consistency levels if your database supports them. Also verify that your storage layer can actually uphold the guarantees your database claims, because a database configured for strong consistency is only as good as the replication running underneath it, and if that replication is asynchronous you’ve basically bought a label, not a guarantee. Then measure the latency. It matters. Even on a healthy network, strong consistency carries a cost, and that cost needs to be justified by the workload.

Most production systems end up somewhere in the middle. They combine strong and eventual consistency and apply each where it fits best. In 2026, more databases and storage platforms let you make that decision per operation instead of forcing one model across the entire system, which finally means you can tune by query rather than by cluster. That’s a welcome change – most teams have spent years over-provisioning clusters because vendors wouldn’t let them mix guarantees inside one deployment.

FAQ

Is eventual consistency just unreliable?

No. It’s briefly stale, then convergent. Give it a pause. Every replica ends up holding the same value, assuming the system’s healthy.

Can one system use both models?

Yes. Many engines expose tunable, per-operation consistency, so one application can run strong writes and eventual reads together. You don’t have to pick one model for the whole codebase.

How does storage replication affect my database’s consistency?

Directly. Asynchronous block replication can lose the last acknowledged writes on failover, and that quietly undercuts any strong guarantee you’ve configured above it, no matter what the database console claims. (Your database thinks it’s synchronous. The SAN underneath disagrees.)

Did distributed SQL make eventual consistency obsolete?

No. It made strong consistency cheaper at scale, but eventual still wins wherever latency and availability matter more than reading the newest byte, and that’s still most of the time.

from StarWind Blog https://ift.tt/jTh2VX5
via IFTTT

Your Best Analyst Shouldn’t Be a Person. It Should Be a Capability Everyone Can Summon.

For thirty years, we have measured security operations by the tools we buy. The next decade will measure us by the outcomes we deliver. That shift is already here, and it is being driven by something quietly radical: a repository of AI “skills” that turns the deep expertise of a principal analyst or engineer into a capability any team member can invoke on demand.

I want to talk about what that actually changes for the business, not the bits and bytes underneath it.

The problem every CISO already knows by heart

You are not short on data. You are drowning in it. Endpoint telemetry, identity logs, firewall traffic, cloud control planes, email security, SaaS audit trails. Each one speaks a different language. Each one demands a specialist who knows where the bodies are buried. The talent who can fluently read all of them at once is rare, expensive, and almost certainly already burned out.

So the work stacks up. Alerts wait. Investigations get triaged by whoever is awake. The third repeat of an attack pattern goes unnoticed. The analyst who caught the first two left for a competitor. Your security posture quietly becomes a function of who happens to be on shift.

This is the real cost center in modern security operations: expert human attention, not licenses or infrastructure. There is never enough of it.

What changes when expertise becomes a skill

The ai-siem repo, located on the Sentinel One GitHub community (https://github.com/Sentinel-One/ai-siem/tree/main/plugins/s1-secops-skills), attacks that bottleneck directly. Instead of asking a human to remember how to query log sources, pivot through threat intelligence, correlate findings, and write it all up, each of those steps becomes a skill. Captured once. Available to everyone, every shift, every time.

Disclaimer: This sample script/prompt is community-contributed, open-source content provided “AS IS,” without warranty of any kind. SentinelOne does not certify or endorse it, is not responsible for its accuracy or outputs, and is not liable for any outcomes arising from its use. Test and validate in a non-production environment before use.

The senior analyst’s playbook stops living in one person’s head. It becomes a durable asset owned by the whole organization. That single change cascades into outcomes leadership actually cares about.

The data lake is the foundation nobody’s talking about

Here is the part that makes the rest of it work. It is the most underrated shift in security right now. Skills are useless if the data lives in a dozen disconnected silos. Each has its own query language, retention tier, and price per gigabyte. The reason this whole model becomes possible is the security data lake. A single place where endpoint, identity, network, cloud, email, and your own application logs land together in one queryable substrate, at a cost that doesn’t punish you for keeping data.

This is where SentinelOne’s Singularity Data Lake stops being infrastructure and starts being the differentiator. It was built for streaming AI from day one, not retrofitted onto it. That architecture is what makes an AI analyst viable. Data becomes searchable the moment it arrives. No indexing delay to wait through. Everything stays hot and searchable. All of it. There’s no cold tier to thaw, and no log you quietly dropped because retention got expensive. It scales to petabytes where legacy SIEMs buckle at terabytes. And it does this at more than ten times the query performance, for less than half the cost of the per-gigabyte SIEM model it replaces.

Translate that into outcomes, and the picture is stark. Ingestion, detection, and query that used to take minutes to hours on a legacy SIEM now happen in seconds. More than 2,000 detections run in the stream itself. Threats surface as the data lands, not minutes after it’s stored. That speed is not a nice-to-have. An AI agent is only as fast as the data underneath it. Give it a lake that answers in under a second, and it reasons across your entire estate before you’d have opened one console tab.

That is what breaks the twenty-year SIEM economics. For twenty years, the industry’s answer to “where do we put all the security data” was a SIEM. One that charged so much per gigabyte that teams were forced to drop the very logs they later wished they’d kept. The data lake inverts that math. Keep everything. Query everything. Correlate everything. Let the ingest bill stop dictating your detection strategy. The skills are the brain. The data lake is the nervous system, letting the brain feel the whole body at once, instantly. You cannot have the outcomes below without it.

This is Autonomous Cybersecurity (AI-Native Protection Across the Enterprise) in practice. Autonomous Security Intelligence, ASI, is the intelligence fabric that runs on top of that data. It is not a bolt-on skill pack. It is what turns a queryable lake into an analyst that never sleeps.

Outcome 1: Investigations that took a shift now take minutes

The gathering is the slowest part of any investigation, not the decision: pulling the alert, finding the affected asset, enriching every indicator against external intelligence, sweeping the rest of the fleet for the same fingerprint, and assembling the timeline. That is hours of skilled work that have to happen before anyone can even say “true positive” with confidence.

When those steps run as orchestrated skills, the gathering collapses into minutes. Your analysts spend their judgment on the verdict and the response, which is the part only a human should own. Mean time to detect and mean time to respond stop being aspirational metrics on a slide. They become numbers you can defend to the board.

Outcome 2: A first-year analyst operating at a principal level

This is the one that genuinely reshapes the org chart. When the hard-won method of your best investigator becomes a skill, a junior analyst inherits it directly: the answer, arrived at the right way, with evidence cited, confidence calibrated, and assumptions flagged.

The skills gap that has defined this industry for a decade narrows dramatically. You stop competing for the handful of unicorns who can do everything, because everything is now a shared capability. Tier-one talent does tier-three work. New hires become productive in days, not quarters. And the people you already have stop drowning. That’s how you keep them.

Here is what convinced me that this is real and not a demo. It was not a SOC analyst who proved it first. It was an engineer. Reviewing application logs, they surfaced a genuine fraud case. A true positive lived in business telemetry. No traditional security tool was even watching. Sit with that for a second. People who do not carry a security title, looking at data that never reaches the SIEM, caught actual fraud. That is what happens when investigative expertise stops being gated behind a job description. The capability travels to wherever the data and the curiosity are. Threats that used to hide in the gaps between teams suddenly have nowhere to live.

More impact per analyst and greater control with less fatigue.

Outcome 3: No blind spots, because nothing gets correlated in isolation

Attackers do not respect your tool boundaries. They land in email, execute on the endpoint, move through identity, and leave through the network. A threat that is invisible in one source is often obvious the moment you line it up against three others. The trouble is that lining them up has always required a specialist for each layer. All working in concert, under time pressure, at 3 am.

Cross-source correlation built into the workflow doesn’t depend on who’s in the room. The full attack story assembles itself. You see the chain, not the fragments. The single most dangerous phrase in security operations, “we had the data, we just never connected it,” starts to disappear.

Outcome 4: Every alert arrives with context already attached

A medium-severity alert on a domain controller matters more than a critical one on a throwaway sandbox. Every experienced analyst knows this. Yet most alerts land in the queue as bare indicators with no business context. Someone has to hunt down what the asset is, who owns it, and whether it matters. That manual lookup happens thousands of times a week. It’s where prioritization quietly goes wrong.

When asset enrichment runs autonomously, every log and every alert already carries the device and user context that determines its importance: what the machine is, how critical it is, and whose account is involved. The queue effectively sorts itself by business impact. Analysts stop chasing noise in disposable systems and spend their time where the real risk lies. False-positive fatigue drops, and the genuinely dangerous signal stops getting buried under the trivial. Prioritization by business impact stops being an aspiration and becomes the automatic default.

Outcome 5: Proactive defense, finally, at machine speed

Known-bad signatures catch yesterday’s threats. The adversaries that actually hurt you, the patient ones and the insiders, only ever show up as deviations from normal. A login at an impossible hour. A workstation reaching a destination it’s never touched. A service account suddenly behaving like a human.

Hunting for that kind of anomaly across the entire estate, continuously, has always been a luxury. Reserved for the most mature and best-funded teams. Make it a repeatable skill and proactive hunting stops being a quarterly project you never quite get to. It becomes the default mode of the SOC. You move from reacting to alerts to anticipating the attacker’s next move. That is the whole point of the discipline. Most teams never have the capacity to actually do it.

Outcome 6: A new threat in the headlines becomes a detection the same morning

When a new campaign breaks, the clock starts immediately. The window between “this threat is now public” and “we are protected against it” is pure exposure. Historically, that window has been measured in days or weeks. Someone has to read the intelligence, translate it into detection logic, test it, and push it live. That someone is usually already underwater.

Make detection engineering a skill, and that window collapses to a morning. The moment an emerging threat surfaces, its behavior becomes a live detection rule: validated and deployed across the estate before the first coffee gets cold. Your defenses move at the speed of the threat landscape instead of at the speed of your backlog. Just as importantly, the detection logic your team writes today gets captured and reused. Coverage doesn’t just grow. It compounds.

Outcome 7: New data sources onboarded in minutes, not quarters

Onboarding a new data source has traditionally been a small project: parse the logs, normalize the fields, build the dashboards, write the detections, and wire up the response. Weeks of specialist time have to pass before that source earns its keep. That’s exactly why the backlog of “sources we really should be ingesting” never shrinks.

That math is now broken in your favor. When those steps are packaged as skills, a new feed goes from raw and unreadable to fully operational in minutes: normalized, with detections firing and a dashboard live. Read that again, because it rewrites your roadmap. Every integration you’ve been deferring for budget or bandwidth reasons just got cheap. Cheap enough to do the same day someone asks for it. Coverage stops being a function of how many quarters you can fund. It becomes a function of how fast you can decide.

That is the compounding version of Maximize Efficiency and Effectiveness of Security Operations: coverage that gets cheaper and faster to extend every time you use it.

The economics that should end the conversation

Now brace for the part that makes the CFO lean in. Everyone assumes the AI is the expensive bit. It is the opposite. Bring-your-own-AI on top of the data lake costs peanuts relative to what it replaces and the work it does. The heavy historical spending on security operations was never on intelligence. It was on the ingestion licensing of a legacy SIEM, and the salaries of specialists doing by hand what a skill now does in seconds.

Sit the two columns next to each other. On one side: per-gigabyte SIEM pricing that grows with your business, whether or not it makes you safer. Plus the fully loaded cost of analysts spending their nights on manual gathering. On the other: a data lake built for scale, and an AI layer whose run cost rounds to a rounding error against either line item. The capability goes up and to the right while the cost line stays flat. That’s a different business model for security. It’s a rare case where the cheaper option is also the more capable one.

This is Enable Business Growth and Innovation Safely in dollar terms: the budget fight between “more coverage” and “more efficient spend” disappears, because the same architecture delivers both.

The deeper shift: the SOC stops being a cost center and starts compounding

Here is the part that should excite anyone running a security budget. Every investigation a human does is an effort spent once and largely lost. Every investigation captured as a skill is an effort spent once and reused forever. Your operation stops being a treadmill and starts being an asset that compounds. The work your team does today makes the work tomorrow faster, cheaper, and more consistent.

AI answering faster is the easy headline. The real shift: institutional security expertise stops walking out the door and starts accumulating on the balance sheet.

What I would tell a peer

We have spent a generation buying tools and hoping the outcomes follow. The teams that win the next decade will flip the order. Define the outcomes first. Then make the expertise to achieve them a capability everyone can summon, day or night, junior or senior, first alert or thousandth.

The technology to do this exists now. Our purpose is simple: to give the advantage to those who secure our future. That advantage only counts if it reaches every analyst, not just the ones already fluent in every log source. The organizations that adopt it won’t just be faster. They’ll run a fundamentally different kind of security function: one where the best analyst in the building is available to everyone, all the time, and gets sharper with every case it touches.

The bottleneck was never the data. It was access to expertise. That bottleneck just broke.

If you run a SOC, lead security for your organization, or work the queue every day: how much of your team’s best thinking is locked inside one or two people right now? That is the question worth sitting with this week.

Curious what this looks like in practice for your environment? Come talk it through in our Reddit community, r/SentinelOneXDR. Practitioners there trade real detection logic, ask the SentinelOne team direct questions, and compare notes on what’s actually working in their SOCs.

Disclaimer:  The sample scripts, code, AI prompts, and other tools referenced or included in this publication (“Community Content”) are provided for informational and educational purposes only. Community Content is contributed on an open-source basis and is made available “AS IS” and “AS AVAILABLE,” without warranties of any kind, whether express, implied, or statutory, including, without limitation, any warranties of accuracy, completeness, reliability, merchantability, fitness for a particular purpose, or non-infringement.

SentinelOne does not certify, endorse, or guarantee any Community Content, its outputs, or its suitability for any particular use, and Community Content does not constitute part of any SentinelOne product or service offering. SentinelOne has no obligation to maintain, support, or update Community Content. AI prompts in particular may produce inaccurate, incomplete, or unexpected results depending on the model, configuration, and environment in which they are used.

Any use of Community Content is at your own risk. You are solely responsible for evaluating, testing, and validating any Community Content in a non-production environment before use, and for ensuring your use complies with applicable laws, licenses, and your organization’s policies. To the maximum extent permitted by law, SentinelOne and its affiliates will not be liable for any damages, losses, or outcomes of any kind arising out of or relating to the use of, or reliance on, Community Content. Where Community Content is hosted in or links to a third-party repository (e.g., GitHub), your use is also governed by the applicable open-source license and the terms of that platform.

from SentinelOne https://ift.tt/X94Btaj
via IFTTT

Seeing AI Agents Is Not Enough. Security Teams Must Enforce What They Can Do

AI agent security is moving through a familiar maturity curve: adoption, then visibility, and finally, control. But what we've collectively discovered is that enforcing least privilege for AI agents is harder than we ever imagined. This is why there are so many approaches, from prompt filtering to identity-layer access controls. Where we've collectively landed is that understanding the intent of AI agents is essential to securing them. It's not easy, but it's the only path forward.

Organizations approach this challenge with different levels of sophistication. For many, the current goal is simply to find the AI agents already operating across the business. That is a necessary first step. AI agents are appearing in SaaS platforms, developer environments, cloud workflows, customer support systems, productivity tools, and internal applications. Some are sanctioned, and others are not.

But discovery alone isn't useful. AI agents are not passive; they reason, plan, call tools, invoke APIs, access data, and take action without a human in the loop. The risk is not that an organization has too many agents. The risk is that those agents can operate across systems without consistent identity, intent, ownership, and enforcement. There are also different types of AI agents, each requiring a different approach to securing them.

Recent guidance on the careful adoption of agentic AI services makes the point clear: agentic AI introduces privilege, authentication, accountability, design, and behavioral risks that security teams need to address before these systems become embedded in critical workflows. Visibility is the starting line, but enforcement is what matters.

The Visibility Trap

Most security programs begin with the question: "What do we have?" That made sense for cloud, SaaS, endpoints, identities, and vulnerabilities. It also makes sense for AI agents.

But the risk of stopping at visibility alone for AI agents is greater than in every other environment in the list because of the speed with which AI agents are being created, what they have access to, and how they can be shared.

An AI agent inventory that does not connect to enforcement becomes another static asset list. It may show that an agent exists, but it cannot tell you whether the agent's access is appropriate, its behavior matches its purpose, its owner remains accountable, or when its permissions should be revoked as conditions change. For AI agents, visibility without enforcement creates a dangerous kind of confidence, where it's easy to feel in control when the reality is far different.

Why AI Agents Break Static Access Models

Traditional access control assumes some level of predictability. Human Identity and Access Management has it the easiest, as each person has a job function. Non-human or machine identity management is more complex, but a service account still supports a defined workload. These assumptions are imperfect, but they gave security teams a foundation for roles, entitlements, approvals, access reviews, and periodic cleanup.

AI agents are far from static. An agent is defined less by a fixed workflow and more by a goal. It may interpret instructions, call different tools, and adapt its actions based on context. Two agents with similar permissions may have a very different risk profile, depending on what each is trying to accomplish.

Static access is not enough because AI agents are more likely to be used in ways not anticipated when access was granted. The issue is not always malicious behavior but ambiguity that poses a risk, such as a task that expands beyond its original purpose.

The question security teams need to ask is not only "what can this agent access?" The more important question is: What should this agent be allowed to do, under these conditions, for this purpose? That is an enforcement question.

Enforcement Starts With Better Understanding

Effective AI agent enforcement cannot be bolted onto a basic, non-contextual inventory. Security teams need to correlate information across owners, consumers, identities, systems, permissions, and intent before they can define meaningful controls.

That means understanding an agent across several dimensions:

• Ownership: Who owns the agent? (This can be more difficult than you may think.)
• Consumers: Who is using the agent?
• Identity: Which identities, tokens, secrets, OAuth grants, and service accounts does the agent use?
• Intent: What is the agent supposed to accomplish?
• Access: Which systems, applications, data stores, APIs, and infrastructure can it reach?
• Usage: What has the agent actually done, and how often?
• Origin: How was the agent created?
• Lifecycle: Is the agent active, dormant, or no longer tied to its original purpose?

This is where many organizations struggle because agent context is scattered. Identity data lives in one place. Cloud permissions are somewhere else. SaaS integrations have their own models. Infrastructure as code can reveal intended deployment patterns, but that context is rarely correlated with the rest. Ownership may be obvious to the person who created the agent and invisible to everyone else.

Without correlation, enforcement becomes guesswork. With correlation, security teams can begin defining rules that reflect how agents actually operate.

Many security tools equate enforcement with remediation. Something risky is found, and a playbook opens a ticket, removes access, disables an identity, or notifies an owner. That is useful, but it is not enough for agentic AI. AI agents need enforcement before, during, and after they take action.

Security teams need to move from asking, "What should be removed after risk is detected?" to "What should this agent be allowed to do in the first place?" That shift moves enforcement from cleanup to control. Organizations can then define rules such as:

• A customer support agent can read ticket history, but cannot export customer data in bulk
• A code assistant can suggest changes, but cannot push to production without an approved workflow
• A cloud operations agent can inspect configuration drift, but cannot modify privileged roles
• A finance agent can generate reports, but cannot initiate payments or change vendor details
• A security agent can triage alerts, but cannot delete logs or suppress detections

These rules cannot be managed effectively inside one AI platform at a time. Enterprises will use many agent platforms, SaaS-native agents, internal frameworks, cloud services, and developer tools. Each may have its own controls, logs, and permission models. Security teams need a consistent way to govern agents across that fragmented environment. That is why the next control plane for AI agents has to be identity-centric, context-aware, and platform-agnostic.

The Role of Intent in Enforcement

Identity answers who the agent is. Permissions answer what access exists. Intent answers why that access should be active.

The intent dimension is essential. AI agent risk cannot be understood only by looking at whether an API call is technically permitted. Security teams need to evaluate whether an action aligns with the agent's approved purpose.

Intent-based enforcement gives organizations a more precise control model. It allows security teams to move from broad, static permissions to conditional access based on purpose and context. That does not mean every action must be manually approved. It means high-risk actions should be constrained by the agent's role, owner, task, environment, and expected outcome.

The OWASP Top 10 for Agentic Applications highlights risks such as identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures, and rogue agents. These risks all point to the same conclusion: security controls must understand the agent's reason to act.

A Singular Control Plane for Agentic AI

AI agents do not live in one platform. They exist across the enterprise. While "traditional" machine identities were created by IT, Developers, and DevSecOps teams, AI agents are created by people in every role in the organization. Some agents will operate in cloud environments, while others will run locally. Some will be embedded in business workflows that security teams do not directly manage.

Platform-by-platform controls for AI agents will not scale. Each platform may provision its own agents, but no single platform can see the full enterprise picture of identity, access, ownership, and lifecycle. Organizations need a unified control plane that can understand agents across environments and enforce consistent rules.

That control plane should do three things:

• Discover: Find agents wherever they exist
• Understand: Correlate agents with identities, owners, access, infrastructure context, usage, and intent
• Enforce: Apply rules that govern what agents can do, when they can do it, and how access should change as context changes

See how AI-first security solutions like Token Security discover, understand, and enforce what your AI agents can do across every platform.

This is the difference between managing agent sprawl and governing agentic AI. Sprawl happens when every platform, team, and business unit creates agents independently. Governance occurs when the organization can apply consistent controls across that activity without blocking innovation.

What Security Leaders Should Do Now

Security teams do not need to wait for perfect standards or fully mature tooling before acting. They can start building the operating model now.

The first step is to stop treating AI agent visibility as the finish line. Of course, agent inventories are the foundation for enforcement. Every agent should be mapped to an owner, a purpose, an identity, a set of permissions, and a lifecycle state. Unowned agents should be investigated, overprivileged agents should be right-sized, dormant agents should be retired, and high-risk actions should require stronger controls.

But ultimately, enforcement is what matters. Security leaders should align AI agent governance with identity and access management, cloud security, application security, and DevOps workflows. Agentic AI is not a separate universe. It is software with access, autonomy, and business impact. It belongs inside the enterprise security model, but that model has to evolve.

NIST's AI Agent Standards Initiative points in the same direction, with work focused on standards, protocols, authentication, identity infrastructure, and secure human-agent and multi-agent interactions. The market is moving toward the same conclusion: AI agents need to be governed as actors with authority, not treated as ordinary applications with a chatbot interface.

Visibility Is the Beginning, but Enforcement Is the Goal.

The first wave of AI agent security was about awareness. Organizations needed to understand that agents were entering the enterprise and creating new identity risk. That message landed, and every security and IAM team knows they need visibility. The next wave is enforcement.

Enterprises need to define what agents are allowed to do and apply rules consistently across platforms. They need to move from "Which agents exist?" to "Which agents can take which actions, under which conditions, and who is accountable?"

That is the control plane agentic AI requires. Not another dashboard or static inventory. AI agents are becoming active participants in enterprise operations. They will write code, manage infrastructure, move data, update systems, and execute workflows. The organizations that succeed with agentic AI will not be the ones that simply find every agent. They will be the ones who understand every agent well enough to enforce what it can do.

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

Golden Chickens Resurfaces With Four New Malware Families and Modular Implants

The threat actors behind the Golden Chickens malware-as-a-service (MaaS) ecosystem have resurfaced with four new malware families, indicating that the operators are showing no signs of stopping despite extensive public disclosures into their inner workings.

The malware families in question are: TinyEgg, ChonkyChicken, a modularized variant of ChonkyChicken, and a modified web browser credential theft utility codenamed ChromEggscalator. Recorded Future's Insikt Group is tracking the group under the moniker TAG-195.

TAG-195 is a financially motivated malware-as-a-service (MaaS) developer whose tooling has been previously linked to TAG-127 as an operator and customer. The threat intelligence company said it has also observed TAG-127 deploying TinyEgg via ClickFix-style social engineering campaigns that trick unsuspecting users into manually executing malicious commands.

"The four new families indicate an architectural transition and evolution in the TAG-195 MaaS ecosystem," Recorded Future said. "All four families share a common set of architectural traits: consistent command-and-control mechanisms, a shared persistence approach, string obfuscation, and execution via the same delivery model."

A brief description of each of the tools is as follows -

• TinyEgg, a lightweight initial-access backdoor providing host profiling, interactive shell access, and persistence management
• ChonkyChicken, a fully featured implant that expands on TinyEgg with browser credential theft, live browser session control using Chrome DevTools Protocol (CDP), credential-backed remote execution, network reconnaissance, and sustained surveillance
• A modularized version of ChonkyChicken that introduces a controller-and-plugin architecture that enables the controller to request and load 14 discrete capability modules on demand instead of embedding the entire functionality in the implant
• ChromEggscalator, a successor to TerraStealerV2 and a modified version of a publicly available Chrome encryption-bypass tool called ChromElevator

The shift is a sign that Golden Chickens, also called Venom Spider, is actively refining its arsenal through active development, while deliberately moving to modular, operator-driven tooling for defense evasion.

Associated with a malware family called More_eggs, the threat actor's tools have been put to use by other cybercrime groups like Cobalt Group (aka Cobalt Gang), Evilnum, and FIN6. Another threat actor associated with the Golden Chickens MaaS is TAG-127, which uses ClickFix or VenomLNK as delivery methods.

Attack chains have been found to leverage ClickFix lures to execute OCX payloads downloaded from attacker-controlled staging infrastructure, resulting in the installation of TinyEgg. The malware's functionality is limited to initial access and profiling functions, with all post-exploitation capability passed on to ChonkyChicken. TinyEgg is also designed to terminate execution if sandbox and automated analysis environments are detected.

The malware establishes connections with a C2 server using WebSockets to facilitate an interactive command shell, run operator-supplied input to the active shell session commands, send the output back to the controller, and stage OCX payloads.

The modular version of ChonkyChicken, on the other hand, supports 14 different components that are fetched from the C2 infrastructure as needed, allowing the operators to selectively deliver certain functionality on the fly that monolithic malware architectures cannot easily support without an update mechanism. The 14 modules enable the following functions -

• Process management
• Screen capture and monitor enumeration
• File manipulation
• Command execution
• Network reconnaissance
• Domain-based reconnaissance
• Clipboard capture
• Keylogging
• Audio capture
• Idle time check
• HTTP/S request via host
• Browser theft via ChromEggscalator
• Persistence management

The modular version also supports a module named "wtrack" whose purpose remains unknown. This suggests the addition of an active capability under development.

"TAG-195's transition to a modular architecture almost certainly reduces the base implant's static detection exposure, and likely also reflects commercial incentives inherent to the MaaS model, including the ability to provision capabilities selectively to operators, limit exposure if a customer is compromised, and serve a broader range of operational requirements," the cybersecurity company said.

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

Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say

Redis shipped seven security releases on July 23 after researchers published authenticated RCE PoCs for stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0.

All four chains require RESTORE. The Streams chains also need EVAL and XGROUP; the 8.8.0 chain needs EVAL and the bundled RedisBloom module. Redis says the underlying memory flaws may lead to remote code execution.

Redis 6.2.23, 7.2.15, and 7.4.10 fix the Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom and TDigest out-of-bounds writes; Redis 8.8.1 fixes the RedisBloom and TDigest loaders, while the Streams guard was already present in Redis 8.8.0.

Two PoC targets, Redis 6.2.22 and 7.4.9, were the May security updates Redis told users to install, but those releases did not include the shared-NACK ownership guard.

Upgrade to the fixed release for the deployed branch. Until then, revoke RESTORE from accounts that do not strictly need it and block untrusted network access. Restricting RESTORE cuts off both disclosed paths.

Neither Redis's July 23 release notes nor the public PoC repositories reviewed reported in-the-wild exploitation as of July 24, 2026.

Two Paths Through RESTORE

The Redis Streams path is a shared-ownership bug. A corrupt RDB object can make two consumers point to the same pending-entry record, so removing both consumers frees the same object twice.

The published script is designed to turn the resulting memory corruption into arbitrary memory access and ultimately invoke system().

The RedisBloom path is an out-of-bounds write in the TDigest RDB loader. The loader allocated memory from one serialized value but trusted a separate attacker-controlled capacity field when deciding how much data to load.

The Redis 8.8.0 script is designed to turn that mismatch into read and write primitives, leak Redis and libc addresses, and call system().

The Streams Shared-NACK Chain

The first path is in Redis Streams. A corrupt RDB object can make two consumers point to the same pending-entry record, represented internally by a streamNACK. Removing the first consumer frees the object and leaves the second holding a dangling pointer. The scripts then remove the second consumer too. One chunk, two frees.

Redis 8.6.4's release notes cite PR #15081. But a source review by The Hacker News found that the tagged 8.6.4 source lacks the duplicate-ownership check added by that change. The guard appears in Redis 8.6.5, released on July 23.

The published Redis 8.6.4 script is designed to turn the double-free into arbitrary memory access, then poison a database hash function so a crafted GET invokes system(). It restores the pointer and checks whether Redis still responds.

The RedisBloom TDigest Chain

The second path sits in the RedisBloom TDigest RDB loader. It allocated its centroid arrays from a serialized compression value, then trusted a separate attacker-controlled capacity field when deciding how many nodes could be loaded. A small real allocation paired with inflated metadata produces an out-of-bounds write.

The Redis 8.8.0 script is designed to turn the write into read and write primitives, leak Redis and libc addresses, and poison a database hash function so a crafted GET calls system(). A separate proof of concept published the same root cause and an authenticated RCE chain against Redis 8.8.0.

Redis's July fix requires the loaded TDigest capacity to match the allocation derived from the compression value. It also bounds the merged and unmerged node counters before reading the arrays.

Seven Releases, No New CVE Records

The repository calls the Streams issue part of a CVE-2026-25589 "incomplete fix family," but Redis maps that CVE to RedisBloom memory corruption during RESTORE, not the Streams shared-NACK flaw. Redis's July release notes list no CVE or CVSS score for either new bug class.

As of July 24, searches by The Hacker News found no separate NVD record for the July shared-NACK or TDigest findings. NVD still listed the May records for CVE-2026-25243 and CVE-2026-25589. A search of CISA's Known Exploited Vulnerabilities catalog returned no entry for either identifier.

The disclosure follows another AI-discovered Redis RCE flaw patched in May. Bera Buddies describes itself as "AI Agent Research." Chaofan Shou said on X that Kimi K3 agents found 19 Redis zero-days in about 90 minutes, and said another run produced the Redis 8.8.0 exploit in 27 minutes.

Those counts, timings, and the claimed degree of autonomy remain self-reported. Redis's public record confirms the flaws and fixes. It does not validate the claimed zero-day count or how independently the agents worked.

Redis 6.2.22 and 7.4.9 were the May destination. By July, both needed another update. Check the exact branch version, not whether Redis was merely "recently patched."

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

Fake Notepad++ Plugin Delivers MATCHBOIL.V2 in UAC-0099 Attacks

The Computer Emergency Response Team of Ukraine (CERT-UA) has warned of a new campaign that involves the use of a malicious program that's dressed up as a Notepad++ plugin to compromise Windows systems.

The activity has been attributed by the agency to a threat cluster it tracks as UAC-0099, a Russia-aligned group that has previously observed weaponizing security flaws in WinRAR software to deliver a malware strain called LONEPAGE. Other cyber attacks mounted by the adversary have employed phishing emails as an initial access method to deploy MATCHBOIL, MATCHWOK, and DRAGSTARE. It's known to be active since at least mid-2022.

The latest set of attacks begins, observed earlier this summer, with a phishing email containing an image attachment, which, when clicked, opens a URL that's concealed using a link shortener from where the request is sent to a file-sharing service like EasySend[.]co to retrieve a ZIP archive.

The ZIP file contains a Visual Basic Script (VBScript) that masquerades as a PDF document. Attempting to launch it will cause a decoy PDF to be downloaded and displayed to the victim as a distraction mechanism, while it silently downloads a second archive named "Evernote.zip." The archive includes multiple components -

• A complete copy of the legitimate editor Notepad++ version 8.8.3
• A malicious DLL plugin ("NppExport.dll")
• A password-protected archive ("updater.rar")
• Legitimate WinRAR executable ("winrar.exe")

The primary goal of the VBScript is to extract the contents of the archive and launch Notepad++, which, in turn, loads "NppExport.dll." Codenamed LUNCHPOKE, the DLL is designed to unpack the RAR archive, which contains "RemoteLibUpdater.exe" and "InitTest.dll," to a specific directory, set up persistence by means of a scheduled task to run "RemoteLibUpdater.exe" every three minutes.

The "RemoteLibUpdater.exe" binary is BURNYBEAR, which serves as a loader for "InitTest.dll," a modified version of MATCHBOIL, a C#-based loader capable of delivering secondary payloads. The new version has been codenamed MATCHBOIL.V2.

"At the same time, if 'RemoteLibUpdater.exe' is launched incorrectly, namely without specifying arguments, BURNYBEAR instead activates logic designed to exhaust computer resources (RAM and processor)," CERT-UA said.

CERT-UA is recommending that organizations update their WinRAR, 7-Zip, and Notepad++ software to the latest versions to prevent threat actors from exploiting any known vulnerabilities to facilitate follow-on attacks.

The disclosure comes as the U.S. government highlighted a phishing campaign orchestrated by the Russia-linked threat actor called Laundry Bear (aka CL-STA-1114, TA488, UNK_PitStop, and Void Blizzard) targeting Zimbra mail servers belonging to Western government and commercial organizations since at least July 2025.

The campaign employs a novel "half-click" exploit that abuses CVE-2025-66376 to deliver malicious JavaScript dubbed ZimReaper capable of harvesting email communications and other sensitive data.

"Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, Laundry Bear's latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service," the U.S. government said.

"The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group's involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first-both as a priority target and as a test bench for malicious cyber techniques before broader global deployment."

The disclosure also follows a report from Proofpoint about Russian threat actor's continued webmail targeting using half-click cross-site scripting (XSS) exploits to siphon valuable data as part of a campaign referred to as Operation RoundPress. The email security company is tracking the activity as TA458.

Since originally exposed by ESET in May 2025, the campaign has expanded in scope to target Kerio Webmail and SOGo Webmail, alongside Zimbra, mDaemon, and Roundcube. In March 2026, the hacking group is said to have exploited zero-day vulnerabilities in Kerio and the SOGo webmail platform (CVE-2026-8496). It was subsequently patched in version 5.12.8. In the case of Kerio, no CVE was issued as the webmail product was old and outdated.

It's worth noting that the campaign is different from Operation Roundish, which was disclosed by Hunt.io back in March and uses longstanding infrastructure that CERT-UA attributed to APT28 in 2024.

"Since at least July 2025, TA458 began removing stealing components, and swapping in interactive backdoor mechanisms to its Roundcube variant of SpyPress, to enable long-term access to the instance," Proofpoint researchers said. "SpyPress uses a second Roundcube exploit (CVE-2025-49113) that abuses Roundcube's file upload handler to trigger unsafe PHP deserialization."

The end goal is to trigger arbitrary code execution and install multiple backdoor or persistence mechanisms so as to ensure continued access in the face of disruption. TA458 has been described as likely a Russian military intelligence operation without any overlaps with APT28 (aka TA422).

"TA458 primarily targets Ukrainian government and Eastern European military and government entities across Albania, Greece, Moldova, and Türkiye, with occasional targeting of chemical, telecommunications, and technology firms," Proofpoint said. "TA458 continues to use SpyPress - an obfuscated JavaScript-based malware seen in Operation RoundPress - which the adversary modifies based on the targeted mail server."

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