Every year, CrowdStrike Professional Services performs hundreds of Technical Risk Assessments (TRAs) across myriad industries, geographies, and business environments. These deep, hands-on reviews look at how security controls behave in production to evaluate the threats they see and block — and crucially, the threats they miss. 

Exposure is constantly changing as organizations adopt new technologies and adversaries accelerate and explore new tactics. Because our team sees so many different environments up close, we have a lens into the patterns that put businesses at risk: the same misconfigurations, visibility gaps, and temporary exceptions continue to appear, and they map to the techniques modern adversaries use to move quickly and bypass detection. By analyzing these real-world findings, we’ve identified that the highest risk often resides in “silent” spaces — unmanaged assets and overlooked credential paths — where adversaries now operate with machine speed.

Addressing these systemic issues requires moving beyond tool acquisition and toward operational discipline. Our assessments reveal that securing the enterprise isn’t just about having the right technology, but about gaining clarity into where risk lives. By closing the visibility gaps across critical areas, organizations can shift from a reactive posture to a proactive approach that disrupts the adversary’s path.

In this blog, we draw on a large sample of CrowdStrike Technical Risk Assessments to examine those patterns and highlight the most common issues quietly driving cyber risk. For security teams seeking to lower their risk profile, these are the areas to focus on to strengthen security posture.

Most Common Risk Patterns

Shadow AI: The Governance Gap Organizations Can’t Ignore

Employees, developers, and SaaS platforms are deploying AI tools faster than security and policy teams can respond. From LLM-powered browser extensions to unapproved AI agents running in production, AI is proliferating outside sanctioned channels — and security teams often have no visibility into it. Unlike traditional shadow IT, shadow AI requires no installation, hides inside existing tools, and can silently route sensitive data to external models. In one recent CrowdStrike Services assessment, the client had zero approved agentic AI use but had agents running in production. In another, the approved inventory was off by 400. The risks are significant: uncontrolled data exposure, broken access permissions, unmonitored autonomous agent behavior, and no clear accountability.

Recommendations

• Form a cross-functional AI committee to align business needs with security requirements
• Deploy CrowdStrike Falcon® AI Detection and Response (AIDR) to surface shadow AI adoption and CrowdStrike Falcon® Exposure Management to inventory LLMs, agents, IDE extensions, and MCP servers
• Use CrowdStrike Falcon® Cloud Security (AI-SPM), CrowdStrike Falcon® Shield, and Falcon AIDR to identify AI activity across productivity and communication platforms
• Publish clear rules and a sanctioned list of approved models and interfaces
• Define who can build and deploy AI agents, what they can access, and how their behavior is logged and terminated
• Ensure staff understand the data exposure, compliance, and integration risks of unauthorized AI tools

External Attack Surface

The external attack surface refers to everything an adversary can see and access from the internet before they enter the target network. This includes:

• Public-facing websites and applications
• Domains and subdomains (including old or “test” ones)
• Internet-exposed IP addresses and services
• VPN gateways, remote access portals, and management interfaces
• Cloud and SaaS services that can be reached directly from the internet

In our Technical Risk Assessments, we consistently find that this external footprint is larger and more exposed than security teams realize. Shadow IT, forgotten projects, third-party integrations, and misconfigured cloud services all expand the attack surface in ways that rarely show up in internal inventories.

Common issues we uncover include:

• Unknown or “orphaned” assets that no one owns but are still live on the internet
• Outdated software and configurations on public-facing systems
• Overly permissive access to admin portals, APIs, and management interfaces
• Inconsistent controls between on-premises and cloud, or between different business units

Each one of these gaps represents an opportunity for an adversary to gain initial access with minimal effort.

How Falcon Exposure Management Uncovers Risk

CrowdStrike Professional Services uses Falcon Exposure Management to uncover and validate these risks as part of the Technical Risk Assessment.

Falcon Exposure Management continuously discovers and maps internet-facing assets — domains, IP ranges, cloud services, and more — and correlates them with vulnerabilities, misconfigurations, and threat intelligence. This gives us a view of the external attack surface.

