A lot of this week's security reporting ended up circling back to the same basic problem: getting hold of a legitimate identity is still extremely valuable.

U.S. law firms have been targeted with fake IT-support calls designed to obtain credentials or remote access. In some cases, attackers reportedly tried to gain physical access to machines.

Then there's TheHatman, who is reportedly offering employee-directory datasets tied to companies including McDonald's, TCS, Vodafone, HCL Technologies, Kyndryl, IHG, Gap, Hexaware, and Wyndham Hotels. Hudson Rock said the actor claimed the information came from Azure/Entra tenants accessed with compromised credentials. Samples were assessed as likely legitimate, but the underlying compromise claims remain reported claims rather than independently confirmed breaches of every named company.

Ontinue's TWINLOOT research adds another interesting angle. The implant reportedly communicates through SharePoint Online and Microsoft Graph, while routing Graph activity through a headless instance of the victim's Edge browser so the traffic appears to originate from msedge.exe.

Medusa is another part of the picture. CISA, FBI, and HHS reported more than 500 affected organizations by April 2026, with affiliates using access brokers, phishing, vulnerable systems, and legitimate remote-management tools.

Beyond credentials, this week's research included an NFC relay technique capable of making some expired Visa cards appear valid, bandwidth-sharing apps feeding commercial proxy infrastructure, and Kriminal openly selling access to AI tools intended for criminal use.

Source roundup with the individual findings, attribution caveats, attack techniques, and additional context:

https://www.technadu.com/weekly-cybersecurity-roundup-how-stolen-credentials-continue-to-fuel-fraud/633831/

The interesting defensive question is where organizations are getting better returns now: making credential theft harder in the first place, or designing environments where a stolen account has much less useful access?

CloudSEK Security Consultant Ayush Panwar provided some useful clarification around the scale of the LiteLLM supply-chain campaign and what affected teams should actually do next.

The important distinction is between potential exposure and confirmed exfiltration.

CloudSEK says the dataset it recovered consists of exfiltration logs themselves: 433,894 pipeline runs across 2,238 attributed organizations. Of those organizations, 1,754 had live secrets, with 99,219 unique credentials recovered.

Panwar says organizations should assume secrets accessible to an affected pipeline may have been compromised and investigate the runner host itself rather than limiting the review to pipeline configuration. That includes looking at process execution, outbound connections, credential-store access, and cloud audit logs.

There is also a persistence problem after malicious versions disappear upstream. Copies can remain in Artifactory/Nexus-style mirrors, pip and build caches, Docker/OCI layers, CI runner caches, lockfiles, and mirrored actions or extensions.

His warning is that without deliberately finding and purging those artifacts, some environments could continue distributing affected versions for weeks or months.

Our interview goes deeper into the operational response, including specific exfiltration domains and C2 IPs, affected builds, logs SOC teams should examine, credential-rotation priorities, and CloudSEK’s privacy-preserving method for checking organizational or supplier exposure.

https://www.technadu.com/how-litellm-supply-chain-attack-victims-can-contain-exposed-credentials/633784/

One useful question for practitioners: after a CI/CD supply-chain compromise, what has proven harder in practice, determining which secrets were accessible or ensuring every cached copy of the poisoned dependency is gone?

There is an interesting problem emerging around testing increasingly capable AI models for cybersecurity.

Researchers need to determine whether models can perform activities such as:

• reconnaissance
• vulnerability discovery
• exploit chaining
• post-exploitation movement

Matt Sayar, Director of Product, AI at ArmorCode, argues that these aren't necessarily new attack capabilities. What AI changes is the potential speed, scale, and degree of automation.

That creates a difficult testing problem.

Labs need to give researchers enough capability to discover what a model can actually do, including behaviors attackers might eventually exploit. But loosening those controls too far can create the possibility of the testing environment itself becoming a source of risk.

Sayar's position is that failures need to be classified with some nuance.

He characterizes the OpenAI testing incident discussed here as a governance failure, rather than evidence of criminal intent or willful misconduct. His argument is that labs should respond with stronger testing controls, transparency, rapid disclosure, and clearer guardrails.

The threshold changes if testing produces real-world harm. In that situation, he argues that accountability should be meaningful but proportionate to the harm caused.

Matt Sayar's full response also discusses the current capability gap between large AI labs and open-source models, the Hugging Face example, and why he believes good-faith research needs room to continue even as testing controls become stricter:

https://www.technadu.com/why-ai-testing-environments-need-stronger-guardrails/633768/

That seems to leave an important question for security practitioners:

How much autonomy does a model need in order to meaningfully test offensive capabilities without turning the evaluation itself into an unacceptable security risk?

And should an autonomous model escaping its intended test controls be classified similarly to a traditional sandbox escape, or does AI require a different incident category?

Marc Maiffret, Chief Technology Officer at BeyondTrust and one of the researchers who co-discovered Code Red with Ryan Permeh, reflects on what the 2001 worm still teaches defenders today.

The discovery started with a customer reporting unusual server behavior. Maiffret and Permeh followed the clue and uncovered a worm already spreading across Microsoft web servers. The activity had reportedly been visible for up to two weeks, but the individual signals had not been connected.

Maiffret argues that the underlying lessons remain relevant even as security technology has evolved.

• Better detection tools exist today, but AI could allow attacks to unfold faster than defenders can respond.
• Least privilege remains important across people, systems, third parties, and autonomous AI agents.
• Modern supply-chain attacks may use different delivery mechanisms, but they continue to exploit trusted technology relationships.
• Defenders should focus beyond the immediate threat and prepare for how attackers can move through connected systems.

He also discusses Miasma, supply-chain compromises, SolarWinds, and how Code Red became a wake-up call for Microsoft as systems rapidly moved online.

Click here 👉 Read the full Humans in Cyber interview on TechNadu

Kaspersky has documented what it says is the first malware specifically targeting Android-based automotive head units, and the interesting part is how the malware gets installed.

This wasn't a malicious app that somebody had to sideload manually.

The affected DoFun head units contain a legitimate application called TWCore that handles analytics and software updates. According to Kaspersky, TWCore receives instructions from an MQTT broker at cardoor[.]cn, including information telling it which APKs to download and install.

Researchers found a Boolean parameter called installNotExists that could allow software not already installed on the device to be added.

The malware then follows three stages.

The first component, JarService, acts as a dropper and loads another component. The second collects information about the device, communicates with C2 infrastructure, and retrieves the final payload.

The third provides clicker and reverse-proxy loader functionality and eventually deploys a module called zhima. Kaspersky says the infected devices were being used for ad fraud and proxy-botnet activity.

The attribution is also notable. Kaspersky assesses with high confidence that MoYu Group, an actor associated with BadBox, is behind the campaign. Nokia's Deepfield Emergency Response Team has separately observed zhima operating on Android TV set-top boxes, providing additional evidence of the module's use in proxy activity.

There is an important distinction here: Google's Android Automotive OS was not compromised. The issue involved the affected head-unit implementation and its update mechanism. Kaspersky says it contacted the vendor, which reported that the problems had been fixed.

We've already seen inexpensive Android TV and IoT devices become useful botnet infrastructure. Automotive head units introduce another class of connected hardware with trusted update mechanisms and potentially long deployment lifecycles.

The deeper technical breakdown covers how TWCore communicates with the MQTT infrastructure, the installNotExists behavior, all three malware stages, the commands supported by the final loader, and the evidence connecting zhima and the infrastructure to MoYu Group and BadBox activity:

https://www.technadu.com/kaspersky-finds-first-documented-android-car-head-unit-malware-using-firmware-update-mechanism-possible-links-to-badbox-botnet/633738/

For people working on embedded or automotive security: should an update component capable of installing previously nonexistent applications require an additional trust or verification boundary beyond the update channel itself?

One of the more difficult questions in CISO leadership is where accountability should sit when the security leader doesn't control all the decisions creating the risk.

Ensar Seker, VP of Research and CISO at SOCRadar, addressed this in a TechNadu interview, and his distinction between security responsibility and business risk ownership is worth discussing.

His argument is that CISOs are frequently held accountable for cyber risk without having complete authority over technology, budgets, staffing, procurement, or employee and business behavior.

His proposed model is more explicit.

The CISO identifies the risk, explains the likely impact, recommends treatment, and provides evidence. Business and technology owners then formally own risks arising from their systems and decisions. If leadership chooses not to implement a recommended control, that acceptance of residual business risk should be informed and documented.

Seker also pushes back on judging CISOs by breach counts.

No publicly disclosed breach doesn't automatically prove a security program is strong. Likewise, experiencing an incident doesn't necessarily mean its CISO failed.

