Daily Reading for 2026-09-25
Daily Reading for 2026-09-25
Simon Willison’s Tools
Two short release notes from Simon Willison. commit-rewriter 0.2 adds support for operating against branches other than the default, runnable via uvx with a –branch flag. datasette 1.0a41 adds OpenTelemetry support contributed by Alec Garcia and refactors all of Datasette’s modal dialogs into a single Web Component that is now documented for other plugins to reuse. Together they show the steady, incremental maintenance cadence of his open-source tooling: small, focused changes that extend automation (rewriting git history across branches) and observability and interoperability (telemetry, shared UI components) for downstream plugin authors. The value is cumulative — each release lowers the cost of integrating with or extending the surrounding ecosystem rather than chasing a headline feature.
Watch for:
- The uvx commit-rewriter –branch workflow for rewriting history on non-default branches.
- Datasette’s OpenTelemetry instrumentation and what signals it exposes.
- Plugin reuse of the new Datasette modal-dialog Web Component.
- The continuing alpha cadence on the path toward Datasette 1.0.
Wardley signals:
-
Components: commit-rewriter; uvx; Datasette; OpenTelemetry; Datasette modal-dialog Web Component; the plugin ecosystem.
-
Evolution stage: Datasette is Product (mature, widely used, feature-differentiated) trending Commodity for data publishing; commit-rewriter is Custom (niche, evolving); OpenTelemetry is Product trending Commodity (standard observability); Web Components are Product/Commodity (standardised browser technology).
-
Doctrine hits/misses: “Use standards” (OpenTelemetry, Web Components); “A bias towards open” (components documented for plugins); “Use appropriate tools” (uvx for distribution); “Do better with less” (small incremental releases).
-
Climatic patterns: Everything evolves through supply and demand competition; components co-evolve (observability with tooling); efficiency enables innovation (reusable components); higher-order systems create new sources of value (the plugin ecosystem).
-
Diffusion markers: Standardised OpenTelemetry adoption; shared component reuse across plugins; documented APIs lowering integration cost; routine alpha release cadence.
wardley-beta %% 1. Users: developers, data publishers, and Datasette plugin authors %% 2. Needs: rewrite git history, publish and query data, observe and extend tooling %% 3. Capabilities: branch-aware history rewriting, packaging/distribution, telemetry, reusable UI components, plugin extension %% 4. Components: commit-rewriter, uvx, Datasette, OpenTelemetry, modal-dialog Web Component, plugin ecosystem %% 5. Maturity: uvx (Commodity), Datasette (Product), OpenTelemetry (Product), modal-dialog Web Component (Product), commit-rewriter (Custom), plugin ecosystem (Custom) %% 6. Managed by: Simon Willison as maintainer, with community contributions and plugin authors anchor developer [0.95, 0.90] anchor dataPublisher [0.85, 0.80] component commitRewriter [0.30, 0.60] component uvx [0.82, 0.45] component datasette [0.58, 0.78] component openTelemetry [0.62, 0.55] component webComponent [0.55, 0.50] component pluginEcosystem [0.32, 0.65] commitRewriter -> developer uvx -> commitRewriter datasette -> dataPublisher openTelemetry -> datasette webComponent -> datasette pluginEcosystem -> datasette openTelemetry -> developer evolve datasette 0.68 evolve webComponent 0.62
Storm-2570 Ransomware Tradecraft
Microsoft Threat Intelligence has tracked Storm-2570, a ransomware affiliate active since April 2025, across the Qilin, DragonForce, Anubis and BERT RaaS ecosystems. The throughline is that the affiliate’s post-compromise tradecraft stays largely constant even as the final payload changes: commodity RMM tools (MeshAgent/MeshCentral, Atera, ScreenConnect, Splashtop, NinjaRMM), tunneling utilities (Cloudflared, ngrok), credential theft (Mimikatz, LaZagne, pypykatz, ntdsutil), and cloud exfiltration (s5cmd, Rclone to S3). Renamed, victim-themed binaries and encrypted outbound tunnels let the actor blend into legitimate administration. The practical message for defenders is to hunt the affiliate’s recurring behaviour across the attack chain, rather than treating each ransomware brand as an isolated incident, because detection and disruption opportunities exist before encryption begins.
Watch for:
- Renamed MeshAgent/MeshCentral binaries and services (meshagent64-.exe) with Base64-encoded command lines.
- Cloudflared.exe installed as a LocalSystem service, exposing RDP or creating a persistent outbound tunnel.
- ntdsutil IFM/ntds.dit dumping plus Defender tampering (DisableAntiSpyware, DisableRealtimeMonitoring, C:\PerfLogs exclusions).
- s5cmd or Rclone staging with credential files, copying filtered data to attacker-controlled S3 buckets.
Wardley signals:
-
Components: RaaS ecosystems (Qilin, DragonForce, Anubis, BERT); RMM tooling (MeshAgent/MeshCentral, Atera, ScreenConnect, Splashtop, NinjaRMM); tunneling utilities (Cloudflared, ngrok); credential theft tools (Mimikatz, LaZagne, pypykatz, ntdsutil); cloud exfiltration (s5cmd, Rclone, AWS S3); Microsoft Defender/XDR detections and Security Copilot.
-
Evolution stage: Ransomware payloads are Product (competing RaaS brands with feature differentiation); commodity RMM, tunneling and exfil tools are Commodity (widely available, interchangeable); credential-theft tooling is Product trending Commodity; the affiliate’s cross-ecosystem tradecraft is Custom (adapting, not standardised); Defender/XDR detections and attack-disruption automation are Product.
-
Doctrine hits/misses: The affiliate illustrates “Use appropriate tools” and “Do better with less” (reusing commodity tooling); defenders tracking payloads rather than actors miss “Know the details” and “Manage inertia”; Microsoft’s tamper-protection and MFA guidance reflects “Use standards” and “Focus on the outcome”; affiliate independence from any single brand echoes “There is no core”.
-
Climatic patterns: Everything evolves through supply and demand competition; components co-evolve (RMM tooling with criminal practice); success breeds inertia (payload-centric defence); efficiency enables innovation (commodity tools lower attacker cost); commoditisation of RaaS.
-
Diffusion markers: Cross-ecosystem affiliate reuse and copy-cat tradecraft across ransomware brands; publicly documented, standardised TTPs; commodity tooling adoption; vendor detections and hunting queries standardising defender response.
-
Beyond the ransomware: Tracking Storm-2570’s consistent tradecraft across deployments
wardley-beta %% 1. Users: SOC analysts and incident responders %% 2. Needs: detect and disrupt ransomware intrusions before encryption, and connect related incidents %% 3. Capabilities: threat detection, credential/identity protection, tamper-resistant endpoint hardening, exfiltration monitoring %% 4. Components: affiliate tradecraft, RaaS ecosystems, RMM tooling, cloud exfiltration (s5cmd/Rclone), credential theft tooling, Defender XDR detections, tamper protection %% 5. Maturity: RMM tooling (Commodity), cloud exfiltration (Commodity), credential theft (Product), XDR detections (Product), tamper protection (Product), RaaS ecosystems (Product), affiliate tradecraft (Custom) %% 6. Managed by: ransomware affiliates across RaaS ecosystems; Microsoft Defender/XDR and internal security teams on the defence anchor socAnalyst [0.95, 0.90] anchor incidentResponder [0.88, 0.80] component affiliateTradecraft [0.30, 0.80] component raasEcosystem [0.50, 0.85] component rmmTooling [0.85, 0.55] component cloudExfiltration [0.82, 0.50] component credentialTheft [0.55, 0.45] component xdrDetections [0.60, 0.65] component tamperProtection [0.65, 0.70] xdrDetections -> socAnalyst tamperProtection -> socAnalyst affiliateTradecraft -> xdrDetections raasEcosystem -> affiliateTradecraft rmmTooling -> affiliateTradecraft cloudExfiltration -> affiliateTradecraft credentialTheft -> affiliateTradecraft affiliateTradecraft -> incidentResponder tamperProtection -> incidentResponder evolve affiliateTradecraft 0.42 evolve xdrDetections 0.72
Microsoft Security Product Updates
Microsoft’s September 2026 security update round is framed around governing AI agents. New capabilities let Defender and Security Copilot generate AI explanations of email URL/file detonation results; Purview and Entra Global Secure Access extend context-aware data-loss policy to the network layer for on-behalf-of agentic traffic, blocking sensitive uploads to unsanctioned AI tools. Purview auto-labeling scales to 20 million items and 50,000 sites with new audit reporting, eDiscovery now covers user-owned SharePoint embedded containers such as Loop and Copilot Pages, and Data Lifecycle Management can archive or permanently delete inactive content so it drops out of Microsoft 365 Copilot indexing. The throughline is that agentic AI is arriving in the enterprise and identity, data and SOC controls are being retrofitted to discover, govern and contain it.
Watch for:
- Enforcement of Purview classification at the network layer for on-behalf-of agentic traffic, blocking shadow-AI uploads.
- Auto-labeling adoption at 20M-item / 50k-site adaptive-scope scale and the new coverage/processing reports.
- eDiscovery search, hold, review and export of Copilot/Loop containers, plus HTML conversion for legal review.
- Archiving and priority-cleanup deletion of stale content dropping out of Microsoft 365 Copilot indexing.
Wardley signals:
-
Components: Microsoft Defender; Security Copilot (email detonation summaries, agents); Microsoft Purview (auto-labeling, eDiscovery, Data Lifecycle Management); Microsoft Entra Global Secure Access; agentic/on-behalf-of traffic; shadow AI apps; SharePoint embedded containers (Loop, Copilot Pages); Microsoft 365 Copilot indexing.
-
Evolution stage: Defender and Purview are Product (mature, feature-differentiated suites) trending Commodity; Copilot and AI agents are Custom (emerging, rapidly changing); agent governance and Zero Trust for agent traffic is Genesis (novel); auto-labeling is Product.
-
Doctrine hits/misses: “Use appropriate tools” and “Focus on the outcome” (govern agents rather than ban them); “Listen to your ecosystem” and “Design for constant evolution” as agentic use spreads; “Manage inertia” for organisations still treating AI as shadow IT; misses “A bias towards open” where controls remain vendor-locked.
-
Climatic patterns: Everything evolves through supply and demand competition; components co-evolve (AI agents with data-governance practice); higher-order systems create new sources of value; capital flows to new areas of value (agent security); creative destruction of manual compliance workflows.
-
Diffusion markers: Rapid adoption of AI agents across employee devices and developer workflows; standardisation of agent identity and governance; copy-cat vendor features (data-security-for-AI); ecosystem bundling of governance into existing suites.
wardley-beta %% 1. Users: SOC teams and compliance/eDiscovery officers %% 2. Needs: govern AI agents, keep sensitive data in policy, investigate content at scale %% 3. Capabilities: agent discovery/containment, data classification and DLP, network-layer enforcement, AI-assisted investigation %% 4. Components: Microsoft Defender, Security Copilot, Microsoft Purview, Entra Global Secure Access, agentic traffic governance, auto-labeling, eDiscovery %% 5. Maturity: eDiscovery (Commodity), Defender (Product), Purview (Product), Entra Global Secure Access (Product), auto-labeling (Product), Security Copilot (Custom), agentic traffic governance (Genesis) %% 6. Managed by: Microsoft as platform vendor; enterprise security/compliance teams operating it anchor socTeam [0.95, 0.90] anchor complianceOfficer [0.85, 0.78] component defender [0.62, 0.70] component securityCopilot [0.30, 0.75] component purview [0.58, 0.60] component entraGSA [0.55, 0.55] component agenticGovernance [0.12, 0.68] component autoLabeling [0.60, 0.50] component ediscovery [0.72, 0.45] securityCopilot -> socTeam defender -> securityCopilot purview -> complianceOfficer entraGSA -> purview agenticGovernance -> entraGSA autoLabeling -> purview ediscovery -> complianceOfficer defender -> socTeam evolve agenticGovernance 0.35 evolve securityCopilot 0.55
Threat Modeling: Diagrams vs Models
In an excerpt from the second edition of his threat modeling book, Adam Shostack draws a sharper line between diagrams and models. A diagram is just pixels — a boundary, control or principal drawn by hand; it is easy, fast and customizable, and nothing stops you breaking its rules. A model makes those properties explicit so they can be specified, computed and checked: give each element an account attribute and boundaries can be derived automatically. Models are harder and costlier to build and maintain, but a model checker can warn like a compiler. Shostack argues LLMs will drive down the cost of modeling, moving the field from diagrams toward deeper, model-centered analysis — and eventually toward model-driven system construction that generates design, as-built and as-operated diagrams on the fly.
Watch for:
- Whether LLM-assisted threat modeling treats a diagram as a useful review checkpoint or skips it entirely.
- Tooling that derives boundaries and controls from model attributes rather than hand-drawn lines.
- Traceability links actively maintained between models and code.
- The shift from hand-made diagrams to diagrams generated on the fly from system models.
Wardley signals:
-
Components: threat-model diagrams; formal threat models; model checkers; LLM threat-modeling assistants; diagramming tools (e.g. Visio); system models and model-driven construction.
-
Evolution stage: Hand-drawn threat-model diagrams are Commodity (ubiquitous, cheap, standardised practice); diagramming tools are Product; formal threat models and model checkers are Custom (emerging, specialist); LLM-assisted threat modeling is Genesis (novel, uncertain); model-driven development is Genesis/Custom.
-
Doctrine hits/misses: “Know your users” and “Focus on user needs” (the return-on-investment framing); “Use appropriate tools” (diagram vs model by context); “Think fast, inexpensive, restrained and elegant” (diagrams’ low cost); “Bias towards the new” and “Listen to your ecosystem” for LLM-driven modeling.
-
Climatic patterns: Efficiency enables innovation (componentisation effect) — cheaper modeling enables deeper analysis; everything evolves through supply and demand competition; characteristics change as components evolve; evolution to higher-order systems creates new sources of value.
-
Diffusion markers: LLM assistants lowering the cost of diagramming and modeling; growing tooling work on model-driven construction; standardisation of models with checkable properties.
wardley-beta %% 1. Users: security architects and threat-modeling practitioners, plus product teams reviewing output %% 2. Needs: find design flaws, communicate and review risk, keep model-to-code traceability %% 3. Capabilities: sketching system boundaries, specifying checkable properties, automated rule checking, LLM-assisted analysis %% 4. Components: hand-drawn diagrams, diagramming tools, formal threat models, model checkers, LLM threat-modeling assistants, model-driven system construction, traceability to code %% 5. Maturity: hand-drawn diagrams (Commodity), diagramming tools (Product), formal threat models (Custom), model checkers (Custom), traceability (Custom), LLM assistants (Genesis), model-driven construction (Genesis) %% 6. Managed by: practitioners and tool vendors; increasingly LLM assistants generating or checking models %% note: QA iterate #1 — respaced nodes (diagrams right-low, modelCheckers/traceability separated) to remove label/node overlaps anchor securityArchitect [0.93, 0.93] anchor productTeam [0.72, 0.86] component diagrams [0.86, 0.66] component diagrammingTools [0.66, 0.60] component threatModels [0.38, 0.72] component modelCheckers [0.14, 0.55] component llmAssistants [0.26, 0.38] component modelDrivenConstruction [0.05, 0.28] component traceability [0.48, 0.45] diagrams -> securityArchitect diagrammingTools -> diagrams threatModels -> securityArchitect modelCheckers -> threatModels llmAssistants -> threatModels modelDrivenConstruction -> threatModels traceability -> threatModels threatModels -> productTeam evolve threatModels 0.45 evolve llmAssistants 0.30
SectopRAT Malware Analysis
Fortinet’s incident response team dissects a SectopRAT (ArechClient2) variant concealed inside a tampered legitimate digital-audio-workstation application. This is not a supply-chain compromise: FrameworkBase.dll was modified to import a malicious sdkcra.dll, planted under C:\ProgramData and launched by a scheduled ReportDump.exe task. A multi-stage loader decrypts ASM from Activation.Desktop.db, resolves 187 APIs by hash, abuses EnumSystemCodePagesW as an execution trampoline, and unpacks the final .NET payload from pool.db entirely in memory. Once running, SectopRAT communicates AES-encrypted with its C2 across 29 commands, stealing browser credentials, cookies, autofill, saved cards, email-client and crypto-wallet data, while offering screen capture, file and process management, and remote shell. The write-up shows how a RAT can hide behind legitimate software to evade file-based detection.
Watch for:
- Tampered IATs on legitimate DLLs and malicious imports such as sdkcra.dll under C:\ProgramData.
- EnumSystemCodePagesW abused as an execution trampoline together with API hashing.
- AES-encrypted C2 packets with a five-byte encoded length prefix and a hardcoded AES key.
- Fallback C2 discovery via Binance BNB seed domains and download of the WbElevation.dll stealer module.
Wardley signals:
-
Components: SectopRAT/ArechClient2 .NET RAT; legitimate DAW software and its DLLs (FrameworkBase.dll, sdkcra.dll, ReportDump.exe); multi-stage loader (pool.db, Activation.Desktop.db); API hashing and EnumSystemCodePagesW; AES-encrypted C2 protocol; WbElevation.dll stealer module; FortiGuard AV/web-filtering detections; cryptocurrency wallet extensions.
-
Evolution stage: .NET RAT families are Product (many competing, well-understood malware kits); commodity loaders and API-hashing are Product trending Commodity; the tailored multi-stage loader and C2 fallback are Custom (evolving, bespoke); AV signatures and IOC lists are Commodity (standard, widely shared).
-
Doctrine hits/misses: The attacker “Uses appropriate tools” and thinks “fast, inexpensive, restrained and elegant” (reusing legitimate software and commodity APIs); defenders relying only on file-based detection miss “Manage failure” and “Manage inertia”; defender “Bias towards data” (IOCs, ATT&CK mapping) and “Know the details” support response.
-
Climatic patterns: Everything evolves through supply and demand competition; characteristics change as components evolve (RATs gaining fileless, in-memory loading); success breeds inertia (signature-only defence); commoditisation of crimeware tooling.
-
Diffusion markers: Public IOC sharing and ATT&CK technique mapping; commodity .NET obfuscation and API hashing adopted across RAT families; standardised AV signatures; copy-cat loader techniques.
wardley-beta %% 1. Users: malware analysts and incident responders %% 2. Needs: understand the loader, detect and contain RAT intrusions, protect credentials and wallets %% 3. Capabilities: payload unpacking, execution-trampoline detection, C2 traffic analysis, AV/IOC-based containment %% 4. Components: SectopRAT payload, multi-stage loader, API hashing/EnumSystemCodePagesW, AES C2 protocol, WbElevation stealer module, AV signatures/IOC lists, crypto wallet extensions %% 5. Maturity: AV signatures and IOC lists (Commodity), crypto wallet extensions (Commodity), SectopRAT payload (Product), AES C2 protocol (Product), multi-stage loader (Custom), API hashing (Custom), stealer module (Custom) %% 6. Managed by: a malware operator running the C2; Fortinet/AV vendors and incident responders on the defence anchor malwareAnalyst [0.95, 0.90] anchor incidentResponder [0.86, 0.78] component sectoprat [0.55, 0.72] component loader [0.28, 0.55] component apiHashing [0.30, 0.42] component c2Protocol [0.50, 0.60] component stealerModule [0.35, 0.50] component avSignatures [0.85, 0.65] component walletExtensions [0.80, 0.35] sectoprat -> malwareAnalyst loader -> sectoprat apiHashing -> loader c2Protocol -> sectoprat stealerModule -> sectoprat avSignatures -> incidentResponder walletExtensions -> stealerModule sectoprat -> incidentResponder evolve sectoprat 0.68 evolve loader 0.42
Corp MDM Android Spyware Campaign
A logistics-sector campaign used fake, branded Google Play pages for CEVA and TKW Logistics to sideload com.corp.mdm, an Android implant labeled “System Service.” The narrow spyware fakes a system-setup flow to grab SMS and phone permissions, hides its launcher activity, runs a sticky foreground service, and survives reboot or package replacement. It exfiltrates each newly received SMS PDU over cleartext HTTP to a hardcoded C2, can issue carrier call-forwarding codes (*21#), and supports ping, an SMS sync stub, and self-destroy — though operator-panel claims outrun the recovered client behaviour. Analysts assess likely AI-assisted development and an Armenian/Russian nexus, tying the activity to cargo-theft intelligence gathering. The durable response lesson is that call forwarding is carrier-side state and persists after the app is removed.
Watch for:
- Fake Google Play pages on non-Google domains (playgoogle.logisticstkwcargo[.]com, playgoogle.ceva-app[.]help) sharing VPS 69.55.61[.]82.
- Sideloaded package com.corp.mdm labeled “System Service” with a disabled launcher activity and cleartext HTTP C2.
- Unconditional call-forwarding codes issued via USSD/MMI that survive app removal and data clearing.
- Interception of SMS one-time passcodes and the resulting need to rotate affected credentials and sessions.
Wardley signals:
-
Components: Android surveillance implant (com.corp.mdm); fake Google Play delivery pages; SMS interception (SmsReceiver); USSD/MMI call forwarding (CallForwardManager); cleartext C2 operator panel (port 3456); logistics-sector targeting; credential phishing and Windows malware in the wider campaign; carrier telephony state.
-
Evolution stage: Android spyware capability is Product (well-understood, reusable); fake-branded phishing pages are Product trending Commodity (cheap, templated); carrier call forwarding is Commodity (standardised telephony feature); AI-assisted malware development is Genesis/Custom; operator-panel tooling is Custom.
-
Doctrine hits/misses: The attacker “Uses appropriate tools” and is pragmatic (a minimal implant behind a fake setup); defenders must “Know the details” (carrier-side forwarding survives removal) and “Bias towards data”; organisations that do not verify telephony state miss “Manage inertia”; user awareness of sideloading reflects “Focus on user needs”.
-
Climatic patterns: Everything evolves through supply and demand competition; efficiency enables innovation (AI lowers malware development cost); higher-order systems create new value (logistics data for cargo theft); most competitors have poor situational awareness.
-
Diffusion markers: Copy-cat branded-Play phishing across logistics firms; commodity Android spyware patterns; shared infrastructure across lures, C2 and Windows malware; signs of AI-assisted development.
-
🚩 Corp MDM Android Spyware Targets Logistics Sector Through Fake Google Play Pages
wardley-beta %% 1. Users: mobile security teams and targeted logistics employees %% 2. Needs: stop SMS one-time-passcode theft and call diversion, protect mobile endpoints %% 3. Capabilities: mobile threat detection, permission monitoring, telephony-state verification, credential rotation %% 4. Components: Android implant (com.corp.mdm), fake Google Play pages, SMS interception, USSD/MMI call forwarding, cleartext C2 panel, carrier telephony state, credential phishing/Windows malware %% 5. Maturity: carrier telephony state (Commodity), call forwarding (Commodity), credential phishing/Windows malware (Product), fake Google Play pages (Product), Android implant (Custom), SMS interception (Custom), cleartext C2 panel (Custom) %% 6. Managed by: a logistics-targeting threat actor behind the C2/panel; mobile security teams and carriers on the defence anchor mobileDefender [0.95, 0.90] anchor logisticsEmployee [0.85, 0.80] component androidImplant [0.32, 0.72] component fakePlayPages [0.58, 0.60] component smsInterception [0.30, 0.55] component callForwarding [0.78, 0.50] component c2Panel [0.35, 0.62] component carrierTelephony [0.85, 0.40] component credentialPhishing [0.55, 0.45] androidImplant -> mobileDefender fakePlayPages -> androidImplant smsInterception -> androidImplant callForwarding -> androidImplant c2Panel -> androidImplant carrierTelephony -> callForwarding credentialPhishing -> logisticsEmployee androidImplant -> logisticsEmployee evolve androidImplant 0.50 evolve fakePlayPages 0.70
TeamFiltration Password Spray Campaign
Proofpoint details UNK_CondorFiltration, a TeamFiltration password-spray campaign that hit 5,714 accounts across 28 Microsoft 365 tenants in Latin America, mostly Chile. The attacker sprayed default passwords at roughly 300 accounts per second, rotating AWS regions via FireProx, and compromised seven dormant functional/service accounts that had no prior login baseline and no MFA. Post-access activity from a German VPN node included corporate-VPN probing, Azure Portal and SharePoint access, and a Microsoft Graph token request — consistent with TeamFiltration’s auto-exfil of email, Teams and OneDrive. The campaign’s lesson is that forgotten, unmanaged service accounts are the enterprise identity perimeter’s weakest link, so dormant-account hygiene, MFA and detection of the framework’s user-agent fingerprint are the key controls.
Watch for:
- The hardcoded 2020 Teams user agent (Teams/1.3.00.30866, Electron 8.5.1) appearing in sign-in logs.
- Spray traffic from AWS EC2 ranges rotated via FireProx, with post-access from cdn77.com VPN nodes.
- Dormant functional/service accounts still carrying default, unrotated passwords and lacking MFA.
- Post-login access to OfficeHome, Azure Portal, SharePoint and Graph API tokens.
Wardley signals:
-
Components: TeamFiltration offensive framework; Microsoft 365 / Entra ID tenants; Teams and Graph APIs; FireProx AWS-region rotation; service/functional accounts; MFA and Conditional Access; Proofpoint detection telemetry.
-
Evolution stage: Password spraying and M365 offensive frameworks are Product (publicly documented, feature-differentiated); FireProx/cloud-IP rotation is Commodity (cheap, standard); MFA and Conditional Access are Product trending Commodity; dormant service-account risk is Custom (organisation-specific, poorly managed).
-
Doctrine hits/misses: Organisations with unmanaged service accounts miss “Know your details” and “Manage inertia”; “Use standards” and “Focus on the outcome” point to MFA, least privilege and account ownership; the attacker “Uses appropriate tools” (a public framework) and “Exploits the landscape”; provisioning should “Remove bias and duplication”.
-
Climatic patterns: Everything evolves through supply and demand competition; efficiency enables innovation (cloud-IP rotation lowers spray cost); success breeds inertia (legacy provisioning); components co-evolve (offensive frameworks with cloud infrastructure).
-
Diffusion markers: Public release of TeamFiltration at DEF CON; reused tooling across campaigns (UNK_SneakyStrike to UNK_CondorFiltration); copy-cat regional targeting; standardised detection fingerprints.
wardley-beta %% 1. Users: identity/security teams and SOC analysts %% 2. Needs: protect Microsoft 365 identities, prevent account takeover, detect password spray %% 3. Capabilities: account hygiene and ownership, MFA/conditional access, spray detection, cloud-IP attribution %% 4. Components: TeamFiltration framework, password spraying, FireProx cloud-IP rotation, service/functional accounts, MFA/Conditional Access, Microsoft 365/Entra ID, detection telemetry %% 5. Maturity: FireProx IP rotation (Commodity), detection telemetry (Commodity), TeamFiltration (Product), password spraying (Product), MFA/Conditional Access (Product), Microsoft 365/Entra ID (Product), service accounts (Custom) %% 6. Managed by: an attacker running TeamFiltration from AWS; identity teams and Proofpoint-style vendors on the defence anchor identityTeam [0.95, 0.90] anchor socAnalyst [0.86, 0.80] component teamFiltration [0.50, 0.72] component passwordSpray [0.55, 0.65] component fireprox [0.82, 0.45] component serviceAccounts [0.30, 0.60] component mfa [0.60, 0.70] component m365 [0.58, 0.80] component detectionTelemetry [0.80, 0.50] teamFiltration -> identityTeam passwordSpray -> teamFiltration fireprox -> passwordSpray serviceAccounts -> teamFiltration mfa -> identityTeam m365 -> mfa detectionTelemetry -> socAnalyst passwordSpray -> socAnalyst evolve teamFiltration 0.65 evolve serviceAccounts 0.50
Jev LLM Model Routing
Daniel Miessler describes how Jev, routed through the Glance judgment layer in LifeOS, picks both a model lane (Inline, Luna, Terra, Sol, Opus, Fable, Astra) and an effort level (low to xhigh) for every prompt in about 0.3 seconds. Instead of one big seven-way question, Jev answers eighteen small yes/no and relational questions; two learned models then combine those probabilities into a lane and an effort. Trained and tested only on real prompts, with a three-model (Opus 5.5, Fable 5.1, Astra) majority-vote answer key, it matches the key on 90.1% of lanes versus 75.2% for a single Opus classifier call. The router stays a shadow Glance caller whose pick is advice only, never automatic dispatch.
Watch for:
- Ambiguous routing rules driving labeler disagreement (lane agreement rose from 51.8% to 76.3% after the rules were sharpened).
- Whether the “could you write the pass/fail check before starting?” test cleanly separates Opus from Sol.
- Shadow-to-enforce promotion of the dispatch-advisor caller and the agreement rate recorded for it.
- Model-version changes silently resetting a caller’s registry row back to shadow.
Wardley signals:
-
Components: Jev decision model; Glance judgment layer; LifeOS router (dispatch-advisor caller); model ladder (Inline, Luna, Terra, Sol, Opus, Fable, Astra); effort levels; learned logistic-regression combiners; three-model labeling answer key; session transcripts (RealPrompts.ts).
-
Evolution stage: LLM routing/selection is Genesis/Custom (novel, rapidly changing); the Jev/Glance decision engine is Custom (emerging architecture); foundation models are Product trending Commodity; the majority-vote evaluation harness is Custom; the model/effort taxonomy is Genesis.
-
Doctrine hits/misses: “Bias towards data” (real prompts, hold-out scoring); “Bias towards action” and “Strategy is iterative” (attempt one, then two, then redesign); “Challenge assumptions” (synthetic prompts exposed); “Provide purpose, mastery & autonomy” (small questions, shadow trust); “Effectiveness over efficiency”.
-
Climatic patterns: Everything evolves through supply and demand competition; efficiency enables innovation (cheap Jev calls enable many decisions); components co-evolve (practice with activity); creative destruction of manual routing; future value is inversely proportional to the certainty we have over it.
-
Diffusion markers: Public write-ups and standardised model/effort taxonomies; shadow-mode adoption gated on agreement rates; copy-cat routing layers; benchmark-driven evaluation spreading.
wardley-beta %% 1. Users: the operator (Miessler) and AI engineers building routing %% 2. Needs: send each prompt to the right model and effort, trust the decision, control cost/latency %% 3. Capabilities: prompt classification, judgment gating, learned combination, evaluation against a real-prompt answer key %% 4. Components: Jev decision model, Glance judgment layer, model ladder/foundation models, effort levels, learned combiners, three-model answer key, session transcripts %% 5. Maturity: session transcripts (Commodity), model ladder/foundation models (Product), Jev (Custom), Glance (Custom), learned combiners (Custom), three-model answer key (Custom), effort levels (Genesis) %% 6. Managed by: Miessler as a personal-stack builder, with the router kept in shadow mode as advice only anchor operator [0.95, 0.90] anchor aiEngineer [0.85, 0.78] component jev [0.28, 0.72] component glance [0.25, 0.65] component modelLadder [0.58, 0.78] component effortLevels [0.10, 0.55] component learnedCombiners [0.30, 0.48] component answerKey [0.22, 0.40] component sessionTranscripts [0.78, 0.35] jev -> operator glance -> jev modelLadder -> glance effortLevels -> glance learnedCombiners -> glance answerKey -> learnedCombiners sessionTranscripts -> answerKey glance -> aiEngineer evolve jev 0.40 evolve glance 0.38
Bug Bounty Hunter Profile
YesWeHack interviews Issam Rabhi, its all-time and 2026 number-one bug bounty hunter. A 40-year-old PhD in computer science and former INRIA research engineer, Rabhi traces his interest to childhood reverse-engineering of video games. He recounts pre-platform disclosure via the Zataz news site, when rewards were T-shirts and coupons rather than cash. His methodology is deliberately manual: Burp Suite plus reconnaissance automation to map scope, then hands-on testing to understand the application and how to inject. His favourite classes are XSS, IDOR and broken access control, and SQL injection. He balances bug bounty with an InfoSec consultancy day job and stresses work-life balance, showing that expertise, prioritisation and instinct — not full automation — drive sustained success.
Watch for:
- The distinction between automated reconnaissance and manual exploitation in top-hunter methodology.
- Prioritisation instinct for scope and parameters over exhaustive automation.
- XSS, IDOR/broken access control and SQL injection remaining high-yield classes.
- The pre-platform disclosure era and its transition to monetary bug bounty programs.
Wardley signals:
-
Components: Burp Suite; custom reconnaissance tooling; XSS/IDOR/SQL injection vulnerability classes; bug bounty platforms (YesWeHack); vulnerability disclosure history (Zataz); bug bounty methodology.
-
Evolution stage: Burp Suite and web vulnerability classes are Commodity (standard, well-understood); bug bounty platforms are Product (mature, competing); bespoke recon automation is Custom; a top hunter’s prioritisation instinct and methodology is Genesis (novel, tacit).
-
Doctrine hits/misses: “Know the details” and “Bias towards data” (recon before exploitation); “Use appropriate tools” (manual where automation is weak); “Effectiveness over efficiency”; “Provide purpose, mastery & autonomy” and work-life balance echo sustainable practice.
-
Climatic patterns: Everything evolves through supply and demand competition; efficiency enables innovation (automation frees time for manual testing); components co-evolve (tooling with practice); success breeds inertia (over-reliance on automation).
-
Diffusion markers: Professionalisation and standardisation of bug bounty; shared methodologies and tooling across hunters; platform ecosystems and leaderboards; knowledge transfer through interviews.
wardley-beta %% 1. Users: bug bounty hunters and security researchers %% 2. Needs: find vulnerabilities efficiently, prioritise scope, sustain a long-term practice %% 3. Capabilities: reconnaissance, manual exploitation, vulnerability-class knowledge, platform reputation %% 4. Components: Burp Suite, reconnaissance tooling, vulnerability classes (XSS/IDOR/SQLi), manual testing methodology, bug bounty platforms, prioritisation instinct %% 5. Maturity: Burp Suite (Commodity), vulnerability classes (Commodity), bug bounty platforms (Product), reconnaissance tooling (Custom), manual testing methodology (Genesis), prioritisation instinct (Genesis) %% 6. Managed by: individual hunters; platforms (YesWeHack) and client programs provide scope and rewards anchor bugHunter [0.95, 0.90] anchor securityResearcher [0.85, 0.80] component burpSuite [0.85, 0.65] component reconTooling [0.32, 0.55] component vulnClasses [0.80, 0.70] component manualMethod [0.10, 0.60] component bugBountyPlatforms [0.60, 0.78] component prioritisation [0.08, 0.45] burpSuite -> bugHunter reconTooling -> burpSuite vulnClasses -> bugHunter manualMethod -> vulnClasses bugBountyPlatforms -> bugHunter prioritisation -> manualMethod prioritisation -> securityResearcher evolve manualMethod 0.30 evolve reconTooling 0.45