This week’s Cloud Security Newsletter topic: En (continue reading)

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter!

A ConnectWise application secret signed into customer Microsoft 365 tenants as the vendor, with no user and no MFA in the path. Eight eMudhra intermediate certificates had their private keys compromised, and ransomware operators are now using a PAN-OS GlobalProtect flaw that has been on the CISA KEV list since May. Seven stories follow, each with a concrete action.

On the Cloud Security Podcast, Ashish Rajan spoke with Ramesh Ramani, a staff security engineer at Block, about how Block got from a single 2021 bug bounty report with more than 80 findings to a DNS takeover program that "went to almost zero" by 2024. Ramani is a return guest, and his answer runs through ownership, registrar policy and a stateless pipeline, with AI kept out of the detection step for now.[Listen to the episode]

Each story includes why it matters and what to do next — no vendor fluff.

Primary source:  Huntress Research
Reporting: BleepingComputer; The Hacker News

What Happened

Attackers used a ConnectWise Cloud Backup application secret to authenticate as that app into customer Microsoft 365 tenants and obtain Microsoft Graph tokens. Huntress reported sign-ins from a hosting-provider IP starting October 15, and in one tenant the ConnectWise Cloud Management app added itself to Global Administrator and added new secrets to other applications. Huntress confirmed unauthorized sign-ins in 162 tenants as of October 16, and its October 17 update cites nearly 1,000 tenants with sign-in attempts from the attacker IP, over 300 of them successful. ConnectWise suspended Cloud Backup, SaaS Security and Cloud Management, and said on October 20 that it had reset credentials in the affected environment and was preparing phased restoration.

Why It Matters

The credential lives in the vendor's tenant, so no customer could have rotated, scoped or conditionally restricted it. The app signed in as itself, so MFA never applied and the tenant saw a legitimate service principal. Huntress notes that Graph directory reads leave no audit record, so a clean log does not prove no access. Programs that review user sign-ins but not service principal sign-ins and app role grants had no signal here.

Action for defenders: In Entra, disable (do not delete, which drops consent) the ConnectWise and SkyKick enterprise apps, remove any directory role you did not grant them, and review client secrets added to any app since October 13. Check service principal sign-in logs for the app IDs in Huntress's post.

Primary source: Cloudflare Blog

What Happened

Cloudflare says it learned at about 17:00 UTC on October 19 that the private keys for eight eMudhra intermediate certificates were compromised, and that the keys are weak enough for an attacker to forge a certificate for any domain. Cloudflare reports no active exploitation on its services. It shipped updates for the Cloudflare One Client (WARP), the 1.1.1.1 app and cloudflared 2026.10.2, and finished CDN and Zero Trust server-side mitigations at 19:20 UTC on October 20. The iOS Cloudflare One Agent was pending app review. 

Why It Matters

A forged certificate defeats the control most service-to-service traffic relies on, which is the client's trust store. Containers, sandboxes and sidecars that bundle their own CA store will not pick up a platform-side fix, which is why Cloudflare tells container users to rebuild images or move validation to egress interception. Mutual TLS setups that trust uploaded CAs need a manual review. Ramani makes a related point about DNS: cookies and auth depend on DNS and on certificates.

Action for defenders: Inventory where eMudhra-chained roots or intermediates sit in your trust stores (mTLS client CAs, custom origin pull, base images), and redeploy images that bundle CA bundles once vendors publish distrust updates. Do not clear certificate errors by disabling verification.

🛠 If you only do one thing this week: open the Entra enterprise applications list and write the named owner next to every app that holds a directory role or a client secret. Start with the ConnectWise and SkyKick apps: disable them (do not delete, which drops consent), remove any role you did not grant, and review secrets added since October 13. It takes 30 to 60 minutes and answers the first question Ramesh Ramani's DNS program had to answer: who owns this?

Primary source: Palo Alto Networks Unit 42

What Happened
Unit 42's October 19 update attributes exploitation of the GlobalProtect authentication bypass to ransomware operators: Spikey Scorpius (Qilin) and Tarnished Scorpius (Inc), with Settra named per public reporting. Observed post-access activity includes internal reconnaissance with dual-use RMM tools, lateral movement over RDP and SMB, pivoting to vCenter and ESXi, offline credential dumping from a domain controller's VMDK, and chaining with Veeam CVE-2023-27532. An October 20 update adds a separate misconfiguration where GlobalProtect profiles mapped to HTTP/HTTPS services on management interfaces exposed ports 4443 and 3879 to the internet. The CVE was added to CISA KEV on May 13, 2026, and a public proof of concept appeared on May 29.

Why It Matters
Five months after KEV listing, the flaw is an initial-access path for groups that go straight to the virtualization layer and the backup system. A patched firewall does not close the exposed-management-port misconfiguration, so a ticket closed against KEV can sit on a device that is still reachable. The vCenter, ESXi and Veeam hops put private cloud and disaster recovery copies inside the blast radius.

Action for defenders: Confirm GlobalProtect is on a fixed PAN-OS build and check whether ports 4443 and 3879 answer from the internet. Verify Veeam is patched for CVE-2023-27532 and that vCenter and ESXi management is not reachable from the VPN pool.

