Wednesday, 29 July 2026

Romanian public university UVVG Arad confirms a cyberattack on its IT infrastructure; a Qilin leak-site listing is the only thing linking an actor to it

The university's press release is specific about process and silent about substance. It states that a cyberattack was recently identified which affected the institution's IT infrastructure and the functioning of digital services used in academic and administrative activity, that the competent authorities were notified immediately — naming DNSC, the national cybersecurity directorate; ANSPDCP, the data-protection authority; and DIICOT, the organised-crime and terrorism prosecution directorate — and that technical teams are working with specialists on the gradual resumption of affected services (Aradon.ro, 2026-07-28). Radio România is direct about the gaps: the university has not specified which systems are unavailable, nor whether personal data was compromised or extracted, and authorities are yet to determine the nature of the attack, how the attackers entered the systems and the scope of any damage, with no timeframe announced for full restoration (Radio România, 2026-07-28). The notification of all three authorities at once is itself informative: DIICOT's involvement indicates a criminal referral, and ANSPDCP's indicates the university considered a personal-data breach at least possible, even while declining to confirm one.

The actor question should be read carefully, because the two available pieces of information do not actually touch. The Qilin ransomware operation listed the university on its leak site with an estimated attack date of 2026-07-26, two days before the university's disclosure (Ransomware.live, 2026-07-26). That listing is the only source for the connection: it carries no description text, and none of the Romanian outlets covering the incident — including the national broadcaster — mentions Qilin, ransomware, or any actor at all. So while the timing is consistent with an unresolved extortion negotiation, which is the ordinary explanation for a victim confirming a "cybersecurity incident" without naming a cause, nothing in the university's statement corroborates the claim, and treating the two as one confirmed story would be assembling an attribution the sources do not make.

Coordinated two-day cyberattack disrupts operational technology at 30+ Minnesota water and wastewater utilities — no authority has attributed it

The confirmed facts are narrow and worth stating precisely. Minnesota's technology bureau announced on 2026-07-28 that more than 30 communities had their water and wastewater utilities disrupted by a coordinated cyberattack on 26 and 27 July (StateScoop, 2026-07-28), a two-day event rather than a single-utility incident (Cybersecurity Dive, 2026-07-28). Where individual utilities described impact, it fell on field equipment rather than treatment processes: Plymouth stated the attack was limited to equipment connected via cellular communications at two water towers and multiple lift stations, and disconnected that equipment from the network to stop the attack and avoid retargeting during reconfiguration; Braham's water plant went offline, and the city later stated the outage was the result of a malicious cyberattack of computerised operating systems by unknown actors (StateScoop, 2026-07-28). Braham did ask residents to minimise water use while its tower held a limited quantity, and a later notice reported the plant back online (StateScoop, 2026-07-28) — a real if temporary consumption instruction. Separately, authorities in South St. Paul said they identified a cyberattack on Monday that impacted certain automated controls, and after implementing contingency procedures confirmed no major impact to drinking and wastewater treatment operations (Cybersecurity Dive, 2026-07-28). Multiple utilities stated water remained safe and no treatment-quality impact has been reported. Minnesota IT Services coordinated a response alongside the FBI, CISA and the EPA, with its chief information security officer describing a whole-of-government response that helped prevent more serious impacts (StateScoop, 2026-07-28).

What is not established matters as much. No authority has named an actor. The Center for Internet Security's senior director of threat intelligence stated the Minnesota attacks have not yet been attributed to any particular party and that it is unclear whether the programmable logic controllers CISA had warned about were involved, and separately noted that of the nation-state attacks on US water facilities in recent years, none has documented major downstream health impacts (StateScoop, 2026-07-28). The FBI confirmed only that it is aware and in contact with victims (Cybersecurity Dive, 2026-07-28). The reason Iran appears in coverage of this event is timing: the attack landed days after federal officials warned of state-linked groups targeting a wider set of industrial devices (Cybersecurity Dive, 2026-07-28) — a juxtaposition, not a finding. Treating it as attribution would be reading the calendar as evidence.

The transferable content sits in that separate advisory, and it is why this belongs in front of European water and energy operators despite the victims being American. AA26-097A documents actors using leased third-party infrastructure and the vendors' own engineering software — Rockwell Studio 5000 Logix Designer, Schneider EcoStruxure Control Expert, Siemens TIA Portal — to reach misconfigured, internet-facing controllers and pull down device project files, then re-upload files with modified or deleted logic (CISA and partners, 2026-07-22). At one victim the FBI observed a malicious project file downloaded to a PLC that retained ladder logic for downstream function but added logic overriding the instruction sets responsible for maintaining safe operating parameters, and the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators (CISA and partners, 2026-07-22). CISA is explicit that this represents no new vulnerability in the named products — it is opportunistic targeting of misconfiguration. The affected controller families are the same Rockwell, Schneider and Siemens lines that run European water, wastewater and district-energy plants, and in one instance access came through Dropbear SSH on a victim's modem, which is precisely the class of device Plymouth found affected.

