Fake LastPass Authenticator Installer Abuses Microsoft-Signed Driver to Kill Antivirus and EDR

A fake LastPass Authenticator installer offered on GitHub installs a Windows kernel driver that shuts off antivirus and other security software before a password stealer runs if a victim downloads and runs it, researchers at LastPass and Delphos Labs said on September 17.

Microsoft's own hardware-compatibility program signs the driver, scored zero detections on VirusTotal when researchers checked it in August, and was not on Microsoft's list of blocked drivers. LastPass says none of its own systems, services, or customer vaults were touched, and that the attackers only borrowed its name.

The lure is a fake GitHub page (github.com/LastPass-Authenticator) that ranks in search results for terms like "LastPass Authenticator download" and looks like a real LastPass product page.

Clicking the download button sends the visitor through several GitHub pages to an attacker server, which serves a large ZIP file. The real LastPass Authenticator comes from lastpass.com and the official app stores, not GitHub.

Inside the ZIP is a renamed copy of a real Microsoft debugging tool, vsdbg.exe, placed next to a malicious file named vsdbg.dll. When the fake installer runs, Windows loads the attacker's DLL from the same folder, a trick called DLL side-loading. The loader then tries three ways to gain administrator rights, reaches SYSTEM, the highest level on a Windows machine, and installs the kernel driver as a service.

The archives seen were 148 MB and 127.9 MB, padded with junk files so that scanners with size limits skip them.

What the driver does, and why Windows trusts it

A kernel driver runs below the level where antivirus and endpoint detection and response (EDR) tools operate. This one, which the researchers named Alinubx.sys, carries a list of 145 antivirus and security process names and terminates each one it finds running.

It does this from the kernel, below the level where security software runs, so those user-mode tools cannot block or see the kill. Loading a legitimately signed but abusable driver to gain that access is a known technique called bring your own vulnerable driver, or BYOVD, which The Hacker News has covered before.

The driver is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing date of March 2023, years before this campaign. As the researchers put it, "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe."

The kill list is the only part of the driver that ran here. Its code can also hide files, inject into other programs, and reroute web traffic, but those need a configuration file the attackers did not include, so they stayed off.

What it did do is enough. With security software down, the stealer collected saved passwords from more than two dozen browsers, cryptocurrency wallet files, and login sessions for Discord, Steam, and Telegram, along with the contents of Windows Credential Manager and files named like "password," "seed," or "recovery."

For Chrome and Edge, which use Google's app-bound encryption to stop exactly this, the stealer injects code into the browser and asks the browser's own service to decrypt the passwords. The data is packed into a ZIP and sent to an attacker server.

Why nothing caught it

The driver is a renamed copy of CcProtect.sys, a driver from the Chinese disk-encryption product CnCrypt that is already listed on the LOLDrivers catalog as a process killer, with public proof-of-concept code. The two share the same product name, version, and submitter; only the file name and description changed.

That change dropped the file's antivirus detections: the known original showed 7 of about 70 engines flagging it in August, while the renamed driver showed zero.

The blocklist is a different matter. Microsoft's vulnerable driver blocklist, on by default since the Windows 11 2022 update, stops listed drivers from loading. Delphos checked it on August 20 and found neither the renamed driver nor the known original on it. The rename did not slip past the blocklist, because the original was never on it either.

The blocklist matches known file hashes, and a renamed or recompiled driver produces a new hash that the list does not carry. At the September 17 report, Alinubx.sys was still not on the blocklist.

Delphos reported the driver to Microsoft on August 19. Microsoft responded that the behavior does not meet its definition of a security vulnerability, because the driver is not a Microsoft component, and pointed the researchers to the separate channel that considers drivers for the blocklist. Delphos resubmitted there the same day.

If you ran the fake installer

Treat every password saved in the browser on that machine as stolen, along with any cryptocurrency wallet files, Discord, Steam, and Telegram sessions, and anything in Windows Credential Manager. The stealer copies these out before the driver work begins.

Change those passwords from a separate, clean device, not the affected one, and review account activity for anything you did not do. The driver stays loaded, re-kills security tools, and re-runs the stealer on every reboot, defeating the tools that would normally clean it up.

A machine that ran this payload should be treated as a kernel-level compromise and, where possible, given a kernel-level forensic check or rebuilt.

What defenders can hunt for

The researchers say to hunt for the driver's lineage and behavior rather than one file name, because the operators can change the name again as they did here. Signs to watch for:

• Service: a service created as NvFsFilter
• File: a driver written to C:\Windows\System32\drivers\nvfsflt64.sys
• Signer: a driver whose signing details name Henan Dafeng Software or contain "CnCrypt"
• Device: the path \\.\Alinubx
• Behavior: a driver load followed by security processes being killed

A community detection for the exact driver is published on LOLDrivers, though it matches by hash and so shares the same weakness once the file changes. Full indicators are in the joint report.

Where it came from

The LastPass page was one of many lures. The attacker server was serving impersonation pages for at least 40 brands, LastPass said, and a near-identical second fake page for a "macOS LastPass" product was taken down before the team could examine it.

Fake GitHub repositories delivering this family of stealer are not new: Trend Micro documented the BoryptGrab stealer spread this way in March, and Arctic Wolf reported a separate wave of nearly 300 such repositories in July.

Delphos assesses with high confidence that the loader was built with the Cruciferra crypter, a paid tool whose default kill list also holds 145 names and whose driver is interchangeable, and with moderate confidence that the stealer, which LastPass calls Rapuncel, is a relative of BoryptGrab rather than the same build. How many people were infected is unknown; the report provides no victim count.

from The Hacker News https://ift.tt/1vDB8TF
via IFTTT

Contagious Interview Campaign Compromises 30,000 Devices, Steals $10.71M in Crypto

The North Korean threat actors behind the Contagious Interview campaign have compromised at least 30,000 devices located in more than 100 countries and siphoned funds or account credentials from over 7,000 cryptocurrency wallets, according to a new joint cybersecurity advisory.

The primary targets of the campaign are individual web designers, engineers, and specialists in cryptocurrency, blockchain, and Web3 technologies. In all, the threat actors are estimated to have plundered at least $10.71 million worth of cryptocurrency from victims.

The alert comes courtesy of cybersecurity and intelligence agencies from Japan, the U.S., Australia, and Germany. The activity is tracked by the broader cybersecurity community under the monikers CL-STA-0240, DeceptiveDevelopment, DEV#POPPER, Famous Chollima, Gwisin Gang, PurpleBravo, Tenacious Pungsan, UNC5342, Void Dokkaebi, and WaterPlum.

The cyber threat group "conducts cyber attacks by infiltrating unsuspecting job seekers' computer networks, harvesting sensitive information, and stealing cryptocurrency," the alert said.

It's suspected that both WaterPlum and some North Korean IT workers (aka PurpleDelta or Wagemole) operate under the 313 General Bureau of the Munitions Industry Department, corroborating a June 2025 assessment from DTEX. What's more, the two clusters are said to be deeply intertwined, in some cases using the same IP addresses when accessing laptop farms and applying for positions at Japanese cryptocurrency exchanges.

Contagious Interview, first exposed by Palo Alto Networks Unit 42, is a long-running campaign that has been underway since at least 2022, targeting software developers and IT professionals across the wild by posing as prospective employers and recruiters, and approaching them on social media platforms like LinkedIn under the pretext of lucrative job offers.

Once initial rapport is established, the threat actors instruct targets to complete a job assessment or coding test, triggering a multi-step infection chain that leads to the deployment of various malware families, including BeaverTail, InvisibleFerret, FlexibleFerret, GolangGhost, PylangGhost, OtterCookie, RATatouille, OtterCandy, and StoatWaffle.

