AppSec · Brennenstuhl on Security

AppSec in the Age of Agentic Engineering

Fri, 03 Jul 2026 00:00:00 +0200

Guest lecture by Jan Brennenstuhl for the cybersecurity course at Hochschule für Technik und Wirtschaft Berlin (HTW), summer term 2026.

Materials #

Reading companion #

Coding agents write a growing share of production code, so security feedback that arrives after the code exists cannot keep up. The lecture argues that AppSec teams get the most leverage from the harness the agent runs in: the rules, tools, sandboxes and credentials around the model, not the model itself. Three practices follow: deliver security findings while the task is still in the agent’s context, run agent tasks in disposable sandboxes with short-lived task-scoped credentials, and measure risk per change instead of per release.

This is a short reading companion, not a transcript. The supporting essay is the condensed lecture with context and references in accessible HTML.

Guest Lecture at HTW Berlin: AppSec in the Age of Agentic Engineering

Fri, 03 Jul 2026 00:00:00 +0200

I recently gave a guest lecture to the cybersecurity course at Hochschule für Technik und Wirtschaft Berlin (HTW). The topic was application security (AppSec) in the age of agentic engineering, and how coding agents change the daily work of developers and AppSec teams.

My central argument: AppSec teams have to move from finding problems after code is written to shaping the systems that coding agents write code inside. Agentic engineering makes weak defaults, slow handoffs, and local exceptions more expensive, so the biggest wins now come from the harness, the platform, and the risk model.

The full slide deck contains the key points, examples, and references from the session. Below is a condensed version of the lecture with some additional context and links.

Fixing Findings Is the New Bottleneck #

The adoption numbers make this hard to dismiss. Google’s New SDLC whitepaper estimates that as of early 2026, 85% of professional developers use AI coding agents regularly, 51% use them daily, and roughly 41% of new code is AI-generated. Addy Osmani, one of the authors, wrote a readable summary if you don’t want to read the whole paper.

Coding agents don’t write one function and wait for review. They write, test, read the failures, rewrite, and verify, often several times per hour. Security scanners can keep up with that loop. The old queue of triage, ticketing, and human remediation can’t. At that speed, an AppSec team has plenty of findings and lacks a fast way to turn them into fixes.

The way to close that gap is to return security feedback while the agent still holds the task in its context, so it can repair the problem in the same session. I’d reserve tickets for 2 cases: the in-session loop failed, or new findings surface in artifacts that are already deployed.

Remediation also changes shape at fleet scale. Instead of hunting down individual findings, the AppSec team designs the fix for a whole vulnerability class, and agents apply it to every affected service. I describe this model in more detail in AppSec in the Age of Agentic Engineering.

The Harness Is the Control Plane #

The whitepaper offers a useful mental model: an agent is a model plus a harness. The harness is everything around the model: instructions and rule files, tools and Model Context Protocol (MCP) servers, guardrails, sandboxes, orchestration, and observability. The authors estimate the split at roughly 10% model and 90% harness. Osmani gives a public example in his summary: on Terminal Bench 2.0, 1 team moved a coding agent from outside the top 30 into the top 5 by changing only the harness and keeping the same model underneath.

The harness is also where an AppSec team has the most control. A stronger model helps, but it won’t fix unsafe access defaults, missing tests, or an insecure tool configuration on its own. So I’d ship security skills, local scanning, and review feedback into the harness, where agents can check and improve their own work before a pull request exists.

Shift Security Down into the Platform #

Shift-left still catches mistakes early, but it doesn’t remove the security decisions that every team and every agent has to make. At agent speed, each local workaround becomes a reusable pattern, and architectural drift compounds across the fleet.

That’s why I argued for shift-down security. Instead of asking whether a team implemented authentication correctly, ask why the team needs to implement authentication at all. A mature platform makes that question unnecessary: it exposes APIs with authentication built in, gives workloads scoped identity, and offers a deployment path that is secure by default.

Hardened base images, service templates, platform-owned delivery pipelines, and workload identity remove whole categories of errors and make the secure path the easy path. In my experience, agents follow it. These constraints move undifferentiated choices into a maintained platform, and teams keep the engineering decisions that make their product different. Shift Down: Why Agentic Engineering Demands Platform-Level Security explains this platform role in more detail.

Give Risk an Operational Budget #

Agentic engineering also needs security decisions that work at machine speed. Blocking every finding doesn’t scale, and neither does ignoring them. I suggested borrowing the error-budget model from site reliability engineering (SRE) and applying it to security exposure.

A risk budget caps how long a high-risk, reachable vulnerability may stay in production. Reachability analysis turns raw findings into business exposure: a known vulnerability (CVE) in dead code doesn’t consume the same budget as the same CVE behind a public API. The budget gives people and agents a clear decision rule: fix what burns the budget, defer what doesn’t.

Security then becomes a shared operating concern with an accountable number attached. Instead of an impossible demand (fix every finding), the team decides on an exposure window and defends it.

The Coding Agent Is an Attack Surface #

The agent itself belongs in the threat model. Each task is an untrusted workload: it executes arbitrary code and reads dependency metadata, issue descriptions, pull-request comments, and documentation. That creates a large internal code-execution surface and exposes the agent to prompt injection and excessive agency.

A warning in a rule file won’t protect against that. Run agent tasks in disposable cages, such as nono OS-level sandboxes or Firecracker microVMs, and issue short-lived, task-scoped credentials through an identity broker. Persistent roles and long-lived API keys don’t belong in an agent context.

What I Asked the Students to Learn #

I closed the session with direct advice: learn software engineering deeply, and learn to think in platforms. Get comfortable with distributed systems, identity and access management (IAM), observability, infrastructure as code, and the economics of risk.

Agentic engineering makes AppSec more structural and more software-heavy. The next generation of AppSec engineers will still understand attacks and secure coding, but their biggest impact will come from building paved roads (maintained, secure defaults that teams use without asking), hardening harnesses, and designing systems where insecure choices are rare.

Shift Down: Why Agentic Engineering Demands Platform-Level Security

Sun, 14 Jun 2026 00:00:00 +0200

An organization with 500 engineering teams rarely has a single way to build, deploy, and operate services. It has a preferred path, a few tolerated exceptions, and a long tail of custom setups. Over time, local optimizations pile up on top of historical accidents. Now give every engineer multiple coding agents that produce code at machine speed. The inconsistency does not grow linearly. It compounds.

This is the core tension of agentic engineering for AppSec: Agents amplify whatever patterns exist. Good patterns scale. Bad patterns scale faster. The response most organizations reach for is shift-left: More scanning, earlier detection, faster feedback loops. That helps. But it treats symptoms. The structural answer is shift-down: Embedding security into the platform layer so that insecure choices become difficult or impossible, rather than merely detectable.

Shift-Left Distributes Responsibility. Shift-Down Removes Decisions. #

Shift-left answered the question: Who should own security? The answer was everyone. Development teams run their own SAST, manage their own dependencies, configure their own infrastructure. The intent was sound. The result, in many organizations, was that hundreds of teams now make thousands of security-relevant decisions independently, with varying expertise and attention.

Shift-down asks a different question: Which security decisions should exist at all? Instead of teaching every team to build a secure CI/CD pipeline, the platform ships one standard pipeline that verifies, tests, scans, signs, and deploys by default. Instead of auditing IAM policies across services, the platform binds short-lived credentials to Kubernetes workloads automatically. Instead of reviewing pod security settings and container hardening across the fleet, a platform-owned WebService resource deploys on a managed base image with secure defaults.

The Kubernetes Security SIG formalized this distinction in their shift-down security paper: Security outcomes improve when platforms absorb complexity that individual teams previously handled alone. The two approaches are complementary. Shift-left catches what slips through. Shift-down reduces what can slip through in the first place.

Agentic Engineering Makes This Urgent #

Human engineers introduce inconsistency slowly. A team picks a non-standard auth library. Another team forks a deployment template. Over months, drift accumulates. Organizations notice, create governance processes, schedule remediation campaigns.

Coding agents reproduce inconsistency at machine speed. Every non-standard pattern in the codebase becomes context for generation. Every local workaround becomes a template. Every exception becomes infinitely scalable. The risk is not that agents produce insecure code in isolation. It is that they rapidly multiply architectural entropy across the fleet.

Shift-left tooling (scanners, gates, review agents) catches individual instances after they appear. That was viable when inconsistency grew at human speed. At agent speed, the detection-and-remediation loop cannot keep up. You cannot scan your way out of a problem that regenerates faster than you fix it. The leverage is upstream: Make the inconsistency impossible to produce.

Platforms as Security Architecture #

Good platforms are opinionated. They encode architectural preferences and reject alternatives. This is not bureaucracy. It is engineering leverage: Every abstraction that removes a choice also removes an opportunity for mistakes.

Base images, Dockerfiles, CI/CD pipelines, pod security contexts: These are platform concerns, not product concerns. When organizations treat them as team responsibilities, they get 500 variations of the same solved problem, each with its own security gaps. The alternative: Product teams declare what they need, and the platform handles how it runs securely.

Custom platform resources (Kubernetes CRDs, internal service APIs) abstract entire categories of security decisions. A team declares a WebService resource. The platform operator provisions a hardened container from a managed base image, injects mTLS sidecars, attaches scoped credentials via workload identity, configures egress policies, and wires observability. No Dockerfile. No pipeline YAML. No security context to misconfigure.
Managed identity services issue short-lived, scoped credentials automatically. Teams do not configure service accounts or rotate secrets. They annotate their workload, and the platform binds identity at deploy time.
Platform-owned build and delivery pipelines compile, test, scan, verify, sign, and deploy artifacts without team-maintained configuration. Security scanning is not opt-in. It is invisible. Teams push code. The platform does the rest.

Each of these shifts security from “a thing teams do” to “a property teams cannot opt out of”. Agents, which follow the path of least resistance by design, naturally produce code that fits within platform constraints rather than working around them.

AppSec Moves from Enforcement to Architecture #

Traditional AppSec reviews decisions made elsewhere. Shift-down AppSec decides which decisions should exist. Instead of asking “did this team implement authentication correctly?”, the question becomes “why are teams implementing authentication themselves?”

This reframes the operating model:

From policy documents to platform primitives. The 50-page security standard becomes a set of platform defaults, service templates, and policy-as-code rules. Coding agents (usually) do not read PDFs. They consume MCPs, CLIs and constraints.
From reviewing PRs to designing abstractions. The highest-leverage work is not catching a broken IAM policy in review. It is designing the identity service so that broken IAM policies cannot be expressed.
From remediation campaigns to platform upgrades. When security lives in the platform, fixing a vulnerability class means upgrading the platform once instead of patching hundreds of services individually. The fleet inherits the fix.

This does not eliminate the need for detection. Edge cases exist. Custom integrations break assumptions. New vulnerability classes appear. But detection becomes the fallback, not the primary mechanism.

The Paradox: Less Freedom, More Productivity #

Engineers often interpret constraints as a lack of trust. The evidence points the other direction.

Modern cloud engineers have far less infrastructure freedom than system administrators twenty years ago. They cannot choose their hypervisor, their network stack, or their storage firmware. Yet they are dramatically more productive. Few miss managing physical servers. The same applies to security constraints. Every hour spent on container configuration or pipeline maintenance is an hour not spent on the problem the product engineering team exists to solve. Constraints do not limit productivity. They redirect it toward differentiation.

Where This Leaves AppSec Teams #

Earlier this year, I argued that AppSec must become an engineering discipline: building tooling, shipping remediation at scale, treating risk quantitatively. Shift-down refines the target. The tooling AppSec builds is not primarily scanners and gates. It is platform primitives, secure defaults, and opinionated abstractions that make insecure choices structurally difficult.

This requires a different skill set. AppSec engineers become platform engineers who specialize in security properties. They design APIs and MCPs, build service templates, contribute to infrastructure abstractions, and maintain (or support) the paved roads that the rest of engineering (and their agents) follow.

The organizations that will thrive in an agentic world are not those that allow infinite flexibility. They are those that carefully decide where flexibility should exist and where it should not. Shift-left taught us that everyone owns security. Shift-down teaches us that not everything should remain a choice. The future belongs to teams that understand the difference.

Dependency Updates: latest Is Not a Security Strategy

Fri, 15 May 2026 00:00:00 +0200

On March 31, 2026, North Korean state actors compromised Axios, an npm package with over 70 million weekly downloads. Any project declaring axios@^1.14.0 connected to attacker C2 infrastructure the next time npm update ran. Six weeks later, a self-propagating worm hit 42 TanStack packages. It reached Mistral AI, UiPath, and OpenAI within hours. It also carried valid SLSA provenance attestations, signed by the legitimate build pipeline.

The same infrastructure that helps us stay current also amplified these attacks. Automated dependency updates pushed the compromised packages into production builds faster than any human could react.

We learned that outdated dependencies are dangerous. That is true. But many teams have flipped the lesson around. Newer is treated as safer. It is not.

The Trust Problem #

Modern package managers are not static library linkers. They are code execution pipelines. A single npm install can run arbitrary install scripts, read credentials, and run with full CI permissions. It does this across hundreds of transitive packages that nobody on the team has reviewed. Every dependency expands your trusted computing base.

It’s not every dependency you add that’s a problem; it’s every dependency you update.
Ben Hoyt, Every dependency you add is a supply chain attack waiting to happen

Two problems arise here:

Version ranges like ^1.14.0 do not mean “I trust version 1.14.0”. They mean “I trust every future release that matches this constraint”. That is a large, open-ended trust delegation. The Axios attackers used exactly that. Version 1.14.1 was a manifest-only change that added a malicious dependency while leaving the Axios source code untouched. Semantic versioning signals maintainer intent, not trustworthiness. The same applies to floating Docker tags, unpinned GitHub Actions, and latest tags everywhere.
Tools like Dependabot and Renovate normalized constant dependency updates. At scale, they improve visibility and shorten the window for known CVEs. But they also changed how we consume trust. Security automation quietly became trust automation. Dependency update PRs receive less review than internal code, even though they run with the same or higher privilege. The volume is overwhelming and eventually the workflow shrinks to: CI passes → vulnerability score drops → merge. That creates a dangerous illusion. “No known CVEs” does not mean “safe”. Supply-chain attacks are newly published, initially undetected, semantically valid, and technically “up to date”.

False positive alerts are not only a waste of time, they also reduce security by causing alert fatigue and making proper triage impractical.
Filippo Valsorda, Turn Dependabot Off

The XZ Utils backdoor in 2024 showed how long-running social engineering can compromise critical infrastructure. The Mini Shai-Hulud incidents in 2025 and the ongoing supply chain attacks show that the attack surface extends well beyond maintainer compromise. It reaches into version ranges, build pipelines, provenance systems, and the update automation that ties them together. These are not theoretical risks. They are documented, attributed attacks against the most popular packages in the ecosystem.

What Controlled Trust Looks Like #

There is no perfect fix for supply-chain risk. There are practical ways to replace blind trust with controlled trust:

Pin Versions #

Remove ^ and ~ from package.json or whatever dependency manifest you use. Use exact versions. For transitive dependencies, force the version with overrides:

{
 "dependencies": { "axios": "1.14.0" },
 "overrides": { "axios": "1.14.0" }
}

Lockfiles like package-lock.json, pnpm-lock.yaml, Cargo.lock, and poetry.lock do not make dependencies safe. They make dependency state reproducible. You cannot investigate what you cannot reproduce.

Enforce Release-Age Cooldowns #

Supply-chain attacks have a short half-life. The compromised TanStack versions lasted about three hours before someone caught them. A release-age cooldown rejects packages younger than a threshold. That gives the community time to spot compromises before they reach your builds:

# ~/.npmrc
min-release-age=7

# pnpm-workspace.yaml
minimumReleaseAge: 1440

# ~/.bunfig.toml
[install]
minimumReleaseAge = 604800

# ~/.config/uv/uv.toml
exclude-newer = "7 days"

A seven-day cooldown covers 90% or more of recent supply chain incidents. It would have prevented both the Axios and TanStack compromises.

Control Upgrade Cadence #

Filippo Valsorda recommends a better model than auto-updating: Run your test suite against the latest dependency versions daily in a sandboxed CI job. You get early warning of breakage without pulling untrusted code into production. You still update. You do it on your schedule, after review, when you are ready.

Verify Provenance, But Do Not Trust It Alone #

The TanStack attack is the first documented case of malicious npm packages carrying valid SLSA Build Level 3 attestations. Provenance verification is necessary but not sufficient. Pair it for instance with deep package inspection to catch suspicious network calls, filesystem access, and hidden scripts before they run.

Deploy Repository Proxies #

Place package managers behind a properly configured repository proxy like Sonatype Nexus, JFrog Artifactory, or an internal mirror. These proxies should be configured not only to mirror (ideally approved) dependencies, but also quarantine suspicious releases and scan for known malware. But keep in mind that most scanners only detect known threats. Sophisticated attacks are novel by design. Proxy scanning is one layer, not a replacement for version pinning and controlled upgrades.

Use Reachability-Aware Scanning #

Not every CVE in your dependency tree matters. A vulnerability in a function you never call does not deserve the same urgency as one that is on your hot path. Go’s govulncheck traces your actual call graph and filters out findings in code your application never reaches. Other ecosystems are catching up. At a minimum, make sure your scanner can tell whether a vulnerable package is actually used. The best scanners go further and trace the call graph down to the specific vulnerable function.

Reduce Dependency Surface Area #

A little copying is better than a little dependency.
Go Proverbs

Every package adds code, maintainers, credentials, infrastructure, and trust assumptions. Modern ecosystems normalize absurd dependency depth. Before adding a package, ask: can we write this in 30 lines? If yes, write it. A coding agent can do most of the work for you.

The lesson from 2025 and 2026 supply-chain attacks is not “never update”. Stale dependencies become liabilities too. The lesson is that blind trust does not become safer just because it is automated.

Secure software supply chains are built on controlled trust: Pinned versions. Enforced cooldowns. Verified provenance. Proxy repository managers. Reachability-aware scanning. A small dependency surface. The fastest update is not always the safest. Sometimes the safest thing to do is wait.

Updated on May 17th: Referenced THN report on “the TanStack supply chain attack hitting two OpenAI employee devices” and the “Practical Package Security” guide by Wiz.

AppSec in the Age of Agentic Engineering

Thu, 14 May 2026 00:00:00 +0200

In agentic engineering, engineers hand tasks to coding agents that write code, run it, and fix their own mistakes in fast loops. Bartosz Ocytko recently mapped where agentic engineering is heading, from a surge of commits on GitHub to bottlenecks in verification, open source, and compute. Most security tooling and processes weren’t built for that volume of change. While reading his piece, I kept coming back to 1 question: what does this shift mean for application security (AppSec)?

Ocytko argues that agentic engineering will reward organizations with strong engineering foundations: those that can verify, coordinate, and safely absorb machine-generated change. I think AppSec is part of that foundation. AppSec teams that already build tooling, run large-scale remediation, and treat risk quantitatively are well placed to make agentic engineering safe at scale. Attackers raise the stakes for strong security engineering, too: Google’s Threat Intelligence Group reports that AI models lower the barrier for adversaries to develop exploits. In May 2026, the group reported the first threat actor it believes used a zero-day exploit developed with AI.

The same agents that create the volume can also help with problems that AppSec teams couldn’t solve at human scale: too many findings, too few security engineers, and feedback that arrived long after the code was written. I see 3 shifts that decide which AppSec teams keep up:

From detection to mitigation: prevent findings inside the agent’s loop and fix the backlog at fleet scale.
From writing policies to building tools: ship security tooling into the context that coding agents work in.
From gatekeeping to partnership: manage security risk together with site reliability engineering (SRE), platform, and cloud engineering teams, the way they already manage reliability.

Findings Pile Up Faster Than Teams Fix Them #

Most mature organizations already have good visibility into known vulnerability classes. Their scanners cover infrastructure, cloud platforms, application code, and continuous integration and delivery (CI/CD) pipelines. AI adds even more findings: HackerOne argues that AI-powered vulnerability discovery has improved by an order of magnitude, while remediation hasn’t kept up.

Backlog data shows how far remediation lags behind. Edgescan, a vulnerability management vendor, analyzed its 2024 scanning and penetration testing results in its Vulnerability Statistics Report 2025. At enterprises with more than 1,000 employees, 45.4% of the vulnerabilities discovered within 12 months were still open. High and critical findings with the highest predicted exploit probability (an Exploit Prediction Scoring System score above 0.7) took 115.7 days on average to fix, slightly longer than the 109.4 days for those least likely to be exploited. Every finding that nobody fixes grows the backlog and extends the exposure window, the time during which an attacker can exploit the vulnerability in production.

Coding agents make this worse. They generate code at machine speed, so new findings appear faster. Lars Janssen calls the growing gap between how fast teams generate code and how fast they can check it verification debt. If remediation still depends on engineers picking up tickets between feature work, the backlog keeps growing. Risk only goes down when teams fix findings faster than scanners discover new ones.

That requires AppSec teams to move from “we found it, you fix it” to “we prevent it, and we fix what slips through”.

Move Security Feedback Into the Agent Loop #

In the traditional loop, a scanner reports an issue in the pipeline, someone files a ticket, and an engineer fixes it when there’s time. In the agentic loop, the scan results go straight back to the coding agent, which rewrites the code in the same session until the checks pass. Many findings never reach a ticket because the agent fixes them before anyone commits the code. GitHub’s Copilot Autofix suggests fixes directly in the pull request, which comes close to this loop. During its 2024 public beta, developers fixed new code scanning alerts in pull requests in a median of 28 minutes, compared with 1.5 hours without Autofix.

Today’s security gates weren’t built for this loop. When a coding agent opens a pull request (PR) in seconds, a security gate that takes minutes becomes the slowest step. Binary gates also break down at this volume: “block on medium severity” blocks everything, and “ignore everything below critical” leaves real risks open. The risk budgets I describe further down give teams a better decision rule.

Some findings will still slip through, and most organizations already carry a large backlog. Fixing them 1 ticket at a time doesn’t scale. In campaign-based remediation, AppSec targets a whole vulnerability class at once, such as an outdated dependency, an infrastructure as code (IaC) misconfiguration, or an insecure pattern repeated across hundreds of services.

Spotify’s fleetshift is a good mental model: it makes fleet-wide code changes by running a Docker image against each repository. Spotify reports that fleetshift created more than 270,000 PRs in 2022 and merged 77% of them automatically, and that it patched 80% of its production backend services within 9 hours of the Log4j disclosure.

With coding agents, the AppSec team designs the campaign, and agents open, test, and verify the remediation PRs across the fleet. GitHub already supports part of this: in security campaigns, teams can assign alerts to the Copilot cloud agent, which opens pull requests with fixes.

Build and Ship Security Tooling #

In this model, AppSec engineers build and ship security tooling and contribute remediation code directly. Their goal is infrastructure that makes coding agents produce secure code by default.

Security Skills and Machine-Readable Policy #

Skills are packaged instructions that coding agents load when a task needs them, and they follow an open specification. Project CodeGuard from the Coalition for Secure AI (CoSAI) publishes general security skills for cryptography, input validation, authentication and authorization, and supply chain security. Organization-specific skills go further and encode internal policies (“use the central auth SDK, not raw JWT handling”), approved libraries, and deployment constraints. If the organization distributes skills centrally, AppSec can publish a skill update when a new vulnerability class appears, and every agent in the organization has it the same day.

The security policy itself needs the same treatment, because a coding agent can’t do much with a 50-page PDF. AppSec teams can turn it into agent instructions, a searchable vector database, or policy-as-code rules that agents check while they work. The agent then verifies compliance mid-task without waiting for a human reviewer, and AppSec’s work moves from reviewing individual changes to maintaining the policies and risk models that agents enforce.

Local Scanners and Review Agents #

Security scanning can’t live only in version control platforms and CI pipelines anymore. Coding agents need static application security testing (SAST), dynamic application security testing (DAST), and reviewers based on large language models (LLMs) on the engineer’s machine, so they can check their own output before they push. AppSec teams package these tools as command-line interfaces (CLIs) or Model Context Protocol (MCP) servers and manage their configuration and policies centrally. MCP gives agents a standard way to call tools. Engineering teams then get scanning that works without setup.

Dedicated review agents combine security skills with local tooling. They check code against organization-specific policies and report issues in a form the coding agent can act on directly. roborev points in this direction: it’s a local daemon that reviews each commit in the background through a git hook and reports every finding with a severity and a file and line location before the code reaches a PR.

A shared review ledger ties these checks together. Every source, whether static analyzer, dynamic scanner, or LLM-based reviewer, writes to the same structured log, typically in the Static Analysis Results Interchange Format (SARIF). The coding agent reads the ledger after each iteration and knows which checks passed, which failed, and what to fix next. LLM-based reviewers can catch context-dependent issues that rule-based scanners miss, but they don’t return the same result on every run, so the ledger needs both.

Sandboxes and Short-Lived Credentials #

Coding agents are most useful when they can run the code they write: they implement a change, run the tests, read the failure, and try again. That makes every agent task an untrusted workload running arbitrary code, often on an engineer’s laptop. For AppSec, this adds up to a large internal remote code execution (RCE) surface, and securing it touches workstation setup as well as engineering practice.

Sandboxing and prompt injection defense go together. A coding agent reads external input such as dependency metadata, issue descriptions, PR comments, and documentation, and each of these can carry a prompt injection that tells the agent to do something else. A sandbox limits the damage when that happens, and the common options differ in isolation strength and cost:

Lightweight virtual machines (micro-VMs) such as Firecracker and Docker Sandboxes give each task a disposable environment with its own kernel.
OS-level sandboxes are lighter. nono applies irrevocable, kernel-enforced filesystem allow-lists through Landlock on Linux and Seatbelt on macOS, and Sandvault runs agents as a separate macOS user inside sandbox-exec. The nono authors point out that OS-level sandboxing doesn’t give the memory isolation of a virtual machine.
Containers share the host kernel, so escaping 1 container puts the attacker on the host.