Triage: engineering software connecting to a PLC and writing a project file is exactly what commissioning and maintenance look like, so the activity class is not the signal. The discriminators the advisory's own mechanics supply are provenance and timing: a project-file write originating from outside the engineering network or from leased hosting rather than an engineering workstation; a controller left in program or remote mode outside a change window rather than in RUN; and a logic change with no corresponding maintenance record. On the network side, protocol functions that modify programs or change controller mode are the ones to surface — connection attempts to controller-associated ports are ubiquitous background noise, whereas a mode change or program write is a discrete, auditable act.

Builds on: 2026-07-24/cyberav3ngers-plc-aa26-097a-schneider-siemens-expansion

STAC4749 runs Teams helpdesk vishing from attacker-owned .top domains into certificate-pinned Golang implants and Chaos ransomware in under 17 hours

The initial access here is entirely social, and the interesting part is what the operators changed. Contact comes as a Microsoft Teams chat or call from an IT-support persona; Sophos observed call durations from 90 seconds to over 20 minutes, most lasting two to two and a half (Sophos X-Ops, 2026-07-28). Earlier Teams-abuse campaigns spoofed onmicrosoft.com tenants, which gave defenders a tractable check. STAC4749 instead registers its own IT-themed domains under the .top TLD and populates them with plausible first-name/last-name employee accounts (Sophos X-Ops, 2026-07-28). That moves the detection question from "is this tenant genuinely Microsoft's" to "should this external domain be able to reach our users at all" — a policy question rather than a signature one. The persuasion goal is a remote-support session: Quick Assist initially, with the cloud-based RemSupp as fallback, and from April 2026 RemSupp by preference — Sophos assesses this is likely because it is less apt to appear on application blocklists (Sophos X-Ops, 2026-07-28). Lateral movement consistently began by enabling RDP on the initial host through Windows service reconfiguration via msconfig (Sophos X-Ops, 2026-07-28).

Two payload design choices are worth carrying into detection engineering. First, the Python backdoor — PyArmor-obfuscated, PyInstaller-packaged, able to run shell commands, collect system information and load further Python modules — retrieves its AES key and initialisation vector from a public code-hosting repository at runtime and uses them to decrypt its embedded configuration and payload (Sophos X-Ops, 2026-07-28). The key is therefore not in the sample, which defeats static key extraction and lets the operators rotate it by editing a public page. Second, the Golang implants embed CA certificates and will complete an encrypted connection only when the C2 server presents a matching issuer; Sophos found payloads sharing an issuer consistently talked to the same servers while different issuers meant separate infrastructure, and reads this as deliberate segmentation by payload or operational role (Sophos X-Ops, 2026-07-28). The practical effect is that a TLS-terminating proxy or a researcher's redirection attempt cannot complete the handshake, so interception-based analysis and sinkholing both fail unless the issuer is reproduced. Persistence evolved visibly across the campaign: HKCU Run keys masquerading as Realtek audio components from February, joined by WinAudio-themed names from mid-May, alongside .vbs scripts creating Startup-folder shortcuts named to look like SecurityHealth or OneDriveUpdate, sometimes with hidden attributes (Sophos X-Ops, 2026-07-28). In ransomware cases operators added DWAgent and AnyDesk for redundant access, and in one case a standalone reverse-SOCKS proxy supporting up to a thousand concurrent connections; encryption landed nearly simultaneously across endpoints, in one incident under 17 hours from initial access (Sophos X-Ops, 2026-07-28).

Triage: the remote-support tools in this chain are genuine software that IT departments use daily, so the tool itself discriminates nothing — and neither does the fact of an inbound Teams call. The discriminator Sophos's own guidance points at is provenance and initiative: a legitimate support session is requested by the user or arranged against an existing internal ticket, whereas this pattern is an unsolicited approach from an unrecognised external domain followed immediately by pressure to launch or install a remote-access tool. Operationally that means correlating remote-support process starts against your ticketing system, and treating a first-ever external Teams contact followed within minutes by an RMM installation as the sequence to alert on.

Mirage Kitten (UNC1549) fields the NightLedger backdoor and two WebSocket tunnelers, one of them built to negotiate through corporate proxies with the victim's own SSO

