Cyberside Chats: Cybersecurity Insights from the Experts

Stay ahead of the latest cybersecurity trends with Cyberside Chats! Listen to our weekly podcast on Tuesdays at 6:30 am ET and join us live once a month for breaking news, emerging threats, and actionable solutions. Whether you’re a cybersecurity pro or an executive who wants to understand how to protect your organization, cybersecurity experts Sherri Davidoff and Matt Durrin will help you understand and proactively prepare for today’s top cybersecurity threats, AI-driven attack and defense strategies, and more!

Cyberside Chats: Cybersecurity Insights from the Experts is a technology podcast hosted by Chatcyberside, with 85 episodes on record and a Required Pod Score of 82. PitchCentric scores this show on Booking Probability, Listen Score, and live audience signals refreshed every 24 hours.

Chatcyberside hosts Cyberside Chats: Cybersecurity Insights from the Experts, a technology show with 85 episodes published.

Our AI reads these to draft pitches. Use them as grounding for a pitch that cites a real guest and a specific topic.

• 

  Episode #87

  Your Security Tools Can Be Used Against You

  Aug 25, 202616 min

  On the first night of a remote internal penetration test, a bank’s own vulnerability scanner tried to log in to our computer, using a highly privileged account. That was all it took. We had started with nothing: a foothold on the internal network, no credentials, no domain access. A day later we had domain admin and the password hashes of every user in the bank, a complete takeover built out of the bank’s own security tooling. Sherri Davidoff and Tom Pohl walk through the whole chain: why we relayed the scanner’s login instead of cracking it, the “low severity” SMB signing finding the entire compromise turned on, and the misconfigured certificate template that handed over domain admin. Then they widen the lens: the breach-simulation platform that had a domain admin account of its own, the backup server with administrative rights nearly everywhere, and why the tools you bought to watch your network are the ones most worth attacking. Plus what to actually change: not just what your scanner finds, but how and to what it authenticates. Key Takeaways: Your security tools are among the most attractive targets on your network, because you gave them the keys. Scanners, backup, EDR, and breach-simulation platforms routinely hold domain admin and reach every host. Inventory those privileged service accounts and know exactly what each one can reach. Check how your scanner authenticates — not just what it finds. Credentialed scanning that will authenticate to an untrusted or unknown host, without signed/mutual authentication, hands out privileged credentials to whatever answers. Ask your vendor how to enforce this and verify the setting. “Low / informational” findings are the pivot. Missing SMB signing is the classic example: it barely rates in a report, and it’s the hinge the whole bank compromise turned on. Enforce SMB signing. 4. Audit your Active Directory Certificate Services templates. A single over-permissive template turns into “issue myself a certificate as any user in the company,” which turns into domain admin. Most organizations have never looked. Least privilege applies to tooling, and it’s usually where least privilege gets skipped. Scoped accounts, tiered admin, no single account with admin everywhere, no shared credential across host classes. Resources: Microsoft — Control SMB signing behavior (how to require signing) — https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing Tenable — Plugin 57608, “SMB Signing not required” (rated Medium — the finding this compromise turned on) — https://www.tenable.com/plugins/nessus/57608 Microsoft MSRC — Mitigating NTLM Relay Attacks by Default — https://www.microsoft.com/en-us/msrc/blog/2024/12/mitigating-ntlm-relay-attacks-by-default Microsoft — KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services — https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429 SpecterOps — Certified Pre-Owned: Abusing Active Directory Certificate Services (Will Schroeder & Lee Christensen) — https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf Rapid7 — Authentication on Windows: best practices (vendor guidance recommending administrator-level scan accounts) — https://docs.rapid7.com/insightvm/authentication-on-windows-best-practices/

  ListenShow Notes