AppSec picks the isolation boundary that fits each workload’s trust level and, together with platform teams, ships the sandbox setup as the default configuration engineers get out of the box.

Credentials need the same care. Coding agents should never hold persistent identity and access management (IAM) roles or long-lived API keys. An identity broker issues short-lived, task-scoped credentials on demand and revokes them when the task completes. AppSec can build the broker together with platform and IAM teams and hide it behind the agent’s tooling, so agents exchange tokens automatically and never fall back on whatever credential is at hand.

Beyond internal credentials, agents increasingly act on behalf of users in third-party services. That needs delegation and consent infrastructure with narrow, time-limited permissions the user can revoke at any moment. Without it, teams end up storing tokens in agent contexts or hard-coding service accounts, and both fail as soon as an attacker compromises an agent or the agent misreads a prompt.

Threat Modeling and Offensive Testing #

Traditional scanners catch known vulnerabilities listed as Common Vulnerabilities and Exposures (CVEs), common misconfigurations, and obvious injection points. They miss logic flaws such as broken access control across multi-step workflows, business logic bypasses, and race conditions. To catch design-level flaws, AppSec teams have to encode their domain knowledge into agents.

Threat modeling, where a team maps how an attacker could abuse a system’s design, usually happens in periodic workshops. Jack Naglieri built threat models with AI agents and MCP and argues that agents remove the weeks of meetings and documentation review that kept threat modeling a once-a-year exercise. Naglieri’s example comes from detection engineering, but the approach carries over to applications. AppSec teams can build agent setups that regularly review applications and repositories, analyze access control patterns, data flow boundaries, and trust assumptions, and report drift from the organization’s security posture.

Agentic penetration testing (pentesting) complements this, and AppSec can offer it to engineering teams as an internal service. These agents explore the application’s business logic and look for the flaws a human pentester would target: authorization boundaries, multi-step attack paths, and privilege escalation. To build them, AppSec teams turn their offensive expertise into repeatable attack strategies. Public setups today still keep a human in the loop. In AI-assisted web pentesting with Claude Code and Burp MCP, for example, the agent suggests the next test and the pentester decides whether to run it.

Partner With SRE and Platform Teams #

Can a system ever truly be considered reliable if it isn’t fundamentally secure? Or can it be considered secure if it’s unreliable?
Building Secure and Reliable Systems

In SRE, the product owner sets a service level objective (SLO) such as 99.9% availability, and the remaining 0.1% becomes the service’s error budget, which the team can spend on outages and risky releases. AppSec can join that model with a risk budget. The risk budget sets how long a high-risk, reachable vulnerability may stay open in production before it burns error budget, just like downtime does. AppSec provides the framework and the tooling, and the product owner sets the target, just as for the SLO.

A risk budget helps with a problem that agentic engineering makes worse. Coding agents generate change faster than people can triage the findings, and without a quantitative target every finding competes for the same attention. With a risk budget, teams fix what burns the budget and defer what doesn’t. The conversation moves from “fix all the bugs” to “manage the exposure window”, and security becomes an operational concern that AppSec shares with the teams running the service.

Teams can only use a risk budget if they can tell real exposure from noise, and that requires reachability analysis: tracing the call graph from the vulnerable code to the application’s entry points. A CVE in dead code doesn’t burn budget, but the same CVE behind a public API does. At the CI gate, teams then block only changes that introduce reachable risk and stop failing builds on raw finding counts. In production, a monitoring layer tracks how long reachable findings stay open and burns error budget accordingly.

Platform and cloud engineering teams already ship the paved roads that engineering teams build on: base images, service templates, IaC modules, identity primitives, and networking defaults. AppSec teams get the most reach by building security into those golden paths. A hardened base image or a secure-by-default service template then carries security to every service that uses it, including the code that agents write. Platform engineering owns the templates and modules, and AppSec owns the security defaults inside them. I cover this model in more detail in Shift Down.

Where to Start #

None of this has to happen at once. A team that wants to start can work through these steps in order:

Sandbox the coding agents that engineers already run, and replace their long-lived credentials with short-lived, task-scoped ones.
Package the existing scanners as CLIs or MCP servers with central configuration, and make them write SARIF.
Publish an organization-specific security skill that encodes the internal policies that matter most.
Pick 1 vulnerability class from the backlog and fix it across the fleet as a campaign.
Agree on a risk budget for reachable vulnerabilities with 1 service owner and their SRE team.

The sandbox comes first because the exposure exists as soon as an engineer runs an agent with access to their machine.

Bunny Shield Review: 3 Things Need Improvement

Sat, 07 Jun 2025 00:00:00 +0200

Bunny.net launched the Bunny Shield Preview earlier this year. It’s an integrated Web Application Firewall (WAF), DDoS mitigation and rate-limiting controls solution all bundled into their Content Delivery Network (CDN) platform. I’ve been testing it on a few real-world projects over the last few weeks to see how ready it is and how easy it is to use.

Spoiler: Bunny Shield is straightforward to use and makes the most of your first experience. It’s a solid start for an accessible WAF, but there are a few key improvements needed to make it a production-ready web security product.

Here’s a quick rundown of the things I noticed and the problems I came across. It’s meant to show what’s working well now and where Bunny.net could improve their security tooling before it leaves the “Preview” stage.

What Bunny Shield Gets Right #

Initial User Experience & Setup Simplicity #

Bunny Shield carries on the tradition of Bunny.net of offering clean and usable interfaces. As always, you only need to do the bare minimum to get things done. It was easy enough to enable the service and set up firewall or rate limit rules. For smaller sites and teams without dedicated security personnel, this kind of usability is invaluable.

Default Security Coverage #

The out-of-the-box rules catalogue seems pretty reasonable to me, catching common threats without overwhelming users with complex tuning. For most users, this makes Bunny Shield a no-brainer for basic web protection.

What Bunny Shield Needs to Improve #

Certificate Renewal Blocked by WAF #

One of the most critical issues I encountered was Bunny Shield blocking HTTP-01 challenges from Let’s Encrypt. This sometimes seems to stop the automatic TLS certificate renewals through Bunny’s own certificate mechanism, which could cause service disruptions if not caught in time.

The good news is that Bunny’s support team have already said they know about the problem and are working on a fix. For now, users relying on HTTP-01 validation (e.g. by using the built-in Bunny CDN certificate management) should proceed with caution or disable the WAF.

No Bot Allowlisting for Good Bots like Ahrefs or Semrush #

Currently, Bunny Shield doesn’t offer any particular bot management solution. This means there’s no way to tell the difference between harmful bots and legit crawlers (like Ahrefs, Semrush, and other SEO tools). I saw this causing these “good bots” to be blocked, which harmed my SEO audits and (potentially) visibility.

It’d be great to add a bot management layer or at least some simple allow listing functionality for expected crawlers. The opposite is also true: I’m sure some people would love to trap rogue or misbehaving AI scraper bots in a maze.

Overall, I’d love to see Bunny hop on board with the HTTP Message Signatures bandwagon that Cloudflare recently kicked off.

Limited Logging and Visibility into WAF Events #

There’s a clear difference between the 403 traffic logs and the WAF event logs. I can see that requests were blocked, but there’s no clear traceability to what specific WAF rule was triggered and why. This makes it tricky to debug false positives or fine-tune firewall behaviour, especially when you’re dealing with a lot of data.

Missing WAF Error Code Lookup Tool #

When Bunny Shield blocks a request, it returns a 403 with a unique deny code (e.g. WAF403-XXXX). Unfortunately, there doesn’t seem to be a lookup tool for these codes at the moment. If we could get a dashboard-integrated lookup, that’d make a big difference to WAF rule debugging.

Final Thoughts: Promising Foundations, But Still in Beta #

All in all, the Bunny Shield Preview is doing really well, especially when it comes to how easy it is to use. It’s accessible, integrated tightly into the Bunny.net platform, and it’s already solving basic security needs for many developers.

That said, there are a few key things that need to be sorted for Bunny Shield to become a great product. For example, observability, bot management and configurability need to be improved.

I’m excited to see how this product develops, and I’ll definitely be keeping an eye on the next updates.

Got Feedback or Similar Experiences? #

Have you had a chance to try out Bunny Shield yet? Did you encounter similar issues? Found any workarounds yet? I’d love to hear about your experience – just send me a message on Bluesky or Mastodon.

Let’s help make Bunny Shield a secure, modern WAF that everyone can use.

What is Whaling Cyber Awareness? Prevention Tips & Training

Tue, 23 May 2023 00:00:00 +0200

Disclaimer: This article involved collaboration with a GenAI tool for personal research. All content was reviewed and edited by myself. Feel free to report inaccuracies. Thanks.

What is Whaling Cyber Awareness? #

Cyber security is an ever-evolving challenge requiring constant attention and effort to stay ahead of the game. One of the most significant threats companies face today is whaling cyber attacks, a social engineering approach targeting high-level executives and other individuals with access to sensitive information. Profound cybersecurity awareness is essential for businesses to protect themselves from these threats.

Whaling cyber awareness refers to the knowledge and skills necessary to identify and prevent whaling cyber attacks, also known as whale phishing. The goal is to educate employees, especially those in leadership positions, on how these attacks work and how they can be prevented. This type of training plays a critical role, especially because whaling emails are often successful due to their sophisticated nature, making them difficult to detect. Whales, or high-profile individuals, are often targeted in these attacks, which can lead to data breaches because of their exposure to relevant information or business processes. It’s important not to confuse whale phishing with ordinary phishing, as the former targets essential individuals.

Security Awareness: Why It Matters #

The challenge with security awareness for whaling is that these phishing attacks are highly targeted and personalized, making them very difficult to spot. Attackers use social engineering tactics such as impersonation or pretexting to trick their victims into divulging sensitive information or transferring funds. Spoofed emails and business email compromise (BEC) are also commonly used to impersonate trusted business contact. Additionally, smishing attacks target mobile devices via text messages. These attacks can cause significant financial losses and damage a company’s reputation.

To combat the threat of cyber attacks such as whaling, businesses must take immediate action and implement a comprehensive whaling awareness program that includes training and education for top-level executives, simulation exercises to prepare for social engineering tactics, continuous monitoring and response capabilities, and building a corporate security culture.

Training and education are essential components of every effective cybersecurity program, especially in the business world, where social engineering attacks are becoming more prevalent. Employees need regular training on how to recognize phishing emails or suspicious requests for information, as well as how to handle sensitive data securely. This is particularly important for top-level executives who may be prime targets for sophisticated social engineering attacks. They should also be taught where to report suspected cases to ensure the safety of the entire organization.

Regular security awareness programs should also include simulation exercises to prepare employees for potential cyber-attacks through social engineering tactics. These allow employees to practice recognizing potential threats in a safe environment without risking real-world consequences. Whaling simulations help reinforce the importance of being vigilant regarding digital communication, phishing, and sharing confidential information.

Continuous monitoring and response capabilities are crucial for businesses to enhance their cyber awareness and detect potential threats, such as phishing attacks or whaling emails, early on before they can cause damage. Companies should have systems like secure email gateways that monitor communications for signs of unusual behavior or suspicious activity.

Building a security-minded corporate culture involves creating an environment where cybersecurity is ubiquitous and a top priority. This means promoting a culture of awareness and responsibility, where employees understand the importance of cybersecurity and take an active role in protecting company assets.

Technologies and Strategies for Whaling Prevention #

Defensive Technologies: Anti-Spoofing, Secure Email Gateways, and AI-based Solutions #

Whaling emails are becoming more sophisticated, and organizations must employ defensive technologies to protect themselves. Anti-spoofing techniques such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) can prevent email spoofing. SPF validates the sending server’s IP address against the domain’s DNS record to ensure that it is authorized to email on behalf of that domain. DKIM adds a digital signature to an email message header to verify its authenticity. DMARC combines SPF and DKIM to protect against spoofed email whale phishing. These email authentication policies are considered fundamental anti-phishing basics.

Secure email gateways can also help defend against whaling phishing attacks by filtering out malicious emails before they even reach users’ inboxes. These gateways often use advanced threat intelligence and can leverage machine learning algorithms to detect phishing attempts and other cyber threats. These AI-based solutions analyze patterns in user behavior, match against common attack patterns, and identify potential phishing attacks. They can also scan incoming emails for suspicious content or attachments, making them very useful for phishing prevention.

Proactive Measures: Two-Factor Authentication, Secure Communication Channels #

In addition to defensive technologies, information security departments should take proactive measures, to prevent or at least mitigate whaling attacks. Two-factor authentication (2FA) for email accounts is one such measure that can significantly reduce the risk of a successful attack. 2FA requires users to provide two forms of identification before accessing their accounts, making it much harder for attackers to gain unauthorized access.

Secure communication channels such as cryptographic security infrastructure for emails and forward secrecy for messaging apps can also help prevent spear phishing and related threats by ensuring the integrity and authenticity of data transmitted securely between parties.