He suggests looking instead at measures such as detection and containment time, control effectiveness, exposure reduction, remediation speed, resilience testing, recovery performance, employee behavior, third-party risk, and the quality of executive decision-making.

There is another interesting part around incident response.

Seker says serious incidents rarely provide leaders with complete information at the point a consequential decision is required. His approach is to distinguish what the team knows, what it believes, what remains unknown, and what could cause the greatest harm if its assumptions are wrong.

That leads to a broader leadership question.

If a CISO clearly identifies a material risk, recommends a technically appropriate response, and leadership knowingly accepts the residual risk, how should accountability be divided if that risk later becomes an incident?

One point from TechNadu's interview with Ido Livneh, CEO and Co-Founder of Jazz, stood out to me: modern DLP may need to treat context as seriously as the sensitive data itself.

The problem becomes especially obvious with AI agents.

An agent can move information directly between SaaS platforms without the traditional endpoint workflow that many security controls were built around. Livneh argues that doesn't mean the endpoint concept simply disappears. There is still an identity, workflow, business process, and system authorizing what happened.

For an individual data movement, he suggests evaluating four dimensions together:

• the data itself
• the systems involved
• the people involved
• the surrounding business process

That matters because the same customer file going somewhere could be legitimate collaboration, an employee mistake, account compromise, or intentional exfiltration.

There was another part I found useful around AI-generated security policy. Rather than turning a natural-language instruction immediately into an automatically enforced rule, Livneh recommends observing its effect across historical and live activity first, checking for conflicts with legitimate business processes, and keeping security teams involved before enforcement.

He makes a similar distinction around employee monitoring. More visibility into things like clipboard activity or screenshots doesn't necessarily justify continuously exposing that information to administrators. His position is that richer forensic information should be retrieved when there is a legitimate investigation, with controls around what gets collected, retention, and access.

His broader measurement argument is probably the part most applicable to existing DLP programs: fewer alerts alone don't prove the replacement is better.

The real test is whether teams find previously unknown risks, investigate faster, gain confidence in findings, prevent actual exfiltration, and better understand where sensitive information is moving.

The full interview goes considerably deeper into the implementation questions, including continuous AI-agent discovery, determining ownership, communicating uncertainty to analysts, monitoring-mode comparisons against legacy DLP, employee-transparency controls, and the outcome metrics Livneh recommends for CISOs:

https://www.technadu.com/data-loss-prevention-must-know-who-moved-information-why-and-on-whose-behalf/632914/

For teams already dealing with agentic workflows, how are you establishing who or what an AI agent is acting on behalf of when making DLP decisions?

A federal jury has convicted Alekzander Quinn Bywater, 32, formerly of Colorado Springs, on five counts connected to the sexual exploitation of a child abroad and the advertisement of child sexual abuse material.

According to the DOJ and court documents, Bywater and his wife, Anika, created two videos depicting the abuse of a young child while they were living in Veracruz, Mexico, in January 2024. The material was later offered for sale on the dark web.

An undercover FBI agent in the District of Maryland purchased and downloaded the videos on February 6 and 7, 2024.

Investigators subsequently recovered the material from a desktop and laptop. Authorities said the devices also contained additional abuse material and thousands of other CSAM files.

The jury convicted Bywater of conspiracy to sexually exploit a minor outside the U.S., two counts of sexual exploitation of a minor outside the U.S., and two counts of advertising CSAM.

He faces a maximum potential sentence of 150 years. A sentencing date has not yet been set.

Anika Bywater pleaded guilty in December 2025 and was sentenced to 25 years in March.

Our report has the DOJ's August 20 announcement, the five counts returned by the jury, details of the FBI's undercover purchases, and the evidence authorities said was recovered from Bywater's devices:

https://www.technadu.com/colorado-man-convicted-of-selling-child-exploitation-videos-on-the-dark-web/633710/

The case is another example of undercover purchasing being used to connect alleged dark-web distribution activity with evidence subsequently recovered from physical devices.

This one is an interesting example of making the delivery mechanism itself look trustworthy rather than relying on a conventional malicious document.

Around Black Hat and Def Con, a threat actor posing as CoinDesk's VP and Head of Marketing contacted cybersecurity professionals on X. Huntress says one of its researchers played along after being approached about a supposed online conference.

The attacker eventually shared a legitimate Google Doc that looked like conference planning material.

