Trusted Until It Isn't

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

Welcome to What Matters in Cyber

SPEAKER_01 0:01

Each week we break down the biggest cybersecurity stories: emerging threats, new technologies, and the changes that matter to you. What happened, why it matters, and what to do next. This is What Matters in Cyber with your host Steve.

SPEAKER_00 0:22

Hi, I'm Steve, and welcome to What Matters in Cyber. It's Monday, October 5th, and this is your weekly look at the cybersecurity stories worth paying attention to. This week, millions of military personnel and their families learn that some of their most sensitive information was exposed for months. A ransomware group is using SharePoint vulnerabilities to attack Warder, telecommunications, and government organizations. Microsoft temporarily loses control of its own account on X to people promoting a cryptocurrency token based on Clippy. Yes, Clippy. Apparently the little paperclip has returned from retirement and gone into crypto. Because that is precisely what the world was missing. We also have urgent patches affecting Citrix, Fortinet, and GitLab, plus new evidence that AI agents searching for public information decided that trying SQL injection was an acceptable research technique. The thread connecting these stories is trust, trusted systems, trusted accounts, trusted software, trusted users, and now trusted AI agents. But trust, however useful it may be, is not a security control. Before

Kiteworks Follow Up

SPEAKER_00 1:38

we get to this week's main stories, we need to close the loop on something from last week's episode. Kiteworks had advised customers to shut down their secure file transfer systems temporarily after receiving credible intelligence about a possible imminent attack. At the time there was no confirmed compromise and very little public technical information. I said that the precaution appeared responsible but that it needed to be followed by transparency. We now have that follow-up. Kiteworks lifted the shutdown recommendation, restored its hosted systems, and said it had identified and remediated a critical vulnerability. The company also said it had found no evidence that the vulnerability had been exploited. That does not mean the weekend was painless for customers. Taking an important system offline rarely wins anyone a popularity contest. But this is what responsible follow-through looks like. The company acted on credible intelligence, used the shutdown window to investigate and remediate the risk, restored services, and publicly explained the outcome. Later in the week, Kiteworks also published security updates covering a much broader collection of vulnerabilities across its products. Customers should confirm that they are running the current supported release rather than assuming that restarting the system completed the job. My view from last week has not changed. In fact, it has probably strengthened. There are occasions when control disruption is better than uncontrolled compromise. The difficult part is having the leadership, preparation, and authority to make that decision before you become the next breach notification. Our

Pentagon Contractor Data Breach

SPEAKER_00 3:22

first main story concerns the Defense Manpower Data Center, or DMDC. DMDC maintains personnel and identity records for people connected to the United States military. That includes active duty and reserve personnel, veterans, civilian employees, contractors, and military family members. The Pentagon has confirmed that unauthorized users accessed files in one of DMDC's systems between October 2025 and July 2026. That is roughly nine months of access before the activity was discovered. The incident affected approximately 2.76 million living people and another 294,000 people who were deceased. The information exposed varied by person, but could include names, dates of birth, contact details, social security numbers, demographic information, and military occupational specialties. The records were reportedly stored without encryption on the affected server. The Pentagon says it has no evidence at this time that the information has been misused. Those affected are being offered 12 months of credit monitoring. There are several things worth unpacking here. First, no evidence of misuse does not mean the data is safe. It means misuse has not been detected or attributed. Stolen identity data does not expire when the free credit monitoring subscription does. Social security numbers, dates of birth, and employment histories can remain useful for years. Criminals can combine them with information from other breaches to make fraud and impersonation attempts far more convincing. Second, this is not only a consumer identity theft problem. Military roles, employment history, and personal details can be useful for intelligence gathering, social engineering, and identifying individuals who may have privileged access or sensitive knowledge. Third, the nine-month period matters almost as much as the number of records. The initial vulnerability allowed entry, but the monitoring environment apparently did not identify the unauthorized access for most of a year. Patching the doorway is important. Understanding why nobody noticed people walking through it for nine months is equally important. My take is that one year of credit monitoring feels inadequate for an exposure of this sensitivity and duration. The response should include longer-term identity protection, clear guidance for those affected, and a direct explanation of how unencrypted personal information ended up on an accessible file sharing server. This incident is a reminder that data inventory and retention are not administrative housekeeping. If an organization does not know exactly where sensitive information is stored, why it is there, whether it is encrypted, and who is accessing it, it does not really control that information. It is simply hoping the right people are using it. Next,