The backdoor access afforded is then abused by the adversary to deliver remote access trojans for enabling persistent access and data exfiltration.

"Some WaterPlum actors also operate as North Korean IT workers performing web system design and development tasks on corporate web systems for clients," the agencies said, adding a laptop farm operated by a facilitator in Japan has been identified and dismantled.

Furthermore, WaterPlum has been observed using online chat platforms to communicate with U.S. and Japanese developers, while employing enablers in Japan, the U.S., and other countries to set up and manage laptop farms for remote device management.

"Beyond immediate credential theft, successful infections provide WaterPlum actors opportunities to infiltrate organizations employing targeted developers, enabling espionage, intellectual property theft, and additional lateral movement in corporate environments," the agencies noted. "Stolen ID images can also be used by North Korean IT workers to impersonate victims and generate foreign currency."

IT Worker Threat Expands to Discord for Recruiting Proxies

Complementing North Korea's offensive cyber capabilities is the infamous IT worker scheme, which is tasked with generating illicit revenue for the regime by landing jobs in Western companies and elsewhere under false identities. The operation is also known for increasingly relying on artificial intelligence (AI) to craft fictitious identities and expand its activities globally.

Sekoia, in its overview of North Korea's cyber operations, described the IT worker program as an adaptation of an established practice that involved the "dispatch of North Korean labor abroad to earn foreign currency dates to the 1960s and 1970s, beginning with logging in the Soviet Far East before broadening into construction, textiles and restaurant services across Russia, China, the Gulf and Africa."

According to a July 2026 analysis of the internal infrastructure linked to the threat, Kudelski Security said the primary targets appear to be the U.S. and Japan, with the threat actors using VPN services like Astrill VPN and Mullvad to obtain exit nodes in these countries.

In a report published last week, Silent Push said it identified a North Korean IT worker spreading a fake job recruitment scam via a Discord server named "Mouse Review," specifically hiring individuals based in the U.S., the E.U., and Latin America to act as proxies and attend job interviews so as to get around sanctions, geographic blocks, and compliance checks.

The AI-generated job advertisement claims: "YOUR ROLE IS SIMPLE, BUT CRUCIAL. You handle communications and interviews. I handle all technical work behind the scenes. You get paid consistently for your communication."

Facilitators who end up securing a job are eligible for anywhere between $3,000 and $5,000, the ad continues. "For live coding challenges, I can remotely access your screen and complete coding tasks while you continue the conversation smoothly."

"The North Korean IT worker's primary goal is proxy hiring, using Western or Latin American (LATAM) citizens as the 'face' and legal identity to bypass sanctions, KYC (identity verification) controls, and regional hiring restrictions," Silent Push said. "The job ad scam offers a financial incentive split (35% to the proxy, 65% to the North Korean IT Worker) to incentivize foreign nationals to serve as financial and identity mules."

from The Hacker News https://ift.tt/FervXuC
via IFTTT

Google Fined €403 Million Over GDPR Violations Tied to Location Data

Google has been fined €403 million for breaking the EU's data protection law, the GDPR, in the way three of its features handled people's location data from May 2018 to February 2020.

Ireland's Data Protection Commission (DPC), Google's lead regulator in the EU, also ordered the company to make its processing comply with the law within 6 months. The DPC has not said publicly which processing the order covers, and it says its full decision will be published later.

The three features are Web & App Activity, Location History and Location Accuracy.

Web & App Activity is a Google account setting that, when turned on, lets Google process data about a user's activity on its sites and apps. That data can include location. Location History, which users must opt in to, keeps track of where they go with their signed-in mobile devices, even when they are not using a Google service.

For both cases, the DPC found that Google breached the GDPR's rules on lawful and fair processing and on transparency, and that it retained location data longer than necessary.

Location Accuracy is an Android feature that works out a device's location more precisely than GPS alone, and it is available to Android users with or without a Google account. The DPC's findings for this feature are narrower.

Google broke the transparency rules and the GDPR's accountability rules because it could not demonstrate that this processing was lawful, fair and transparent.

DPC Deputy Commissioner Graham Doyle said these failures meant people could have been unaware that their location was being used, for example, to influence them with ads or to infer their interests. They could also lose control of their personal data, and keeping it for so long made that worse.

At €403 million, the fine is the fourth-largest the DPC has issued. It cannot be collected yet, because a DPC fine becomes payable only after an Irish court confirms it. Google can appeal to the High Court within 28 days of receiving formal notice of the decision.

In a statement reported by the Associated Press, Google said the case "centers around historical policies that have since been updated" and that it has changed its practices significantly since 2019.

In May 2019, during the period the DPC examined, Google announced auto-delete controls for Location History and Web & App Activity. They let users have that data deleted automatically after 3 or 18 months. In June 2020, Google made 18-month auto-delete the default for Web & App Activity on new accounts and for anyone turning on Location History for the first time.

In December 2023, Google announced that Timeline, the Google Maps feature that shows Location History on a map, would keep its data on users' devices. Auto-delete would also default to 3 months for anyone turning on Location History for the first time.

The DPC has not publicly said whether these changes are sufficient to meet its order.

The DPC opened its inquiry in February 2020 after complaints from European consumer groups, including BEUC, the European Consumer Organization. BEUC's member groups had filed the complaints with national data protection authorities in November 2018. The period the DPC examined ends on 4 February 2020, the day it announced the inquiry.

The decision came more than 6.5 years after the inquiry opened. In comments reported by NewsIreland.EU, BEUC director general Agustín Reyna welcomed it but criticized how long it took. "Late enforcement can be as harmful as no enforcement at all," he said.

from The Hacker News https://ift.tt/ixzRZyj
via IFTTT

TASK#STOMP PowerShell Backdoor Steals Documents, Wi-Fi Passwords, and Clipboard Data

Cybersecurity researchers have disclosed details of a new campaign dubbed TASK#STOMP that delivers a PowerShell backdoor designed to harvest sensitive data from compromised hosts.

The backdoor "automatically harvests and exfiltrates business documents, watches the filesystem for new files in real time, steals Wi-Fi passwords and clipboard contents, takes screenshots, and accepts arbitrary remote commands through two redundant, token-authenticated C2 servers," Securonix researchers Akshay Gaikwad and Aaron Beardslee said in a report shared with The Hacker News.

The starting point of the infection chain is the use of "wscript.exe" to execute an encoded Visual Basic Script (VBScript) file staged on the victim's desktop ("95c9050t66.vbs"). The exact initial access pathway used to deliver the payload is unclear, although it's possible that it may have been via email-based phishing or social engineering.

By giving it a completely random file name, it's suspected that the intention may have been to evade file name-based detection mechanisms. The VBScript functions as the orchestrator for establishing persistence on the host using scheduled tasks and launching subsequent stages.

The tasks are given the names Local Credential Manager, Network Audio Service, Windows Display Manager, and Device Credential Handler so as to blend in with regular operating system activity and avoid raising any red flags.

The VBScript installer also sets up a backup persistence method that uses the Windows Startup folder to launch another script payload ("msdiag.vbs") every time the user logs in to the system. In the next phase, the malware executes PowerShell commands to forcibly terminate previously running instances and ensure there exists only one active session

These strategies, paired with deliberate timestamp modification (aka timestomping), hidden execution, and cleanup behavior, suggest a deliberate effort to get around superficial administrative reviews and complicate forensic analysis. The use of redundant persistence methods guarantees continued execution even if one of them fails or is detected and removed.