The load-bearing detail in Kaspersky's write-up is not the backdoor's feature list but how it gets to run and how it gets out. NightLedger ships as a file named to impersonate SspiCli.dll and is placed alongside a legitimate AppVShNotify.exe; that binary does not import SspiCli.dll directly, but it does import RPCRT4.dll, which delay-loads SspiCli.dll at the moment it invokes an RPC API requiring authentication — so the malicious module is pulled in through the normal search order, under a legitimate vendor process, and forwards the expected exports to the genuine DLL so the host keeps functioning (Kaspersky Securelist, 2026-07-28). Two properties make this awkward to catch: the load is triggered by ordinary RPC activity rather than by anything the malware does, and because exports are proxied there is no crash or functional break to notice. The backdoor beacons over HTTPS and dispatches 16 numeric commands, among them process execution, identity and host/network reconnaissance, process listing and termination, directory and drive enumeration, file copy, deletion, upload and download, screenshot capture, DLL loading, beacon-interval changes, and collection of the Windows domain-join diagnostic log, which Kaspersky describes as a diagnostic log generated during domain and workgroup join, unjoin and related network-setup operations (Kaspersky Securelist, 2026-07-28). Kaspersky attributes NightLedger to Mirage Kitten on code and behavioural similarity to the group's historical implants, and observes that its command dispatch resembles TWOSTROKE, an implant previously documented as the same actor's (Kaspersky Securelist, 2026-07-28).

The tunnelers are the part worth a hunt cycle, and the two are not equivalent. Kaspersky describes ArcBridge as the simpler tool: a WebSocket-style channel with an embedded configuration block carrying C2 host, port, a retry value, an SSL flag and a likely implant identifier, driven by two commands — one to open a tunnel session and one to resolve a hostname (Kaspersky Securelist, 2026-07-28). BridgeHead is the one built for networks that do not simply let traffic out: presented with an HTTP 407 proxy-authentication challenge it queries which schemes the proxy supports, selects Negotiate in preference to NTLM, supplies null credentials so Windows fills in the logged-in user's single-sign-on context, and retries — falling back to exponential connection retry capped at a minute when that fails (Kaspersky Securelist, 2026-07-28). The consequence for defenders is that the outbound channel authenticates as a real employee to the real proxy, so it appears in proxy logs as that user's traffic. Once established, the operator drives everything server-side and the implant only forwards, which Kaspersky describes as turning the host into a relay node so that resulting TCP traffic appears to originate inside the victim's network (Kaspersky Securelist, 2026-07-28). BridgeHead also refuses to run outside its intended target: a hardcoded 3-character value must appear as a substring of the lowercased Windows username, and the implant exits silently otherwise — behaviour Kaspersky reads as evidence of prior internal reconnaissance and per-target tailoring of each binary (Kaspersky Securelist, 2026-07-28). Victims span government and SMB environments in Jordan and Tanzania, aviation in Pakistan, telecommunications in Ethiopia, finance in Burkina Faso and organisations in Egypt (Kaspersky Securelist, 2026-07-28).

Triage: AppVShNotify.exe loading SspiCli.dll is normal and expected — the parent process, the module name and the RPC trigger are all legitimate, so none of them discriminates on its own. The signal is the loaded file's identity: SspiCli.dll resolving from the same directory as the executable rather than from the system directory, and not carrying a valid Microsoft signature. On the network side, an authenticated proxy session that upgrades to a long-lived WebSocket and then carries a sustained, bidirectional flow to a single destination is the shape to look for; ordinary user browsing through the same proxy does not hold one connection open as a steady tunnel.

CVE-2025-15467 — Siemens Desigo CC: a vendored OpenSSL CMS parsing overflow gives pre-auth code execution, and the V7 family still has no fix (CVSS 9.8)

The Desigo CC flaw is a vendored-dependency problem with an unusually clean exploitation precondition. When OpenSSL parses a CMS AuthEnvelopedData structure that names an AEAD cipher, the initialisation vector encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without checking that the encoded length fits the destination, so an oversized IV produces a stack out-of-bounds write (Siemens ProductCERT, 2026-07-14); OpenSSL's own advisory confirms the flaw sits in CMS AuthEnvelopedData parsing and rates it High, and states that OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable while 1.1.1 and 1.0.2 are not (OpenSSL, 2026-01-27). The load-bearing detail for defenders is when the overflow fires: it happens during length parsing, before the AEAD tag is verified, so an attacker needs no valid key material and no credential — only a path by which the process is handed a crafted CMS or S/MIME message. Siemens is affected because Desigo CC, its building-management platform, vendors the library for that parsing path, and a public command-execution proof-of-concept for the underlying OpenSSL flaw is already published — though it achieves a shell against a build compiled with stack protection and fortification disabled and ASLR off, and OpenSSL's own advisory notes that exploitability to remote code execution depends on platform and toolchain mitigations (guiimoraes, 2026-07-28; OpenSSL, 2026-01-27).

The remediation picture is where this stops being routine. Siemens' structured advisory splits the product line three ways: family V9 is fixed at 9.0.1, family V8 is fixed by patch V8.0 QU2.0021, and family V7 — all versions — carries the remediation category none_available with the plain text "Currently no fix is available" (Siemens ProductCERT, 2026-07-14). A pre-authentication memory-corruption bug with public exploit code and no vendor patch, in software that runs heating, ventilation, access control and life-safety integration for real buildings, is not something a quarterly maintenance window addresses. For any V7 estate the only available control is the network position: Siemens points to its own segmentation guidance, which in practice means the Desigo CC server should be unreachable from any network that can hand it untrusted certificate or message content.

