The Red Thread Weekly Wrapup: Issue #19
Categories: IT Risk Management | Information Security | Vulnerability Scanning
I spent part of this week reviewing incidents that, on the surface, looked unrelated. One involved product lifecycle management software. Another involved Azure tenants. A third traced back to an open-source security scanner. The fourth involved vulnerabilities that had already been patched but were still finding their way into active attacks.
The common thread was clear: attackers were not breaking into something an organization had never heard of. They were using tools, accounts, permissions, and software that the organization had already trusted.
That is the red thread for Issue #19.
Windchill Put Engineering Data in the Extortion Line
I have worked with manufacturing and engineering organizations long enough to know that their most valuable data does not always sit in the systems executives first think about when they hear “cybersecurity.”
It may sit inside a product lifecycle management platform. It may be embedded in engineering drawings, supplier records, product specifications, design history, photographs, project files, or technical documentation. Those systems are essential to the business, but they are not always included in the same security conversations as email, finance, or customer databases.
That gap is exactly what made the Cl0p campaign against PTC Windchill and FlexPLM so concerning.
The campaign exploited CVE-2026-12569, an improper input validation flaw that allowed remote code execution against affected instances. Reporting from SecurityWeek indicates that Cl0p named more than 40 alleged victims, including Shell, Philips, Fiserv, Zebra Technologies, Ingersoll Rand, and others. GE was also named before being removed from the group’s leak site, while several companies investigated or confirmed incidents involving specific systems.
This was not primarily a story about systems being encrypted and operations stopping overnight. It was a data theft and extortion campaign. Cl0p took information and then applied pressure by threatening disclosure.
The technical detail matters because it shows how deeply attackers understood the application. BleepingComputer reported that the custom Java web shell was built specifically for Windchill. It could map file repositories, decrypt stored credentials, access application data, and retrieve files through the platform’s own internal functions.
From a business perspective, I would ask three basic questions. Do I use Windchill or FlexPLM anywhere in my environment? Is any instance exposed to the internet? Can I prove that the patch was applied and that the system was checked for signs of compromise?
I would also ask who owns the answer. If the system is managed by engineering, a subsidiary, or a third-party hosting provider, that does not remove executive accountability. It makes ownership more important.
Azure Shows Why Identity Is the Perimeter
The second story involved an alleged theft of 3.6 million Azure account records from major companies. The claims named McDonald’s, Tata Consultancy Services, Vodafone, Gap, HCL Technologies, IHG, Kyndryl, and others.
I want to be precise here: not every company named in the claims has confirmed a breach, and some have said the data was old, limited, or not evidence of a compromise. But the method described is still important. The attacker claimed to have accessed Azure and Entra environments using compromised credentials.
As BleepingComputer reported, the advertised records included names, email addresses, phone numbers, job titles, employee identifiers, service accounts, and other directory information. SecurityWeek’s coverage noted that some datasets appeared to include privileged account information and service account details.
That information has value even when it is not immediately sensitive. It gives an attacker a map of the company: who works there, who reports to whom, which accounts may have elevated access, and which people are likely to respond to a convincing request.
The lesson I take from this is straightforward. A strong cloud provider does not eliminate identity risk. Large security teams do not eliminate identity risk. Identity becomes the perimeter when a stolen password, weakly protected account, or over-privileged service identity can reach sensitive systems.
I would want to know how much of my environment is protected by phishing-resistant or otherwise strong MFA. I would want to know whether conditional access is actually enforced for administrators, contractors, service accounts, and remote access. I would want to know which identities can reach sensitive data and whether those permissions still make business sense.
A password reset is not the same thing as identity security. I need to understand the permissions attached to the account, the devices from which it was used, and whether an attacker could have created persistence elsewhere.
The LiteLLM Follow-Up Is About Whether Remediation Actually Worked
Last week, I wrote about the LiteLLM supply chain compromise. This week’s reporting made the story more serious because it clarified both the original path and the weakness in the response.
The primary initial vector was not LiteLLM itself. It was Trivy, the open-source vulnerability scanner. The compromise moved through software development and build environments, where tools are automatically trusted and allowed to execute with access to credentials, tokens, and cloud secrets.
SecurityWeek’s follow-up reported that the Trivy compromise was responsible for most of the initial exposure. A separate Tech Times report described 153 gigabytes of stolen data tied to thousands of corporate domains and reported that credentials taken months earlier were still working at a major technology company.
That last point is the one I want executives to remember.
Remediation is not complete because a team removed a malicious package. It is not complete because someone reported that credentials were rotated. It is complete only when I can verify that every exposed credential was identified, replaced, tested, and prevented from being reused.
I would ask for evidence that the old keys no longer work. I would ask whether cloud audit logs were reviewed from the date of the compromise forward. I would ask whether CI/CD systems, build runners, code repositories, container environments, and cloud secrets were examined. I would ask whether the investigation covered credentials that were not obviously labeled with the company’s name.
As Help Net Security reported, the exposed information included cloud credentials, API keys, pipeline data, and other secrets linked to thousands of organizations. “We responded” should be treated as the beginning of verification, not the conclusion.
CISA’s List Is an Operating Rhythm, Not a Compliance Exercise
On August 18, CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog: Microsoft SharePoint CVE-2026-55040, Microsoft IKE Service Extensions CVE-2026-33824, Broadcom VMware vCenter CVE-2026-59310, and Apple macOS CVE-2026-65400.
Separately, CISA confirmed that the Windows Task Host vulnerability CVE-2025-60710 is now being exploited by ransomware groups. Microsoft patched that flaw in November 2025, but BleepingComputer reported that unpatched systems remain at risk of privilege escalation and full device takeover.
The four new additions were covered by Security Affairs, which also noted that the affected technologies touch collaboration, identity and network services, virtualization, and employee endpoints.
I do not see the KEV catalog as another compliance report to file away. I see it as a practical operating rhythm.
When a vulnerability is known to be exploited, I need to be able to answer quickly: Do I have the affected product? Where is it installed? Who owns it? Is it exposed? When was it patched? How was the fix verified? What temporary protection exists if the patch cannot be applied immediately?
If those answers are not available, the problem may not be a shortage of security tools. It may be an incomplete asset inventory or unclear accountability.
The Thread Connects Back to Accountability
I have spent 26 years in cybersecurity, and I continue to see the same pattern: organizations often invest in tools before they establish clear ownership for what those tools are meant to protect.
This week’s stories connect vendor oversight, identity management, credential hygiene, vulnerability scanning, and patch verification. They also show why a single assessment or one-time response is rarely enough. The environment changes, credentials remain active, new systems appear, and last month’s incident can still create risk months later.
My single takeaway is this: trust is not a security control unless I continuously verify what that trust allows.
If you are unsure whether your organization can answer these questions across its critical systems, I would welcome a quiet conversation about where to start.
Comments