The next phase involves running a pair of hidden PowerShell commands -

• sys_loader.ps1, which decodes "diag_pack.dat" and initiates the document-stealing, surveillance, and remote-access
• payload to steal system metadata, business documents, Wi-Fi passwords, and clipboard content, monitor for newly modified files, take screenshots, and execute arbitrary PowerShell commands
• win_conn.ps1, which decodes "win_conn_cfg.dat" and sets up a secondary, persistent C2 channel with command execution and collection capabilities

"Running the modules as separate processes provides functional separation and operational redundancy: failure or termination of one branch does not immediately remove the other," Securonix said.

Both the modules communicate with the same C2 infrastructure ("corecloudfileshare[.]xyz" or "attachmentsharingdrive[.]xyz"). Interestingly, the two components incorporate a mutual-watchdog relationship in which "diag_pack.dat" checks if "win_conn.ps1" is running, and restart it if not, and vice versa.

The end goal of the attack is to provide a pathway for continuous document collection, credential and clipboard theft, screenshot capture, redundant C2 communications, and arbitrary code execution, while leveraging an array of techniques to fly under the radar.

In the final stage, the VBScript orchestrator opens Google Chrome in a maximized window and opens a specific URL from "irantenders[.]com," which hosts a searchable database of all tenders and contracts issued by government departments and local authorities in Iran. The purpose behind this user-facing web action is unknown.

Also launched is a batch script ("purge.bat") that invokes a two-second delay and likely performs a clean-up to erase traces of the malicious activity. That said, what this batch script does is unknown as its contents have not been recovered.

"Threat actors routinely abuse Windows Script Host, PowerShell, Task Scheduler, and the .NET toolchain to blend malicious execution with legitimate administrative activity," the researchers said.

"TASK#STOMP demonstrates this approach through a VBS-controlled framework that installs multiple persistence anchors and delegates follow-on functionality to PowerShell and dynamically compiled C# code. By relying almost entirely on native Windows components, the operation reduces its dependence on conventional executable payloads and makes individual events more difficult to distinguish from benign system activity."

from The Hacker News https://ift.tt/hd6KzNY
via IFTTT

From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies

Executive Summary

This article explores how AWS mitigates the security risks associated with publicly exposed Identity and Access Management (IAM) access keys through its AWSCompromisedKeyQuarantine managed policy. We discuss the evolution of the different versions of this AWS managed policy. We also show how the managed policy AWSCompromisedKeyQuarantine evolved over time to protect organizations by relating it directly to new cloud attacks against AWS environments.

Additionally, this article provides background to the partner integration between GitHub's secret scanning program and AWS. Our research details how the managed policy automatically gets attached with a step-by-step timeline of a real-world exposure test.

Finally, the article highlights practical monitoring strategies for security teams to detect quarantine events within their own logging environments to ensure rapid incident response.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

• • Cortex Cloud
  • Idira Privilege Access Management (PAM)

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics

IAM, Exposed Credentials, Identity

AWSCompromisedKeyQuarantine Background

When organizations face attacks against their AWS environments, misuse of AWS IAM user access keys continue to account for a large majority of initial attack vectors. These long-term access keys pose security risks to organizations if the permissions associated with the IAM users do not follow the principle of least privilege.

Access keys and their associated secrets become exposed in many different ways, commonly through publication in public code repositories or exposure in environment variable files. If AWS receives notifications about access keys and secrets exposed in public GitHub repositories or through other notices, it promptly secures those credentials and notifies the owners.

AWS secures the exposed credentials using automated processes, which allows it to quickly support victim organizations and limit their exposure. This automated process has been around for many years and was documented by cloud security researcher Pawel Rzepa in the AWS Access Keys Leak in GitHub Repository and the Some Improvements in Amazon Reaction posts.

Before delving into the importance of the AWSCompromisedKeyQuarantine managed policy and its purpose, we will first discuss how managed policies work within AWS environments.

The AWS IAM service offers various features for configuring identities within an AWS account. In particular, AWS provides a policy feature that aggregates permissions into an object for attachment to a principal.

Policies encompass a wide range of types, but this article focuses on identity-based policies. Identity-based policies specifically attach to an identity, while other policy types attach to resources or define permission limitations, such as a permission boundary.

These policies consist of managed (AWS-managed and customer-managed) and inline policies. Managed policies include three sub-types:

• AWS managed
• AWS managed for job functions
• Customer managed

Figure 1 shows the breakdown of these policies.

Figure 1. Breakdown of IAM features in relation to main IAM service.

AWS-managed policies exist to assist organizations with IAM permission management. They also enable organizations to configure permissions to stand up resources within an AWS account swiftly and securely. Of the AWS-managed policies, AWSCompromisedKeyQuarantine specifically helps protect an IAM user in case of an exposed AWS IAM access key and secret. Access keys grant long-term command line interface (CLI) access to an IAM user.

AWS created the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, later releasing V2 on April 21, 2021, and V3 on Aug. 21, 2024. According to the V3 managed policy description, this policy:

“Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources. Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.”

We will cover the evolution of the policy permissions and the implication of those changes in the Managed Policy Permission Evolution section of this article.

Analyzing this policy in detail matters because AWS automatically attaches it upon locating exposed credentials in public code repositories or external exposure notifications. The AWSCompromisedKeyQuarantine managed policy proactively assists customers during access key exposures to minimize potential damage from attackers. Once attached, the managed policy limits the scope of permissions associated with the IAM user by denying various permissions commonly misused by threat actors.

GitHub Secret Scanning Partner Program

Long-term access keys can be exposed in many different ways. For example, it could be due to them being included in publicly accessible environment variable files and or public code repositories.

To help protect against exposing sensitive credentials, GitHub established the secret scanning partner program starting in 2018 and expanded to include AWS in 2020. It then created validity checks in January 2023 and push protection in August 2023 (discussed in more detail in the GitHub Validity Checks for Detecting Secrets Exposure section).

The GitHub secret scanning partner program allows it to scan public surfaces across GitHub, including repositories and public npm packages for specific sequences to identify exposed credentials. These scans occur by default within public repositories. Administrators and owners can also enable scanning on private repositories. Service partners can work with GitHub to create specific sequences for scanning and then provide an HTTP endpoint for GitHub to alert the service provider to exposed credentials in public repositories.

This alert allows the service provider to then proactively notify their customers about exposed credentials, and in some cases, the service providers take steps to secure the secret by revoking or quarantining the exposed secret. GitHub documentation lists more than 500 detectors across over 200 service partners, such as AWS. The checkbox in GitHub’s documentation notes when GitHub has an agreement to share compromised secret leaks with the respective issuer.

Managed Policy Attachment and Notification Process

When AWS first released the AWSCompromisedKeyQuarantine managed policy, the notification process differed from the current iteration. The original process entailed emailing the AWS account owner of the exposure. The process evolved to also attach the managed policy to the IAM user associated with the exposed access key and secret. The process has evolved again to include a support ticket generated within the AWS account containing the exposed access key.

We performed a test exposing an access key with a public GitHub repository in the main branch to track the response time and notification process. During the test scenario, AWS attached the AWSCompromisedKeyQuarantineV3 managed policy within 10 seconds of the access key exposure. A second later, GitHub generated a notification. This was followed shortly by AWS generating various Health and Support tickets.

The timeline below details each step of the testing process with commentary about what actions appear in the default AWS CloudTrail logs. The CloudTrail service, enabled by default for 90 days, records all management events occurring within an AWS account. During the test, we did not enable any additional CloudTrail data events so all the events in the timeline appear in the default CloudTrail logs. All times listed below are in Coordinated Universal Time (UTC).

