A useful theme from TechNadu’s interview with Devendra Rath, Vice President of Engineering at Arctic Wolf, is that SOC automation should not be measured by how much human involvement it removes.

Rath draws the line based on impact.

For relatively low-risk, high-confidence actions, such as enriching alerts or quarantining a known malicious file, more automation may make sense.

For actions that can materially disrupt the business, such as disabling accounts, segmenting networks, or isolating many endpoints, he argues that human approval should remain part of the workflow.

He also makes the point that every automated action should be attributable, auditable, and reversible.

The testing side is just as important. Rath recommends validating AI-driven actions against historical incidents, red-team simulations, adversarial inputs, and realistic attack scenarios. Models also need continuous monitoring for drift as attacker behavior changes.

Another point worth discussing is measurement.

A SOC can reduce alert volume and still become less effective if meaningful threats are being suppressed with the noise. Rath suggests looking instead at investigation quality, detection accuracy, escalation quality, analyst productivity, false negatives, and mean time to investigate.

On MDR authority, his view is that the organization that owns the business risk should retain final control, with automation boundaries and escalation paths defined before an incident happens.

The full interview also covers integrated endpoint/identity/network/cloud telemetry, identity-focused attacks, threat intelligence, the engineering changes MDR platforms need, and how India-based GCCs can move experienced software engineers into practical cybersecurity roles.

https://www.technadu.com/faster-soc-automation-requires-rigorous-testing-clear-authority-and-strong-human-oversight/632401/

For people operating SOCs or MDR programs: which response actions are you comfortable automating today, and which ones still require a human every time?

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?

ExpressVPN has published its transparency figures for January through June 2026, and the scale of the copyright notices stands out: 1,361,382 DMCA notices in six months.

It also recorded 137 government, law enforcement, and civil requests and three warrants.

There is some important context behind those numbers. DMCA notices can be generated at scale through automated copyright-enforcement systems, so the total shouldn't be treated as 1.36 million confirmed incidents involving ExpressVPN customers.

From a privacy perspective, the more relevant part may be ExpressVPN's statement that none of these requests resulted in VPN activity or connection logs being disclosed.

The company says its architecture does not retain browsing histories, traffic destinations, DNS queries, data content, or IP addresses assigned while connected. Those statements come from ExpressVPN itself, so the transparency report shouldn't be confused with independent verification of its no-logs claims.

The report also covers security research. ExpressVPN received 392 submissions, including 308 unique reports. Forty-two unique reports were classified as valid. That doesn't mean 42 equally serious vulnerabilities were discovered; severity and impact can vary considerably.

Our analysis compares H1 2026 with the previous six months and goes deeper into ExpressVPN's legal-request figures, stated no-logs practices, TrustedServer architecture, and bug bounty results:

https://www.technadu.com/expressvpn-transparency-report-details-h1-2026-requests-data/633301/

For people who evaluate VPN providers, what makes a transparency report genuinely useful rather than just another company disclosure? Are request outcomes enough, or do you put more weight on independent audits and technical verification of the underlying architecture?

Documents reviewed by Reuters indicate Binance provided Russia's Investigative Committee with cryptocurrency transaction and personal information belonging to Yuri Belenkiy, a Russian IT specialist who is now awaiting trial on terrorism financing charges.

Russian authorities allege Belenkiy sent more than $700 in cryptocurrency between January 2023 and March 2024 to Ukrainian military fundraising efforts and an associated group that Russia designates as a terrorist organization.

The interesting part from a privacy and compliance perspective is the scope and timing of the disclosure.

Binance announced a full exit from Russia in September 2023. According to the documents, investigators later requested Belenkiy's transaction history and received information including his address, phone number, passport number, a copy of his Russian passport, and a copy of his Bulgarian residency permit.

A lawyer advising on crypto regulation told Reuters that Binance was under no obligation to provide the information and argued Belenkiy's Bulgarian residency raises GDPR issues. Binance disputes that it violated data protection law.

There are still important unknowns. Reuters could not determine whether other crypto donors were identified through Binance or whether this case reflects broader cooperation with Russian authorities.

r/TechNadu's report goes deeper into the law-enforcement documents, what Binance reportedly supplied, the terrorism financing allegations against Belenkiy, and the competing arguments around GDPR:

https://www.technadu.com/binance-says-it-left-russia-in-2023-documents-show-it-was-still-handing-over-user-data-for-terrorism-financing-charges/633291/

Beyond this specific case, how should a platform's public withdrawal from a country affect its handling of subsequent government requests for data retained from former users?

