Australian Signals Directorate kills the essential eight

In this week's episode, we break down four major cybersecurity stories that are shaping the threat landscape in 2026.

We start with the Australian Signals Directorate's announcement that the Essential Eight cyber security framework will be retired over the next two years and replaced with a broader security model covering cloud, operational technology and AI. We examine what this means for government agencies, critical infrastructure and enterprise security teams.

Next, we look at Google's warning that proposed European regulations could unintentionally increase cyber risk by requiring broader access to sensitive search data. We explore the security implications of data sharing, API exposure and protecting one of the world's largest repositories of user information.

We then analyse the massive KDDI email breach that exposed up to 14.2 million ISP email accounts, discussing the attack against shared infrastructure, the potential impact on identity security and why email remains one of the most valuable assets for attackers.

Finally, we dive deep into the new StockStay backdoor deployed by a Russian advanced persistent threat against Ukrainian organisations. We examine the malware's architecture, command-and-control techniques, persistence mechanisms and what defenders can learn from this latest cyber espionage campaign.

If you're a SOC analyst, penetration tester, incident responder, security engineer, threat hunter or cybersecurity enthusiast, this episode delivers the technical context behind the headlines—not just the news.

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:00

Hello again. Welcome back to the podcast. This week we're looking at four stories to kick off the week. We'll cover Australia's plan to retire the Essential Eight. We'll also look at Google's concerns over proposed European search data regulations, as well as one of the largest email credential exposures of the year. And finally, a new Russian cyber espionage campaign targeting Ukraine with sophisticated malware. So let's jump into the first story to kick off the week. You've almost certainly heard of the Essential Eight. The Australian Signals Directorate introduced the framework as a practical set of eight mitigation strategies that organizations could implement to significantly reduce the likelihood of compromise. The focus of the Essential Eight centers around application control, patching operating systems, restricting admin privileges, regular backups, and limiting Microsoft Office macros. Those are some of the fundamental tenets of ASD's Essential 8. These recommendations were incredibly successful because they focus on stopping the techniques that attackers usually used. In many ransomware investigations, organizations that had fully implemented the Essential 8 were dramatically harder to compromise. So it comes as a bit of an industry shift that the Australian Signals Directorate has now announced that the framework will be retired over the next two years and replaced with the broader quote-unquote essentials series that will cover enterprise IT, cloud environments, operational technology, and potentially artificial intelligence. Essential 8 was first put out. This is when the majority of enterprise IT workloads were all on-prem. So any IT practitioner knows that the Essential 8 has a lot of on-prem advice and less cloud advice, and very little artificial intelligence, cyber posture advice. So we can see that it is being up to date with today's technology environment. When the Essential 8 was created, most organizations run Active Directory, exchange servers, on-prem file servers, Windows desktop. Security teams owned almost every component of their infrastructure. Today, this is just no longer true. Many organizations now operate in Microsoft 365, AWS, Azure. Instead of patching exchange servers, Microsoft patches them in a cloud SaaS first environment. Furthermore, instead of maintaining hypervisors, AWS manages them. Security teams are increasingly responsible for identities, cloud configuration, access policies, and encryption rather than operating systems. This is the industry shift in the what internally in the industry is called the shared responsibility model. Cloud providers secure the underlying infrastructure, while customers remain responsible for securing identities, permissions, applications, and data. So this fundamentally does change what good cybersecurity looks like. Instead of asking whether office macros are disabled, organizations are now asking whether privileged identities are protected using conditional access, whether workloads have excessive IM permissions, or whether cloud logging providers provide sufficient visibility into suspicious behavior. Moreover, ASD has also hinted that future guidance may also include, you guessed it, AI. I think this is particularly important because AI, as we all know, introduces new attack surfaces that the old essentialite doesn't really touch on. Language models are susceptible to prompt injecture, where malicious instructions are hidden inside documents or web pages to manipulate an AI system's behavior. You know, that's that's a classic recurrent technique that uh malicious actors are using in today's hacking environment that the essential doesn't really touch on. Another one, AI agents also introduce machine identities that require authentication, authorization, and least privileged uh controls, just like human users. These simply weren't considerations when the essential 8 was first deployed. So it's a bit of a uh bittersweet feeling knowing that the Essential 8 is going to be deprecated as all Australian organizations all around the country almost know it back to front. The framework has served Australia very well, but it is a lesson that cybersecurity is no longer about protecting Windows PCs, it's about protecting your identities, your cloud services, your eyes, and your system. Let's quickly move on to story two. Google has warned about European search data proposals. So our second story comes from Google, where senior security leadership has warned that proposed European regulations requiring greater access to search data could unintentionally increase cybersecurity risk. So regardless of politics involved, and obviously there is a lot, there's an interesting technical discussion here. Search history is among the most valuable data set on the planet. If you think about it, what have you searched up in your life? You would not want that list divolved to anybody. It can reveal someone's medical concerns, financial situation, political interests, employment plans, personal relationships. You know as well as I do what is in a potential Google search. Security engineers generally follow one principle with highly sensitive data. The fewer copies that exist, the smaller the attack surface. Every additional database means another environment that requires encryption, authentication, monitoring, backup, incident response, so on and so forth. If regulations require search information to be shared with more organizations, those organizations must expose APIs that authenticate requests and authorize access to extremely sensitive information. This is where Google is saying a problem lies. Most modern APIs rely on uh OAuth 2.0, OpenID Connect, and short-lived access tokens. You know, sort of three versions of API authentication. But attackers frequently target APIs through what's called broken object level authorization. Excessive permissions, it's good token storage, or flawed business logic. But it's not typically the encryption itself that is broken. Instead, this new attack surface, attackers may be able to exploit mistakes in how developers implement authentication and authorization at the API level. Security architects often debate another concept called federation versus replication. Federation leaves its original location and grants controlled access when required. Replication creates additional copies of the data. Federation generally reduces exposure but introduces complexity around identity, trust relationships, and latency. So neither approach is perfect, and designing secure systems often means balancing confidentiality, performance, and regulatory requirements. So we can see here that Google is concerned that replicating Google search in order to satisfy EU regulation is simply creating a greater attack surface. Are they right? Are they wrong? I'm not sure. I think only time will tell, but let me know what you think. Let's quickly jump into story three. So our next story takes us to Japan, where a telecommunications giant KDDI has disclosed a breach that could have exposed the email credentials of up to 14 million accounts is being reported across six internet service providers. Unlike many recent breaches that stem from phishing or ransomware, this incident appears to have originated from a vulnerability in third-party software used within KDDI's shared email platform. According to KDDI, the intrusion was detected on the 17th of June after security teams identified unauthorized access to email systems. Their investigation concluded that the attacker exploited an as-yet unnamed vulnerability in software integrated into the platform. The ISP hasn't disclosed the software vendor or assigned a CVE suggesting either the vulnerability is still under embargo, although that wouldn't be surprising to me, or the investigation hasn't progressed to public disclosure. What makes this breach particularly interesting to me is the architecture. In the reporting, it seems that rather than attacking each ISP individually, the threat actor targeted a shared email infrastructure operated by KDDI. The single platform services multiple providers, including B Globe, JCOM, and NIFTI, probably butchering these names. Meaning one successful compromise potentially exposed customers across all of them. It's a classic example of supply chain concentration risk. Compromise the shared services provider, you inherit access to every organization relying on the platform. The company believes attackers may have obtained email addresses and passwords associated with customer mailboxes. Some passwords were stored in hashed or encrypted form, but KDDI hasn't revealed which algorithms were used or how many accounts fall into each category. Because those implementation details seem to be unknown in the write-up, the company is treating the incident as though all credentials may have been compromised. This is a scary proposition for an ISP. It looks like another important detail that's being reported is that the estimated 1.4 million accounts includes inactive and closed accounts. While that inflates the overall number, dormant accounts can still provide valuable intelligence I think a lot of people often forget. Old email addresses are frequently reused as usernames on other services, making them useful for credential stuffing attacks, phishing campaigns, and password reset attempts, even. I would say this incident also highlights how email remains one of the highest value assets an attacker can obtain. You know, if you think about it, once an adversary controls an email account, they often don't need to crack additional passwords. They simply trigger password resets on cloud services, banking portals, social media platforms, so on and so forth. You can really see how in a modern identity-centric ecosystem, the inbox effectively becomes your certificate infrastructure. I don't know, is that too much of a claim? Could be, but you don't want to have your mailboxes popped. So until KDDI publishes a full post-incident report, we'll likely learn more about the exploited software, the initial access factor. So for defenders, this is another reminder that patching internally developed systems isn't enough. You also need visibility to third-party applications embedded within your environments. Go have a chat to your vendors. Okay. A last story of the day. A Russian APT deploys Stockstay backdoor against Ukraine. So this final one comes from Security Week, if you prefer proper English, where researchers have analyzed a new malware family called Stockstay, being developed by a Russian state-sponsored threat actor against Ukrainian organizations. This one's interesting because unlike commodity malware that grabs credentials and leaves, Stockstay is designed for persistent espionage, remaining hidden inside a victim network while providing operators with long-term remote access. Researchers observe the malware being delivered as part of a broader intrusion campaign targeting Ukrainian organizations. It looks like once executed, Stockstay establishes itself as a fully featured backdoor capable of receiving commands from its operators, executing arbitrary processes, transferring files, and downloading additional payloads. Rather than being a one-stage implant, this reporting seems to suggest it acts as a platform that allows attackers to expand the compromise over time. One notable characteristics of its C2 design, which sort of gives away the attribution. Instead of using obviously malicious protocols, Stock Stay is communicating over standard web traffic, really enabling it to blend into normal HTTPS activity. I think this is an increasingly common technique among APT threats because encrypted outbound traffic is difficult to distinguish from legitimate employee browser, sort of without behavioral analysis and an organization really tracking what their employee is doing within the network. Researchers have also noted that the Stockstay malware has a peculiar modular design. Instead of embedding every capability into a single executable, additional functionality can be delivered on demand. This reduces the initial malware footprint while allowing operators to customize capabilities depending on the victim. So if the objective changes from reconnaissance to credential theft or lateral movement, operators can simply deploy another module rather than replacing the implant. This modular approach would certainly frustrate defenders. The reason it's sort of so difficult to deal with malware like this is that antivirus products often rely on known file signatures. But if each campaign loads different modules, static detectors become significantly more difficult. Security teams instead need to focus on telemetry. They need to unpack that massive pile of logs they've got. You know, that have to look at IOCs pertaining to child processes, suspicious PowerShell execution, unusual outbound connections and abnormal authentication events. From an attribution perspective, research has linked the campaign to a Russian threat actor based on overlapping infrastructure, malware development patterns, and operational tactics observed in previous campaigns targeting Ukraine. Attribution in these cases rarely depends on a single indicator. Instead, it's built from multiple artifacts including C2 infrastructure, malware code similarities, Yarrow rule analysis, victimology, and the attacker's operational schedule. I think this campaign also reinforces a broader trend that I've seen throughout the conflict in Ukraine. Rather than relying exclusively on destructive malware, Russian operators increasingly favor long-term intelligence collection. We've all known this for a while. The change in the living off the land that APT operators are more and more increasingly deploying. Maintaining covert access to government departments, defense organizations, and critical infrastructure often provides more strategic value than immediate disruption. I think that wraps up all the stories for today. Thank you very much for listening. As I'm a relatively new podcast trying to get it off the ground, I'd love if you could give my podcast a follow, a like, or a comment. That would all be greatly appreciated. See you next time.