• Dec. 19, 2025 17:28:39 - CreateUser - CloudTrail logs showed the creation of the initial IAM user with the arbitrary username TestUser
• Dec. 19, 2025 17:29:44 - CreateAccessKey - CloudTrail logs showed the creation of the new access key associated with the newly created IAM user
• Dec. 19, 2025 17:34:23 - GetCallerIdentity - CloudTrail logs showed the initial test of the access key with aws sts get-caller-identity
• Dec. 19, 2025 18:46:57 - When trying to push a new text file into the GitHub repository, GitHub push protection noted that it identified an access key and secret, as noted below in Figure 2. Both the access key and the secret each generated a pop-up asking whether the push with the credentials was purposeful.

Figure 2. GitHub notification of an AWS access key.

• Dec. 19, 2025 18:50:05 - Access key and secret successfully pushed to public GitHub Repository
• Dec. 19, 2025 18:50:15 - CloudTrail logs show the attachment of the AWSCompromisedKeyQuarantineV3 managed policy with the AttachUserPolicy event as noted in Figure 3. The CloudTrail log did not indicate this was an AWS automated action. Instead, the userIdentity JSON field, which identifies the action's performer, listed the IAM user's name (TestUser as shown in Figure 4) even though TestUser did not perform this action.

Figure 3. AWSCompromisedKeyQuarantineV3 managed policy attached.

Figure 4. JSON entry from the CloudTrail log.

• Dec. 19, 2025 18:50:16 - GitHub also sent out an email notification stating that it identified the sensitive access key and secret. Figure 5 shows the body of this email notification.

Figure 5. Content from the GitHub email notification.

• Dec. 19, 2025 18:50:17 - In the AWS console, a notification appeared noting that an AWS Health alert was created with the name Risk IAM quarantine, as noted below in Figure 6. This action did not generate an event in the CloudTrail logs.

Figure 6. AWS console showing the Health alert.

• Dec. 19, 2025 18:50:26 - AWS also sent out an email notification, shown below in Figure 7. This contained the same information as a Support ticket created seconds later in the AWS console.

Figure 7. Content from the AWS email notification.

• Dec. 19, 2025 18:50:59 - In the AWS console, a Support case was also created with details of the exposed access key and IAM user. Figure 8 shows the details of this case. Creating a Support case also did not generate an event in the CloudTrail logs.

Figure 8. Details of the Support case in the AWS console.

Figure 9 shows the high-level chain of events from the timeline illustrated in Figures 2–8.

Figure 9. Access key and secret exposure test scenario high-level timeline.

Within some organizations, the cloud engineering teams monitor emails regarding an AWS account and the security team is unaware of these emails. To prevent these communication gaps, security professionals can leverage AWS Systems Manager Explorer which helps aggregate AWS Support cases. The security team can also proactively enable alerting in the tool of their choice, based on the attachment event in the CloudTrail logs.

Within the CloudTrail logs, when any version of the AWSCompromisedKeyQuarantine managed policy gets attached to an IAM user, the event name AttachUserPolicy with the event source of IAM will be generated. The name of the managed policy will be present within the requestparameters subfield PolicyArn. This helps security teams proactively stay on top of exposed credentials and quickly begin investigating the access key in question.

Managed Policy Permission Evolution

After the initial release of the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, AWS has continued to update the policy to keep protecting their customers from new threats. AWS performs two types of version updates for managed policies. In minor updates, AWS makes changes to the permissions in the policy and updates the policy version without changing the managed policy name. In major updates, AWS creates a new managed policy and appends vX with the new version number to the end of the policy name.

Originally, the permissions of AWSCompromisedKeyQuarantine v1 focused on limiting 28 actions for the following five services:

• IAM
• Amazon Elastic Cloud Compute (EC2)
• AWS Organizations
• AWS Lambda
• Amazon Lightsail

However, with each new version of the managed policy, those permissions have evolved and expanded.

The code snippet below from the AWSCompromisedKeyQuarantine v1 managed policy JSON permissions details the full JSON permissions associated with the first version of this managed policy. Unlike traditional managed policies, this specific policy contains a Deny effect on permissions. After identifying an exposed access key, AWS does not need to modify the existing permissions associated with the IAM user to protect the identity from exploitation.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

{   "Version" : "2012-10-17",   "Statement" : [     {       "Effect" : "Deny",       "Action" : [         "iam:AttachGroupPolicy",         "iam:AttachRolePolicy",         "iam:AttachUserPolicy",         "iam:ChangePassword",         "iam:CreateAccessKey",         "iam:CreateInstanceProfile",         "iam:CreateLoginProfile",         "iam:CreateRole",         "iam:CreateUser",         "iam:DetachUserPolicy",         "iam:PutUserPermissionsBoundary",         "iam:PutUserPolicy",         "iam:UpdateAccessKey",         "iam:UpdateAccountPasswordPolicy",         "iam:UpdateUser",         "ec2:RequestSpotInstances",         "ec2:RunInstances",         "ec2:StartInstances",         "organizations:CreateAccount",         "organizations:CreateOrganization",         "organizations:InviteAccountToOrganization",         "lambda:CreateFunction",         "lightsail:Create*",         "lightsail:Start*",         "lightsail:Delete*",         "lightsail:Update*",         "lightsail:GetInstanceAccessDetails",         "lightsail:DownloadDefaultKeyPair"       ],       "Resource" : [         "*"       ]     }   ] }

Simply attaching these AWSCompromisedKeyQuarantine policies with the Deny component helps limit unauthorized usage of the key. When interpreting IAM user permissions, AWS dictates that explicit Deny overrides explicit Allow. So even if the IAM user permissions contained iam:CreateUser with an Allow for the effect, the AWSCompromisedKeyQuarantine managed policy containing iam:CreateUser with a Deny for the effect will override the Allow.

If the IAM user had completely different permissions than those listed below, then the purpose of the identity would not be impacted by these permission limits. Since the attachment of this specific managed policy occurs automatically, AWS wants to balance operational impact with securing the exposed credentials.

Another policy exists, AWSDenyAll, which denies all actions. However, this has a significant impact on any processes using the access key and secret. The AWSCompromisedKeyQuarantine policy limits the majority of risky threat actor activity while also allowing normal business operations.

AWS purposefully denies specific actions rather than completely disabling the compromised access key or user password. However, this decision allows advanced threat actors to use the exposed credentials for any actions the policy does not explicitly deny.

With AWSCompromisedKeyQuarantineV2, released on April 21, 2021, the permissions evolved to include the Amazon Simple Storage Service (S3) service with 11 permissions and 16 additional permissions to the original five services. Throughout the five versions of AWSCompromisedKeyQuarantineV2, AWS ultimately added a total of 61 permissions to the Deny list across 17 services.

When reviewing the different JSON permissions within v1 and v2 of AWSCompromisedKeyQuarantineV3, we identified that it replicated the additions to AWSCompromisedKeyQuarantineV2 v4 and v5 and added no additional permissions. Tables 1–3 detail the modifications made throughout each version of the managed policy.

Managed Policy Version	Version Release Date	Permissions changed
v1	2020-08-11 18:04:13	N/A

Table 1. AWSCompromisedKeyQuarantine permission changes per version.