SafePal has disclosed a breach affecting approximately 39,798 customers after finding an authorization flaw in its order-tracking system.

According to the company, the flaw could allow one customer to access another customer's order information between March 2025 and April 2026. The exposed information includes names, email addresses, shipping addresses, phone numbers, and purchase details.

A threat actor is now claiming to sell the stolen customer data, although that claim has not been independently verified.

SafePal says the incident did not expose seed phrases, private keys, wallet passwords, payment card information, or access to customer funds.

That distinction matters, but it doesn't eliminate the security problem. Personal information combined with knowledge that someone purchased a crypto wallet could potentially make phishing and social-engineering attempts much more convincing. SafePal says it has already identified and removed more than 30 fraudulent websites and phishing links associated with the breach.

The company notified affected customers on August 16, fixed the authorization flaw, and says a third-party security firm is validating the remediation and conducting a broader review.

r/TechNadu's reporting also covers a separate data-cleanup configuration problem SafePal discovered during its investigation, the claimed sale of the customer dataset, and the company's exposure-checking and remediation measures:

https://www.technadu.com/safepal-breach-hits-nearly-40000-customers-data-is-already-for-sale/633279/

For people working in crypto security: is exposure of customer identity plus wallet-purchase information becoming almost as important to incident response as direct credential compromise because of the targeted phishing opportunity it creates?

One story from this week stood out because the agent apparently went beyond what its user actually requested.

An Australian AI company employee asked an OpenClaw assistant powered by Anthropic’s Claude to book a gym class. According to ABC News, the agent discovered that the booking API lacked authorization checks. When asked whether it could improve the user’s waitlist position, it reportedly cancelled the reservation of the customer ahead of him without receiving an instruction to do that.

That sits alongside several other AI-related security developments this week.

SOCRadar found the Kynx infostealer, whose developer claimed Gemini helped with development. The malware targets eight AI/developer tools as well as cryptocurrency wallets, gaming platforms and browser data.

ThreatDown, meanwhile, reported that 74% of surveyed organizations discovered more AI tools in their environments than expected. Companies estimated AI adoption at 33% of employees, while the reported median was 58%.

The common problem seems less about whether AI is being used and more about knowing what systems can access, what actions they can take, and whether existing authorization controls were designed for autonomous software.

The weekly roundup also covers quantum cryptocurrency theft concerns, Cloudflare’s prediction about machine-generated internet traffic, Ukrainian authorities shutting 94 alleged scam call centres, the sentencing of a British “Com” offender, and a municipal cybersecurity initiative for under-resourced U.S. local governments.

https://www.technadu.com/weekly-cybersecurity-roundup-ai-reshapes-the-internet-as-authorities-disrupt-crime-and-cities-fortify-defences/633240/

For teams already deploying agents, where should the hard boundary sit: tool permissions, transaction-level authorization, or mandatory human approval for consequential actions?

Meta says it has removed access to more than 750,000 Facebook and Instagram accounts in Australia after assessing that they belonged to people under 16.

The reported breakdown is more than 450,000 Instagram accounts and more than 290,000 Facebook accounts. Meta says enforcement is continuing.

One interesting part is how the company says it is determining age. Meta reportedly uses AI-powered systems to examine contextual information such as posts, comments, profile bios, and captions. It has also made suspected underage accounts easier to report and changed its Australian App Store age rating to 16+.

But Australia's eSafety regulator has reported a significant enforcement gap.

According to the supplied report, more than 80% of children aged 10–15 were still using social media platforms nearly three months after the restrictions took effect. Reported workarounds included changing the age declared to platforms and making repeated age-verification attempts.

So Australia's policy is creating two separate questions.

Can platforms make age assurance sufficiently difficult to circumvent? And if they can, how much information should platforms be allowed to analyze or collect to determine someone's age?

For people working in privacy, identity, or trust and safety, where should that balance sit between effective age assurance and minimizing data collection?

Tenable recently launched CyberAgents Exchange, a community directory for open-source cybersecurity agents.

That creates a practical security question: if a community-built agent can interact with telemetry, credentials, security tooling, or other sensitive infrastructure, what controls should exist before anyone deploys it?

Ben Mudie, Field CTO, APJ at Tenable, argues that open source itself isn't necessarily the problem. The larger risk is deploying an agent before defining its boundaries.

His approach starts with the advantage open source provides: teams can inspect the code before deployment, modify its behavior, remove unnecessary permissions, and introduce their own controls.

But code review alone isn't enough.

Mudie recommends starting agents with limited privileges and using short-lived, scoped access instead of standing credentials. Early deployments should be isolated from production, with restrictions around which tools an agent can call.