Primary source: Cyber Security News

What Happened

From about 07:08 BST on October 20, Google reported a power event in europe-west2-b (London). Cloud Run, App Engine, GKE and Cloud Filestore showed elevated errors. Reported downstream effects: Revolut card payments and ATM withdrawals, issues at Halifax and HSBC, the HMCTS Cloud Video Platform (the Criminal Bar Association said it was down across England and Wales from 10:00 BST), NHS app appointment booking through a third-party service, and DPD web connections. Google said the event was mitigated and most customers had recovered, but creating new workloads could still fail for some, and it promised an incident analysis.

Why It Matters

No attack is reported, so this belongs in resilience planning. Recovery prioritized existing workloads while new workload creation stayed impaired, which breaks any failover plan that needs to provision capacity in the same region. Courts and a health booking path failed through third-party providers, which shows dependency chains that few customers have mapped.

Action for defenders: Check whether your disaster recovery runbook requires provisioning new resources in the failing region, and map which of your SaaS and payment vendors run on a single GCP region.

Primary source: The Hacker News (Swati Khandelwal)

What Happened

OpenCode confirmed on October 17 that the Console, its shared-access service for AI models, was breached the night before, through unauthorized access to a "legacy system" being decommissioned. OpenCode described it as a large-scale distillation attack affecting 1.4% of Console users, those who had linked external providers. Third-party provider keys for OpenAI, Anthropic and Google Gemini in affected workspaces "may have been exposed." OpenCode says it notified affected users and the three providers. The OpenCode client tool itself was not affected.

Why It Matters

A gateway that stores customers' provider keys centrally turns one decommissioning miss into a multi-provider credential leak. The described goal is model distillation, so the first visible symptom is a spend or rate-limit anomaly at the provider, with no alert in your environment. Keys pasted into shared AI tooling sit outside your secrets manager and outside rotation policy.

Action for defenders: Find which workspaces or tools hold provider API keys, rotate any stored in OpenCode Console, review provider usage logs from October 16 onward, and set spend caps per key.

Primary source: TechCrunch

What happened:
Microsoft announced agent-security features on October 19, including "Guardian Agents" that monitor the AI agents a company uses, Defender detection of up to 60 types of agents employees bring in (named examples: Claude Code, Codex, OpenClaw), task-scoped permissions, and human approval for risky agent decisions. Microsoft's security business chief Hayete Gallot said frontier models "cannot be trusted" because they are trained to complete tasks and do not follow organizational norms. TechCrunch notes that Microsoft invests in and hosts OpenAI and Anthropic and also sells agent security. 

Why it matters:
Where agent telemetry lands is now an architecture decision. If the model provider's guardrails are the only monitor, the monitored party is grading itself. Coding agents on developer machines also become a scope item for endpoint and identity teams, since each one is an identity class with data access that nobody provisioned.

Action for defenders: Inventory which agents run on managed endpoints and which credentials they can reach, and decide whether agent action logs reach your SIEM as well as the vendor's console.

Primary source: SecurityWeek

What happened:
SecurityWeek reports that Anthropic acquired Opaque Systems, which built technology for using sensitive data in AI systems with protection enforced by the underlying hardware. Opaque's team is joining Anthropic, and its site says the company is winding down operations. Financial terms were not reported, and Opaque has not said what happens to existing customers. Opaque raised a $24 million Series B earlier in 2026 at a $300 million valuation.

Why it matters:
A vendor wind-down with no stated continuity path is a procurement problem before it is a technology one.

Action for defenders: If Opaque is in your stack, request written continuity and support terms and identify a fallback attestation path. Otherwise, add confidential-compute attestation to your AI vendor questionnaire.

Ramani's program has a fixed sequence. Block enumerated its DNS records and cleaned up the dangling ones, 400 hosted zone findings that took months of work with the vulnerability management team. It then restricted which registrars anyone could use, backed by service control policies at the cloud level and a named, searchable list of approved registrars. Education came next, and automation last, with a third-party attack surface tool as the single source of truth and tickets routed by takeover type.

He frames hosted zone takeover as the case to start with, because every subdomain under a captured zone goes with it, including callback URLs that carry tokens and cookies. By 2024 the DNS takeover bug bounty program was at almost zero.[Listen to the full episode →]

Before diving into our insights, let's clarify some key terms:

This week's issue is sponsored by AI Security Lab

Eliminating DNS Takeover as a Class: Ownership First, Automation Last

Ramani first ran into the problem in 2021, when a single bug bounty report arrived with more than 80 findings, about half on production domains. The cause was a cloud migration where anyone could spin up an account, create a zone in Route 53 and point subdomains at an EC2 instance, a load balancer, Heroku or Vercel. Ramani: "No one owns this. DNS is one of those things where it's either no one's problem, or when stuff breaks, it's everyone's problem."

He ranks the takeover types by impact and starts with hosted zones. If an attacker captures the name servers for a zone, the subdomains under it go too, and so do the callback URLs and cookies that carry auth. Ramani: "The cookies go through, the callback URL goes through, so now they get tokens." Ashish Rajan adds that exposure does not need a bug bounty program: "Could just be an email someone sends over, say, "By the way, I just own your domain. Pay me whatever."