Incident Response Planning: Preparation for Whaling Attacks #

Despite the best efforts at prevention, businesses must still prepare for the possibility of a successful whaling attack. Incident response planning involves developing procedures for detecting, containing, and mitigating the impact of a cyber-attack. This includes identifying key personnel responsible for responding to an attack, establishing communication protocols, and regularly testing incident response plans to ensure their effectiveness.

Make DMARC a part of your Whaling Cyber Awareness Agenda #

DMARC is a critical component of any whaling prevention strategy. By restricting messages from a company domain that don’t comply with the established DMARC policy, domain-based message authentication prevents email spoofing and results in fraudulent emails not being delivered to users’ inboxes. By implementing DMARC policies, organizations can protect their employees from falling victim to the most common forms of spear phishing scams.

Robust Compliance Policies #

Corporate policies that, for example, mandate verification of financial transactions or sharing sensitive information can also be beneficial in protecting against whaling attacks. Such a policy might require that all financial requests, including those received through whaling emails, be confirmed through a second, independent means of communication, like a phone call or face-to-face meeting. Consider modifying your organization’s policies so that two people, rather than one, must sign off on payments.

Additionally, regular reviews and adjustments of permissions and access rights help to ensure the least privileged access principles by enforcing that employees only have access to information they need for their job. This can minimize potential damage if a whaling attempt is successful. Mitigating whaling attacks is a continuous process, demanding constant vigilance, regular updates to defense strategies, and a proactive approach to cybersecurity.

Defense Strategies for Individuals #

As an individual, defending against whaling attacks primarily involves fostering a vigilant mindset and adopting practical measures that enhance your cybersecurity hygiene. Here are some strategies that can help:

Maintain Awareness: Keep up-to-date with the latest cybersecurity threats and trends, including understanding whaling and how social engineering functions. This knowledge can help you identify potential risks before they can cause harm.
Verify Requests: If you receive an unusual request involving sensitive information or money, always verify it through a separate communication channel. This could be a direct phone call or a face-to-face meeting with the person making the request.
Be Cautious with Links and Attachments: Be extremely wary of clicking links and opening attachments in unsolicited or suspicious emails. They could lead to fraudulent websites or download malicious software onto your device.
Secure Your Personal Information: The less publicly available your personal information is, the harder it is for cybercriminals to target you. Be cautious about what information you publish online, particularly on social media.
Enable Two-Factor Authentication (2FA): Use two-factor authentication for your accounts whenever possible. This adds an extra layer of security, protecting you even if your password is compromised.
Check Email Sender Details: Always scrutinize the sender’s email address in any suspicious email. Look for discrepancies in the email address or domain name that may reveal a phishing attempt.
Invest in Security Software: Reliable antivirus and anti-malware software can add an extra layer of defense by detecting and blocking malicious content.

By combining these defense strategies with a general culture of cybersecurity awareness, individuals can significantly reduce their vulnerability to whaling attacks.

The Future of Whaling and Cyber Awareness #

Predicting Future Trends in Whaling: The Changing Landscape #

As we move towards 2024 and beyond, the landscape of whaling cyber attacks is changing rapidly. Malicious actors are becoming more sophisticated, and their phishing attack methods are evolving by incorporating new technologies. One major trend we can expect is an increase in targeted spear phishing attacks on high-level executives and other key individuals.

Deepfakes will play a significant role in the impersonation of trusted sources. Deepfake technology, according to researchers, is the most concerning use of artificial intelligence, with essential ramifications in cybercrime and terrorism.

To combat this rising threat, it will be essential for companies to invest in advanced whaling defense strategies. This may include implementing AI and machine learning (ML) mechanisms that detect suspicious activity before it leads to a successful attack. Companies must provide ongoing cybersecurity training and education for all employees, especially those at the executive level.

The Role of AI and Machine Learning in Whaling Defense #

AI and machine learning already play a significant role in whaling defense today, but as we look toward the future, these technologies will become even more critical. By analyzing vast amounts of data from email communications, these tools can assist employees in identifying patterns that indicate phishing attempts or other malicious activity.

One exciting development in this area is using machine learning algorithms to analyze employee behavior patterns over time. By understanding how individuals typically interact with emails and other digital communications, these algorithms can detect anomalies that may indicate an attempted whaling attack.

Some companies are exploring using chatbots powered by AI technology to provide real-time support for employees who may be targeted by phishing attacks. These chatbots can guide how to spot and avoid these threats, reducing the risk of a successful attack.

A Machine-Learning Approach to Phishing Detection and Defense #

Phishing attacks remain common cyber threats organizations face today. Ordinary phishing, however, will likely become a daemon of the past. With advancements in AI and machine learning technology, we can expect to see more elaborate and highly personalized phishing attacks but also significant improvements in abilities to detect and defend against these attacks.

One promising approach involves using machine learning algorithms to analyze email content for signs of phishing attempts, including whaling attacks. These algorithms can learn from past examples of successful phishing emails and use this knowledge to identify new threats as they emerge.

The Importance of Ongoing Cyber Awareness Training and Education #

While AI- and ML-based phishing prevention technologies are critical components of any effective whaling defense strategy, ongoing cyber security training, and employee education should be the focus. Companies can significantly reduce their risk of a successful attack by teaching individuals how to identify potential threats and providing them with the knowledge they need to protect themselves. This training should cover various topics, including best practices for email security, password management, and safe browsing habits. Companies may consider implementing regular simulated phishing tests to help employees stay vigilant against these attacks.

AI-driven Cybersecurity #

As we move into the future, it’s clear that AI-driven cybersecurity will play an increasingly important role in protecting organizations from whaling cyber attacks. By analyzing vast amounts of data in (near) real-time, these tools can detect suspicious activity before it leads to a successful attack.

However, it’s important to remember that these technologies are not (yet?) foolproof. To protect against whaling attacks, companies must take a multi-layered approach, including ongoing employee education, training, and advanced technological solutions like AI and machine learning.

Frequently Asked Questions (FAQs) #

What is whaling cyber awareness? Whaling cyber awareness refers to understanding and knowing how to prevent and detect targeted phishing attacks aimed at high-level executives or individuals with access to sensitive information.
How can I protect myself from whaling attacks? You can implement several strategies to protect yourself from whaling attacks, including being cautious of suspicious emails, verifying requests for sensitive information through a separate communication channel, and regularly updating your security software.
What technologies can be used for whaling prevention? Email filters, multi-factor authentication, and encryption can be used for whaling prevention. Employee training and education on identifying and reporting suspicious activity can also be practical.
What does the future of whaling and cyber awareness look like? As technology continues to advance, whaling attacks will likely become more sophisticated. However, there is also an increased focus on cybersecurity awareness and prevention measures. Individuals and organizations must stay informed and proactive in their approach to cyber security.

Whaling Phishing: Definition and Prevention Strategies

Thu, 18 May 2023 00:00:00 +0200

Disclaimer: This article involved collaboration with a GenAI tool for personal research. All content was reviewed and edited by myself. Feel free to report inaccuracies. Thanks.

Whaling phishing is a cyber attack that targets high-profile individuals and key organizational staff. Attackers use social engineering tactics to trick victims into executing actions or disclosing confidential information, posing a severe cybersecurity threat. These attacks aim to gain access to sensitive information or steal money through fraudulent wire transfers for malicious purposes. Organizations can utilize threat intelligence to stay informed and prepared to prevent such attacks.

Highly context-aware spear phishing attacks in the form of whaling emails are one of the most common forms of whaling attacks. These phishing emails are composed to look like legitimate messages from trusted sources, such as banks, financial institutions, or other companies that the victim may do business with.

Also, phone calls and text messages are standard for attackers to carry out whale phishing cyber attacks. In these cases, the attacker will pose as someone from a trusted source and try to convince the victim to provide confidential data over the phone.

To protect against whale phishing attacks, organizations should implement proper whaling cyber awareness training, educating staff on identifying and avoiding suspicious emails and phone calls. Standard technical security measures such as passwordless authentication or encryption for sensitive data are not enough to cope with a whaling attack. Best practices include implementing processes to regularly update and reinforce employee knowledge of the latest whale phishing tactics based on real-life examples.

Spear Phishing vs Whaling Attacks in Cybersecurity #

Spear phishing attacks, including whaling attacks, are responsible for over 90% of successful data breaches. While traditional phishing attacks target basically anyone with an email address, whaling is a spear phishing attack targeting a very selected audience.

Whale Phishing: A Personalized Approach to Spear Phishing #

Whale phishing, or “whaling,” is a highly personalized spear phishing that targets high-value individuals such as CEOs, financial officers, or other top executives in a company’s management team. Unlike traditional phishing attempts that cast a wide net in hopes of catching any unsuspecting victim, whale phishers take a more targeted approach by researching their victims’ interests, habits, and contacts before launching an attack.

Often malicious actors incorporate social engineering strategies to trick their targets into divulging sensitive information or clicking on malicious attachments or links, which can compromise data privacy. For example, they may send whaling emails that appear to come from trusted sources (like the CEO’s assistant) requesting confidential information or asking the recipient to click on a malware link for malicious purposes.

While whale phishers may go to great lengths to make their phishing email appear legitimate, there are often subtle clues that can help recipients identify them as fraudulent and prevent whaling. For example, they may use slightly different spelling or suspicious grammar. They may also include urgent language designed to create anxiety or fear in the recipient.

The Risks of Spear Phishing Attacks #

A spear-phishing attack, especially whaling, poses significant risks to businesses and organizations of all sizes. By targeting senior executives with access to confidential data and financial resources, attackers can access critical systems, trigger fraudulent processes and wreak havoc on an organization’s operations.

To prevent whaling attacks, educating employees at all levels about spear phishing and whaling risks and providing training on identifying and responding (or instead not responding) to suspicious emails is essential. Regular training and simulated phishing exercises can strengthen this awareness and foster a security-conscious culture.

How Whaling Works #

Targeting the Top #

Whaling phishing attacks are cyber attacks that explicitly target senior executives and decision-makers within an organization. Social media platforms, professional networks, and company websites are rich in information and serve as excellent hunting grounds for malicious actors. This section looks closely at critical concepts used in whaling phishing scams.

A whaling attack often works by applying social engineering strategies. Social engineering is a term that describes psychological manipulation to trick people into exposing sensitive information or performing actions that are not in their best interest.

Whaling is, at its core, an abuse of trust or authority. It can be counted into the class of social engineering attacks as it primarily focuses on obedience psychology, either playing on employees’ inherent desire to follow orders from their superiors or exploiting their personal trust boundaries.

By targeting the human element (the weakest link in any security chain), whaling often successfully circumvents routine technological precautions, making it a particularly troubling type of cyber threat. Attackers can deceive their target individuals into bypassing classical security controls and handing over the keys to the kingdom by playing on trust, authority, or fear. In essence, whaling serves as a sobering reminder that the most severe cybersecurity threats frequently arise not from flaws in our technology but from vulnerabilities within ourselves.

Impersonation #

Cybercriminals regularly use a sophisticated blend of persuasion, deception, and influence rather than brute force or advanced hacking techniques to make their move. They extensively research their high-level targets and study their routines, communication styles, and professional ties. They may utilize this information to impersonate a valued colleague or business partner, creating plausible circumstances that put the target under pressure to act quickly.

Whaling Attack Examples #

Whaling attacks are phishing scams aimed at the organization’s senior management team and decision-makers. This section will discuss some examples of whaling attacks and their impact on businesses.

CEO Fraud #

One typical example of a whaling attack is CEO fraud or “business email compromise” (BEC). In this attack, cybercriminals impersonate a high-level executive or CEO and send fraudulent emails to employees requesting sensitive information or money transfers. The email may appear legitimate, using the CEO’s name and address, but it comes from an external source. According to the FBI’s Internet Crime Complaint Center (IC3), CEO fraud resulted in over $2.4 billion in business losses in 2021 alone.

High-Profile Whaling Attacks #

The following are three famous examples of whaling campaigns. Of course, these are only the tip of the iceberg…

Ubiquiti Networks Inc. – In 2015, a special whaling attack occurred when Ubiquiti Networks Inc., a network technology company, fell victim to a whaling attack, which resulted in a $47 million loss. Cybercriminals pretended to be executives from the management team to persuade key finance department staff to initiate wire transfers to foreign accounts. The damage had already been done by the time the deception was detected. It’s a great example that emphasizes the value of company-internal communication culture.
FACC Operations GmbH – A whaling scam cost FACC Operations GmbH, an Austrian company producing aviation parts, €52 million (about $56 million). A phishing email posing as coming from the CEO requesting a money transfer for a purported “acquisition project” tricked a financial officer in the finance department, who then authorized a corresponding wire transfer. The importance of verifying any unexpected cash demands, especially those that appear to emanate from the top brass, is highlighted by this example.
Snapchat – Even the tech industry’s behemoths are not immune to elaborate phishing practices. In 2016, a whaling attack on Snapchat was executed successfully when a high-profile target employee was duped by a whaling email claiming to be from the CEO. The employee responded to the email’s request for payroll information by providing it without further verification. Fortunately, there was no direct monetary loss. Nevertheless, the phish resulted in a significant data breach incident. It is a somber reminder that hackers aren’t always directly for money; sometimes, they’re after data.