Managed Policy Version	Version Release Date	Permissions changed
v1	April 21, 2021 22:30:59	Add: "iam:AddUserToGroup", "iam:CreatePolicyVersion", "iam:PassRole", "iam:PutGroupPolicy", "iam:PutRolePolicy", "iam:SetDefaultPolicyVersion", "iam:UpdateAssumeRolePolicy", "iam:UpdateLoginProfile", "lambda:AddLayerVersionPermission", "lambda:AddPermission", "lambda:GetPolicy", "lambda:ListTags", "lambda:PutProvisionedConcurrencyConfig", "lambda:TagResource", "lambda:UntagResource", "lambda:UpdateFunctionCode", "s3:DeleteBucket", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:PutLifecycleConfiguration", "s3:PutBucketAcl", "s3:DeleteBucketOwnershipControls", "s3:DeleteBucketPolicy", "s3:ObjectOwnerOverrideToBucketOwner", "s3:PutAccountPublicAccessBlock", "s3:PutBucketPolicy", "s3:ListAllMyBuckets"
v2	Nov. 11, 2021 21:32:48	Add: "s3:PutBucketOwnershipControls", Remove: "s3:DeleteBucketOwnershipControls"
v3	Aug. 10, 2022 21:15:53	Add: "cloudtrail:LookupEvents"
v4	March 16, 2023 00:20:25	Add: "ec2:PurchaseReservedInstancesOffering", "ec2:AcceptReservedInstancesExchangeQuote", "ec2:CreateReservedInstancesListing", "savingsplans:CreateSavingsPlan"
v5	Oct. 2, 2024 16:41:39	Add: "ecs:CreateService", "ecs:CreateCluster", "ecs:RegisterTaskDefinition", "ecr:GetAuthorizationToken", "bedrock:CreateModelInvocationJob", "bedrock:InvokeModelWithResponseStream", "bedrock:CreateFoundationModelAgreement", "bedrock:PutFoundationModelEntitlement", "bedrock:InvokeModel", "s3:CreateBucket", "s3:PutBucketCors", "s3:GetObject", "s3:ListBucket", "sagemaker:CreateEndpointConfig", "sagemaker:CreateProcessingJob", "ses:GetSendQuota", "ses:ListIdentities", "sts:GetSessionToken", "sts:GetFederationToken", "amplify:CreateDeployment", "amplify:CreateBackendEnvironment", "codebuild:CreateProject", "glue:CreateJob", "iam:DeleteRole", "iam:DeleteAccessKey", "iam:ListUsers", "lambda:GetEventSourceMapping", "sns:GetSMSAttributes", "mediapackagev2:CreateChannel"

Table 2. AWSCompromisedKeyQuarantineV2 permission changes per version.

Managed Policy Version	Version Release Date	Permissions changed
v1	2024-08-21 17:36:49	Same as AWSCompromisedKeyQuarantineV2 v4
v2	2024-10-02 16:52:27	Same as AWSCompromisedKeyQuarantineV2 v5 AWSCompromisedKeyQuarantineV3 v2 created 11 minutes after AWSCompromisedKeyQuarantineV2 v5

Table 3. AWSCompromisedKeyQuarantineV3 permission changes per version.

After releasing a new version, AWS stops attaching older policies to the exposed IAM users. Starting with AWSCompromisedKeyQuarantineV2, the Support service contains the support ticket with the attachment details as outlined in Table 1.

Cloud Attack Transition Based on Policy Updates

The evolution of the AWSCompromisedKeyQuarantine managed policy reflects how threat actors have changed their attacks against AWS environments. This section discusses an example permission added to the various versions of the managed policy and illustrates how various attacks might have caused that addition.

Let’s start with iam:CreateRole and lambda:CreateFunction in the AWSCompromisedKeyQuarantine v1 managed policy. This AWS Security Blog discusses how AWS uncovered a cryptomining campaign. Part of the attack involved creating a new IAM role to attach to the threat actor-created Lambda function. Once attached, the AWSCompromisedKeyQuarantine managed policy would have prevented this threat actor from creating a Lambda function and role.

The AWSCompromisedKeyQuarantineV2 v1 managed policy contains the s3:DeleteObject action. As discussed in an InfoRisk Today article, threat actors delete data from S3 buckets after exfiltration to maximize impact and encourage payment of extortion fees. Once again, if attached, the managed policy would have prevented the threat actor from successfully deleting all the data from the S3 bucket.

To counter malicious activity targeting the Amazon Bedrock service, AWS expanded v5 of the AWSCompromisedKeyQuarantineV2 managed policy to restrict five Bedrock permissions. This update was directly influenced by research from Permiso, which exposed how attackers exploit Bedrock to run unauthorized API calls like InvokeModel. Due to these policy enhancements, the attack methods uncovered by Permiso can now also be blocked.

GitHub Validity Checks for Detecting Secrets Exposure

GitHub has also created validity checks as part of its GitHub Secret Protection program (a subprogram of the GitHub Advanced Security program, or GHAS). When enabled, these checks periodically verify the validity of a detected credential by testing it against API endpoints provided by that service provider.

A list of supported secret scanning patterns can be found within the GitHub support secret scanning patterns documentation. Once GitHub identifies a secret, the platform proactively checks with various service providers to determine whether the exposed secret remains active or inactive, or whether it cannot be confirmed. GitHub also performs GET requests with the exposed credentials to confirm the credential’s validity and filters out dummy data.

After exposure of long-term AWS access keys in GitHub repositories, these GET requests take the form of performing the AWS Security Token Service (STS) API call GetCallerIdentity. This API event subsequently appears in the CloudTrail logs for the specific AWS account containing the exposed access key. Our testing triggered the newer push protection features that assist with catching secrets before they’re pushed to repositories.

A note of caution: There are some scenarios where push protection may will not scan a code push or alert on all identified secrets:

• In one scenario, push protection does not detect secrets in the event of an overly large code push (e.g., pushing thousands of files or a public repository exceeding 50 MB)
• In another scenario, if a single code push contains more than five exposed secrets, only five will generate alerts

These scenarios could result in an identification gap. Security teams should monitor for these potential cases to ensure additional scanning occurs on those code pushes, preventing any missed secrets.

Our testing generated CloudTrail logs that contain IP addresses, which resolve to the GitHub Autonomous System Number (ASN). The user agent present within the logs identifies the API event as originating from an automated testing process.

In early October of 2025, GitHub updated the user agent associated with AWS credential checks from:

aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-Please-contact-secret-scanning-github.com-for-more-info.

To:

aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-For-questions-on-our-processes--please-contact-secret-scanning-github.com.

Note: The above user agent strings use an asterisk (*) as a wildcard value for the version numbers.

Organizations need strong internal relationships between teams managing the organization’s GitHub repositories and cloud environments to promptly address exposed credentials. To circumvent organizational inefficiencies and issues between teams, security teams can also monitor for these exposed access keys by creating alerts specifically around GitHub ASN IP addresses with the above user agents performing GetCallerIdentity. This helps security teams proactively monitor exposed credentials and quickly begin investigating the access key before a potential attacker can misuse it.

Conclusion

The creation of the AWSCompromisedKeyQuarantine managed policy has proactively secured many organizations against unknowingly exposed IAM access keys and secrets. As the managed policy evolves, it reflects how attackers change their tactics when targeting cloud environments. Using the attachment of the managed policy and the presence of the GitHub validity check user agent, organizations can quickly address an exposure and investigate potential unwanted activity.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
• Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

User Agents:

aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-Please-contact-secret-scanning-github.com-for-more-info.

aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-For-questions-on-our-processes--please-contact-secret-scanning-github.com.

Note: The above user agent strings use an asterisk (*) as a wildcard value for the version numbers.

from Unit 42 https://ift.tt/u41QPSN
via IFTTT

Meet ShapeBlue at Community Over Code Glasgow 2026