Try this week: list every Route 53 hosted zone and Cloud DNS zone across all accounts, and mark which ones have no named owning team.

Rajan asked whether the DNS market has improved now that platforms such as Vercel make it simple to attach a domain. Ramani said it has not, and he puts the responsibility on the customer. His example: a team creates test.block.vercel.com, the CNAME for it points at a Vercel application, and Vercel has "done nothing wrong here" because the zone belongs to Block. Hugging Face, Heroku, GitHub and Lovable sit in the same position.

Ramani: "So it's very much a problem of the company that's integrating with these third parties and not the third parties themselves." No technology gives a preventive control at the third-party level. The controls have to sit in the organization's own DNS and registrars.

Try this week: pull every CNAME that points at a third-party platform and confirm the application on the other end still exists.

Rajan raised M&A as a source of dangling DNS. Ramani: "when you acquire a company, their problems become your problems now." Block took over an acquired company's name servers, and a year and a half later sold that company. The zone records were transferred to the buyer, but a step was missed. Ramani: "the Route 53 records associated with those destinations still pointed to accounts that we owned". The buyer's bug bounty reports kept arriving at Block, because Block was the party that could fix them.

The lesson he draws is that DNS ends up either unowned or in a fuzzy place where nobody knows who manages it, and M&A makes both worse.

Try this week: add a name server and Route 53 record check to your acquisition and divestiture closing checklist, and verify it 30 days after any zone transfer.

Block's first scan found 400 hosted zone issues, all internal. Cleanup was slow because deleting a zone risks breaking a production application in another account, and the account that created the record often belongs to someone who has left. Ramani: "It took me months to work with the vulnerability management team to even do a cleanup." Rajan's reaction: "Tech- technically, yes, it's easy, but the risk you're taking by just deleting the hosted zone, you're like, "Okay, what's the ripple effect that I'm going to create here for this revenue?""

After cleanup came the policy. Ramani and a colleague spent months persuading stakeholders to allow domains only at allowlisted registrars, with legal involved because domains carry brand risk. At the cloud level an AWS SCP stops registration, and a named, searchable list of approved registrars with points of contact gives people a paved path. He is direct about the gap. Rajan asked whether Block could stop someone registering a domain at an unapproved registrar such as Cloudflare. Ramani: "So the answer is no, sadly." The sequence he gives: "Starts with educa- it starts with guardrails, then education, and then finally automation." Registrar consolidation, in his words, was one of the biggest challenges they had.

Try this week: write down the registrars your organization is allowed to use, publish the list where engineers will find it, and apply an SCP that denies domain registration in your cloud accounts.

Block did not wait for a complete owner for every domain. Hosted zone takeovers go to platform security, which has registrar access and can clean the record itself. Everything else, such as CNAME and Elastic IP takeovers, goes to the team that owns the cloud account the record lives in. That works because Block keeps a catalog of applications with accounts mapped to owning teams. Ramani: "at Block, every account is associated with an application-owning team." The routing rule made automation possible. Ramani: "without having ownership, you cannot do much with DNS and automation."

Try this week: check whether every cloud account in your organization maps to an owning team in a catalog, and list the accounts that do not.

The automation uses a third-party external attack surface tool, which came to Block through an acquisition, as the single source of truth for DNS and cloud accounts. A sub-application pulls registrar data into it. When it finds a takeover, it sends a webhook, a ticket is created and routed by type, and a closed ticket without a real fix is reopened by the next scan. Ramani: "Our system's like, oh, this ticket got closed, but it's actually still, you know, an exposure."

Ramani built it stateless, with Lambda, Step Functions and API Gateway, and relied on the scanner for state so he would not run databases. Ramani: "As a security engineer, the lesser I can manage, the better." He chose AWS because it was the platform he knew best, and he says he could have built the same system in GCP. The result: "By 2024, our bug bounty program for DNS takeovers went to almost zero." The starting point was roughly 200 in 2022. The system now also catches the random domains that AI applications and their users create.

Try this week: pick one finding type your tooling already detects and wire it to open a ticket that reopens when the scan still shows the exposure.

Rajan asked whether AI would change the design. Ramani said it could enumerate the external attack surface instead of the third-party tool, with a condition. Ramani: "Can you do this in a controlled way? And, uh, will you be able to trust the signals, you know, every single time? That's the important thing." He chose not to, because he would have to tune prompts and maintain state.

He tried AI for least privilege and logs and did not get usable output. Ramani: "I needed absolute deterministic results to measure least privilege because, not just least privilege, but also logs in general." On takeover types he separates the two: "But yes, CNAME takeovers are easy to do. Hosted zone takeovers, not so much." AI can tell you a CNAME is vulnerable against an open source list of takeover-prone providers. For hosted zones he wants the source of truth to come from your own registrars and accounts first.

Try this week: run an AI-assisted CNAME check against your zone export, and compare its findings with your deterministic scanner's before you trust it.

Practical takeaways

🌐 If an attacker captured a dangling hosted zone of yours tomorrow, which team would get the ticket?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast