Scheduled tasks are one of the most overlooked real estate in any enterprise environment — and that obscurity is precisely what makes them attractive to attackers. This episode of Cybersecurity examines how threat actors abuse task schedulers to plant persistent footholds that survive reboots, password resets, and even closed incident tickets, all while blending in with the everyday automation every organization relies on. The discussion is grounded in this eight-minute deep dive on covert persistence via scheduled task abuse, and translates it into actionable guidance defenders can apply right away.

The episode walks through the full arc of the problem — from why schedulers are structurally easy to exploit, to the specific habits and controls that raise the cost of hiding inside them. Key topics covered include:

• Why covert persistence is different: The distinction between simply surviving a reboot and actively disguising that survival inside normal operations — and why scheduled tasks are nearly purpose-built for the latter.
• How attackers stay invisible: The playbook relies on mimicking existing task names, borrowing the tone of official tooling, timing execution during off-hours, and keeping payloads minimal so dashboards stay quiet.
• Baseline and inventory as a first line of defense: Treating every scheduled task like an asset — with a known owner, a business justification, and a version-controlled record — so that anything unaccounted for is a finding, not a curiosity.
• Hardening the scheduler infrastructure: Applying least-privilege service accounts, protecting task binary directories, enforcing script signing, and ensuring detailed task history is forwarded to logs that analysts actually review.
• Monitoring signals that cut through noise: What to watch for — interpreters launched from unusual paths, tasks created after odd-hours privileged logins, spikes in scheduler errors, and behavior changes with no associated change record.
• Tuning alerts to avoid fatigue: Why alert volume is a design problem, not a staffing problem, and how requiring justification fields and weighted context at creation time makes triage faster and more accurate.

The episode closes with a practical incident response framework for when abuse is suspected despite strong controls: enumerating and diffing tasks fleet-wide, preserving evidence before remediation, rotating affected credentials, hunting for adjacent persistence, and — critically — documenting whatever gap allowed the task to blend in so that condition gets fixed, not just the symptom. For more on how attackers exploit trusted network behaviors to stay hidden, check out the episode Covert Channels: How Hackers Hide in Your Everyday Network Traffic.

SEC

When every firewall rule shows green and no alerts are firing, an attacker could still be quietly draining your network — one DNS query at a time. This episode of Cybersecurity examines covert channels: the technique of weaponizing trusted, everyday protocols to smuggle data and commands past security controls that were never designed to look twice at them. Drawing on this deep-dive on covert channels in legitimate protocols, the episode walks through why these attacks are so difficult to catch and what defenders can realistically do to surface them.

Here's what the episode covers:

• Why legitimate protocols are ideal hiding spots — DNS, ICMP, and HTTP are pervasive, plausible at any hour, and typically waved through by firewalls that only check whether a packet is syntactically valid, not what it's actually carrying.
• DNS tunneling in depth — how attackers base64-encode stolen data into subdomain labels, route it through port 53 to an attacker-controlled name server, and run a full bidirectional command-and-control channel entirely within normal-looking DNS traffic.
• ICMP and beyond — embedding encrypted C2 instructions inside ICMP echo request payloads, and how the same covert-channel logic extends to HTTP POST bodies, WebSocket frames, cloud storage APIs, VoIP packet slack space, and more.
• The emerging blind spot of DoH and DoT — how DNS over HTTPS and DNS over TLS, introduced to protect user privacy, inadvertently defeat traditional DNS monitoring and give tunneling traffic a nearly invisible path out of the network.
• A layered detection framework — building per-host baselines for DNS and ICMP volume, applying deep packet inspection for payload entropy, routing all internal DNS through logged resolvers, correlating network anomalies with endpoint process telemetry, and enforcing Zero Trust egress segmentation.
• Operational hardening — extending log retention beyond 30 days to catch slow-drip exfiltration, tuning SIEMs for high-entropy domain labels, and running purple-team exercises that specifically test DNS and ICMP tunneling detection.

The central takeaway is that covert channels are not undetectable — they leave fingerprints in query volume, payload entropy, and timing regularity. The gap between "undetected for months" and "caught in hours" usually comes down to whether defenders have built the visibility infrastructure to see those fingerprints in the first place. For more on securing the infrastructure attackers love to abuse, check out the episode on Container Security: Hardening Kubernetes and Docker Environments.

SEC

Container adoption has outpaced container security at organizations of every size. Kubernetes and Docker power modern software delivery, but their default configurations were built for ease of use — not for defense. This episode of Cybersecurity draws on the five-minute deep dive on hardening container environments published by SEC to walk through the most consequential security gaps teams are leaving open, and exactly what to do about them.

The episode covers the full threat surface of containerized infrastructure, from initial configuration through runtime monitoring:

• Dangerous defaults: Out-of-the-box Kubernetes and Docker settings — permissive RBAC, open networking, unrestricted API access — are well-known attack vectors that threat actors actively scan for and exploit at scale.
• The root container problem: Running containers with root privileges creates a path from a single compromised container to the underlying host and beyond; the principle of least privilege, applied consistently, limits the blast radius.
• Network policy enforcement: By default, any pod can reach any other pod in a Kubernetes cluster — a lateral movement dream for attackers. Kubernetes Network Policies enable granular, deliberate segmentation that turns a cluster-wide compromise into a significantly harder attack.
• Locking down APIs: The Kubernetes API server and Docker daemon are master control planes; exposed without strong authentication and firewall restrictions, they hand attackers the ability to create, destroy, and pivot across an entire environment.
• Supply chain vigilance: Pulling unverified images from public registries is trusting strangers with infrastructure access — image signing, vetted registries, and continuous vulnerability scanning with tools like Clair or Trivy are the baseline, not a bonus.
• Runtime monitoring and secrets hygiene: Build-time and deploy-time controls go dark the moment containers are running; tools like Falco catch behavioral anomalies in real time, while proper secrets management — not hardcoded credentials or base64 encoding — keeps sensitive data from becoming low-hanging fruit.

The episode makes a point that cuts through the complexity: container security is not a one-time checklist completed at deployment. It is a continuous discipline that spans configuration, access control, network design, supply chain, runtime behavior, and secrets management. Teams that treat containerization as a security-neutral infrastructure decision are, statistically, the ones issuing breach notifications. The controls covered here are well-understood and entirely achievable — they simply require intention. For more on what happens when container defenses fail, listen to Container Escape via Kernel Modules: Real Exploits, Real Risk.

SEC

Serverless computing promises less operational overhead, faster deployment, and infinite scalability — but it doesn't promise security. The shared responsibility model means cloud providers manage the infrastructure, while everything above that line remains squarely in your hands. This episode of Cybersecurity unpacks the specific threats that emerge in serverless environments and what engineering and security teams need to do differently to stay ahead of them. The discussion draws from this in-depth guide on cloud-native serverless security best practices published by the team at SEC.

Here's what the episode covers:

• IAM misconfigurations as a top breach vector — Why overpermissioned function roles are so common, how the pressure of fast product launches creates dangerous shortcuts, and how tools like AWS IAM Access Analyzer can surface problems before attackers do.
• API Gateway hardening — The case for enforcing authentication and authorization through established standards like OAuth and JSON Web Tokens rather than rolling custom solutions, and why rate limiting belongs in every serverless deployment from day one.
• Securing the code itself — How insecure coding practices reach production not through carelessness but through deadline pressure, and why static analysis, code reviews, and runtime protections need to be automated into the pipeline rather than scheduled as afterthoughts.
• Supply chain risk and dependency scanning — The reality that every third-party library or package imported into a function is an uninspected link in a chain of custody, and how tools like Snyk and AWS CodeGuru can flag known vulnerabilities before they become two-in-the-morning incidents.
• Data security and storage misconfiguration — Why cloud storage defaults to public access far too often, how misconfigured buckets have driven some of the most embarrassing data breaches in recent memory, and why encryption at rest and in transit should be a baseline rather than an optional hardening step.
• Visibility, cold starts, and runtime monitoring — How the dormancy cycles unique to serverless functions create aging dependencies and abandoned-but-reachable deployments, why logging is only useful when someone — or something automated — is actually watching, and how real-time monitoring closes the dwell-time gap before damage compounds.

The episode closes with a broader mindset argument: serverless doesn't reduce your security obligations, it transforms them. Organizations that treat serverless security as a future problem tend to discover it's a present one when it's already too late. For more on securing cloud runtime environments, check out the related episode Cloud Egress Control: Policy-as-Code for Secure Runtime Traffic.

SEC

Container security is often treated as a solved problem — namespaces, cgroups, and image hardening give teams confidence that workloads are properly isolated. But that confidence has a critical blind spot: every container on a host shares the same kernel. This episode of Cybersecurity examines one of the most dangerous exploitation paths in modern infrastructure — container escape via kernel modules — drawing on this in-depth breakdown of real-world container escape exploits and risks from the SEC research team.

The episode walks through the full attack chain — from initial foothold to full host compromise — and explores the misconfigurations that make it possible. Here's what's covered:

• Why containers aren't virtual machines: Unlike VMs, containers share the host kernel, meaning kernel-level access is never truly off the table for a determined attacker.
• What kernel modules are and why they're dangerous: Modules run at the deepest privilege level of the system — if an attacker loads a malicious one, they effectively own the host, not just the container.
• How the attack chain unfolds: From exploiting a vulnerable application inside a container, through privilege escalation (often aided by containers running as root), to abusing the CAP_SYS_MODULE capability to load a hostile kernel module.
• Why detection is so difficult: Malicious kernel-level code runs beneath standard monitoring tools and can disable audit logging, hide processes, and intercept system calls before any alert fires.
• The four conditions attackers depend on: Containers running as root, overly permissive Linux capabilities, absent or misconfigured mandatory access controls (SELinux/AppArmor), and unpatched kernels with known CVEs.
• Practical defenses that actually reduce the attack surface: Enforcing least privilege, stripping CAP_SYS_MODULE from production containers, disabling dynamic module loading at the host level, patching kernels with the same urgency as application dependencies, and investing in sub-user-space monitoring.

The episode closes with a reminder that none of these defenses are exotic — they're foundational practices. The gap between a secure container environment and a compromised one is often a handful of configuration decisions made for convenience rather than security. For more from the show on related cloud infrastructure risk, listen to Cloud Misconfigurations: Why They're Still the #1 Cause of Breaches.

SEC

Despite years of cloud adoption and a booming security tooling market, misconfigured cloud environments continue to top the list of breach root causes. This episode of Cybersecurity examines why organizations — from scrappy startups to enterprise giants — keep falling into the same traps, drawing on the six-minute deep dive on cloud misconfigurations and how to prevent them published by SEC. The conversation moves beyond the headlines to explore the structural, human, and operational forces that make this problem so stubbornly persistent.

Here's what the episode covers:

• Complexity as the root cause — Modern multi-cloud stacks (AWS, Azure, GCP, Kubernetes, serverless, SaaS) create webs of interdependencies that are nearly impossible to govern without serious automation.
• Human error under pressure — Most misconfigurations aren't signs of incompetence; they're the predictable result of engineers working fast in environments too complex to hold in one's head, from overly broad IAM policies granted "just for now" to SSH ports left open after a late-night debug session.
• The three recurring offenders — Overly permissive IAM roles, publicly accessible storage buckets, and forgotten ghost infrastructure (old dev clusters, zombie CI/CD resources) each get their own breakdown, including the mechanics of how attackers exploit them.
• Real-world breach anatomy — The 2019 Capital One incident illustrates how a routine SSRF vulnerability becomes a nine-figure data loss event the moment it collides with an overprivileged IAM role — and the still-growing catalog of exposed Elasticsearch databases drives home that the same playbook repeats at scale.
• Policy-as-code and CI/CD enforcement — Treating security configuration as version-controlled, reviewable code (via Terraform, CloudFormation, and Open Policy Agent) lets teams catch regressions before they reach production rather than months into an incident response.
• Continuous scanning and secrets hygiene — Tools like Prowler, ScoutSuite, and Checkov shrink the window between "misconfiguration exists" and "team knows about it," while dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) close the embarrassingly common gap of hardcoded credentials in source repos and Slack channels.

The episode closes with a reframe that cuts through the noise: in complex cloud environments, some misconfiguration is inevitable. The organizations that stay out of the breach headlines aren't the ones chasing perfection — they're the ones who've built systems designed around human fallibility, automating detection and enforcement so that no single mistake becomes a catastrophe. For more on related cloud security controls, check out the episode on Cloud Egress Control: Policy-as-Code for Secure Runtime Traffic.