The same-day Mendix advisory is a different failure mode with a similar bottom line. Siemens describes it not as a code bug but as an access-control-model gap — Mendix's documentation does not adequately convey the reserved behaviour of the built-in System.User entity, and the common consequence is that the anonymous user role reaches every stored user record even though no access rights were explicitly configured for it (CISA, 2026-07-28). The mechanism matters because it defeats the obvious defence: Siemens states that System.User carries platform-enforced access rules that cannot be overridden or restricted by access rules defined on a specialization, so a developer who wrote XPath constraints on a System.User specialization and believed the data was fenced off is wrong, and the remediation is to enforce the restriction at the App Security role-management level instead (Siemens ProductCERT, 2026-07-14). All Mendix Runtime versions are affected and there is no code patch to wait for.

Detection: for Desigo CC the honest observable is thin, because a pre-auth memory-corruption attempt against a vendored parser leaves little application-level trace — the telemetry class to watch is process-crash and crash-dump events on hosts running Desigo CC server components, correlated in time with inbound content that would reach a CMS, PKCS#7 or S/MIME parsing path, since a failed overflow attempt is far more likely to crash the process than a successful one is to log anything. For Mendix the observable is much more direct and lives in application access logs: unauthenticated requests to the app's REST or OData endpoints that return user records the requester has no relationship to. Triage: on the Mendix side, an anonymous endpoint returning a single record tied to the requester's own session can be normal application behaviour, while an anonymous request enumerating user records beyond the requester's own is the signal — the discriminator is the breadth of the result set, not the fact of an unauthenticated call.

CVE-2026-0769 — Langflow: an unpatched pre-auth eval-injection RCE that VulnCheck observes being exploited, and that CISA KEV does not list

Two facts about the same identifier, published six months apart, combine into something a vulnerability-management process organised around CISA KEV will not see. The first: CVE-2026-0769 is an eval injection in Langflow's eval_custom_component_code function, where a user-supplied string reaches Python execution without proper validation, and Zero Day Initiative states plainly that authentication is not required to exploit it (Zero Day Initiative, 2026-01-09). ZDI published it as a 0-day advisory — its disclosure timeline records the report going to the vendor in July 2025, two follow-up requests over the following months, and then notice of intent to publish as a 0-day advisory — and its mitigation guidance is correspondingly blunt: restrict interaction with the product, because there is nothing to upgrade to (Zero Day Initiative, 2026-01-09). The CVE record ZDI filed as CNA carries CVSS 9.8 and lists only the single tested version, 1.3.2, with a default status of unknown (MITRE CVE Record, 2026-01-23).

The second fact is that this is no longer theoretical. VulnCheck reports observing attackers use exploits against CVE-2026-0769 to gain initial access to Langflow, then harvest credentials — it assesses these as likely for services such as OpenAI and Claude — deploy cryptominers, and attempt lateral movement, and states explicitly that the vulnerability has not been added to CISA KEV (VulnCheck, 2026-07-28). That framing is worth carrying: VulnCheck describes Langflow here as an AI-workflow platform being targeted for the model-provider credentials it holds, which is a different economic motive from generic web-application RCE and explains the credential-then-cryptominer sequence.

The KEV gap is the part with immediate procedural consequence, and it comes with a trap. This pipeline verified the absence directly against the current catalog rather than relying on VulnCheck's assertion: KEV carries five Langflow entries, and CVE-2026-0769 is not one of them — but CVE-2026-0770 is, and it is a different vulnerability, one this pipeline already covers. Two identifiers differing in the final digit, one KEV-listed with a patch path and one neither listed nor patched, is exactly the shape that produces a false all-clear when a ticket is closed against the wrong record. Any process that answers "are we exposed to Langflow?" by checking KEV membership will return a clean result for the flaw that has no fix.

Detection: with no patch to apply, the operative telemetry is on the host and at its egress. Langflow runs Python, so the process-creation observable is the Langflow service process spawning children it has no business spawning — shells, package managers, download utilities, or a second Python interpreter outside the application's own worker pattern. In egress telemetry, look for outbound connections from the Langflow host to mining pools or to destinations unrelated to the model providers the application legitimately calls, and for authentication events at your model providers originating from addresses that are not the Langflow host. Triage: Langflow's whole purpose is executing user-authored component code, so "Python executing dynamic code" is the application working as designed and is not by itself a signal; the discriminators are the process's children stepping outside the interpreter, and egress to destinations the application has no configured relationship with. Hardening: the only preventive control ZDI offers is restricting who can reach the product at all, which for most estates means removing internet exposure entirely and putting authenticated proxy access in front of the remainder.

Builds on: 2026-06-11/cve-2026-5027-langflow-unauthenticated-path-traversal-to-arb · 2026-07-22/langflow-cve-2026-0770-exploited-ncsc-nl-15-cve-batch