Strategies for Preventing Whaling Cyber Attacks #

To prevent a whaling phishing attack, it’s crucial to implement effective strategies that can protect against social engineering tactics used by cybercriminals.

Implement Employee Training Programs #

A way to prevent whaling is through threat intelligence and training programs for regular employees and the senior management team. These programs should educate employees on social engineering approaches to phishing attacks and provide them with the knowledge required to identify and avoid potential threats.

However, understanding whaling is only the first step toward effective prevention. It is vital to cultivate a security-centric culture within the organization, along with regular security awareness training focusing on the telltale signals of a whaling attack. Employees who receive regular training can spot and report potential whaling efforts.

Establish Best Practices for Email Communication #

Another strategy for preventing whaling phishing attacks is establishing best practices, dedicated security protocols, and safeguarding policies for email communication. This includes requiring multi-factor authentication for email accounts and verifying the sender’s identity before responding to requests or inquiries. Unusual requests should always get verified through a separate communication channel like a phone call. Secure email gateways with robust spam filters must be implemented and maintained.

Profile Target Audiences #

To effectively mitigate a whaling phishing attack, it’s essential to profile target audiences and identify potential vulnerabilities. By understanding the behavior patterns of high-profile individuals and other likely target individuals, businesses and their information security departments can tailor their prevention programs and awareness campaigns accordingly. For example, if a senior executive is known for traveling frequently, they may be more vulnerable to targeted phishing attempts while on the go.

Protecting Against Whaling Phishing Attacks #

There are many different steps organizations can take to protect against whaling phishing attacks:

Employee Training: One crucial step is establishing mandatory employee security awareness training on identifying whaling emails and mitigating social engineering. All key personnel should know how to recognize a fishy domain name, identify the suspicious sender, and call out uncommon business practices.
Two-Factor Authentication: Implementing two-factor or passwordless authentication for all authentication processes can help prevent unauthorized access even if an attacker has already obtained login credentials.
Strong Password Policies: Organizations should implement strong password policies.
Email Filters: Strong email filters can help prevent phishing emails from reaching employees’ inboxes.
Regular Testing: Regularly testing employees’ awareness of social engineering and conducting simulated phishing attacks can help identify areas for improvement.

Potential Impact of Whaling Phishing on Organizations #

Financial Losses #

Successful whaling phishing attacks can lead to significant financial losses for businesses. The game is usually over once cybercriminals trick high-level executives and employees into authorizing a fraudulent wire transfer. These attacks can be devastating. Small and medium-sized companies may need more financial resources to recover from such losses.

Reputational Damage #

Like many other security incidents, successful whaling attacks can cause reputational damage to brands. If an organization falls victim to a phishing attack, it may lose the trust of its customers and partners, who may question its ability to protect data and prevent fraud. It can take years for organizations to rebuild their reputation after a successful phish, which can have long-term financial consequences.

Compromised Sensitive Data #

A whaling phishing attack can severely impact data privacy by compromising confidential data, personally identifiable information (PII), or organizations’ intellectual property. Cybercriminals may use stolen credentials or access gained through these attacks to steal personal information such as trade secrets, customer data, and financial records. This data type is valuable on the black market and can be used for identity theft, subsequent attacks, or sold to competitors or malicious actors.

Conclusion: Understanding the Risks of Whaling Phishing Attacks #

Cyber threats will become more sophisticated and targeted. State-of-the-art AI tooling will make it even easier for malicious actors to social engineer their way into many people. Whaling is a severe threat that must be addressed head-on. Businesses can protect their sensitive data, retain their reputation, and secure financial stability by understanding the psychology behind these attacks and establishing effective preventative and reactionary measures.

Preventing whaling phishing attacks requires a multi-layered defensive approach that includes employee training, robust security protocols, and continuous monitoring and awareness programs. Employee training is essential in raising consciousness about these types of scams. It helps to share best practices, so employees know what red flags to look for when receiving suspicious emails or inquiries.

Regular security assessments should be conducted by third-party experts who can identify vulnerabilities in an organization’s systems and recommend remediation measures. Finally, having a comprehensive incident response plan will help organizations respond quickly and effectively if they fall victim to a whaling phishing attack.

Frequently Asked Questions (FAQs) #

What distinguishes whaling from phishing? While both whaling and phishing are deceptive methods aimed at duping people into providing sensitive information, whaling is primarily designed to target high-ranking members of an organization. It’s like comparing a shark to a whale; both are dangerous, but one is unquestionably bigger and capable of causing more damage.
What kind of information do whalers typically target? Whalers often seek sensitive information that will provide them access to an organization’s secure data or financial assets. This could contain login credentials, financial information, or information that could be used to infiltrate an organization’s network.
How can an organization protect itself from whaling attacks? The first line of protection is awareness. Regular cybersecurity awareness training, concentrating on whaling, can assist employees in recognizing and reporting such attacks. Furthermore, technical safeguards such as powerful spam filters, secure email gateways, and regular software updates should be implemented.
How can I identify a whaling attack? Whaling emails are frequently from reputable sources, such as high-ranking CEOs or well-known organizations. However, warning indicators can include strange requests, inappropriate language, or minor differences in email addresses. When in doubt, it’s best to double-check through another channel before moving on.
How prevalent are whaling attacks? While less common than classical phishing attacks, whaling is gaining appeal among cybercriminals due to its vast potential returns. As cyber risks grow, it is critical to be cautious and aware.
What should I do if I suspect a whaling attempt? First and foremost, do not respond or click on any links. Inform your organization’s IT or security department about the questionable activities. They can evaluate possible threats and take suitable actions.

Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)

Sun, 14 May 2023 00:00:00 +0200

Security measures are effective when they cause the least friction while providing the highest level of security necessary for the targeted, user-friendly business process. Asking for too little gives users (or whoever is posing as them) too much freedom, but asking for too much, especially up front, generates obtrusive friction.

Minimal friction is essential to success, especially in conversion-sensitive flows like sales funnels. Services or apps are meant to be simple to access, and customers who want to utilize a product or purchase within as little time as possible may do so with as little friction. Making authentication even slightly more complicated risks alienating prospective customers.

What is Step-Up Authentication? #

Step-up authentication is one way of balancing friction and security that has received much attention and application in recent years. Step-up authentication ensures that users can access specific resources or execute the most typical actions with a single set of credentials. Users will be prompted for additional authentication factors when requesting to access sensitive resources or initiating privileged operations.

The Rationale Behind Step-Up Authentication #

Step-up authentication aims to tailor identity requests to the value of the resource and the local risk level and anticipated impact if it is compromised. By enabling risk-based authentication, step-up authentication allows organizations to provide easy access to one tier of non-critical resources while providing secure access to another.

As a result, security stays out of the way most of the time and only intervenes when further proofs of authenticity are absolutely required. This makes authentication work for both organizations and customers since both can be certain that their most sensitive resources are safe and secure.

It also opens new ways to conduct authorization by allowing organizations to privilege access for paying users.

Step-Up Authentication vs Single-Factor Authentication #

Although ubiquitous, single-factor authentication (SFA) frequently falls short of offering adequate security against common identity attacks. This traditional approach, which usually requires only a username and password, is widely regarded as insufficient due to its susceptibility to breaches ranging from brute-force attacks like password spaying to phishing schemes.

In contrast, step-up authentication provides a more dynamic and context-sensitive security barrier. Instead of depending on a single, static layer of protection, it adjusts to changing risk levels by providing additional verification steps as needed. Step-up authentication provides a more sophisticated and scalable approach to security, delivering a higher level of protection without losing user convenience under normal conditions.

Step-Up Authentication vs Multi-Factor Authentication #

In many security-conscious environments, multi-factor authentication (MFA) has become the gold standard, requiring users to present a second factor (or multiple authentication factors) to access their online accounts. While MFA considerably improves security over single-factor authentication, it may cause user annoyance, particularly if additional verification steps are required for every login or transaction, regardless of the associated risk.

Step-up authentication is a flexible form of multifactor authentication, adding additional security layers only when necessary, such as during high-risk transactions or unusual account activity. This method ensures essential security requirements and improves the user experience by reducing unnecessary disruptions.

Step-Up Authentication vs Adaptive Authentication #

Adaptive authentication, like step-up authentication, is a more intelligent, context-aware approach to account security. It dynamically increases the level of necessary user authentication based on a risk assessment of each individual login or access attempt, considering parameters like geolocation (e.g., impossible travel), IP reputation, device characteristics, and behavior patterns, or user’s risk profile.

However, there is a subtle distinction between the two. While responding to perceived risks, step-up authentication often initiates additional authentication processes in predetermined conditions and based on static risk assessments, such as when a user attempts a high-value transaction.

In contrast, adaptive authentication uses advanced risk analysis algorithms, sometimes powered by artificial intelligence or machine learning, to assess the need for extra real-time authentication steps. While both give a more personalized and responsive approach to security compared to previous static techniques, Adaptive Authentication provides a more granular and automated risk assessment, possibly providing a higher level of protection and user experience when applied successfully.

How Step-Up Authentication Works #

Step-up authentication generally requires multiple stages of verification. When a user initiates an action that requires enhanced security, such as accessing confidential documents or conducting financial transactions, the system prompts the user for multi-factor authentication. This step up can manifest itself in a variety of ways, including, but not limited to:

Two-Factor Authentication (2FA) – To verify a user’s authenticity, this method combines something the user knows (e.g., a password) with something the user owns (possession factor), such as a unique code generated by a mobile app.
Biometric Authentication – Biometric authentication delivers high security and convenience for users by using unique biological traits (inherence factor) such as fingerprints, facial recognition, or iris scans.

Implementing Step-Up Authentication #

In traditional authentication systems, step-up authentication was handled by integrating the relevant business logic within the web applications. Custom engineering efforts and heterogeneous implementations could have used more resources by neglecting to reuse well-tested code and incurring ongoing maintenance costs. Still, they also increased the possibility of security flaws.

Since federation protocols like OpenID Connect (OIDC) are becoming increasingly popular for modern applications that want to improve security by relying on a reliable identity provider, there are also better, standardized options for implementing step-up authentication.

Step-up Authentication with OpenID Connect #

OIDC is an open standard with built-in support for relying parties (RP) that require more potent authentication methods (AMR) to be used depending on the authentication context classes. Because conventional federation protocols such as OIDC are business context agnostic and do not track every user interaction, business apps must initiate step-up scenarios independently.

Forced Re-Authentication Methods #

Following successful authentication, IdPs frequently provide long-running login sessions bound to user agents. The goal is to eliminate consumer friction by removing the need for regular active credential authentication. However, depending on an RP’s local risk assessment, certain business operations may require the most recent functional proof of authenticity check to be no more than a particular period old.

Relying parties use the optional authentication request variable max_age to communicate session age expectations to an IdP service. OIDC-compliant IdPs ensure that all session age requirements are met by requiring authentication as needed.

GET /authorize?
 response_type=code
 &scope=openid%20profile%20email
 &client_id=s6BhdRkqt3
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &max_age=300 HTTP/1.1
Host: server.example.com

Requiring re-authentication of existing sessions every time a user attempts to access sensitive information or protected areas of an application adds friction to the user experience. Session elevation can be used to successfully achieve a balance between a smooth user experience and security considerations.

The authentication context class concept allows apps to build such scenarios and coordinate with an identity provider (IdP) for smooth step-up service in a declarative policy-driven method.

Authentication Context Class Reference (ACR) #

The optional authentication request parameter acr_values is a space-separated list of ACRs that determines the client application’s minimum degree of authentication. If the parameter is present, the IdP takes all measures necessary to verify and match the requested class. Users may be asked to re-authenticate using additional or different authentication methods to achieve this objective.

The authentication context class met by the completed identity authentication is returned as the ACR claim value within the provided identity token, which can then be utilized for authorized purposes by the RP.

ACR values and their semantics must be established, aligned, and documented between IdP and RPs out of the band. Only then business owners effectively employ them to precisely determine what ACR relates to the local risk assessment of their specific business operations.

Authentication Level Elevation #

Access to sensitive information and operations must be logged appropriately and authorized by resource servers. Verifying the validity of the provided bearer token is required to ensure that a client is eligible to undertake a specific operation.

The goal of session authentication and assurance level elevation is to provide a relatively seamless user experience by maintaining a minimum level of assurance for a user session when the user first authenticates to the application and then raising their authenticity levels based on local risk assessments:

Assuming that a user successfully established a session after logging in with a username and password and now attempts to access a sensitive resource, they are prompted to apply extra authentication factors.
The session is upgraded to a higher assurance level after a successful step-up using an additional authentication method.
Because their session is already at the raised authentication levels, no extra authentication challenge will be prompted the next time users enter the sensitive section within the specified duration.