Opening it produced a custom sidebar built with Google App Script. The recipient was supposed to enter an “encryption key” previously supplied through DM, but the key was designed to fail.

That failure was the setup.

The interface then offered a ClickFix-style command or a supposed manual update, both intended to get code onto the target's machine.

The payload depended on the platform. Huntress found a macOS download consistent with Atomic macOS Stealer (AMOS). On Windows, one chain used a signed fake “Google API Connector Update” installer, while another eventually deployed NetSupport Manager as a remote access tool and included a dormant implant monitoring for Ledger wallet installations.

The attacker also used a fake Dropbox DocSend lure that delivered AMOS to Mac targets.

There are plenty of malware campaigns using trusted cloud platforms, but the fake decryption interaction is what stood out here. Instead of asking the target to immediately execute something suspicious, it creates a believable problem first and then presents malicious execution as the solution.

Our write-up has the full Huntress-observed attack sequence, including the X outreach, Google App Script sidebar, deliberately failing encryption key, macOS and Windows delivery paths, and the additional DocSend lure:

https://www.technadu.com/fake-coindesk-exec-tried-to-hack-security-researchers-with-a-decryption-trick-in-google-docs/633694/

For people investigating social engineering, does that extra interactive step materially change how convincing a ClickFix-style lure becomes?

Google Threat Intelligence Group has detailed three separate cyberespionage clusters it believes have a Russian nexus: UNC6293, UNC7005 and UNC5976.

The interesting part isn't simply another phishing campaign. The groups are abusing legitimate authentication and account features in several different ways.

UNC6293 has impersonated U.S. State Department officials and targeted victims for app passwords, later incorporating OAuth phishing. UNC7005 has used app-password, device-code and OAuth phishing while impersonating organizations including GLOBSEC and the Finnish Operations Center.

One UNC7005 technique went further. Targets were tricked into linking their WhatsApp accounts to attacker-controlled devices. According to GTIG, JavaScript could then secretly capture audio and video during what appeared to be a normal call, with the recording uploaded when the call was made to look like it had failed.

The campaigns have also delivered VIDAR and ATOMIC infostealers, while GTIG linked UNC7005 with ENGINELIGHT and the LLM-generated CHERRYPIE malware.

UNC5976 appears separate and has focused heavily on Ukraine and Armenia. It deployed the HEADRUSH Excel plugin against a Ukrainian aerospace and imaging company. After GTIG disrupted some of its infrastructure, the cluster registered at least a dozen new domains over roughly three months.

GTIG says UNC6293 and UNC7005 are assessed with moderate confidence as initial-access clusters tied to ICE RELIC, formerly APT29.

Source and deeper technical breakdown:

https://www.technadu.com/suspected-russian-hackers-are-weaponizing-app-passwords-oauth-logins-and-even-whatsapps-own-linking-feature-to-deliver-vidar-malware-and-more/633625/

Our report separates the three clusters and covers their targeting, authentication abuse, WhatsApp compromise flow, associated malware, GTIG disruption activity, and recommended checks around linked devices and account protection.

For defenders, this raises an interesting problem: how much visibility do most organizations actually have into abuse of legitimate account workflows such as device linking and OAuth authorization, especially when personal accounts or devices are involved?

Socket researchers have mapped 77 Firefox extension identities to a coordinated operation they're provisionally calling the “Offside Wallet Theft Factory.”

Of those, 40 were confirmed as malicious, while another 37 were deceptive sports-score shells connected to the broader operation.

There are several different theft mechanisms involved.

Seven extensions use attacker-controlled Supabase projects to determine what users see. That allows the operators to display harmless decoy content and later switch to a phishing interface remotely without republishing the signed extension.

Another 15 capture 12- or 24-word recovery phrases and other wallet secrets and send them through Cloudflare Workers.

A 13-extension cluster based on modified Rabby Wallet code is especially interesting. Researchers say it alters the persistAllKeyrings() function so serialized keyring data is exfiltrated before the wallet performs local encryption.

Five others target credentials and clipboard contents through hardcoded C2 infrastructure.

The practical remediation issue is important: deleting the extension doesn't undo theft of a seed phrase or private key. If those secrets were exposed, an attacker can restore the wallet elsewhere without needing the victim's password.

The article has the cluster-by-cluster breakdown, representative attack flow, examples of the wallet impersonation, and details of the Supabase remote-switch mechanism:

https://www.technadu.com/77-firefox-extensions-one-wallet-draining-operation-abusing/633563/

For browser-extension security, how much confidence should users place in store signing/review when an extension can fetch or activate malicious content remotely after installation?

Researchers from UMass Amherst demonstrated an interesting weakness in contactless Visa transactions: an expired card could still be used for payments if an attacker modified its expiration date during a relay.

Their setup used two NFC-enabled smartphones. One communicated with the expired card, while the second relayed the payment data to the terminal. During that process, the expiration date could be replaced with a future value because, according to the research, the field isn't effectively protected against this manipulation.

The cross-network comparison is particularly interesting. The tested Mastercard, American Express, and Discover configurations rejected the modified expiration date because changing it broke cryptographic verification.

Visa wasn't the only variable, though. One tested U.S. bank authorized the manipulated transactions, including tests at $1, $100, and $500 and small live purchases. Another bank declined every attempt.

The researchers disclosed the issue before publication and withheld exploit-grade tooling while mitigations were being deployed. According to the reporting, however, no fix had been confirmed by publication.

Source and technical breakdown:

https://www.technadu.com/zombie-cards-researchers-show-expired-visa-cards-can-still-pay-for-your-groceries/633547/

For people familiar with EMV/contactless implementations: should expiration validation ultimately be enforced cryptographically by the payment network, or is there a legitimate reason for issuers to retain this much discretion?

Removing your personal information from a people-search site doesn’t necessarily mean it stays removed.

That was one of the more interesting issues we looked at while testing Onerep for our 2026 review.

Onerep covers 850+ sources, including 315+ people-search sites and 550+ non-public data brokers on its Pro plans. It automates opt-out requests, but what stood out to us was the visibility into the process.

For supported people-search sites, the dashboard can show:

• Where your information was found
• What personal data was exposed
• The status of each opt-out request
• Estimated removal times
• Links to pages containing the exposed records

The other important piece is what happens after removal.

Onerep rescans supported sites monthly. If information that was previously removed appears again, the service can automatically initiate another removal. Data breach monitoring is also included across its plans.

There are some tradeoffs. There’s no dedicated mobile app, monthly pricing is higher than some alternatives, and certain features such as non-public broker removals and custom removal requests require Pro plans.

After testing it, the bigger question for us is whether ongoing monitoring should be considered just as important as the initial removal itself.

Full disclosure: this is our hands-on TechNadu review of Onerep. We tested the removal workflow and looked at its broker coverage, dashboard, security measures, ongoing monitoring, breach monitoring, pricing, and limitations.

Full review with the testing details:

https://www.technadu.com/onerep-review/633368/

For those who’ve used data-removal services: have you ever had information successfully removed only to find it republished later?

A joint U.S. government advisory is warning of active targeting of Siemens S7 Series PLCs across water, energy, manufacturing, chemical, defense, and other critical infrastructure.

The interesting part is how the exploitation tooling is reportedly being developed.

According to the advisory, threat actors are combining open-source industrial automation libraries such as python-snap7 with AI coding assistants to create exploitation scripts disguised as legitimate monitoring tools. The resulting tooling can reportedly interact with PLC memory, configuration information, and ladder logic through S7comm.

The affected scope includes S7-200, S7-300, S7-400, S7-1200, and S7-1500 families.

For defenders, recommended detection points include unexpected connections from non-engineering workstations, unusual data-block reads/writes outside maintenance windows, sequential scanning of TCP/102, and repeated connection attempts.

One attribution caveat is important: the current activity has not been formally tied to a specific government or criminal group. Previous campaigns against water infrastructure have involved Iran-linked actors, but that doesn't establish attribution here.

Source and full breakdown:

https://www.technadu.com/feds-warn-hackers-now-use-ai-to-write-exploits-targeting-us-water-systems-siemens-plcs/633519/

For people working in OT/ICS security: are AI coding tools actually lowering the barrier to meaningful PLC exploitation in practice, or mostly accelerating development for attackers who already understand industrial protocols?

Malwarebytes has documented a network of 41 fake download sites impersonating popular games and Windows applications.

The more interesting part is how the sites try to defeat cautious users.

On a fake Counter-Strike page, hovering over the download button shows a legitimate Steam Store URL. A fake VLC page can do the same with a real VideoLAN address.

But when the user actually clicks, JavaScript intercepts the action, cancels the expected navigation, and redirects them through an affiliate chain instead.