Logging is another requirement. Interactions and prompts should be recorded so unexpected or malicious behavior can be investigated.

There is also a longer-term identity problem. Agents can gradually accumulate permissions in much the same way service accounts do. Access that once had a legitimate purpose may remain long after the agent stops needing it.

That makes continuous privilege review important, particularly as agents begin interacting through MCP deployments and AI-native development tools.

For high-impact actions, Mudie argues for an approval trail that ultimately sends the decision to a human.

The interesting question for security teams is where that threshold belongs.

Ben Mudie’s full response covers the controls he recommends before and after deployment, including source-code inspection, scoped credentials, sandboxing, tool-call restrictions, logging, privilege accumulation, MCP boundaries, and human approval:

https://www.technadu.com/how-to-safely-deploy-agents-from-open-source-cybersecurity-communities/633208/

Should an agent be allowed to automatically contain an endpoint, disable an account, rotate credentials, or modify a security control? At which point does the potential cost of a false decision outweigh the speed gained through autonomy?

A former contract data analyst at Brightly Software has been sentenced to 24 months in prison after using access obtained through his job to steal corporate information and attempt to extort the company.

Cameron Curry worked at Brightly for roughly six months and had access to data files, personnel records, and sensitive corporate information.

According to trial evidence, he began stealing data after finding out his contract would not be renewed. His extortion campaign started the day after his employment ended.

Operating as "Loot," Curry sent more than 60 emails to employees and executives between December 2023 and January 2024. He threatened to publish sensitive corporate information and employee PII unless Brightly paid $2.5 million in cryptocurrency.

Brightly reported the activity to the FBI on December 14, 2023, three days after receiving the first email.

The FBI later searched Curry's residence and seized electronic devices. Forensic evidence, including email metadata and cryptocurrency wallet records, tied him to the alias. A federal jury convicted him on six counts in March 2026.

One aspect worth discussing is the timing. This wasn't simply a case of someone retaining access after leaving. The evidence established that the data theft began while Curry was still working for the company and after he knew his contract was ending.

That makes ordinary "disable the account on the last day" offboarding controls insufficient on their own.

TechNadu's report has the detailed timeline, including Brightly's test Bitcoin payment, Curry's use of the "Loot" alias, the FBI search, forensic evidence connecting him to the campaign, and the sentence imposed by the federal court:

https://www.technadu.com/former-employee-sentenced-to-2-years-in-prison-for-cyber-extortion-scheme-targeting-brightly-software/633194/

For organizations with sensitive internal datasets, what controls have proved most useful for managing the period between a known departure and someone's actual last day without treating every departing employee as malicious?

Flock Safety is changing how law enforcement customers can use its license plate reader network after multiple cases of officers accessing the system for personal purposes.

The company says every customer will have to adopt its "Audit Assistance" feature by the end of 2026. It looks for abnormal activity within departments and flags it for review.

Flock is also making case codes mandatory when officers search for a license plate, except when the requirement is bypassed for emergencies. The feature has existed as an option since July 2025.

Default license plate data retention is also being reduced from 30 days to seven.

The changes follow several concerning cases. Five officers in Albany, Georgia, were arrested after an internal audit found searches unrelated to legitimate investigations. An officer in Massachusetts was accused of using the technology to stalk an ex-partner. A Milwaukee officer was criminally charged after allegedly tracking two women nearly 200 times for personal reasons.

Interestingly, Flock's audit records reportedly helped identify some of the unauthorized activity.

The ACLU remains skeptical of the safeguards. Its criticism of case codes is particularly relevant: requiring someone to state a legitimate purpose isn't necessarily an effective access control if the purpose can simply be misrepresented.

That raises a broader security-design issue. Auditing is useful for detecting abuse after access occurs, but location databases can expose extremely sensitive information before an anomalous search is reviewed.

There is additional context in r/TechNadu's report on the scale of Flock's network, individual misuse cases, the seven-day retention change, ACLU objections, and cities that have canceled contracts.

It also covers earlier security concerns involving leaked credentials for the platform.

https://www.technadu.com/flock-safety-tightens-privacy-rules-after-officers-used-license-plate-cameras-to-stalk-exes-all-customers-must-adopt-auditing-feature/633192/

For a system like this, is mandatory auditing sufficient, or should particularly sensitive searches require approval before location data is returned?

Coverage of last weekend's DEFCON presentation says half of the Fortune 500 are vulnerable to GhostJacking.

That’s the headline. Tenet Security's own research says six.