CVE-2026-63077 — JetBrains TeamCity On-Premises: unauthenticated RCE through the agent-polling protocol, every on-prem version affected (CVSS 9.8)

JetBrains' advisory is short on mechanism by design and unambiguous on reach: an unauthenticated attacker with HTTP(S) access to a TeamCity On-Premises server can bypass authentication checks and run arbitrary operating-system commands with the privileges of the TeamCity server process, and every On-Premises version ever shipped is affected (JetBrains, 2026-07-27). The reachable surface is the agent-polling protocol — the channel distributed build agents use to check in with the central server for job assignments and configuration. JetBrains' own framing is that exploitation of the flaw requires no authentication and that the attacker bypasses authentication checks by way of that protocol, so there is no credential, session, or user interaction standing between a network-reachable server and command execution (JetBrains, 2026-07-27). The flaw was reported privately on 2026-07-10 by Antoni Tremblay, and JetBrains states it is not aware of any active exploitation as of publication (JetBrains, 2026-07-27); the CVE record filed by JetBrains as its own CNA carries the flaw as CWE-502, deserialization of untrusted data, at CVSS 9.8 (MITRE CVE Record, 2026-07-27).

The reason this warrants moving ahead of the ordinary patch queue is what a build server is, not the score. A TeamCity server holds the credentials its pipelines deploy with, the signing material its artifacts are stamped with, and write access to the outputs every downstream consumer trusts — so command execution as the server process converts into a durable ability to alter what future builds produce. Public exploitation of the present flaw has not been observed, and the honest reading of that is a clock rather than an all-clear — JetBrains withheld the gadget chain, but "all versions affected" plus "no authentication" plus a widely deployed, easily fingerprinted product is a combination that historically closes quickly once someone reconstructs the path.

Detection: the observable is in the web-server or reverse-proxy access log in front of TeamCity and in process-creation telemetry on the server host. Requests to the agent-polling endpoint arriving from addresses that are not your registered build agents are the first signal, and the second — the one that matters if the first was missed — is any child process spawned by the TeamCity server process that is not part of a build it was asked to run: shells, interpreters, or network utilities parented to the server rather than to an agent's build step. Triage: the agent-polling endpoint legitimately receives continuous check-in traffic from your build fleet, so request volume to it discriminates nothing on its own. Two things do. The source address set is finite and knowable — your registered agents are an inventory, so polling traffic from anything outside it is the anomaly. And on the server host, legitimate command execution belongs to agent processes running build steps; the server process itself spawning an interpreter or a network utility is not a quieter version of normal activity but a different thing entirely. Hardening: apply 2025.11.7 or 2026.1.3, or the security-patch plugin on 2017.1 and later, and treat the agent-polling interface as an internal service — if the only reason it faces the internet is that some agents live outside the network, a VPN or reverse tunnel for those agents removes the exposure that makes this flaw reachable at all.

CVE-2026-59243 — Apache Airflow FAB provider: the Azure AD OAuth login decoded ID tokens with signature verification off by default, letting anyone log in as Admin

Apache's own disclosure describes a straightforward broken trust boundary in the Flask-AppBuilder auth-manager provider for Airflow: the Azure AD OAuth login path decoded the identity-provider-supplied JWT ID token with verify_signature left at False, which means the login logic read the token's claims without ever checking that Azure AD had signed them (Apache Airflow security team, 2026-07-28). The consequence is that the token's alg header can be set to none — or the signature simply forged — and the deployment will accept whichever username the attacker writes into the claims, up to and including an account holding the Admin role; BSI's republication states the same outcome in its own words, that a remote anonymous attacker can bypass security measures and obtain administrator rights (BSI CERT-Bund, 2026-07-27). This is a shipped default rather than a customer misconfiguration: nothing beyond selecting Azure AD OAuth as the login method is required to be exposed, and Apache notes the equivalent Authentik login path was already defaulting to True (Apache Airflow security team, 2026-07-28). Neither party reports in-the-wild exploitation, and the fix landed essentially alongside the disclosure — Apache's advisory and the remediation both dated 2026-07-27/28.

Why it matters beyond the CVSS-shaped hole in the record: Airflow instances are orchestration control planes that hold connection objects and variables for the systems they schedule against — database credentials, cloud service-account keys, API tokens — and an Admin-role session is enough to read and edit them, or to author a DAG that runs attacker-chosen code on the workers. Detection: the relevant telemetry class is the application's own authentication events plus the reverse proxy or web-server access log in front of the Airflow webserver — look for successful logins through the OAuth callback whose ID token carried an alg of none, or whose signature cannot be validated against the tenant's published JWKS, and for Admin-role sessions originating from the OAuth path rather than from the accounts your identity provider actually grants that role to. Triage: legitimate Azure AD OAuth logins arrive with a token signed by a key published in the tenant's JWKS document and resolve to a user your directory can account for; the discriminator is a token that validates against no published key, or an authenticated session whose named principal does not exist as an assigned Airflow Admin in the identity provider. Hardening: upgrade the provider to 3.7.3; where the version is pinned, set verify_signature=True explicitly, and treat any Admin session created through this login path before the upgrade as suspect — rotating the credentials and connection secrets stored in that Airflow instance is the part an upgrade does not do for you.