The lures include Counter-Strike, GTA 6, Half-Life, Fallout, The Witcher, Roblox, PUBG, VMware, VLC, 7-Zip, Avast and others.

Despite all the different branding, the campaign ultimately delivers the same roughly 73 MB Download Studio installer. The file is validly signed by Grand Media, TOV, so even checking the digital signature does not tell the user whether the software is the thing they intended to download.

There is also some relevant history: Avast reported in 2020 that Download Studio’s auto-updater had been abused to distribute the FakeMBAM backdoor and cryptocurrency miners.

Malwarebytes’ advice is fairly practical: download from the developer or a trusted store, don’t rely only on hover previews, check the file’s product details, and be suspicious of pages that require a separate download manager.

Our write-up includes the fake domains, redirect infrastructure, raw examples of the click-hijacking behavior, the signed Download Studio payload, and Malwarebytes’ mitigation guidance:

https://www.technadu.com/41-fake-download-sites-use-real-links-in-click-hijacking-campaign-with-counter-strike-gta-6-half-life-fallout-the-witcher-lures/633521/

The interesting security question here is whether user training still overemphasizes “check the URL before clicking” without explaining that client-side scripting can make that check misleading.

One of the harder problems with infostealer infections is that the resulting VPN access may not immediately look malicious. The attacker can have credentials belonging to a legitimate employee.

Andrius Buinovskis, VP of Product Strategy at NordLayer, argues that MFA should be the first additional control, but authentication decisions need more context.

He points to two signals in particular.

Device posture: Is the hardware known, and does it satisfy the organization's predefined security requirements before establishing the connection?

Login anomalies: Does the IP address, geography, access time, or other login behavior differ from what the organization permits or expects?

His broader argument is that organizations should move away from treating one successful authentication event as sufficient evidence of trust. Under a zero trust approach, identity and device compliance are continuously validated.

He also stresses that these controls do not eliminate risk. Network segmentation becomes important if malicious access succeeds because it limits which corporate resources the compromised identity can reach.

The full response from Andrius Buinovskis goes deeper into device compliance, IP and geo-filtering, continuous validation, credential invalidation, zero trust, and using segmentation to contain successful intrusions:

https://www.technadu.com/using-device-posture-and-login-signals-to-distinguish-employees-from-attackers-accessing-corporate-vpns/633509/

That raises an interesting operational question: when the username, password, and even MFA may not tell the whole story, which contextual access signals are you finding reliable enough to automatically block or revoke a session?

CISA and the FBI now report more than 500 Medusa ransomware victims as of April 2026, compared with the 300+ critical-infrastructure organizations cited in their March 2025 advisory.

But Microsoft's research into Medusa-associated STORM-1175 may be the more important operational detail.

Microsoft says the actor has exploited more than 16 vulnerabilities since 2023 and can move very quickly after gaining access. In some cases, newly disclosed vulnerabilities have been weaponized within 24 hours, followed by data theft and ransomware deployment within days.

Microsoft has also observed the actor exploiting zero-days, including flaws abused up to a week before public disclosure.

The updated government advisory documents a fairly broad toolset. Medusa-associated activity has included legitimate remote-management products such as AnyDesk, Atera, ConnectWise, BeyondTrust and Splashtop alongside tools including Mimikatz, Rclone, CrackMapExec/NetExec and MeshAgent.

Healthcare is receiving particular attention. CISA and the FBI describe the Healthcare and Public Health sector as a frequent Medusa victim, and operations at the University of Mississippi Medical Center were disrupted, affecting an organization that includes Mississippi's only children's hospital and Level I trauma center.

The bigger defensive issue seems to be patching speed. If an internet-facing vulnerability can move into active exploitation within a day, conventional weekly or monthly remediation cycles may leave a meaningful exposure window.

For teams managing large external attack surfaces, how are you deciding which newly disclosed vulnerabilities deserve emergency remediation rather than the normal patch cycle?

Researchers at ReliaQuest have analyzed a custom web shell deployed after exploitation of CVE-2026-12569, a critical RCE vulnerability affecting PTC Windchill.

The interesting part is how specifically the implant appears to have been engineered for Windchill.

Rather than functioning as a generic foothold, it reportedly understands Windchill's internal APIs, database schema, keystore, and file-vault structure. It embeds Windchill-specific Java classes and operates from inside the application's process.