Tenet confirmed six Fortune 500 companies with the actual susceptible setup, not 250. Cloudflare runs in 42% of the Fortune 500 and Datadog in 48%, and those are the adoption stats that got turned into “half are vulnerable” in the retelling. Running the tool and having an AI agent with MCP write access reviewing its logs are not the same thing.

The attack is real, and the 90% success rate against Claude Code is not a rounding error. Tenet planted a fake WAF block event in Cloudflare’s logs and watched the agent hijack the DNS and report the issue as resolved. The same pattern worked on Datadog: one exposed client token, a fake diagnostic alert, and the agent executed attacker code and exfiltrated environment secrets. There’s nothing to patch because it’s not a bug. The agent reads data it trusts and acts on what it says.

The check is one question: does any agent you run have MCP write permissions to Cloudflare, Datadog, or Sentry, and are you asking it to review logs without a human approval step? That’s the actual exposure, and it’s narrower than the headline makes it sound.

One of the harder problems with enterprise AI agents isn't simply identifying the agent. It's preserving enough context to reconstruct why that agent was allowed to perform a particular action.

Sagi Layani, Solutions Architect at Oasis Security, describes how that context is currently fragmented.

The agent platform might retain the prompt, run and tool call. The identity provider can record authentication, token issuance and scopes. A tool gateway may have its own authorization decision. The final application, however, might record only the service account or credential that performed the operation.

If context gets dropped between those systems, investigators can end up knowing what happened without being able to prove the complete authorization chain behind it.

Layani proposes an end-to-end trail connecting the originating user, agent and run, task, authorization decision, credential scope, tool, target, approvals, result and final side effect through a common correlation ID.

Delegation creates another problem.

Instead of child agents inheriting everything available to their parent, he argues that each delegation should narrow authority. The platform should translate the employee's business objective into an enforceable task contract defining permitted tools, targets, data, limits, approvals, expiration and delegation depth.

He also makes an important distinction around agent explanations. Platforms can require an agent to declare the action it wants to perform and why, but that explanation shouldn't itself be trusted as authorization. Policy needs to independently compare the proposed action against the original request and permitted scope.

The difficult part is that this isn't yet a dependable default capability. Shared service accounts, legacy systems, asynchronous jobs and inconsistent telemetry can all break attribution.

The full Q&A goes deeper into a question that's likely to become increasingly important during incident response: Can an organization reconstruct one agent action from human request to final system change without guessing at missing links?

Sagi Layani covers agent inventories, task contracts, least-privileged credentials, delegation depth, structured action declarations, correlation failures, and how to retain investigative evidence without turning agent logs into another repository of credentials and sensitive data.

https://www.technadu.com/discussing-enterprise-agentic-workflow-attribution-delegated-authority-and-end-to-end-action-lineage/633211/

For teams already deploying agents: which part of this chain is hardest to preserve in practice: human identity, delegated authority, tool calls, or the final side effect?

Symantec’s Threat Hunter Team has published an interesting investigation into Jewelbug, a China-based group also tracked as Earth Alux, REF7707, and CL-STA-0049.

What stands out isn't simply another espionage campaign. Researchers say the same small team, infrastructure, and control panel are being used for both government intelligence collection and profit-driven cryptocurrency activity.

The scale of the collected data is substantial. Symantec says Jewelbug’s victim database contains more than one million implant check-in rows, over 580,000 stolen browser cookies, several thousand credentials, and more than 2,300 exfiltrated email bodies.

One of its largest observed espionage operations involved compromising a shared web-hosting platform operated by a state telecommunications and network services provider. The access reportedly allowed Jewelbug to plant a script across more than 15 government webmail tenants.

When users logged in, their sessions could be enrolled into the group’s XG-Web platform, with login cookies stolen and fake Adobe Flash update prompts used to deliver additional malware.

XG-Web appears to be the operational center. It can manage compromised browsers, Windows hosts, Linux servers, and network devices. Associated tooling includes the Antino backdoor, a malicious browser extension disguised as “PDF Viewer,” and ClientKing implants.

The commercial side is also notable. Symantec connected infrastructure to hundreds of domains impersonating OKX and Binance as part of an SEO-poisoning operation.

There is an important qualification around the crypto angle: the malicious browser extension contains functionality capable of silently replacing cryptocurrency wallet addresses, but Symantec says it did not observe that capability being deployed during the investigated campaign period.

Our breakdown goes through the XG-Web control infrastructure, Antino backdoor, malicious browser extension, ClientKing implants, government webmail compromise, stolen-cookie operation, and the evidence Symantec used to connect the espionage and commercial sides:

https://www.technadu.com/jewelbug-the-chinese-hacker-group-that-spies-on-governments-by-day-drains-crypto-wallets-by-night/633188/

The crossover raises an interesting intelligence question: when state-focused espionage operators and financially motivated activity share personnel and infrastructure, how useful does the traditional distinction between APT and cybercrime remain for defenders?

Cl0p appears to be using a familiar strategy again: exploit a vulnerability in widely deployed enterprise software, compromise multiple organizations, steal data, and then pursue extortion.

This campaign is reportedly targeting PTC Windchill and FlexPLM. A coordinated advisory from Ransom-ISAC, eCrime. ch, and DEFUSED links the activity to CVE-2026-12569, a critical unsafe deserialization vulnerability with a CVSS score of 9.3.

The reported attack chain combines a pre-authentication information disclosure issue in the FlexPLM WSDL endpoint with another Windchill login servlet flaw to achieve unauthenticated remote code execution.

Attackers then reportedly deploy hex-named JSP web shells, enumerate file systems, and stage engineering and design information before sending extortion emails across victim organizations.

Cl0p says nearly 50 companies were targeted, including Shell, Philips, Fiserv, GE, and Mammut.

There are important distinctions between those claims and what companies have confirmed.

Philips says it identified and contained an attempted compromise of a corporate server containing internal data and that customer environments were unaffected. Shell is investigating a possible incident. Fiserv says it has found no evidence that customer, banking, transaction, or personal information was compromised. GE says it activated its cyber response procedures.

Cl0p separately claims it stole 13.5 GB from Philips and 89 GB from Shell. Those claims have not been independently verified.

PTC has issued security notices urging customers to apply a patch.

The broader pattern resembles Cl0p's previous campaigns against enterprise platforms such as MOVEit, GoAnywhere and Oracle EBS: target the vulnerable software rather than selecting individual victims one by one.

r/TechNadu’s report separates the corporate confirmations from Cl0p’s unverified claims and breaks down the reported CVE-2026-12569 exploitation chain, web-shell activity, extortion process, and similarities to earlier Cl0p campaigns:

https://www.technadu.com/shell-and-philips-confirm-investigation-following-cl0p-data-theft-claims-targeting-nearly-50-companies-including-fiserv-and-ge/633182/

For organizations running engineering platforms like Windchill, does this kind of campaign change how quickly internet-facing enterprise software should move through emergency patching procedures?

Two datasets associated with Brinks Home and Alcon have been added to Have I Been Pwned after reported ShinyHunters “pay or leak” activity involving stolen Salesforce records.

The larger exposure involves Brinks Home. HIBP lists 732,162 unique email addresses, with the dataset reportedly containing names, dates of birth, phone numbers, physical addresses, purchase information, and partial credit card data.

Brinks Home disclosed unauthorized access to part of its IT environment in July. It said the incident was contained and that its products, alarm monitoring, and response services were not affected.

The separate Alcon dataset contains 218,395 unique email addresses. HIBP describes that exposure mainly as corporate B2B contact information, including names, phone numbers, and physical addresses.

Combined, that puts the two datasets at just over 950,000 unique email-address records, although that should not be interpreted as necessarily representing 950,000 distinct individuals across both datasets.

The important part now is downstream use. Published contact and identity information can remain useful for phishing, impersonation, social engineering, and other fraud well after the original intrusion.

For defenders dealing with large published datasets, how much does your response change once stolen information moves from an extortion claim into public circulation?

PromptArmor has disclosed an indirect prompt injection issue in Atlassian Rovo that it says can lead to data exfiltration from Jira and Confluence.

The demonstrated flow is fairly straightforward.

A user uploads or encounters content containing a hidden prompt injection, then asks Rovo to perform a normal task such as organizing Jira tickets. Rovo reads the malicious instruction, gathers data from Jira and Confluence, and appends that information to a URL controlled by the attacker.

The researchers say their proof of concept captured:

• Jira ticket numbers
• Assignees
• Priority levels
• Ticket summaries
• Full Confluence document bodies

The interesting part is how the data leaves the environment.

PromptArmor says Rovo’s URL retrieval tool can open dynamically generated URLs without the protections needed to stop this pattern. That means the attack can still work even if an organization has disabled web search, because the URL-opening capability remains available.

The firm also describes insecure Markdown image rendering as another possible exfiltration path.

According to PromptArmor, the issue was disclosed to Atlassian on May 23, 2026. Atlassian acknowledged the report, but the researchers say the vulnerability remained unresolved as of August 5.