LegacyHive: a public Windows technique that redirects a profile's Local AppData into the NT Object Manager namespace via offline hive edits, reproduced on fully patched systems

LevelBlue is explicit that LegacyHive is not a traditional vulnerability — like the rest of the Nightmare Eclipse series it explores a corner of Windows rather than introducing a bug, in this case profile initialisation and registry hive loading (LevelBlue SpiderLabs, 2026-07-27). The chain runs in seven steps and every one uses documented, legitimate machinery. It first creates a directory hierarchy inside the NT Object Manager namespace via NtCreateDirectoryObjectEx called from user mode, which LevelBlue notes is itself unusual because normal applications almost never create Object Manager namespaces after system initialisation, then builds native Object Manager symbolic links inside it with NtCreateSymbolicLinkObject — not Windows shortcuts or NTFS junctions — to form the redirection layer (LevelBlue SpiderLabs, 2026-07-27). It then opens a helper account's ntuser.dat directly and edits it offline through Microsoft's Registry Offline API, replacing the Local AppData value under Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders with the redirected namespace path, before saving the hive back over the original (LevelBlue SpiderLabs, 2026-07-27).

The timing step is what makes it reliable rather than racy. Instead of retrying until it wins, the exploit takes a batch opportunistic lock on UsrClass.dat, which pauses execution until profile initialisation reaches the expected point — LevelBlue's framing is that the exploit does not fight the Windows startup process but uses Windows' own synchronisation features to control it (LevelBlue SpiderLabs, 2026-07-27). It then launches a process as the helper user via CreateProcessWithLogonW with LOGON_WITH_PROFILE — the point being not execution but forcing a normal profile load that consumes the tampered hive — and validates success through RegOpenUserClassesRoot. Cleanup removes temporary files but leaves the modified registry configuration and namespace redirection in place, so the persistence lives in on-disk state rather than in a process or scheduled task (LevelBlue SpiderLabs, 2026-07-27).

Two facts bound how much this should worry a defender, in opposite directions. Downward: the released proof-of-concept requires the attacker to control a low-privileged account and hold valid credentials for a separate helper account on the same machine, which LevelBlue says makes it more useful as a post-compromise capability than a standalone attack, and notes those limitations were intentionally introduced before publication to discourage immediate abuse (LevelBlue SpiderLabs, 2026-07-27). This is not remote, not pre-authentication, and not privilege escalation from nothing. Upward: what the attacker does not need is the credentials of the account whose profile data they end up reaching — that is the whole point of the technique — and LevelBlue's teams reproduced the complete chain on fully patched Windows with July 2026 updates installed, with no Microsoft mitigation existing for this class of abuse (LevelBlue SpiderLabs, 2026-07-27). LevelBlue also cautions that the published code demonstrates the technique rather than exhausting it, and expects variants to change how profile loading is triggered or which hives are targeted while relying on the same building blocks.

Triage: every individual operation here is legitimate — offline hive editing, an oplock on a profile hive, a logon-with-profile process launch — and LevelBlue's explicit position is that each is legitimate in isolation while observing them together in a short window is highly unusual and well suited to behavioural correlation. Note specifically that the target executable carries no discriminating value: LevelBlue demonstrates the PoC's notepad.exe is trivially substitutable, so detection must anchor on the calling pattern — a cross-account CreateProcessWithLogonW using LOGON_WITH_PROFILE, routed through the seclogon service — rather than on any process name.

CVE-2026-16232 root cause — Check Point SmartConsole accepted a caller-supplied SIC distinguished name as identity, and the exploitable Trusted Clients setting was the default

UPDATE · originally covered CVE-2026-16232 — Check Point SmartConsole: authentication bypass to full admin, exploited in the wild (CVSS 9.1) (2026-07-23)

the earlier entry recorded that this Check Point Security Management authentication bypass was being exploited in the wild and had been added to CISA's KEV catalog, but not how it worked. Rapid7 Labs has now published the mechanics, reverse-engineered from decompiled Java across a vulnerable R81.20 Jumbo Hotfix Take 146 build and the patched Take 158 (Rapid7 Labs, 2026-07-28).

The root cause is a trust boundary drawn in the wrong place. A SmartConsole login crosses two generations of management-plane plumbing: the legacy FWM/CPMI service on TCP 18190, which uses Check Point's SIC certificate-based trust mechanism, and the newer CPM/DLE SOAP service on TCP 19009 under the /cpmws/ path (Rapid7 Labs, 2026-07-28). In the vulnerable build, the method that authenticates a remote application preferred whatever SIC distinguished name the caller supplied, falling back to the DN bound to the authenticated peer certificate only when the caller supplied none — so a remote client that simply copied the management server's own SIC DN into that field was accepted as that identity, with no client certificate ever presented (Rapid7 Labs, 2026-07-28).