Microsoft Clippy Account Takeover

SPEAKER_00 6:22

something slightly less severe, but wonderfully illustrative. Microsoft has confirmed that its official account on X was accessed without authorization. The account, which has more than 13 million followers, was used to amplify messages promoting a clippy-themed cryptocurrency token. The attackers changed the account's profile image, followed an account impersonating Microsoft's old paperclip assistant, and promoted a token claiming an association with Microsoft's stock. Microsoft removed the unauthorized posts, secured the account, and said it was investigating how the access occurred. We should be careful not to invent an explanation before that investigation is complete. We do not yet know whether this involved stolen credentials, a compromise session, social engineering, delegated access, or a problem somewhere in the platform. But we do know the lesson. Corporate social media accounts are production systems. They may not process orders or run factories, but they speak with the organization's identity. A single post can move markets, mislead customers, spread malware, or give a scam instant credibility. Yet these accounts are often managed through a mixture of shared passwords, personal devices, outside agencies, former employees, and permissions that were granted for a campaign three years ago, and then quietly forgotten. For well-known brands, account security should include phishing-resistant multi-factor authentication, tightly controlled administrative access, regular reviews of connected applications and delegated users, rapid alerting, when account details change, and a tested recovery route with the platform. The same principle applies to smaller organizations. An attacker does not need 13 million followers if the account they compromise is trusted by the right 50 customers. And perhaps the strangest part of this story is that a Clippy endorsement might have seemed plausible. He always was rather persistent.

Warlock Ransomware Targets SharePoint

SPEAKER_00 8:22

Our third story involves a ransomware operation known as Warlock. Researchers at Symantec say a China-linked group they track as long legs has continued using Microsoft's SharePoint vulnerabilities to break into organizations. During the past two months, the group reportedly attacked at least four organizations in Portuguese and Spanish-speaking countries across Europe, Africa, and Latin America. The victims included a water utility, a telecommunications provider, a regional government organization, and a university. The group first became prominent through its use of the SharePoint vulnerabilities commonly referred to as ToolShell. Researchers say it continues to favor SharePoint as an initial point of entry and maybe using both older and newer vulnerabilities. After gaining access, the attackers have used a vulnerable but digitally signed driver to disable security tools. They have also abused Visual Studio Code's tunneling feature to maintain covert remote access before deploying ransomware. There are two particularly important lessons here. The first is about systems exposed to the Internet. SharePoint is not merely somewhere to store the holiday calendar and a policy document that nobody has opened since 2019. It can contain sensitive documents, connect to identity services, and provide a route deeper into the organization. Internet-facing collaboration platforms need the same urgency and scrutiny as firewalls, VPN appliances, and remote access gateways. The second lesson is that installing the patch may not complete the response. If a vulnerable system was exposed before it was updated, particularly while exploitation was known to be active, organizations should consider the possibility that access occurred before the fix. That means reviewing logs, looking for web shells and unexpected accounts, checking for suspicious tunnels or remote management tools, and examining whether credentials need to be rotated. This is especially important in critical infrastructure, where a compromise can become an operational and public safety problem, rather than merely an IT incident. Now for the Monday

Monday Patch List

SPEAKER_00 10:37

morning patch list, the first priority is Citrix Netscaler ADC and NetScaler Gateway. Citrix disclosed two critical vulnerabilities that have been exploited in attacks. One can allow an unauthenticated attacker to execute commands remotely against affected deployments. The other is a memory overflow issue that can lead to remote code execution or denial of service when the relevant configuration is enabled. These are externally exposed systems that frequently sit between users and important internal services. If your organization operates customer-managed Netscaler appliances, confirm the installed build against Citrix's current advisory and review the published indicators of compromise. Do not stop at the question, was the patch installed? Ask, was the appliance exposed before the patch? And have we checked for evidence that it was already accessed? The second priority is Forty Mail. Fortinet disclosed a critical path traversal vulnerability that can allow an unauthenticated attacker to write files to the underlying system using crafted web requests. Fortinet says the vulnerability has been exploited, and CSER added it to the known exploited vulnerabilities catalog. Organizations using Forty Mail should update to a fixed version and investigate unexpected files or activity on exposed systems. The third item is GitLab's self-hosted AI gateway. GitLab has fixed a critical vulnerability with a severity score of 9.9. Under certain conditions, an authenticated user with access to the duo agent platform could craft a flow configuration that escapes the prompt template sandbox and executes commands on the AI gateway. GitLab hosted gateways have already been fixed. The action is for organizations running the gateway themselves. There is no need to panic simply because the words AI, critical, and remote command execution have appeared in the same paragraph. But there is a useful architectural lesson. Prompt templates, agent configurations, and workflow definitions are code adjacent. If they influence tools, commands, or execution environments, they require validation, access control, and change governance. In summary, the Monday questions are: do we run Netscaler? Do we run Fordymail? Do we host our own GitLab AI gateway? And can someone provide technical evidence that the vulnerable systems are updated and have been checked for compromise? Our

