Five Eyes and Space Wars

AI Worms, Runaway Claude and Top Gun in Space

What happens when an AI assistant treats a malicious document as trusted instructions? What happens when a cybersecurity testing environment accidentally gives an autonomous model access to the real internet?

In this episode, we investigate four emerging security risks reshaping software, artificial intelligence and even military operations in space.

First, we examine Australia’s updated minimum requirements for a Software Bill of Materials, or SBOM. Learn how component hashes, digital signatures, SPDX, CycloneDX, transitive dependencies and Package URLs can help organisations identify vulnerable software across complex supply chains.

We then break down a proof-of-concept Microsoft Copilot for Word worm that uses hidden prompt injection to manipulate documents and copy itself into new files. This attack demonstrates why large language models struggle to separate trusted instructions from untrusted content.

Next, we explore how Anthropic’s Claude reached real organisations during cybersecurity evaluations. The incidents involved misconfigured internet access, exposed credentials and a dependency-confusion package downloaded by real systems. We explain sandbox isolation, egress filtering, package-manager behaviour and why AI agents must be contained by infrastructure rather than prompts.

Finally, we head into orbit to examine the US Space Force’s Victus Haze mission, satellite pursuit, orbital manoeuvring and the cybersecurity risks facing software-controlled spacecraft.

This is a technical cybersecurity news breakdown covering:

• Software supply-chain security and SBOMs
• Microsoft Copilot prompt injection
• Self-propagating AI worms
• Anthropic Claude cybersecurity testing
• Dependency-confusion attacks
• AI sandbox and network isolation
• Satellite security and orbital warfare

Thanks for listening.

Follow the podcast for more cyber security news, malware analysis, threat intelligence, AI security, and real-world attacker tradecraft.

For contact or story tips, email: cyberinvestigationsau@gmail.com

Disclaimer: This podcast is for education and awareness only. Technical details are shared to help defenders improve detection, response, and security controls.

Transcript

SPEAKER_01 0:06

Welcome back to the podcast. This week, Australia and its international Five Partners have put the cybersecurity industry on notice by redefining what they think belongs inside a software build of materials. Also, we're looking at a researcher that has created a self-propagating prompt injection worm inside Microsoft Word. We're also going to be looking at some AI stories. Sorry, not sorry. Anthropic admits that clawed models reach the public internet during security testing and compromised three real organizations. So while all the eyes have been on open AI in their quote-unquote rogue AI infiltration of Hugging Face, it looks like Claude's Anthropic is kind of doing the same thing. And finally, my interest in the space domain is growing rapidly. And I'm wanting to cover a story where United States Space Force has conduct what is essentially a top gun exercise between two satellites. Let's get into it. So the Australian Cybersecurity Centre, as well as five eye partner agencies, including CISA, NSA, FBI, from several other countries, have published and updated minimum required elements for a software bill of materials, or SBOM. So I've seen that SBOMs are becoming more and more important for organizations to consider, particularly given the prevalence of supply chain and dependency packaging vulnerabilities that we've been seeing in the industry for a number of years, but it's becoming increasingly more frequent. If you didn't know, an S-bomb is a machine-readable inventory of the components inside a software product, right? It's basically an ingredients list for software. And that ingredients list is what we call transitive dependencies. A transitive dependency is something your application did not directly install, but which was pulled in by another dependency. So, you know, your application might depend on library A, which depends on library B, which then depends on vulnerable library C. That third level dependency could still compromise your system, even though your developers didn't really ever knowingly select it. This is sort of the issue that the the industry is is needing to grapple with, which we certainly haven't solved. The new guidance on S-BOMS should cover all components. They've said including transitive dependencies with no minimum depth. It also adds information such as component hashes, hash algorithms, licenses, generation context, tool versions, so on and so forth. Here, hash fields are especially important, and I think something that many developers probably don't even know much about. A cryptographic hash such as um SHARE two five six converts a software artifact into a fixed length digest. Even one-bit modification produces a dramatically different result. This allows a recipient to verify that the binary they received matches the component described in the S-bomb. But remember, a matching hash proves integrity, not safety. So malicious software can be hashed perfectly. That hash only tells you that the artifact has not changed since the digest was calculated. The new author signature field addresses a different question. Who created this S BOM and has the document itself been modified? A digital signature, if you didn't know, normally works by hashing the SBOM and signing that digest using the author's private key. A recipient uses the corresponding public key to validate the signature, right? And of course this then creates the cryptographic evidence that the SBOM came from the claimed author and was not modified in transit. I think particularly interesting, this guidance also recommends identifiers such as package URL or Perl, a common platform enumeration or CPP, CPE. A PURL or Perl might identify the ecosystem, package name, and version of an NPM, Maven, Nuget, ByPy component, all of those package management systems. This is important because that identifier can then be correlated automatically with vulnerability databases and security advisories. So this is where S-BOMs become operationally useful. So for a suppose a critical vulnerability is announced in a particular version of an open source library. Instead of sending hundreds of emails asking application owners whether they use it or not, a security platform can query every ingested S-bomb, find the relevant Perl, and generate an exposure list within seconds. This would really clamp down on the supply chain dependency vulnerabilities that the whole industry has been seeing lately. And I think a bigger lesson here is that S-Bomb is only useful when it feeds an active vulnerability management process, right? A stale JSON file seeing in a document repository is not supply chain security. So I think this is relatively good guidance. If you haven't read it, you can go onto ASD's Published Advisories and NSA or CISA. I've always wondered how the industry is going to tackle the independency of dependency over dependency issue that is plaguing the industry at the moment. I think this is a generally a good step. Let's quickly move on to the next story. This is a bit of a new one. A prompt injection worm inside of Microsoft. We've now moved on from uh normal propagating malware worms to prompt injection worms. It's a bit of an interesting write-up. So what's happened here is that a Norwegian researcher named Hakon Maloi definitely butchered there, developed a proof-of-concept attack against copilot for Word using cross-domain prompt injection, normally abbreviated to XPIA. The attacker places malicious natural language instructions inside a Word document. Those instructions can be hidden from the human reader using white text on the background and a very small font, right? Classic hidden text. Copilot removes formatting before sending document text to the underlying language model. That's important to know. And so this means that the user sees a harmless looking document while the model receives the supposedly invisible instructions as ordinary text. This malicious document then becomes part of Copilot's context window.