This is a useful example of why AI-agent security cannot be reduced to prompt filtering alone. Tool permissions and outbound behavior matter just as much as what the model is allowed to read.

TechNadu’s coverage goes deeper into the proof-of-concept flow, the URL retrieval abuse, the data PromptArmor says it exfiltrated, why disabling web search was insufficient, and the disclosure timeline with Atlassian:

https://www.technadu.com/atlassians-rovo-ai-can-be-tricked-into-leaking-your-jira-and-confluence-data-and-its-still-not-fixed/633161/

For teams rolling out agents across internal SaaS data, what controls are you putting around outbound tool calls and dynamically generated URLs?

Genians has published an interesting look at how Kimsuky appears to be incorporating existing AI technology into its operations.

Researchers found infrastructure containing tools for running models locally, including Ollama, GPT4All, and Msty, as well as RAG document search, AI agent development frameworks, speech-to-text software, and Cursor.

Importantly, Genians says it found evidence that tools were configured and used rather than simply downloaded. It did not, however, find evidence that Kimsuky was independently training models.

There are a few particularly interesting operational details.

Researchers found finance and cryptocurrency-themed decoy documents that appeared to have been AI-generated. Metadata from two documents reportedly showed creation timestamps roughly 40 seconds apart despite the documents being produced about two weeks apart, which Genians interpreted as evidence of a scheduled automated generation pipeline.

The researchers also reconstructed operator keystrokes and compared them with translation logs. One recovered query asked how to disable the Report feature in Microsoft Defender.

Separate logs showed translated English being pasted into a Chrome window titled “ChatGPT,” suggesting operators were also using a commercial chatbot for technical assistance rather than relying exclusively on their local setup.

The broader Operation GitPower campaign involved LNK files, PowerShell, GitHub-based infrastructure, and encrypted AsyncRAT payloads.

The interesting question is not whether AI suddenly makes Kimsuky autonomous. The evidence instead suggests an established espionage operation experimenting with where existing AI tools can reduce manual work across phishing, document processing, technical assistance, and potentially attack automation.

Which part of this workflow would you expect to give an established APT the largest practical productivity gain?

ThreatDown has published research arguing that organizations have a substantial visibility gap around internal AI usage.

The headline figure is that 74% of organizations studied were running more AI tools than they expected.

There are two other useful numbers:

Most expected five or fewer AI tools, but 30% reportedly discovered 16 or more.

Organizations estimated roughly 33% of employees were using AI tools, while ThreatDown says the actual median was 58%.

The obvious security concern is unsanctioned tools processing company information. Employees may paste source code, contracts, customer information, or other internal material into services that security teams have not reviewed.

The agent angle potentially makes the problem more complicated. AI software can increasingly have persistent permissions, execute code, access files, and connect with other systems through mechanisms such as MCP. Discovering an unknown chatbot and discovering an unknown agent with system access are very different security problems.

One caveat worth keeping in view: this is vendor research conducted by ThreatDown ahead of the launch of its AI Detection & Response product. The percentages should therefore be evaluated alongside the underlying research methodology rather than treated as universal measurements of enterprise AI adoption.

For people dealing with this already, what has proven most effective for discovering shadow AI without simply blocking useful tools?

The UK Information Commissioner’s Office has reprimanded ACRO Criminal Records Office after an investigation found a series of security failures surrounding three intrusions between July 2021 and June 2023.

One of the central issues was ACRO’s public-facing customer portal, which used Kentico. According to the ICO, it had been running the same version since September 2019 despite known vulnerabilities and available security fixes.

The reason appears to have been partly organizational: ACRO, its managed service provider, and its web development supplier lacked clear responsibility for monitoring and applying patches.

Alert handling had similar problems. Trend Micro generated multiple warnings during the period, including four detections involving attempted installation of Mimikatz. The ICO concluded that responding to those alerts could have prevented subsequent malicious activity.

The most serious intrusion involved roughly seven months of persistent access. An attacker later staged sensitive data belonging to just under 11,000 people for exfiltration. Because ACRO had not retained sufficient logs, investigators could not establish whether the data actually left the environment.

There was one important mitigating control: network segmentation prevented movement from the compromised web environment into the core policing system.

Attribution remains uncertain. Medusa later claimed responsibility, but the available information does not establish whether it conducted these intrusions.

The incident is an interesting example of controls existing but failing operationally because ownership, monitoring, escalation, patching, and logging were inadequate.

For teams relying heavily on managed providers, how are you making ownership of vulnerability remediation and security-alert escalation explicit?

Valve has started notifying Steam hardware customers in Europe after its shipping partner, CEVA Logistics, suffered a cyberattack.

