Executive summary
July reporting put email access and the infrastructure around authentication at the centre of the threat picture: the UK's National Cyber Security Centre (NCSC) warned about a Zimbra espionage campaign, and Microsoft disclosed CaptiveCrunch activity affecting hospitality networks. Google announced action against the NetNut residential proxy network, while its threat-intelligence team published supply-chain mitigation guidance informed by recent open-source compromises. The US Cybersecurity and Infrastructure Security Agency (CISA) added 26 entries to its Known Exploited Vulnerabilities (KEV) catalogue, and the National Vulnerability Database (NVD) records 9,919 vulnerability publications for July. We assess it is likely (B2) that organisations will miss consequential access if their investigations stop at the first phishing message or endpoint alert; the reporting describes follow-on email collection, session abuse and compromised supporting infrastructure that require investigation across identity, devices and networks.
The month in numbers
The CISA catalogue released on 29 July, the final version before this review, contains 26 entries with July addition dates. All 26 have the ransomware-use field marked Unknown in this snapshot. This should not be converted into a claim that ransomware operators were absent: the field records what the catalogue identifies, rather than proving the non-existence of a particular use.
NVD's publication-date query for 1–31 July returns 9,919 Common Vulnerabilities and Exposures (CVE) records in its totalResults field. This publication count and the KEV addition count have different denominators. Neither is a count of July attacks, and their ratio should not be presented as an exploitation rate.
The ransomware figures below cover four explicitly selected ransomware.live group pages. Entries are counted by their Discovered date, using July boundaries; this is a bounded panel rather than a census of every extortion operation.
| Group page | July postings | Public source |
|---|---|---|
| The Gentlemen | 178 | ransomware.live |
| Qilin | 127 | ransomware.live |
| Deadlock | 85 | ransomware.live |
| DragonForce | 42 | ransomware.live |
| Four-page subtotal | 432 | Sum of the rows above |
Every posting is a criminal claim. These figures establish neither the number of unique confirmed victims nor the date of an underlying attack. The subtotal is a floor for the broader landscape, and the selected groups must not be described as the definitive top four worldwide. No victim organisation is named from these postings. A consistent discovery-date measure is useful for observing disclosure activity, provided its limited coverage remains visible beside the numbers.
Four themes in July reporting
1. Email viewing itself entered the exposure model
The NCSC's 23 July warning describes LAUNDRY BEAR activity against Zimbra Collaboration Suite. The agency and its partners assess the campaign as espionage almost certainly supported by the Russian state. They say the group has stolen email information from affected organisations since July 2025. In the reported beehive technique, viewing a crafted message within a vulnerable webmail service can be sufficient; a separate link click or attachment opening is not required.
NCSC urges patching and improved monitoring, and warns that the approach could be adapted to other vulnerabilities. That is a warning about potential adaptation, not evidence that every email platform is affected by the same exploit. The first operational step is therefore to identify the actual mail platform, deployed versions and exposure. Security awareness remains useful, but training users to avoid links does not directly address a case in which the reported trigger is rendering a message.
Our recommended investigation scope includes the mailbox and its access history, not just the message that started the alert. Preserve relevant mail and authentication evidence before routine deletion or account changes remove useful context. Record whether the affected service was vulnerable, what evidence of access exists, and what remains unknown. Avoid declaring a mailbox safe merely because no employee recalls clicking a link: that statement does not test the mechanism described in this advisory.
2. Travel connectivity became part of identity defence
In its 31 July CaptiveCrunch report, preserved in that day's capture, Microsoft describes traffic manipulation involving hospitality networks and captive portals since early May. Microsoft attributes the campaign to Storm-2945, which it assesses to be an operational sub-cluster of Midnight Blizzard. It reports redirection to phishing infrastructure and malware presented as browser or operating-system updates. At publication, the initial compromise route into the captive-portal networks remained under investigation.
Microsoft's report includes abuse of the legitimate device-code authentication process and malware intended to collect credentials and session material. Its recommendations include preferring private connectivity where practical, rejecting unexpected update prompts, and blocking device-code flow where it is unnecessary. The original July account is the basis of this review; later revisions to a living advisory are not used to fill gaps in what was known at month end.
For an enterprise travel programme, our recommendation is to turn that advice into a supportable procedure. Staff should know which connection options are approved and how to obtain help without following a portal's instructions to install software. Identity teams should document which applications require device-code authentication, who owns each exception and how it is monitored. Endpoint responders should include relevant cloud sessions in the incident scope when a travelling user's device is suspected of compromise, rather than assuming that removing a downloaded file resolves every consequence.
3. Proxy disruption changed infrastructure without settling attribution
Google announced on 2 July that it had acted against NetNut in coordination with the FBI, Lumen and other partners. Google says it disabled associated accounts and services used for malicious command and control, shared technical intelligence, and used Play Protect to warn users about and disable known applications incorporating the relevant software components. Google estimates the network at at least two million devices and says 316 distinct threat clusters used suspected exit nodes during a single week in June.
Google also cautions that proxy operators can buy capacity from competitors after their own infrastructure is degraded. Its announcement describes disruption and an expected wider effect, not permanent elimination of the ecosystem. The distinction is operationally useful: a change in source addresses may reflect a provider's response to disruption, rather than a new adversary or the end of an intrusion.
Our recommendation is to treat residential network origin as one contextual signal. Review it alongside the account, device, authentication method and subsequent actions. An analyst should be able to distinguish an unusual sign-in that merits investigation from an accusation about the household or organisation whose address carried the traffic. Likewise, an address appearing in reporting should not become the sole basis for attributing later activity to one of the hundreds of clusters Google observed using the wider service.
4. Supply-chain controls needed to follow the publishing path
GTIG and Mandiant's 30 July guidance distinguishes growing open-source repository and dependency compromises from traditional software-distribution compromises, which it assesses remain rare. The report draws on incidents in 2025 and the first half of 2026; it is not a count of attacks newly occurring in July. Its mitigation programme spans inventories, publisher and developer identity, isolated build execution, package handling and response exercises.
The useful question for a development team is how a newly accepted dependency can reach a privileged environment. Our recommendation is to document the actual sequence: source selection, review, installation, build, publication and deployment. At each step, identify the credential used and the evidence retained. Require an owner for exceptions such as installation scripts or privileged automation. Test the procedure against a deliberately revoked benign package so that the team can demonstrate how it finds affected builds and deployed artefacts.
The guidance should be implemented with application owners, rather than by copying every suggested control into production at once. A package quarantine, for example, needs an emergency update process; isolated builds need a controlled way to obtain required dependencies. Those are implementation decisions for the defender, not findings about the particular campaigns. Success should be demonstrated by the ability to identify and contain an affected release, including its credentials and downstream artefacts.
Actors and exploited vulnerabilities
The two espionage accounts above should remain distinct. NCSC names LAUNDRY BEAR in the Zimbra campaign. Microsoft attributes CaptiveCrunch to Storm-2945 and assesses a relationship to Midnight Blizzard. This review does not infer that they are the same actor from shared interest in email or Russian state-related attribution. The vendor or agency making each assertion remains attached to the name.
Selected entries from the historical CISA catalogue show how July's remediation work extended across web applications, identity infrastructure and network administration. This is a subset of the 26 additions, chosen to show different affected services.
| CVE | Product in CISA's record | Added in July | Ransomware use in snapshot |
|---|---|---|---|
| CVE-2026-48282 | Adobe ColdFusion | 7 July | Unknown |
| CVE-2026-55255 | Langflow | 7 July | Unknown |
| CVE-2026-15409 | SonicWall SMA1000 Appliances | 14 July | Unknown |
| CVE-2026-56155 | Microsoft Active Directory Federation Services | 14 July | Unknown |
| CVE-2026-46817 | Oracle E-Business Suite | 15 July | Unknown |
| CVE-2026-58644 | Microsoft SharePoint | 16 July | Unknown |
| CVE-2026-20316 | Cisco Secure Firewall Management Center | 29 July | Unknown |
Our recommendation is to attach each relevant entry to an accountable system owner, a verified exposure assessment and a remediation result. Keep compromise triage separate from the question of whether an update installed successfully. Where an appliance cannot provide sufficient investigative data, record that limitation explicitly and escalate the restoration decision. Neither a high publication count nor a long vulnerability list supplies that asset-specific judgement automatically.
Ransomware: administrative tooling and the limits of a sample
Cisco Talos's 28 July incident-response review reports on the second quarter, rather than July alone. Its detailed initial-access section says phishing accounted for more than half of engagements where the entry route could be determined. It also describes abuse of legitimate remote-management software, including a modified MeshAgent in a Sinobi engagement and Zoho Assist in activity associated with Warlock. These are observations from Talos's response work, not estimates for all organisations or all ransomware incidents.
For practitioners, the actionable distinction is between a legitimate tool and an authorised installation or session. Our recommendation is to retain a list of approved remote-management deployments with the team that owns them, expected management destinations and the process for emergency use. An alert should give the analyst enough context to compare activity with that record. A familiar vendor name should not by itself close the case, while an approved support session should not be treated as hostile merely because the same software appears in an incident report.
Unit 42's 10 July assessment of The Gentlemen describes a ransomware-as-a-service operation using multiple initial-access routes and custom tooling. Its recommendations include protecting endpoint security controls, investigating prior exploitation, restricting management interfaces and validating recovery capabilities. Its historical claimed-victim figures use a different presentation from this review's July discovery-date panel; they are not combined here into one trend line.
The wider response lesson is to rehearse the hand-off from suspicious administration to potential ransomware containment. Decide who can suspend an unrecognised management session, isolate a critical server, or preserve evidence before a rebuild. Include service owners in the exercise so that operational impact is considered before an emergency. These are preparedness recommendations, not a prediction that every intrusion using remote-management tools will culminate in encryption.
Policy, disruption and the ability to investigate
The NetNut action described above was July's principal disruption in the sources selected for this review. The other consequential public intervention concerned the design of network equipment. In its 29 July article on forensic visibility, NCSC argues that defenders need supported ways to obtain logs, configuration state and forensic data, rather than relying on improvised techniques or undisclosed vulnerabilities to investigate a device.
NCSC directs this message to buyers as well as manufacturers. For procurement teams, our recommendation is to convert it into a demonstration requirement: show how an authorised responder obtains useful evidence, how that evidence is protected, and what remains available if the device is suspected of compromise. Ask the vendor to explain retention limits and the effect of resets or upgrades. A marketing claim that a product supports logging is less useful than an exercised collection and restoration process.
This is guidance and a product-design expectation, not a new legal obligation asserted by this review. It belongs in operational planning because it affects the questions responders can answer after a suspected intrusion. The inability to reconstruct activity should be visible to incident decision-makers as uncertainty, rather than quietly being translated into a finding that nothing happened.
What to watch
Our assessment remains likely (B2): investigations confined to a single message or host will miss relevant access in cases resembling July's reported campaigns. The basis is the combination of email collection described by NCSC, device and session theft in Microsoft's July account, and Talos's observations of authentication abuse and incomplete investigative visibility. The assessment applies to those mechanisms; it is not a forecast of a measured percentage of future incidents.
For August, recommended checks are completion of relevant webmail patching and investigation, review of device-code authentication exceptions, verification of remote-management ownership, and an exercise that traces a compromised dependency through a build. Add one concrete network-device evidence-collection test. Record what was actually demonstrated, and retain an owner and due date for any gap. These steps offer a way to turn the month's reporting into decisions that can be inspected later.
July briefings
These weekly periods overlap July. The monthly figures use 1–31 July boundaries, so weeks extending into June or August cannot be added together without filtering their records back to July.
- Weekly threat briefing: 29 June–5 July 2026.
- Weekly threat briefing: 6–12 July 2026.
- Weekly threat briefing: 13–19 July 2026.
- Weekly threat briefing: 20–26 July 2026.
- Weekly threat briefing: 27 July–2 August 2026.