GET /authorize?
 response_type=code
 &scope=openid%20profile%20email
 &client_id=s6BhdRkqt3
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &acr_values=mfa
 &max_age=300 HTTP/1.1
Host: server.example.com\

Conclusion #

Step-up authentication aims to adapt authentication requirements to the significance associated with a resource and the level of risk if it is exposed. It is one way to strike a balance between friction and security by allowing customers to continue using already known, established, and understood authentication concepts (username and password, for example) to access regular resources while prompting them for additional proof of authenticity and a different form of two-step authentication (such as confirmation via email or push notifications) in the context of more sensitive business operations (such as financial transactions or accessing sensitive data).

Enabling session authentication level elevation and step-up authentication can resolve the target conflict of providing customers with a smooth experience on the one hand and enforcing more significant security standards for specified operations or resources on the other.

Frequently Asked Questions (FAQs) #

What are the minimum requirements to implement Step-Up Authentication? #

First and foremost, a reliable and secure primary authentication mechanism, such as a secure password system or biometric identification method, is essential. Second, an additional authentication method, such as text message verification, email confirmation codes, security questions, or biometric checks, must be available and compatible with the user base.

The user’s technological capabilities and the amount of security required to determine which to utilize. Third, an effective risk assessment system must be established to detect circumstances requiring more verification. Finally, to support all the complex procedures involved in step-up authentication, an IT infrastructure that is both adaptable and secure is necessary.

How does Step-Up Authentication improve user experience? #

Step-up authentication is intended to improve the user experience by requiring further verification only when necessary. Step-up authentication, as opposed to standard static multi-factor authentication, which requires additional steps every time a user signs in or performs specific actions, only increases security measures in the context of higher-risk activities.

This means that for most ordinary actions, consumers may enjoy a frictionless, seamless experience without being burdened by additional security precautions. However, when it comes to more sensitive procedures, such as changing personal information or completing large transactions, consumers can welcome the added degree of protection, knowing their accounts and data are secure.

How can Step-Up Authentication prevent data breaches? #

Step-up authentication is a powerful technique that adds complexity and layers to the authentication process. Step-up authentication adapts to the perceived risk level of a user’s activity. This means that even if an attacker successfully steals or guesses a user’s primary credentials, they will still face additional, often unanticipated, obstacles before getting access. Many cyberattacks are deterred by this since it considerably increases the work and skill required to compromise an account.

Password Attack Guide: What is Password Spraying?

Thu, 11 May 2023 00:00:00 +0200

Introduction to Password Attacks #

Cybercriminals continuously seek new ways to gain account access and exploit security flaws as technology progresses. Password spraying is one such practice that, in recent years, has become popular among hackers looking to gain unauthorized access to accounts and sensitive information. But what exactly is password spraying, how does it work, and what can you do to prevent it? Let’s get started.

What is Password Spraying? #

Password spraying is a well-defined (T1110.003) password attack in which hackers test several commonly utilized passwords to gain access to several user accounts. Malicious actors frequently prepare spraying attacks with reconnaissance and discovery techniques to learn more about the targeted account base. Often online services leak information in their sign-up or password reset processes. Password spraying then concentrates on trying common passwords across many known accounts.

The motivation behind password spraying attacks #

As the cyber threat landscape evolves, threat actors’ focus shifts from assaulting computer networks to stealing user identities. Because of the increasing sophistication of software in detecting malware programs and vulnerabilities, attackers have been forced to adapt, resulting in a greater emphasis on identity-based attacks.

Many organizations invest considerably in securing user accounts by establishing complicated password policies and restricting access to resources from secure networks. While these precautions are vital best practices, they are frequently insufficient in the face of a compromised trusted user account.

How Password Spraying Works #

Understanding a typical password spray attack is critical to protect against and investigate it. Password spray attacks are brute-force attacks that use an exhaustive list of usernames and link them with popular passwords to guess the proper combination for as many passwords and users as possible.

Advanced password spraying involves techniques that rely on people using variations of common passwords and often follow three key characteristics: multiple account targeting, common passwords and wordlists, and other dictionary attacks while flying low and slow under the radar.

Targeting Multiple Accounts #

In a password-spraying attack, attackers target many accounts instead of focusing on one password or a single account. They avoid activating security measures such as account lockout policies or active blocking by spreading their efforts over numerous accounts.

Common Passwords & Dictionary Attack #

Attackers employ lists of common passwords or customized dictionaries, pre-compiled lists of words, phrases, and character combinations likely to be used as passwords. These lists are frequently based on leaked password databases, increasing the likelihood that an attacker would find a match. The password top lists by OWASP are likely the most popular sources for common passwords.

The Use of Bots & Automation in Password Spraying #

A determined malicious actor has to be patient. The most sophisticated password sprays will employ multiple IP addresses and not uncommonly involve botnets to simultaneously assault various accounts with a limited number of selected password guesses. Numerous password-spraying tools exist that help even less techy threat actors to automate brute-force attacks and password-spraying for multiple targets, protocols, and use cases. Due to their highly distributed and low frequent (“dripping”) characteristics, these credential-based attacks are hard to distinguish from natural authentication attempts and often remain undetected.

Password Spraying vs Brute-Force Attack #

Password spraying is a type of brute-force attack. Both seek to guess passwords and identify matching user credentials; the primary distinction is how they do it. Traditional brute-force attacks target a single account and attempt all potential password combinations. This can take time and may result in account lockouts or security alerts. Password spraying, on the other hand, distributes the risk by targeting several accounts with fewer password attempts, making it harder to detect and more likely to succeed, especially given that many regular users reuse commonly used passwords across multiple sites. A password-spraying attack is a brute-force attack on steroids.

Password Spraying vs Credential Stuffing #

Password spraying and credential stuffing are two different credential-based attacks used by attackers to exploit password vulnerabilities. Credential stuffing is a technique in which an attacker obtains a list of leaked credential pairs (username and password) from a prior data breach and attempts to use the same credentials against several accounts hoping to gain access to a valid account. Credential stuffing takes advantage of a list of known credential combinations, and many end-users reuse the same password across many accounts, which is more effective than password spraying. The dark web is full of more or less reliable stolen credentials.

Password Spraying vs Dictionary Attack #

A dictionary attack is a brute force attack in which an attacker generates a password list by combining various words and phrases from a dictionary, hence the name “dictionary” brute force attack. While dictionary attacks and password spraying target passwords, their goals and methods differ. Dictionary attacks seek to exhaust all possible password combinations, whereas a password spraying attack aims to discover a common password used by numerous users. In both cases, attackers are hunting for easy-to-guess or regularly used passwords.

Real-World Examples of Password Spraying #

Password spraying attacks never stop. The following three real-world examples of security incidents caused by password spraying attacks are just the tip of the iceberg:

Microsoft Office 365 Attack – In 2021, Microsoft observed a spike in password-spraying assaults against 250 Office 365 customers in the US and Israeli defense technology sectors. According to Microsoft, the credential-based attacks targeted critical infrastructure businesses in the Persian Gulf and were conducted by a group known as DEV-0343.
Parliament of the United Kingdom Attack – In June 2017, a password-spraying attack targeted the email accounts of members of the UK Parliament, resulting in remote access being blocked for MPs as a precaution.
Citrix Systems Attack – Between 2018 and 2019, hackers accessed Citrix systems and sensitive data over five months. The FBI alerted Citrix to the breach in March 2019 and stated that a password-spraying attack was the likely cause.

How a Password Spraying Attack Affects Your Customers #

Understanding password spraying risks and compromised security costs heavily depends on local threat scenarios, business contexts, and risk appetite. The most severe consequence of password spraying is often a loss of consumer trust. When a website or email account is compromised, there is no way to protect the customer’s personal information or sensitive data without extra passwordless security measures.

Data Breaches & Identity Theft – Password spraying attacks allow fraudsters to gain unauthorized access to sensitive consumer data such as personal information, financial information, intellectual property, and login credentials. This information can be used to commit identity theft or resell on the dark web, placing your clients at risk of financial loss and long-term damage to e.g. their credit ratings.
Loss of Trust – Customers provide businesses their personal information, expecting to be kept safe and secure. A compromised account caused by a password spraying attack can cause users to lose trust in your brand, resulting in decreased customer loyalty and potential loss of business.
Disrupted Services – Credential-based attacks might cause your services to be unavailable, inconveniencing customers that rely on them. Downtime caused by an attack and active countermeasures might make it difficult for your consumers to access their accounts, make purchases, or use your services, leading to irritation and dissatisfaction.
Financial Impact – If an attack is successful, customers may experience economic consequences due to unlawful transactions, fraudulent charges, or the cost of mitigating the effects of identity theft. These financial obligations can diminish the perceived value of your products or services, driving away customers.
Privacy Concerns – When customers discover that their personal information has been exposed due to a password spraying attack, they may become more concerned about their overall privacy and be less willing to share information with a business in the future.

Detecting password spraying attacks #

The most critical exercise to enable effective password spray defense is to monitor and respond to suspicious activity by leveraging tools for detecting password spraying.

Examine account authentication attempts regularly and automatically to spot any failed logins or suspicious patterns. A high ratio of failed login attempts for different accounts in a short period could indicate an ongoing password-spraying attack.

Unusual Account Activity #

Organizations vulnerable to spraying and other credential-based attacks should create user profiles for their accounts and overarching population profiles for their whole account base to discover login abnormalities. User profiles can assist in signaling suspected account activity coming from unexpected IP addresses, utilizing unique user agent identifiers, or other criteria by scoring the originality of an authentication attempt based on prior interaction data. If a user has previously successfully authenticated from a German IP using an iOS user agent, authentications for the same account from an Android smartphone in India should be noticed, considered malicious traffic, and (ideally) trigger additional authentication steps.

Population profiles are comparable but have a broader scope because they consider metadata such as location profiles, network profiles, and device information used throughout the customer base. If an organization’s business plan, for example, restricts service offers to specific users or regions, login attempts from other locations may result in a higher risk score. A company that only operates in Europe will most certainly flag sign-ins from China, resulting in additional actions or limited privileges.

Password spraying prevention #

There are plenty of password spraying defense techniques and best practices available. The most effective threat mitigation is the abandonment of password-based authentication systems (knowledge factor) in favor of passwordless mechanisms. Because this is not currently practicable for many organizations, defense with multiple layers and reinforced authentication approaches is required.

IP-Blocking & Geo-Blocking #

When preventing password spraying or distributed denial of service (DDoS), the ultimate last resort is to hard block individual IPs, entire CIDR ranges, ASNs, or regions. Of course, this will have a significant business impact and will only temporarily alleviate the pressure.

Bot Management #

Because password spraying attacks frequently use automation tooling and large-scale botnets, automated bot recognition and management are critical for password spraying prevention. Because bot detection can not produce binary conclusions or sharp deny decisions, intermediary challenges, and further authentication steps are required.

Intermediary Challenges #

There are at least two types of intermediary challenges: interactive challenges, such as CAPTCHAs, which require users to solve a puzzle to prove human interaction, and non-interactive challenges, such as proof-of-work-based mechanisms, which need a suspicious user agent to solve cryptographic exercises, significantly slowing automated efforts and raising operational costs for large-scale attacks.

Strong Password Policies and Best Practices #

Implementing a firm password policy that encourages complex passwords and prohibits using regularly used passwords and compromised credentials does not necessarily prevent spray attacks. Bad actors will still attempt them, but it renders them virtually ineffective. I recently wrote about how to create a strong password policy that is user-friendly and effective, which you should read!

Passwordless Authentication #

Passwordless authentication is a modern paradigm shift away from knowledge factors (passwords) and toward possession (like Passkeys) or inherence factors (biometrics). Passwordless login is the most effective password-spraying attack prevention because the primary target is removed. I recently described why passwordless sign-in is regarded as the future of cybersecurity; take a look!

Enable Multi-factor Authentication (MFA) #

Two-factor authentication (2FA) and MFA incorporate at least two separate authentication concepts, with the passwordless access component always included. Regular password-based logins are frequently complemented by one-time passwords (OTP) produced in a separate authenticator app or device. Enable MFA to prevent password spraying attacks – many federated authentication providers support 2FA enforcement!

The Ongoing Battle Against Password Attacks #

Password spraying attacks are only one example of how the cybersecurity landscape keeps evolving. As attackers create new strategies, companies and individuals must remain aware and proactive in their security procedures. Brute-force attacks, such as password spraying, can be considerably reduced by setting strong username and password guidelines, establishing multi-factor authentication, and cultivating a security-conscious culture.

Frequently Asked Questions (FAQs) #

Can password spraying be easily detected? #

Because of their low and slow nature, it might be challenging to detect password-spraying attacks. However, organizations can detect and prevent password-spraying attacks with the correct tools and monitoring.

How can I protect my personal accounts from password-spraying attacks? #

To protect your personal accounts from password-spraying attacks, use unique passwords, avoid obvious passwords, enable 2FA, monitor attempts to gain access to your accounts regularly, use password managers, be aware of phishing emails, and keep your security measures up to date.