During a Technical Risk Assessment, our consultants:

1. Enumerate the organization’s external footprint using Falcon Exposure Management to identify known and unknown assets.
2. Prioritize exposures based on exploitability and adversary behavior, focusing on the paths real attackers are most likely to use.
3. Validate risk with hands-on analysis, confirming what an attacker could see and do from the outside.
4. Deliver clear recommendations outlining which issues to fix first and how to close high-risk internet-facing gaps.

The result is an evidence-based view of the external attack surface and a prioritized roadmap to reduce the risk of a breach starting from an exposed asset on the public internet.

Applications and Vulnerabilities

When we review applications and vulnerabilities during a Technical Risk Assessment, we rarely find a lack of tools. Most organizations have endpoint detection and response (EDR), vulnerability scanners, and patch management platforms. The challenge they most often face is the gap between finding issues and fixing them within a defined window.

The most common pattern we see is critical vulnerabilities on “managed” assets. Even on systems covered by endpoint sensors and vulnerability scanners, we routinely find critical-severity CVEs that have been open for weeks or months. These are often on business-critical servers and externally reachable systems.

Patching is often treated as best-effort instead of a measured commitment. Technical Risk Assessments frequently find organizations lacking clear, risk-based SLAs for remediation, or SLAs that exist on paper but aren’t tracked and enforced in practice.

Our recommendation is straightforward:

• Establish explicit SLAs for vulnerability remediation based on severity, exploitability, and exposure — for example, internet-facing and business-critical assets are held to the tightest timelines.
• Continuously measure against those SLAs so security and IT teams can see where patch debt is accumulating.

In a Technical Risk Assessment, our team uses Falcon Exposure Management to surface these high-risk CVEs on managed assets, show where SLA breaches are concentrated, and give you a prioritized, evidence-based plan to close the most dangerous gaps.

Accounts, Identity, and Configuration Hygiene

In almost every Technical Risk Assessment, we find identity hygiene issues create easy, high-impact paths for attackers. A few patterns repeatedly surface:

Noisy Remote Accounts on Home Networks

With today’s remote and hybrid workforce, many employees are accessing corporate resources from home networks that don’t have enterprise-grade security controls. In our assessments, we often see a small number of systems associated with remote workers generating a very high volume of login attempts.

These endpoints become magnets for credential stuffing and brute-force activity. Attackers repeatedly try username/password combinations against internet-reachable services, and nothing on the home Wi-Fi stops this activity at the perimeter. Without good monitoring and controls, this “background noise” can hide real compromise attempts and make it harder for defenders to spot malicious logins in time.

Kerberos Misconfigurations that Make Kerberoasting Trivial

Kerberos is foundational to how many organizations authenticate users and services — and there are many ways it can be misconfigured. In many environments, we see service accounts with weak passwords, legacy encryption settings, and excessive privileges.

Kerberoasting remains a go-to technique: Attackers request service tickets, take them offline, and try to crack them. When passwords are weak or never rotated, this becomes a reliable way to quickly turn a standard domain account into powerful access. Misconfigured Kerberos and weak service account passwords is a combination that dramatically lowers the bar for a successful compromise.

Active Directory as a Critical and Accessible Target

Most enterprises still rely on Active Directory (AD) as the backbone of their identity infrastructure. This makes AD a primary target for modern attackers. Once an adversary can control or abuse AD, they can move laterally, escalate privileges, and persist with relative ease.

In Technical Risk Assessments, we frequently uncover:

• Stale or orphaned accounts that still have access they no longer need
• Over-privileged service and admin accounts
• Weak or inconsistent password policies

Legacy configurations that were “good enough” years ago are dangerous today. Cleaning up AD, tightening identity configurations, and enforcing strong authentication and password hygiene are some of the most direct ways to reduce cyber risk.

Patterns of Strong Security

Across hundreds of Technical Risk Assessments, the organizations in the strongest position tend to have a few things in common:

A mapped and owned external attack surface: They know which domains, IP ranges, cloud services, and internet-facing applications belong to them, and who owns each one. Falcon Exposure Management is used to continuously discover new assets and flag drift. It helps confirm nothing lives on the public internet without clear ownership, baseline controls, and a plan to remediate issues.

Risk-based vulnerability management with real SLAs: Vulnerability data is prioritized by exposure and adversary behavior. High-risk CVEs on critical and internet-facing systems have tight, enforced SLAs. Falcon Exposure Management helps correlate vulnerabilities with real-world context so teams can focus on what reduces breach likelihood.

Clean, well-governed identities and directories: Remote endpoints are monitored for unusual login activity, and policies account for the realities of home networks. Kerberos is configured securely, service account passwords are strong and rotated, and Kerberoasting-resistant configurations are in place. Active Directory is well-maintained: Stale accounts are removed, privileges are minimized, and configuration hygiene is continuously improved.

Integrated visibility and a habit of continuous validation: Security and IT teams work from a shared, current view of assets, vulnerabilities, and identities. Technical Risk Assessments are used as a recurring health check to validate that controls are behaving as expected, SLAs are met, and newly introduced technologies don’t silently expand risk.

How We Help: CrowdStrike Technical Risk Assessment

The Technical Risk Assessment provides a unified view of exposure across the external attack surface, applications, vulnerabilities, accounts, identity, and configuration hygiene — powered by the CrowdStrike Falcon® platform.

What the assessment delivers:

• An executive‑ready report that summarizes exposure, business impact, and accountable owners
• Remediation details for each finding, mapped to real‑world adversary techniques
• A prioritized plan that scores every action by criticality and level of effort, so teams know what to fix first and how much work is required

Platform capabilities behind the assessment:

• Falcon Exposure Management to discover, assess, and act on risk across assets and the external attack surface
• CrowdStrike Falcon® Next-Gen Identity Security to reveal and close risky identity paths and Active Directory weaknesses
• CrowdStrike Falcon® for IT to query, manage, and remediate at scale across the environment

Contact your CrowdStrike representative or complete this form to schedule your Technical Risk Assessment.

Additional Resources

The post CrowdStrike Technical Risk Assessments Reveal Common Exposure Patterns appeared first on MASSIVE News.

Our investigation found that 76 of the scanner’s 77 release tags had been retroactively poisoned via git tag repointing, replacing the legitimate entry point with a multi-stage credential stealer. The malicious code runs silently before the real scanner, so workflows appear to complete normally. 

Aqua Security has officially confirmed the compromise of the Trivy GitHub Action script, setup script, and binary, and has subsequently quickly removed all malicious artifacts from their repositories. Additionally, CrowdStrike coordinated with Aqua Security prior to this publication. In this blog, we discuss how this activity was discovered, how the attack works, what the payload does, and how CrowdStrike helps organizations defend against this threat.

GitHub Actions and Why They Matter

GitHub Actions is the CI/CD platform built into GitHub. When a developer pushes code, opens a pull request, or merges a branch, GitHub Actions can automatically build, test, and deploy that code. GitHub Actions is used by millions of repositories from small open-source projects to enterprise production pipelines.

Workflows are defined in YAML files that live in a repository’s .github/workflows/ directory. Each workflow is composed of jobs, and each job runs a series of steps on a runner — a virtual machine or container provisioned to execute the work. These runners have access to the repository’s code, its configured secrets (API keys, deploy tokens, cloud credentials), and often broad network access to internal infrastructure.

A key feature of GitHub Actions is the ability to reference reusable actions, which are prepackaged steps published by third parties. Instead of writing custom scripts for common tasks like checking out code, setting up a language runtime, or running a security scanner, teams reference shared actions by name and version:

  steps:
    - uses: actions/checkout@v4
    - uses: aquasecurity/trivy-action@0.24.0

When a workflow runs, the runner downloads the referenced action from GitHub, extracts it, and executes its entry point. This is where the trust model becomes critical: The runner executes whatever code the action contains, with full access to the runner’s environment, secrets, and network.

Most teams reference actions by tag (e.g., @0.24.0 or @v2). Tags are human-readable and easy to update. But in Git, tags are mutable — they can be silently repointed to a different commit without any visible change to the release page, the tag name, or the published dates. This is the mechanism exploited in the compromise described below.

aquasecurity/trivy-action is a GitHub Action published by Aqua Security that wraps its open-source vulnerability scanner, Trivy. It’s widely adopted for scanning container images, file systems, and infrastructure-as-code for known vulnerabilities as part of CI/CD pipelines.

In summary, if an action’s code is modified, whether by its maintainers or by someone who gained write access, every pipeline that references it will trust and execute the new code on its next run, all with full access to that pipeline’s secrets, credentials, and infrastructure.

Initial Discovery

An initial spike on Linux platforms linked to runners was observed on March 19, 2026. The detections were concentrated on GitHub Actions runners, and the script content didn’t appear to align with benign CI/CD activity.

Digging into the process tree, the full execution chain was traced to one of the affected runners:

 runc
   └── /bin/bash /home/runner/run.sh
        └── /bin/bash /home/runner/run-helper.sh
             └── Runner.Listener run
                  └── Runner.Worker spawnclient 149 152
                       └── /usr/bin/bash --noprofile --norc -e -o pipefail /home/runner/_work/_temp/395479a1-…ded349.sh
                           └── /bin/bash /home/runner/_work/_actions/aquasecurity/trivy-action/0.24.0/entrypoint.sh

Reading from top to bottom: runc starts the container, which launches the runner’s startup scripts (run.sh → run-helper.sh). These start Runner.Listener, which connects to GitHub and waits for jobs. When a workflow is triggered, the Listener spawns Runner.Worker to execute it. The Worker runs each workflow step as a shell script in a temp directory — the 395479a1-…ded349.sh wrapper. That wrapper calls the action’s entrypoint.sh, which is where the malicious code lives.

From here, CrowdStrike began investigating the action itself.

What the Payload Does

The malicious entrypoint.sh prepends approximately 105 lines of attack code before the legitimate Trivy scanner logic. An example of one of the malicious commits can be viewed here.

It executes a multi-stage credential theft operation, then runs the real scanner so the workflow appears to succeed normally.

Stage 1: Runner Process Discovery

Initially, the script enumerates process IDs (PIDs) of GitHub Actions runner processes (Runner.Worker, Runner.Listener, runsvc, run.sh) and reads their /proc/{PID}/environ files, filtering for environment variables containing env or ssh in their names.

Stage 2: Platform-Specific Credential Theft

The attack branches based on the runner environment:

On GitHub-hosted Linux runners, a Base64-encoded Python script is decoded and executed with sudo. It locates the Runner.Worker process, reads its memory maps via /proc/{PID}/maps, and scrapes raw process memory via /proc/{PID}/mem looking for GitHub Actions secrets — specifically JSON structures matching “name”:{“value”:”…”,”isSecret”:true}.

On self-hosted runners, a different Base64-encoded Python script performs broad filesystem credential harvesting. It targets the following:

• SSH private keys and configs
• Cloud credentials (AWS, Google Cloud, Azure)
• Kubernetes configs and service account tokens
• Docker registry credentials
• Database credentials (MySQL, PostgreSQL, MongoDB, Redis)
• CI/CD configs (GitLab CI, Travis, Jenkins, Drone)
• Infrastructure-as-code secrets (Terraform state/vars, Ansible, Helm)
• TLS/SSL private keys
• .env files and API keys
• Cryptocurrency wallet keys (Bitcoin, Ethereum, Solana validator keypairs, Cardano, and others)
• System files (/etc/passwd, /etc/shadow, shell histories)

Stage 3: Encrypted Exfiltration

Collected data is encrypted with a randomly generated AES-256-CBC session key, and the session key is wrapped with a hardcoded 4096-bit RSA public key. The encrypted bundle (payload.enc + session.key.enc) is packaged as tpcp.tar.gz. This ensures only the adversary server with access to the corresponding RSA private key can decrypt the payload.

Stage 4: Dual Exfiltration Channels

