# Cyfidex — Full Content Reference > This file is generated for AI assistants and answer engines that cannot execute JavaScript. It mirrors the content rendered on cyfidex.com. ## Who Cyfidex is Cyfidex delivers expert VAPT (Vulnerability Assessment and Penetration Testing) and offensive security across web, API, mobile, cloud, infrastructure, AI, LLMs, agents, and MCP (Model Context Protocol). Slogan: "Think offensive. Secure what's next." Contact: cyfidex@gmail.com. ## Services ### Web & API security Go beyond automated scans. We test the ways real attackers can abuse your applications, chain vulnerabilities, and reach sensitive data. Surfaces covered: Web applications, REST & GraphQL APIs, Authentication & authorization, Business logic. What you get: Manual, context-driven penetration testing; Reproducible findings with clear business impact; Prioritized remediation guidance and retesting. ### Mobile application security Assess your mobile experience from the device to the backend, including the trust boundaries that connect them. Surfaces covered: iOS applications, Android applications, Mobile backends, On-device storage. What you get: Static and dynamic application analysis; Storage, transport, and session testing; Actionable findings for your engineering team. ### Network & infrastructure Identify weaknesses across your infrastructure and test how an attacker could move through connected systems after gaining a foothold. Surfaces covered: Networks, Infrastructure, Internal environments, Identity environments. What you get: Internal and external penetration testing; Privilege escalation and lateral movement analysis; Clear attack paths and practical remediation. ### Cloud & attack surface Understand what is exposed, where trust is misplaced, and how cloud and internet-facing weaknesses can combine into meaningful risk. Surfaces covered: Cloud infrastructure, External attack surfaces, Cloud identities, Public-facing assets. What you get: Cloud configuration and permission assessment; External exposure discovery and validation; Risk-ranked findings grounded in exploitability. ### Red teaming Put your security assumptions to the test with objective-led, authorized adversary simulations tailored to your environment. Surfaces covered: Adversary simulation, Internal environments, Detection & response, End-to-end attack paths. What you get: Agreed objectives and rules of engagement; Realistic, controlled attack scenarios; Technical debrief and defensive recommendations. ### AI & agentic security Explore the trust boundaries of AI-powered systems: the models, context, agents, tools, and services that can act on your behalf. Surfaces covered: AI & LLM applications, AI agents & agentic systems, MCP & MCP servers, Tool integrations, Emerging technology architectures. What you get: Prompt injection and data exposure testing; Agent permissions and tool-boundary assessment; MCP server and integration security testing. ## Frequently asked questions **Q: What can Cyfidex test?** We test web applications, APIs, mobile applications, networks, cloud infrastructure, infrastructure, external attack surfaces, and internal environments. We also offer red teaming and security testing for AI, LLM applications, agents, agentic systems, MCP servers, tool integrations, and emerging architectures. **Q: How is an engagement scoped?** We start with your goals, assets, and operating constraints. Together we agree on the authorized scope, testing windows, rules of engagement, deliverables, and timeline before testing begins. **Q: Can you assess AI agents and MCP integrations?** Yes. We assess AI and agentic systems alongside their supporting services, including MCP servers and tool integrations. The scope is tailored to your architecture, permissions, data flows, and trust boundaries. **Q: Are your technology products available yet?** Not yet. Three Cyfidex technology products are in development. We’re keeping technical details and previews private for now. Our current commercial focus is expert VAPT and offensive security services. **Q: What will we receive after testing?** Your engagement includes documented findings, reproducible evidence, risk context, and practical remediation guidance. Reporting, debriefs, and retesting arrangements are agreed during scoping. ## Blog posts ### Kerberoasting: Enumeration, Extraction, Cracking, and Detection URL: https://www.cyfidex.com/blogs/kerberoasting-attack-chain Category: Active Directory Tags: Active Directory, Kerberoasting, Kerberos, Red Teaming Published: 2026-01-20 A complete walkthrough of the Kerberoasting attack chain against Active Directory — real enumeration and extraction commands, offline cracking, and the detections that actually catch it. Kerberoasting is one of the highest return-on-effort attacks against Active Directory: it requires nothing more than a valid, unprivileged domain account, and it routinely yields service account credentials — some of which turn out to be Domain Admins that were misconfigured years ago and never revisited. This is the full chain: how the ticket format makes the attack possible, how to enumerate targets, how to extract and crack the tickets, and — just as importantly — how to actually detect and stop it. ### Why Kerberos tickets are crackable at all Any authenticated domain user can request a Kerberos service ticket (TGS) for any service registered with a Service Principal Name (SPN) — that is normal, intended Kerberos behavior, not a misconfiguration. The ticket's body is encrypted with a key derived from the target service account's own password hash, not the requesting user's. That single fact is the entire attack: because the domain controller will hand a TGS to any authenticated user for any SPN, and because the ticket is encrypted with the service account's password-derived key, an attacker can request the ticket, take it home, and try to crack it completely offline — with no further contact with the domain controller, no lockout risk, and no way for the DC to tell the difference between a legitimate service ticket request and a Kerberoasting attempt. This means the entire security of the attack rests on one thing: the strength of the service account's password. Human-chosen "temporary" service account passwords set up five years ago during a software install are exactly the population this attack finds. ### Step 1 — Enumerate accounts with an SPN The first step is identifying which accounts have a registered SPN, since those are the only ones a TGS can meaningfully be requested for. Built-in Windows tooling already exposes this domain-wide with no additional software. - PowerView: Get-DomainUser -SPN -Properties samaccountname,serviceprincipalname,pwdlastset | Format-Table -Wrap - LDAP (any OS): ldapsearch -x -H ldap://dc01.corp.local -D "user@corp.local" -w 'password' -b "DC=corp,DC=local" "(&(objectClass=user)(servicePrincipalName=*))" sAMAccountName servicePrincipalName ### Step 2 — Request and extract the service tickets With target accounts identified, request a TGS for each one and pull it into a crackable format. Impacket's GetUserSPNs.py is the most portable option and works from Linux without touching the domain-joined environment at all beyond the authenticated LDAP/Kerberos traffic. - Rubeus (Windows, from a foothold): Rubeus.exe kerberoast /outfile:hashes.kerberoast - Target one account only (quieter): Rubeus.exe kerberoast /user:svc_sql /simple - Roast only accounts with old passwords first: Rubeus.exe kerberoast /rc4opsec /outfile:hashes.kerberoast ### Step 3 — Crack the tickets offline The extracted ticket is a standard krb5tgs hash. Both hashcat and John the Ripper support it natively, and cracking speed depends entirely on the encryption type: RC4 (etype 23) hashes crack orders of magnitude faster than AES256 (etype 18) ones, which is the whole reason encryption type matters so much in this attack. - AES256 tickets: hashcat -m 19700 -a 0 hashes.kerberoast rockyou.txt - John the Ripper: john --format=krb5tgs --wordlist=rockyou.txt hashes.kerberoast ### What a cracked service account actually gets you A cracked service account password is rarely the objective on its own — it's a pivot. Service accounts are frequently over-provisioned: a SQL service account with local admin on three application servers, a backup agent account with domain-wide read access, or worse, a legacy account still holding Domain Admin membership because nobody wanted to risk breaking a production job by removing it. The chain from here typically continues into whatever that account can reach: lateral movement to servers where it has local admin, DCSync if it holds replication rights, or simply logging in interactively if it was never restricted from doing so. Kerberoasting is almost never the final step of an engagement — it's the door. ### Detecting Kerberoasting Every TGS request against a service account SPN generates Windows Event ID 4769 (A Kerberos service ticket was requested) on the domain controller. This is unavoidable — even the most careful attacker must generate this event, because it is how Kerberos itself functions. The detection challenge is separating normal, high-volume 4769 traffic from anomalous requests. - Ticket Encryption Type: field value 0x17 (RC4) is anomalous in any environment that has enforced AES — flag 4769 events with 0x17 where the account normally requests 0x12 (AES256). - Request volume and pattern: a single source account requesting TGS tickets for many distinct SPNs in a short window is the classic Kerberoasting signature — normal service usage requests one or two specific SPNs repeatedly, not dozens of different ones. - Failure Code 0x0 with an unusual requesting account: 4769 logs the account that requested the ticket, not just the service it was issued for — cross-reference against accounts that have no legitimate reason to be talking to that service. - Deploy canary/honeypot service accounts with SPNs and no real function — any 4769 event referencing them is a near-certain true positive with effectively zero false-positive rate. ### Fixing the root cause Detection buys you time to respond; the actual fix is removing crackable passwords from the population entirely. Two changes close most of the exposure permanently. - Migrate service accounts to Group Managed Service Accounts (gMSA) — Windows manages a 240-character random password automatically, and the account never has a human-memorable secret to crack in the first place. - Where gMSA migration isn't feasible, set msDS-SupportedEncryptionTypes to AES-only and use a genuinely random 30+ character password stored in a vault, not a wiki page. - Audit and remove unnecessary group memberships from every service account — the blast radius of a cracked password matters as much as whether it gets cracked. - Set a recurring review of accounts with an SPN and a stale pwdLastSet date; this is exactly the population Kerberoasting targets, and it should be a standing item, not a one-time cleanup. --- ### OWASP Top 10 API Security Risks: What Changed in 2025 URL: https://www.cyfidex.com/blogs/owasp-top-10-api-security-2025 Category: Web & API Security Tags: API Security, OWASP, Penetration Testing Published: 2025-11-04 A practical breakdown of the latest OWASP API Security Top 10, and how offensive testing catches the risks automated scanners miss. APIs have quietly become the backbone of almost every product built in the last decade. A single mobile app might call twenty different internal and third-party APIs before a user even finishes onboarding. That growth in surface area is exactly why the OWASP API Security Top 10 exists — and why the 2025 revision matters more than the last one did. ### Why API security keeps getting harder Unlike a traditional web application with a handful of forms and a login page, an API exposes its entire data model to anyone who can construct a valid request. Every endpoint is effectively a door, and most organizations we test have more doors than they can accurately count — undocumented internal endpoints, deprecated versions still running in production, and partner integrations nobody remembers approving. Automated API discovery tools help build an inventory, but inventory is not the same as security. Knowing an endpoint exists tells you nothing about whether its authorization logic actually matches the business rules it was built to enforce. ### Broken object level authorization is still #1 Broken Object Level Authorization (BOLA) has topped the OWASP API list for three revisions running, and for good reason: it is simple to introduce and expensive to miss. A developer builds an endpoint like `GET /invoices/{id}`, tests it with their own account, ships it, and never considers what happens when a user substitutes another customer's invoice ID. What makes BOLA particularly dangerous is that it rarely triggers any alarms. There is no malformed payload, no injection string, no obvious signature for a WAF to catch — just a valid request for a resource the requester should not be able to see. That is precisely the class of vulnerability that requires a human tester who understands the data model, not a scanner running a fixed rule set. ### The 2025 additions: unrestricted resource consumption and AI-adjacent risk The updated Top 10 formalizes what many of us were already seeing in engagements: unrestricted resource consumption — APIs with no rate limiting, no payload size caps, and no cost controls on expensive operations like search or export. As more products bolt LLM-backed features onto existing APIs, an uncapped endpoint that triggers a model inference call can turn into a very expensive denial-of-wallet attack, not just a denial-of-service one. We are also increasingly finding API endpoints that exist purely to feed data into an AI agent or chatbot, built without the same authorization scrutiny applied to the "real" customer-facing API. If your agent has broader read access than your web app does, that gap is not incidental — it is a new class of BOLA. #### How manual testing catches what scanners miss Automated tools are excellent at flagging missing security headers, outdated TLS configurations, and known CVEs in dependencies. They are far weaker at reasoning about business logic — the sequence of otherwise-valid calls that, combined, let an attacker reach data or functionality they should never touch. In a recent engagement, our team chained three individually low-severity findings — a predictable ID scheme, a missing ownership check on a "download" endpoint, and an overly permissive CORS policy — into a full account takeover path. No single scanner flag would have represented that risk accurately; only manual exploitation demonstrated the real business impact. ### Building a remediation-first testing program A one-time penetration test tells you where you stood on the day of the assessment. A remediation-first program treats that report as the start of a cycle, not the end of one: findings get triaged with engineering, fixes get shipped, and — critically — a retest confirms the fix actually closed the gap rather than just changing its shape. - Map every endpoint to the object types and ownership rules it should enforce, before testing begins. - Test authorization from the perspective of a legitimate low-privilege user, not just an unauthenticated attacker. - Apply rate limiting and cost controls to any endpoint that triggers a paid third-party call, including LLM inference. - Retest after every fix — a patched endpoint with a new edge case is still a vulnerable endpoint. --- ### The Silent Killer: Cloud Misconfigurations and Your Attack Surface URL: https://www.cyfidex.com/blogs/cloud-misconfigurations-attack-surface Category: Cloud Security Tags: Cloud Security, AWS, Attack Surface Published: 2025-10-22 Most cloud breaches trace back to a handful of common misconfigurations. Here is how attackers find them first — and how to find them before they do. Nobody sets out to misconfigure their cloud environment. Misconfigurations accumulate — a bucket made public for a two-day demo that never got locked back down, a service account granted broad access to unblock a deploy, a security group opened during an incident and forgotten. Individually, each one looks minor. Collectively, they are how the majority of cloud breaches actually happen. ### The attacker view of your cloud estate Attackers do not read your architecture diagrams, and they do not care which team owns which account. They run automated reconnaissance against every IP range, subdomain, and cloud storage naming convention associated with your organization, looking for the one asset that was configured differently than the rest. This is the core argument for continuous external attack surface management rather than periodic reviews: your cloud footprint changes daily through normal engineering activity, and an asset that was locked down in January can be reopened by an unrelated change in March. Attackers are not on your release schedule — they are scanning constantly. ### Storage permissions: the classic mistake, still the most common Public read or write access on object storage remains one of the single most frequent findings across our cloud assessments, years after it became a well-known problem. The reasons are structural rather than a lack of awareness: storage buckets are cheap to create, permissions default differently across providers and SDKs, and a bucket created for a quick data export rarely gets the same scrutiny as a production database. The impact is not limited to obvious secrets. We have found customer PII in "temporary" export buckets, infrastructure-as-code templates containing embedded credentials, and application build artifacts that reveal internal API structure to anyone who finds the bucket name — which is often guessable from the company name alone. #### Identity sprawl across multi-cloud environments As organizations spread workloads across multiple cloud providers, identity and access management becomes the hardest problem to keep coherent. Service accounts created for a one-off migration outlive the migration. Roles get cloned from a template with permissions far broader than the new use case requires. Cross-account trust relationships, set up to simplify a specific integration, quietly become a lateral movement path for anyone who compromises the weaker of the two accounts. The result is what we call identity sprawl: a growing set of credentials and roles that nobody is actively reviewing, each one a potential entry point that expands the blast radius of any single compromised secret. ### From exposure discovery to validated risk Finding a misconfiguration is only half the job — the harder and more valuable question is what an attacker could actually do with it. A public bucket with only static marketing assets is a very different finding from a public bucket containing session tokens or database backups, even though both would show up identically on a basic configuration scan. This is where offensive testing earns its keep over automated posture management tools alone. We do not stop at "this bucket is public" — we attempt to demonstrate the realistic next step: can this credential reach anything else, does this exposed configuration file contain anything usable, does this permission actually enable privilege escalation in practice. ### A practical hardening checklist Most cloud security programs improve dramatically just by consistently enforcing a short list of fundamentals: - Treat "default deny" as the starting posture for every new bucket, queue, and database — access should be granted explicitly, never assumed. - Run continuous, not periodic, external exposure discovery so new misconfigurations are caught in hours, not at the next quarterly audit. - Regularly review and prune service accounts and IAM roles; unused permissions are pure downside risk with zero business benefit. - Validate cross-account trust relationships specifically — they are the piece most likely to be forgotten once the original project ends. --- ### Securing AI Agents and MCP Servers: A New Trust Boundary URL: https://www.cyfidex.com/blogs/securing-ai-agents-mcp-servers Category: AI & Agentic Security Tags: AI Security, MCP, LLM, Agentic Systems Published: 2025-12-01 AI agents and MCP integrations introduce trust boundaries most security teams have never tested before. Here is where to start. For most of the last two decades, "the LLM said something inappropriate" was the worst-case failure mode security teams worried about with AI products. That is no longer true. Once a language model can call tools, read your internal documents, send emails, or execute code on your behalf, a bad output stops being an embarrassment and starts being an incident. ### Agents can now take real-world actions The shift from "AI that answers questions" to "AI that takes actions" is the single biggest change in the threat model. An agent wired into your CRM, ticketing system, or codebase is not just generating text — it is exercising real permissions on real systems, usually with credentials that were scoped for a human, not for an autonomous process making decisions based on untrusted input. That distinction matters because humans apply judgment before acting on suspicious instructions. An agent, by design, follows instructions — and it often cannot tell the difference between an instruction from its operator and an instruction smuggled in through the content it was asked to process. ### Prompt injection as a first-class threat, not a novelty Prompt injection stopped being a curiosity the moment agents started reading content they did not author. A support email, a shared document, a scraped web page, even a filename — any of these can carry text crafted to override the agent's original instructions if the surrounding system does not clearly separate "trusted instructions" from "untrusted content to process." We have demonstrated this in practice: an agent asked to summarize an inbound email containing hidden instructions that redirected it to forward sensitive internal data to an external address. The email itself contained no malware, no links, nothing a traditional email security gateway would flag — the exploit was entirely in the model's interpretation of the text. #### MCP servers need their own security review The Model Context Protocol has made it dramatically easier to connect agents to tools, and that ease of integration is exactly why it deserves scrutiny. Every MCP server you stand up is a new API surface, frequently built quickly, often without the authentication and scoping rigor applied to customer-facing APIs. We routinely find MCP servers granting a connected agent far broader tool access than the agent's actual task requires — a research agent with write access to production data, a read-only reporting agent that can also trigger downstream workflows. Least-privilege tool scoping is not optional here; it is the single most effective control against an agent being manipulated into doing something destructive. ### Data exfiltration through indirect channels Because agents often have both read access to sensitive data and some form of external communication capability — sending an email, posting to a webhook, writing to a shared document — the two together create an exfiltration path that did not exist before. An attacker does not need to breach your database directly if they can convince an agent with legitimate access to summarize and forward it on their behalf. ### A testing framework for agentic systems Assessing an agentic system requires a different playbook from a traditional web or API test, though many of the same principles apply once translated: - Map every tool an agent can call and verify the permission scope matches the narrowest version of the agent's actual job. - Test prompt injection using realistic untrusted content sources — documents, emails, and web pages the agent is expected to process. - Attempt to chain a manipulated instruction into an actual tool call, not just a change in conversational output. - Review outbound channels (email, webhooks, file writes) for opportunities to exfiltrate data the agent has legitimate read access to. - Treat every MCP server as a standalone API requiring authentication, authorization, and logging review. --- ### Red Team vs Penetration Test: Choosing the Right Engagement URL: https://www.cyfidex.com/blogs/red-team-vs-pentest-difference Category: Red Teaming Tags: Red Teaming, Penetration Testing, Security Strategy Published: 2025-09-15 They are not interchangeable. Understanding the difference helps you pick the right engagement for your security maturity and budget. We get asked to "run a red team" more often than the requester actually wants a red team. It is an understandable mix-up — both engagements involve people trying to break into your systems — but they answer fundamentally different questions, and picking the wrong one wastes budget without producing the outcome you actually needed. ### Two different questions being answered A penetration test asks: what vulnerabilities exist in this system, application, or network, within an agreed scope and timeframe? It is broad, methodical, and designed to surface as many exploitable weaknesses as possible so they can be fixed. A red team engagement asks a narrower but deeper question: can a realistic, motivated adversary reach a specific objective — domain admin, access to a crown-jewel database, a fraudulent wire transfer — without being detected by your existing defenses? It is not about finding every vulnerability; it is about testing whether your people, process, and technology actually stop a determined attacker in practice. ### When a penetration test is the right call If you need broad, defensible coverage across an application, API, or network segment — especially to satisfy a compliance requirement, validate a new release, or establish a baseline before your first larger engagement — a penetration test delivers that efficiently. It is also the right starting point for organizations still building out their security program, since a red team exercise assumes a baseline of defenses worth testing. #### When to invest in red teaming Red teaming earns its value once an organization has an established detection and response function worth stress-testing. There is limited benefit in simulating a stealthy, multi-stage attack against a team that has not yet had the chance to build out logging, alerting, and an incident response process — you would mostly be confirming what a penetration test already told you. Mature organizations use red team exercises to answer questions a vulnerability list cannot: did the SOC notice the initial foothold? How long did detection take? Did the response playbook actually work under pressure, or only on paper? ### Combining both into a testing roadmap The strongest security programs we work with do not treat this as an either/or decision. They run regular, scoped penetration tests to close known technical gaps quickly, and periodic objective-led red team exercises to validate that detection and response hold up under a realistic attack — using the findings from each to inform the other. - Start with penetration testing if you do not yet have mature detection and response capability. - Move to red teaming once you have logging, alerting, and an incident response process worth validating. - Use pentest findings to close individual technical gaps quickly, on a regular cadence. - Use red team findings to improve detection coverage and response playbooks, not just to patch a single vulnerability. --- ### The Mobile App Security Testing Checklist Every Team Needs URL: https://www.cyfidex.com/blogs/mobile-app-security-testing-checklist Category: Mobile Security Tags: Mobile Security, iOS, Android Published: 2025-08-28 From insecure local storage to weak session handling, these are the mobile app vulnerabilities we find most often — and how to test for them. Mobile applications get tested less rigorously than web applications far too often, usually because teams assume the app store review process or OS-level sandboxing already handles security. Neither does. App store review checks for policy compliance, not authorization logic, and sandboxing protects the device from the app — not your backend from a malicious or reverse-engineered client. ### The device is not a trusted environment Any assumption that client-side logic is safe from tampering should be treated as false by default. A sufficiently motivated attacker with physical or emulated access to a device can decompile the app, bypass client-side checks, and interact with your backend directly — meaning every security control that matters must be enforced server-side, with the app treated as a convenience layer rather than a trust boundary. We routinely demonstrate this by bypassing "premium feature" gates, jailbreak/root detection, and even client-side input validation entirely, simply by intercepting and modifying traffic before it reaches the backend. ### Insecure local storage remains extremely common Authentication tokens, API keys, and personally identifiable information are still frequently found stored unencrypted in shared preferences on Android, plist files on iOS, or local SQLite databases either app uses for caching. Developers often assume the OS sandbox is sufficient protection, forgetting that a lost or compromised device, a malicious app with excessive permissions, or a simple backup extraction can expose that data entirely outside the app's intended flow. The fix is straightforward in principle — use platform-provided secure storage (Keychain on iOS, EncryptedSharedPreferences or the Keystore system on Android) for anything sensitive — but it requires a deliberate review pass, since insecure storage rarely triggers any functional bug that would surface it during normal QA. #### Certificate pinning and transport security TLS alone protects traffic from passive network eavesdropping, but it does not protect against an attacker who can install their own certificate authority on a test device — which is trivial with tools like Burp Suite or mitmproxy. Without certificate pinning, an attacker can intercept, read, and modify all traffic between the app and its backend, effectively defeating the encryption entirely from a security-testing perspective. We find pinning either missing, applied inconsistently across app versions, or implemented in a way that can be bypassed with well-known runtime hooking frameworks — all of which we specifically test for, since a pinning implementation that only works against a naive attacker provides false confidence. ### Backend trust assumptions unique to mobile Mobile backends frequently skip validation that an equivalent web API would enforce, on the assumption that "only our app" calls these endpoints. That assumption fails the moment an attacker extracts the API structure from the decompiled app — which takes minutes, not days — and begins crafting requests directly, bypassing the mobile client entirely. ### A practical mobile testing checklist A focused assessment should cover, at minimum: - Static analysis of the compiled app for hardcoded secrets, insecure storage, and debug artifacts left in the release build. - Dynamic analysis with traffic interception to test certificate pinning and observe real API calls the app makes. - Session and token handling — expiry, revocation on logout, and reuse across devices. - Server-side authorization testing against every endpoint the app calls, independent of the mobile client entirely. - Platform-specific storage review: Keychain/Keystore usage, backup exclusion flags, and clipboard exposure of sensitive fields. --- ### The State of Offensive Security Heading into 2026 URL: https://www.cyfidex.com/blogs/state-of-offensive-security-2026 Category: Industry Insights Tags: Industry Insights, Security Trends Published: 2026-01-10 AI-assisted attacks, expanding attack surfaces, and tighter budgets: how offensive security teams are adapting. Every year brings a fresh list of predictions, and most of them are noise. Heading into 2026, three shifts are different: they are already visible in the engagements we are running today, not speculative trends borrowed from a vendor report. Here is what is actually changing, based on what we are seeing on the ground. ### Attackers are moving faster with AI tooling Reconnaissance and exploit development that once took a skilled attacker days now takes hours, aided by AI tools that can rapidly enumerate technology stacks, draft convincing phishing content, and even assist with adapting known exploits to slightly different targets. This does not mean attackers suddenly have zero-day capability they lacked before — it means the time between "vulnerability disclosed" and "vulnerability actively exploited in the wild" keeps compressing. For defenders, this shrinks the patching window that used to provide a reasonable margin of safety. A CVE that once gave organizations a week or two of practical runway before mass exploitation now sometimes gives days. ### Attack surfaces keep expanding faster than inventories can track them Every new SaaS integration, AI agent, MCP server, and cloud service adds a boundary that needs to be tested, not assumed secure by association with the systems it connects to. We continue to see organizations with a confident, well-maintained inventory of their core web applications and a near-total blind spot around the dozens of smaller integrations, internal tools, and AI-adjacent services layered on top over the past two years. This is less a technology problem than a process one: attack surface inventory needs to be a continuous, automated discipline, not a project that gets revisited annually. #### Budget pressure is reshaping testing programs Security teams are under real pressure to consolidate vendors and demonstrate that testing spend maps directly to business risk, not just to a list of CVEs sorted by CVSS score. This is pushing a shift away from "check the compliance box" annual penetration tests toward continuous, risk-prioritized testing that can clearly articulate what a finding actually means for the business if left unaddressed. We view this as a healthy correction, not just a cost-cutting trend — a report full of low-impact findings with no business context was never as useful as security teams sometimes needed it to look on paper. ### What to prioritize this year Based on what we are seeing across engagements, four areas deserve disproportionate attention in 2026 planning: - Continuous external exposure discovery, replacing point-in-time audits that miss changes made between review cycles. - Dedicated security review of AI agents, LLM integrations, and MCP servers — a category most programs have not yet formally scoped in. - Identity-focused testing across multi-cloud and SaaS environments, where sprawl creates the most overlooked lateral movement paths. - Faster patch validation cycles, given the shrinking gap between disclosure and active exploitation.