Australia's Silent Signal War

Russian state-sponsored hackers are targeting poorly secured routers, Poland’s energy infrastructure has faced an attempted cyberattack attributed to Russia, frontier AI systems are becoming more capable through advanced model harnesses, and ShinyHunters is exploiting Salesforce environments through OAuth abuse, voice phishing and exposed Experience Cloud data.

In this episode of Cyber Investigations Australia, we break down the technical details behind each story, including insecure SNMP configurations, router configuration theft, TFTP exfiltration, operational technology risks, destructive wiper malware, AI agent orchestration, automated vulnerability research, OAuth refresh tokens, malicious connected applications, Salesforce Aura endpoints and GraphQL pagination.

This episode is designed for cybersecurity professionals, students and technically curious listeners who want to understand not only what happened, but how the underlying technologies and attack methods actually work.

Topics covered include Russian cyber operations, FSB Centre 16, router security, SNMPv3, critical infrastructure attacks, Poland’s electricity grid, DynoWiper, frontier AI, AI model harnesses, autonomous cyber agents, ShinyHunters, Salesforce security, OAuth token theft, vishing and cloud identity attacks.

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_00 0:05

Welcome back to the podcast. This week we're looking at four developments that reveal how cyber operations are evolving. And in particular, we're looking at Russian intelligence services, which have allegedly been exploiting poorly secured routers through protocols that many organizations have forgotten that are even enabled. We're also looking at the recent UK and EU formal attributed attacks against Poland's electricity infrastructure to Russia. Also, the Australian Signals Directorate has warned that the performance of an artificial intelligence system increasingly depends not on the model itself, but on the engineering built around it. What is being more and more referred to as harnessed engineering. And finally, we'll look at Microsoft has mapped a year of shiny hunters-linked attacks against Salesforce environments in which the attackers often required no vulnerability, malware, or stolen passwords. So let's jump into the first story. The Australian Signals Directorate has joined the NSA, CISA, FBI, and numerous other international partners in warning that actors associated with Russia's FSB service, specifically FSB Centre 16, are continuing to compromise vulnerable and poorly configured routers. What makes this campaign technically interesting is that the attackers are not necessarily relying on sophisticated sophisticated zero-day exploits. But in many cases, they are abusing simple network management protocol. Yes. SNMP using insecure configurations that should have disappeared years ago. SNMP allows administrators and monitoring systems to query and manage network equipment. Information exposed through SNMP is organized into a hierarchical database called a management information base or MIB. Individual pieces of information inside that database are addressed using object identifiers, normally called OIDs. An OID might expose the device hostname, interface statistics, routing information, or depending on the vendor and permissions, management function capabil management functions capable of changing the device. Older versions of SNMP authenticate requests using what is known as a community string. In practice, this functions like a shared password. But SNMP version 1 and version 2C transmit that string without meaningful cryptographic protection. Organizations have also historically left predictable strings such as quote unquote public for read access and private for read-write access. FSB linked actors have reportedly been scanning internet address ranges for devices responding to SNMP version 1 or 2. They then attempt common or default community strings, particularly looking for read-write access. Once they have that level of access, they can send an SNMP set request containing vendor-specific OIDs that instruct a router to copy its own configuration into a file and transfer that file to infrastructure controlled by the attacker. On Cisco Equipment, for example, the advisory highlights OIDs within Cisco's configuration copy MIB. The attacker can populate variables defining the source configuration, the transfer protocol, the destination server, and the file name, and then activate the copy operation. The router effectively exfiltrates itself. A stolen configuration can contain interface addressing, access control lists, routing statements, VPN definitions, network diagrams, SNMP strings, and locally sort credentials. Even when passwords are not stored in plain text, some Cisco password formats provide little protection. Cisco Type 7, for example, is reversible obfuscation rather than secure hashing. Once an attacker obtains the configuration, recovering a type 7 password is trivial. The advisory recommends type 8 for stored user credentials and warns against types 0, 4, and 7. The exfiltration is commonly performed using TFTP or Trivial File Transfer Protocol. TFTP uses UDP port 69, provides no authentication, and was designed for simple functions such as transferring boot files inside trusted networks. It is not a protocol that should normally be exposed across an internet perimeter. Because SNMP commonly uses UDP, an attacker can also spoof the source address of a request. UDP does not begin with the three-way handshake, like TCP, so if the router does not cryptographically know the address of the IP header belongs to the real sender, the attacker still needs the resulting file to reach infrastructure they control, but source spoofing can obscure when the command originated, but source spoofing can obscure where the command originated and complicate log analysis. The remediation is therefore more specific than simply telling organizations to patch their routers. Administrators should disable SNMP versions one and two wherever possible and move to SNMP version three using authpriv security level. AuthPriv provides both message authentication and encryption, protecting the integrity and confidentiality of management traffic. SNMP access should also be restricted through access control lists so that requests can originate only from the authorized management systems, preferably over separate out-of-band management network. The advisory additionally recommends blocking unnecessary SNMP, TFTP, and Cisco Smart Install traffic at the perimeter. Cisco Smart Install uses TCP port 4786 and was intended to simplify the deployment of new switches. Once installation is complete, however, leaving the feature exposed creates another remote management surface that attackers can abuse. This campaign demonstrates why routers are such a valuable espionage targets. Compromising an endpoint may expose one user, but compromising a network device can expose the structure and traffic flows of an entire organization while also providing infrastructure that can be reused to disguise later operations. Let's quickly move on to story two. It's being reported that the United Kingdom and European Union have now formally attributed an attempted December 2025 attack against Poland's electricity infrastructure to the same Russian organization I mentioned before, FSB Center 16. Polish officials said the operation attempted to disrupt communications between renewable energy equipment and power distribution operators. The attack was unsuccessful, but authorities warned that it could have potentially interrupted electricity for hundreds of thousands of people during winter. Attackers have reportedly attempted to deploy destructive malware known as Dino Wiper. It is also important not to overstate the publicly available technical evidence. Officials have not released a complete architecture diagram or detailed sequences showing exactly how the attackers moved through the Polish environment. However, the description allows us to understand the type of boundary they were reportedly targeting. Renewable generation is increasingly distributed. Instead of electricity coming from a small number of large power stations, a grid may receive power from thousands of wind turbines, solar installations, battery systems, and remotely managed substations. Operators need telemetry showing voltage, frequency, current generation, capacity, and device state. While control channels allow them to curtail generation, change operation modes, or disconnect equipment when grid stability requires it. This creates a cyber physical control loop. Sensors measure the physical system. Communications networks transport those measurements. Supervisory software decides what action is required, and control messages are sent back to field equipment. So disrupting communications does not necessarily mean directly taking control of a turbine or opening a circuit breaker. An attacker may instead deny operators accurate telemetry, prevent commands from reaching remote devices, corrupt config information, or destroy the systems responsible for coordinating generation. That distinction matters, I think, because electricity networks must continuously balance supply and demand. Grid frequency is an immediate physical representation of that balance, right? If generation significantly exceeds demand, frequency rises. If demand exceeds generation, frequency falls. Protection systems can disconnect equipment to prevent damage, but large and poorly coordinated changes can still create instability and cascading outages. So it looks like the Russian deployed malware, Dino Wiper, adds another dimension. A wiper is not ransomware, because its primary purpose is destruction, right? Rather than financial recovery. Instead of carefully encrypting files and retaining a key, a wiper may just overwrite file contents, corrupt file system structures, destroy boot records or otherwise make machines unrecoverable. In an energy environment, wiping engineering workstations, management servers at the same time as disrupting communications could significantly delay restoration, even if the physical equipment itself remains functional. The attempted Polish operation should therefore be understood as a combination of cyber disruption and operational timing. An attack that is inconvenient during mild weather could become dangerous during a freezing winter, particularly in Poland, right? Where it gets cold, when electricity is required for heating, communications, transport, and medical services. So I think having thought about this story, attribution in this context is not only about identifying malware code, it can combine infrastructure analysis, operational patterns, intelligence collection, so on and so forth. And I think ultimately this is a lesson to be learned for cyber defenders. Let's quickly move on to story three. And ASD, in its most recent update on Frontier Artificial Intelligence, has said the most important point to consider, well, increasingly, one of the most important points to consider when reviewing artificial intelligence systems increasingly depends not only on which language model is being used, but on the system surrounding that model, which here ASD and I think the broader cyber industry in general is referring to as an AI model harness. Sandaling language models essentially is a prediction engine, as we all really know by now, next token prediction. You can provide context and a prompt and it generates an output. Right? On its own, it does not maintain a reliable long-term plan. Inspect a repository, run a compiler, launch a debugger, and so on and so forth. A harness supplies that missing engineering layer. It can divide a large objective into smaller tasks, decide which tools should be called, store intermediate results, provide agents with specialized instructions, validate output and route failures back into another interaction with the model. ASD describes this as the agentic scaffolding around one or more models, including planning, tool use, output verification, and multi-agent coordination. Consider automated vulnerability research, right? One agent could map the application's attack surface and identify externally reachable functions. Another could perform static analysis, tracing untrusted input into dangerous memory operations or database queries. And then a third could generate test cases or fuzzing inputs. When a crash occurs, another agent could inspect the stack trace, determine whether the fault is reproducible, and assess whether control of memory or program logic is possible. This is agentic harnessing. This matters because language models are probabilistic and can produce confident but incorrect conclusions. A useful cyber harness, therefore, needs verification mechanisms that connect claims to observable evidence right out of the box. If an agent claims that it's found, for example, a buffer overflow, the harness should require a reproducible input, a debugger trace, the affected code path, and evidence that the crash is not merely a denial of service. If it proposes a patch, the system should compile the software, run regression tests, and confirm that the change closes the vulnerable path without creating a new failure. ASD highlighted Microsoft's M-System, which reportedly coordinates more than 100 specialized agents across multiple frontier models to discover, debate, and prove vulnerabilities. It also pointed to defensive harnesses from Anthropic, Cisco, OpenAI, and the Hadrian. I haven't actually heard of Hadrian before. Should check that one out. In any case, I think crucially, ASD argues that a well-designed harness using mid-tier models may achieve results comparable to less sophisticated systems using more advanced underlying models. This really changes the threat model and the threat landscape. Organizations cannot assume that only an attacker with access to the most expensive frontier model can create meaningful automation. Open source orchestration frameworks, coding agents, scanners, so on and so forth, inexpensive models can be combined into specialized pipelines. The same architecture that helps a defender identify and patch a vulnerability can be redirected towards finding a flaw, build a POC, and search the internet for exposed targets. I think really the takeaway here is the advantage will therefore belong less to whomever has the most impressive chatbot, and more to whoever can connect models to high-quality tools, data verification and remediation processes. Let's quickly move on to our final story of today. This story concerns Microsoft's analysis of a year of Shiny Hunters linked activity targeting Salesforce environments. Microsoft identified three broad access paths, those being voice phishing that convinces a user to authorize a malicious application, theft of OAuth tokens from trusted software vendors, and excessive guest permissions in public Salesforce experience cloud sites. The first method looks like it begins with a telephone call. Classic, classic. Attackers impersonate IT support and guide an employee through authorizing a connected Salesforce application that may present as a legitimate version of Salesforce data loader. OAuth is intended to let one application access another service without receiving the user's password. The user authenticates directly with Salesforce and approves a defined set of permissions known as scopes. Salesforce then issues tokens that the connected application can use while calling its APIs. This means the attack does not need to defeat MFA. The legitimate user completes the legitimate authentication process and then intentionally delegates access to malicious applications. From Salesforce's perspective, Salesforce will say that five times in a row, the resulting API request may appear properly authorized. And depending on scopes granted to the user's own privileges, the application can enumerate CRM objects, query records, and export data. It looks like attackers can then use Salesforce object query language, or SOQL, to search objects such as accounts, contacts, opportunities, so on and so forth. Typical Salesforce information. Support cases are particularly valuable because employees sometimes paste passwords, cloud keys, diagnostic logs, or internal URLs into a ticket, right? Let's move on to the second part that it's look that looks like Shiny Hunters is continually utilizing. So rather than tricking every customer individually, attackers compromise a software vendor whose integration already has OAuth access to many customer environments. Stealing that vendor's access and refresh tokens can create a supply chain compromise in which one breach provides access to hundreds of downstream Salesforce tenants. The third technique does not require a token at all. Microsoft observed attackers probing Salesforce Aura endpoints associated with Salesforce Excloud sites. These sites can provide functionality to unauthenticated guest users, but organizations sometimes assign the guest profile permissions to access more objects or fields than intended. The Threat Act is reportedly called the Aura GraphQL controller and used cursor-based pagination to move through results sets beyond the normal 2000 record query limit. Pagination legitimate functionality, the server returns a cursor representing the current position, and the client submits the cursor to request the next group of records. When the guest accesses over permissioned, however, an unauthenticated attacker can automate this process and systematically extract the entire accessible data set. Defenders, it looks like, you know, if there's any takeaway, need to monitor what happens after authorization, which connected application is issuing the requests. Defenders need to be looking at which OAuth scope does it hold. Has the previous quiet, sudden integration suddenly started querying thousands of records? Is it accessing unusual objects? So on and so forth. Organizations should inventory every connected Salesforce application, remove unused integrations, reduce OAuth scope to the minimum required, review experience, cloud gas permissions, and ensure that the API and event telemetry is actively monitored. I think that about wraps up our four stories that has kicked off the weekend cyber this week. Thank you very much for tuning in. Please leave a comment or a like. All of it helps to increase our podcast visibility. See you next time.