The primary exfiltration channel is an HTTPS POST to scan.aquasecurtiy[.]org — a typosquatted domain mimicking Aqua Security’s legitimate aquasecurity.com.

If the endpoint returns a non-2XX response and INPUT_GITHUB_PAT is available, the script falls back to exfiltrating through GitHub itself. It will create a public repository named tpcp-docs under the victim’s GitHub account, create a timestamped release, and upload the encrypted bundle as a release asset.

Stage 5: Cleanup and Camouflage

All temporary files are removed. The remainder of the script is a functional copy of the real trivy-action entry point. It downloads and runs Trivy normally, producing expected scanner output. To an operator reviewing workflow logs, the step appears to have completed successfully.

Further Discoveries

Every release tag of aquasecurity/trivy-action from GitHub was downloaded and scanned. This includes 77 tags total, spanning from 0.0.1 to 0.35.0. Each entrypoint.sh was checked against five indicator of compromise (IOC) patterns derived from the malicious payload.

The result of this analysis is as follows:

The only clean tag is 0.35.0. Every other release from 0.0.1 through 0.34.2 currently serves a malicious entrypoint.sh.

The setup-trivy action was also compromised to execute the same malicious script.

In addition to the compromised trivy-action GitHub Action, the trivy scanner version 0.69.4 was also compromised. When it executes, a script is dropped to ~/.config/sysmon.py. The script acts as a lightweight stage-1 loader. After an initial five-minute sleep (likely intended to outlast sandbox analysis timeouts), it enters a polling loop that contacts a command-and-control (C2) server approximately every 50 minutes. 

The C2 is hosted on the Internet Computer (ICP) blockchain (hxxps[://]tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io), making it resistant to traditional domain takedowns.

On each cycle, the loader fetches a URL from the C2, compares it against a locally cached state file, and if the URL is new, downloads the referenced binary to /tmp/pglog. It then marks the file executable and launches it as a detached process with all output suppressed. The choice of filename mimics PostgreSQL logging, and the state file is dot-prefixed to stay hidden from casual directory listings.

Error handling is deliberately silent throughout. Every operation is wrapped in bare except blocks that discard failures, ensuring the loader never crashes or produces visible output. Combined with the spoofed browser User-Agent and the lack of any logging, the script is designed to operate invisibly on a compromised host while allowing the attacker to rotate payloads at will by simply updating the URL served by the C2.

The binary also exhibits the same credential-stealing behavior as the compromised action. It scans for credentials, bundles them, encrypts them, and then exfiltrates the data via a post request.

How It Was Done

Git tags are mutable references. A lightweight tag is just a pointer from a name to a commit SHA. With write access to a repository, an attacker can force-push a tag to point to a different commit:

  git tag -f 0.24.0 <new-commit>
  git push -f origin refs/tags/0.24.0

The release page on GitHub doesn’t change — same name, same dates, same description. But the source archive that gets downloaded now contains different code.

We confirmed this by comparing what the 0.24.0 tag currently delivers against its parent commit:

Tag 0.24.0 resolves to commit e0198fd2b6e1679e36d32933941182d9afa82f6f:

• entrypoint.sh is 17,592 bytes
• First line after the shebang: _COLLECT_PIDS=”$$” (the stealer)
• This commit is not reachable from the master branch — it’s a dangling commit that exists only because the tag points to it

The parent of that commit (57a97c7e7821a5776cebc9bb87c984fa69cba8f1) is the same commit that the clean 0.35.0 tag points to:

• entrypoint.sh is 2,855 bytes
• First line after the shebang: TRIVY_CMD=”${TRIVY_CMD:-trivy}” (the legitimate scanner)
• This commit is reachable from master

The SHA256 hashes tell the story:

The malicious commit’s metadata — author name, commit message (“Upgrade trivy to v0.53.0 (#369)”), and timestamps (2024-07-09) — all mirror a legitimate prior commit. Git allows setting arbitrary author and committer dates via GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables, so these cannot be trusted.

The diagram below shows the full attack chain.

The post From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise appeared first on MASSIVE News.