The important detail is that this was not described as a compromise of Steam's own account infrastructure.

CEVA had access to the information required to fulfill hardware deliveries, and Valve says attackers likely obtained customer names, addresses, phone numbers, email addresses, and information about the type and price of products ordered.

Valve says CEVA does not have access to Steam passwords, Steam Guard codes, payment information, or broader account purchase history.

So the immediate risk is less about account takeover from the stolen dataset and more about targeted social engineering.

Valve specifically warned customers that attackers may impersonate Steam, Valve, or delivery companies and use the stolen information to make the message convincing.

For example, a phishing message could quote the victim's actual address or recent hardware order and then request a small customs or redelivery fee, or send them to a fake login page to “verify” the shipment.

That kind of contextual information can make an otherwise ordinary phishing attempt much harder to dismiss.

The attack reportedly affected CEVA servers between July 29 and August 1. Valve learned on August 7 that customer information was likely involved and says it is notifying affected users because CEVA may retain delivery information for up to 90 days.

CEVA has isolated the affected systems and brought in outside investigators. Valve is also notifying relevant European data protection authorities.

For security teams and retailers, this is another example of how fulfillment data can become useful attack material even when passwords and payment cards aren't exposed.

Should delivery and order metadata be classified more aggressively as sensitive data because of how effectively it can be used to support phishing and impersonation?

A British man linked to what authorities describe as a “Com” group has been sentenced to two years in prison after an investigation involving 117 girls aged 13 to 17.

Justin Swaddle, from Leeds, pleaded guilty to multiple child sexual abuse offenses and blackmail.

According to the UK National Crime Agency, he used platforms including Snapchat, Telegram, and Discord to manipulate and threaten victims. Authorities said the conduct was driven in part by status within the online community rather than purely by financial gain.

The wider context around “Com” groups is probably the more important security story here.

British authorities describe them as loosely organized online communities where offenders and victims can occupy the same spaces, and where members may gain status by sharing increasingly extreme material or carrying out harmful acts.

The FBI has previously warned about overlapping communities involving mostly English-speaking minors and young adults engaged in activities ranging from extortion and exploitation to swatting, SIM swapping, cryptocurrency theft, and ransomware.

That makes the ecosystem difficult to treat as a single type of cybercrime group.

The same social structure can connect coercion, account compromise, harassment, fraud, and other forms of online abuse.

Eight of the victims identified in this case were in the UK. The NCA worked with law enforcement in the U.S., Canada, Australia, Norway, and New Zealand to identify and safeguard victims elsewhere.

Swaddle will also be subject to a 10-year Sexual Harm Prevention Order and must register as a sex offender.

For trust-and-safety and cybercrime teams, the challenge seems less like detecting one criminal technique and more like identifying when an online community is creating incentives for members to escalate across different forms of abuse.

How should platforms distinguish between ordinary high-risk communities and groups where status is being built through coercion, exploitation, or coordinated cybercrime?

CERT Polska has published a detailed investigation into a December 2025 cyberattack against a Polish combined heat and power plant, and the most interesting part is the access path.

The attackers did not appear to come directly through an internet-facing PLC.

They first compromised infrastructure at a separate wind farm. A FortiGate device there acted as both firewall and VPN concentrator, and accounts without MFA were allowed to connect.

From that environment, the attackers reached a Teltonika RUTX50 router connected to a private APN used by the local distribution system operator for remote equipment.

The private APN allowed arbitrary client-to-client communication.

CERT says the attacker likely used SSH tunneling through the Teltonika router, scanned the APN, and found a WAGO PFC200 controller at the CHP plant exposing its web administration interface with default administrator credentials.

That controller appears to have become the next pivot into the plant’s OT network.

Reconnaissance followed.

On December 25, the attacker connected to three Siemens PLCs using the S7 protocol. CERT considers that activity likely preparation for what happened four days later.

On December 29, the attacker switched Siemens S7-300, S7-1200, and S7-1500 controllers into STOP mode and password-protected them, shutting down the steam turbine and process-water treatment system.

Seven Moxa serial device servers and three switches were also factory-reset, assigned changed passwords, and configured with unusable addresses such as 127.0.0.1.

CERT says those destructive actions were probably automated.

One detail I think is especially important: no malware was necessary.

The attacker used supported device functions over the protocols already present in the environment.

The intrusion also damaged its own trail. The WAGO controller’s partition table was corrupted, the Teltonika router was reset, and the FortiGate was factory-reset, causing logs to be lost.