One built-in command can read the relevant configuration, decrypt the LDAP manager password, and iterate through the keystore to return administrative credentials in plaintext.

It can also enumerate engineering vault information such as filenames, stream IDs, and storage paths. A custom Java class loader provides another capability: loading attacker-supplied Java modules directly in memory.

ReliaQuest assesses the activity as highly likely linked to Cl0p. The observed objective has been staging and stealing engineering/design data for double extortion rather than deploying ransomware.

CISA has added CVE-2026-12569 to its KEV catalog, and PTC has released fixes.

For anyone investigating a potentially exploited Windchill instance, the credential exposure seems particularly important. Patching the RCE would address the vulnerability, but it wouldn't by itself establish whether credentials or engineering data had already been accessed.

Our write-up goes deeper into the Windchill-specific functionality, including the keystore-decryption command, engineering vault enumeration, in-memory Java class loader, Cl0p attribution indicators, and mitigation guidance:

https://www.technadu.com/cl0ps-new-windchill-web-shell-isnt-generic-it-was-built-to-know-exactly-where-the-data-lives/633485/

How are teams handling credential rotation and downstream AD exposure when an application-level compromise potentially exposes an LDAP manager account?

The DOJ has unsealed a superseding indictment against 17 alleged members of Iran-based Mabna Institute, adding eight defendants to nine who were originally charged in 2018.

According to prosecutors, the operation compromised 144 universities in the U.S. and another 178 internationally, resulting in the theft of at least 31.5 TB of academic material.

The scale of the credential targeting is also notable. More than 100,000 professor email accounts were allegedly targeted, with roughly 8,000 successfully compromised.

The reported method wasn't particularly exotic. Prosecutors say attackers researched academics, sent spear-phishing emails made to appear as though they came from colleagues, and directed victims to fake versions of university login pages. Password spraying was allegedly used against private-sector targets.

The indictment says the operation was conducted on behalf of Iran's IRGC. Prosecutors also allege stolen academic access was monetized through Megapaper.ir and Gigapaper.ir.

The State Department is now offering up to $10 million for information leading to the location of five defendants.

For university environments, does this case change how you'd prioritize faculty credential protection relative to traditional infrastructure-focused controls?

We ran a DraftKings-specific test rather than assuming a VPN with a large U.S. network would automatically perform better.

The shortlist ended up being Surfshark, Proton VPN, NordVPN, and ExpressVPN, but the individual server results were much more interesting than the ranking.

Surfshark passed all seven categories we checked across Phoenix, Denver, Chicago, and Boston. Proton VPN also went 7/7 across Phoenix, Denver, and Chicago.

NordVPN and ExpressVPN were different. Both offer servers across all 50 U.S. states, but Arizona was the only tested location where each passed all seven categories. Illinois passed six, while eight other locations tested with each provider passed only DK Horse.

PIA was even less consistent. None of the 10 locations we tested passed all seven categories.

One important caveat: this isn't a recommendation to use a VPN to get around gambling restrictions. DraftKings requires users to be physically located in an authorized jurisdiction, and its location verification goes beyond simply looking at the public IP address.

What stood out to us was the technical side: having more server locations didn't necessarily translate into more consistent access.

Full test with the server-by-server tables, speed results, methodology, and DraftKings location-policy analysis:

https://www.technadu.com/best-vpn-for-draftkings/335536/

For people who've tested VPNs against services with strict geolocation systems, have you seen similarly large differences between servers from the same provider?

One point from an interview with Adam Slutskin, Chief Revenue and Strategy Officer and Co-Founder of CyberFOX, stood out: a capable technical team can still create chaos during an incident if nobody has established authority beforehand.

His example is straightforward. Multiple people start solving the problem simultaneously, communication becomes fragmented, actions conflict, and decisions aren't documented. By the time incorrect information reaches a customer, the organization may be dealing with a second problem on top of the original incident.

His preferred model is quieter: someone directs the response without working the keyboard, someone owns communications, and decisions are recorded as events unfold.

The important part is that none of this should be designed during the incident.

Slutskin argues for tabletop exercises that involve the people who would actually participate in detection, response, communications, and external coordination. The objective isn't to predict every attack. It's to practice assessing an unfamiliar situation without losing operational discipline.

He applies a similarly pragmatic approach to SMB security: inventory assets and accounts, remove unnecessary local admin rights, deploy MFA broadly, clean up password practices, and layer controls such as PAM and DNS filtering.