What turns that identity confusion into full administrative control is a second, separate authorization shortcut. Holding the forged application identity, the attacker issues a gen-sso-token request to the legacy FWM service claiming system_admin with all bits set across the permission mask; Rapid7's decompilation shows FWM allows that command before the normal permission-mask check whenever the client is treated as a Check Point config administrator — which the forged identity guarantees (Rapid7 Labs, 2026-07-28). The resulting SSO ticket is then redeemed through the ordinary SmartConsole login path for a full-administrator session able to modify security policy and configuration (Rapid7 Labs, 2026-07-28). The Take 158 patch narrows the caller-supplied-DN path to loopback CN=siclocal traffic only, binds remote callers to their authenticated peer certificate DN regardless of what they supply, and rejects a mismatch with an explicit logged error (Rapid7 Labs, 2026-07-28).

The operationally consequential sentence is about configuration, not code: Rapid7 states exploitation needs network access to the Management Server plus a Trusted Clients configuration that does not restrict GUI clients, and that this was a default setting in its testing (Rapid7 Labs, 2026-07-28). That sits in direct tension with the vendor's own framing recorded in the original entry, where Check Point describes the flaw as affecting only a very specific configuration. The two positions are not reconcilable from the public record, and the difference decides how much of an estate is in scope: on Rapid7's reading an unpatched management server is exploitable as shipped, on Check Point's it is exploitable only where the configuration departs from the norm. A defender sizing exposure should plan against the former and verify the Trusted Clients setting directly rather than assuming either. Detection, for that retrospective question: the patched build logs a rejection when a supplied DN does not match the authenticated certificate DN, so on patched servers that log line is a direct attempt indicator; on servers that were unpatched during the window, the telemetry to reconstruct from is the management server's own administrator audit trail — a full-administrator session, and any policy or configuration change it made, that cannot be tied to a known administrator authenticating from a known client. Triage: legitimate SmartConsole administrator sessions originate from your operator workstations and correspond to named accounts your directory can vouch for; the discriminator is an administrator-privileged session whose client address falls outside the Trusted Clients set you intended, or a policy change with no corresponding named-operator login.

Talos IR Trends Q2 2026: ransomware operators ran their command-and-control through legitimate RMM agents, authentication abuse hit two-thirds of engagements, and missing logs stopped root-cause determination outright

Quarterly incident-response reports are usually read for their percentages, which is the least useful thing in them. The Q2 2026 edition from Cisco Talos Incident Response is worth a deep read for a different reason: it puts three specific intrusion chains on the public record with enough sequence to hunt against, and it documents a visibility failure that stopped Talos's own responders from answering the two questions every incident turns on (Cisco Talos Incident Response, 2026-07-28).

Sinobi: the RMM agent was the C2. Talos IR responded to Sinobi ransomware for the first time in April 2026 — a ransomware-as-a-service operation active nearly a year with minimal public reporting on its operators. The chain reads as a deliberate exercise in staying inside the shape of normal administration. Rather than deploying a bespoke implant, the operators used a trojanized MeshAgent binary — the agent component of the open-source MeshCentral remote-management platform — as their primary command-and-control mechanism, a tactic Talos states had not previously been associated with the group (Cisco Talos Incident Response, 2026-07-28). Installing it as a SYSTEM-level auto-start service collapsed persistence and privilege into the same step: no separate escalation, and boot survival from the outset. The channel was encrypted WebSocket to an attacker-controlled server, which matters because genuine MeshAgent traffic is itself WebSocket-based — Talos's assessment is that this let the actor blend malicious traffic with legitimate remote-management activity and hold undetected access for approximately three days before deploying ransomware (Cisco Talos Incident Response, 2026-07-28). Lateral movement was enabled by a service account whose weak password was cracked after being obtained from the domain credential store ntds.dit, and the operators moved through the network over RDP and WinRM. The endgame is the part worth dwelling on: rather than pushing the payload host by host, the actor deployed ransomware across the entire domain using a malicious Group Policy Object logon script, encrypting with the .SINOBI extension alongside exfiltration staging via rclone.exe (Cisco Talos Incident Response, 2026-07-28). Talos reads the GPO deployment as evidence of genuine enterprise-architecture understanding, and expects the group to keep weaponising legitimate tools precisely because they bypass signature-based alerting.

Warlock and the unattended agent. In a separate engagement, Talos observed Warlock operators — also tracked as Storm-2603 — deploying an installer for the Zoho Assist Unattended Agent, a capability designed to allow administrative remote control of an endpoint with no user logged in, and states it had not previously seen this tool attributed to Warlock (Cisco Talos Incident Response, 2026-07-28). That engagement did not reach encryption, but Talos notes the activity was consistent with a Warlock attack it observed in May 2026 that did. The pattern across both ransomware cases is the same substitution: where a defender's model expects a malicious binary, there is a legitimate, signed, commercially supported remote-administration product instead — which is why Talos's own recommendation shifts from signature detection to behavioural monitoring and application allowlisting that prevents unauthorised binaries from running as services.