This October, ShapeBlue is heading to Glasgow for Community Over Code 2026, the official open-source conference of The Apache Software Foundation (ASF).

Taking place from 11–14 October, Community Over Code brings together contributors, committers, users and organisations from across the Apache ecosystem for four days of technical sessions, real-world experiences and open source collaboration.

Apache CloudStack has a dedicated track in this year’s programme, and three members of the ShapeBlue team will be taking part, sharing their knowledge and experience across four sessions.

Meet the ShapeBlue Speakers

Giles Sirett, CEO

Introduction to Apache CloudStack

Giles Sirett will introduce Apache CloudStack and explore the fundamentals of the open source platform for building and managing IaaS clouds.

The session is an opportunity for those newer to the project to understand what Apache CloudStack is, where it fits within modern cloud infrastructure and how organisations around the world are using it to build and operate their cloud environments.

 

Daan Hoogland, Community Lead

Anything as a Service

Daan Hoogland will take the conversation beyond traditional cloud infrastructure with Anything as a Service.

 

 

Boris Stoyanov, Director of Engineering

How Scalable Is CloudStack?

How far can Apache CloudStack scale?

CloudStack has always known to be scalable, but just how scalable? In this talk, Boris will cover the known and anticipated CloudStack scalability limits. Will also share design decisions that can be made to accommodate growth and examples of organisations running CloudStack at a massive scale.
 
Orchestrating GPU with Apache CloudStack

In his second session Boris will explore how GPU resources can be orchestrated with Apache CloudStack.

Modern workloads such as AI/ML, HPC, and graphics require GPU acceleration. This session will explore how Apache CloudStack enables GPU orchestration, provisioning, and management to deliver scalable GPU powered infrastructure for cloud environment
 

Join Us in Glasgow

For ShapeBlue, contributing to Apache CloudStack goes far beyond the work we do for our customers. Our team has been actively involved in the project and its community for many years, and Community Over Code provides another opportunity to share that experience, exchange ideas and connect with people from across the wider Apache ecosystem.

If you’re attending Community Over Code Glasgow, join the Apache CloudStack track and come and meet Giles, Daan and Boris.
 

Join the next CloudStack Event

If you want to dive even deeper into Apache CloudStack, join the global community again this November at the CloudStack Collaboration Conference 2026.

Taking place in Edinburgh from 18–20 November, the conference brings together CloudStack users, contributors, operators, developers and technology partners for three days of technical sessions, real-world deployment stories, project updates and community collaboration.
 
Register now and join the Apache CloudStack community in Edinburgh.

Register now

The post Meet ShapeBlue at Community Over Code Glasgow 2026 appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/dJWUCx2
via IFTTT

ClickFix Lures Deploy ChainScript RAT Using Polygon to Rotate C2 Infrastructure

Threat actors are leveraging ClickFix-like lures to deliver a previously undocumented remote access trojan (RAT) called ChainScript.

"ChainScript has appeared under multiple build names, including ComponentTask33, UpdateDigital, HostShared, and OrchidViolet66, while presenting itself as Spotify, Zoom Workplace, and Microsoft Teams software," Blackpoint Adversary Pursuit Group (APG) researchers Sam Decker, Andi Ursry, and Nevan Beal said.

Like many malware families observed in recent months, ChainScript employs an EtherHiding-style command-and-control (C2) discovery technique that makes use of a Polygon smart contract to locate its active WebSocket infrastructure.

ChainScript is a full-featured RAT that provides extensive remote access to the operator, including interactive CMD and PowerShell, file operations, screenshot capture, payload deployment, cryptocurrency wallet enumeration (both desktop apps and browser extensions), and remote JavaScript execution.

The starting point of the attack chain is a ClickFix lure that leads to the download and execution of a malicious Windows installer using "msiexec.exe." The installer ("ComponentTask33-4d14e6ac.msi"), disguised as Spotify, deploys the Node.js runtime and launches the ChainScript JavaScript agent through hidden PowerShell and VBScript stages.

The PowerShell script drops various components, namely, the runtime, agent source, configuration, and other auxiliary binaries, across different Microsoft-looking paths in the "%LOCALAPPDATA%" folder. The VBScript serves as the main launcher for ChainScript.

The running agent then establishes user level persistence through a scheduled task with a Registry Run key fallback. Upon execution, ChainScript connects to the C2 server over WebSockets and retrieves additional tasking, giving the threat actor direct control over the compromised system. The supported commands also allow it to self-update and remove persistence.

The findings illustrate how threat actors are increasingly adopting a flexible decentralized infrastructure as a way to resist takedown efforts and ensure uninterrupted operations.

"ChainScript reflects an emerging pattern of malware using development frameworks and blockchain-based C2 discovery to enable infrastructure rotation and complicate traditional indicator-based detection," Blackpoint said. "By separating backend discovery from the malware itself and using the Polygon contract as an external resolver, the operator can redirect infected hosts to new infrastructure while retaining the same implant and reconnect workflow."

ClickFix, a Way for Mac and Windows Users to Infect Themselves

The disclosure comes as threat actors compromised HBO Max's official Reddit account ("u/hbomax") and abused it to push malicious ads that launched ClickFix attacks to infect Windows and macOS devices with information-stealing malware. The activity has been codenamed PasteSwitch by Hudson Rock and ADAMnetworks. It's not known how the account was breached, and how many people clicked on these fake ads and how many were compromised as a result.

On macOS, PasteSwitch has been found to deliver MacSync, Atomic macOS Stealer (AMOS), and fake cryptocurrency wallet applications designed to steal recovery phrases. The Windows branch, on the other hand, distributes Amatera Stealer and cryptocurrency clippers like AnimateClipper and ZigClipper. In all, the verified Reddit account served 108 malicious ads over a 48-hour period in mid-September 2026.

According to data shared by Seqrite Labs, MacSync infections have concentrated in the U.S., followed by the U.K., Germany, Japan, Canada, France, Singapore, Australia, India, and the Netherlands. "MacSync campaigns primarily target regions with widespread macOS enterprise use, tech and software development sectors, and active cryptocurrency or Web3 communities," researcher Chandra Kant Bauri said.

"The threat actors utilized highly polished assets to establish trust before delivering the malicious payload," Hudson Rock said. "By hijacking a verified corporate account, they bypassed the initial skepticism many users apply to internet advertisements."

The findings dovetail with another ClickFix campaign that employs a fake Codex download experience surfaced via search results to lead users to bogus Google Sites pages and trick macOS users into pasting a malicious command into Terminal, resulting in the execution of Atomic Stealer. Visitors using non-Mac devices are served a harmless decoy page.

"The copied Terminal command first retrieves a shell-script loader: the first stage," Cato Networks said. "This loader contains an embedded blob that it decodes and executes with eval, producing the second-stage shell script. The second stage then records execution and retrieves the final, third-stage Mach-O payload."

The cybersecurity company described the activity as part of a broader pattern of attacks that employ trusted services and large language model (LLM) shared chats to serve fake installation instructions, while bypassing browser warnings, URL inspection, and Safe Browsing heuristics.

In a report published last month, Microsoft said it observed a macOS ClickFix campaign propagating MacSync and Atomic Stealer using a cluster of no less than 250 look-alike domains.

"The campaign evolved from broadly serving ClickFix lures to using a server-side browser-fingerprinting gate that shows the lure primarily to visitors whose environment appears consistent with a genuine macOS browser," it said. "This cloaking limits visibility for crawlers, sandboxes, and some automated analysis workflows."

from The Hacker News https://ift.tt/kB2nAju
via IFTTT