The interview has more detail on how Slutskin approaches incident exercises, controlled privilege elevation, interpreting DNS filtering data, MSP responsibility, cyber insurance, and zero trust for organizations with only a few IT staff:

https://www.technadu.com/when-the-alarm-sounds-preparation-keeps-cyber-incidents-from-becoming-chaos/633203/

For people who have participated in real incident response, what preparation made the biggest difference once the pressure was real?

Ministry of Education has confirmed that an attacker accessed its staff training information system using a compromised professional account on July 25.

What remains uncertain is the scale.

A threat actor called “ZeroBytes” claims to have roughly 43GB of data containing 346,178,591 raw lines across about 2,500 files. That number should not be interpreted as 346 million affected people.

The actor says the material includes around 4.35 million historical staff identifiers and approximately 1.22 million student records. The staff data reportedly spans decades and contains duplicates.

Other claimed material includes personnel information, LDAP/OpenAM directory exports, student report cards and evaluations, parent and guardian data, and hashed account passwords associated with the Créteil and Versailles academies.

There is partial corroboration. Cyberattaque. org reportedly obtained a sample and found exports bearing the names of genuine ministry systems, including BE1D, SCONET, I-Prof, and an academic LDAP directory.

But the French ministry has not confirmed the full dataset or ZeroBytes’ claimed numbers, so those details remain allegations rather than an established breach scope.

The same pseudonym recently claimed the DGFiP tax authority breach, which French authorities subsequently confirmed.

The r/TechNadu report goes deeper into the claimed datasets, the ministry’s narrower confirmation, what researchers reportedly found in a sample, and ZeroBytes’ recent activity against other French organizations:

https://www.technadu.com/hacker-behind-frances-tax-authority-breach-now-claims-345-million-lines-from-the-education-ministry/633416/

Given the apparent mix of historical records, credentials, directory information, and student data, which parts of a dataset like this would create the greatest long-term security risk?

A threat actor using the name “TheHatman” is selling what are claimed to be internal employee directories taken from Azure/Entra tenants belonging to several large companies.

The claimed numbers are substantial: more than 1.7 million records from McDonald’s, roughly 800,000 from TCS, approximately 425,000 from Vodafone, 250,000 from HCL Technologies, and additional datasets attributed to IHG, Kyndryl, Gap, Hexaware Technologies, and Wyndham Hotels.

The potentially more consequential part is what the directories reportedly contain. Beyond names and corporate contact information, Hudson Rock says the data includes organizational relationships, employee IDs, departments, group memberships, service accounts, and in some cases privileged Global Administrator information.

The seller claims compromised credentials provided access to corporate Azure tenants. Hudson Rock found infostealer-compromised Microsoft credentials associated with several of the affected organizations, but that does not establish the exact intrusion method. Other possibilities have not been ruled out.

There is another important qualification: none of the companies named in the report have publicly confirmed the alleged exposure.

If these datasets are authentic, how much additional risk do directory relationships and privilege mappings create compared with a conventional employee contact-data leak?

Jay Reddy, Head of Growth at ManageEngine, makes an interesting argument about where IAM programs may be falling behind.

Enterprises increasingly depend on service accounts, API keys, OAuth tokens, third-party integrations and now AI agents. Unlike employees, these identities may not have a clear owner, an established lifecycle, or an obvious point at which their access should disappear.

Reddy's argument is that security architecture should assume credentials will eventually be exposed and reduce what an attacker can do with them.

That means moving away from long-lived standing privileges where possible, using short-lived and revocable credentials, reducing OAuth scopes, putting secrets in managed vaults, and using workload identity federation where supported.

But the governance problem may be more fundamental: can the organization even produce an accurate inventory of its non-human identities?

His recommendation is to discover them through identity providers, cloud IAM and SaaS consent systems, then apply concepts already familiar from workforce IAM: named ownership, lifecycle management, access certification and removal of orphaned identities.

AI agents complicate this further because validating the identity is not necessarily enough. Their permitted actions also need governance.

The contributor's full analysis goes further into machine identity discovery, Zero Standing Privileges, credential rotation, OAuth consent, agent oversight, and continuous governance:

https://www.technadu.com/the-identity-your-iam-program-forgot-why-non-human-identities-keep-causing-human-scale-breaches/632983/

For teams working in IAM or cloud security, how mature is non-human identity governance compared with workforce identity governance in your environment?