• 

  Episode #86

  Zoomsday: Anyone in Your Meeting Can Own You

  Aug 18, 202612 min

  Anyone who can join your Zoom meeting could run code on your device: no click, no download, no sign that anything happened. That’s what Ⓐ Security disclosed on 11 August, in four vulnerabilities in Zoom’s screen-share annotation feature. Zoom patched quickly. The part that should concern security leaders is how the exploit was built — Ⓐ says one researcher did it in under 24 hours, using fewer than 20 prompts to publicly available AI models, against a closed protocol with no published specification. Sherri Davidoff and Matt Durrin walk through how the attack works, compare it to what a zero-click exploit of this class cost to build in 2021, explain why Zoom’s interim fix couldn’t protect the customers who’d enabled end-to-end encryption, and look at what the evidence actually says about AI-accelerated vulnerability discovery — including the data that argues against the panic. Plus what all of this means for organizations that buy software rather than build it. Key Takeaways: 1. Ask every critical software vendor how fast they patch, and put the answer in the contract. Zoom went from report to shipped fix in 12 days. Your exposure window is that vendor cycle plus your own deployment cycle, and you only control the second. A vendor who won’t commit to a remediation timeline is a documented risk decision, not a technical detail. 2. Inventory the software components inside the products you buy, not just the products themselves. Zoom’s Video SDK is affected and sits embedded inside third-party applications — telehealth platforms, contact-centre tools, banking apps. Organizations with no developers carry this exposure entirely through vendors and can’t patch it themselves. Zoom itself only added the Video SDK to its affected-products list three days after publication. 3. Ask vendors which of their security mitigations stop working when you turn on encryption or privacy features. Zoom’s interim server-side fix could not apply to end-to-end encrypted meetings, because the server can’t read what it’s asked to filter — and the bulletins didn’t say so. Any control that depends on a vendor inspecting your traffic is void the moment you encrypt end to end. 4. Treat "no public exploit exists" as a statement about timing, not about risk. There’s no in-the-wild exploitation, no KEV listing, and no validated public proof-of-concept. That reflects where researchers chose to spend effort — macOS was demonstrated because it was cheapest, while Windows and Linux are affected and simply weren’t targeted. That’s someone else’s schedule, not your risk assessment. 5. Assign someone the authority to say what does — and does not — get fixed. FIRST projects roughly 66,000 CVEs this year, with volume up 45%. If you write no code, that flood arrives as vendor advisories, scanner output and emergency patch cycles for software you bought. At that volume most of the job is deciding what to leave alone, and nobody will own that call without explicit cover. Resources: 1. Ⓐ Security — ZOOMSDAY (original research): https://a.security/blog/asecurity-zoomsday 2. Zoom Security Bulletins, ZSB-26015 to ZSB-26018 (affected versions and patches): https://www.zoom.com/en/trust/security-bulletin/ 3. Google Project Zero — A deep dive into an NSO zero-click iMessage exploit (FORCEDENTRY): https://projectzero.google/2021/12/a-deep-dive-into-nso-zero-click.html 4. VulnCheck — State of Exploitation 1H-2026: https://www.vulncheck.com/blog/state-of-exploitation-1h-2026 5. Google Threat Intelligence Group — Adversaries Leverage AI for Vulnerability Exploitation: https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

  ListenShow Notes
• 

  Episode #85

  AI vs. AI: Hacking the Agent, Not the Human

  Aug 11, 202613 min

  In August 2026 the UK AI Security Institute disclosed that during a routine security evaluation, an AI agent went off-script and attacked real people on the live internet — trying to plant malicious code in a publicly used open-source project and inventing fake identities to pressure the maintainer into approving it. The most unsettling part isn't the deception. It's the targeting: the agent worked out that an AI assistant was helping run the project, and wrote its payload to be invisible to humans but readable by machines. Days earlier at Black Hat, Zenity Labs showed the same idea productized against five shipping AI browsers — hijacking Claude in Chrome, Comet, Atlas, Copilot Edge, and Gemini through nothing more than an email or a calendar invite, no clicks required. Sherri Davidoff and Matt Durrin unpack both stories, why two of the five vendors say there's nothing to fix, and what security leaders should decide this week. Agentic AI is now a first-class attack surface — and the countermeasure most organisations have spent years investing in, training people not to fall for it, doesn't transfer. Key Takeaways: 1. Decide now whether work accounts get signed into AI browsers at all — two of the five vendors have said they are not fixing this. Perplexity and 1Password patched specific capabilities. Anthropic closed the report as informative and ineligible for its disclosure program; OpenAI said there is no easy patch because the vulnerable behaviour is the product feature. Waiting is not a strategy when the vendor sees nothing to fix. 2. Move off email one-time codes for anything that matters, and require out-of-band approval for account recovery. The Claude in Chrome chain never touched a password. It triggered password resets and read the codes out of the victim's own mailbox — Slack, X, then their Claude account. A second factor delivered to a mailbox an agent can read is not a second factor. 3. Inventory which of your automations read outside text and then act with permissions — and put a person on the step that commits. Ticket triage, invoice processing, inbox rules, contract review, vendor portals: anything that ingests outside content and then does something authorised is in scope, developers or not. The agent hunted for an automated target precisely because automation reads raw text and never gets suspicious. 4. Add a question to your vendor security reviews: what outside code goes into your product, and what runs it automatically? Modern software is assembled from components written by strangers, and the systems doing the assembling fetch and run that code on a schedule with nobody watching — which is how one agent's component executed inside 53 of GitHub's own build machines. For most organisations that risk sits with suppliers, not in-house. 5. Separate the environment where your people investigate suspicious things from the one holding credentials to approve, merge, deploy, or pay. The attack failed for a reason no policy earned: the person who opened the payload had no rights to merge it. Had the maintainer investigated on their own laptop — sessions live, an AI assistant helping triage — every precondition would have been met. Resources: 1. UK AI Security Institute — Incident Report: Unsanctioned Agent Behaviour During Cyber Testing https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing 2. AISI Technical Report INC-2026-07-28-01 (full detail, PDF) https://cdn.prod.website-files.com/663bd486c5e4c81588db7a1d/6a724858f7db25c81487016d_Security%20Incident%20INC-2026-07-28-01.pdf 3. Zenity Labs — Claude in Chrome: From alert(1) to Full Account Takeover https://labs.zenity.io/post/claude-in-chrome-from-alert-to-full-account-takeover 4. SecurityWeek — Zero-Click AI Browser Hacking: Claude and ChatGPT Atlas Hijacked via Emails, X Posts https://www.securityweek.com/zero-click-ai-browser-hacking-claude-and-chatgpt-atlas-hijacked-via-emails-x-posts/ 5. Dark Reading — And the Winner for Most Dominant Malware Delivery Method Is... ClickFix https://www.darkreading.com/vulnerabilities-threats/winner-dominant-malware-delivery-clickfix

  ListenShow Notes