SPEAKER_00 8:56

Right. This is central to the technical weakness at play.

SPEAKER_01 9:05

System instructions, the user's requests, retrieve documents, and potentially attacker controlled content are all converted into tokens when processed them by the same model. This is important to know how this works. Traditional software has a relatively strong distinction between code and data. A database value is not normally executed as an instruction unless another vulnerability, such as a SQL injection, crosses that boundary. Right? Language models have no equivalent hardware enforced separation. Both instructions and evidence are expressed in natural language. In the researcher's demonstration, it looks like the hidden prompt instructed copilot to halve financial figures in a generated report. It then told copilot to copy the hidden prompt into a newly created document. That second step transforms prompt injection into propagation. The new home report becomes another infected carrier. When a colleague later uses that report as source material, Copilot reads the hidden instructions, manipulates the text document, and copies the prompt again. And what's funny and well, maybe not funny, maybe more scary, the original malicious file is then no longer required. The payload has entered the organization's trusted document chain. That is why calling it a worm is reasonable. It has a carrier, an execution mechanism, and a method of self-replication. Unlike a conventional worm, however, the payload is natural language and the execution engine is an AI model. It's just quite interesting, scary, and fascinating at the same time. The researcher has also reported the issue to Microsoft in March. So I think that's interesting to see. Well, what has Microsoft done about it? And it looks like Microsoft introduced mitigations and later upgraded the model behind Copilot for Word. But but modified prompt wording reportedly reproduced the broader attack class. At publication, the researcher said no custom side control completely eliminated the issue. This is a current weakness in all copilot deployments. Simply asking a second model to detect malicious prompts does not fully resolve this either. To understand whether text is dangerous, the detector must first interpret text. The attacker can also use synonyms, translation, encoding, and indirect references or multi-stage instructions that remain understandable to the target model, but evade a weaker classifier. Let's quickly move on to story three. All of this week throughout InfoSec, you have probably heard about the OpenAI hugging face incident. Just today, through all of the OpenAI hugging face noise, Anthropic has disclosed something a little similar. They have said that there were three incidents in which cloud models operating during cybersecurity evaluations accessed the open internet and gained unauthorized access to real organizations.

SPEAKER_00 13:10

They've said that they've reviewed more than one thousand not one thousand.

SPEAKER_01 13:26

The models had been placed in a capture the flag exercise and told that they had no internet access. However, a misconfiguration of a third-party evaluation environment left a working route to the public internet. A little vague, if you ask me. However, this is an important distinction. The models did not exploit the sandbox vulnerability to escape. I would say unlike that of what's happened with OpenAI. Anthropic says the sandbox was never properly sealed. It's sort of interesting to say whether or not that is not an issue with the model itself.

SPEAKER_00 14:11

Because technically you could say that you could say that about you could use that logic about any CVE.

SPEAKER_01 14:21