Jade Sleet Linked to Indian IT Provider Breach With FLATROOF and ROOFDECK Backdoors

The North Korean threat actor known as Jade Sleet has been attributed to the compromise of an India-based "much smaller organization" in the information technology (IT) services industry, once again highlighting how the adversary continues to target developers to breach target networks.

Cybersecurity company SentinelOne, which disclosed details of the activity, said it involved the use of Apple macOS backdoors tracked as FLATROOF (aka Gaslight) and ROOFDECK, both of which were previously observed in the March-April 2026 attack on KelpDAO's LayerZero bridge.

Jade Sleet, also tracked under the monikers PUKCHONG, Slow Pisces, TraderTraitor, and UNC4899, has a history of targeting the Web3 sector for cryptocurrency heists. In early 2025, the hacking group was tied to the theft of about $1.5 billion from Bybit's cold wallet infrastructure following a supply chain compromise of Safe{Wallet}'s developer environment.

"Jade Sleet mostly targets users associated with cryptocurrency and other blockchain-related organizations, but also targets vendors used by those firms," Microsoft-owned GitHub noted in July 2023.

SentinelOne said the campaign employs social engineering using job interview lures, a common tactic adopted by multiple North Korean threat actors, to target job seekers from the companies that are breached over the course of the attack. Targeted individuals have been found to work in the DevOps, cryptocurrency, or financial technology space.

"The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as," security researchers Albert Priego, Alex Delamotte, and Matej Havranek said.

Some of the repositories observed are listed below -

• gtn-candidate-repo (used in the KelpDAO incident)
• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories include a weaponized Terraform dependency lock file (".terraform.lock.hcl") pointing to malicious domains (e.g., "registry.hashicorp-aws[.]com") that causes the platform to download attacker-controlled modules when the "terraform init" command is run by the unsuspecting developer.

The attack chain culminates in the deployment of two Rust-based malware families targeting ARM-based macOS systems -

• FLATROOF, a backdoor that uses Telegram for command-and-control (C2) and is capable of command execution, file upload and download, and data theft via a Python module that can collect Chrome, Brave, Firefox, and Safari browser data, Terminal command histories, installed application listings, system hardware and software profile, a snapshot of running processes, and a copy of login.keychain-db
• ROOFDECK, a backdoor that uses the Nostr protocol for decentralized C2 and is capable of system reconnaissance, file manipulation, remote shell access, lateral movement, and establishing persistence via Launch Agents

"ROOFDECK commands are signed with the operator's private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code," SentinelOne said.

"The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus' LightlessCan."

The cybersecurity company said its hunt for the two backdoors uncovered an additional unrelated victim, an IT services provider based in India that was compromised through an Apple Silicon MacBook belonging to a DevOps engineer. The backdoors are said to have been detected on the machine as early as March 18, 2026, although the exact delivery mechanism is unknown at this stage.

"They remained dormant until March 29, when beaconing and host activity began," the researchers said. "The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace [~/DevOps-Automation/cloudshield] was opened."

Evidence indicates that ROOFDECK is deployed as a follow-up tool on compromised hosts following the establishment of initial foothold and control. What's more, an updated version of ROOFDECK is said to have been deployed on the DevOps engineer's system on April 20, 2026, a day after LayerZero publicly acknowledged the KelpDAO hack.

The new variant, besides removing the existing ROOFDECK and FLATROOF binaries, removes symbols and debug information in an attempt to evade detection.

"These groups' initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense," SentinelOne said.

"Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim."

from The Hacker News https://ift.tt/5GnbPJv
via IFTTT

AI News for Mid-September 2026

Aaron and Brandon cover what the week's news means for enterprise buyers. They question whether Oracle's reported $664 billion backlog is durable demand or overlapping commitments, and Brandon argues contracted future spend is how enterprise business works. On the labs' "slow down" messaging, Brandon sees no coordination, only incentives, while Aaron finds the timing too coincidental. Salesforce's Nemotron-based model points to enterprises customizing open models instead of building their own, and Brandon doubts labs will displace systems of record like Workday or SAP. Aaron argues agent pricing has reverted to familiar free, bundled, and negotiated tiers. He sees agent swarms as research capability that most enterprises lack the trust and human-in-the-loop controls to run.

SHOW SPONSORS:

• Nasuni - Activate your data for AI and request a demo
• NordLayer - Use ENTERPRISE10 for 10% off.

SHOW: 1064

SHOW TRANSCRIPT: The Enterprise AI Show #1064 Transcript

SHOW VIDEO: https://youtu.be/hrfTovN3kMw

SHOW LINKS:

• https://theenterpriseaishow.com/

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/wZuWpv2
via IFTTT

Identity Visibility in 2026: The Foundation of Identity Security

Identity visibility is a starting point for modern identity security, because stolen and misused credentials are among the most frequently reported initial access vectors in breach research, including Verizon's annual Data Breach Investigations Report. This article explains what identity visibility means in IAM, why cloud and multicloud environments complicate it, which capabilities matter in identity visibility tools, and how to build a practical program.

What is identity visibility?

Identity visibility is the ability to see every identity in an environment, what it can access, and how that access is actually used at runtime. It combines inventory, entitlement mapping, and behavioral telemetry into one continuous picture instead of a periodic snapshot.

The important distinction is between intent and execution. Identity and access management (IAM) platforms express policy intent: who should have access, under what conditions, and for how long. Applications and infrastructure reveal execution: which credentials authenticated, which permissions were exercised, and which paths were taken.

The space between those two layers is where identity dark matter lives: local application accounts, embedded service credentials, legacy authentication flows, and integrations that were never onboarded into a central identity provider (IdP). That hidden surface is what makes visibility a security problem rather than an administrative one.

Why identity visibility has become a critical IAM challenge

Identity dark matter is rarely an isolated edge case. It is a common byproduct of a decade of SaaS adoption, cloud migration, and automation. When organizations add systems faster than their identity programs can absorb them, the gap between documented access and real access widens.

The expanding identity attack surface

Attackers have adapted to that gap. Instead of deploying malware that endpoint tools are tuned to catch, many intrusions now begin with compromised legitimate credentials used within the permissions those credentials already hold. The resulting activity can closely resemble normal operational behavior.

Drivers of identity attack surface growth

• Credential-based intrusion: Phishing, token theft, and session hijacking produce authentication events that resemble normal user behavior in IdP logs.
• Machine and non-human identities: Service accounts, API keys, and workload credentials frequently outnumber employee accounts in cloud-heavy environments and often have no expiration.
• Application-local accounts: Systems that authenticate outside single sign-on (SSO) may never appear in centralized access reviews.
• Agentic AI workloads: Autonomous agents act with delegated permissions across multiple systems, often at a pace and volume that manual review cannot match.

Why traditional IAM reporting falls short

Most IAM reporting describes configuration: group memberships, role assignments, and entitlement catalogs. That data answers what access was granted, but not whether the application enforced it, whether the account still has a human owner, or whether the permission has been used in the last year.

Governance platforms also tend to report on the applications connected to them rather than verify coverage independently. If an application was never integrated, it does not appear in the report, and absence can be mistaken for compliance.

Understanding identity visibility in IAM: core concepts

Verification, not assumption, is the organizing principle behind identity visibility in IAM. Three concepts make that verification possible: accurate inventory, mapped access relationships, and continuous contextual analysis.

Identities, entitlements, and access relationships

An identity inventory lists the actors. An entitlement map explains what each actor can do. Access relationships connect the two across systems, revealing effective permissions rather than nominal ones.

