Why These Two Incidents Still Matter
It is fair to ask why a 2022 breach deserves attention in late 2026. The answer is that the method has not aged at all. The techniques used against Cisco, a phone call from somebody pretending to be support and a stream of approval prompts until one is accepted, are the same techniques behind a large share of the serious business breaches reported since. The group behind the 2025 and 2026 wave of Salesforce and Okta related intrusions relied heavily on phone calls to staff impersonating IT. Our analysis of the Origin Energy breach found the same pattern: the expensive part of an attack is increasingly a conversation, not a piece of code.
The 2024 Webex story matters for a different reason. It was not an attack on a person at all. It was a product that made information easy to find because of the way meeting links were generated. Most businesses assume their communications vendor has taken care of that category of risk. Sometimes it has not, and the only way you find out is by asking the right questions before it matters.
2
separate failure modes at one vendor: people, then product
6,000+
Webex meeting links reported as openly discoverable in 2024
0
advanced exploits needed in either case
We should be clear about intent. This is not a piece about Cisco being careless. Cisco is one of the most security capable companies on earth, it detected the 2022 intrusion, published an unusually detailed account of it through its Talos research team, and fixed the 2024 flaws within weeks. That is exactly why the incidents are useful: if these methods worked there, they will work on a business of twenty people with no security team, and the defences are worth understanding.
May 2022: How Cisco Was Breached
Cisco detected the compromise on 24 May 2022 and disclosed it publicly on 10 August 2022, the same day a ransomware group posted a list of files it claimed to have taken. The Talos write-up was frank about how it happened.
| What | Detail |
|---|---|
| Detected | 24 May 2022 |
| Disclosed | 10 August 2022, by Cisco Talos |
| Starting point | An employee's personal Google account, which had their Cisco credentials saved through Chrome password sync |
| How MFA was beaten | Repeated voice phishing calls plus a high volume of push approval requests, until one was accepted |
| What the attacker got | VPN access as that employee, then movement inside the environment and attempts to establish persistence |
| Attributed to | An initial access broker with links to the UNC2447 group, Lapsus$ and the Yanluowang ransomware operators |
| Data taken | Contents of a Box folder tied to the compromised account, which Cisco said was not sensitive. The group later published about 2.8GB of files |
| Ransomware | None deployed, according to Cisco |
Two details in that table deserve more attention than they usually get. The first is the starting point. The attacker did not break into anything belonging to Cisco. They took over a personal account belonging to an employee, and found the work password sitting inside it because the browser had been helpfully syncing saved passwords to that account. That is a completely ordinary configuration. Millions of people have it on their work laptop right now.
The second is how the attacker dealt with multi-factor authentication. They did not defeat it technically. They wore the person down. According to Talos, the employee received calls from several different people, speaking English in a range of accents, each claiming to be from a trusted support organisation, while push requests kept arriving on their phone. Eventually one was approved.
The Attack Chain, Step by Step
Laid out as a sequence, it becomes obvious where it could have been stopped. Each step is a place a small business can put a control.
- Password saved to a personal profile. A work password stored in a browser profile that syncs to a personal cloud account. The work credential now lives somewhere the business does not control or monitor.
- Personal account compromised. How that happened was not the focus of the disclosure, and it hardly matters. Personal accounts are softer targets than corporate ones and nobody at work is watching them.
- Password tried against the work login. It works. The only thing between the attacker and the network is the second factor.
- The phone calls start. Callers claim to be from a support organisation the target would plausibly trust. The purpose is to make the next prompt feel expected rather than suspicious.
- The push prompts start. Request after request, at whatever hour suits the attacker. Each one is a single tap to approve.
- One is approved. Through confusion, fatigue, or because a caller said it was needed to fix a problem. The attacker is in as that user.
- New MFA devices enrolled. With a session open, the attacker registers devices of their own, so they no longer need the employee at all.
- Movement inside the network. Escalation, looking for credentials and trying to stay. This is where Cisco's detection and response caught up with them.
Steps four and five are a phone problem as much as an IT problem. The attacker used a voice call to make the security prompt feel legitimate. That is why we treat voice security and identity security as the same subject rather than two departments, a point we made at length in our guide to voice cloning and vishing.
MFA Fatigue, Explained Properly
MFA fatigue, sometimes called push bombing, is sending a large number of approval requests to somebody's phone until they accept one, whether by accident, out of irritation, or because somebody on the phone has told them to. It works because a simple push prompt asks the wrong question. It asks "is this you?" and offers a big green button, and it asks it with no context about where the sign-in came from.
The industry response since 2022 has been fairly consistent, and every one of these is available to small businesses in the common identity platforms.
| MFA method | Resists push fatigue? | Resists a fake login page? | Notes |
|---|---|---|---|
| SMS code | Partly | No | Can be read out to a caller or typed into a fake page. Exposed to SIM swap. Better than nothing, not much better. |
| Simple push, approve or deny | No | No | The method used against Cisco. Should be switched off wherever the platform allows it. |
| Push with number matching | Yes, mostly | Partly | The user must type a number shown on the login screen. A stray prompt cannot be approved blind. Microsoft made this the default for its Authenticator app in 2023. |
| Push with location and app context | Yes, mostly | Partly | Shows where the sign-in is coming from. Helps a user notice that "Sydney" is actually overseas. |
| Passkeys or FIDO2 security keys | Yes | Yes | Phishing resistant. The credential is tied to the genuine site, so there is nothing for a caller to talk somebody into handing over. |
If you do one thing after reading this, make it this: log into whatever manages your staff sign-ins, whether that is Microsoft 365, Google Workspace or something else, and check which of those methods are allowed. For most small businesses the move from simple push to number matching is a settings change and an email to staff. The move to passkeys takes a little longer and is worth it for anybody with administrator access, finance access, or access to your phone system's admin portal.
Rate limits matter as much as the method
A good identity platform will also stop sending prompts after a handful of rejected or ignored requests, and alert an administrator. If yours will send fifty prompts at 2am without anybody hearing about it, that is a configuration worth fixing today, whatever method you use.
May 2024: The Webex Meeting Links
The second incident is completely different in shape. In early May 2024, ZEIT Online, working with researchers from the group Netzbegrünung, reported that it could find Webex meetings belonging to German federal institutions simply by changing the numbers in meeting links. The meetings included ones connected to the Bundestag, federal ministries, the Chancellery, the federal information security agency BSI, and the Bundeswehr.
| What | Detail |
|---|---|
| Reported | Early May 2024, by ZEIT Online with Netzbegrünung |
| The weakness | Meeting links, including those for fixed personal rooms, could be found by counting up or down from a known link |
| Scale | More than 6,000 links to past and future meetings reported as discoverable |
| What was visible | Meeting titles, times and invitee details, including meetings marked confidential. One widely reported title concerned planning around the Taurus missile system, and the personal meeting room of the head of the German Air Force was also found |
| Cisco's fix | Cisco identified the bugs in Webex Meetings and had them patched worldwide by 28 May 2024 |
| Customer reaction | The Bundeswehr disconnected its Webex system from the internet as a precaution and suspended external use while it assessed the problem |
Security researchers generally described the underlying problem as an insecure direct object reference, which is a technical way of saying the system handed out information to anybody who asked for the right number without properly checking whether they were allowed to have it. Nobody had to phish anyone. Nobody had to guess a password. They had to count.
It is worth noticing the kind of information that leaked. Not recordings or transcripts, but metadata: who is meeting, about what, and when. For a government that is obviously serious. For a business it can be serious too. A meeting titled with a client's name and "acquisition" or "restructure" tells a competitor, a journalist or a scammer a great deal. So does knowing that your finance team meets the bank every Thursday at 10.
Why Guessable Links Are a Design Problem
The Webex case is a useful reminder that some risks cannot be trained out of staff. A person can learn to reject a push prompt. A person cannot fix how a platform numbers its meetings. That sits entirely with the vendor, and the customer's only real protection is choosing a vendor that designs for it and configuring what it offers.
Three design properties separate a meeting or call platform that holds up from one that leaks by accident.
Identifiers nobody can predict
Meeting IDs, recording links and shared files should use long random identifiers. If you can see a pattern between two of your own meeting links, somebody else can too.
Authorisation on every lookup
Knowing an identifier should never be enough. The system should check who is asking before returning anything, including titles and invitee lists, not just the meeting itself.
Enumeration gets noticed
Somebody requesting thousands of sequential IDs is not a normal user. A well built platform rate limits and alerts on that pattern long before six thousand records are gone.
Customers can see access
An administrator should be able to see who joined, who looked up what, and when. Without that log you cannot tell whether an exposure affected you.
The same logic applies well beyond video meetings. Call recording links, voicemail to email attachments, shared transcripts, fax to email, customer portals. Anything in a communications platform that produces a link is a place where a predictable identifier can turn into a leak. It is a reasonable thing to ask your phone provider about, and most of them have never been asked.
A Footnote: October 2024 and DevHub
For completeness, there was a third Cisco incident that got headlines in 2024. In mid October a well known data broker claimed to have taken a large amount of Cisco data. Cisco's response, published on 15 October 2024, attributed the exposure to a public facing DevHub resource, a site Cisco uses to share code and scripts with customers, said a small number of files not meant for public download may have been published, said it had seen no evidence that personal or financial data was involved, and took public access to the portal offline while it investigated. A second batch published in December was later said by Cisco to come from the same October incident.
It belongs in this article only as a short note, because it is a third, familiar failure mode: something intended to be public held things that were not. For a small business the equivalent is the shared folder, the public link to a document, or the old test environment somebody forgot about. It is the least dramatic of the three and probably the most common.
Two Failure Modes, Side by Side
Put the two main incidents next to each other and the lesson becomes clearer than either one alone.
| Cisco, 2022 | Webex, 2024 | |
|---|---|---|
| Way in | A person, persuaded by calls and prompts | A product, answering questions it should have refused |
| Skill required | Persistence and a convincing phone manner | The ability to count |
| Who could prevent it | The business, through MFA choice, browser policy and staff process | The vendor, through design. The customer, only through configuration and vendor choice |
| What training fixes | A lot | Almost nothing |
| What configuration fixes | Most of it: number matching, passkeys, rate limits, no personal sync | Some of it: passcodes, lobbies, private calendars |
| What it tells you to ask a vendor | How do your own staff get into systems that hold my data? | How are your links, IDs and lookups protected? |
Most small business security advice only covers the left hand column. Train staff, turn on MFA, done. The right hand column is the half that gets missed, because it depends on choices somebody else made. The honest summary is that you need to do your half well and choose vendors who do theirs well, and you can only judge the second by asking.
What Applies in Australia
Neither incident happened here, but the obligations that would apply if something similar happened to an Australian business are clear enough to set out.
| Framework | Why it is relevant |
|---|---|
| Essential Eight | The Australian Signals Directorate's baseline puts multi-factor authentication among its eight core strategies, and the maturity model has moved steadily towards phishing-resistant methods for the most important accounts. It is not legally binding on most private businesses, but it is the standard insurers, auditors and larger customers increasingly measure you against. |
| Notifiable Data Breaches scheme | Organisations covered by the Privacy Act must notify the OAIC and affected individuals of an eligible data breach, one likely to cause serious harm, and must assess a suspected breach promptly, within 30 days. Meeting metadata or call recordings exposed through a communications platform can qualify. |
| Small business exemption | Businesses with annual turnover of $3 million or less are generally outside the Privacy Act, with significant exceptions such as health service providers. The exemption still exists as at writing, but its removal has been proposed repeatedly and it does not protect your reputation. |
| Recording laws | If your platform records calls or meetings, state and federal recording laws apply to how you notify people and how you store the result. Our call recording guide covers the state by state detail. |
| Automated decisions | From 10 December 2026 privacy policies must disclose certain uses of personal information in substantially automated decisions, which may reach security tooling that makes decisions about customers. See our automated decisions guide. |
There is also a telco specific layer. Australian carriers and carriage service providers operate under anti-scam obligations that have tightened considerably, most recently through the Scams Prevention Framework. Those rules deal mainly with scam calls and texts reaching the public, but they reflect the same reality as the Cisco breach: a phone call is now one of the main tools of attack. We explained the business impact in our Scams Prevention Framework article.
Ten Controls, Ranked by Effort
Here is what we would put in place in a typical Australian business of five to two hundred staff, starting with the cheapest and most effective. None of these requires a security team.
| # | Control | Effort | Which incident it answers |
|---|---|---|---|
| 1 | Switch off simple push approval. Use number matching at minimum. | An hour | Cisco |
| 2 | Limit and alert on repeated MFA prompts. A few denials should lock the flow and tell somebody. | An hour | Cisco |
| 3 | Write a one line rule for staff: "We will never ring you and ask you to approve a sign-in or read out a code." | Ten minutes | Cisco |
| 4 | Callback verification for anyone claiming to be IT or a supplier. Hang up, ring back on a number you already hold. | A short staff briefing | Cisco |
| 5 | Turn on waiting rooms and passcodes by default for every meeting platform you use. | An hour | Webex |
| 6 | Keep meeting details off shared and public calendars. Private events, generic titles for sensitive meetings. | A policy and a reminder | Webex |
| 7 | Block work password sync to personal browser profiles. Use a business password manager instead. | Half a day | Cisco |
| 8 | Review public links to recordings, transcripts and shared folders. Expire them. | Half a day | Webex and DevHub |
| 9 | Passkeys or security keys for admins and finance. Including the admin login to your phone system. | A day or two | Cisco |
| 10 | Ask your communications vendor the questions below and keep the answers on file. | An afternoon | Both |
Controls three and four deserve emphasis because they cost nothing and they answer the part of the Cisco attack that no technology fully fixes. An attacker's phone call works when it feels routine. A clear rule, known to everyone, that the business never asks for approvals or codes over the phone turns that call from routine into obviously wrong. The same principle protects against invoice fraud and fake supplier calls, which cost Australian businesses far more each year than headline breaches do. We set out a fuller version of the playbook in how AI improves business security on the phone.
Your help desk is a target too
The same technique works in reverse. Attackers ring a help desk pretending to be a staff member who has lost their phone and needs MFA reset. Whoever handles that request, in house or outsourced, needs a verification step that does not rely on the caller knowing a few facts that can be found online. A callback to the number already on file, or approval from the person's manager, is enough for most businesses.
Securing Your Own Meetings
You cannot change how a vendor generates meeting links. You can make sure that a guessed or leaked link gets an outsider very little. This is the configuration we recommend for any meeting platform, including ours.
- Use a new, randomly generated meeting for anything sensitive. Fixed personal rooms are convenient, which is exactly why they are attractive. The German Air Force chief's personal room was one of the things found in 2024.
- Require a passcode on every meeting, and send it separately from the link where the meeting matters.
- Turn on the lobby or waiting room so the host admits people individually, and lock the meeting once everybody expected has arrived.
- Restrict dial-in access or require a PIN for phone participants. Dial-in numbers are often the weakest route into an otherwise protected meeting.
- Use generic titles for sensitive meetings. "Weekly catch up" is fine. "Smith Pty Ltd acquisition, final terms" is information.
- Keep calendars private by default, and check what a shared or published calendar actually shows to outsiders. Many show full titles and attendee lists.
- Think before recording. A recording is a copy of the meeting that outlives it. Record when there is a reason, notify participants, and set a retention period.
- Check who joined afterwards for anything important. If your platform cannot show you, that is a vendor question.
For businesses running hybrid teams, where meetings have replaced the office conversation, this is worth writing down as a one page standard. We covered the wider set of hybrid decisions in our guide to phone systems for hybrid and remote teams.
Questions for Any Communications Vendor
These cover both halves of the lesson: how the vendor protects itself from being phished, and how its product protects you from being enumerated. A good provider will answer them without a long pause. Ask your current supplier as well as any you are considering.
| Question | What a good answer sounds like |
|---|---|
| How do your staff authenticate to systems that hold customer data? | Phishing-resistant MFA for privileged access, no simple push approvals, managed devices. |
| What stops somebody ringing your support line and taking over my account? | Verification against details held on file, callbacks to registered contacts, account PINs, and changes notified to the account owner. |
| Are meeting IDs, recording links and shared files random and access controlled? | Long random identifiers, authorisation on every request, and expiry options for shared links. |
| Would you notice somebody enumerating IDs? | Rate limiting and alerting, with a clear explanation of how. |
| Can I see an access log for my account? | Yes, including admin changes, sign-ins and who accessed recordings. |
| Where is my data hosted, and who can reach it? | A specific country and a named set of people, not "in the cloud". |
| How and how fast would you tell me about an incident? | A named process, a realistic timeframe, and an explanation of what you would need to do under the Notifiable Data Breaches scheme. |
| Which third parties handle my calls, recordings or transcripts? | A short list. Every extra party is another place for an incident to start. |
That last question is worth pressing on. A lot of AI features in communications products work by forwarding audio or transcripts to another company's service. That may be fine, but it doubles the number of organisations whose staff could be phished and whose products could leak. We made the case for asking about the full stack in not all AI providers are equal.
How We Approach This
We would rather be judged on answers than on claims, so here are ours to the questions above. Uniden Voice over Cloud is Australian owned, hosted in Australia and supported by an Australian team. Administrative access to the platform uses strong multi-factor authentication, and we do not ask customers to approve sign-ins or read out codes over the phone, ever. Account changes requested through support are verified against details held on file, and we will ring you back on your registered number rather than act on an unexpected call or email.
The AI features, including transcription, summaries and AI agents, run inside the platform rather than being passed to a chain of outside services, which keeps the number of parties handling your calls small. Meeting links are generated per meeting, passcodes and lobbies are available as standard, and administrators can see call and access history for their account. If you want the detail behind any of that for your own risk register or insurer, ask and we will put it in writing.
None of this makes a business immune. The point of the Cisco and Webex stories is that capable organisations get caught by simple methods. What you can do is close the simple routes, choose vendors who have closed theirs, and make sure everybody in the business knows that a phone call asking for an approval is the attack, not the fix.