Microsoft has identified an active supply chain attack targeting the npm package ecosystem. On May 28, 2026, a single threat actor operating under the newly created maintainer alias vpmdhaj (a39155771@gmail[.]com) published 14 malicious packages within a four-hour window. The packages typosquat well-known OpenSearch, ElasticSearch, DevOps, and environment-configuration libraries, and several spoof the upstream OpenSearch project’s repository URL in their package.json to appear legitimate. Once installed, the packages harvest AWS credentials, HashiCorp Vault tokens, and CI/CD pipeline secrets from the host environment.
All packages in the cluster ship the same install-time stager and the same Bun-compiled second-stage payload – a ~195 KB credential harvester purpose-built for cloud and CI/CD environments. The payload runs silently during npm install and targets credentials across Amazon Web Services, HashiCorp Vault, GitHub Actions, and the npm registry itself, enabling both cloud lateral movement and downstream supply-chain pivoting through stolen npm publish tokens. Based on our investigation and feedback to the npm team these repos and users were taken down.
Key capabilities observed in the campaign include automatic execution via npm lifecycle hooks, two distinct stager generations (an HTTP-C2 variant and a stealthier variant that abuses the legitimate Bun runtime distribution), AWS Instance Metadata Service (IMDSv2) and ECS task-role theft, AWS Secrets Manager enumeration across 16+ regions, HashiCorp Vault token harvesting, and theft of npm publish tokens for follow-on supply-chain attacks.
The vpmdhaj cluster spans 14 scoped and unscoped packages that all mimic the @opensearch / @elastic ecosystem. The attack proceeds through:
The actor adopted three social-engineering techniques designed to drive installs by mistake or trust transference. First, lookalike naming – names such as opensearch-setup, opensearch-setup-tool, opensearch-config-utility, elastic-opensearch-helper, search-engine-setup, and env-config-manager mimic well-known cluster-management and configuration libraries. Second, spoofed upstream metadata – every unscoped package sets its package.json homepage, repository, and bugs fields to the legitimate github.com/opensearch-project/opensearch-js project. Third, inflated version numbers – releases jump straight to 1.0.7265, 1.0.9108, or 2.1.9201 to suggest a long, mature release history.
Every package in the cluster declares an automatic install-time hook in package.json. The malicious code executes the moment a victim runs npm install – no require() from victim code is needed. Two stager variants were observed:
preinstall.js collects rich host context – hostname, platform, arch, Node version, USER/USERNAME, cwd, INIT_CWD, npm_package_name, npm_package_version – base64-encodes the JSON, and POSTs it to the actor’s C2 with a campaign-unique header X-Supply: 1. The same C2 endpoint then serves a gunzip-compressed second-stage binary, which is written to payload.bin in the package install directory, chmod 0755’d, and spawned detached.
The package’s index.js re-launches the same payload.bin on every subsequent require() of the module – a quiet persistence mechanism that survives across CI build stages and developer rebuild loops. The module also exports a benign-looking object falsely identifying itself as @opensearch/setup.
In newer versions, the actor replaced the noisy HTTP-C2 design with a stealthier loader that eliminates the install-time C2 round-trip entirely. setup.mjs (a) checks whether bun is already present on the host; (b) if not, downloads the legitimate Bun runtime v1.3.13 from github.com/oven-sh/bun/releases for the correct platform/arch (Linux x64/musl/aarch64, macOS x64/arm64, Windows x64/arm64); (c) extracts the ZIP using unzip, PowerShell Expand-Archive, or a hand-rolled ZIP parser; and (d) executes the pre-bundled second-stage payload (opensearch_init.js or ai_init.js) that ships inside the npm tarball.
This design reduces visibility for defenders that primarily monitor unusual outbound traffic during package installation.
The second-stage binary is a single-file Bun-compiled JavaScript binary of approximately 195 KB, purpose-built for cloud and CI/CD secret theft. Static review of the bundle identifies routines that target secrets across five platforms:
Microsoft recommends the following mitigations to reduce the impact of this threat:
Microsoft Defender Antivirus detects and blocks the malicious components on access. During reproduction in our analysis environment, setup.mjs was automatically quarantined the moment the tarball was extracted to disk.
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
| Tactic | Observed activity | Microsoft Defender coverage |
| Initial Access / Execution | Suspicious script execution during npm install or package lifecycle activity | Microsoft Defender Antivirus -Trojan:JS/ShaiWorm -Trojan:JS/ObfusNpmJs -Backdoor:JS/SupplyChain Microsoft Defender for Endpoint – Suspicious usage of Bun runtime – Suspicious installation of Bun runtime – Suspicious Node.js process behavior Microsoft Defender XDR – Suspicious file creation in temporary directory by node.exe – Suspicious Bun execution from Node.js process |
| Credential Access | Potential harvesting of AWS, Vault, GitHub Actions, and npm tokens from CI/CD runners | Microsoft Defender for Endpoint – Credential access attempt – Suspicious cloud credential access by npm-cached binary – AWS Instance Metadata Service access from suspicious process Microsoft Defender for Cloud – Possible IMDS abuse from container workload – Anomalous Secrets Manager enumeration across regions |
| Command and Control | Outbound HTTP beacon with X-Supply: 1 header to attacker-controlled C2 | Microsoft Defender for Endpoint – Connection to a custom network indicator (aab.sportsontheweb[.]net) – Suspicious outbound HTTP from npm install context |
| Persistence | Re-spawn of payload.bin on every require() of compromised package | Microsoft Defender for Endpoint – Detached child process spawned by node.exe with __DAEMONIZED=1 |
The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.
Hunt for suspicious npm lifecycle script execution involving vpmdhaj packages.
Login
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("node.exe", "node", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe")
| where ProcessCommandLine has_any ("preinstall", "postinstall", "install")
| where ProcessCommandLine has_any (
"@vpmdhaj", "opensearch-setup", "opensearch-setup-tool",
"opensearch-config-utility", "opensearch-security-scanner",
"search-engine-setup", "search-cluster-setup",
"elastic-opensearch-helper", "vpmdhaj-opensearch-setup",
"env-config-manager", "app-config-utility")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for the stage-2 payload artifact on disk.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName =~ "payload.bin"
| where FolderPath has "node_modules"
| project Timestamp, DeviceName, FolderPath, FileName,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for detached payload execution with the campaign environment marker.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "__DAEMONIZED=1"
or InitiatingProcessCommandLine has "__DAEMONIZED=1"
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
Hunt for Gen-2 loader: Bun runtime download from GitHub Releases by Node.js.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("node.exe", "node")
| where RemoteUrl has "github.com/oven-sh/bun/releases/download"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for C2 beacon to attacker infrastructure.
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has "aab.sportsontheweb.net"
or RemoteUrl has "sportsontheweb.net"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for AWS IMDS / ECS metadata access from Node.js processes.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("node.exe", "node", "bun.exe", "bun")
| where RemoteIP in ("169.254.169.254", "169.254.170.2")
| project Timestamp, DeviceName, RemoteIP, RemoteUrl,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Affected npm packages – all published by maintainer vpmdhaj on 2026-05-28:
| Indicator | Type | Description |
| @vpmdhaj/elastic-helper (1.0.7269) | Package | Typosquat – ElasticSearch/OpenSearch helper |
| @vpmdhaj/devops-tools (1.0.7267) | Package | Typosquat – DevOps tools / OpenSearch setup |
| @vpmdhaj/opensearch-setup (1.0.7267) | Package | Typosquat – OpenSearch setup utility |
| @vpmdhaj/search-setup (1.0.7268) | Package | Typosquat – search engine setup |
| opensearch-security-scanner (1.0.10) | Package | Unscoped lookalike – security scanner |
| opensearch-setup (1.0.9103) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| opensearch-setup-tool (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| opensearch-config-utility (1.0.9106) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| search-engine-setup (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| search-cluster-setup (1.0.9104) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| elastic-opensearch-helper (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| vpmdhaj-opensearch-setup (1.0.9102) | Package | Unscoped – author-named OpenSearch setup |
| env-config-manager (2.1.9201) | Package | Typosquat – dotenv-style config manager |
| app-config-utility (1.0.9300) | Package | Typosquat – generic app config utility |
| Indicator | Type | Description |
| vpmdhaj | npm maintainer alias | Threat actor publishing all 14 packages |
| a39155771@gmail.com | Maintainer contact email registered on npm | |
| aab.sportsontheweb[.]net | Domain | Stage-1 C2 (Gen-1 packages) |
| hxxp://aab.sportsontheweb[.]net/x.php | URL | Beacon + stage-2 payload endpoint (port 80) |
| X-Supply: 1 | HTTP header | Campaign-unique marker – high-confidence proxy detection |
| 169.254.169.254 | IP | AWS EC2 IMDSv2 endpoint queried by stage-2 |
| 169.254.170.2 | IP | AWS ECS task metadata endpoint queried by stage-2 |
| 638788AFC4F1B5860A328312CAF5895ABD5F5632D28A4F2A85B09076E270D15D | SHA-256 | preinstall.js (Gen-1 stager) |
| 77D92EFE7AF3547F71FD41D4A884872D66B1BE9499EAA637E91EAC866911694D | SHA-256 | setup.mjs (Gen-2 stager) |
| BFA149694EC6411C23936311A999163ADE54D6F38E2F4B0E3CFB8CB67BD7CFAA | SHA-256 | payload.gz (gzipped Bun stage-2) |
| opensearch_init.js | Filename | Bun-compiled stage-2 credential harvester (~195 KB) |
| ai_init.js | Filename | Alternate stage-2 filename used by some Gen-2 packages |
| payload.bin | Filename | Dropped stage-2 binary in node_modules install dir |
| __DAEMONIZED=1 | Env var | Marker set by stager when spawning detached payload |
This research is provided by Microsoft Defender Security Research with contributions from members of Microsoft Threat Intelligence.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
The post Typosquatted npm packages used to steal cloud and CI/CD secrets appeared first on Microsoft Security Blog.
Microsoft has identified an active supply chain attack targeting the npm package ecosystem. On May 28, 2026, a single threat actor operating under the newly created maintainer alias vpmdhaj (a39155771@gmail[.]com) published 14 malicious packages within a four-hour window. The packages typosquat well-known OpenSearch, ElasticSearch, DevOps, and environment-configuration libraries, and several spoof the upstream OpenSearch project’s repository URL in their package.json to appear legitimate. Once installed, the packages harvest AWS credentials, HashiCorp Vault tokens, and CI/CD pipeline secrets from the host environment.
All packages in the cluster ship the same install-time stager and the same Bun-compiled second-stage payload – a ~195 KB credential harvester purpose-built for cloud and CI/CD environments. The payload runs silently during npm install and targets credentials across Amazon Web Services, HashiCorp Vault, GitHub Actions, and the npm registry itself, enabling both cloud lateral movement and downstream supply-chain pivoting through stolen npm publish tokens. Based on our investigation and feedback to the npm team these repos and users were taken down.
Key capabilities observed in the campaign include automatic execution via npm lifecycle hooks, two distinct stager generations (an HTTP-C2 variant and a stealthier variant that abuses the legitimate Bun runtime distribution), AWS Instance Metadata Service (IMDSv2) and ECS task-role theft, AWS Secrets Manager enumeration across 16+ regions, HashiCorp Vault token harvesting, and theft of npm publish tokens for follow-on supply-chain attacks.
The vpmdhaj cluster spans 14 scoped and unscoped packages that all mimic the @opensearch / @elastic ecosystem. The attack proceeds through:
The actor adopted three social-engineering techniques designed to drive installs by mistake or trust transference. First, lookalike naming – names such as opensearch-setup, opensearch-setup-tool, opensearch-config-utility, elastic-opensearch-helper, search-engine-setup, and env-config-manager mimic well-known cluster-management and configuration libraries. Second, spoofed upstream metadata – every unscoped package sets its package.json homepage, repository, and bugs fields to the legitimate github.com/opensearch-project/opensearch-js project. Third, inflated version numbers – releases jump straight to 1.0.7265, 1.0.9108, or 2.1.9201 to suggest a long, mature release history.
Every package in the cluster declares an automatic install-time hook in package.json. The malicious code executes the moment a victim runs npm install – no require() from victim code is needed. Two stager variants were observed:
preinstall.js collects rich host context – hostname, platform, arch, Node version, USER/USERNAME, cwd, INIT_CWD, npm_package_name, npm_package_version – base64-encodes the JSON, and POSTs it to the actor’s C2 with a campaign-unique header X-Supply: 1. The same C2 endpoint then serves a gunzip-compressed second-stage binary, which is written to payload.bin in the package install directory, chmod 0755’d, and spawned detached.
The package’s index.js re-launches the same payload.bin on every subsequent require() of the module – a quiet persistence mechanism that survives across CI build stages and developer rebuild loops. The module also exports a benign-looking object falsely identifying itself as @opensearch/setup.
In newer versions, the actor replaced the noisy HTTP-C2 design with a stealthier loader that eliminates the install-time C2 round-trip entirely. setup.mjs (a) checks whether bun is already present on the host; (b) if not, downloads the legitimate Bun runtime v1.3.13 from github.com/oven-sh/bun/releases for the correct platform/arch (Linux x64/musl/aarch64, macOS x64/arm64, Windows x64/arm64); (c) extracts the ZIP using unzip, PowerShell Expand-Archive, or a hand-rolled ZIP parser; and (d) executes the pre-bundled second-stage payload (opensearch_init.js or ai_init.js) that ships inside the npm tarball.
This design reduces visibility for defenders that primarily monitor unusual outbound traffic during package installation.
The second-stage binary is a single-file Bun-compiled JavaScript binary of approximately 195 KB, purpose-built for cloud and CI/CD secret theft. Static review of the bundle identifies routines that target secrets across five platforms:
Microsoft recommends the following mitigations to reduce the impact of this threat:
Microsoft Defender Antivirus detects and blocks the malicious components on access. During reproduction in our analysis environment, setup.mjs was automatically quarantined the moment the tarball was extracted to disk.
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
| Tactic | Observed activity | Microsoft Defender coverage |
| Initial Access / Execution | Suspicious script execution during npm install or package lifecycle activity | Microsoft Defender Antivirus -Trojan:JS/ShaiWorm -Trojan:JS/ObfusNpmJs -Backdoor:JS/SupplyChain Microsoft Defender for Endpoint – Suspicious usage of Bun runtime – Suspicious installation of Bun runtime – Suspicious Node.js process behavior Microsoft Defender XDR – Suspicious file creation in temporary directory by node.exe – Suspicious Bun execution from Node.js process |
| Credential Access | Potential harvesting of AWS, Vault, GitHub Actions, and npm tokens from CI/CD runners | Microsoft Defender for Endpoint – Credential access attempt – Suspicious cloud credential access by npm-cached binary – AWS Instance Metadata Service access from suspicious process Microsoft Defender for Cloud – Possible IMDS abuse from container workload – Anomalous Secrets Manager enumeration across regions |
| Command and Control | Outbound HTTP beacon with X-Supply: 1 header to attacker-controlled C2 | Microsoft Defender for Endpoint – Connection to a custom network indicator (aab.sportsontheweb[.]net) – Suspicious outbound HTTP from npm install context |
| Persistence | Re-spawn of payload.bin on every require() of compromised package | Microsoft Defender for Endpoint – Detached child process spawned by node.exe with __DAEMONIZED=1 |
The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.
Hunt for suspicious npm lifecycle script execution involving vpmdhaj packages.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("node.exe", "node", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe")
| where ProcessCommandLine has_any ("preinstall", "postinstall", "install")
| where ProcessCommandLine has_any (
"@vpmdhaj", "opensearch-setup", "opensearch-setup-tool",
"opensearch-config-utility", "opensearch-security-scanner",
"search-engine-setup", "search-cluster-setup",
"elastic-opensearch-helper", "vpmdhaj-opensearch-setup",
"env-config-manager", "app-config-utility")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for the stage-2 payload artifact on disk.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName =~ "payload.bin"
| where FolderPath has "node_modules"
| project Timestamp, DeviceName, FolderPath, FileName,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for detached payload execution with the campaign environment marker.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "__DAEMONIZED=1"
or InitiatingProcessCommandLine has "__DAEMONIZED=1"
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
Hunt for Gen-2 loader: Bun runtime download from GitHub Releases by Node.js.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("node.exe", "node")
| where RemoteUrl has "github.com/oven-sh/bun/releases/download"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for C2 beacon to attacker infrastructure.
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has "aab.sportsontheweb.net"
or RemoteUrl has "sportsontheweb.net"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Hunt for AWS IMDS / ECS metadata access from Node.js processes.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("node.exe", "node", "bun.exe", "bun")
| where RemoteIP in ("169.254.169.254", "169.254.170.2")
| project Timestamp, DeviceName, RemoteIP, RemoteUrl,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
Affected npm packages – all published by maintainer vpmdhaj on 2026-05-28:
| Indicator | Type | Description |
| @vpmdhaj/elastic-helper (1.0.7269) | Package | Typosquat – ElasticSearch/OpenSearch helper |
| @vpmdhaj/devops-tools (1.0.7267) | Package | Typosquat – DevOps tools / OpenSearch setup |
| @vpmdhaj/opensearch-setup (1.0.7267) | Package | Typosquat – OpenSearch setup utility |
| @vpmdhaj/search-setup (1.0.7268) | Package | Typosquat – search engine setup |
| opensearch-security-scanner (1.0.10) | Package | Unscoped lookalike – security scanner |
| opensearch-setup (1.0.9103) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| opensearch-setup-tool (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| opensearch-config-utility (1.0.9106) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| search-engine-setup (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| search-cluster-setup (1.0.9104) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| elastic-opensearch-helper (1.0.9108) | Package | Unscoped lookalike – spoofs opensearch-project repo URL |
| vpmdhaj-opensearch-setup (1.0.9102) | Package | Unscoped – author-named OpenSearch setup |
| env-config-manager (2.1.9201) | Package | Typosquat – dotenv-style config manager |
| app-config-utility (1.0.9300) | Package | Typosquat – generic app config utility |
| Indicator | Type | Description |
| vpmdhaj | npm maintainer alias | Threat actor publishing all 14 packages |
| a39155771@gmail.com | Maintainer contact email registered on npm | |
| aab.sportsontheweb[.]net | Domain | Stage-1 C2 (Gen-1 packages) |
| hxxp://aab.sportsontheweb[.]net/x.php | URL | Beacon + stage-2 payload endpoint (port 80) |
| X-Supply: 1 | HTTP header | Campaign-unique marker – high-confidence proxy detection |
| 169.254.169.254 | IP | AWS EC2 IMDSv2 endpoint queried by stage-2 |
| 169.254.170.2 | IP | AWS ECS task metadata endpoint queried by stage-2 |
| 638788AFC4F1B5860A328312CAF5895ABD5F5632D28A4F2A85B09076E270D15D | SHA-256 | preinstall.js (Gen-1 stager) |
| 77D92EFE7AF3547F71FD41D4A884872D66B1BE9499EAA637E91EAC866911694D | SHA-256 | setup.mjs (Gen-2 stager) |
| BFA149694EC6411C23936311A999163ADE54D6F38E2F4B0E3CFB8CB67BD7CFAA | SHA-256 | payload.gz (gzipped Bun stage-2) |
| opensearch_init.js | Filename | Bun-compiled stage-2 credential harvester (~195 KB) |
| ai_init.js | Filename | Alternate stage-2 filename used by some Gen-2 packages |
| payload.bin | Filename | Dropped stage-2 binary in node_modules install dir |
| __DAEMONIZED=1 | Env var | Marker set by stager when spawning detached payload |
This research is provided by Microsoft Defender Security Research with contributions from members of Microsoft Threat Intelligence.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
The post Typosquatted npm packages used to steal cloud and CI/CD secrets appeared first on Microsoft Security Blog.
Congress wants answers from the Cybersecurity and Infrastructure Security Agency about the reported public exposure of sensitive agency credential data on GitHub in an incident that the security researcher who discovered it called one of the worst leaks he’s ever seen.
Other security professionals also voiced concern Tuesday about the leak and the potential for abuse by any malicious parties who got a hold of the information.
Security firm GitGuardian said it discovered a public GitHub repository last week that exposed credentials for privileged AWS GovCloud accounts and internal CISA systems dating back to November. The repository, apparently maintained by a contractor, was named “Private-CISA.”
Krebs on Security first reported the incident.
“My main fear … is that a state actor will get the data and might be able to do bad stuff,” GitGuardian security researcher Guillaume Valadon told CyberScoop that he thought to himself upon discovering the leak, after concluding it was real; he initially thought it looked fake.
State-based attackers who obtained the credentials “might be able to gain persistence,” Valadon said, “so for me it’s even worse than an attacker destroying everything, having someone in a governmental system — it’s really, really bad.”
A House Homeland Security Committee aide said the panel is seeking a staff-level briefing from CISA on the matter.
Mississippi Rep. Bennie Thompson, the top Democrat on the Homeland Security Committee, and Delia Ramirez, the top Democrat on the panel’s cyber subcommittee, had separately demanded a briefing Tuesday in a letter to CISA’s acting director, Nick Andersen.
They said they wanted to learn “how this serious security lapse occurred, any potential security consequences, remediation activities, corrective actions related to the contractor personnel involved, and efforts to monitor for and prevent similar activity from occurring in the future.”
Sen. Maggie Hassan, D-N.H., also sent a letter Tuesday to Andersen, seeking a classified briefing to answer questions about which systems were exposed, what forensic work CISA did to evaluate potential damage and what corrective action it has taken.
“This reported incident raises serious questions about how such a security lapse could occur at the very agency charged with helping to prevent cyber breaches,” Hassan wrote in the missive first reported by Axios, particularly “regarding CISA’s internal policies and procedures at a time of significant cybersecurity threats against U.S. critical infrastructure.”
Both letters pointed to personnel and budget cutbacks at the agency as a potential contributor to the incident.
CISA said it was looking into what happened.
“The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,” a spokesperson said. “Currently, there is no indication that any sensitive data was compromised as a result of this incident. While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”
The repository was reportedly maintained by a contractor at Nightwing. A Nightwing spokesperson referred questions to CISA.
The kind of exposure that happened for CISA “is an unfortunately painful, but common and repeated, if not relentless, way that we see organizations inadvertently leak very sensitive credentials to the wider web,” said Ben Harris, founder of WatchTowr, a company that helps organizations detect such exposures.
Harris told CyberScoop he didn’t want to speculate on what attackers who obtained the credentials might be able to do with it, but he said that it would be “terrifying” if the contractor was transferring information from work to home, as one researcher theorized.
Dave Mitchell, senior director of threat intelligence at Infoblox, told CyberScoop the incident showed the importance of teams having controls and audits in place across their repositories.
“Of all the things that keep me up at night, misconfigurations in GitHub are a recurring nightmare. It’s critical for so many organizations — all it takes is one accidental upload or misconfiguration and you’ve signed yourself up for a major incident,” he said in a written statement. “No need for a threat actor to use advanced techniques to compromise you if the keys are already sitting on the counter.”
Travis Rosiek, public sector chief technology officer at Rubrik, noted that the timing of the issue aligned with the government shutdown that only recently resolved for DHS. He said the incident showed the federal government needs to prioritize resilience.
“A persistent shortage of cybersecurity talent, combined with funding lapses, high workforce turnover, and an increasingly complex threat landscape, created the perfect storm for this scenario,” he said in a written statement to CyberScoop. “No organization is immune, and we must ensure that the federal government, which is responsible for helping protect the nation’s critical infrastructure and enhancing our cybersecurity posture, remains fully operational 24-7, 365 days a year.”
Without minimizing the severity of the incident, some researchers who have looked at the leak said there are mitigating circumstances that make elements of it defensible or, at least, understandable.
CISA acted very swiftly to remove the repository, Valadon said, once he alerted them to the leak.
And even if CISA has the right policies in place, human error still can make it difficult to entirely avoid incidents like this, Harris said.
“The reality is this happens every single day to different organizations, including cybersecurity companies,” he said, noting it would be different if it was a pattern. “This is not exclusive to CISA. I don’t really think it reflects well if we saw this every single day with CISA. … It’s not ideal that it’s even happened once, but the reality is that cybersecurity is people, process, technology.”
CISA has had other security incidents in the past, including recently. The former acting director of the agency endured criticism for uploading sensitive contract data to ChatGPT last year. In 2024 the agency notified Congress of a breach of a chemical plant security tool.
Updated 5/20/26: to include more information on a House Homeland Security Committee briefing request.
The post CISA credential leak raises alarms, and Capitol Hill demands answers appeared first on CyberScoop.
With the expansion of Microsoft Sentinel UEBA (User and Entity Behavior Analytics) into new data sources, spanning multi-cloud (AWS, GCP), identity providers (Okta), and authentication logs (Microsoft Defender for Endpoint DeviceLogon, Microsoft Entra ID Managed Identity, Service Principal sign-ins), defenders can now detect behavioral anomalies across hybrid environments from a single place.
We’ve also expanded AWS coverage with more anomalies, enrichments and insights, so CloudTrail events now arrive with more built-in context at ingestion time. This lets defenders triage suspicious activity faster without building and maintaining large baselines in KQL.
Many defenders analyze CloudTrail activity using thresholds or historical patterns to identify unusual behavior. In dynamic cloud environments, interpreting this activity can be challenging without additional behavioral context.
Microsoft Sentinel UEBA shifts the burden away from query authors by enriching raw AWS logs with simple binary insights (true/false) derived from user, activity, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. Detection authors can stack these binary signals or combine them with built-in UEBA anomalies to surface attacker behavior that would otherwise blend into routine CloudTrail activity.
In this post, you’ll learn how binary feature stacking works, how UEBA baselines AWS identities (human and non-human), and how to use UEBA enrichments and built-in anomalies to strengthen AWS detections and triage.
Defenders investigating AWS activity often rely on raw CloudTrail logs, static thresholds, or manually-engineered baselines to differentiate between normal operational patterns and adversary behavior. While CloudTrail captures rich activity data, defenders often need behavioral context – such as historical usage patterns, geography, and device signals – to distinguish routine operations from suspicious behavior. This is where Microsoft Sentinel UEBA adds value.
Microsoft Sentinel UEBA enriches raw AWS logs with simple, binary behavioral insights (true/false) derived from baseline user, peer, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. These clear binary signals help establish behavioral context and inform investigation and detection decisions. This post refers to this approach as binary feature stacking.
Microsoft Sentinel UEBA surfaces AWS behavioral context in two tables: BehaviorAnalytics and Anomalies.
The BehaviorAnalytics table is the primary investigation surface for UEBA-enriched AWS activity. EventSource field identifies the log source (for example, AWSCloudTrail), ActivityType maps to service level AWS EventSource (for example, S3, KMS, or IAM), and ActionType captures the AWS API name (for example, ConsoleLogin or CreateUser). Use these fields to filter and scope specific categories of AWS activity.
UEBA provides enrichments in three dynamic fields (UserInsights, DeviceInsights and ActivityInsights)– most importantly ActivityInsights, a JSON property bag that contains the binary behavioral features used for baseline-driven profiling. These enrichments are calculated at the user and tenant (AWS AccountId) level, as well as the activity level (for example, uncommon high volume of operations). Each enrichment uses a different baseline window, ranging from 7 days to 180 days.
This data is always available for hunting, even if no alert is fired. Each record includes key fields from the original CloudTrail event alongside enrichments derived from user, activity, and device behavior. The full list of available enrichments and their baseline lookback periods is documented in Entity enrichments – dynamic fields.
The Anomalies table contains outputs from Microsoft’s pre-trained anomaly detection machine learning models. Six built-in anomalies are currently available for AWS. For more information about these anomalies, see: Anomalies detected by the Microsoft Sentinel machine learning engine.
Each anomaly record includes MITRE ATT&CK mappings, behavioral enrichments, an AnomalyScore, and AnomalyReasons, which explains why an event was flagged as an anomaly.
Here’s an example of an AWS IAM Privilege Modification anomaly. In this case, the CreateLoginProfile API was invoked from a previously unseen user agent in a new country. The annotated screenshot illustrates how the anomaly is displayed and how the AnomalyReasons dynamic field provides binary insights that help investigation. In addition to FirstTimeUserPerformedAction and FirstTimeUserConnectedFromCountry, the BrowserUncommonlyUsedInTenant feature indicates a new user agent (Apache-HttpClient/UNAVAILABLE (Java/21.0.9)) not commonly seen in the tenant.
The Defender portal also surfaces UEBA anomalies on user entity pages and incident graphs.
This example highlights the Top UEBA anomalies section in an incident graph, where an Anomalous Logon event is displayed with an anomaly score of 0.8 for the account entity cloudinfra-admin.
You can run built-in queries directly from incident graphs by selecting Go Hunt All User anomalies queries for immediate context-driven hunting based on UEBA outcomes. For more details, see UEBA integration with Microsoft Sentinel workflows.
Let’s look at a classic AWS scenario: Unusual anomalous AWS logons. You want to detect a user’s sign in from an unknown location compared to its historical sign-in patterns.
CloudTrail telemetry can be analyzed using historical baselines and enrichment logic to understand behavioral patterns such as first‑time sign‑ins from new locations. UEBA complements this approach by providing pre‑computed behavioral indicators that can accelerate investigation workflows.
Here is the KQL example on raw log showing necessary operations to add behavioral context.
// The "Hard Way" - baseline-heavy console sign-in analytics
let baselineStart = ago(14d);
let baselineEnd = ago(1h);
let userBaseline = AWSCloudTrail
| where TimeGenerated between (baselineStart .. baselineEnd)
| where EventName == "ConsoleLogin" and isempty(ErrorCode)
| where isnotempty(SourceIpAddress)
| extend geo = geo_info_from_ip_address(SourceIpAddress)
| extend Country = tostring(geo["country"])
| where isnotempty(Country)
| summarize HistoricalCountries = make_set(Country) by UserIdentityPrincipalid;
AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName == "ConsoleLogin" and isempty(ErrorCode)
| where isnotempty(SourceIpAddress)
| extend geo = geo_info_from_ip_address(SourceIpAddress)
| extend Country = tostring(geo["country"])
| where isnotempty(Country)
| join kind=leftouter (userBaseline) on UserIdentityPrincipalid
| extend FirstTimeUserConnectedFromCountry = iif(isempty(HistoricalCountries) or not(set_has_element(HistoricalCountries, Country)), true, false)
| where FirstTimeUserConnectedFromCountry == true
The problem: This query is computationally expensive, hard to read, and requires you to manually enrich IP addresses with location data. Accurately mapping IP addresses to ASN and ISP often requires additional enrichments and up to date lookup databases. Because different user behaviors have different levels of variability, static thresholds and manually engineered baselines can still produce false positives or low-value alerts, especially in dynamic environments.
With Microsoft Sentinel UEBA, the profiling engine has already done the heavy lifting. It learns the user’s sign-in patterns, peer commonality, and tenant-wide behavioral patterns, and outputs the result to the BehaviorAnalytics table as a set of pre-calculated binary features (true/false flags).
KQL Code Snippet:
// The "Smart Way" - leveraging binary features BehaviorAnalytics | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" // The Binary Features | where ActivityInsights.FirstTimeUserConnectedFromCountry == True and ActivityInsights.CountryUncommonlyConnectedFromInTenant == True and ActivityInsights.FirstTimeConnectionViaISPInTenant == True
The advantages:
By relying on these binary features, detection authors stop writing code to discover behavioral signals and instead use UEBA features to express detection intent and how to respond based on severity.
Now let’s look at how these same signals appear during investigation and triage.
The table below summarizes four attack scenarios using a consistent set of fields:
Together, these scenarios illustrate how raw CloudTrail events provide foundational visibility into AWS activity. Combining this telemetry with behavioral enrichment from Sentinel UEBA can improve the interpretability of events during investigation. The same building blocks—successful sign-ins, IAM changes, Secrets or KMS access, and S3 reads—can represent either normal administration or active intrusion.
By combining CloudTrail activity with Sentinel UEBA enrichments in BehaviorAnalytics, defenders can stack multiple high-value signals to hunt for activity patterns that match attacker tradecraft.
This context accelerates investigations by making it easier to explain why an action is suspicious and to pivot directly to correlated entries in the Anomalies table, including risk scores and reasons. For detection engineers, UEBA signals also act as stable building blocks—simplifying KQL, reducing alert noise, and hardening detections over time.
Note: The UEBA signals column lists examples of relevant binary features, not the exact logic that triggers an anomaly. Anomalies are generated by ML models and don’t map one-to-one to individual features. Use AnomalyReasons in the Anomalies table to understand why a specific anomaly was flagged.
| Scenario | The attack | Common log view | UEBA signals (binary features) | Built-in anomaly surfaced |
| Initial Access (Federated / SAML Session Hijack) | An attacker gains access to a federated identity session – for example, through a compromised identity provider (IdP) – and uses a SAML or EXTERNAL_IDP flow to perform actions the user rarely performs, from a new location and at an unusual pace. | CloudTrail shows federated authentication activity (UserAuthentication / EXTERNAL_IDP, for example, Okta) followed by successful API calls under an assumed role session; each event is valid in isolation. | FirstTimeUserConnectedFromCountry = True ISPUncommonlyUsedInTenant = True ActionUncommonlyPerformedByUser = True ActionUncommonlyPerformedInTenant = True | UEBA Anomalous Federated or SAML Identity Activity in AwsCloudTrail |
| Initial Access and Persistence | An attacker compromises a developer’s access keys and logs in (for example, through uncommon user agent) to create a backdoor user. | CloudTrail shows a successful ConsoleLogin via SDK or CLI user agent and subsequent IAM action, such as CreateUser, all of which are valid API calls without behavioral context. | FirstTimeUserConnectedFromCountry = True BrowserUncommonlyUsedInTenant = True ActionUncommonlyPerformedByUser = True (CreateUser) ActionUncommonlyPerformedInTenant = True | Examples: UEBA Anomalous Logon in AwsCloudTrail; UEBA Anomalous IAM Privilege Modification in AwsCloudTrail |
| Credential Access & Collection (Secrets / KMS Key Discovery) | After establishing a foothold with valid credentials, an attacker queries Secrets Manager and KMS to list keys and retrieve secret values, often starting with discovery (ListSecrets/ListKeys) then access (GetSecretValue), sometimes at unusually high frequency. | CloudTrail shows a GetSecretValue, ListSecrets, or ListKeys activity which can look like legitimate automation and make static allowlists and thresholds brittle. | FirstTimeUserPerformedAction = True ActionUncommonlyPerformedInTenant = True UncommonHighVolumeOfOperations = True ISPUncommonlyUsedInTenant = True | UEBA Anomalous Secret or KMS Key Access in AwsCloudTrail |
| Data Exfiltration (the “low-and-slow” S3 drain) | A compromised admin account performs a burst of repeated S3 GetObject operations—representing a high volume of similar operations within the same service—often targeting multiple objects or prefixes in quick succession to stage data for exfiltration while staying below traditional volume thresholds. | If S3 data events are enabled, CloudTrail shows a high frequency of GetObject API calls across multiple objects or buckets in a short time window. Each request appears legitimate in isolation, and overall data transfer may remain below static thresholds, making the activity difficult to detect using traditional methods. | UncommonHighVolumeOfOperations = True CountryUncommonlyPerformedInTenant = True ActionUncommonlyPerformedByUser = True (S3 GetObject) ISPUncommonlyUsedInTenant = True | UEBA Anomalous Data Transfer from Amazon S3 |
Table 1: Examples of Microsoft Sentinel UEBA enrichments in real-world attack scenarios
The visual below illustrates how Microsoft Sentinel UEBA’s AWS anomaly coverage maps across multiple stages of the kill chain:
Together, these anomaly detections provide defenders with end-to-end visibility – from suspicious authentication through sensitive access and data movement – with binary feature enrichments that add high-value behavioral context during investigations.
Before you begin
Before you run the queries, ensure the following are in place:
Baseline establishment period completed
Allow sufficient time for UEBA to establish user, activity, and device baselines. In most environments, this typically requires 7–14 days of steady telemetry.
AWS environment onboarded to Microsoft Sentinel UEBA
Ensure that AWS CloudTrail (management events and, where applicable, object-level data) is connected, and UEBA is enabled for the AWS data source.
CloudTrail data is flowing consistently
Confirm that AWS CloudTrail events are being ingested into Microsoft Sentinel and visible in Advanced Hunting.
Ready to start hunting? Open Advanced Hunting in Microsoft Sentinel and run the following query to explore the BehaviorAnalytics table and inspect enriched AWS behavioral signals. This query intentionally keeps the logic lightweight. The goal is not to “detect” anomalous activity immediately, but to understand how binary behavioral features surface in your environment.
// Starter query – explore UEBA-enriched AWS behavioral signals
BehaviorAnalytics
| where EventSource == "AWSCloudTrail" or ActivityType endswith "amazonaws.com"
| where isnotempty(ActivityInsights)
| where ActivityInsights.FirstTimeUserConnectedFromCountry == true
or ActivityInsights.ActionUncommonlyPerformedByUser == true
or ActivityInsights.UncommonHighVolumeOfOperations == true
| project
TimeGenerated,
UserName,
ActionType,
EventSource,
ActivityType,
ActivityInsights
| order by TimeGenerated desc
When reviewing the results, focus on:
Once you are comfortable interpreting enriched behavior:
This approach lets detection authors focus on behavioral intent, not baseline math – turning raw AWS telemetry into actionable security signals.
Microsoft Sentinel UEBA can substantially reduce detection complexity, but it’s important to account for coverage boundaries and the conditions under which enrichments and scores are most reliable:
Coverage is selective (not “every API”).
Enrichments vary by event type.
Cross-cloud identity baselines are calculated independently.
Use scores for prioritization, not direct alerting without retroactive lookup.
Anomaly support in the UI is currently for UPN-based entities.
Some insights depend on identity and user agent fidelity.
CloudTrail provides detailed activity data. Sentinel UEBA enhances this telemetry with behavioral context, such as first‑time geography or uncommon ISP usage, to support investigation and detection workflows. A single failed console login is often low signal on its own. That same event becomes far more meaningful when it’s paired with behavioral context, such as a first-time country, an unusual ISP, or activity on a rarely used admin account.
By shifting our focus from writing complex queries to leveraging Microsoft Sentinel UEBA’s binary feature stacking, we gain three practical advantages:
For the modern SOC, the goal is not only to collect logs—it’s to understand behavior. Use the BehaviorAnalytics table as your starting point to understand what “normal” looks like in your environment, then pivot to related Anomalies when you need model-driven prioritization. In practice, this shifts investigations from “What happened?” to “Is this consistent with expected behavior?”
Ready to start hunting? Onboard your AWS environment to Microsoft Sentinel UEBA, open Advanced Hunting, and run the starter query in the Practical implementation section to explore the BehaviorAnalytics and Anomalies tables in your environment.
Learn about the UEBA Behaviors Layer for AWS CloudTrail and other data sources.
The Microsoft Sentinel UEBA Essentials solution provides additional built-in queries.
The post Simplifying AWS defense with Microsoft Sentinel UEBA appeared first on Microsoft Security Blog.
U.S. states issued $3.45 billion in privacy-related fines to companies in 2025, a total larger than the last five years combined, according to research and advisory firm Gartner.
The increase is driven in part by stronger, more established privacy laws in states like California, new interstate partnerships built around enforcing laws across state lines, and a renewed focus to how AI and automation affect privacy.
The data indicates that “regulators are shifting their efforts away from awareness to full scale enforcement,” marking a significant shift from even the last few years in how aggressively states are investigating and penalizing companies for privacy law violations.
“This is increasingly becoming the standard in 2026 and for the coming two years,” Gartner’s analysis concludes.
The California Consumer Privacy Act had consumer privacy provisions go live in 2023, but for years enforcement was largely dormant. According to Nader Heinen, a data protection and AI analyst at Gartner and co-author of the research, that enforcement lag mirrors the way other major privacy laws, like Europe’s Global Data Protection Regulation, have been carried out in order to “lead with a bit of guidance” for companies while using enforcement sparingly.
But that era appears to be over. In 2025, the California Privacy Protection Agency has used the law to pursue violators across a wide range of industries— not just large conglomerates, but smaller and mid-sized companies in tech, the auto industry, and consumer products, including off-the-shelf goods and apparel.
Heinen said some businesses “weren’t paying attention” and may have been lulled into a false sense of complacency as regulators spun up their enforcement teams, leading to a harsh 2025.
“Unfortunately what happens when so much time passes between the legislation and starting enforcement regularly, is a lot of organizations let their privacy program atrophy,” he said.
States have also sought to combine their resources to target and penalize privacy violators across state lines. Last year, ten states came together to form the Consortium of Privacy Regulators, pledging to coordinate investigations and enforcement of common privacy laws around accessing, deleting and preventing the sale of personal information.
Beyond laws like the CCPA, states have been updating existing privacy and data-protection laws to more directly address harms from automated decision-making technologies, including AI. State privacy regulators are especially focused on how personal or private data is used to train AI systems and help it make inferences.
Gartner expects privacy fines to further increase in the coming years and Heinen said states will likely again lead the way on building the legal infrastructure to enforce data privacy in the AI age as they become the main conduit for lingering anxiety about the potential negative impacts of the technology.
“You have to put yourself in the position of these state legislatures,” Heinen said. “Their constituencies – the voting public – is telling them we’re worried about AI. AI anxiety is a thing. Everybody’s worried about whether AI is going to take their job or impact their capacity to find a job, so they want to see legislation in place to protect them.”
This past month, House Republicans unveiled their latest attempt to pass comprehensive federal privacy legislation with a bill that would preempt tougher state laws like those in California. In particular, the CCPA gives residents a private right of action – the legal right to sue companies directly – for violation of privacy laws.
On Monday, Tom Kemp, executive director of the California Privacy Protection Agency, wrote to House Energy and Commerce Chair Brett Guthrie, R-Ky., to oppose the bill, arguing it would provide “a ceiling” for Americans’ data privacy protections rather than a “floor” to build on.
“Preemption would strip away important existing state privacy provisions that protect tens of millions of Americans now,” Kemp wrote. “That would be a significant step backward in privacy protection at a time when individuals are increasingly concerned about their privacy and security online, and when challenges from data-intensive new technologies such as AI are developing quickly.”
The post U.S. companies hit with record fines for privacy in 2025 appeared first on CyberScoop.
With the expansion of Microsoft Sentinel UEBA (User and Entity Behavior Analytics) into new data sources, spanning multi-cloud (AWS, GCP), identity providers (Okta), and authentication logs (Microsoft Defender for Endpoint DeviceLogon, Microsoft Entra ID Managed Identity, Service Principal sign-ins), defenders can now detect behavioral anomalies across hybrid environments from a single place.
We’ve also expanded AWS coverage with more anomalies, enrichments and insights, so CloudTrail events now arrive with more built-in context at ingestion time. This lets defenders triage suspicious activity faster without building and maintaining large baselines in KQL.
Many defenders analyze CloudTrail activity using thresholds or historical patterns to identify unusual behavior. In dynamic cloud environments, interpreting this activity can be challenging without additional behavioral context.
Microsoft Sentinel UEBA shifts the burden away from query authors by enriching raw AWS logs with simple binary insights (true/false) derived from user, activity, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. Detection authors can stack these binary signals or combine them with built-in UEBA anomalies to surface attacker behavior that would otherwise blend into routine CloudTrail activity.
In this post, you’ll learn how binary feature stacking works, how UEBA baselines AWS identities (human and non-human), and how to use UEBA enrichments and built-in anomalies to strengthen AWS detections and triage.
Defenders investigating AWS activity often rely on raw CloudTrail logs, static thresholds, or manually-engineered baselines to differentiate between normal operational patterns and adversary behavior. While CloudTrail captures rich activity data, defenders often need behavioral context – such as historical usage patterns, geography, and device signals – to distinguish routine operations from suspicious behavior. This is where Microsoft Sentinel UEBA adds value.
Microsoft Sentinel UEBA enriches raw AWS logs with simple, binary behavioral insights (true/false) derived from baseline user, peer, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. These clear binary signals help establish behavioral context and inform investigation and detection decisions. This post refers to this approach as binary feature stacking.
Microsoft Sentinel UEBA surfaces AWS behavioral context in two tables: BehaviorAnalytics and Anomalies.
The BehaviorAnalytics table is the primary investigation surface for UEBA-enriched AWS activity. EventSource field identifies the log source (for example, AWSCloudTrail), ActivityType maps to service level AWS EventSource (for example, S3, KMS, or IAM), and ActionType captures the AWS API name (for example, ConsoleLogin or CreateUser). Use these fields to filter and scope specific categories of AWS activity.
UEBA provides enrichments in three dynamic fields (UserInsights, DeviceInsights and ActivityInsights)– most importantly ActivityInsights, a JSON property bag that contains the binary behavioral features used for baseline-driven profiling. These enrichments are calculated at the user and tenant (AWS AccountId) level, as well as the activity level (for example, uncommon high volume of operations). Each enrichment uses a different baseline window, ranging from 7 days to 180 days.
This data is always available for hunting, even if no alert is fired. Each record includes key fields from the original CloudTrail event alongside enrichments derived from user, activity, and device behavior. The full list of available enrichments and their baseline lookback periods is documented in Entity enrichments – dynamic fields.
The Anomalies table contains outputs from Microsoft’s pre-trained anomaly detection machine learning models. Six built-in anomalies are currently available for AWS. For more information about these anomalies, see: Anomalies detected by the Microsoft Sentinel machine learning engine.
Each anomaly record includes MITRE ATT&CK mappings, behavioral enrichments, an AnomalyScore, and AnomalyReasons, which explains why an event was flagged as an anomaly.
Here’s an example of an AWS IAM Privilege Modification anomaly. In this case, the CreateLoginProfile API was invoked from a previously unseen user agent in a new country. The annotated screenshot illustrates how the anomaly is displayed and how the AnomalyReasons dynamic field provides binary insights that help investigation. In addition to FirstTimeUserPerformedAction and FirstTimeUserConnectedFromCountry, the BrowserUncommonlyUsedInTenant feature indicates a new user agent (Apache-HttpClient/UNAVAILABLE (Java/21.0.9)) not commonly seen in the tenant.
The Defender portal also surfaces UEBA anomalies on user entity pages and incident graphs.
This example highlights the Top UEBA anomalies section in an incident graph, where an Anomalous Logon event is displayed with an anomaly score of 0.8 for the account entity cloudinfra-admin.
You can run built-in queries directly from incident graphs by selecting Go Hunt All User anomalies queries for immediate context-driven hunting based on UEBA outcomes. For more details, see UEBA integration with Microsoft Sentinel workflows.
Let’s look at a classic AWS scenario: Unusual anomalous AWS logons. You want to detect a user’s sign in from an unknown location compared to its historical sign-in patterns.
CloudTrail telemetry can be analyzed using historical baselines and enrichment logic to understand behavioral patterns such as first‑time sign‑ins from new locations. UEBA complements this approach by providing pre‑computed behavioral indicators that can accelerate investigation workflows.
Here is the KQL example on raw log showing necessary operations to add behavioral context.
// The "Hard Way" - baseline-heavy console sign-in analytics
let baselineStart = ago(14d);
let baselineEnd = ago(1h);
let userBaseline = AWSCloudTrail
| where TimeGenerated between (baselineStart .. baselineEnd)
| where EventName == "ConsoleLogin" and isempty(ErrorCode)
| where isnotempty(SourceIpAddress)
| extend geo = geo_info_from_ip_address(SourceIpAddress)
| extend Country = tostring(geo["country"])
| where isnotempty(Country)
| summarize HistoricalCountries = make_set(Country) by UserIdentityPrincipalid;
AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName == "ConsoleLogin" and isempty(ErrorCode)
| where isnotempty(SourceIpAddress)
| extend geo = geo_info_from_ip_address(SourceIpAddress)
| extend Country = tostring(geo["country"])
| where isnotempty(Country)
| join kind=leftouter (userBaseline) on UserIdentityPrincipalid
| extend FirstTimeUserConnectedFromCountry = iif(isempty(HistoricalCountries) or not(set_has_element(HistoricalCountries, Country)), true, false)
| where FirstTimeUserConnectedFromCountry == true
The problem: This query is computationally expensive, hard to read, and requires you to manually enrich IP addresses with location data. Accurately mapping IP addresses to ASN and ISP often requires additional enrichments and up to date lookup databases. Because different user behaviors have different levels of variability, static thresholds and manually engineered baselines can still produce false positives or low-value alerts, especially in dynamic environments.
With Microsoft Sentinel UEBA, the profiling engine has already done the heavy lifting. It learns the user’s sign-in patterns, peer commonality, and tenant-wide behavioral patterns, and outputs the result to the BehaviorAnalytics table as a set of pre-calculated binary features (true/false flags).
KQL Code Snippet:
// The "Smart Way" - leveraging binary features BehaviorAnalytics | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" // The Binary Features | where ActivityInsights.FirstTimeUserConnectedFromCountry == True and ActivityInsights.CountryUncommonlyConnectedFromInTenant == True and ActivityInsights.FirstTimeConnectionViaISPInTenant == True
The advantages:
By relying on these binary features, detection authors stop writing code to discover behavioral signals and instead use UEBA features to express detection intent and how to respond based on severity.
Now let’s look at how these same signals appear during investigation and triage.
The table below summarizes four attack scenarios using a consistent set of fields:
Together, these scenarios illustrate how raw CloudTrail events provide foundational visibility into AWS activity. Combining this telemetry with behavioral enrichment from Sentinel UEBA can improve the interpretability of events during investigation. The same building blocks—successful sign-ins, IAM changes, Secrets or KMS access, and S3 reads—can represent either normal administration or active intrusion.
By combining CloudTrail activity with Sentinel UEBA enrichments in BehaviorAnalytics, defenders can stack multiple high-value signals to hunt for activity patterns that match attacker tradecraft.
This context accelerates investigations by making it easier to explain why an action is suspicious and to pivot directly to correlated entries in the Anomalies table, including risk scores and reasons. For detection engineers, UEBA signals also act as stable building blocks—simplifying KQL, reducing alert noise, and hardening detections over time.
Note: The UEBA signals column lists examples of relevant binary features, not the exact logic that triggers an anomaly. Anomalies are generated by ML models and don’t map one-to-one to individual features. Use AnomalyReasons in the Anomalies table to understand why a specific anomaly was flagged.
| Scenario | The attack | Common log view | UEBA signals (binary features) | Built-in anomaly surfaced |
| Initial Access (Federated / SAML Session Hijack) | An attacker gains access to a federated identity session – for example, through a compromised identity provider (IdP) – and uses a SAML or EXTERNAL_IDP flow to perform actions the user rarely performs, from a new location and at an unusual pace. | CloudTrail shows federated authentication activity (UserAuthentication / EXTERNAL_IDP, for example, Okta) followed by successful API calls under an assumed role session; each event is valid in isolation. | FirstTimeUserConnectedFromCountry = True ISPUncommonlyUsedInTenant = True ActionUncommonlyPerformedByUser = True ActionUncommonlyPerformedInTenant = True | UEBA Anomalous Federated or SAML Identity Activity in AwsCloudTrail |
| Initial Access and Persistence | An attacker compromises a developer’s access keys and logs in (for example, through uncommon user agent) to create a backdoor user. | CloudTrail shows a successful ConsoleLogin via SDK or CLI user agent and subsequent IAM action, such as CreateUser, all of which are valid API calls without behavioral context. | FirstTimeUserConnectedFromCountry = True BrowserUncommonlyUsedInTenant = True ActionUncommonlyPerformedByUser = True (CreateUser) ActionUncommonlyPerformedInTenant = True | Examples: UEBA Anomalous Logon in AwsCloudTrail; UEBA Anomalous IAM Privilege Modification in AwsCloudTrail |
| Credential Access & Collection (Secrets / KMS Key Discovery) | After establishing a foothold with valid credentials, an attacker queries Secrets Manager and KMS to list keys and retrieve secret values, often starting with discovery (ListSecrets/ListKeys) then access (GetSecretValue), sometimes at unusually high frequency. | CloudTrail shows a GetSecretValue, ListSecrets, or ListKeys activity which can look like legitimate automation and make static allowlists and thresholds brittle. | FirstTimeUserPerformedAction = True ActionUncommonlyPerformedInTenant = True UncommonHighVolumeOfOperations = True ISPUncommonlyUsedInTenant = True | UEBA Anomalous Secret or KMS Key Access in AwsCloudTrail |
| Data Exfiltration (the “low-and-slow” S3 drain) | A compromised admin account performs a burst of repeated S3 GetObject operations—representing a high volume of similar operations within the same service—often targeting multiple objects or prefixes in quick succession to stage data for exfiltration while staying below traditional volume thresholds. | If S3 data events are enabled, CloudTrail shows a high frequency of GetObject API calls across multiple objects or buckets in a short time window. Each request appears legitimate in isolation, and overall data transfer may remain below static thresholds, making the activity difficult to detect using traditional methods. | UncommonHighVolumeOfOperations = True CountryUncommonlyPerformedInTenant = True ActionUncommonlyPerformedByUser = True (S3 GetObject) ISPUncommonlyUsedInTenant = True | UEBA Anomalous Data Transfer from Amazon S3 |
Table 1: Examples of Microsoft Sentinel UEBA enrichments in real-world attack scenarios
The visual below illustrates how Microsoft Sentinel UEBA’s AWS anomaly coverage maps across multiple stages of the kill chain:
Together, these anomaly detections provide defenders with end-to-end visibility – from suspicious authentication through sensitive access and data movement – with binary feature enrichments that add high-value behavioral context during investigations.
Before you begin
Before you run the queries, ensure the following are in place:
Baseline establishment period completed
Allow sufficient time for UEBA to establish user, activity, and device baselines. In most environments, this typically requires 7–14 days of steady telemetry.
AWS environment onboarded to Microsoft Sentinel UEBA
Ensure that AWS CloudTrail (management events and, where applicable, object-level data) is connected, and UEBA is enabled for the AWS data source.
CloudTrail data is flowing consistently
Confirm that AWS CloudTrail events are being ingested into Microsoft Sentinel and visible in Advanced Hunting.
Ready to start hunting? Open Advanced Hunting in Microsoft Sentinel and run the following query to explore the BehaviorAnalytics table and inspect enriched AWS behavioral signals. This query intentionally keeps the logic lightweight. The goal is not to “detect” anomalous activity immediately, but to understand how binary behavioral features surface in your environment.
// Starter query – explore UEBA-enriched AWS behavioral signals
BehaviorAnalytics
| where EventSource == "AWSCloudTrail" or ActivityType endswith "amazonaws.com"
| where isnotempty(ActivityInsights)
| where ActivityInsights.FirstTimeUserConnectedFromCountry == true
or ActivityInsights.ActionUncommonlyPerformedByUser == true
or ActivityInsights.UncommonHighVolumeOfOperations == true
| project
TimeGenerated,
UserName,
ActionType,
EventSource,
ActivityType,
ActivityInsights
| order by TimeGenerated desc
When reviewing the results, focus on:
Once you are comfortable interpreting enriched behavior:
This approach lets detection authors focus on behavioral intent, not baseline math – turning raw AWS telemetry into actionable security signals.
Microsoft Sentinel UEBA can substantially reduce detection complexity, but it’s important to account for coverage boundaries and the conditions under which enrichments and scores are most reliable:
Coverage is selective (not “every API”).
Enrichments vary by event type.
Cross-cloud identity baselines are calculated independently.
Use scores for prioritization, not direct alerting without retroactive lookup.
Anomaly support in the UI is currently for UPN-based entities.
Some insights depend on identity and user agent fidelity.
CloudTrail provides detailed activity data. Sentinel UEBA enhances this telemetry with behavioral context, such as first‑time geography or uncommon ISP usage, to support investigation and detection workflows. A single failed console login is often low signal on its own. That same event becomes far more meaningful when it’s paired with behavioral context, such as a first-time country, an unusual ISP, or activity on a rarely used admin account.
By shifting our focus from writing complex queries to leveraging Microsoft Sentinel UEBA’s binary feature stacking, we gain three practical advantages:
For the modern SOC, the goal is not only to collect logs—it’s to understand behavior. Use the BehaviorAnalytics table as your starting point to understand what “normal” looks like in your environment, then pivot to related Anomalies when you need model-driven prioritization. In practice, this shifts investigations from “What happened?” to “Is this consistent with expected behavior?”
Ready to start hunting? Onboard your AWS environment to Microsoft Sentinel UEBA, open Advanced Hunting, and run the starter query in the Practical implementation section to explore the BehaviorAnalytics and Anomalies tables in your environment.
Learn about the UEBA Behaviors Layer for AWS CloudTrail and other data sources.
The Microsoft Sentinel UEBA Essentials solution provides additional built-in queries.
The post Simplifying AWS defense with Microsoft Sentinel UEBA appeared first on Microsoft Security Blog.
