• AI Agent Security Needs to Move to the Tool-Call Boundary

    AI agents are becoming useful for the same reason they are becoming risky: they can act. They can browse websites, read files, call APIs, search repositories, invoke MCP servers, use skill files, modify documents, and trigger workflows across external systems. That makes them very different from older chatbot deployments, where most risk stayed inside the response text.

    Once an agent can take action, prompt injection stops being a model-output problem and becomes an execution-control problem. A malicious instruction hidden in a webpage, document, tool result, MCP response, or skill file can influence what the agent does next. The attacker does not need to control the user’s prompt. The attacker only needs to control something the agent reads.

    That is the structural weakness behind indirect prompt injection. Tool-augmented agents often append tool outputs directly into the conversation history as observations, then ask the model to reason over that expanded context. If the returned content contains hostile instructions, the model may treat those instructions as part of the task. The ClawGuard research frames this as a tool-call boundary problem: each proposed action needs to be checked before it reaches the real environment.

    That framing is valuable for enterprise security teams. It moves the focus away from hoping the model refuses the wrong instruction and places the control where damage actually occurs: before a file is read, before data is sent, before a command runs, before an external endpoint receives traffic, and before a tool invocation changes state.


    Alignment Alone Is Too Soft for Agentic Workflows

    Model alignment can reduce obvious misuse, but it is a weak primary control for tool-connected agents. The model is interpreting a mixed stream of user intent, system guidance, retrieved content, tool returns, and prior observations. That context is messy by design. Agents are built to absorb external information and act on it.

    This creates a recurring problem: the model must distinguish data from instruction in situations where both are represented as natural language. A webpage can contain a legitimate paragraph and a hidden command. A document can contain business content and an adversarial instruction. An MCP server can return useful tool output mixed with manipulation. A skill file can contain both valid operational guidance and attacker-controlled behavior.

    OWASP describes prompt injection as crafted input that changes model behavior in unintended ways, including inputs that may not be visible to humans but are still parsed by the model. OWASP also calls out indirect prompt injection through external sources such as websites and files, with possible outcomes that include sensitive data disclosure, unauthorized access, arbitrary command execution, and manipulated decision-making.

    That maps cleanly to agent risk. The prompt is no longer just what the user typed. The prompt is the agent’s full working context, including anything its tools return. If a security control only asks whether the model “should” obey the injected instruction, it is arriving too late and relying on a probabilistic judgment.

    A safer design asks a different question: is the next tool call allowed under the user’s original task?


    The Tool-Call Boundary Is Where Intent Becomes Action

    The tool-call boundary is the point where the agent moves from reasoning to doing. Before that point, the model may be reading, planning, summarizing, or selecting a next step. After that point, the system may access a local file, contact a domain, execute code, send data, install a package, write a record, or trigger an external service.

    That boundary is easier to govern than the model’s full internal reasoning. Security teams do not need to solve every ambiguity in natural language to block a bad action. They need to evaluate concrete attributes of a proposed tool call: tool name, command string, file path, target domain, request payload, credential material, write destination, and expected data movement.

    This is the idea behind a runtime guard for agent activity. Instead of trusting every proposed action, the system places an enforcement layer between the model and the environment. The layer checks whether the action fits the active policy. If it clearly fits, it proceeds. If it violates policy, it is blocked. If it is ambiguous, it can be queued for explicit approval and logged.

    This approach changes the security model. A malicious webpage may still persuade the model to propose a dangerous command. The command still fails if the runtime policy blocks shell execution, credential file access, unapproved outbound domains, or destructive operations.

    The agent may be manipulable at the reasoning layer, but its actions become constrained at the execution layer.


    The Three Injection Paths Security Teams Need to Watch

    The same pattern appears across three major agent attack surfaces: external content, MCP servers, and skill files.

    External content injection is the most familiar. An agent retrieves a webpage, search result, PDF, internal document, or local file. The content includes hidden or direct instructions telling the model to ignore prior guidance, extract data, call another tool, or send information elsewhere. Since the content arrives as a tool result, the agent may process it as trusted context.

    MCP server injection expands that risk into the agent integration layer. MCP servers expose tools and return structured responses, but a malicious or compromised server can embed instructions in returned content. It can also poison tool metadata before the first tool call, steering tool selection or parameter use from inside the client’s discovery process. The official MCP security guidance lists attack areas such as confused deputy patterns, token passthrough, SSRF, local server compromise, OAuth validation issues, and scope minimization concerns, which shows how broad the MCP trust boundary has become.

    Skill file injection is different but just as dangerous. Skills are reusable capability modules that may include behavioral guidance, scripts, tool instructions, and configuration. Since skills are meant to tell the agent how to behave, malicious additions can blend into legitimate guidance. A poisoned skill does not have to look like an obvious attack. It can quietly redirect behavior inside a capability the user meant to enable.

    These paths share the same core issue. The agent absorbs untrusted content into its working context, then proposes actions based on that context. A runtime defense has to assume that some observations are hostile and still keep tool execution inside the user’s intended scope.


    Task Scope Should Be Defined Before the Agent Reads the Outside World

    One of the strongest ideas in the ClawGuard design is pre-session rule creation. Before any external tool is invoked, the agent derives a rule set from the user’s stated objective. That timing matters. The user’s original task is still clean. The agent has not yet retrieved a poisoned webpage, loaded a malicious server response, or parsed a contaminated skill file.

    A task such as “summarize the latest posts from this site and save the result in this folder” has a fairly narrow security shape. It may need web access to one domain, read access to returned content, and write access to one report path. It does not need access to SSH keys, browser profiles, cloud credential files, package installation, shell pipelines, private network ranges, paste sites, tunneling services, or unlisted external domains.

    A runtime policy can capture that distinction. The baseline rules deny known dangerous categories such as credential stores, irreversible filesystem operations, reverse shells, privilege changes, agent self-modification, suspicious exfiltration endpoints, and obfuscated command patterns. Task-specific rules then add the narrow set of domains, paths, and tools required for the user’s request. In the ClawGuard design, task-specific entries cannot override fixed safety rules.

    This is closer to least privilege than ordinary agent approval prompts. The agent does not receive broad authority and then rely on the user to catch abuse. It receives a scoped operating envelope before untrusted content reaches the model.


    Blocking the Action Is Better Than Parsing Every Injection

    Indirect prompt injection is hard to detect at the content layer. Attackers can use obfuscation, paraphrasing, multi-step instruction splitting, encoding, roleplay, hidden text, formatting tricks, or context-dependent wording. Some payloads are obvious, such as “ignore previous instructions.” Others may be embedded inside normal-looking task guidance.

    Trying to classify every tool result as safe or unsafe becomes brittle. A long webpage, skill file, or MCP response may contain thousands of tokens. The hostile instruction may be subtle. The model may assemble the unsafe behavior across multiple steps.

    The action boundary offers a cleaner point of control. A security layer does not need to fully understand why the model wants to run a command like reading a private key and sending it to an external domain. It only needs to see that the proposed action violates policy.

    The ClawGuard case study uses that exact pattern. A legitimate web-summary task retrieves a page containing injected commands to read an SSH private key, exfiltrate it through curl, and remove the SSH directory. The runtime check blocks the resulting exec call, rejects the credential file path, logs the denial, and still lets the legitimate report write proceed.

    That is the practical value of boundary enforcement. It does not require perfect model judgment. It limits the model’s ability to turn hostile context into real-world effects.


    Sanitization Reduces What the Model Can Carry Forward

    Runtime authorization controls whether an action can execute, but agents also need data hygiene. Sensitive values can leak through tool arguments, tool returns, conversation memory, logs, generated content, and follow-on requests.

    A content sanitizer can reduce that risk by redacting high-value secrets before they move through the agent pipeline. That includes cloud credentials, version control tokens, CI/CD tokens, Slack tokens, webhook URLs, JWTs, bearer tokens, payment keys, SSH material, database URLs, Redis URLs, passwords, and generic API keys. The ClawGuard paper lists a default pattern library covering many of these categories.

    This type of control is not a complete data-loss-prevention program, but it gives agent systems a practical starting point. If a tool return includes a credential, the agent should not blindly append it into future reasoning. If a proposed tool call includes a secret in an outbound payload, the runtime should redact or block it before execution.

    The goal is to break the chain between accidental exposure and automatic reuse. Agents tend to carry context forward. Sanitization stops sensitive content from becoming reusable context for later tool calls.


    Skills Need Inspection Before First Use

    Skill files create a different control problem. They are supposed to be directive, so the presence of instructions is not suspicious by itself. A useful skill might tell the agent how to search repositories, format reports, generate code, or interact with a service. A malicious skill can hide inside that same structure.

    That is why skill inspection should happen before first execution. The system should analyze the skill’s content, scripts, tool dependencies, file access, network behavior, and stated purpose. Then the user or operator should confirm whether the skill belongs in the environment. If the skill changes later, it should be treated as a new artifact and inspected again.

    This is analogous to reviewing a browser extension, CI/CD plugin, or automation script. A skill is not just text. It is an instruction package that changes how the agent behaves. In a mature enterprise deployment, skills need ownership, versioning, approval, and removal paths.

    Unmanaged skill ecosystems create a supply chain issue for agents. A team may trust the agent platform but overlook the public skill repository feeding it behavior.


    Results Point to a Clear Pattern, Not a Silver Bullet

    The ClawGuard evaluation is useful since it tests runtime enforcement across multiple benchmarks and model backbones. Across AgentDojo, SkillInject, and MCPSafeBench, the basic-rule configuration reduced attack success compared with unprotected baselines. On AgentDojo, attack success reached 0% across the tested models. On MCPSafeBench, baseline attack success ranged from 36.5% to 46.1%, and the basic-rule configuration reduced it to roughly 7.1% to 11.0% across the evaluated models.

    The limitations matter too. The evaluation notes that the tested configuration used baseline rules without the full task-specific rule-induction component, and residual failures remained in cases involving content-misleading attacks or gaps in endpoint coverage.

    That makes the lesson stronger, not weaker. Runtime enforcement works best as a layered control, not a magic filter. Baseline deny rules catch high-severity patterns. Task-specific policy narrows the allowed environment. Sanitization limits sensitive data movement. Skill inspection reduces supply chain risk. User approval handles ambiguous cases. Audit logging gives defenders visibility.

    The point is not that one framework solves agent security. The point is that tool-connected agents need enforceable runtime policy, and the tool-call boundary is one of the most defensible places to apply it.


    What This Means for Enterprise AI Programs

    Organizations adopting AI agents should avoid treating prompt injection as a purely model-side issue. The security program needs to account for the systems the agent can reach and the actions it can perform.

    The first step is inventory. Security teams should know which agent platforms are in use, which tools are enabled, which MCP servers are connected, which skill files are loaded, which users can install new capabilities, which credentials the agent can access, and which external domains it can contact.

    The next step is scoping. Each agent workflow should have a defined task envelope. A support-ticket summarizer, code-review assistant, vulnerability enrichment agent, finance workflow, and cloud operations agent do not need the same file access, network access, command access, or SaaS permissions.

    After that, teams need runtime controls. High-risk actions should be denied or queued by policy, not left to model preference. Examples include shell execution, package installation, access to credential stores, writes outside approved directories, calls to unknown domains, private network access, URL shorteners, paste sites, tunneling services, destructive filesystem commands, and agent configuration changes.

    Monitoring needs to follow the same model. Agent telemetry should show tool calls, file paths, network destinations, blocked actions, user approvals, skill loads, MCP server changes, and sanitizer events. Without those records, an incident involving an agent can collapse into guesswork.


    The Security Model Has to Assume the Agent Will Be Misled

    The safest assumption is that any tool-connected agent will eventually read hostile content. It may come from a webpage, repository, email, PDF, ticket, chat thread, MCP server, database field, or skill file. Security controls should be built around that assumption.

    If an agent is misled but cannot access credential stores, cannot contact unapproved domains, cannot run shell commands, cannot install packages, cannot modify its own configuration, and cannot write outside approved paths, the impact is limited. If the same agent has broad local access, broad network access, and weak approval prompts, indirect prompt injection becomes a path to data loss or execution.

    This is the real shift in AI security. The model is no longer just generating answers. It is selecting actions inside a connected environment. That means the control plane has to move closer to the action.

    Runtime enforcement at the tool-call boundary gives defenders a concrete place to apply least privilege, content sanitization, approval, and audit logging. It does not remove the need for safer models, better prompts, or stronger MCP implementations. It gives enterprises a practical control layer for the point where agent reasoning becomes operational change.

    AI agents will keep gaining access to real systems. The security model has to treat every proposed action as something that can be authorized, denied, inspected, and logged before it happens.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • NETIZEN JOINT VENTURE WINS SPOT ON $60B NASA SOLUTIONS FOR ENTERPRISE-WIDE PROCUREMENT (SEWP) VI CONTRACT

    Allentown, PA: Netizen Corporation, an ISO 27001, ISO 9001, and CMMI Level 3 certified Service Disabled Veteran-Owned provider of enterprise cybersecurity and information technology (IT) solutions for defense, government, and commercial customers worldwide, was awarded a spot on NASA’s Solutions for Enterprise-Wide Procurement VI (SEWP VI) contract vehicle through their joint venture company FourNet Solutions JV, LLC (FourNet).

    SEWP VI (pronounced “Soup Six”) is a government-wide acquisition contract (GWAC) that provides federal agencies with streamlined access to a comprehensive range of Information Technology, Communications, and Audio Visual (ITC/AV) hardware, software, and service solutions. Building on the success of previous SEWP contracts – some of the most widely used procurement vehicles for IT solutions throughout the public sector – SEWP VI is designed to further simplify the acquisition process.

    The SEWP VI contract has a five-year base period and five one-year option periods, for a total ten-year ordering period, with a maximum ceiling value of $60 billion dollars. SEWP VI is currently managed by NASA’s Goddard Space Flight Center and will be available for use by all government agencies and their approved support contractors beginning around October 2026. FourNet was awarded contracts in categories B and C.

    “This SEWP VI contract award has been nearly three years in the making and is a key part of our strategic roadmap for the continued growth of Netizen into new markets and solution areas,” said Akhil Handa, Netizen’s COO. “Through our close partnership and long-term relationship with Four Points Technology, we anticipate tremendous growth in coming years driven heavily by this contract vehicle and leveraging our joint venture.”

    FourNet, the awardee, is a U.S. Small Business Administration (SBA)-certified Service-Disabled Veteran-Owned Small Business (SDVOSB) joint venture between Netizen Corporation and Four Points Technology, LLC (Four Points). Four Points, founded in 2002 and based in Herndon, Virginia, is one of the largest and most successful providers of information technology hardware, software, and services for agencies across federal, defense, and education spaces nationwide. Under the SBA Mentor-Protégé Program Agreement, Netizen serves as the Protégé and managing venturer, while Four Points serves as the Mentor aiding Netizen’s continued growth and maturity.

    About Netizen Corporation:

    Founded in 2013, Netizen is a highly specialized provider of enterprise cybersecurity and related information technology (IT) solutions. The company, a Small Business Administration (SBA) certified Service-Disabled Veteran Owned Business (SDVOSB), is headquartered in Allentown, PA with additional locations in Virginia (DC Metro) and South Carolina (Charleston). Netizen maintains ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations that demonstrate their operational maturity.

    In addition to recognition as one of the most successful businesses in the U.S. three times by Inc. Magazine in their annual “Inc. 5000” list of the nation’s fastest growing companies, Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for Veteran hiring and training, a Greater Lehigh Valley Chamber of Commerce Business of the Year and Veteran-Owned Business of the Year, and a recipient of dozens of other awards for innovation, community involvement, and growth.

    Netizen operates a state-of-the-art 24x7x365 Network Security Operations Center (NSOC) in Allentown, PA that delivers comprehensive solutions for both government and commercial clients. Their service portfolio includes network and security monitoring, cybersecurity assessments and advisory, software assurance, penetration testing, IT systems engineering, and compliance support for government and commercial markets.

    Netizen specializes in serving organizations that operate within some of the world’s most sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable. Their proven track record in these domains positions them as the premier trusted partner for organizations where technology reliability and security simply cannot be compromised.

    Learn more at https://www.Netizen.net.  

    References:

    1. NASA SEWP VI Home Page (https://www.sewp.nasa.gov/sewpvi/)
    2. Welcome to FourNet Solutions (https://www.fournetsolutions.com/)
    3. Four Points Technology (https://www.4points.com/)
  • Netizen: Monday Security Brief (7/6/2026)

    Today’s Topics:

    • BioShocking Shows Why AI Browsers Turn Prompt Injection Into Account Access
    • FBI Seizure of NetNut Shows How Residential Proxies Turn Home Devices Into Cybercrime Infrastructure
    • How can Netizen help?

    BioShocking Shows Why AI Browsers Turn Prompt Injection Into Account Access

    AI browsers change the risk model for web security. A normal browser displays pages, runs site code inside web security boundaries, and leaves most decisions to the user. An AI browser in agent mode can read, click, type, summarize, follow links, interact with signed-in services, and make task-level decisions inside the user’s active session. That means prompt injection is no longer just a model-behavior issue. It becomes an identity and access issue.

    LayerX’s BioShocking research, published on June 29, 2026, demonstrates that problem through a proof-of-concept attack against six agentic browsers and assistants: ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser, and Anthropic’s Claude Chrome plugin. The attack does not rely on a memory corruption bug, stolen cookies, or malware. It relies on the agent accepting a manipulated operating context and then treating dangerous instructions as part of a task it is supposed to complete.

    The proof of concept was built as a BioShock-themed puzzle page. The agent is pushed into a false set of rules where incorrect answers are rewarded, such as accepting that 2 + 2 = 5. Once the agent adapts to that logic, the page asks it to continue the “game” by visiting a path that redirects to the victim’s work GitHub repository and copying sensitive SSH login credentials. LayerX says all six tested agents failed to identify the final step as a guardrail violation.

    The important detail is not the game theme. The important detail is that the malicious page and the user’s task arrive to the model as context the agent must interpret. That is the core failure behind indirect prompt injection: untrusted page content becomes operational instruction. OWASP’s 2025 LLM guidance lists prompt injection as LLM01 and describes it as manipulation of model behavior through crafted inputs that can cause unauthorized access, data exposure, and unsafe decisions.

    BioShocking is part of a broader pattern in agentic browser research. Brave disclosed an earlier indirect prompt injection issue in Perplexity Comet where malicious content in a web page could be processed by the assistant as instruction. In Brave’s demonstration, the assistant could move across authenticated sessions and retrieve information from services such as Gmail, exposing the limits of traditional browser security assumptions when an AI agent acts with user-level reach across sites.

    Guardio’s “Scamlexity” testing reached a similar conclusion from a scam and phishing angle. In its tests, agentic browsers interacted with fake shops, phishing pages, and hidden prompt-injection content in ways that removed the user from key decision points. The user might never inspect the sender, domain, checkout flow, or warning signs. The agent becomes the decision-maker, and attackers shift from deceiving the human to deceiving the browser assistant.

    That shift matters for enterprise security. A compromised AI browser does not need to break into GitHub, Gmail, Google Drive, a ticketing system, or an internal portal if the user is already signed in and the agent is allowed to operate inside that session. The agent becomes a delegated actor with access inherited from the user. From a defender’s view, that looks less like classic credential theft and more like misuse of a trusted identity.

    LayerX’s controlled test used a harmless plaintext file, but the attack path shows how the same technique could reach authenticated repositories, open tabs, internal tools, connected SaaS platforms, or other data sources visible to the browser session. BleepingComputer’s coverage of the research notes that LayerX’s proof of concept was tested across six mainstream agentic products, with OpenAI named as the only vendor LayerX says had a working fix at the time of publication.

    The vendor response also shows how immature this control space still is. LayerX says it submitted reports between October 2025 and January 2026. Its disclosure table states that OpenAI fixed the issue in ChatGPT Atlas, Perplexity closed or ignored the Comet report, Fellou, Genspark, and Sigma did not respond, and Anthropic attempted a patch for the Claude Chrome plugin that LayerX says did not hold. Those statuses should be treated as LayerX’s reported disclosure record, not as an independently verified statement from each vendor.

    Academic work on agentic prompt injection supports the same concern. A 2025 paper on prompt injection and data leakage in LLM agents found that tool-using agents can leak personal data observed during task execution, with attack success shaped by the task type, the data requested, and the agent’s role in extraction or authorization workflows. The authors also note that LLMs lack a clean mechanism for separating instructions from data, which is exactly the weakness BioShocking exploits in the browser.

    The defensive answer cannot be a single prompt telling the model to be careful. BioShocking shows that the model’s interpretation layer can be manipulated before the sensitive action happens. Effective controls need to sit around the agent, the browser, and the identity plane. Sensitive reads from authenticated systems should require explicit user confirmation. Agents should treat page content, comments, hidden text, URLs, documents, and third-party data as untrusted input. High-impact actions such as reading private repositories, copying credentials, sending messages, changing settings, or posting data externally should be gated by separate policy checks rather than the model’s own judgment.

    Scope control is just as important. An AI browser used to summarize a public article should not inherit access to corporate email, repositories, customer portals, admin consoles, or password managers. Agent sessions should be constrained by task, site, identity, and data class. If the user asked for help reading a page, the agent should not be able to search private GitHub repositories. If the user asked for a calendar summary, the agent should not be able to post data to an external endpoint. Least privilege has to apply to AI agents the same way it applies to service accounts.

    Security teams also need visibility. Browser agents should be logged as distinct actors, not buried inside generic user activity. Defenders need to know when an agent accessed a repository, copied a secret-like string, visited an internal tool, submitted a form, read a message, or transferred content across trust boundaries. DLP, CASB, browser security, identity governance, and endpoint telemetry all become more valuable when they can distinguish normal human browsing from agent-driven action.

    BioShocking is not just a clever jailbreak. It is a warning about what happens when agentic automation is placed directly on top of authenticated user sessions. The browser has become a control surface for AI, identity, SaaS access, and data movement at the same time. If attackers can influence the agent’s context, they may be able to influence what the user’s account does next.

    The lesson is direct: AI browsers should not be treated as safer browsers with better assistants. They should be treated as delegated identities with browser access, SaaS reach, and automation rights. Until agentic browsing has enforceable permissions, sensitive-action confirmation, untrusted-content isolation, and full auditability, every signed-in tab becomes part of the attack surface.


    FBI Seizure of NetNut Shows How Residential Proxies Turn Home Devices Into Cybercrime Infrastructure

    The FBI’s seizure of domains tied to NetNut and the Popa botnet is a clear signal that residential proxy networks have moved from a gray-market privacy problem into core cybercrime infrastructure. On July 2, 2026, NetNut’s homepage was replaced with a federal seizure notice after the FBI, IRS Criminal Investigation, Google, Lumen, Shadowserver, and other partners acted against hundreds of domains associated with the service. KrebsOnSecurity reported that NetNut is operated by Alarum Technologies, a publicly traded Israeli company, and that the seizure followed research linking NetNut to Popa, a botnet estimated at no fewer than two million compromised consumer devices.

    Residential proxy services sell access to real consumer IP addresses. To a target website, login portal, ad exchange, or fraud detection engine, traffic routed through one of these nodes can look like it is coming from a normal household internet connection instead of an obvious cloud server, VPN endpoint, or known criminal host. That makes residential proxies useful for legitimate testing and localization, but also valuable for credential stuffing, account takeover, scraping, ad fraud, spam, password spraying, and intrusion activity that needs to blend into normal user traffic. Google’s Threat Intelligence Group said suspected NetNut exit nodes were used by 316 distinct threat clusters in a single week during June 2026, including cybercriminal and espionage groups.

    The central allegation is that NetNut’s residential pool was tied to Popa, an Android proxyware ecosystem that enrolled consumer devices into a commercial proxy network. Synthient’s research describes Popa as an Android SDK that can turn phones, tablets, and streaming boxes into residential proxy nodes. Its analysis found Popa-family samples communicating with NetNut SDK endpoints, shared infrastructure at the SDK-distribution layer, and controlled-test telemetry from June 17, 2026 showing traffic from a Popa host egressing through NetNut’s commercial gateway. Synthient also states that NetNut disputes the conclusion and says it operates a lawful proxy network with customer due diligence and abuse monitoring.

    That distinction matters. A residential proxy company can claim to sell routing capacity, but the security question is how that capacity is sourced, whether device owners gave meaningful consent, and what happens once unknown third-party traffic enters a home network. Google says home devices can become exit nodes through malware preinstalled before purchase or through apps that secretly contain proxy code. Once that happens, the device owner’s IP address can be used as a launchpad for attacks, and other devices on the same local network may be exposed to internet-originated traffic routed through the compromised node.

    The consumer device angle is what makes Popa so damaging. A no-name Android TV box or free streaming app is usually treated like low-risk entertainment hardware, not like a remotely controlled network relay. Yet these devices often run outdated Android builds, ship outside trusted update channels, lack transparent software provenance, and sit on the same home network as phones, laptops, routers, work devices, and smart home systems. Once proxy code is installed, the device can run constantly, relay outside traffic, and make the homeowner’s IP address part of someone else’s operation.

    Google says it disabled Google accounts and services used by NetNut for malware command-and-control, shared technical intelligence on NetNut SDKs and backend infrastructure, and used Google Play Protect to warn users and disable apps known to include NetNut SDKs. Google also said the disruption reduced the pool of devices available to the proxy operator by millions. Reuters reported that Alarum confirmed it had been informed of the FBI seizure of certain domains and said it would cooperate with law enforcement.
    The case also points to a much larger ecosystem. Google says NetNut was widely resold and white-labeled by third-party proxy providers, meaning customers may have been buying NetNut capacity through other brands without seeing the true upstream source. This is one reason takedowns of individual providers may produce only temporary disruption. After a network loses its own botnet capacity, it can purchase capacity from competitors and reappear as a reseller. Google linked this pattern to earlier disruption work against IPIDEA and said long-term impact requires action against several interconnected providers, not one platform at a time.

    The smart TV and app ecosystem makes the problem harder to contain. Spur Intelligence scanned 6,038 LG webOS and Samsung Tizen apps and found 2,058 containing residential proxy SDKs, equal to 34.1 percent across the dataset. The reported rate was 42.5 percent for LG webOS apps and 26.9 percent for Samsung Tizen apps. That does not mean every app was tied to NetNut or Popa, but it shows that proxy SDKs are no longer limited to shady desktop utilities or mobile apps. They are being embedded into living-room software at scale.

    For defenders, the main lesson is that residential IP traffic should not be trusted just due to its source category. A login attempt from a consumer ISP address can still originate from malware, proxyware, or an attacker buying access to a hijacked device. Security controls that treat residential IPs as low risk can be exploited by operators who use proxy networks to avoid datacenter blocklists, throttle limits, geography checks, and reputation scoring. Detection logic needs to account for behavioral signals, impossible travel, session anomalies, authentication velocity, ASN drift, device fingerprint changes, and repeated failed logins spread across many residential addresses.

    Network teams should also look inward. Smart TVs, streaming boxes, and unmanaged Android devices should not share flat access with corporate systems, workstations, NAS devices, printers, or sensitive home-office equipment. At home, these devices belong on a guest or IoT network with client isolation where practical. In business environments, unmanaged media devices should be blocked or segmented. DNS logs, egress telemetry, and firewall records can help identify unexpected proxy protocols, persistent outbound connections, unknown relay infrastructure, SOCKS traffic, and beaconing to suspicious domains.

    Consumers have fewer controls, but they are not powerless. Google recommends buying connected devices from reputable manufacturers, using official app stores, checking permissions for third-party VPN and proxy apps, and keeping Play Protect active. Google’s Android certification guidance says Play Protect certified devices must pass security and compatibility testing, ship without preinstalled malware, and include Google Play Protect protections such as app scanning.
    The NetNut seizure is not just a botnet takedown. It is a reminder that the boundary between consumer electronics and attack infrastructure has eroded. A cheap streaming box, free TV app, or proxy SDK can quietly convert a household connection into a rented exit node for fraud crews, scrapers, password-spraying operators, and espionage activity. The device owner may see only a normal entertainment app. The attacker sees clean residential reach.

    That is what makes residential proxy abuse so difficult to fight. It hides inside ordinary devices, ordinary networks, and ordinary IP space. The FBI and Google action against NetNut may degrade one of the largest known networks in that ecosystem, but the broader market is adaptive, reseller-heavy, and difficult to dismantle permanently. For security teams, the right response is to treat residential proxy traffic as a serious abuse vector, treat unmanaged consumer devices as potential network relays, and stop assuming that an IP address is trustworthy just because it looks like a normal home connection.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • AI Agent Tooling Is Turning Metadata Into an Attack Surface

    AI agent security is beginning to move beyond the familiar problem of malicious prompts. The more serious issue is what happens after the model is connected to real systems. Once an AI assistant can reach files, APIs, databases, SaaS platforms, code repositories, ticketing queues, and internal workflows, the security boundary is no longer just the conversation. It is the entire environment the agent can act inside.

    The Model Context Protocol, or MCP, sits directly in the middle of that shift. MCP gives AI applications a standard way to connect with outside tools and data sources. A client can ask an MCP server what tools are available, what each tool does, what parameters it accepts, and how it should be used. That structure makes agent workflows easier to build and easier to reuse across different applications.

    It also creates a new trust problem. The model is not just receiving instructions from the user. It is receiving descriptions, schemas, prompts, and parameters from tool servers. In a normal application, that kind of metadata might be treated as reference material. In an AI agent workflow, it can shape the model’s next action.

    That is where MCP tool poisoning becomes dangerous. A malicious or compromised MCP server can hide instructions inside tool metadata. The user may never type anything unsafe. The model may never be directly jailbroken. The attack can begin quietly, inside the tool description that the client loads before the user even sees a tool call.

    Once that poisoned metadata enters the model’s context, it can influence how the agent reasons about the task. A tool that appears to be a calculator, file search helper, or project utility may quietly instruct the model to read sensitive files, prefer one tool over another, log future activity, generate deceptive links, or execute commands. The tool description stops being a harmless label and starts functioning as an instruction channel.

    For organizations adopting AI agents, this changes the security question. It is no longer enough to ask whether the model is safe. The more practical question is whether the agent’s tool environment can be trusted.


    The Attack Lives in the Tool Layer

    MCP tool poisoning is a form of indirect prompt injection. Instead of placing the malicious instruction in the user’s prompt, the attacker places it in content the model is expected to consume during normal operation. That content may come from a webpage, document, retrieved record, API response, or in this case, tool metadata.

    This makes the attack path easy to miss. A user may open an AI client, connect a server, and ask the agent to complete a routine task. Behind the scenes, the client has already pulled tool descriptions from the MCP server and passed them into the model. If those descriptions contain hidden instructions, the model may treat them as part of its operating context.

    The attacker benefits from the way agent systems blend natural language with execution logic. Tool descriptions are written for the model to interpret. They explain when a tool should be used, what it can access, and how the request should be formed. A poisoned description abuses that same pathway by adding instructions that serve the attacker rather than the user.

    The result is a subtle trust inversion. The user believes the agent is responding to their request. The model may be responding to the user’s request and to hidden tool guidance supplied by an untrusted server. The client becomes the gatekeeper, yet many clients still treat tool metadata as ordinary text instead of hostile input.


    MCP Makes Agents More Useful by Giving Them More Reach

    The reason MCP is attractive is also the reason it carries risk. Agents are far more useful when they can take action. A coding assistant that can inspect a repository, run tests, search documentation, and interact with a ticketing system is more valuable than a chatbot that can only generate text. A security assistant that can query logs, enrich indicators, check asset data, and draft reports can save analysts time.

    MCP helps make those connections cleaner. A server can expose a set of tools, and the client can make those tools available to the model in a consistent way. That reduces integration friction, but it also expands the agent’s action space.

    A local MCP server might expose a filesystem, terminal, browser, database, or developer environment. A remote MCP server might expose a SaaS platform, cloud API, CRM, knowledge base, or ticketing system. In either case, the agent is being handed new ways to read, write, send, query, and execute.

    That expanded reach means poisoned metadata can have real effects. A malicious instruction inside a basic chat transcript is one problem. A malicious instruction inside an agent environment with file access, network access, OAuth tokens, or shell access is a different problem altogether.

    The model does not need to break out of anything on its own. It only needs to follow a poisoned instruction through a tool path that already exists.


    File Access Turns Prompt Injection Into Data Loss

    File access is one of the most direct ways tool poisoning can become an enterprise issue. Many AI workflows ask users to grant access to local folders, project directories, configuration files, documentation, or source code. That access may feel reasonable at setup time. The agent needs context, and local files often contain the context needed to complete the task.

    The risk appears when a poisoned tool uses that access for a different purpose. A tool can describe itself as a harmless helper, then instruct the model to read files unrelated to the user’s request. In a developer environment, those files might include SSH material, environment variables, cloud profiles, API keys, MCP configuration, repository secrets, private notes, or internal documentation.

    From the user’s point of view, the approval prompt may still look routine. The interface may show a tool name and a short description, but not the full parameter payload. It may summarize the action without showing the exact file path. It may hide long values, collapse arguments, or present the request in language that sounds harmless.

    That is why user approval alone cannot carry the security burden. A user cannot evaluate a risk they cannot see. If an approval dialog hides the sensitive file path or the outbound destination, the approval is little more than a speed bump.

    The better control is to reduce what the tool can reach in the first place. A file server that only needs access to one project should not see the user’s full home directory. A documentation assistant should not be able to read SSH keys. A code helper should not receive write access or shell access by default. The agent’s permissions need to match the task, not the broadest possible workspace.


    Poisoned Tools Can Watch the Workflow

    Data theft is not the only outcome. A poisoned tool can also try to observe how the agent is used over time.

    This can happen when a tool description claims that the tool should always run first, should monitor other tool calls, or should record user activity for performance or context. If the client passes that description into the model without filtering, the model may begin calling the tool during unrelated tasks.

    That turns the tool into a quiet surveillance point inside the workflow. It may record prompts, tool names, filenames, timestamps, project references, generated outputs, or command history. That data can reveal far more than it first appears to. It can show which clients a team supports, which incidents are active, which repositories are being changed, which systems are being queried, and which internal projects are receiving attention.

    This matters in security operations, engineering, legal work, finance, healthcare, and any other environment where workflow context has value. Attackers do not always need the final document or credential. Sometimes the sequence of actions is enough to infer priorities, processes, or weak points.

    A tool should never be allowed to grant itself priority through its own description. Tool ordering and tool selection should come from trusted client policy, explicit user intent, and approved configuration. Natural-language claims from a server should not decide which tool gets to observe the rest of the session.


    Agent-Generated Phishing Blends Into Normal Work

    Tool poisoning can also affect what the agent produces for other people. If a poisoned tool can influence the model’s output, it can push the agent to generate deceptive links inside content that looks legitimate.

    This is especially risky in business workflows. An AI assistant might draft a ticket comment, create a pull request response, prepare a Slack message, write a customer update, or generate a report. A poisoned tool can instruct the model to include a link that appears to point to a trusted destination but actually routes somewhere else.

    The attack is effective since the malicious content is not arriving as a suspicious external email. It appears inside normal work product generated by a trusted assistant. A user may review the message for tone and accuracy without checking the underlying URL. A teammate may trust the link since it came through an internal workflow.

    Clients need to make link behavior visible. If the displayed text and destination differ, the user should see that clearly. If a generated link points to an external domain, uses a shortener, includes sensitive values in the URL, or routes through an unexpected redirect, the client should warn the user before the content is sent or published.

    Agent output should not be treated as trusted simply since it came from an internal assistant. It is generated content, and generated content can carry attacker-controlled instructions forward.


    Remote Execution Is the Line That Cannot Be Soft

    The most severe MCP tool poisoning scenario is command execution. If a poisoned tool can push the model to download a script, run a shell command, install a package, or modify local configuration, the risk moves from prompt injection into host compromise.

    That risk is especially high for developer-facing AI clients. These environments often have source code, SSH keys, package managers, cloud CLIs, build pipelines, internal repositories, and deployment files within reach. A tool-poisoning attack that reaches command execution may give an attacker access to the same operational environment the developer uses every day.

    This is where soft controls break down. A model may refuse a dangerous request in one context and miss it in another. A user may approve a command after seeing a vague description. A client may treat a download or execution step as part of a normal workflow.

    Execution needs hard boundaries. Shell access should be separated from ordinary tool use. Dangerous commands should require clear, detailed approval. Remote downloads should be blocked or tightly restricted. Tools should run in sandboxes with narrow filesystem and network permissions. Outbound network access should be limited to known destinations for tools that need it.

    An agent should never inherit broad local authority for convenience.


    Better MCP Security Starts at the Client

    The MCP server exposes the tools, but the client decides what reaches the model and what the user can inspect. That makes client behavior central to the defense model.

    A secure client should treat tool metadata as hostile until it is validated. Descriptions should be scanned for hidden instructions, priority manipulation, requests to ignore user intent, sensitive file references, exfiltration language, and suspicious network behavior. Tool schemas should be checked before they are passed into the model. Parameters should be visible before execution, including full file paths, domains, commands, and outbound destinations.

    The client also needs runtime policy. Reading a README is not the same as reading an SSH key. Opening an internal documentation link is not the same as sending data to an unknown domain. Generating a report is not the same as running a downloaded script. The interface should make those differences obvious, and the policy engine should block actions that fall outside approved bounds.

    Auditability is part of the same problem. Security teams need records showing which MCP servers were connected, which tools were loaded, which tool calls were made, what parameters were used, what data was accessed, what the user approved, and what the client blocked. Without that trail, a tool-poisoning incident can become difficult to reconstruct.


    MCP Servers Should Be Treated Like Third-Party Code

    Organizations should also change how they think about MCP servers. They are not simple configuration files. They are integrations with code, permissions, dependencies, network behavior, and tool metadata that can shape agent actions.

    An MCP server from a public repository should be reviewed before it is connected to sensitive systems. Its source code, dependencies, startup commands, tool descriptions, schemas, permission requests, and network destinations should all be examined. A popular repository can still contain unsafe defaults. A legitimate server can become risky after an update. A compromised dependency can alter behavior without changing the name of the tool users recognize.

    This puts MCP servers closer to browser extensions, CI/CD plugins, and third-party SaaS integrations than ordinary documentation. They deserve an approval process, ownership, version tracking, and removal procedures.

    In enterprise environments, unmanaged MCP installation should be treated as shadow IT. A single workstation running an over-permissive local server may expose credentials, code, or customer data through an agent workflow that security teams cannot see.


    Identity Controls Still Shape the Blast Radius

    Tool poisoning often begins with instructions, but the blast radius is shaped by identity and authorization. A poisoned tool can only abuse what the agent environment can access. That makes scoped identity controls a major part of the defense.

    Remote MCP servers should require authentication. Tokens should be scoped to the correct server, user, and audience. OAuth flows should use strict redirect validation, protected state values, and clear consent screens. A server should not accept tokens meant for another service, and agent actions should be traceable across the user, client, MCP server, and downstream resource.

    That traceability matters during investigations. A log entry saying that a user accessed a file may not be enough. Security teams need to know whether the user clicked it manually, whether an AI client invoked a tool, whether a remote MCP server brokered the request, and whether the action matched an approved workflow.

    As agents gain more access, delegated identity becomes part of incident response. The more systems an agent can reach, the more important it becomes to know exactly which component acted.


    What Security Teams Should Put in Place

    The first step is visibility. Organizations need to know which AI clients are in use, which support MCP, which MCP servers are connected, which users enabled them, and which systems those servers can reach. Without that inventory, policy is mostly theoretical.

    Once the inventory exists, teams can group MCP servers by risk. A read-only documentation server is very different from a server that can execute shell commands, access source code, query production data, or send content to external APIs. Higher-risk servers should require stronger review, narrower permissions, and more logging.

    Security teams should also define minimum client controls before MCP is broadly adopted. Those controls should include metadata validation, full parameter visibility, warning prompts for risky actions, sandboxed execution, scoped filesystem access, restricted network egress, authentication for remote servers, and searchable audit logs.

    Detection should cover agent behavior directly. A newly added MCP server, a tool asking for credential paths, a tool attempting to log unrelated activity, a generated link to an unknown domain, repeated blocked tool calls, or unexpected outbound traffic from an agent process should all be visible to defenders.

    The goal is not to block MCP outright. The goal is to make sure agent tooling receives the same level of scrutiny as the systems it can reach.

    The Real Risk Is Uncontrolled Agent Action

    MCP shows where AI security is heading. The prompt still matters, but the larger risk is the connection between language and action. Once a model can call tools, read files, send data, create content, and execute commands, every piece of context that influences the model becomes part of the control path.

    Tool poisoning takes advantage of that control path. It turns metadata into instruction, instruction into tool use, and tool use into data movement or execution. The attack can feel invisible since it begins in a place users rarely inspect and ends in a tool call that may look normal on the surface.

    MCP can still be used safely, but it needs guardrails that match its role. Tool metadata should be treated as untrusted. Tool permissions should be narrow. Execution should be contained. User approvals should show the real action. Agent activity should be logged in a way security teams can investigate.

    AI agents are becoming interfaces into enterprise systems. The tool layer is where those interfaces gain the ability to act. That makes MCP security less about chatbot safety and more about controlling what connected agents can actually do.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • Vulnerability Management Is Outgrowing Severity Scores

    Vulnerability management has always involved a mismatch between volume and capacity. Security teams identify thousands of findings across endpoints, cloud workloads, SaaS platforms, network appliances, containers, applications, and third-party software. Remediation teams do not have unlimited time, and many systems cannot be patched without maintenance windows, regression testing, uptime planning, or business approval.

    That is why prioritization matters. The hard part is no longer finding vulnerabilities. The hard part is deciding which vulnerabilities actually deserve immediate action.

    For years, many programs leaned heavily on severity scores. A scanner finds a CVE, maps it to CVSS, assigns a severity label, and pushes the finding into a remediation queue. That workflow is simple, repeatable, and easy to explain. It is also incomplete.

    A vulnerability with a high severity score may sit behind layers of segmentation, require conditions that do not exist in the affected environment, or affect an asset with limited business value. A vulnerability with a lower score may sit on an internet-facing identity system, a VPN appliance, a domain-joined server, or a system tied to regulated data. In practice, the second vulnerability may represent the greater operational risk.

    Modern vulnerability prioritization needs more than severity. It needs exploitability, exposure, asset value, business impact, threat activity, compensating controls, remediation feasibility, and dependency mapping. Research on vulnerability prioritization increasingly separates these dimensions into impact metrics, exploitability metrics, contextual and environmental metrics, predictive metrics, and system-level aggregation methods. A 2025 survey of 82 studies organized the field using those same categories, which reflects how far prioritization has moved beyond single-score triage.


    Severity Is a Starting Point, Not a Decision

    CVSS remains one of the most widely used ways to describe vulnerability severity. It gives security teams a common language for discussing technical impact and exploit conditions. CVSS version 4.0 also supports Threat and Environmental metrics that can adjust severity using threat intelligence and deployment context, which helps move the score closer to real risk.

    The problem begins when organizations treat a base severity score as the final remediation order.

    CVSS describes characteristics of a vulnerability. It does not automatically know whether the affected asset is exposed to the internet, whether exploit code is active, whether the system stores sensitive data, whether segmentation limits reachability, whether a compensating control blocks the attack path, or whether the patch will break a production workflow.

    The vulnerability prioritization survey makes this gap clear. More than 70% of reviewed studies used CVSS as a primary prioritization metric, yet the survey also notes that CVSS base scores are static and lack deployment-specific context.

    That limitation appears in real environments every day. A severity-only queue may put a high-scoring vulnerability on an isolated test box ahead of a lower-scoring vulnerability on an exposed authentication gateway. It may overload engineering teams with findings that satisfy scanner logic but do not map cleanly to exploitability or business risk.

    Severity should open the conversation. It should not end it.


    Exploitability Changes the Order of Operations

    Attackers do not exploit vulnerabilities in descending CVSS order. They exploit what is reachable, reliable, useful, and profitable.

    Exploitability metrics try to account for that difference. They consider whether exploitation is technically feasible, whether public exploit code exists, whether the attack requires authentication, whether user interaction is needed, whether exploitation has been observed in the wild, and whether the vulnerability is being discussed or operationalized by threat actors.

    EPSS is one of the more useful signals in this area. FIRST describes EPSS as a data-driven machine learning model that estimates the probability that a published CVE will be exploited in the wild within the next 30 days.

    CISA’s Known Exploited Vulnerabilities catalog adds another important signal: confirmed exploitation. CISA says organizations should use the KEV catalog as an input to vulnerability management prioritization, and NVD notes that federal civilian agencies must remediate KEV-listed vulnerabilities within prescribed timelines under BOD 22-01.

    These signals shift vulnerability management from theoretical severity to operational likelihood. A vulnerability that is already being exploited deserves a different response than one with a high technical score but no known exploitation, no exploit code, and limited exposure.

    The strongest prioritization programs combine severity, exploitability, and confirmed threat activity. CVSS can describe impact. EPSS can estimate near-term exploitation probability. KEV can identify vulnerabilities already used by attackers. None of these signals is perfect alone. Together, they give teams a better starting point than severity alone.


    Context Is Where Risk Becomes Real

    The same CVE can create very different risk across two organizations, or even across two assets inside the same organization.

    A vulnerability on an internal lab server may be tolerable for a short period. The same vulnerability on an externally exposed VPN appliance may demand immediate action. A flaw in a low-value kiosk system may create limited risk. The same flaw in a clinical system, payment environment, identity provider, or domain controller may carry major operational consequences.

    Contextual prioritization brings asset and environment data into the scoring process. That includes asset criticality, network exposure, business function, data sensitivity, user population, compensating controls, system dependencies, uptime requirements, and remediation difficulty.

    The vulnerability prioritization survey identifies contextual and environmental factors as a distinct metric category, including business impact, system impact, network and host exposure, and operational feasibility.

    This is where many programs struggle. Vulnerability scanners can produce findings, but scanners often lack full asset context. CMDBs may be incomplete. Cloud inventories may change constantly. Business owners may not keep asset tags current. Network exposure may shift after a firewall change, cloud deployment, or remote access update.

    Without context, prioritization becomes guesswork with scores attached.

    A mature program connects scanner output to asset inventory, identity data, network topology, EDR visibility, exposure management, ticketing history, business ownership, and service criticality. The goal is to rank vulnerabilities based on where they sit in the organization’s actual operating environment.


    Exposure Should Change Urgency

    Exposure is one of the most practical prioritization signals. A vulnerable system reachable from the public internet carries a different level of urgency than the same system reachable only from a segmented subnet. A vulnerability on an asset accessible from partner VPNs, vendor networks, guest wireless, or cloud peering links may also need faster attention than one buried deep inside a restricted environment.

    Network exposure also interacts with exploit complexity. A remotely exploitable vulnerability on an internet-facing appliance is a common path into organizations. A local privilege escalation vulnerability may matter less on a locked-down workstation, but more on a system where attackers already have a foothold or where remote access services are exposed.

    Graph-based prioritization methods help here. They model systems, dependencies, trust relationships, attack paths, and propagation routes. The survey describes graph-based methods as useful for analyzing attack paths, dependencies, and cascading effects across complex environments.

    This type of modeling matters since vulnerabilities rarely exist in isolation. An attacker may chain a perimeter flaw, weak credential control, lateral movement path, and privilege escalation bug. A single CVE may look moderate in isolation but become high risk when it sits on a path to a crown-jewel asset.

    Prioritization should ask where a vulnerability can lead, not just what the vulnerability is.


    Business Impact Belongs in the Queue

    Technical risk and business risk overlap, but they are not identical.

    A vulnerability on a billing system may affect revenue. A vulnerability on a healthcare system may affect care delivery. A vulnerability on a manufacturing system may affect safety, uptime, or production. A vulnerability on a legal document system may affect confidentiality obligations. A vulnerability on an identity platform may affect nearly every connected application.

    Business impact helps translate vulnerability management into operational decision-making. It also helps justify remediation urgency to teams outside security.

    This is especially useful when patching carries risk. Some assets cannot be patched immediately without downtime, vendor coordination, testing, or replacement planning. In these cases, prioritization must account for operational feasibility. The right decision may be patching, virtual patching, segmentation, compensating control deployment, service isolation, or scheduled remediation tied to a maintenance window.

    The survey’s discussion of industrial trends points to growing use of context-aware and multi-domain metrics that incorporate asset criticality, operational impact, network topology, device characteristics, compensating controls, and position inside industrial networks.

    That direction matches what many organizations already need. Patching everything immediately is not realistic. Patching based only on scanner severity is inefficient. Ranking based on technical risk and business consequence produces a queue that operational teams can actually defend.


    Predictive Scoring Can Help, but It Must Be Explainable

    Machine learning can improve vulnerability prioritization by analyzing historical exploitation, exploit code availability, vulnerability text, software vendor patterns, references, social signals, and other indicators that may predict future exploitation. The survey describes predictive metrics as forward-looking signals that use statistical and machine learning models to anticipate exploitation or changing impact.

    That is useful at scale. Large environments can generate too many findings for manual analysis. Predictive scoring can surface vulnerabilities likely to become weaponized before they appear in active exploitation catalogs.

    The limitation is trust. If a model ranks a vulnerability as urgent, analysts and remediation owners need to know why. A black-box score with no explanation may be ignored, challenged, or applied inconsistently. The survey identifies explainability as a major issue for advanced prioritization methods, noting that some ML-based models perform well but lack interpretability for practitioners who need clear justifications.

    Explainability should be built into the workflow. A prioritization engine should show which factors drove the ranking: active exploitation, exploit code, internet exposure, asset criticality, sensitive data, lateral movement potential, business function, control gaps, or remediation deadline.

    Security teams need rankings they can defend in change boards, engineering meetings, audits, and incident reviews.


    Compliance Deadlines Can Conflict With Risk-Based Triage

    Vulnerability management is also shaped by compliance requirements. PCI DSS, HIPAA-related security expectations, NERC CIP, FedRAMP, customer contracts, cyber insurance requirements, and internal policies may impose remediation timelines based on severity labels or asset classes.

    That can create friction. A compliance-driven deadline may require a medium-risk vulnerability to be patched within a set time window, even when threat activity points to a different vulnerability as the larger immediate risk. A purely risk-driven queue may conflict with audit requirements if it does not track policy timelines.

    The survey notes that compliance remediation timelines can conflict with risk-based approaches and calls for prioritization methods that integrate standards such as CVSS, CPE, and SCAP with compliance-driven metrics such as SLA deadlines.

    Security teams should not treat this as an either-or problem. The remediation queue needs both risk urgency and compliance accountability. A finding can be low exploitation risk and still require closure for audit. A finding can sit outside a strict compliance clock and still require emergency response due to active exploitation.

    The ticketing workflow should make both visible.


    Data Quality Can Make or Break Prioritization

    A prioritization model is only as good as the data behind it.

    Scanner data can be noisy. Asset inventories can be stale. Software detection can be wrong. Internet exposure data can lag behind infrastructure changes. Threat intelligence can be incomplete. Vulnerability records can lack detail. Exploit availability can change quickly. Business ownership data can be outdated.

    The survey found that most reviewed studies relied on standard vulnerability databases such as CVE and NVD, with 70 of 82 using those sources. It also identifies data quality issues, including inconsistent vulnerability feeds, bias, and gaps that can skew prioritization.

    This matters in production security programs. A high-risk vulnerability may be missed if the affected software is not detected. A vulnerability may be over-prioritized if a scanner flags a package that is present but not reachable or loaded. A ticket may sit untouched if ownership data points to the wrong team.

    Improving prioritization requires improving the underlying data pipeline. Asset management, vulnerability scanning, SBOM data, EDR telemetry, cloud inventory, external attack surface management, threat intelligence, and ticketing systems all need to feed each other.

    The scoring model cannot fix missing context that was never collected.


    A Practical Prioritization Model

    A practical vulnerability prioritization model should begin with severity, then enrich it.

    The first layer is technical severity. CVSS still has value as a common baseline for impact and exploit characteristics. The second layer is exploitation likelihood, using signals such as EPSS, exploit code availability, active scanning, malware integration, and KEV status. The third layer is exposure, including internet reachability, network segment, authentication boundary, and attack path position.

    The fourth layer is asset context. This includes asset criticality, data sensitivity, business owner, regulatory scope, identity role, and dependency on other systems. The fifth layer is operational feasibility, including patch availability, downtime risk, compensating controls, maintenance windows, vendor constraints, and rollback options.

    The final output should not just be a score. It should be a decision record. It should explain why the vulnerability is ranked where it is, what action is recommended, which team owns it, what deadline applies, and what compensating controls are acceptable if patching cannot happen immediately.

    This turns vulnerability management from scanner output into risk operations.


    What Security Teams Should Change

    Organizations that still prioritize mainly by CVSS should start by adding exploitability and exposure data. KEV-listed vulnerabilities, high-EPSS vulnerabilities, externally exposed assets, and identity-facing systems should receive special attention.

    Security teams should connect vulnerability data to asset inventory and business ownership. A finding without an owner is a delayed remediation. A finding without asset context is an incomplete risk decision.

    Programs should also define exception paths. Some vulnerabilities cannot be patched immediately. The process should require documented compensating controls, business acceptance, expiration dates, and review checkpoints rather than letting exceptions become permanent.

    Metrics should shift from raw vulnerability counts to risk reduction. Total findings matter less than exploitable findings on critical assets, internet-exposed vulnerabilities, KEV remediation performance, SLA compliance, exposure reduction, and time to remediate vulnerabilities with active exploitation.

    The larger goal is to make remediation effort match attacker opportunity and business impact.


    The Future of Vulnerability Management Is Context-Aware

    Vulnerability management is becoming less about counting flaws and more about ranking risk under operational constraints. Severity scores still matter, but they are no longer enough for environments where attackers move fast, infrastructure changes constantly, and remediation capacity is limited.

    The next stage is context-aware prioritization. That means scoring vulnerabilities based on technical impact, exploitation likelihood, asset criticality, exposure, business function, system dependencies, compliance deadlines, and operational feasibility.

    It also means being honest about tradeoffs. Some vulnerabilities need emergency patching. Some need mitigation until a maintenance window. Some need segmentation more than a patch. Some need ownership cleanup before remediation can even begin.

    Security teams that mature past severity-only triage will make better use of limited remediation capacity. They will reduce the risk that matters most, create clearer justification for patching decisions, and build vulnerability programs that map more closely to the way attacks actually unfold.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • How AI Use Creates New Compliance Challenges

    AI adoption is creating a new class of compliance risk that does not fit cleanly inside traditional policy, audit, privacy, or security programs. For years, most compliance programs were built around known systems, known data flows, defined user roles, documented vendors, and repeatable business processes. Artificial intelligence changes that operating model. It introduces probabilistic outputs, opaque vendor dependencies, dynamic model behavior, prompt-based user interaction, training and inference data exposure, and automated decision support that can affect customers, patients, employees, citizens, and regulated records.

    The compliance issue is no longer limited to whether an organization has approved software in place. The harder question is whether the organization can prove how AI is being used, what data it can access, what decisions it influences, what controls govern its outputs, and what evidence exists when auditors, regulators, customers, or legal teams ask for accountability. NIST’s AI Risk Management Framework is built around four core functions: govern, map, measure, and manage. That structure reflects a major shift from static control checklists to lifecycle oversight of AI systems.

    AI use creates compliance strain since the technology can sit across many functions at once. Employees may paste customer data into public AI tools to summarize tickets. Developers may use coding assistants to generate application logic. Security analysts may use LLMs to draft reports. HR teams may rely on automated screening tools. Customer support groups may deploy chatbots that pull from internal knowledge bases. Each use case may appear operationally small, but each one can create a regulated data flow, a vendor relationship, a recordkeeping issue, or an automated decision risk.


    The Limits of an AI Policy

    Many organizations respond to AI risk by writing an acceptable use policy. That is a necessary starting point, but it is not a control program. A policy may say sensitive data cannot be entered into unapproved tools, but a compliance program needs technical enforcement, monitoring, approved-use inventories, training records, vendor review, retention controls, and incident response procedures.

    The control gap appears when an organization can state its rule but cannot prove that the rule is being followed. This is one of the central problems with enterprise AI adoption. AI usage can spread through browsers, SaaS features, API integrations, productivity tools, development environments, and shadow workflows long before the compliance team has a full inventory.

    A mature program must treat AI use as a governed business process. That means every approved use case should have an owner, a purpose, a permitted data boundary, a logging model, a vendor review record, and a defined path for escalation. Without that level of structure, AI policy becomes aspirational rather than auditable.


    Data Governance Becomes Harder

    AI systems can consume, transform, retain, infer, and expose data in ways that differ from traditional applications. A conventional SaaS tool usually has predictable fields, database tables, access permissions, and logging structures. An AI system may accept free-form prompts, ingest uploaded files, retrieve internal documents through retrieval-augmented generation, produce generated outputs containing regulated information, and store interaction history for review or model improvement.

    That makes data classification harder. It also makes data minimization harder.

    For privacy and compliance teams, the key issue is that AI can blur the line between source data, derived data, metadata, and output. A prompt containing protected health information, financial data, trade secrets, export-controlled technical data, or employee records may create several compliance artifacts at once: input data, vendor-processed data, model context, log data, generated content, and downstream business records.

    Healthcare provides a clear example. The HIPAA Security Rule requires covered entities and business associates to protect electronic protected health information through administrative, physical, and technical safeguards tied to confidentiality, integrity, and availability. An AI tool used in a healthcare workflow must be evaluated against those same safeguard expectations when it creates, receives, maintains, or transmits ePHI.

    This creates practical questions that must be answered before deployment. Can users submit patient data? Is the vendor a business associate? Are prompts retained? Are outputs stored in the medical record? Are logs protected at the same level as the source data? Can the organization retrieve evidence after an incident or audit? The answers determine whether the AI use case is a minor productivity tool or a regulated system component.


    Automated Decisions Raise Legal and Audit Risk

    AI becomes much more sensitive when it influences decisions about people. That includes hiring, promotion, lending, insurance, education, healthcare, benefits, fraud review, law enforcement, housing, access to services, and other consequential processes.

    GDPR Article 22 gives individuals rights related to decisions based solely on automated processing, including profiling, when those decisions produce legal effects or similarly significant effects. This creates a compliance burden for organizations using AI systems that rank, score, recommend, approve, deny, or prioritize individuals.

    The hard part is not just the legal classification of the tool. It is proving the actual role AI plays in the workflow. An organization may describe an AI system as “decision support,” but that label means little if human reviewers accept the output by default. Compliance teams need to understand whether humans are independently reviewing AI output, whether they have enough information to challenge it, whether overrides are tracked, and whether affected individuals have a path to contest the result.

    This makes human review an evidence problem. It is not enough to say that a person stays in the loop. The organization needs records that show who reviewed the output, what information they had, what decision they made, whether they changed the AI recommendation, and how exceptions were handled.


    Vendor Risk Expands Across the AI Supply Chain

    Most organizations adopting AI are not building foundation models from scratch. They are licensing models, connecting to APIs, using AI features inside existing SaaS products, deploying open-source models, or relying on cloud providers for AI infrastructure. This creates a dependency chain that may include the model provider, cloud host, embedding model, vector database, application vendor, plug-in provider, monitoring service, and third-party data source.

    Traditional vendor reviews still matter. SOC 2 reports, penetration tests, privacy policies, breach notification terms, encryption controls, subprocessors, and data residency terms remain relevant. AI adds questions many third-party risk processes were not built to ask.

    Does the vendor train on customer prompts? Are customer prompts retained? Can retention be disabled? Where are embeddings stored? Are prompts and outputs encrypted and logged? Which subprocessors support the AI feature? How does the vendor test for prompt injection, data poisoning, insecure output handling, and excessive agency? What happens when the model provider changes the model version? Can the customer obtain audit logs showing who used the tool and what data was submitted?

    The OWASP Top 10 for LLM Applications identifies major risks for LLM-based systems, including prompt injection, sensitive information disclosure, supply chain issues, insecure output handling, and excessive agency. These are security risks, but they also create compliance risk. A prompt injection attack against an internal AI assistant can become a confidentiality failure. A poisoned knowledge base can become a processing integrity failure. Excessive agency can become an access control failure if an AI agent can send emails, modify tickets, query databases, or trigger workflows without meaningful approval.


    Approved Platforms Can Still Create New AI Risk

    Many compliance programs rely on inherited controls from cloud providers, SaaS vendors, identity providers, endpoint tools, logging platforms, and managed service providers. AI complicates those assumptions.

    A vendor may have strong infrastructure controls but weak prompt logging segregation. A cloud platform may meet baseline security requirements, yet the application team may connect a model to sensitive internal documents without proper entitlement checks. A SaaS provider may offer an AI feature inside an already-approved platform, but that feature may introduce different data processing, retention, and subprocessors.

    This is a major issue for SOC 2, ISO 27001, HIPAA, GLBA, PCI DSS, CMMC, FedRAMP, and internal audit programs. The existence of an approved platform does not automatically mean every AI feature inside that platform is approved for every data type. Compliance teams need to treat AI capabilities as functional changes that can alter system boundaries, data flows, control objectives, and evidence requirements.


    AI Change Management Is Difficult to Control

    AI systems change more often than traditional applications. Models are updated. Prompts are modified. Retrieval sources are expanded. Connectors are added. Guardrails are tuned. Users discover new ways to interact with the tool. A small prompt change can alter output behavior. A new document source can expose restricted records. A model upgrade can change accuracy, refusal behavior, or data extraction patterns. A new plug-in can turn a chatbot into an action-taking agent.

    This creates friction with audit models that expect stable systems over a defined review period. A SOC 2 Type II examination, for example, evaluates whether controls operated over time. If an AI workflow changes every few weeks without formal approval, testing, and documentation, the organization may struggle to prove that controls operated consistently.

    AI change management needs model version tracking, prompt versioning, retrieval source approvals, test results, rollback procedures, and defined ownership. Without that structure, teams may ship AI changes faster than compliance can verify them.


    AI Output Creates Recordkeeping and Accuracy Concerns

    AI-generated content can be plausible, useful, and wrong at the same time. That matters for regulated communications, legal records, financial reporting, vulnerability management, clinical documentation, customer support, and public claims.

    Compliance programs often assume that business records are created by humans or deterministic systems. AI introduces generated records that may contain unsupported statements, incorrect summaries, omitted facts, fabricated citations, or inaccurate technical guidance. This creates review obligations for any workflow where AI output becomes part of a record, customer communication, audit artifact, incident report, medical note, legal analysis, or public statement.

    Organizations also need controls around claims they make about AI. The SEC announced settled charges in 2024 against two investment advisers for false and misleading statements about their use of AI, with the firms agreeing to pay $400,000 in total civil penalties. The FTC also announced Operation AI Comply in 2024, targeting deceptive AI claims and AI-enabled schemes.

    This means compliance teams must review both AI use and AI-related representations. Marketing language, investor materials, customer contracts, product pages, sales decks, and security questionnaires should not overstate model capability, autonomy, accuracy, or security.


    Sector-Specific Rules Add More Pressure

    AI compliance is not governed by one unified legal regime in the United States. It is spread across privacy law, consumer protection, employment law, financial regulation, healthcare regulation, cybersecurity regulation, state law, contract law, and industry standards.

    Employment is one of the clearest examples. New York City’s Local Law 144 restricts employer use of automated employment decision tools unless the tool has undergone a bias audit within one year of use, the audit summary is publicly available, and required notices have been provided to candidates or employees. This type of rule changes how organizations must evaluate AI tools used for screening, scoring, ranking, interviewing, promotion, or workforce analytics.

    Financial services face similar pressure. Regulators expect firms to maintain governance over AI-enabled communications, recommendations, surveillance, recordkeeping, and customer-facing tools. Healthcare organizations must evaluate AI through privacy, security, patient safety, clinical documentation, business associate, and breach notification requirements. Government contractors may face AI-related obligations tied to data handling, controlled unclassified information, export control, and federal system security requirements.

    The compliance burden depends on the use case. AI used to rewrite internal marketing copy does not carry the same risk as AI used to rank job applicants, triage patients, approve financial transactions, generate legal advice, or operate inside a security workflow.


    International Regulation Is Changing the Compliance Baseline

    Multinational organizations face another layer of complexity: AI rules differ across jurisdictions. The EU AI Act entered into force on August 1, 2024, and the European Commission states that it will be fully applicable on August 2, 2026, with certain exceptions. The Act uses a risk-based structure, with obligations that vary based on the type of AI system and the context in which it is used.

    This creates a mapping problem. The same AI system may need to satisfy EU AI Act requirements, GDPR requirements, U.S. state privacy requirements, sector rules, customer contract clauses, and internal risk standards. A chatbot used for basic customer service may be lower risk in one context, but a similar system used for employment, benefits, healthcare triage, education, credit, or law enforcement may trigger much heavier obligations.

    Compliance teams need a use-case inventory that classifies AI by purpose, affected population, data type, decision impact, autonomy level, vendor, jurisdiction, and control owner. Without that inventory, organizations may not know which AI systems fall into higher-risk categories until a customer, regulator, auditor, or plaintiff’s counsel asks.


    Audit Evidence Must Cover the Full AI Lifecycle

    AI controls must be provable. It is not enough to say that an AI tool has human review if the organization cannot show review logs, approval records, reviewer training, sampling results, and escalation history. It is not enough to say prompts are filtered if no one tests bypass attempts. It is not enough to say data is not used for training if vendor contracts, settings, and technical logs do not support that statement. It is not enough to say a model is accurate if testing was performed once during procurement and never repeated after model, data, or workflow changes.

    A mature AI compliance program needs evidence across the full lifecycle. That includes intake forms for new AI use cases, data protection impact assessments, model and vendor due diligence, approved data categories, access controls, prompt and output logging rules, retention schedules, test plans, red team results, bias assessments, human review records, incident tickets, customer notices, contractual terms, and executive risk acceptance.

    ISO/IEC 42001 provides requirements and guidance for establishing, implementing, maintaining, and improving an AI management system. This type of management-system approach is useful since AI governance cannot be limited to one-time approval. It needs defined processes, owners, evidence, review cycles, and improvement mechanisms.


    Security Controls Must Be Part of AI Compliance

    AI compliance cannot sit apart from security architecture. The same systems that create privacy, audit, and governance concerns also create technical attack surfaces. Prompt injection, insecure plug-ins, weak retrieval controls, excessive permissions, exposed API keys, training data poisoning, model supply chain issues, and unvalidated outputs can all create compliance failures.

    AI controls should map into existing security domains: identity and access management, data loss prevention, logging, encryption, network segmentation, software supply chain security, vulnerability management, incident response, third-party risk, and secure development. AI does not replace those control families. It adds new failure modes that must be incorporated into them.

    For internal AI applications, retrieval access should follow existing authorization. A user should not be able to retrieve sensitive documents through an AI assistant if they could not access those documents directly. For AI agents, tool permissions should be constrained by role, approval gates, transaction limits, and logging. For developer tools, generated code should still pass secure code review, dependency scanning, secret detection, and vulnerability testing.


    Building a Practical AI Compliance Program

    A practical AI compliance program starts with inventory. Organizations need a central record of approved and unapproved AI use cases, including user-facing tools, embedded SaaS AI features, developer tools, analytics tools, chatbots, internal copilots, AI agents, model APIs, open-source models, and vendor-provided automation. Each entry should identify business owner, system owner, data owner, vendor, model type, hosting location, data categories, user population, connected systems, output use, and decision impact.

    The next step is classification. AI use should be tiered by risk. A tool used to rewrite internal copy does not need the same control depth as a tool used to rank job applicants, generate clinical summaries, approve transactions, produce security findings, or interact with customers about regulated services. Risk tiering should account for data sensitivity, affected individuals, autonomy, reversibility, legal impact, safety impact, external exposure, and operational dependency.

    The third step is technical enforcement. Controls should restrict which AI tools can be accessed, what data can be submitted, which users can connect sensitive repositories, and which outputs can trigger downstream actions. Browser controls, CASB or SASE tooling, DLP, API gateways, identity policies, endpoint telemetry, and logging pipelines can help detect shadow AI use and enforce approved paths.

    The fourth step is documentation and testing. Each production AI use case should have a documented intended purpose, permitted data, prohibited data, model and vendor details, known limitations, evaluation criteria, human review requirements, monitoring plan, incident path, and retirement criteria. Testing should cover accuracy, bias, security abuse cases, privacy leakage, prompt injection, data poisoning exposure, output handling, and business process failure. For agentic workflows, testing should also cover tool permissions, approval gates, rate limits, transaction caps, and rollback.

    The fifth step is ongoing monitoring. AI compliance cannot be assessed once and left untouched. Models, prompts, retrieval data, users, regulations, and business processes change. Monitoring should include usage analytics, anomalous prompt patterns, sensitive data submission, output sampling, user feedback, vendor change notices, model version changes, and periodic control testing. Compliance review should be tied to actual use, not procurement records alone.


    The New Compliance Question

    AI use creates new compliance challenges since it changes the evidence model. Organizations must prove far more than policy acceptance. They must prove control over data, vendors, models, prompts, outputs, decisions, logs, and actions.

    The organizations that handle this well will not treat AI governance as a separate paperwork exercise. They will connect AI oversight directly to privacy, security, legal, audit, procurement, software development, data governance, and enterprise risk management.

    The core compliance question has changed. It is no longer just, “Did we approve this system?” It is now, “Can we prove what this AI system did, what it had access to, why it produced the result it produced, who reviewed it, what controls constrained it, and what evidence we can produce when challenged?”

    That is the new compliance burden created by AI use.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • Netizen: Monday Security Brief (6/29/2026)

    Today’s Topics:

    • Squidbleed Shows Why Old Proxy Code Still Belongs in the Threat Model
    • FortiBleed Shows Why Firewall Credentials Are Now Perimeter Risk
    • How can Netizen help?

    Squidbleed Shows Why Old Proxy Code Still Belongs in the Threat Model

    Squidbleed is the kind of vulnerability that looks small in code and much larger in an environment diagram. Tracked as CVE-2026-47729, the flaw is an out-of-bounds read in Squid’s FTP gateway that can leak fragments of proxy memory back to a client. In the worst case, that memory may contain another user’s cleartext HTTP request, including an Authorization header, bearer token, API key, session cookie, or other credential material that was never meant to leave the proxy process.

    The bug is being compared to Heartbleed for a reason. This is not remote code execution. It does not give an attacker shell access, modify traffic, or knock the service offline. It reads memory past the intended boundary and returns data that should have stayed inside the process. That makes the vulnerability easier to underrate if teams focus only on exploit categories, yet memory disclosure against a shared proxy can still be a direct path to account takeover. If a leaked header contains a valid token, the attacker does not need to exploit the victim’s endpoint. They can simply reuse what the proxy exposed.

    The threat model is narrow, but realistic. Squid describes the attacker as a trusted client, meaning someone already permitted to send traffic through the proxy. That matters in environments where Squid is used as a shared forward proxy for schools, enterprises, guest networks, public Wi-Fi, managed networks, or filtering gateways. The attacker does not need to be an external internet host hitting Squid from the outside. They need access as a proxy user, a Squid instance with FTP gateway functionality available, and an FTP server they control or can influence.

    That limitation is also what makes the bug easy to miss during risk scoring. CVSS places it in the moderate range with network attack vector, low attack complexity, low privileges required, no user interaction, high confidentiality impact, and no integrity or availability impact. On paper, that looks contained. In practice, a shared proxy is a collection point for other people’s requests. A confidentiality-only vulnerability in that position can still expose high-value secrets.

    The exposed traffic is also bounded. Standard HTTPS traffic sent through an HTTP CONNECT tunnel remains opaque to Squid, so Squidbleed does not magically decrypt the modern web. The most direct exposure is cleartext HTTP. The risk expands in deployments where Squid is configured to terminate or inspect TLS, such as SSL Bump environments, since the proxy can then see decrypted request contents before forwarding them upstream. Legacy internal applications, captive portals, old appliances, device management pages, and operational tools are the kinds of places where cleartext HTTP still tends to survive longer than security teams expect.

    The root cause sits in Squid’s FTP directory-listing parser. FTP directory listings are messy, old, and inconsistent across server implementations, so Squid contains parsing logic meant to turn FTP listings into something usable for clients. The vulnerable behavior traces back to compatibility handling introduced in 1997 for NetWare-style listings, where extra whitespace could appear between a timestamp and a filename.

    The parser advances a pointer after a parsed timestamp and then skips whitespace before treating the next bytes as the filename. The edge case appears when a crafted FTP listing line ends right after the timestamp and provides no filename at all. At that point, the pointer lands on the string terminator. The relevant C library behavior is the catch: strchr can match the terminating null byte in a string. If code asks whether that terminator appears inside the whitespace string, it can get a positive result. The parser then advances past the end of the intended buffer and keeps reading until it finds a byte that stops the scan.

    That is where an old parser bug turns into a data exposure issue. Squid reuses memory buffers, and reused heap memory may still contain data from prior transactions. If a buffer recently held part of a different user’s HTTP request, a crafted FTP listing can overwrite only a small portion of that buffer and cause Squid to return the remaining stale bytes as if they were part of an FTP filename. The attacker sees the data in the generated FTP directory response.

    Calif.io’s demonstration showed an Authorization header leaking from another client using the same proxy. That is the security impact in one line: a user who is allowed to use the proxy may be able to trigger a malformed FTP response and receive secrets from unrelated traffic handled by the same Squid process.

    The fix itself is small. Squid patched the FTP gateway parsing logic by checking for the null terminator before using the character membership test that caused the over-read. The official advisory lists Squid versions older than 7.6 as affected, with Squid 4.x, 5.x, 6.x, and 7.x through 7.5 vulnerable. Squid versions older than 3.5.28 were not tested and should be treated as vulnerable. Operators using vendor-packaged builds should rely on distribution advisories and backported package fixes rather than only checking the upstream version string.

    That distinction matters. Enterprise Linux distributions often backport security patches into older package versions. An environment may still show a Squid 5.x or 6.x package and be patched, or it may show a seemingly familiar package version that still lacks the fix. Ubuntu, for example, lists fixed Squid packages for supported releases such as 22.04 LTS and 24.04 LTS. Debian’s tracker shows fixed status for some releases and vulnerable status for others. The right validation step is to confirm the vendor package status or inspect whether the FtpGateway.cc guard is present.

    The better mitigation, where operations allow it, is to disable FTP through Squid entirely. FTP is a legacy protocol with little place in most modern browser-driven networks. Chrome removed FTP URL support years ago, and many organizations have little legitimate need for proxy-mediated FTP access. Squid’s own advisory provides a workaround that denies FTP traffic through the proxy, with an optional allowlist for trusted FTP destinations. In many networks, the safer answer is no allowlist at all.

    Blocking outbound TCP port 21 from the proxy can also reduce practical exploitability, but it should be treated as a compensating control rather than the full fix. A proxy policy change inside squid.conf is more direct, and a patched package removes the parser bug itself. Organizations should also review whether Squid is performing TLS interception, whether cleartext HTTP remains in use internally, and whether proxy users are segmented by trust level. A guest network user and a corporate endpoint should not be sharing sensitive proxy memory in the same risk bucket.

    Detection is not straightforward. A successful attempt may look like FTP traffic through Squid to an attacker-controlled server, followed by abnormal directory listing responses. Security teams can review Squid access logs for unexpected ftp:// requests, outbound connections to untrusted FTP servers, and spikes of repeated FTP listing activity from a single proxy client. Network controls can flag outbound FTP from proxy infrastructure, especially in environments that do not use FTP operationally. Still, the absence of obvious logs should not be treated as proof of safety. Memory disclosure vulnerabilities rarely leave clean, high-confidence forensic markers.

    The incident response question is less about wiping systems and more about credential exposure. If an organization confirms exploitability or suspicious FTP traffic through a vulnerable Squid instance, it should identify which applications and internal services still sent cleartext HTTP through that proxy. Tokens, API keys, basic authentication headers, session cookies, and service credentials exposed over HTTP should be rotated. Legacy internal applications that still rely on cleartext authentication deserve extra attention, as they are exactly the kind of systems that turn a moderate proxy bug into a real identity problem.

    Squidbleed also says something broader about aging internet infrastructure. The vulnerable logic survived for nearly three decades in a mature, widely deployed open-source proxy. It sat in compatibility code for an old FTP listing format tied to platforms most modern defenders will never touch. That is not an indictment of Squid alone. It is a reminder that mature software often carries protocol support, parser logic, and compatibility branches that outlive their original use case by decades.

    The AI angle is real, but it should not be exaggerated. Calif.io credited Anthropic’s Claude Mythos Preview with surfacing the strchr behavior quickly during research into Squid’s FTP state machine. That does not mean AI agents are suddenly replacing security engineering. It means they are becoming useful at finding weird interactions between old parser code, language semantics, and forgotten protocol features. For defenders, the lesson is practical: AI-assisted review may be most valuable in the code nobody wants to audit by hand anymore.


    FortiBleed Shows Why Firewall Credentials Are Now Perimeter Risk

    FortiBleed is not being treated as a new Fortinet zero-day, and that may be the most useful detail in the story. The campaign is larger than a single vulnerability bulletin. It is a credential problem at perimeter scale, involving internet-facing FortiGate firewalls and SSL VPN gateways where valid logins, old password hashes, weak account hygiene, and exposed management paths appear to have converged into a large verified access dataset.

    CISA issued guidance after reports that malicious actors were using compromised credentials against Fortinet devices across government and private-sector networks. The public numbers vary by source and date. CISA referenced leaked credentials tied to about 74,000 Fortinet devices. SOCRadar later reported 86,644 compromised FortiGate devices, more than 80,000 unique IPs, 22,405 domains, and exposure across 194 countries. Arctic Wolf placed the confirmed range between 30,000 and 75,000 devices in its June analysis, citing differences in dataset validation and source reporting. The exact count matters less than the operating model: the actors were not guessing at a few exposed VPN portals. They were building a verified inventory of working perimeter credentials.

    Fortinet has pushed back on the idea that FortiBleed is tied to a new product flaw. In its June 19 PSIRT post, the company said the activity appears to involve reused credentials from prior incidents and brute-force activity against devices with weak password hygiene and no MFA. Fortinet also said it was not related to any current incident or advisory. That distinction is technically meaningful. It also should not make defenders comfortable. A valid firewall login obtained through credential reuse can be just as operationally useful as access gained through an exploit chain.

    The risk starts with what FortiGate devices are. These appliances often sit at the boundary between the public internet and internal networks. They terminate VPN access, enforce firewall policy, route traffic, hold certificates, connect to identity providers, and often integrate with Active Directory, LDAP, RADIUS, TACACS+, SAML, or other authentication systems. Administrative access to that control plane gives an attacker far more than a login screen. It can provide network topology, user access paths, VPN visibility, configuration data, and a starting point for lateral movement.

    SOCRadar described FortiBleed as an automated operation built in two stages. The first stage tests curated username and password combinations against internet-facing Fortinet endpoints. The second stage reportedly uses successful access to collect more credentials from traffic passing through the device, feeding those credentials back into the same access operation. Dutch NCSC also warned that researchers had seen attackers collect packet captures from Fortinet systems in several cases, creating the possibility that more authentication material was exposed after initial firewall access.

    That is what makes this different from a normal credential stuffing story. The firewall is not just the target. Once compromised, it can become a collection point. A compromised SSL VPN or firewall appliance may expose user names, VPN sessions, internal addressing, authentication integrations, service accounts, and administrative behavior. If the appliance is tied into directory services, the downstream risk moves into identity infrastructure. Fortinet’s own guidance says that if AD or LDAP integration is configured, that account should be treated as compromised and monitored for use elsewhere.

    The older credential storage behavior adds another layer. Fortinet’s technical guidance says FortiOS 7.2.11, 7.4.8, and 7.6.1 introduced PBKDF2 for administrator password storage, replacing SHA-256-based storage. The migration is conditional. After an upgrade from an older version, administrator passwords can remain stored as SHA-256 hashes until the corresponding administrator logs in after the upgrade. Fortinet also notes that older SHA-256 values may remain in a hidden old-password setting for backward compatibility, visible in configuration backups taken by a super admin account.

    That matters for two reasons. First, SHA-256 is fast. Fast hashing is bad for password storage when an attacker can obtain hashes and work offline with GPU cracking rigs. Second, many organizations treat firmware upgrades as complete once the version number changes. In this case, the version number alone may not remove the weaker stored credential material. Admin logins, password resets, and Fortinet’s weaker-encryption lockout setting may still be needed to move accounts away from legacy hash exposure.

    This is why “patch and move on” is too narrow here. Updating FortiOS is part of the response, but FortiBleed is about credential state, session state, configuration state, and exposure state. A firewall can be on a newer train and still carry old credential baggage. A password can be complex and still be compromised if it was reused, leaked, harvested from an earlier incident, or cracked from a stored hash. An admin interface can be patched and still risky if it remains reachable from the public internet.

    The account patterns reported by SOCRadar point to basic but damaging failures. Generic admin accounts and Fortinet system-style accounts accounted for a large share of the exposed credentials. Organization-specific accounts also made up a significant portion of the dataset, which suggests the campaign reached beyond factory naming conventions and default behavior. This is a familiar perimeter problem: predictable account names reduce attacker cost, password reuse extends breach life, and exposed management interfaces let attackers test access at internet scale.

    For attackers, a valid FortiGate credential can be more valuable than a workstation foothold. It may allow rule changes, VPN account creation, configuration export, traffic capture, route manipulation, certificate inspection, logging changes, and stealthy access maintenance. A firewall is also a trust anchor in many environments. Security tools often assume it is enforcing policy correctly. If an attacker controls or modifies that enforcement point, detections inside the network may see only the later stages of an intrusion.

    That is the defensive lesson. FortiBleed should be treated as an identity incident and a perimeter device incident at the same time. Ending active SSL VPN and administrative sessions is the containment step that breaks live access. Password resets address known and unknown credential exposure. MFA limits replay. PBKDF2 migration reduces the value of stolen configuration hashes. Management access restrictions reduce the number of systems attackers can test. Log review determines whether the appliance was just exposed or actually used as a pivot.

    The log review should be wide. Firewall and VPN logs can show unexpected administrator access, unfamiliar source IPs, strange login times, failed sprays, successful logins after long dormancy, new local users, password resets, policy changes, route changes, certificate changes, and configuration exports. Domain controller and identity logs can show lateral movement after the perimeter event, such as unusual use of LDAP bind accounts, new privileged accounts, VPN users authenticating from rare geographies, or service accounts appearing outside their normal pattern. Configuration comparison against a known-good backup can catch subtle persistence that normal event review may miss.

    The response also needs to cover more than human administrator passwords. Local Fortinet administrators, VPN users, API accounts, service accounts, LDAP and RADIUS bind accounts, TACACS+ secrets, SAML-related credentials, shared accounts, and any reused credentials on adjacent edge devices should be rotated where exposure is plausible. If packet capture or traffic inspection occurred, downstream application credentials may also need review. Treating this as a single admin password reset can leave the real blast radius untouched.

    Management exposure is another core issue. Fortinet recommends trusted hosts as a baseline, local-in policy as a stronger control, and removal of internet administration as the preferred end state. That hierarchy is correct. Internet-facing firewall administration creates a public test surface for credential abuse. Even with MFA, every exposed login endpoint becomes an opportunity for enumeration, spraying, social engineering follow-up, and future vulnerability exploitation. Admin access should be reachable through controlled management networks, jump hosts, VPN paths with strong MFA, and explicit source restrictions.

    This incident also fits a broader pattern. Perimeter appliances have become high-value identity targets, not just vulnerability targets. Attackers do not always need a new exploit if they can reuse credentials from an old one. They do not need malware on an endpoint if a firewall hands them remote access. They do not need to decrypt the whole network if the gateway already sees enough traffic to collect the next set of secrets. FortiBleed shows how yesterday’s breach data, today’s exposed management interface, and legacy password storage can combine into a current intrusion path.

    The name makes the campaign sound like a single wound. The real problem is more structural. Many organizations still operate perimeter devices as static infrastructure, patched on a schedule and checked during audits, rather than as identity-bearing systems that need continuous credential rotation, configuration drift review, management-plane isolation, and telemetry. A firewall is not just a box that filters traffic. It is a privileged identity system with routes, secrets, sessions, and trust relationships attached to it.

    For Fortinet customers, the near-term answer is clear: terminate sessions, rotate credentials, confirm MFA, upgrade to supported FortiOS branches, force PBKDF2 migration, remove legacy hashes, review logs, compare configurations, and restrict management access. For any environment with signs of unauthorized configuration changes, unexpected accounts, suspicious VPN activity, or packet capture use, treat the appliance as compromised and investigate internal movement from that point forward.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • The Growing Market for Stolen Browser Data

    The modern browser has become one of the most valuable data repositories in the enterprise. It stores passwords, cookies, active sessions, autofill fields, saved payment details, authentication tokens, browsing history, device identifiers, and traces of nearly every cloud platform a user touches during the workday. For attackers, that makes the browser less like a utility and more like a portable identity vault.

    The market for stolen browser data has grown around that reality. Criminal marketplaces no longer need to sell only usernames and passwords. They can sell full identity packages: the credential, the session cookie, the login URL, the user’s device metadata, the browser profile, the local context, and sometimes the victim’s screenshot at the time of infection. That combination gives buyers more than a password. It gives them the ability to impersonate a real user with less friction, fewer alerts, and a greater chance of bypassing traditional authentication controls.

    This shift is changing the economics of cybercrime. A single endpoint infection can produce dozens of usable credentials across corporate applications, personal accounts, VPN portals, cloud consoles, developer tools, email platforms, password managers, and SaaS environments. The infected machine does not need to belong to a domain administrator to create enterprise risk. A personal device used to check work email, log into Microsoft 365, access a ticketing system, or authenticate into a cloud dashboard can produce enough browser data to become the first step in a larger intrusion.

    The result is a market where browser data has become a raw material for account takeover, fraud, ransomware, data extortion, identity abuse, and initial access brokerage.


    What Stolen Browser Data Actually Contains

    The phrase “stolen credentials” can understate the issue. Infostealer malware is usually built to extract a much broader set of browser artifacts. A typical stealer log may contain saved usernames and passwords, authentication cookies, session tokens, autofill data, browser history, downloaded file history, cryptocurrency wallet files, local application data, screenshots, hostnames, IP addresses, operating system details, installed software, and browser profile metadata.

    This matters since the value of the log is tied to context. A password by itself may be blocked by MFA, conditional access, password rotation, or impossible-travel detection. A session cookie can be more useful to an attacker since it may represent a session that already passed MFA. A login URL tells the buyer what service the credential belongs to. Device metadata helps the attacker reproduce the victim’s environment. Browser history can reveal which applications the victim uses, which administrative portals are active, and which organizations may be linked to the account.

    A stealer log, then, is not just a list of secrets. It is a snapshot of the user’s digital working environment.

    This is one reason browser data is so attractive to downstream criminals. A buyer can search a marketplace for logs tied to a target domain, a cloud provider, a bank, a cryptocurrency service, an RMM platform, a VPN appliance, or a government email address. The buyer does not need to run the malware campaign personally. They can purchase the output of someone else’s infection operation and focus on exploitation.

    That division of labor has made stolen browser data a core component of cybercrime supply chains.


    How the Market Became Industrialized

    The infostealer market has matured into a service economy. Developers build and maintain malware families. Affiliates distribute them through phishing, cracked software, fake browser updates, malicious ads, search engine poisoning, Discord lures, game cheats, fake AI tools, and compromised websites. Log sellers aggregate the stolen data. Marketplaces index it. Initial access brokers turn selected entries into enterprise intrusion opportunities. Fraud actors use the same data for bank, crypto, email, and social account takeover.

    This model scales. The person who infects a machine is often not the person who uses the stolen session. The operator who runs the stealer may sell raw logs in bulk. Another actor may parse those logs for corporate domains. A third actor may test credentials against VPN, SSO, or cloud portals. A ransomware affiliate may purchase only the subset of access that supports lateral movement or data theft.

    Markets such as Genesis Market, Russian Market, 2easy, Telegram-based log shops, and invite-only criminal forums helped normalize this structure. Genesis was especially significant since it packaged credentials together with browser cookies and device fingerprints. That model allowed buyers to impersonate victims more convincingly by making their access attempts look closer to the original user’s browser and device profile.

    Even after takedowns, the model persists. Criminal infrastructure is disrupted, operators lose domains, servers are seized, and some users are arrested, but the market adapts. New shops appear, existing shops absorb demand, sellers shift channels, and malware families are rebranded or replaced. The demand side remains strong since the product solves a central attacker problem: getting valid access without burning time on exploitation.


    Why Session Cookies Changed the Value of the Market

    MFA changed the economics of password theft. It did not end credential abuse, but it reduced the usefulness of a password in isolation. Infostealer operators responded by placing more value on session material.

    A session cookie is powerful since it can prove to an application that a user has already authenticated. In many environments, the application does not challenge the user again until the session expires, the risk score changes, or the token is revoked. If an attacker can replay that session from a compatible environment, they may avoid the login sequence entirely.

    This is why stolen browser data is often more dangerous than breached password data. A reused password may trigger MFA. A session artifact may bypass the MFA step entirely. A password reset may not invalidate every active session. A user may change a password and still remain logged in across browsers, mobile apps, and SaaS sessions. If incident response focuses only on password rotation, the attacker may keep access through tokens or cookies that were never invalidated.

    This also changes detection. A brute-force attempt, impossible travel event, or failed MFA challenge can stand out. A replayed session may look like normal post-authentication activity, particularly when the attacker uses residential proxies, browser automation, stolen fingerprints, or infrastructure near the victim’s region. From the application’s view, the attacker may appear to be an already authenticated user returning to an active session.

    That makes stolen browser data an identity-layer problem rather than a malware problem alone.


    Infostealers as an Initial Access Pipeline

    Infostealers are often treated as commodity malware, but their downstream use can be far more serious than the initial infection suggests. A user may download a fake software installer on a personal laptop. The stealer runs for seconds, extracts browser data, sends a compressed archive to a command-and-control server, and exits. The endpoint may never touch a corporate network. No ransomware runs. No lateral movement occurs at the time of infection.

    The enterprise impact begins later.

    If the user has logged into corporate SaaS from that machine, the stolen log may contain access to email, SSO, VPN, cloud storage, CRM, source code repositories, ticketing systems, payroll systems, or administrator portals. A broker can identify those entries and sell them to a buyer focused on enterprise compromise. That buyer may then use the access to enumerate internal data, create OAuth grants, register MFA devices, add inbox rules, access cloud files, or pivot into other systems.

    This creates a delayed blast radius. The infection event and the breach event may be separated by hours, days, or weeks. Security teams may clean the endpoint without knowing that its browser data has already entered an underground market. A password reset may occur after the session has already been replayed. A user may have no sign that their browser profile has become an access package.

    The market thrives on that delay.


    The Role of Personal Devices and Identity Sprawl

    The stolen browser data problem is made worse by identity sprawl. Users mix personal and professional browsing. They access work applications from unmanaged devices. They save corporate credentials in consumer browsers. They reuse passwords across personal accounts and work-adjacent tools. Contractors, vendors, executives, developers, and remote workers may all create exposure outside managed endpoint telemetry.

    This breaks many defensive assumptions. An organization may have strong EDR coverage on corporate laptops, but no visibility into a personal system used to access cloud email. It may enforce MFA, but allow long-lived browser sessions. It may centralize SSO, but still permit unmanaged devices for certain SaaS platforms. It may rotate passwords, but leave OAuth tokens and active sessions untouched.

    Developers introduce another high-value exposure point. Browser data on a developer workstation may include access to GitHub, GitLab, CI/CD platforms, package registries, cloud consoles, secrets managers, issue trackers, and internal documentation. A stolen browser profile from one developer can expose code, deployment workflows, API keys, infrastructure credentials, and third-party integrations.

    For executives, the risk is different but just as severe. Browser sessions may expose email, financial systems, HR platforms, board materials, legal correspondence, and approval workflows. Attackers can use that access for fraud, business email compromise, extortion, or reconnaissance.

    The common thread is that the browser has become a bridge between human identity and enterprise systems.


    Why Marketplace Data Is Hard to Defend Against

    Stolen browser data creates several problems for defenders.

    The first is speed. Stealer logs can be posted, indexed, searched, resold, and exploited quickly. By the time an organization learns that an employee’s credentials appeared in a log, the highest-value material may already have been used or resold.

    The second is attribution. A login using stolen session data may not look like malware activity. It may look like a user accessing a cloud service from a new IP, a familiar browser, or a plausible device profile. If the attacker uses a proxy close to the victim, location-based controls may not trigger.

    The third is scope. One infected machine can expose many identities across many platforms. Traditional incident response often treats credential compromise as an account-level event. Infostealer exposure has to be treated as a device-level identity spill. Every account, token, cookie, OAuth grant, API key, and saved login touched by that browser profile may be in scope.

    The fourth is data quality. Stealer logs are noisy. They may contain old passwords, expired cookies, personal accounts, duplicates, typos, and stale artifacts. Criminal buyers account for that by testing and filtering at scale. Defenders need a process that can triage exposure without creating alert fatigue.

    The fifth is ownership. Browser data often spans corporate and personal boundaries. A corporate security team may discover that a user’s personal Gmail, personal password manager, and work SSO were present in the same stealer log. That creates response, privacy, and policy issues that many organizations have not planned for.


    Browser Vendors Are Raising the Cost, but the Market Is Still Active

    Browser and platform vendors are responding. Chrome’s App-Bound Encryption on Windows was built to reduce the ability of same-user malware to decrypt cookies directly through standard operating system protections. Device Bound Session Credentials go further by tying session use to a device-held private key, making stolen cookies less useful when replayed elsewhere.

    These controls raise attacker cost. Malware may need higher privileges, browser injection, live session manipulation, or more advanced tradecraft. That makes some theft noisier and easier for endpoint tools to detect.

    Still, these protections do not remove the market overnight. Coverage depends on browser version, operating system, hardware support, enterprise configuration, and application-side adoption. Many applications still rely on long-lived bearer tokens. Many environments still allow unmanaged devices. Many users still install untrusted extensions, cracked software, fake updates, and malicious tools. Attackers can also shift from offline cookie replay to adversary-in-the-browser techniques, malicious extensions, remote control, OAuth abuse, device code phishing, or live proxying.

    Defender strategy has to assume that browser data will remain a target even as browser security improves.


    What Security Teams Should Do

    The right response is not just “train users better” or “turn on MFA.” Those controls matter, but the stolen browser data market exists in part since attackers have learned how to work around them.

    Security teams need to treat browser data as part of the identity attack surface. That starts with policy. Organizations should define which browsers are approved, which extensions are allowed, whether password saving is permitted, which devices can access corporate SaaS, and how long sessions can persist. Browser management should be handled through enterprise policy where possible, not left to individual user choice.

    Conditional access should enforce device health, compliance state, geography, risk score, and phishing-resistant MFA for sensitive applications. Access from unmanaged devices should be limited, isolated, or blocked for high-risk services. Persistent sessions should be shortened for privileged users and sensitive apps. Token revocation needs to be part of standard incident response, not a rare step taken only after confirmed account takeover.

    Endpoint controls should watch for browser data access patterns. Attempts to read browser credential stores, cookie databases, local storage, browser profile directories, or password manager data should be treated as high-signal behavior. Chrome App-Bound Encryption event logs, suspicious browser process injection, abnormal access to DPAPI-protected data, and execution from user-writable paths should all feed detection logic.

    Security teams should also monitor underground exposure. Infostealer intelligence can identify employee credentials, session-bearing logs, contractor exposure, and third-party access risk before a breach is confirmed. This has to be paired with an internal response workflow: identify the user, determine whether the device is managed, revoke active sessions, rotate passwords, review OAuth grants, inspect recent SaaS activity, check mailbox rules, audit MFA changes, and look for follow-on access.

    For SaaS applications, defenders should collect logs that show session creation, token refresh, device registration, OAuth consent, impossible travel, suspicious user agents, new inbox rules, mass downloads, administrative changes, and access from anonymization infrastructure. The key is to focus on post-authentication behavior. If attackers are logging in with valid sessions, the strongest signals may appear after access is granted.

    For privileged users, the bar should be higher. Administrators, executives, developers, finance staff, and help desk personnel should use phishing-resistant MFA, managed devices, tighter session lifetimes, stronger browser controls, and stricter extension policies. Their browser profiles should be treated as high-value assets.


    The Market Will Keep Growing

    The market for stolen browser data is growing since it fits the way modern organizations work. Enterprise identity has moved into SaaS. SaaS has moved into the browser. The browser has become the place where authentication, productivity, administration, development, and communication converge.

    Attackers follow concentration of value. A browser profile can contain access to email, cloud storage, code, finance, customer data, internal tickets, identity platforms, and administrative consoles. It can also contain the session artifacts needed to avoid some login challenges. That makes it one of the most efficient targets in the modern intrusion chain.

    The defensive model has to change in response. Password resets alone are not enough. MFA alone is not enough. EDR alone is not enough. Organizations need identity-aware endpoint telemetry, managed browser policy, session revocation playbooks, device-bound access, phishing-resistant authentication, SaaS log coverage, and dark web exposure monitoring tied to real response actions.

    Stolen browser data has become a marketplace product because it collapses the distance between infection and access. The attacker does not need to exploit the perimeter if the browser already contains the keys to the environment. That is why this market matters, and why browser security now belongs at the center of enterprise identity defense.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • The Next Software Supply Chain Problem May Not Be Code

    Software supply chain security has spent the last several years focused on source code, third-party packages, vulnerable libraries, and malicious dependencies. That focus made sense. Incidents like Log4Shell, dependency confusion, typosquatting, and compromised open-source packages made it clear that organizations needed better visibility into what their applications were built from.

    That visibility still matters. SBOMs, dependency scanning, signed artifacts, vulnerability intelligence, and secure development frameworks are now part of the baseline conversation for software risk. The problem is that attackers are also moving past the obvious target. The next major software supply chain failure may not begin with a vulnerable function, a poisoned library, or a malicious commit. It may begin with everything around the code.

    Modern software is no longer just written, reviewed, built, and shipped by people. It is assembled through CI/CD pipelines, package registries, GitHub Actions, build runners, signing keys, service accounts, AI coding assistants, secrets managers, release tokens, container builders, deployment automation, vendor portals, and third-party SaaS integrations. Every one of those pieces can influence what eventually runs in production. Every one of them can become a trust boundary.

    That is the part many organizations still underestimate. A clean code review does not prove that the build process was clean. A dependency scan does not prove that the package came from the expected workflow. An SBOM does not prove that runtime behavior matches what was declared at build time. A vendor security questionnaire does not prove that release automation cannot be bypassed. Supply chain risk has moved into the operational machinery that turns source code into deployed software.

    That shift changes the problem. The question is no longer just “what code are we using?” It is also “who or what was allowed to build it, sign it, publish it, modify it, and deploy it?”


    The Supply Chain Is the System That Produces the Software

    Many organizations still treat the software supply chain as a dependency inventory problem. They want to know which packages are present, which versions are vulnerable, and which vendors are connected to the product. That is a necessary starting point, but it is incomplete.

    A modern release path can include dozens of non-code decisions that materially affect risk. A workflow file can define what runs during a build. A package registry token can authorize a release. A GitHub Actions trigger can decide whether untrusted pull request input reaches a privileged job. A build runner can hold environment variables, cloud credentials, signing material, or deployment permissions. A release artifact can be produced outside the expected process and still appear legitimate to downstream consumers.

    From an attacker’s perspective, compromising the codebase is no longer the only path. It may not even be the easiest path. Stealing a publishing token can be more useful than landing a malicious pull request. Abusing a CI/CD workflow can be quieter than modifying application logic. Targeting a maintainer account can provide access that security tooling treats as normal. Manipulating the build process can place malicious behavior downstream without leaving obvious source-level evidence.

    This is why supply chain security has to expand past repository scanning. The repository is only one layer. The release pipeline, identity model, artifact store, and deployment path are also part of the product.


    The Nx Incident Showed the Risk Around Release Automation

    The 2025 Nx supply chain attack is a clear example of this shift. The issue was not simply that a malicious package appeared in npm. The more important lesson was how the release path became the attack path.

    Malicious versions of several Nx packages were published to npm after attackers exploited a GitHub Actions injection vulnerability and stole an npm publishing token. The packages were live for several hours and scanned user systems for sensitive data, including developer credentials and tokens. The payload also attempted to use local AI CLI tools, including Claude and Gemini, for reconnaissance and data exfiltration.

    That incident matters because it ties several supply chain trends together at once. The attacker did not need a conventional application vulnerability in a production system. They targeted automation, publishing authority, developer workstations, secrets, and AI-assisted tooling. The trust placed in a widely used package became the delivery mechanism.

    Nx later stated that the malicious packages lacked npm provenance signing, which helped identify that they did not come from the expected CI pipeline. That detail is important. Provenance did not prevent installation by itself, but it gave defenders a signal that the package did not match the normal release path. In a mature supply chain program, that signal should become enforceable policy rather than post-incident context.

    This is where many organizations are still behind. They may scan dependencies after installation, but they do not always block artifacts that lack expected provenance. They may require MFA for maintainers, but still rely on long-lived publish tokens. They may review source changes, but leave workflow files, release triggers, and build permissions under weaker control.

    The result is a supply chain model that trusts the final package more than it verifies the process that produced it.


    Provenance Is Becoming More Important Than Package Name

    For years, software trust has often been based on names and locations. Developers pull a package from npm, PyPI, Maven Central, GitHub, Docker Hub, or a vendor portal and assume that the package is what it claims to be. That model is fragile. Package names can be spoofed. Maintainer accounts can be compromised. Tokens can leak. Build jobs can be manipulated. Registries can host packages that are technically valid but operationally suspicious.

    Provenance changes the question. Instead of asking whether a package came from a known place, defenders can ask whether it was built by the expected workflow, from the expected repository, at the expected commit, under the expected identity.

    That distinction is becoming central to software supply chain security. A package name tells you what something claims to be. Provenance tells you how it came into existence. The second answer is much harder for an attacker to fake if the organization enforces it correctly.

    This is why trusted publishing, artifact attestations, Sigstore-style signing, and SLSA-aligned build controls are becoming more important. They help move the supply chain from implicit trust to verifiable trust. A signed artifact with build provenance gives security teams a way to connect a release to the process that created it. A short-lived OIDC publishing flow reduces the value of stolen long-lived tokens. A dedicated build environment reduces the risk of local developer machines becoming the release authority.

    None of this removes the need for code review or dependency scanning. It adds a missing control layer. Code can be safe and the release process can still be compromised. The inverse is also true: a package can look normal at the registry level and still fail provenance checks.

    The organizations that treat provenance as optional metadata will have a harder time detecting this type of attack. The organizations that treat provenance as a deployment requirement will have a stronger control point before malicious artifacts reach production.


    The Non-Human Identity Problem Is Growing

    The next supply chain problem may also be an identity problem.

    Software delivery is full of non-human identities. CI jobs authenticate to cloud providers. Build runners access artifact repositories. Deployment bots modify infrastructure. Package publishing workflows request tokens. Scanners read source code. Service accounts push container images. AI tools may access repositories, issue trackers, local files, terminal sessions, and internal documentation.

    These identities often have more reach than individual users. They may run across multiple projects. They may be exempt from normal MFA requirements. They may hold long-lived credentials. They may be poorly documented. They may lack clear ownership. In many environments, these accounts are treated as plumbing rather than privileged access.

    Attackers see the opposite. A non-human identity inside a build or release process is a high-value target. It can provide persistence, data access, publishing authority, cloud access, or deployment control. Compromising that identity can be more useful than compromising a single developer account.

    This is especially dangerous in CI/CD environments. A pipeline is usually trusted to run code, access secrets, fetch dependencies, build artifacts, sign releases, and deploy changes. If an attacker can influence the pipeline, they can often cross boundaries that would be blocked in a normal user session.

    The control model has to change. Release automation should not depend on broad, long-lived secrets stored in build systems. Workflows should use short-lived, scoped credentials where possible. Publishing should be bound to specific workflows and protected environments. Runners should be isolated by sensitivity. Secrets should not be exposed to untrusted pull request contexts. Build jobs should be treated like privileged production systems, not disposable developer conveniences.

    The supply chain is now an identity graph. Organizations that cannot map that graph cannot reliably defend it.


    AI Adds Another Supply Chain Layer

    AI is adding a new layer to the software supply chain, and it is not limited to generated code.

    Security teams are already paying attention to insecure code generated by AI assistants. That matters, but it is only part of the risk. AI tools are also being connected to repositories, terminals, ticketing systems, internal documentation, cloud environments, package managers, and build workflows. In some cases, AI agents can read files, write code, run commands, call APIs, open pull requests, summarize logs, modify configuration, or assist with releases.

    That means AI tooling can become part of the development and delivery chain. If it has access, it has to be governed. If it can act, its actions have to be logged. If it can read secrets, the exposure has to be treated as real. If it can execute commands, the execution path has to be constrained.

    The Nx incident showed one version of this problem from the attacker side: malware attempted to use local AI CLI tools for reconnaissance and exfiltration. That is a warning sign. AI developer tools are attractive to attackers because they may already have broad local context and user trust. They may know where projects are stored, how repositories are structured, which files look sensitive, and how to automate discovery across a workstation.

    For defenders, this creates a hard policy question. Is an AI coding assistant just a developer productivity tool, or is it a supply chain participant? If it can influence code, configuration, tests, dependencies, release notes, infrastructure, or deployment logic, the answer is clear. It belongs in the supply chain model.

    That does not mean organizations should ban AI development tools by default. It means they need controls that match the access level. AI tools should be restricted from secrets. Generated changes should go through the same review path as human-written changes. Agent actions should be logged. Tool permissions should be scoped. Local developer environments should not become uncontrolled bridges between repositories, cloud credentials, and AI execution.

    The security concern is not that AI writes code. The concern is that AI tools are being connected to privileged development contexts faster than many organizations can inventory or govern them.


    SBOMs Are Necessary, But They Are Not the Whole Answer

    SBOM adoption has improved software transparency by forcing organizations to document the components inside their applications. That is valuable. It gives teams a way to answer exposure questions faster when a dependency vulnerability is disclosed. It also helps with vendor risk, procurement, compliance, and incident response.

    Still, an SBOM is not a complete supply chain control by itself. It is an inventory artifact. It does not automatically prove that the build was trustworthy, that the published artifact matches source, that the runtime environment loaded only declared components, or that a package was produced by the expected workflow.

    This gap matters during real incidents. A static SBOM can tell an organization what was expected to be present at a point in time. It may not reveal what actually executed in memory, what a malicious post-install script did during package installation, what a compromised build runner injected, or whether a release artifact was created outside the approved pipeline.

    SBOMs should be paired with provenance, artifact signing, runtime visibility, and policy enforcement. The goal is not just to know what components exist. The goal is to know whether the software that reached production was built, signed, and deployed through a trusted path.

    That is a higher bar. It also fits the direction of modern software risk. Static inventory helps answer “what is inside this application?” Provenance helps answer “can we trust how this application was produced?” Runtime validation helps answer “is the application behaving like the inventory said it would?”

    All three questions matter.


    Vendor Risk Has to Move Past Questionnaires

    The same issue applies to third-party software vendors. Many organizations still evaluate software suppliers through questionnaires, SOC 2 reports, penetration test summaries, vulnerability disclosure policies, and security addendums. Those documents have value, but they rarely show the full release path.

    A vendor can have a secure coding policy and still use weak release controls. A vendor can provide an SBOM and still lack enforceable artifact provenance. A vendor can require MFA for employees and still rely on overprivileged service accounts. A vendor can pass an audit and still have build runners with excessive network access, exposed secrets, or unreviewed workflow changes.

    Procurement and security teams need to ask more operational questions. How are release artifacts signed? Are builds reproducible or at least traceable? Are package publishing tokens long-lived or replaced with trusted publishing? Are workflow changes reviewed as security-sensitive changes? Are build runners isolated? Are deployment credentials short-lived? Can the vendor prove which commit, workflow, and environment produced a given release? Can customers verify that proof?

    These questions matter more than a generic statement that secure development practices are followed. A mature supplier should be able to explain how code becomes software and how that process is protected from tampering.

    This is where supply chain security becomes a shared accountability problem. Buyers need stronger evidence. Vendors need stronger release controls. Security teams need to stop treating the vendor’s final artifact as the beginning of the risk conversation. The artifact is the end of a process. That process needs assurance.


    What Defenders Should Prioritize Next

    The next phase of software supply chain defense should focus on the systems that produce, publish, and deploy software.

    Organizations should start by identifying their critical build and release paths. That means mapping repositories, CI/CD workflows, build runners, package registries, artifact stores, signing keys, service accounts, cloud roles, deployment jobs, and third-party integrations. This should include internal software and vendor-managed software that has privileged access to the environment.

    Next, teams should reduce reliance on long-lived credentials. Package publishing, cloud access, and deployment automation should move to short-lived identity flows where possible. OIDC-based trusted publishing is a strong example of this pattern. If a token cannot be removed, it should be scoped narrowly, rotated regularly, monitored closely, and kept out of workflows that handle untrusted input.

    Build provenance should become a policy control. Artifacts should be signed. Provenance should be generated by the build system. Production deployment should prefer, and eventually require, artifacts that can prove where and how they were built. This is the point where supply chain security becomes enforceable instead of advisory.

    Workflow files should be treated as sensitive code. A change to a CI/CD pipeline can be as dangerous as a change to authentication logic. Pull request triggers, external contributor permissions, environment variable access, and secret exposure rules need review from people who understand both engineering and security impact.

    Developer workstations also need more attention. Many supply chain attacks target the developer first, then move into repositories, secrets, package publishing, and cloud environments. Endpoint controls, secret scanning, local credential hygiene, and restrictions on package install scripts can reduce this risk. Development systems should not hold broad, reusable credentials that can turn one malicious package install into an organization-wide incident.

    AI development tools should be added to the access review process. Security teams need to know which tools are in use, what data they can read, what commands they can run, and whether their actions are logged. AI-generated or AI-assisted changes should follow the same review, testing, and approval path as any other change.

    SBOMs should continue to mature, but they should not be treated as a finish line. The stronger model is SBOM plus provenance plus signing plus runtime visibility plus deployment policy. That gives organizations a better chance of detecting mismatch between what was declared, what was built, what was shipped, and what actually ran.


    The Next Problem Is Trust Without Verification

    The software supply chain problem is no longer limited to unknown code. It is trust without verification across the systems that produce software.

    A package can have the right name and still be malicious. A release can come from the right maintainer account and still bypass the expected pipeline. A build can pass tests and still leak secrets. A vendor can provide documentation and still lack defensible artifact controls. An AI tool can improve productivity and still create a new path into sensitive development context.

    That is the next supply chain problem. It is not just the code organizations import. It is the authority granted to everything around that code.

    Security teams need to treat the software factory as production infrastructure. CI/CD systems, package publishers, build runners, signing services, AI developer tools, and service accounts are no longer background components. They are part of the attack surface. They decide what becomes trusted software.

    The organizations that understand this will move from dependency visibility to process assurance. They will ask for proof, not promises. They will verify artifacts, not just scan packages. They will govern automation, not just developers. They will treat the release path as a security boundary.

    The next software supply chain problem may not be code. It may be the system that everyone already trusts to deliver it.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.


  • Netizen: Monday Security Brief (6/22/2026)

    Today’s Topics:

    • INTERPOL Warns Cybercrime Is Surging Across Asia-Pacific as Phishing, Ransomware, and AI Scams Scale Up
    • The Gentlemen Ransomware Shows How Former Affiliates Are Building Faster, Leaner RaaS Operations
    • How can Netizen help?

    INTERPOL Warns Cybercrime Is Surging Across Asia-Pacific as Phishing, Ransomware, and AI Scams Scale Up

    Cybercrime is rising sharply across Asia and the South Pacific, with phishing, ransomware, banking malware, information stealers, deepfakes, and AI-assisted fraud placing new pressure on governments, businesses, and law enforcement agencies across the region. A new INTERPOL assessment says the threat environment has been shaped by fast digital adoption, wider internet access, organized criminal networks, uneven cybersecurity maturity, and the growing use of artificial intelligence in online crime.

    According to INTERPOL’s 2025/2026 Asia and South Pacific Cyberthreat Assessment Report, phishing is now the most widespread and financially damaging form of cybercrime reported across the region. A third of countries covered in the assessment recorded more than 10,000 phishing cases between January 2024 and March 2025. More than half of INTERPOL member countries also reported that cybercrime made up at least 30% of all nationally recorded crime.

    The numbers point to a broader shift in how cybercrime is operating. Phishing is no longer limited to low-effort credential theft emails or generic lures. Criminal groups are combining social engineering, fake login pages, malware delivery, business impersonation, and AI-generated content to reach more victims at scale. In many cases, phishing now serves as the entry point for broader fraud, account takeover, ransomware deployment, or data theft.

    Ransomware also remains a major threat across the Asia-Pacific region. INTERPOL estimated that more than 135,000 ransomware-related attacks affected the region in 2024, with real estate, manufacturing, and financial services among the most heavily impacted sectors. These industries are attractive targets due to their operational reliance on digital systems, high-value data, financial exposure, and limited tolerance for downtime.

    Ransomware groups are also increasing pressure during extortion by using victims’ regulatory and legal obligations against them. Rather than relying only on encryption, attackers may steal data, threaten public leaks, contact customers, reference compliance requirements, or use breach disclosure timelines to force faster payment decisions. This makes ransomware a legal, financial, operational, and reputational crisis, not just a technical incident.

    INTERPOL also warned that AI-enabled scams are becoming more common, especially in impersonation and fraud campaigns. Deepfake audio, synthetic video, AI-generated personas, and more convincing written messages are being used to impersonate executives, manipulate victims, authorize fraudulent transfers, and support romance or investment scams. These tools reduce the skill required to produce believable social engineering content and allow criminal groups to run higher-volume campaigns with more convincing narratives.

    The report also points to the industrialization of cyber-enabled fraud by transnational organized crime groups. Scam centers in Cambodia, Laos, Myanmar, and the Philippines have been linked to large-scale fraud operations that use forced labor to conduct investment scams, romance baiting schemes, and other online fraud. INTERPOL said organized crime groups in Myanmar, Cambodia, and Laos have used deepfakes in romance baiting scams, combining AI personas with social engineering in schemes tied to billions of dollars in regional cybercrime losses.

    Malware activity is also expanding. Banking trojans and information stealers ranked as the second most common category of cybercrime in the report, with families such as RedLine, Lumma, LokiBot, Negasteal, and ZBot appearing among the most active threats. These tools are often used to harvest browser-stored credentials, session cookies, cryptocurrency wallet data, system information, and authentication material that can later be sold, reused, or combined with other intrusion activity.

    Phishing link engagement in the region also exceeded the global average. INTERPOL reported that 5.5 out of every 1,000 individuals in Asia and the South Pacific clicked phishing links monthly, compared with a global average of 2.9 per 1,000. That higher rate gives attackers more opportunities to harvest credentials, compromise accounts, deliver malware, and move into business email compromise or identity fraud.

    Distributed denial-of-service attacks also increased sharply, rising 92% in 2024 compared with the prior year. These attacks can be used to disrupt public services, pressure businesses, distract defenders, or support extortion campaigns. For organizations with weak network resilience or limited incident response capability, DDoS activity can create service outages that damage operations and public trust.

    System intrusions remain a major driver of data breaches, accounting for about 80% of all data breach activity in 2024, according to the report. INTERPOL cited misconfigured systems, weak encryption, insecure APIs, and insufficient monitoring as common weaknesses attackers exploit to gain access to target networks. These issues are familiar to defenders, but their impact grows as organizations move more services online and expose more cloud, application, and identity infrastructure to the internet.

    The rise in deepfake abuse has also created new risks beyond financial fraud. INTERPOL warned that synthetic media is being used for sexual exploitation, blackmail, and coercion. That threat category shows how AI-enabled cybercrime can cross from enterprise risk into personal harm, placing pressure on law enforcement agencies to respond to both technical abuse and human exploitation.

    The regional trend is clear: cybercrime across Asia and the South Pacific is becoming more organized, more automated, and more closely tied to traditional criminal enterprises. Phishing, ransomware, infostealers, deepfakes, and online scams are no longer separate threat categories. They increasingly operate as connected parts of a broader criminal economy, where stolen credentials, synthetic identities, malware access, extortion, and fraud infrastructure support one another.

    INTERPOL said law enforcement organizations across the region are scaling joint efforts to disrupt cybercriminal infrastructure, coordinate investigations, share intelligence, train personnel, and strengthen cyber resilience policies. That cooperation will be necessary as criminal groups continue using AI, ransomware-as-a-service, social engineering, and cross-border infrastructure to target victims at scale.

    For organizations, the report reinforces the need to treat phishing resistance, ransomware readiness, identity security, endpoint visibility, API hardening, monitoring, incident response planning, and employee training as connected defensive priorities. The threat is no longer limited to isolated scams or opportunistic malware. It is a regional cybercrime ecosystem built to exploit weak controls, human trust, exposed systems, and the growing use of AI in both business and crime.


    The Gentlemen Ransomware Shows How Former Affiliates Are Building Faster, Leaner RaaS Operations

    The Gentlemen ransomware operation is a case study in how the ransomware-as-a-service economy is changing. The group did not appear as a fully isolated criminal brand with no prior tradecraft behind it. Reporting from PRODAFT, Microsoft, Check Point Research, Huntress, Trend Micro, and other threat intelligence teams indicates that The Gentlemen grew out of earlier affiliate activity tied to established ransomware ecosystems, then moved into its own independent partnership program after disputes, leaks, and instability inside the underground market.

    PRODAFT tracks the group as Phantom Mantis and says it was initially known as ArmCorp. The operation has been active since March 2025 and is assessed to be led by a Russian-speaking threat actor tracked as LARVA-368, associated with aliases including hastalamuerte, ArmCorp, zeta88, nobody0, and santamuerte. Before launching The Gentlemen as a standalone program, the actor is said to have worked with or borrowed from ransomware ecosystems linked to LockBit, Qilin, Medusa, and Embargo. That background matters, since The Gentlemen does not look like a novice operation. It looks like a group built by people who already knew how ransomware crews recruit affiliates, manage panels, negotiate payments, move data, and pressure victims.

    The operation’s shift from ArmCorp into The Gentlemen appears to have accelerated in July 2025 after a dispute with Qilin, with LARVA-368 alleging that roughly $48,000 in affiliate commissions had been withheld. That dispute fits a larger pattern in the ransomware market. Since 2023, major crews have been disrupted, exposed, rebranded, or accused of cheating affiliates. LockBit was hit by law enforcement action, ALPHV collapsed after payment controversy, RansomHub disappeared from public view, and several smaller crews splintered into private or semi-private programs. In that climate, experienced affiliates have more incentive to build their own platforms rather than depend on larger brands that may steal commissions, lose infrastructure, or attract too much law enforcement pressure.

    The Gentlemen’s growth has been tied closely to that affiliate-first model. Check Point Research reported that the group publicly claimed more than 320 victims by April 2026, with 240 of those claims occurring in the first months of 2026. Halcyon has assessed that the group offered affiliates a 90/10 revenue split, giving affiliates 90 percent of ransom proceeds. That is higher than the 70/30 or 80/20 split common across many RaaS programs, making it a strong recruitment tool for operators who already have access, tradecraft, and victim pipelines.

    This is one reason The Gentlemen should be seen as a business-model threat, not just a malware threat. The ransomware itself is dangerous, but the affiliate structure is what allows the operation to scale. Operators provide the locker, infrastructure, support, leak site, and build process. Affiliates bring access, execute intrusions, steal data, deploy ransomware, and negotiate with victims through their own Tox or messaging identifiers. That separation lets the core program support many intrusions without directly conducting each one.

    The group’s internal communications, later exposed through leaks affecting its Rocket.Chat environment, gave researchers an unusually clear view into how the operation functioned. PRODAFT said it identified 34 registered users in the group’s Rocket.Chat instance between May 2025 and April 2026. Check Point Research reported that leaked material included conversations about initial access, edge appliance exploitation, affiliate roles, shared tools, backend systems, victim handling, and ransom negotiations. The leak also exposed accounts connected to the administrator, who reportedly managed infrastructure, built lockers, handled the RaaS panel, and oversaw payouts.

    The internal structure shows a division of labor that resembles a criminal services platform. One role, referred to as The Gentlemen Data, appears focused on data exfiltration support, helping move stolen information from affiliate-controlled cloud storage into The Gentlemen infrastructure for publication on the group’s leak site. LARVA-368 and related support channels appear to have helped affiliates with encryption, intrusion troubleshooting, and security-tool bypasses. Support moved through Tox, SimpleX Chat, Ricochet Refresh, and other messaging platforms after the Rocket.Chat leaks damaged the group’s internal trust.

    The affiliate panel also reflects the maturity of the operation. PRODAFT reported that prospective affiliates needed to provide at least 1 GB of exfiltrated victim data before gaining access to the panel, a vetting method also seen in other ransomware crews trying to keep researchers and law enforcement out. The panel reportedly allowed affiliates to configure targets, build ransomware packages, download lockers, manage users, and track victim states. That kind of infrastructure lowers friction for affiliates and helps standardize attacks across different operators.

    The ransomware payload is built for broad enterprise coverage. Reporting indicates that The Gentlemen supports Windows, Linux, ESXi, older Windows systems, and LVM environments. Microsoft tracks the operators as Storm-2697 and described the Windows encryptor as a Go-based ransomware family obfuscated with Garble. Microsoft also reported that the ransomware can use self-propagation logic, turning a single-host encryptor into malware that attempts to spread across reachable systems once enabled by the operator. That feature raises the risk of domain-wide impact after initial access, particularly in flat networks with weak segmentation and overprivileged accounts.

    The ransomware’s options show a focus on speed, reach, and recovery disruption. Analysts have reported features for local encryption, network share encryption, delayed execution, selective scope, self-deletion, free-space wiping, GPO-based deployment, and propagation using credential material. ESXi support gives the group a path to affect virtualization infrastructure, where encrypting hosts or datastores can impact many workloads at once. LVM support extends the reach against Linux storage configurations and block-device targets. This cross-platform coverage reflects how modern ransomware crews build for mixed enterprise environments rather than single endpoint classes.

    Incident reporting from Huntress and Trend Micro also shows that affiliates deploying The Gentlemen have used common enterprise intrusion tradecraft before encryption. Observed activity has included scheduled task abuse, Windows scripting, log clearing, Defender tampering, antivirus exclusions, remote access tooling such as AnyDesk, Group Policy manipulation, privileged account compromise, encrypted file transfer, and legitimate driver abuse. These techniques are not new on their own. The risk comes from how they are packaged into a repeatable affiliate workflow backed by a growing RaaS program.

    Initial access patterns also match broader ransomware trends. Researchers have pointed to exposed edge devices, VPN appliances, firewall infrastructure, stolen credentials, and public-facing services as common entry paths. Check Point’s analysis of an affiliate-linked incident involving SystemBC found more than 1,570 victims connected to the relevant command-and-control server, with signs that many were corporate or organizational environments. SystemBC is often used in human-operated ransomware intrusions to create proxy access, support tunneling, and enable later payload delivery.

    The Gentlemen’s use of AI, as described by PRODAFT, adds another layer to the story. LARVA-368 reportedly used AI to assist with ransomware and tool development, maintenance, and post-exploitation procedures. That does not mean AI created the operation by itself. The more realistic concern is that AI can reduce development time, help operators troubleshoot code, generate scripts, translate instructions, maintain panels, and produce procedural guidance for affiliates. For groups already familiar with ransomware operations, AI can act as a force multiplier across coding, documentation, support, and attack planning.


    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.