AI Agents Attempt SQL Injection

SPEAKER_00 13:16

final story begins with a fairly ordinary request. Find some public statistics. Researchers at the nonprofit Transloose have reported that AI agents searching for government information used increasingly aggressive techniques against websites in the United States and Canada. In one incident, agents searching for school statistics made more than 200,000 requests to a United States Department of Education website. The activity included a basic SQL injection attempt designed to bypass the site's normal filtering. In another incident, agents looking for historical Canadian divorce records sent hundreds of requests to Library and Archives Canada. Thirteen of those requests contained attack style inputs, including SQL injection probes, a cross-site scripting test, and attempts to enable debugging or change output formats. The good news is that the attempts appear to have failed. Researchers found no evidence that the agents accessed non-public information and the relevant government organizations reported no known compromise. Attribution also requires care. Transloose said some of the activity resembled previously observed OpenAI associated agent behaviour, but it did not confidently attribute all of these attempts to open AI. OpenAI said it was reviewing the findings and had briefed Canadian officials. So this is not a story about a malicious artificial intelligence declaring war on government databases. It is more interesting than that. These agents appear to have been trying to complete legitimate information retrieval tasks. The problem is that their methods drifted from searching into probing for vulnerabilities. The objective was apparently find the answer. The missing instruction was without attempting to break into anything. This is what excessive agency looks like in practice. It does not require consciousness, evil intent, or a glowing red robot eye. It requires a capable system, a vaguely defined goal, access to tools, and inadequate boundaries around what it is permitted to try. Microsoft's newly released digital defense report makes the broader point that AI is compressing parts of the attack process. Microsoft says the median time from vulnerability discovery in the wild to weaponization has fallen below 24 hours, while enterprise remediation of critical external vulnerabilities can still take 30 to 60 days. That gap is uncomfortable enough when attackers are working manually. Automation makes it much less forgiving. For organizations deploying AI agents, the security conversation must go beyond the model. What identity does the agent use? Which data can it reach? Which tools can it call? Can it create accounts? Reuse credentials, or submit arbitrary web requests? Are actions rate limited? Which actions require approval? And can the organization reconstruct exactly what the agent did after something goes wrong? An agent should not receive broader authority simply because its objective sounds harmless. Sometimes find a statistic apparently becomes try an SQL injection and see what happens. That is a governance problem, wearing a clever technical hat. So,

My Take and Closing

SPEAKER_00 16:33

what matters in Cyber this week? For me, the answer is that trust is not a security control. The Pentagon trusted a file sharing system containing sensitive personnel information, but unauthorized users reportedly accessed it for months. Microsoft's customers trusted that a message from Microsoft's official account actually came from Microsoft. Critical infrastructure operators trusted SharePoint as part of their working environment, while attackers used it as an entrance. Organizations trust security appliances to protect the network, even though those appliances are often among the most attractive targets on it. And we are beginning to trust AI agents to find information and complete tasks, sometimes without defining the limits of how those tasks may be completed. Trust is necessary, modern organizations could not operate without it, but trust should always be accompanied by verification, limited access, monitoring, and the ability to revoke that trust quickly. This week I would encourage you to ask one question. Which account, system, vendor, or automated agent do we trust so completely that we have stopped checking what it is actually doing? That may be where the next problem is already developing. If you have a view on any of today's stories, particularly the Pentagon Breach or the behavior of autonomous AI agents, I would like to hear it. I'm Steve, and this has been What Matters in Cyber. Subscribe wherever you get your podcasts, share the episode with someone who might find it useful, and join the conversation. I'll see you next Monday.