UAT-11764: phishing that grows its own target list. From April 2026 and still ongoing in late June, Talos tracked a QR-code phishing campaign against primarily Australian organisations, attributing it to a newly designated actor. Delivery is auto-generated, victim-tailored PDF documents carrying embedded QR codes — a shape chosen to sit outside what email-gateway text and link scanning inspects. The codes lead to Microsoft 365 credential-harvesting pages; on success the operator accesses the mailbox, creates inbox rules to hide incoming mail and reduce the victim's visibility of the compromise, stages follow-on malicious documents on SharePoint, and then sends further internal and external phishing using that mailbox's own contact list (Cisco Talos Incident Response, 2026-07-28). Talos assesses with high confidence that the actor will almost certainly continue, using each newly compromised mailbox's contacts to expand reach and sustain momentum (Cisco Talos Incident Response, 2026-07-28). The tradecraft insight Talos draws is that the operation leans on trusted infrastructure — SharePoint and Microsoft 365 — rather than attacker-registered domains, so reputation-based controls have nothing to fire on. The same report profiles ARToken, the phishing-as-a-service panel this pipeline already tracks, noting it exposes over 80 API endpoints covering device-code phishing, primary-refresh-token persistence, mailbox access and SharePoint exfiltration, and bypasses multi-factor authentication through the OAuth device-authorisation flow rather than by stealing a password.

The two cross-cutting findings. Authentication abuse was the most prevalent weakness Talos recorded, in 65% of its engagements against 35% the previous quarter — and the composition is more useful than the share: adversaries defeated or bypassed multi-factor authentication using adversary-in-the-middle proxies and session-token theft, MFA-fatigue attacks, registration of attacker-controlled devices for authentication, and legacy authentication protocols that circumvent MFA altogether (Cisco Talos Incident Response, 2026-07-28). Three of those four defeat a correctly configured push-based MFA deployment, which is the deployment most organisations have. The second finding is the one to take to a budget conversation. Insufficient logging and visibility appeared in 42% of engagements against 18% the previous quarter, and Talos enumerates what that meant in practice: domain-controller security logs retained for only a few hours, host event logs truncated or overwritten before capture, absent NetFlow preventing reconstruction of external authentication and exfiltration, on-device-only logs that adversaries deleted, and cloud telemetry whose retention did not reach back to the true initial-access date. Talos states plainly that in several engagements these gaps prevented definitive determination of the initial access vector or the scope of data exfiltration (Cisco Talos Incident Response, 2026-07-28). That is not a hygiene observation — it is a statement that the questions a board, a regulator and a data-protection authority all ask first were unanswerable. Talos's remediation names 90 days of centralised retention as a minimum, logs forwarded off-device so they survive tampering and rebuilds, and process-creation, command-line and cloud-API auditing enabled.

Also recorded: exposed or unpatched internet-facing infrastructure was the third-ranked weakness at 31%, with ToolShell, an older Telerik UI deserialization flaw and SD-WAN/VPN appliance CVEs among the named examples; and unlimited outbound email thresholds enabled propagation in almost 15% of engagements, illustrated by a single compromised mailbox that sent over 6,600 phishing and spam messages before containment — a concrete number worth borrowing as an alerting threshold, since Talos rightly calls outbound rate-limiting low-effort and high-impact. On targeting, healthcare led for the second consecutive quarter at 17% of engagements, with public administration and manufacturing at 14% each; Talos's read is that the three share a critical lack of downtime tolerance, and it notes that almost all targeted public-administration organisations were local governments and that targeted manufacturers were high-value industrial-supply-chain entities where disruption cascades downstream. For a constituency built around cantonal and communal administration and critical-infrastructure operators, that is the sentence in the report with the most direct read-across — the segment being hit is not central government but the municipal tier, and the reason given is operational intolerance of downtime rather than data value.

Triage: every mechanism in the ransomware chains is normal administration, and Talos's explicit position is that this is why they were chosen — so no single event discriminates and the correlation has to carry it. For remote-management agents the discriminator is provenance against inventory: a genuine MeshAgent or Zoho Assist deployment is provisioned by your own management server onto an asset of record and appears as an expected service, whereas the malicious instance is an agent-named SYSTEM service on a host with no deployment of record. For the lateral movement, the discriminator is the identity rather than the protocol: RDP and WinRM between servers is routine, but a service account interactively authenticating across hosts is not what service accounts are for, and that is the question an access review can settle in advance. For the GPO step, the discriminator is change provenance — a logon-script modification is a discrete, auditable act with an expected author and change window, so an unattributed edit to a domain-wide policy object is high-fidelity on its own.