SEC.co

Outbound traffic from cloud workloads is noisy, fast-moving, and easy to overlook — right up until a breach makes it impossible to ignore. This episode of Cybersecurity takes a practical look at cloud egress control, examining why the gap between "we have a firewall" and "we have meaningful outbound control" is where so many security programs fall short. Drawing from the cloud egress control best practices article on SEC.co, the episode walks through a modern, policy-as-code approach to governing runtime traffic without grinding development teams to a halt.

Here's what the episode covers:

• Why cloud runtimes are naturally chatty — container pulls, third-party API calls, and dynamic scaling all create outbound connections that can become exfiltration lanes or compliance liabilities.
• The three common traps in egress policy design: IP-anchored rules that rot quickly, over-centralized enforcement that creates delivery bottlenecks, and policies too opaque for engineers to maintain.
• Policy-as-code as a tool for encoding intent — not just machine-readable rules, but explicit documentation of which workload can reach which destination, under what conditions, and for what business reason.
• Workload identity over IP addresses as the primary key for egress authorization, so policies follow workloads through scaling and node migration rather than breaking on reassigned IPs.
• Structured exception workflows that give developers a legitimate on-ramp — time-scoped, approval-gated, and automatically expiring — to prevent shadow networking from quietly accumulating.
• Operational practices that hold up in production: segmenting policy by runtime context, unifying DNS, TLS, and routing enforcement, distributing application-layer policy ownership while centralizing observability, and measuring outcomes like egress gateway coverage and wildcard reduction rather than raw rule counts.

The episode also makes the case for treating egress gateways as products — with real owners, published contracts, and SLOs — and for making every policy decision explainable to developers and auditors alike. For more on the threat side of outbound data movement, listen to the episode Cloud Data Exfiltration: How Attackers Bypass Traditional Defenses.

SEC

Cloud security in 2025 looks nothing like the threat models most organizations were built to handle. This episode of Cybersecurity digs into the mechanics of modern cloud data exfiltration — drawing on this seven-minute deep-dive on cloud exfiltration tactics and defenses — to explain why attackers are so consistently succeeding against organizations that believe their perimeter controls still matter.

The central argument is uncomfortable but hard to refute: in the majority of cloud breaches today, there is no dramatic intrusion. Attackers authenticate with stolen or abused credentials and operate from within the same trusted access paths your employees use every day. The episode walks through the specific techniques, misconfaced architectures, and blind spots that make this possible:

• Credential abuse and session hijacking — Phishing, exposed tokens in public repositories, and credential stuffing give attackers legitimate-looking access that most controls are never designed to question.
• OAuth token persistence — Refresh tokens that outlive their intended lifespan allow adversaries to maintain silent, long-term footholds inside cloud environments without triggering reauthentication.
• API sprawl and SIEM blind spots — Overpermissioned, poorly validated APIs generate volumes of activity that most SIEMs only partially log, handing attackers wide-open operating space.
• Exfiltration over trusted services — Data isn't leaving via suspicious IP addresses; it's moving to Google Drive, Dropbox, and S3 buckets, traffic that pattern-based DLP tools routinely miss entirely.
• Serverless and Kubernetes risks — Ephemeral compute environments leave little forensic trace, while misconfigured Kubernetes clusters — exposed dashboards, over-permissive service accounts — routinely hand attackers cluster-wide access.
• Shadow IT and misconfiguration — Unsanctioned tools and forgotten storage buckets create invisible infrastructure that security teams cannot monitor and attackers actively exploit.

The episode closes with a practical framing of what actually helps: Zero Trust implemented as a genuine operating philosophy rather than a product purchase, cloud-native tooling capable of behavioral baselining and runtime analysis, and continuous verification of every access request regardless of whether it originates inside or outside the network. Legacy on-premises security solutions retooled for cloud workloads are not a substitute — the visibility gap they leave is precisely where modern exfiltration happens.

For more from the show, check out the episode on CI/CD Pipeline Hijacking: How Attackers Strike and How to Stop Them.

SEC