In any case, from a network security perspective, the evaluation environment failed at egress control.

SPEAKER_00 14:30

Although just on a personal note, if you are testing a AI system, should it not be completely air gapped anyway?

SPEAKER_01 14:45

I d I I don't think it's quite right that the reporting has said that that the uh sandbox fail failed to egress control. There shouldn't have been an ability to egress in the first place, no?

SPEAKER_00 15:03

Anyway, this is just I'm thinking out loud now.

SPEAKER_01 15:08

It looks like in one instance an evaluation used the name of what is believed to be a fictional company. The corresponding domain was actually active. Claude found a real company, obtained credentials, and accessed a production database containing several hundred rows of data. In another incident, Claude found developer instructions referencing a Python package that did not exist on PyPy.

SPEAKER_00 15:39

The model recognized a dependency confusion opportunity. And I think this is a really interesting attack vector dependency confusion.

SPEAKER_01 15:53

If you've not heard of dependency confusion, it basically occurs when a build process expects an internal or non existent package, but the package manager searches a public repository. An attacker publishes a malicious package using the expected name. If the public version is selected, the attacker's code runs during installation. So Claude created a and published such a package. It remained publicly available for roughly one hour and was downloaded and executed on 15 real systems. One security scanner installed the package, executed its hidden code, and exposed credentials that Claude then used to access additional infrastructure. This is quite sneaky. That incident is an excellent example of why automated malware analysis systems must treat every package as hostile. It's a great reminder. You do not analyze a potentially hostile package while authenticating to infrastructure that matters, right? So Anthropic characterized the incidents primarily as failures of the evaluation harness and operating procedures rather than evidence that Claude had developed an independent malicious goal. That's a debate that we could have for hours, is it not? The explanation is plausible, but it does not reduce the engineering lesson, at least. An autonomous system with offensive cyber capabilities must be contained by infrastructure not by a sentence in its prompt. Who would have guessed? Let's quickly move on to our last story of the day. If you haven't guessed by now, I have a great interest in the cyber domain that operates in space, or whenever there's a juicy space cyber story, I love covering it.

SPEAKER_00 18:01

And this one blends space and autonomous AI agents within the space domain.

SPEAKER_01 18:16

So what's happened here is that the United Space Forces Victus Hayes mission involved Rocket Labs, Rocket Lab being the New Zealand hardware rocket company. It involved their Puma spuma spacecraft and true anomalies, true anomaly being another space company, involved their Jackal spacecraft conducting rendezvous and proximity operations in low Earth orbit. So a rocket lab launched Puma just sixteen hours and forty-two minutes after receiving its notice to launch. The spacecraft was commissioned in under thirty-eight hours and then performed orbital maneuvers to pursue, monitor, and approach and photograph another satellite. Orbital pursuits does not work like an aircraft chase. What they're trying to do is test that or look at a satellite that cannot simply point at its target and accelerate towards it. So how then do you gather and collect evidence, photography, videos against a quote unquote potentially malicious satellite? Because changing velocity changes the shape and period of a satellite's orbit. Cannot just drive up to a satellite in space. To catch a spacecraft ahead of you, you may temporarily move into a lower orbit, where you travel around the Earth faster before raising your orbit again near a target. Operators calculate a sequence of burns while accounting for relative motion, fuel limits, uncertainty, and even collision risk. The spacecraft must also determine the target's relative position using ground tracking, right? Optical sensors and navigation filters. A Kalman filter, or Kalman, can combine noisy measurements with a mathematical model of orbital motion to continually update estimates of position and philosophy.

SPEAKER_00 20:38

Philosophy, I meant velocity, if you prefer proper sentences.

SPEAKER_01 20:45

I think what's interesting from a infosec perspective, these spacecrafts are remote cyberphysical systems, or CPSs. Their command links, ground stations, software supply chains, cryptographic keys and navigation data all become potential attack vectors. A compromised command system could issue an unsafe maneuver. Manipulated tracking data could corrupt the spacecraft's estimate of another orbit's trajectory. A stolen signing key could potentially make malicious commands appear legitimate. The whole operation therefore demonstrates more than a responsive launch. It shows that future conflicts may involve software-defined pursuits and inspection operations hundreds of kilometers above Earth. I think that is such a cool thing, but also requires cyber operators to be very aware of what's coming in the future. I think that wraps up our stories of the day. This week in cybersecurity was pretty wild. Um, but as always, it's a pleasure covering it. Um still the new podcast. Hoping you're enjoying the content. Please leave a like, a comment, follow me on the podcast catcher websites or wherever you get the podcast. It's all much appreciated. See you next time.