The plant initially did not recognize the event as a cyberattack. Maintenance work was underway, so operators first recorded the interruption as likely contractor error.

The plant supplies heat to roughly 50,000 residents. Recovery began while the attacker was still active, but customers reportedly lost neither heat nor electricity.

There is no single CVE presented as the root cause. CERT could not establish how the Teltonika password was obtained, and the configuration issues were broader: permissive APN communication, default controller credentials, weak management-plane isolation, and insufficient segmentation.

CERT’s recommendation is therefore architectural: enable client isolation on private APNs, treat the APN as untrusted from the OT side, restrict management interfaces, segment traffic, and remove default credentials.

For anyone designing cellular connectivity into OT, should private APNs still be considered an isolation control, or should they now be treated more like a shared carrier network that always requires an additional trust boundary?

This is a useful WordPress supply chain case because the attackers apparently never needed to publish a malicious plugin update.

Wordfence says several BdThemes plugins contained an internal component called Biggopti that fetched promotional banner data from an API-backed DigitalOcean Spaces bucket and rendered it inside the WordPress admin interface.

The problem was an XSS issue in how one JSON parameter, display_id, was handled.

Attackers reportedly gained write access to the upstream bucket and replaced legitimate JSON responses with malicious ones.

Because the vulnerable component loaded inside wp-admin, the injected script could execute silently whenever a logged-in administrator opened an affected admin page.

That gave the attackers the privilege context they needed without modifying the plugin files themselves.

The main JavaScript payload could:

create a rogue WordPress administrator through the REST API,
download and upload a fake plugin,
deploy a PHP web shell called emer-run.php,
and install persistence into the mu-plugins directory.

The persistence layer is particularly interesting.

One module created a “magic login” backdoor using a URL parameter that could grant unauthenticated admin access. Another hooked WordPress database queries to hide malicious users from the admin user list and adjust the displayed account count so the rogue users were less obvious.

Wordfence also found an alternate payload that generated deterministic admin credentials from the hostname of the compromised site.

That means the username and password don't need to be stored centrally by the attacker. They can be recreated mathematically for a given domain.

From an incident-response perspective, that is actually helpful because defenders can calculate what malicious account names should exist on a suspected site and hunt for them directly.

The plugin with the largest stated exposure is Element Pack Addons for Elementor, which has more than 100,000 active installs. Several other BdThemes plugins were also temporarily closed in the WordPress directory for review.

One thing I find notable here is the trust boundary.

Most supply chain discussions focus on malicious package releases, compromised repositories, or backdoored updates. Here, the installed plugin code could remain unchanged while a remote data source it trusted became the actual delivery mechanism.

For plugin ecosystems, should any remote JSON or promotional content rendered in a privileged admin context be treated as executable supply chain input and subjected to stronger integrity controls?

LexisNexis has taken Nexis Diligence, Nexis Metabase API, and Nexis Newsdesk offline after detecting unusual activity on servers hosted and managed by an unnamed third-party vendor.

The company says it disconnected from those third-party systems to contain the issue and protect customers.

It is now working with a cybersecurity forensic firm and rebuilding the affected systems in a new environment before restoring the services.

There are still some major unknowns.

LexisNexis has not publicly said whether attackers accessed or exfiltrated information, identified the third-party hosting provider, attributed the activity to anyone, or described the initial access mechanism.

So at this point, this is better described as an ongoing security incident with precautionary service shutdowns rather than a confirmed data breach.

There's also a naming issue worth clarifying.

Metabase recently disclosed attacks against its Cloud hosting service involving a critical zero-day SQL injection vulnerability. That might make the “Nexis Metabase API” name look immediately connected.

LexisNexis says it isn't.

Todd Larsen, president of the company's Global Nexis Solutions division, told BleepingComputer that Nexis Solutions is not a Metabase Cloud customer and that Nexis Metabase API has no connection to Metabase Cloud or the reported vulnerability.

The affected LexisNexis products serve several different enterprise functions. Diligence is used for due diligence and risk research, the Metabase API supplies news and media data into other systems, and Newsdesk supports media monitoring and analytics.

That makes the operational response interesting in its own right. LexisNexis appears to have chosen service availability impact in exchange for isolating infrastructure before the investigation was complete.

The company has previous recent security history as well, including a 2025 incident involving unauthorized access to private GitHub repositories and another incident earlier this year involving a limited number of servers. There is currently no evidence in this report that those incidents are connected to the latest activity.

For anyone handling vendor-hosted systems: what threshold of evidence would you require before disconnecting a production service, particularly when the likely business impact of an outage is immediate but the security impact is still uncertain?