Effective access is often broader than intended. A user assigned a modest application role may inherit administrative capability through a nested group, a shared service account, or a trust relationship between cloud accounts. Relationship mapping exposes those chained paths, and those paths are what attackers traverse during lateral movement.

Continuous discovery and contextual risk analysis

Discovery answers a harder question than inventory: what exists that nobody registered? Continuous discovery pulls identity data directly from applications and infrastructure, surfacing local accounts, embedded credentials, and authentication methods that centralized IAM platforms never recorded.

Context then converts findings into priorities. A dormant account with read access to a test system is low-consequence noise. A non-expiring automation credential with write access to production, no assigned owner, and no multi-factor authentication (MFA) carries materially higher risk.

Cloud identity visibility and the multicloud identity visibility challenge

Context fragments the moment identity data crosses provider boundaries. Cloud identity visibility is difficult not because cloud platforms lack logging, but because each one models identity differently and none of them describes what happens in the others.

Identity silos across cloud providers and SaaS applications

Each platform expresses permissions in its own vocabulary. Multicloud identity visibility is the practice of normalizing those vocabularies so a single identity can be traced across every environment it touches.

Identity models that require normalization

• AWS: Roles, identity- and resource-based policies, and cross-account role assumption define what a principal can reach.
• Azure/Entra ID: Directory principals, Azure RBAC role assignments, and consented application permissions (delegated and application scopes).
• Google Cloud: Service accounts and IAM bindings that inherit scope through the organization, folder, and project hierarchy.
• SaaS applications: Proprietary admin tiers, custom roles, and local accounts that never reach the identity provider.

Without normalization, security teams review each platform separately and can miss the connective tissue: federated trust, cross-account assumption, and shared credentials that let an identity in one cloud act inside another. Cloud lateral movement commonly follows these IAM trust relationships rather than network paths.

Human, machine, and nonhuman identities in the cloud

Machine identities are a subset of non-human identities, and in cloud environments they often represent the majority of principals. Infrastructure automation creates them — pipelines, Terraform runs, orchestration tools — rather than HR-driven joiner-mover-leaver events, so they tend to bypass the lifecycle governance built for employees.

Control-plane identities deserve particular attention. Because they configure infrastructure itself, a compromised automation credential can create new access, alter logging configuration, or disable the controls meant to detect it. Every non-human identity benefits from the same governance attributes as a human account: a named owner, a stated purpose, an expiration or rotation schedule, and active monitoring.

Monitoring machine and human identities at scale is the job of identity visibility and intelligence platforms (IVIP), a category that emerged because governance, cloud posture, and detection tools each addressed part of the problem. The vendors below approach it from different architectural starting points.

Identity visibility platforms and their primary approaches

The list is illustrative rather than exhaustive, and it is not ordered by performance. Capability sets overlap and change frequently, so evaluate against your own environment and requirements. Note that this page is published by Orchid Security, which appears in the list.

1. Orchid Security: Discovers identities, entitlements, and authentication flows directly from applications and infrastructure rather than relying only on IAM configuration data, and turns that telemetry into audit-ready compliance evidence. Oriented toward application-layer blind spots.
2. Veza: Observability-centric access graph that maps effective permissions across data systems, cloud platforms, and SaaS, with an emphasis on entitlement-relationship analysis.
3. SailPoint: Governance-centric identity security platform focused on lifecycle management, certification campaigns, and policy enforcement at enterprise scale.
4. Saviynt: Converged governance and cloud entitlement management, combining identity governance and administration (IGA) workflows with cloud infrastructure entitlement management (CIEM) analysis.
5. Silverfort: Runtime authentication visibility and enforcement, including legacy and unmanaged systems that cannot readily be onboarded to modern SSO.
6. Semperis: Posture-centric protection for Active Directory and Entra ID, emphasizing configuration hygiene, attack-path analysis, and recovery.
7. CrowdStrike Falcon Identity Protection: Detection-centric identity threat detection and response (ITDR) tied closely to endpoint and workload telemetry.

Unified identity inventory and access mapping

Whatever the starting architecture, the baseline capability is the same: one authoritative inventory that reconciles identities across IdPs, cloud platforms, applications, and infrastructure, then maps effective access between them.

A useful test of that inventory is whether it includes identities nobody registered. A platform that reads only IAM configuration will reproduce the blind spots already present in IAM. Application-layer discovery separates a report from an inventory.

Inventory without analysis creates a longer list, not a safer environment. Detection quality depends on the behavioral baseline: knowing what normal usage looks like for a given identity before judging a deviation.

Analytics capabilities worth evaluating

• Behavioral baselining: Distinguishes routine automation activity from anomalous privilege use by the same credential.
• Attack-path analysis: Assesses whether a misconfiguration is exploitable given permissions, reachability, and runtime context.
• Technique mapping: Aligns findings to MITRE ATT&CK identity-related techniques, such as Valid Accounts (T1078), so analysts can reason about adversary behavior rather than isolated alerts.
• Remediation routing: Sends findings to the owning team with the evidence needed to act, rather than to a shared queue.

How identity visibility and intelligence fits the identity fabric

Identity visibility and intelligence is not a replacement layer. It is the observability layer that makes existing identity investments verifiable.

Connecting IAM, IGA, PAM, and security operations

IAM platforms generally operate in two dimensions: design time, covering lifecycle, policy, and provisioning, and runtime, covering authentication and authorization enforcement. Visibility platforms observe both and report the difference between them.

That reporting feeds each neighboring system differently. IGA receives evidence that certifications reflect real access. Privileged access management (PAM) receives discovery of privileged accounts operating outside vaulting. Security operations receive identity context that can shorten timeline reconstruction during an investigation, instead of requiring analysts to stitch events together across several consoles.

Using identity intelligence to support zero trust

Zero trust, as described in NIST SP 800-207, assumes continuous verification, and continuous verification requires continuous observation. Access decisions are only as good as the signal behind them: session context, credential type, historical behavior, and the sensitivity of the target system.

Identity intelligence supplies that signal. It also supplies the counterweight: evidence of where enforcement is not actually happening, such as applications still accepting legacy authentication protocols or administrative accounts without MFA.

Real-world use cases and implementation best practices

Prioritization is where many programs succeed or stall. Mature organizations tend to treat identity visibility as a maturity journey: from manual, static governance, to automated and continuous control, to behavioral observability across applications and infrastructure.

Prioritizing high-risk identities and excessive privileges

Permission sprawl is a common finding in cloud environments, often because IAM policies were provisioned broadly during deployment and never right-sized afterward. Start where excess privilege intersects with exposure.

Practical first targets include unowned service accounts with production write access, administrative accounts authenticating without MFA, credentials that have never been rotated, and dormant accounts belonging to departed staff. Each is a concrete, fixable finding with a clear owner, which builds credibility for the broader program.

Building a phased identity visibility program

Sequencing matters because discovery generates volume, and volume without a remediation path creates alert fatigue.

Program rollout sequence

1. Scope definition: Identify the crown-jewel applications and cloud accounts where identity compromise would cause the most damage.
2. Direct discovery: Pull identity and entitlement data from those applications and infrastructure layers, not only from the IdP.
3. Effective access mapping: Resolve nested groups, trust relationships, and inherited permissions into real capability.
4. Ownership assignment: Give every account, including non-human ones, a named human owner and a review or expiration date.
5. Behavioral monitoring: Baseline normal usage and alert on deviations in privilege use and authentication patterns.
6. Evidence automation: Generate compliance artifacts from live telemetry rather than reassembling spreadsheets each audit cycle.

Timelines vary widely with environment complexity, application count, and the availability of application owners.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/7Ny32lu
via IFTTT