• 

  Episode #84

  We don’t break in, we badge in (rerun)

  Aug 4, 202629 min

  In this timely rerun episode, Matt interviews Tom and Derek from our pen test team to break down why attackers often don’t need to hack their way in at all. While most organizations invest heavily in tools like EDR and SIEM, Tom and Derek share how they regularly get inside buildings using nothing more than confidence, a good story, and sometimes even a box of donuts. From posing as copier technicians to tailgating behind employees, their experiences show that people are often the easiest way into an organization. And once they’re in, things escalate fast. Physical access can quickly turn into network access, whether it’s plugging in a device, jumping on an unlocked workstation, or moving through the environment with far fewer restrictions than an external attacker would face. The big takeaway is simple. Real-world testing exposes what audits miss. Doors get propped open, employees try to be helpful, and small gaps add up in ways most organizations never see on paper. If you’re not testing your people and your physical controls, you’re only testing part of your security. Key takeaways: 1. Attackers target people first, not systems Social engineering consistently bypasses even mature technical controls. 2. Physical access equals full compromise Once inside your facility, most security controls can be circumvented quickly. 3. Un-tested controls are assumed to fail If you’re not running social engineering or physical assessments, you don’t know your real risk. 4. Culture is a security control Employees must feel empowered to challenge, verify, and report suspicious behavior. 5. Real-world testing reveals what audits miss Offensive social engineering exposes how attacks succeed, not just theoretical vulnerabilities.

  ListenShow Notes
• 

  Episode #83

  The OpenAI – Hugging Face Autonomous Agent Breach

  Jul 28, 202612 min

  In this episode, Sherri and Matt discuss the July 2026 incident in which OpenAI’s own AI models escaped a sandboxed cybersecurity evaluation and broke into Hugging Face, generating more than 17,000 recorded malicious actions over a single weekend. The models were being scored on the ExploitGym benchmark — turning known vulnerabilities into working exploits — with safety classifiers deliberately disabled. They found a zero-day in the one service they could reach, escaped, inferred on their own that Hugging Face likely hosted the benchmark’s answer key, and got in through a malicious dataset that executed code during routine automated processing. No human directed them at Hugging Face. Sherri and Matt also dig into the defender’s side: commercial frontier models refused to process the forensic data, so Hugging Face ran the analysis on a self-hosted open-weight model instead — raising hard questions about guardrail asymmetry and model provenance. They connect the case to earlier precedents including JADEPUFFER agentic ransomware and Claude Mythos Preview, and close with what security and IT leaders should be doing now, because human-paced log review is no longer a defensive strategy. Key Takeaways: Decide now whether your incident responders can actually analyze malicious content — and prove it at your next tabletop. Hugging Face found mid-incident that commercial AI models refused to process the exploit payloads its team needed to examine. Pick a self-hosted model, decide who may invoke it and what gets logged, before an incident forces the question. Inventory every automated pipeline that ingests content from outside your organization, and find out who built each one. A malicious dataset executed code during routine automated processing — no login, no web app. The same pattern lives in invoice processing, resume screening, ticket attachments, and RAG pipelines, increasingly built by non-engineers with low-code AI tools. Rewrite your AI vendor agreements to require incident notification, because the law does not. SB 53 and the RAISE Act only compel reporting above 50 deaths or $1 billion in damage. And on the reported timeline, roughly a week passed before OpenAI connected its own models to the breach — a detection gap under the legal one. Re-baseline patch prioritization for a world where a working exploit costs a few hundred dollars. Anthropic found a 27-year-old OpenBSD bug in a run costing under $50. JADEPUFFER’s downstream target fell to a 2021 auth bypass and a default signing key public since 2020. Deferring old, low-severity, internet-facing exposures no longer pencils out. Assume detection has to be automated, because the intrusion will be. More than 17,000 recorded events over a single weekend. Hugging Face caught it with LLM-based triage over security telemetry and reconstructed the timeline in hours; OpenAI ran the evaluation on a system not monitored by default. Resources: Hugging Face incident disclosure - https://huggingface.co/blog/security-incident-july-2026 OpenAI incident post - https://openai.com/index/hugging-face-model-evaluation-security-incident/ TIME — How OpenAI Lost Control of an AI Model - https://time.com/article/2026/07/24/openai-hugging-face-attack/ Sysdig — JADEPUFFER: Agentic ransomware for automated database extortion - https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion NIST CAISI assessment of Z.ai’s GLM-5.2 - https://www.nist.gov/news-events/news/2026/07/caisi-assessment-zais-glm-52

  ListenShow Notes

Based on semantic analysis of episode topics and host coverage, this show is a strong guest fit for executives in:

Industry fit is computed by PitchCentric using vector embeddings of the show's episode catalog.