Are there any tools available to help detect and prevent password spraying? #

Numerous technologies are available to detect and prevent password spraying attacks, like Security Information and Event Management (SIEM) systems, User and Entity Behavior Analytics (UEBA) tools, or dedicated edge protection services. Organizations should employ a combination of these tools and solutions to safeguard their networks and user accounts.

What should I do if I suspect password spraying compromised my account? #

If you suspect your account has been hacked by a password-spraying attack, act quickly to protect your account and personal information. Change your password, apply two-factor authentication, notify the service provider, monitor your potentially compromised accounts, and update your security measures if you see any strange behavior.

Is it Possible to Prevent a Password Spraying Attack? #

While 100% protection against brute-force attacks like credential stuffing or password spray attacks is difficult to ensure, implementing strong password policies, utilizing two-factor authentication, monitoring for suspicious activity, and training users and staff can considerably lower the likelihood of successful attacks.

Honeytoken: Authentication Attack Breach Detection

Sat, 29 Apr 2023 00:00:00 +0200

Disclaimer: This article involved collaboration with a GenAI tool for personal research. All content was reviewed and edited by myself. Feel free to report inaccuracies. Thanks.

TL;DR

Honeytoken accounts are a tool that can help businesses detect data breaches. Creating a honeytoken account involves setting up canary traps by inventing sensitive data that appears legit PII.
When a threat actor stumbles upon a honeytoken account and attempts to use the fake credential set, it triggers an alert that notifies the system administrator or security analyst of the intrusion.
Honeytokens can’t prevent attacks but can function as threat detectors.

The Need for Honeytoken Accounts #

In today’s rapidly evolving digital landscape, cybercriminals are devising new and sophisticated ways to exploit vulnerabilities and gain unauthorized access to sensitive information. With organizations of all sizes experiencing an alarming rise in credential breaches, it’s more important than ever to have robust defense and threat detection mechanisms in place.

Enter honeytoken accounts: a powerful yet often overlooked tool transforming how businesses detect data breaches and prevent authentication attacks. In this article, I’ll delve into honeytokens, explore their unique benefits, and reveal how they can serve as a formidable threat detection alert in your cybersecurity arsenal. So, buckle up and get ready to uncover the secret weapon that just might page your security team early enough in case of a data breach!

Threat detection & Credential Breaches #

Detecting credential breaches can be a daunting challenge, and even with the right combination of strategies and tools, organizations can’t be sure about all their employed safety measures effectively safeguarding their sensitive data, like customer accounts and PII. Many companies today face reality where they are constantly tasked with verifying (supposedly) breached credentials that pop up in the darkest corners.

The Collection #1 breach from 2019, for example, included 2.7 billion email/ password pairs and affected many platforms and services around the web, not because they were actively breached but because large percentages of their customers constantly reuse their credentials on other solutions, as these alarming password reuse studies show. This fact alone renders credential breach verifications a tedious exercise.

At the same time, security teams have to deal with ever so expanding software supply chains leading to an organization’s infrastructure complexity constantly increasing. In short, suspicious activity is the default, and the recent waves of layoffs in IT companies around the globe do not reasonably contribute to reducing insider threats.

What are Honeytoken accounts, and how do they work? #

Honeytoken accounts, sometimes called trap or decoy accounts, are a clever and creative way to detect unauthorized access and stay one step ahead of cybercriminals. Picture them as digital tripwires, alerting you when someone tries to break into your computer systems. Intrigued? Let’s dive deeper into the world of honeytoken accounts and see how they work.

At their core, honeytoken accounts are fake user accounts explicitly created to act as bait for cyber attackers. They’re designed to blend seamlessly with real accounts, making it difficult for hackers to distinguish between them. When threat actors stumble upon a honeytoken account and attempt to use the fake credential set, it triggers an alert that notifies the system administrator or security analyst of the intrusion.

The beauty of honeytoken accounts lies in their simplicity. Planting these decoys throughout your system or network can lure hackers into revealing their presence. This gives your security team valuable information about the attacker’s methods and tactics, enabling them to respond quickly and effectively to mitigate potential threats.

In summary, honeytoken accounts are an ingenious and proactive approach to detecting unauthorized access. They allow security teams to set traps that function as web beacons and trigger alerts for your security analysts in case honeytoken authentication activity is registered. By incorporating them into your cybersecurity strategy, you can either catch an attacker in the act or detect malicious actors post-breach.

Types of Honey Tokens #

Different types of honey tokens can be used in various ways, such as creating decoy email addresses, placing a fake file containing bogus sensitive information, or even setting up false API keys:

Fake Email Addresses #

The idea behind using fake email addresses as honeytokens is to create convincing decoy accounts that blend in with real ones, making it difficult for hackers to distinguish between them. Curious about how it works? Let’s explore this creative cybersecurity technique.

To begin with, you’ll want to create a fake email address that appears genuine and closely resembles your organization’s actual email addresses. This could involve using a similar top-level domain, following the same naming conventions, or even incorporating the names of real employees. The key is to make it look authentic so that hackers are tempted to target it.

Once you set up your fake email address, the next step is strategically placing it within your organization’s digital landscape. This could involve including it in publicly accessible documents, online directories, text files, or even embedding it within, e.g., an internal website’s code. By doing this, you’re essentially laying a digital breadcrumb trail for cybercriminals to follow.

When an attacker comes across a fake email address and decides to target it with phishing emails, spam, or other malicious activities, it triggers an alert. This notification informs your security analysts that someone is attempting to exploit the decoy address, allowing them to quickly respond and investigate the incident. In the process, they can gather invaluable information about the attacker’s methods, tactics and even determine the extent of their knowledge about your organization.

Fake Database Records #

You’ll want to create fake database records that convincingly blend in with your actual data. This could involve creating decoy customer profiles, transactions, or relevant data that match your organization’s structure and environment. The crucial element here is to make these fake records appear genuine, enticing cybercriminals to interact with them.

Once you have your fake database records ready, the next step is to carefully embed them within your actual database. Be sure to scatter them among nonfictional records, making it challenging for hackers to identify the decoys. While doing this, set up monitoring tools and paging mechanisms to notify your security teams when these fake records are accessed, modified, or exported.

When an attacker infiltrates your system and interacts with the fake database records, it triggers an incident, allowing your security analysts to quickly identify, respond and investigate the incident. As they gather information about the attacker’s methods, tactics, and potential targets, they can take appropriate measures to mitigate the threat and strengthen your organization’s defenses.

Fake Executable Files #

Fake executables can go a few steps further, as they often are very much like malware, except they’re created and manipulated for defensive purposes against a threat. The software or application can contain backchannels that return data back to you when threat actors interact with them. While it is theoretically possible that fake executable files could cause damage to an attacker’s systems, they can only work as long as attackers cannot effectively protect their devices.

How to create a Honeytoken Account? #

Creating honeytokens for customer accounts means setting up canary traps by inventing sensitive data that appears to be legit PII. Often the most rudimentary subset of information necessary for such a honey token involves email address, password hash, and names.

When you now ask ChatGPT for a set of fake customer data, alter the generated email addresses so that they nicely blend into your customers. If you, for example, conduct business mostly with people from Spain, give them some nice Spanish TLDs. Also, create hashes that match your hash algorithm based on passwords that people commonly use instead of super long, randomized strings. This way, your own honeytokens might even be crackable by the attacker. The honey credentials must appear natural and smell like real value.

Once you are done with your preparations, feed the fake data into your customer DB and set up alerting for honeytoken authentication activity with your identity provider.

How to detect threats with Honeytoken Accounts? #

If you follow the approach outlined above, this part of your threat detection is fully automated without needing to actively monitor around the clock. The identity provider or authorization server will detect threats when attackers gain access using the honey credentials.

Furthermore, even with malicious activity on your site, you will be able to quickly assess the validity of a potential breach data next time external security researchers reach out with critical information or your own threat intelligence team gets their hands on email/ password collections attributed to your organization.

Of course, honey tokens can only be one puzzle piece within your threat detection toolset. The low effort and neglectable cost factors make it a simple approach you should consider in your everyday security practice.

Frequently Asked Questions (FAQs) #

What Is a Honeypot vs. Honey Token? #

Honeypots and honeytokens, while sharing a similar purpose, have distinct roles in cybersecurity. They both serve as digital traps to detect and analyze cybercriminal activities. A honeypot is a decoy system or network resource designed to appear as a legitimate and valuable target to attackers. It can mimic servers, databases, or other network components, enticing cybercriminals to interact with it. Once the attacker engages with the honeypot, their activities are monitored, logged, and analyzed.

On the other hand, a honeytoken is a specific type of digital bait, such as a fake user account, email address, or file, strategically placed within an organization’s systems or network. Like a honeypot, it is designed to attract attackers but focuses on individual elements rather than an entire system.

Can Honeytokens Prevent Supply Chain Attacks? #

Cyber-security techniques never can or will prevent any attack on the supply chain or via other angles. In general, honey tokens function as a threat detector rather than threat prevention. Since supply chain attackers could breach target systems via compromised vendors, honeytoken deployment can provide a genuine approach for digital supply chain attack detection when incorporated into processes and data exposed to the vendors.

How can Honeytokens help security teams? #

As ingenious digital traps, Honeytokens can provide security teams with a proactive edge in the battle against cyber threats. They offer several key benefits, making them an invaluable tool for enhancing an organization’s cybersecurity strategy. The essential advantage lies in the early detection of breaches and enhanced threat intelligence.

How do you protect accounts from stolen credentials?

Fri, 21 Apr 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summaries kept. Replaced the broken link to the password breach alerting paper with the USENIX copy.

Short answer: Check usernames and passwords against breach data with a privacy-preserving protocol, and add risk signals such as known devices and locations to the login decision. Breached credentials show up in about 1.5% of logins on the web, and in one study 7-25% of exposed passwords matched the victim’s Google account.

Key findings #

Telemetry from nearly 670,000 users and 21 million logins showed that 1.5% of logins on the web involve breached credentials.

