Affiliate Disclosure: This site contains affiliate links. We earn a commission when you purchase through our links at no additional cost to you.

SecurityClaw just ran its most complete scan of bol.com yet — and the numbers are stark.

Campaign-005 ran on April 29, 2026, on an EC2 instance with 16 AI-powered security skills executing in parallel. It recovered 2,607 findings from S3 storage. The previous campaign, run weeks earlier against the same target, returned only 57 findings — not because the platform was cleaner, but because a platform bug was silently truncating output at 24 kilobytes. That issue is now fixed. This is what bol.com actually looks like.

What SecurityClaw Is

SecurityClaw is an AI-driven security reconnaissance platform built by ClawWorks. It runs structured “campaigns” — target-scoped runs where a set of skills executes concurrently on EC2, each looking for a different class of issue. Skills are stateless Python functions wrapped in a common interface. Results land in S3. A coordinator aggregates them.

Campaign-005 was a validation run: its primary purpose was to confirm that three recent platform fixes actually worked in the field. The target was bol.com — one of the largest e-commerce platforms in Europe, operating a bug bounty program on Intigriti.

What the Campaign Found

Certificate hygiene at scale. The dominant finding was expired TLS certificates: 2,547 expired_cert findings across bol.com’s subdomains. These are certificates that have passed their validity date but are still being served. For a platform at bol.com’s scale, this is almost always infrastructure sprawl — decommissioned services, staging environments, and CDN edge nodes that outlive the cert renewal cycle.

These findings are informational at P3 severity. They’re not exploitable in the classical sense, but they signal certificate lifecycle management gaps and create risk in environments where clients don’t enforce strict cert validation.

Wildcard certificate exposure. 53 wildcard_cert findings: subdomains serving certificates with *.bol.com or similar wildcards. Wildcard certs are a legitimate pattern, but at this count they indicate bol.com relies heavily on wildcard issuance rather than per-service certificates. From a bug bounty perspective, wildcard reuse is worth noting as a scope artifact.

Unexpected CA. 6 unexpected_ca findings: subdomains presenting certificates issued by a CA outside bol.com’s expected trust anchors. The specific subdomain surfaced: techlab.bol.com. This is a medium-severity finding (P3 in Intigriti’s framework) — it suggests a lab or research environment running with a non-standard PKI setup.

One WAF block. A single WAF_BLOCK finding: Akamai’s WAF returning a 403 on a specific skill’s probe. The detection was correct — the skill identified the Akamai response header, extracted the block reason, and logged it with the right payload. This validates the WAF detection skill added in the previous sprint. (There’s a minor platform issue to fix: the finding normalizer doesn’t yet have a type mapping for WAF_BLOCK, so it gets stored under service_vuln — that’s on the backlog.)

How the Platform Validated Its Own Fixes

Campaign-005 was explicitly designed to confirm three prior fixes:

S3 results pipeline (PR #910): The previous campaign lost ~2,550 findings to SSM stdout truncation. The fix reroutes results to S3 — large outputs go directly to bucket storage, bypassing the 24KB SSM cap entirely. Campaign-005 returned 978,146 bytes of findings with no truncation. Fix confirmed.

Context-optional skills (PR #911): 16 of 16 skills ran successfully with zero context-related failures. The fix decoupled skills from a required context parameter that was causing silent failure when context wasn’t provided. Fix confirmed across the full skill set.

WAF detection (PR #914): The WAF skill correctly identified the Akamai 403, extracted the right payload, and generated a finding. Partial confirmation — the detection works, but the output normalizer needs a follow-up fix to map WAF_BLOCK to its own finding type instead of falling through to service_vuln.

Bonus fix discovered. While validating, the team found a dead code path that had been hiding in run_campaign.py since the S3 collection was first written: the s3_client object was created but never passed to the execution function, meaning S3 collection was silently skipped on every run. It was fixed in this PR.

What This Looks Like in Practice

Campaign-005 ran in 4 minutes 8 seconds on a single EC2 instance. 16 skills. 2,607 findings. No truncation, no context failures. If you’re benchmarking what automated security reconnaissance against a major European e-commerce platform looks like in 2026, that’s the number.

The cert hygiene findings won’t produce bounty payouts — they’re informational — but they’re exactly the kind of surface that informs a more targeted follow-up campaign. Where are the unexpired but misissued certs? What’s techlab.bol.com running under that unexpected CA? What does the WAF’s fingerprint reveal about which resources it’s protecting?

Campaign-006 is scoped to dig into those questions. The platform is ready. If you’re hunting subdomain-related findings on mature targets, see the bol.com subdomain recon walkthrough for a deeper look at what CT log enumeration surfaces.

Understanding Certificate Findings at Scale

The 2,547 expired certificate findings deserve more explanation than “P3, not submittable.” Certificate transparency data is a research tool, not just a finding type — and understanding what the volume signals about a target’s infrastructure is part of using it effectively.

Why Expired Certs Accumulate

Certificate lifecycle management at scale is genuinely hard. A large e-commerce platform like bol.com runs dozens of active services simultaneously: the main storefront, seller portals, internal APIs, staging environments, microservices, partner integrations, monitoring endpoints. Each service needs a TLS certificate. The difficulty is that cert renewal is typically tied to the service’s deployment pipeline — and when a service is decommissioned, the cert renewal job gets cancelled, but the DNS record stays active for weeks or months.

The result: a graveyard of expired certs in CT logs, each representing a service that once existed at a subdomain. From a recon perspective, this is useful. Expired certs from 2024–2025 reveal the architecture of the old infrastructure. Services named partner.bol.com, recruitment-git.bol.com, and cms-gateway.bol.com suggest a Git service for internal recruitment, a CMS gateway facing the internet, and a partner portal — all of which may have been decommissioned but could still have successors at different URLs.

Reading the Subdomain List

The CT log enumeration from Campaign-005 surfaced subdomains that wouldn’t appear in normal DNS resolution. A selection that warrant follow-up:

  • techlab.bol.com — lab or R&D environment, unexpected CA (Trust Provider B.V.), currently serving
  • recruitment-git.bol.com — historical Gitea or similar, decommissioned
  • cms-gateway.bol.com — historical CMS gateway, decommissioned
  • hipstershop.stg.bol.com — Google microservices demo app on staging environment (see Campaign-004 for detail)
  • servicedesktps.bol.com — typo in the domain name (desktps rather than desktops) — suggests manual DNS entry rather than automated provisioning

The typo subdomain is the most interesting from a security perspective. Automated DNS provisioning doesn’t produce typos. This entry was probably created manually for a service desk or IT portal. Manual entries are more likely to survive decommissioning unnoticed, because automated rotation pipelines don’t clean them.

What “WAF_BLOCK” Means as a Finding

The single WAF_BLOCK finding from Campaign-005 was Akamai blocking a specific skill probe on bol.com’s main domain. The finding type is important to understand correctly: it doesn’t mean the WAF was bypassed — it means SecurityClaw correctly detected the WAF and logged the block as a structured finding.

What you do with a WAF_BLOCK finding:

  1. Map which skill triggered it. Different skills send different request shapes. If the CORS-testing skill triggered the block but the header-checker didn’t, that tells you the WAF is pattern-matching on specific request headers (like Origin: evil.com) rather than on IP/ASN alone.
  2. Check which assets are behind the WAF vs. not. Large platforms often have inconsistent WAF coverage — the main domain is protected, but API subdomains, staging environments, or partner portals may not be. Campaign-005’s single WAF_BLOCK suggests the block was targeted at a specific probe, not a blanket IP-level block (which would have returned dozens of WAF_BLOCK findings).
  3. Use it as a scope signal. If the WAF is blocking your scanner on the main domain but not on techlab.bol.com or hipstershop.stg.bol.com, those subdomains become higher-priority targets for follow-up campaigns.

The Data Pipeline That Made This Possible

The reason Campaign-005 recovered 2,607 findings — where Campaign-004 recovered only 57 — was entirely a platform infrastructure fix, not a change in what bol.com exposes.

The old result collection flow used AWS Systems Manager (SSM) RunCommand to execute the campaign script and collect output via CommandInvocation.Output. SSM caps stdout at 24,000 bytes. A certificate transparency scan of bol.com and *.bol.com produces hundreds of kilobytes of JSON — the first 24KB gets returned, the rest is silently discarded.

The new flow:

# skills write findings to S3 during execution
s3_client.put_object(
    Bucket=RESULTS_BUCKET,
    Key=f"campaigns/{campaign_id}/findings/{skill_name}.json",
    Body=json.dumps(findings)
)

# coordinator reads from S3 after execution completes
response = s3_client.get_object(Bucket=RESULTS_BUCKET, Key=findings_key)
findings = json.loads(response['Body'].read())

Each skill writes its findings directly to S3 as it runs. The coordinator reads from S3 after the campaign completes. No stdout. No 24KB limit. Campaign-005 returned 978,146 bytes — the full output.

This is the fix that unlocked real-scale scanning. Without it, SecurityClaw was running 16 skills and seeing only the first ~50 findings regardless of target.

Peng is Senior Security Engineer at ClawWorks. SecurityClaw is the research platform behind bughuntertools.com.