Source: Thomas et al., Protecting accounts from credential stuffing with password breach alerting (USENIX Security 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

26% of breach warnings shown at login led users to switch to a new password at least as strong as the original.

Source: Thomas et al., Protecting accounts from credential stuffing with password breach alerting (USENIX Security 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Between 7% and 25% of passwords exposed through breaches, phishing kits and keyloggers matched the victim’s Google account.

Source: Thomas et al., Data Breaches, Phishing, or Malware? (CCS 2017)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In some contexts, the hash prefixes that common breach-checking services receive make remote guessing attacks 12 times more effective.

Source: Li et al., Protocols for Checking Compromised Credentials (CCS 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Compromised credential studies
Study	Year	Sample	Method	Finding
Protocols for Checking Compromised CredentialsCornell Tech, Cloudflare	2019	Existing C3 services (HaveIBeenPwned, Google Password Checkup)	Formal analysis, leakage simulation, protocol design	Hash-prefix leakage can make guessing 12 times more effective; 2 stronger protocols remain practical.
Protecting accounts from credential stuffing with password breach alertingGoogle, Stanford	2019	Over 4 billion breached credentials; nearly 670,000 users and 21 million logins	Protocol design, Chrome extension telemetry	1.5% of logins involve breached credentials; 26% of warnings led to a new password.
Data Breaches, Phishing, or Malware? Understanding the Risks of Stolen CredentialsGoogle, UC Berkeley, ICSI	2017	1.9 billion breached credentials, 12.4 million phishing and 788,000 keylogger victims	Longitudinal measurement, March 2016 to March 2017	7-25% of exposed passwords matched the victim’s Google account.

What to do #

For engineers #

Check credentials against breach data at sign-up, password change and login. Use a protocol that never sends the password or its full hash to the checking service. Thomas et al. combine “computationally expensive hashing, k-anonymity, and private set intersection”; Li et al. show how much a plain hash prefix can leak.
Don’t decide a login on the password alone. Thomas et al. (2017) show that risk signals such as a user’s historical geolocations and device profiles reduce the hijacking risk from stolen passwords. The reinforced authentication entry collects studies on login risk scoring.
Watch for stuffing and spraying patterns across accounts, not only per account. See password spraying and honeytokens for detection ideas.

For product and UX #

Tell users when their credentials appear in a breach, and make the next step a single action. In the Google study, 26% of warnings led to a new password that was at least as strong.
Expect most users not to act on a warning alone. The password reuse entry covers what makes a notification work and where notifications fall short.

The studies in detail #

Protocols for Checking Compromised Credentials #

“To prevent credential stuffing attacks, industry best practice now proactively checks if user credentials are present in known data breaches.”

For this paper, researchers from Cornell Tech and Cloudflare analyzed existing compromised credential checking (C3) services such as HaveIBeenPwned and Google Password Checkup. They give the first formal description of C3 services, including operational requirements and threat models. Current services have the client share a short prefix of a password hash. The authors show that in some contexts this prefix makes remote guessing 12 times more effective. They then propose “two new protocols that provide stronger protection for users’ passwords”, implement them, and show that they remain practical to deploy.

Read the paper (PDF)

Protecting accounts from credential stuffing with password breach alerting #

Researchers from Google and Stanford describe how Google’s password breach alerting works, which constraints and hard requirements it meets, and which cryptographic protocols it uses. Their cloud service covered over 4 billion breached credentials, and a Chrome extension served as the first client.

“Our protocol relies on a combination of computationally expensive hashing, k-anonymity, and private set intersection. Our approach improves on existing protocols by taking into account both an adversarial client and server, while also minimizing the chance of false positives.”

Anonymous telemetry from nearly 670,000 users and 21 million logins showed that 1.5% of logins on the web involved breached credentials. 26% of the warnings led users to migrate to a new password at least as strong as the original.

Read the paper (PDF)

Data Breaches, Phishing, or Malware? Understanding the Risks of Stolen Credentials #

Between March 2016 and March 2017, researchers from Google, UC Berkeley and the International Computer Science Institute identified 788,000 potential keylogger victims, 12.4 million potential phishing kit victims and 1.9 billion usernames and passwords exposed in data breaches. With this data, they “explore to what degree the stolen passwords […] enable an attacker to obtain a victim’s valid email credentials — and thus complete control of their online identity due to transitive trust”. In their case study of Google accounts, 7-25% of exposed passwords matched the victim’s Google account.

The study is from 2017, but its mitigation still applies today: the authors show that adding risk signals, such as a user’s historical geolocations and device profiles, to authentication helps mitigate hijacking with a correct but stolen password.

Read the paper (PDF)

How do attackers take over accounts?

Fri, 21 Apr 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summaries kept and extended with numbers from the papers.

Short answer: Some attackers prepare an account before the victim even signs up: at least 35 of 75 popular services studied were vulnerable to such pre-hijacking. Others are paid to break into a specific account and mostly use tailored phishing that can get past SMS two-factor authentication.

Key findings #

At least 35 of 75 popular online services were vulnerable to one or more account pre-hijacking attacks.

Source: Sudhodanan and Paverd, Pre-hijacked accounts (USENIX Security 2022)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In an account pre-hijacking attack, an attacker who knows only the victim’s email address acts before the victim creates an account and gains access after the victim has signed up.

Source: Sudhodanan and Paverd, Pre-hijacked accounts (USENIX Security 2022)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Of 27 hack-for-hire services that researchers approached as buyers, only 5 succeeded in attacking the email accounts of the test identities.

Source: Mirian et al., Hack for Hire (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Hack-for-hire attackers relied mainly on tailored phishing messages that were sophisticated enough to bypass SMS two-factor authentication.

Source: Mirian et al., Hack for Hire (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Account hijacking studies
Study	Year	Sample	Method	Finding
Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the WebIndependent researcher, Microsoft Security Response Center	2022	75 popular online services	Attack design and testing against live services	At least 35 services were vulnerable to one or more of 5 pre-hijacking attacks.
Hack for Hire: Exploring the Emerging Market for Account HijackingUC San Diego, Google	2019	27 English, Russian and Chinese hack-for-hire services	Posing as buyers against synthetic victim identities	5 services succeeded, mostly through tailored phishing.

What to do #

For engineers #

Don’t let anyone use an account before they have proven they control its identifier. Verify the email address before the account becomes usable, and before you merge a password account with a federated login for the same address.
Only trust email addresses from identity providers that verify them. One of the 5 attacks relies on a non-verifying identity provider.
End all sessions and expire pending email-change links when the password is reset or the email address changes. Two of the attacks rely on unexpired sessions and email changes.
Offer phishing-resistant factors. The hack-for-hire services got past SMS codes with phishing. See passwordless authentication and my critical notes on passkeys.

For product and UX #

Show users which sign-in methods are linked to their account, and notify them when one is added.
When someone signs up with an address that already has a pending or unverified account, guide them through verification instead of silently signing them in.
Recovery flows are another takeover path. The account recovery entry lists the common weaknesses.

The studies in detail #

Account Pre-Hijacking Attacks: Security Failures in User Account Creation #

“The ubiquity of user accounts in websites and online services makes account hijacking a serious security concern. Although previous research has studied various techniques through which an attacker can gain access to a victim’s account, relatively little attention has been directed towards the process of account creation.”

In this study, Avinash Sudhodanan and Andrew Paverd show that there is a whole class of account pre-hijacking attacks. The key point: “The distinctive feature of these attacks is that the attacker performs some action before the victim creates an account, which makes it trivial for the attacker to gain access after the victim has created/recovered the account.”

The authors assume a realistic attacker who knows only the victim’s email address. They describe 5 attacks: Classic-Federated Merge, Unexpired Session, Trojan Identifier, Unexpired Email Change and Non-verifying IdP. Of 75 popular services they analyzed, at least 35 were vulnerable to one or more of them. Some attacks were completely undetectable from the victim’s point of view. The paper closes with security requirements that prevent these vulnerabilities.

Read the paper (PDF)

Hack for Hire: Exploring the Emerging Market for Account Hijacking #

In this paper, researchers from UC San Diego and Google “study a segment of targeted attackers known as ‘hack for hire’ services to understand the playbook that attackers use to gain access to victim accounts.”

Posing as buyers, they contacted 27 English, Russian and Chinese black-market services, and only 5 succeeded in attacking the synthetic but realistic identities the researchers controlled. The attackers mostly used tailored phishing that could bypass SMS two-factor authentication. The authors also observed low volume, poor customer service and multiple scammers in this market. The paper is a good read if you want to understand the commercial account hijacking ecosystem and the techniques criminals use.

Read the paper (PDF)

About Jan Brennenstuhl

Thu, 08 Apr 2021 00:00:00 +0200

Hi. My name is Jan Brennenstuhl, I live and work in Berlin Germany, where I was born and raised. I am a product-minded software engineer, security enthusiast & clean code artist with a huge interest in interdisciplinary software development and engineering leadership. I am a big fan of cycling sports, coffee & hiking.

I currently work in Berlin as principal engineer, focused on application security and making agentic engineering more secure and efficient. I spent years building and operating identity solutions used by millions of customers — balancing UX and security in high-stakes revenue funnels — and have since moved into the broader AppSec space, where I’m most interested in the intersection of security, usability, and automation.

I’ve worked as software engineer and lead on e-commerce funnels, rule engines, cloud strategies, IAM and SSO solutions, REST APIs, system integrations, technology research, legacy migrations, decommissioning projects and modularizing monolithic systems — various things, mostly in e-commerce and security. I practiced software archaeology more than I set up greenfield web services.

I am an internet standards enthusiast, who values open source software and open formats over custom builds. For me, quality software products are created best by small teams of product-minded engineers with a narrow, well-defined business scope and a clear vision. I’m especially passionate about leading and influencing engineers as well as creating and operating reliable, secure and maintainable software products.

I hold a M.Sc. in Computer Science from the University of Potsdam, where I completed my thesis on “Certificate Management in the Cloud for Authentication in university Environment”. I’ve also studied Media Informatics at the Beuth University of Applied Sciences in Berlin.

Weak Crypto, Github SAML Attack & Twitter Security UX

Sun, 15 Jan 2017 00:00:00 +0100

Finally, I managed to come up with a name for my regular reading tips series which will feature both, latest info around recent events & incidents (especially when it comes to identity and security topics) as well as long running articles I strongly advice to read… it’s simply called Readme.

The first issue of my Readme series features not just the latest Google Infrastructure Security Design Overview but also the most recently fixed SAML authentication bypass in GitHub Enterprise. As a small bonus on top, I’d like to share a nice UX security analysis regarding Twitters “someone is logging in to your account” e-mail, I recently stumbled upon. But first things first…

Weak Crypto in Google Cloud Platform?! #

Google just released the latest version of its Google Infrastructure Security Design Overview that describes how security is designed into Google’s technical infrastructure. It’s a quite interesting paper for everyone, relying on Google Services but also for people who want to know how current industry standards look like. In addition to operational security and hardware infrastructure, it also considers authentication and login abuse as well as end user data access and inter-service access.

I am not quite done reading it, but one interesting catch so far is that Google Cloud Platform products seem to be heavily based on the “common cryptographic library, Keyczar”, which actually is made by Google and states on its project page…

“KeyCzar has some known security issues which may influence your decision to use it.”

One of the known issues is the usage of 1024 bit DSA keys with SHA1… nothing more to add, I believe.

Update 08.04.2017: As Tim Dierks (Security at Google) let me know via Twitter, “the use of the term ‘KeyCzar’ was an error in the first release of the white paper” that got already removed. “We do not rely on the open-source lib [KeyCzar, editor’s note] internally and its disclaimers do not apply to GCP”, he clarified.

GitHub SAML Vulnerability #

January 12th, a critical security patch was rolled out for Github Enterprise. In accordance to the official release notes, it fixes a major issue that allowed the bypass SAML authentication which was found and reported by Ioannis Kakavas. Github strongly advices to update asap!

Critical security issues in SAML implementations are not new, as German security researchers already showed back in 2012: On Breaking SAML - Be Whoever You Want to Be.

Bad Security UX at Twitter #

Being open and transparent towards your endusers when it comes to (possible) security issues can be a good thing to do. But you can also do a lot wrong about it - e.g. when your phishing or login fraud countermeasures turn against you (and your customers).

A Twitter security notification get analyzed by UX experts.

One of the examples, that actually illustrate how not to communicate a possible account compromise is Twitters “someone is logging in to your account” e-mail that can (and should) be optimized/ fixed as pwnallthethings described on Twitter… well done!

That’s it for now, so have fun reading and stay secure!

AppSec · Brennenstuhl on Security

AppSec in the Age of Agentic Engineering

Materials #

Reading companion #

Guest Lecture at HTW Berlin: AppSec in the Age of Agentic Engineering

Fixing Findings Is the New Bottleneck #

The Harness Is the Control Plane #

Shift Security Down into the Platform #

Give Risk an Operational Budget #

The Coding Agent Is an Attack Surface #

What I Asked the Students to Learn #

Shift Down: Why Agentic Engineering Demands Platform-Level Security

Shift-Left Distributes Responsibility. Shift-Down Removes Decisions. #

Agentic Engineering Makes This Urgent #

Platforms as Security Architecture #

AppSec Moves from Enforcement to Architecture #

The Paradox: Less Freedom, More Productivity #

Where This Leaves AppSec Teams #

Dependency Updates: latest Is Not a Security Strategy

The Trust Problem #

What Controlled Trust Looks Like #

Pin Versions #

Enforce Release-Age Cooldowns #

Control Upgrade Cadence #

Verify Provenance, But Do Not Trust It Alone #

Deploy Repository Proxies #

Use Reachability-Aware Scanning #

Reduce Dependency Surface Area #

Controlled Trust, Not Blind Trust #

AppSec in the Age of Agentic Engineering

Findings Pile Up Faster Than Teams Fix Them #

Move Security Feedback Into the Agent Loop #

Build and Ship Security Tooling #

Security Skills and Machine-Readable Policy #

Local Scanners and Review Agents #

Sandboxes and Short-Lived Credentials #

Threat Modeling and Offensive Testing #

Partner With SRE and Platform Teams #

Where to Start #

Bunny Shield Review: 3 Things Need Improvement

What Bunny Shield Gets Right #

Initial User Experience & Setup Simplicity #

Default Security Coverage #

What Bunny Shield Needs to Improve #

Certificate Renewal Blocked by WAF #

No Bot Allowlisting for Good Bots like Ahrefs or Semrush #

Limited Logging and Visibility into WAF Events #

Missing WAF Error Code Lookup Tool #

Final Thoughts: Promising Foundations, But Still in Beta #

Got Feedback or Similar Experiences? #

What is Whaling Cyber Awareness? Prevention Tips & Training

What is Whaling Cyber Awareness? #

Security Awareness: Why It Matters #

Technologies and Strategies for Whaling Prevention #

Defensive Technologies: Anti-Spoofing, Secure Email Gateways, and AI-based Solutions #

Proactive Measures: Two-Factor Authentication, Secure Communication Channels #

Incident Response Planning: Preparation for Whaling Attacks #

Make DMARC a part of your Whaling Cyber Awareness Agenda #

Robust Compliance Policies #

Defense Strategies for Individuals #

The Future of Whaling and Cyber Awareness #

Predicting Future Trends in Whaling: The Changing Landscape #

The Role of AI and Machine Learning in Whaling Defense #

A Machine-Learning Approach to Phishing Detection and Defense #

The Importance of Ongoing Cyber Awareness Training and Education #

AI-driven Cybersecurity #

Frequently Asked Questions (FAQs) #

Whaling Phishing: Definition and Prevention Strategies

Spear Phishing vs Whaling Attacks in Cybersecurity #

Whale Phishing: A Personalized Approach to Spear Phishing #

The Risks of Spear Phishing Attacks #

How Whaling Works #

Targeting the Top #

Social Engineering Tactics #

Impersonation #

Whaling Attack Examples #

CEO Fraud #

High-Profile Whaling Attacks #

Strategies for Preventing Whaling Cyber Attacks #

Implement Employee Training Programs #