The Rapid Change of Cloud Dynamics

Are the dynamics of the hyperscale cloud providers changing? Will the leaders of the last decade continue for the next 3-5 years, or the next decade? Let’s explore how the market is now rapidly changing.

SHOW: 934

SHOW TRANSCRIPT: The Cloudcast #934 Transcript

SHOW VIDEO: https://youtube.com/@TheCloudcastNET 

CLOUD NEWS OF THE WEEK: http://bit.ly/cloudcast-cnotw

CHECK OUT OUR NEW PODCAST: "CLOUDCAST BASICS"

SHOW SPONSORS:

• [US CLOUD] Cut Enterprise IT Support Costs by 30-50% with US Cloud
• [VASION] Vasion Print eliminates the need for print servers by enabling secure, cloud-based printing from any device, anywhere. Get a custom demo to see the difference for yourself.

SHOW NOTES:

• Andy Jassy (Amazon CEO) - Thoughts on Generative AI 
• AWS quarterly revenue growth 
• OpenAI struggling to meet deadline for $20B investment (including Microsoft)
• Inside Microsoft’s complex relationship with OpenAI
• Google Cloud quarterly revenues
• BG2 Podcast
• East Meets West 2025 (keynote presentation)

TECHNOLOGY WAVES CHANGE MARKET DYNAMICS; INCUMBENTS DON’T ALWAYS LEAD

• Revenues: AWS ($62B, 2021), Azure ($60B, 2021), GCP ($19B, 2021) 
• Revenues (run rate): AWS ($130B, 2025), Azure ($108B, 2025), GCP ($50B, 2025) 
• AWS is on 3rd CEO since pandemic; market questioning their AI strategy
• Azure + OpenAI alignment strategy went from strategic to questioned
• Google start-stop AI strategy, but coming together; but company breakup looming
• Apple AI strategy seems completely unknown (Siri,Apple Intelligence, devices, models?)
• Oracle seems to be rebounding around Oracle Cloud Infrastructure
• New hypercloud AI providers emerging? The Amazon/AWS 20%

FEEDBACK?

• Email: show at the cloudcast dot net
• Twitter/X: @cloudcastpod
• BlueSky: @cloudcastpod.bsky.social
• Instagram: @cloudcastpod
• TikTok: @cloudcastpod

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

Scattered Spider Behind Cyberattacks on M&S and Co-op, Causing Up to $592M in Damages

Jun 21, 2025Ravie LakshmananCyber Attack / Critical Infrastructure

The April 2025 cyber attacks targeting U.K. retailers Marks & Spencer and Co-op have been classified as a "single combined cyber event."

That's according to an assessment from the Cyber Monitoring Centre (CMC), a U.K.-based independent, non-profit body set up by the insurance industry to categorize major cyber events.

"Given that one threat actor claimed responsibility for both M&S and Co-op, the close timing, and the similar tactics, techniques, and procedures (TTPs), CMC has assessed the incidents as a single combined cyber event," the CMC said.

The organization has categorized the disruption of the retailers as a "Category 2 systemic event." It's estimated that the security breaches will have a total financial impact of £270 million ($363 million) to £440 million ($592 million).

However, the cyber attack on Harrods around the same time has not been included at this stage, citing a lack of adequate information about the cause and impact.

The initial access vector employed in the attacks targeting Marks & Spencer and Co-op revolved around the use of social engineering tactics, particularly targeting IT help desks.

The CMC further noted that its attribution efforts are still ongoing. That said, the notorious cybercrime group known as Scattered Spider (aka UNC3944) is believed to be behind the intrusions.

The group, an offshoot of the larger cybercrime community known as The Com, has a track record of leveraging its English-speaking members to carry out advanced social engineering attacks where they impersonate members of a company's IT department to obtain unauthorized access.

"The impact from this event is 'narrow and deep,' having significant implications for two companies, and knock-on effects for suppliers, partners, and service providers," the CMC said.

Earlier this week, Google Threat Intelligence Group (GTIG) revealed that Scattered Spider actors have begun to target major insurance companies in the United States.

"Given this actor's history of focusing on a sector at a time, the insurance industry should be on high alert, especially for social engineering schemes which target their help desks and call centers," John Hultquist, Chief Analyst at GTIG, said.

"The anticipated threat of Iranian cyber capability to U.S. organizations has been the focus of many discussions lately, but these actors are already targeting critical infrastructure. We expect more high-profile incidents in the near term as they move from sector to sector."

The development comes as Indian consulting giant Tata Consultancy Services (TCS) disclosed that its systems or users were not compromised as part of the attack against Marks & Spencer. Last month, the Financial Times reported that TCS is internally probing whether its systems were used as a launchpad for the attack.

It also follows a new strategy from the Qilin ransomware operation that involves offering legal assistance to ramp up pressure during ransom negotiations. The threat actors also claim to have an in-house team of journalists who can work together with the legal department to craft blog posts and assist with victim negotiations.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

Qilin Ransomware Adds "Call Lawyer" Feature to Pressure Victims for Larger Ransoms

The threat actors behind the Qilin ransomware-as-a-service (RaaS) scheme are now offering legal counsel for affiliates to put more pressure on victims to pay up, as the cybercrime group intensifies its activity and tries to fill the void left by its rivals.

The new feature takes the form of a "Call Lawyer" feature on the affiliate panel, per Israeli cybersecurity company Cybereason.

The development represents a newfound resurgence of the e-crime group as once-popular ransomware groups like LockBit, Black Cat, RansomHub, Everest, and BlackLock have suffered abrupt cessations, operational failures, and defacements. The group, also tracked as Gold Feather and Water Galura, has been active since October 2022.

Data compiled from the dark web leak sites run by ransomware groups shows that Qilin led with 72 victims in April 2025. In May, it is estimated to be behind 55 attacks, putting it behind Safepay (72) and Luna Moth (67). It's also the third most active group after Cl0p and Akira since the start of the year, claiming a total of 304 victims.

"Qilin stands above the rest with its rapidly rising marketplace due to a mature ecosystem, extensive support options for clients, and robust solutions to ensure highly targeted, high-impact ransomware attacks designed to demand substantial payouts," Qualys said in an analysis of the group this week.

There is evidence to suggest that affiliates working for RansomHub have migrated to Qilin, contributing to the spike in Qilin ransomware activity in recent months.

"With a growing presence across forums and ransomware activity trackers, Qilin operates a technically mature infrastructure: payloads built in Rust and C, loaders with advanced evasion features, and an affiliate panel offering Safe Mode execution, network spreading, log cleanup, and automated negotiation tools," researchers Mark Tsipershtein and Evgeny Ananin said.

"Beyond the malware itself, Qilin offers spam services, PB-scale data storage, legal guidance, and a full set of operational features—positioning itself not just as a ransomware group, but as a full-service cybercrime platform."

The decline and demise of other groups have been complemented by new updates to the Qilin affiliate panel, incorporating a new legal assistance function, a team of in-house journalists, and the ability to conduct distributed denial-of-service (DDoS) attacks. Another notable addition is a tool for spamming corporate email addresses and phone numbers.

The feature expansion indicates an attempt on the part of the threat actors to market themselves as a full-fledged cybercrime service that goes beyond just ransomware.

"If you need legal consultation regarding your target, simply click the 'Call lawyer' button located within the target interface, and our legal team will contact you privately to provide qualified legal support," reads a translated version of a forum post announcing the new capabilities.

"The mere appearance of a lawyer in the chat can exert indirect pressure on the company and increase the ransom amount, as companies want to avoid legal proceedings."

The development comes as Intrinsec assessed that at least one affiliate of Rhysida has started using an open-source utility named Eye Pyramid C2 likely as a post-compromise tool to maintain access to compromised endpoints and deliver additional payloads.

It's worth noting that the Eye Pyramid C2 refers to the same Python-based backdoor that was deployed by threat actors linked to the RansomHub crew in Q4 2024.

It also follows a fresh analysis of the leaked Black Basta chat logs, which has shed light on a threat actor who went by the online alias "tinker." Their real-world identity is presently unknown.

Tinker, per Intel 471, is said to be one of the trusted aides of tramp, the group's leader, and joined the criminal enterprise as a "creative director" after having prior experience running call centers, including for the now-defunct Conti group, and as a negotiator for BlackSuit (aka Royal).

"The actor tinker played an important role in securing initial access to organizations," the cybersecurity company said. "The leaked conversations reveal tinker would analyze the financial data and evaluate a victim's situation before direct negotiations."

The threat actor, besides conducting open-source research to obtain contact information for the company's senior staff in order to extort them either via phone calls or messages, was tasked with writing phishing emails designed to breach organizations.

Tinker, notably, also came up with the Microsoft Teams-based phishing scenario, wherein the attackers would masquerade as an IT department employee, warning victims that they are at the receiving end of a spam attack and urging the employees to install remote desktop tools like AnyDesk and grant them access to purportedly secure their systems.

"After the RMM software was installed, the caller would contact one of Black Basta's penetration testers, who would then move to secure persistent access to the system and domain," Intel 471 said.

The leaked messages also reveal that tinker received no less than $105,000 in cryptocurrency for their efforts between December 18, 2023, and June 16, 2024. That said, it's currently not clear what group they may be working for.

The findings coincide with the extradition of an unnamed 33-year-old foreign member of the Ryuk ransomware group to the United States for their alleged role as an initial access broker (IAB) and facilitating access to corporate networks. The suspect was arrested from Kyiv earlier this April at the request of U.S. law enforcement.

The member "was engaged in the search for vulnerabilities in the corporate networks of the victim enterprises," the National Police of Ukraine said in a statement. "The data obtained by the hacker was used by his accomplices to plan and carry out cyber attacks."

Authorities said they were able to trace the suspect following a forensic analysis of equipment seized in a previous raid that took place in November 2023 targeting members of the LockerGoga, MegaCortex, and Dharma ransomware families.

Elsewhere, police officials in Thailand have apprehended several Chinese nationals and other Southeast Asian suspects after raiding a hotel in Pattaya that was used as a gambling den and as an offices to conduct ransomware operations.

The ransomware scheme is said to have been run by six Chinese nationals, who sent malicious links to companies in order to infect them with ransomware. Local media reports say they were employees of a cybercrime gang, who were paid to distribute the booby-trapped links to Chinese firms.

Thailand's Central Investigation Bureau (CIB), this week, also announced the arrest of more than a dozen foreigners as part of Operation Firestorm for allegedly running an online investment scam that defrauded several victims in Australia by calling them and deceiving them into investing their money in long-term bonds with a promise of high returns.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

The Good, the Bad and the Ugly in Cybersecurity – Week 25

The Good | Pentagon Accelerates AI Adoption to Strengthen Cyber & Operational Readiness

In a significant step forward to modernizing government operations, the DoD has awarded a contract up to $200 million to OpenAI to develop frontier AI-based capabilities for the Pentagon. The contact will be managed by the Chief Digital and Artificial Intelligence Office (CDAO), which currently leads AI adoption efforts across the U.S. military. Created in 2022, CDAO serves as the Pentagon’s central hub for AI expertise and innovation.

Source: diu.mil

The contract is part of a broader government initiative to responsibly and effectively harness AI with the purpose of streamlining operations, reducing administrative burdens, and shoring up national defense. A core part of the project includes the development of prototype agentic workflows – semi-autonomous AI agents that are designed to perform repetitive, time-consuming tasks that currently demand a large amount of human effort. These AI tools would free up both military and civilian personnel, with focus and time redirected to high-value work to enhance mission readiness.

The effort builds on the Pentagon’s previous AI work, including Task Force Lima, which spent over a year evaluating generative AI’s reliability for defense use. As the DoD continues to embrace its potential, with safeguards in place, AI is actively being used by the Army to sift through massive volumes of unstructured data, such as regulations, field manuals, and procurement documents. It’s also worth noting that generative AI is already assisting with drafting acquisition paperwork and translating orders into actionable tasks for military aid efforts.

This contract signals the DoD’s growing confidence in AI’s utility and points to a larger trend: federal agencies are moving forward with secure, carefully-governed AI integration to enhance cybersecurity, data management, and operational effectiveness across government agencies.

The Bad | New Threat Actor ‘Water Curse’ Exposes Risks of Weaponized GitHub Platforms

Water Curse, a newly identified threat cluster, is weaponizing GitHub repositories to distribute multi-stage malware, masquerading as penetration testing tools. While the cluster has yet to be attributed to any known actor, the activity is described as stealthy with financially-motivated goals.

Cyber researchers have been tracking the cluster since March 2023, noting the use of at least 76 GitHub accounts using Visual Studio files to conceal payloads like SMTP email bombers and a remote access trojan called Sakura-RAT. These payloads allow attackers to exfiltrate data such as credentials, browser information, and session tokens, while also establishing long-term access to compromised systems.

The infection chain begins with heavily obfuscated Visual Basic Script and PowerShell loaders, which download encrypted archives containing malicious Electron-based applications. These then conduct system reconnaissance and establish persistence using anti-debugging, privilege escalation, and defense evasion techniques. Additional scripts are used to weaken system defenses and prevent recovery.

Snippet of VBS script created (Source: Trend Micro)

So far, infrastructure and tooling associated with Water Curse show a focus on scalability, stealth, and cross-functional development. The unknown threat actor blurs the line between red team utilities and actual malware, deploying a wide variety of components ranging from OSINT scrapers and game cheats to crypto-wallet tools and credential stealers, all suggesting a multi-vertical monetization strategy. While similarities exist between Water Curse and known distribution-as-a-service (DaaS) campaigns, researchers have yet to confirm a direct connection.

Threat actors continue to quietly exploit trusted platforms to hide malware in plain sight, embedding malicious tools in seemingly legitimate projects. Tactics like the ones used by Water Curse not only complicate detection but also highlight the need to effectively secure developer ecosystems and open-source platforms.

The Ugly | Zero-Day Used in “Trinper” Malware Campaign Highlights Software Supply Chain Risks

A recently-patched Google Chrome flaw was exploited in March by a threat actor known as TaxOff, who used it to slip a stealthy backdoor called “Trinper” onto targeted systems. The attack began with a phishing email, then exploited a sandbox escape flaw (CVE-2025-2783) to bypass Chrome’s defenses, giving TaxOff access with no clicks or downloads required beyond the initial link.

Google Chrome Zero-Day CVE-2025-2783 Exploited by TaxOff to Deploy Trinper Backdoor #cybersecurity #hacking #news #infosec #security #technology #privacy thehackernews.com/20…

[image or embed]

— Ninja Owl (@ninjaowl.ai) 19 June 2025 at 05:18

The malware is written in C++ and uses multithreading to stay hidden while capturing keystrokes, collecting files, and exfiltrating data. It communicates with a remote command and control (C2) server to execute commands, launch a reverse shell, and extend its capabilities. Initial infection vectors traced back to phishing emails all contained links to malicious websites hosting the exploit or ZIP files with shortcuts that launched PowerShell commands, often using loaders like Donut or Cobalt Strike.

TaxOff was first reported in late 2024, and has consistently used finance-themed and geopolitical lures to target domestic organizations. In this most recent operation codenamed “ForumTroll”, the phishing emails impersonated invitations to high-profile Russian forums, leading users to a fake website hosting the exploit. Security researchers have since reportedly uncovered further links between this operation and earlier attacks dating back to October 2024, some of which share tactics with another group called Team46, raising the possibility of overlap between the two.

The attackers’ repeated use of zero-days and complex backdoors points to a long-term strategy focused on persistence and stealth. These incidents underscore the continued exploitation of software supply chains and widely used platforms to deliver advanced malware through trusted but vulnerable entry points.

from SentinelOne https://ift.tt/HgP8xFl
via IFTTT

Iran's State TV Hijacked Mid-Broadcast Amid Geopolitical Tensions; $90M Stolen in Crypto Heist

Jun 20, 2025Ravie LakshmananCyber Warfare / Hacktivism

Iran's state-owned TV broadcaster was hacked Wednesday night to interrupt regular programming and air videos calling for street protests against the Iranian government, according to multiple reports.

It's currently not known who is behind the attack, although Iran pointed fingers at Israel, per Iran International.

"If you experience disruptions or irrelevant messages while watching various TV channels, it is due to enemy interference with satellite signals," the broadcaster was quoted as saying.

The breach of state television is the latest in a string of cyber attacks inside Iran that have been attributed to Israel-linked actors. It also coincides with the hack of Bank Sepah and Nobitex, Iran's largest cryptocurrency exchange.

The Nobitex hack led to the theft of more than $90 million, a brazen escalation in the cyber war that has simmered between Israel and Iran for more than a decade.

"Iranian entities have experimented with virtual assets as both a financial workaround and as a strategic asset to support broader geopolitical ambitions — including the proliferation of advanced weapons technology," TRM Labs said. "This latest incident highlights how crypto exchanges, once peripheral to conflict, are increasingly becoming strategic targets for geopolitical actors."

The latest development also follows the revelation from Israeli officials that Iran is hijacking private security cameras installed in Israel to gather real-time intelligence, mirroring a similar tactic used by Russia after its invasion of Ukraine in 2022.

"We know that in the past two or three days, the Iranians have been trying to connect to cameras to understand what happened and where their missiles hit to improve their precision," Refael Franco, the former deputy director general of the Israel National Cyber Directorate, said.

Cybersecurity firm Radware said nearly 40% of all hacktivist DDoS activity has been directed against Israel since the onset of the latest flare-up. On June 17, the hacktivist group DieNet warned it would launch cyber-attacks at the United States should it join the conflict against Iran.

The message has since been amplified by other groups like Arabian Ghosts, Sylhet Gang, and Team Fearless, suggesting that these entities are forming a potential collaboration in cyberspace as battle rages on the ground.

"Companies are urged to take maximum vigilance. The warning signs are clear. Critical infrastructure, supply chains, and even global businesses could become collateral targets if the cyber crossfire intensifies," said Pascal Geenens, director of threat intelligence at Radware.

"The Israel-Iran conflict of 2025 is a stark illustration of modern hybrid warfare, where bytes and narratives are as much a part of the fight as bombs and missiles."

In a two-part analysis, CloudSEK said more than 35 distinct pro-Iranian groups have launched coordinated attacks against Israeli infrastructure, as opposed to only less than half-a-dozen pro-Israeli groups engaging in hacktivist activity.

"The attacks predominantly consisted of DDoS assaults, website defacements, and claimed data breaches targeting government sites, military systems, and critical infrastructure," security researcher Pagilla Manohar Reddy said.

"Most significantly, these recent attacks maintain the same pattern of exaggeration and disinformation that has characterized the broader hacktivist ecosystem, with groups continuing to take credit for unrelated service outages, recycle old data leaks, and inflate damage claims for media attention rather than achieving substantial operational impact."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

Massive 7.3 Tbps DDoS Attack Delivers 37.4 TB in 45 Seconds, Targeting Hosting Provider

Cloudflare on Thursday said it autonomously blocked the largest ever distributed denial-of-service (DDoS) attack ever recorded, which hit a peak of 7.3 terabits per second (Tbps).

The attack, which was detected in mid-May 2025, targeted an unnamed hosting provider.

"Hosting providers and critical Internet infrastructure have increasingly become targets of DDoS attacks," Cloudflare's Omer Yoachimik said. "The 7.3 Tbps attack delivered 37.4 terabytes in 45 seconds."

Earlier this January, the web infrastructure and security company said it had mitigated a 5.6 Tbps DDoS attack aimed at an unnamed internet service provider (ISP) from Eastern Asia. The attack originated from a Mirai-variant botnet in October 2024.

Then in April 2025, Cloudflare revealed it defended against a massive 6.5 Tbps flood that likely emanated from Eleven11bot, a botnet comprising roughly 30,000 webcams and video recorders. The hyper-volumetric attack lasted about 49 seconds.

The 7.3 Tbps DDoS attack, in comparison, carpet-bombed an average of 21,925 destination ports of a single IP address owned and used the hosting provider, hitting a crest of 34,517 destination ports per second.

The multi-vector attack originated from a similar distribution of source ports and has been identified as a combination of UDP flood, QOTD reflection attack, echo reflection attack, NTP reflection attack, Mirai UDP flood attack, portmap flood, and RIPv1 amplification attack. The UDP flood accounted for 99.996% of the attack traffic.

Cloudflare also pointed out that the attack came from over 122,145 source IP addresses spanning 5,433 Autonomous Systems (AS) across 161 countries. The top sources of attack traffic included Brazil, Vietnam, Taiwan, China, Indonesia, Ukraine, Ecuador, Thailand, the United States, and Saudi Arabia.

"The average number of unique source IP addresses per second was 26,855 with a peak of 45,097," Yoachimik said.

"Telefonica Brazil (AS27699) accounted for the largest portion of the DDoS attack traffic, responsible for 10.5% of the total. Viettel Group (AS7552) follows closely with 9.8%, while China Unicom (AS4837) and Chunghwa Telecom (AS3462) contributed 3.9% and 2.9% respectively. China Telecom (AS4134) accounted for 2.8% of the traffic."

The disclosure comes as the QiAnXin XLab team said the DDoS botnet tracked as RapperBot was behind an attack aimed at artificial intelligence (AI) company DeepSeek in February 2025, and that the latest samples of the malware attempting to extort victims to pay them "protection fees" to avoid being targeted by DDoS attacks in the future.

China, the United States, Israel, Mexico, the United Kingdom, Greece, Iran, Australia, Malaysia, and Thailand are the primary countries where devices infected by RapperBot are located. The botnet is known to be active since 2022.

RapperBot campaigns are known to target routers, network-attached storage devices, and video recorders with default weak passwords or firmware vulnerabilities to obtain initial access, and drop malware that can establish contact with a remote server over DNS TXT records to fetch DDoS attack commands.

The malware also makes use of custom encryption algorithms to encrypt the TXT records and command-and-control (C2) domain names used.

"Since March, its attack behavior has been significantly active, with an average of more than 100 attack targets per day and more than 50,000 bots observed," the Chinese security vendor said.

"RapperBot's attack targets are all over the fields of various industries, including public management, social security and social organizations, Internet platforms, manufacturing, financial services, etc."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

Resurgence of the Prometei Botnet

Executive Summary

In March 2025, Unit 42 researchers identified a wave of Prometei attacks. Prometei refers to both the botnet and the malware family used to operate it.

This malware family, which includes both Linux and Windows variants, allows attackers to remotely control compromised systems for cryptocurrency mining (particularly Monero) and credential theft. This article focuses on the resurgence of the Linux variant.

Prometei is under active development, incorporating new modules and methods into its capabilities. The latest Prometei versions feature a backdoor that enables a variety of malicious activities. Threat actors employ a domain generation algorithm (DGA) for their command-and-control (C2) infrastructure and integrate self-updating features for stealth and evasion.

This article presents a static analysis of Prometei malware versions three and four, highlighting key functional differences from version two.

Palo Alto Networks customers are better protected from the Prometei botnet through our Network Security solutions. These include Advanced WildFire, Advanced Threat Prevention, Advanced URL Filtering and Advanced DNS Security. Coverage can also be provided through our Cortex line of products including Cortex XDR and Cortex XSIAM.

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

Related Unit 42 Topics	Cryptominers, Linux

History of the Prometei Botnet

Cybersecurity researchers first identified the Prometei botnet in July 2020, with its Windows version being the primary focus at the time. The Linux version of the botnet was subsequently identified in December 2020. The latest variants of the Prometei Linux botnet, first observed in March 2025, will be discussed in greater detail in this article.

Prometei has a history of exploiting various vulnerabilities. It uses techniques such as brute-forcing credentials, leveraging EternalBlue (the infamous Windows exploit linked to the WannaCry ransomware) and exploiting Server Message Block (SMB) protocol flaws to spread laterally within networks.

Prometei employs a DGA and self-updating features to create resilient and adaptive malware. It uses a DGA to dynamically generate domain names to ensure uninterrupted communication with its C2 infrastructure, even if some domains are blocked. Self-updating capabilities allow the malware to evolve, adapt to security defenses and deliver new payloads, while maintaining stealth and evading detection. Together, these strategies make the malware more persistent and harder to combat.

While its primary goal is cryptocurrency (Monero) mining, Prometei also possesses secondary capabilities, such as stealing credentials and deploying additional malware payloads. We assess that Prometei's operations appear driven by financial gain, and there is no evidence of ties to nation-state actors.

Prometei's architecture is modular, meaning it is built from multiple independent components, each responsible for a specific function. These modules work together to accomplish the botnet's objectives. For example, it has modules for the following activities:

• Brute-forcing administrator credentials
• Exploiting vulnerabilities
• Mining cryptocurrency
• Stealing data
• Communicating with C2 servers

This modular design makes Prometei highly adaptable, as individual components can be updated or replaced without affecting the overall botnet functionality. It operates in multiple stages in the order listed below, which typically include the following:

• Initial Exploitation
• Payload Delivery
• Lateral Movement
• Cryptocurrency Mining
• Data Stealing
• C2 Communication

New Activity Timeline

We have been tracking this new wave of Prometei activity since March 2025. Figure 1 presents a timeline depicting the sample count of the Prometei botnet from late March-late April 2025.

Figure 1. Timeline of Prometei botnet samples observed.

Technical Analysis

The Prometei botnet malware is distributed via an HTTP GET request to hxxp[://]103.41.204[.]104/k.php?a=x86_64.

A slight variation, hxxp[://]103.41.204[.]104/k.php?a=x86_64,<PARENT_ID> returns the malware sample with an extra ParentID field value populated with the <PARENT_ID> value. This allows the attacker to dynamically assign a ParentID value to the malware sample. Here, <PARENT_ID> is used as a placeholder.

This URL is not restricted by geographic location; it serves the same malware sample file, with a randomized configuration each time. The HTTP response headers indicate that this server is an Apache PHP server running on a Windows platform. The server IPv4 address belongs to the network operated by Infinys Network (Autonomous System Number (ASN): 58397), based in Jakarta, Indonesia.

Later versions of this malware released in March 2025 are packed using Ultimate Packer for eXecutables (UPX). Version two, which was released in 2021, did not use this technique.

UPX is used to compress the executable, making it smaller and potentially more difficult to analyze. The malware itself is a 64-bit executable and linkable format (ELF) file, indicating it's designed to run on Linux-based systems.

Despite the file being named k.php, it is not a PHP script, likely a tactic to further disguise its true nature. In version two, malware authors named the corresponding file uplugplay.

The UPX-packed executable infects compromised systems by decompressing itself in memory during runtime. After decompression, the actual malicious payload is executed, allowing the botnet to begin its operations.

Unpacking Prometei for Static Analysis

Static malware analysis is a process of examining a malware sample without running or executing the file. In this case, because of the way this file is structured, we need to perform some extra operations to unpack this file for analysis. Attempting to use the standard UPX tool's decompression command-line option (i.e., upx -d) to restore the original file for further analysis will not successfully unpack it.

The UPX tool will fail because it relies on specific metadata, including a valid PackHeader and overlay_offset trailer, to identify and decompress UPX-packed files as shown in Figure 2. The presence of a custom configuration JSON trailer appended to the malware disrupts this process, causing the UPX tool to incorrectly determine that the file is not a valid UPX archive.

Figure 2. Interpretation of the UPX PackHeader and overlay_offset trailer for the sample.

Interpretation (note that bytes are formatted in little-endian order):

• 55 50 58 21: magic constant
• 0E: version
• 16: format
• 08: method
• 07: level
• B8 8F 14 BF: uncompressed Adler-32 checksum
• 4B 74 01 2A: compressed Adler-32 checksum
• F0 08 13 00: uncompressed length
• C4 A6 06 00: compressed length
• F0 08 13 00: original file size
• 49: filter id
• 22: filter_cto
• 00: filter_misc / n_mru
• 4B: header checksum
• F4 00 00 00: overlay_offset

The configuration JSON trailer must be stripped before using the UPX tool to unpack the sample file for analysis. After unpacking, the configuration JSON must be re-attached to the sample file for the malware to use those values during execution.

The sample contains a subroutine to search for and parse the configuration JSON trailer. Table 1 below compares the supported fields in versions two, three and four.

	Version 2	Versions 3 and 4
Fields	config id enckey	config id enckey ParentId ParentHostname ParentIp ip

Table 3. Comparison of supported fields in the configuration JSON trailer between version two, and versions three and four.

The sample also contains another subroutine responsible for collecting compromised system information. This information includes:

• Processor information (obtained from /proc/cpuinfo)
• Motherboard information (obtained using the dmidecode --type baseboard command)
• Operating system information (obtained from /etc/os-release or /etc/redhat-release)
• Information about how long the system has been running (obtained using the uptime command)
• Kernel information (obtained using the uname -a command)

The collected system information is submitted via HTTP GET to the C2 server at hxxp://152.36.128[.]18/cgi-bin/p.cgi.

For a more comprehensive understanding of the Prometei botnet and its evolution you can read the 2021 article IoT Malware Journals: Prometei (Linux). This more recent article, Communication with a Prometei C2, provides a detailed analysis of its newer capabilities.

Conclusion

This research has detailed the resurgence of the Prometei botnet, highlighting its continued evolution and the techniques it employs to evade detection. The new version of the Prometei botnet malware family can be detected with a YARA rule that identifies UPX and the configuration JSON trailer, a detection method that is likely to remain effective. However, as Prometei continues to evolve, security teams must remain vigilant and proactively adapt their defenses.

Palo Alto Networks Protection and Mitigation

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

• The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
• Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
• Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
• Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.

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

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

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

Indicators of Compromise

Malware samples

Version	SHA-256 Hash
v2.87X	46cf75d7440c30cbfd101dd396bb18dc3ea0b9fe475eb80c4545868aab5c578c
v3.05L	cc7ab872ed9c25d4346b4c58c5ef8ea48c2d7b256f20fe2f0912572208df5c1a
v4.02V	205c2a562bb393a13265c8300f5f7e46d3a1aabe057cb0b53d8df92958500867
v4.02V	656fa59c4acf841dcc3db2e91c1088daa72f99b468d035ff79d31a8f47d320ef
v4.02V	67279be56080b958b04a0f220c6244ea4725f34aa58cf46e5161cfa0af0a3fb0
v4.02V	7a027fae1d7460fc5fccaf8bed95e9b28167023efcbb410f638c5416c6af53ff
v4.02V	87f5e41cbc5a7b3f2862fed3f9458cd083979dfce45877643ef68f4c2c48777e
v4.02V	b1d893c8a65094349f9033773a845137e9a1b4fa9b1f57bdb57755a2a2dcb708
v4.02V	d21c878dcc169961bebda6e7712b46adf5ec3818cc9469debf1534ffa8d74fb7
v4.08V	d4566c778c2c35e6162a8e65bb297c3522dd481946b81baffc15bb7d7a4fe531

URLs

Purpose	URL
Malware distribution	hxxp://103.41.204[.]104/k.php
C2	hxxp://152.36.128[.]18/cgi-bin/p.cgi

Additional Resources

• Reversing a Prometei botnet binary with r2 and AI - Axelle Apvrille, Fortinet
• IoT Malware Journals: Prometei (Linux) - CUJO AI
• Prometei botnet and its quest for Monero - Cisco Talos

 

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

67 Trojanized GitHub Repositories Found in Campaign Targeting Gamers and Developers

Cybersecurity researchers have uncovered a new campaign in which the threat actors have published more than 67 GitHub repositories that claim to offer Python-based hacking tools, but deliver trojanized payloads instead.

The activity, codenamed Banana Squad by ReversingLabs, is assessed to be a continuation of a rogue Python campaign that was identified in 2023 as targeting the Python Package Index (PyPI) repository with bogus packages that were downloaded over 75,000 times and came with information-stealing capabilities on Windows systems.

The findings build on a previous report from the SANS's Internet Storm Center in November 2024 that detailed a supposed "steam-account-checker" tool hosted on GitHub, which incorporated stealthy features to download additional Python payloads that can inject malicious code into the Exodus cryptocurrency wallet app and harvest sensitive data to an external server ("dieserbenni[.]ru").

Further analysis of the repository and the attacker-controlled infrastructure has led to the discovery of 67 trojanized GitHub repositories that impersonate benign repositories with the same name.

There is evidence to suggest that users searching for software such as account cleaning tools and game cheats such as Discord account cleaner, Fortnite External Cheat, TikTok username checker, and PayPal bulk account checker are the targets of the campaign. All the identified repositories have since been taken down by GitHub.

"Backdoors and trojanized code in publicly available source code repositories like GitHub are becoming more prevalent and represent a growing software supply chain attack vector," ReversingLabs researcher Robert Simmons said.

"For developers relying on these open-source platforms, it's essential to always double check that the repository you're using actually contains what you expect."

GitHub as a Malware Distribution Service

The development comes as GitHub is increasingly becoming the focus of several campaigns as a malware distribution vector. Earlier this week, Trend Micro said it uncovered 76 malicious GitHub repositories operated by a threat actor it calls Water Curse to deliver multi-stage malware.

These payloads are designed to siphon credentials, browser data, and session tokens, as well as to provide the threat actors with persistent remote access to the compromised systems.

Then Check Point shed light on another campaign that's using a criminal service known as the Stargazers Ghost Network to target Minecraft users with Java-based malware. The Stargazers Ghost Network refers to a collection of GitHub accounts that propagate malware or malicious links via phishing repositories.

"The network consists of multiple accounts that distribute malicious links and malware and perform other actions such as starring, forking, and subscribing to malicious repositories to make them appear legitimate," Check Point said.

The cybersecurity company has also assessed that such "GitHub 'Ghost' accounts are only one part of the grand picture, with other 'Ghost' accounts operating on different platforms as an integral part of an even larger Distribution-as-a-Service universe."

Some aspects of the Stargazers Ghost Network were exposed by Checkmarx in April 2024, calling out the threat actor's pattern of using fake stars and pushing out frequent updates to artificially inflate the popularity of the repositories and make sure they surfaced on top on GitHub search results.

These repositories are ingeniously disguised as legitimate projects, typically related to popular games, cheats, or tools like cryptocurrency price trackers and multiplier prediction for crash-betting games.

These campaigns also dovetail with another attack wave that has targeted novice cybercriminals on the lookout for readily available malware and attack tools on GitHub with backdoored repositories to infect them with information stealers.

In one instance highlighted by Sophos this month, the trojanized Sakura-RAT repository has been found to incorporate malicious code that compromised those who compiled the malware on their systems with information stealers and other remote access trojans (RATs).

The identified repositories act as a conduit for four different kinds of backdoors that are embedded within Visual Studio PreBuild events, Python scripts, screensaver files, and JavaScript to steal data, take screenshots, communicate via Telegram, as well as fetch more payloads, including AsyncRAT, Remcos RAT, and Lumma Stealer.

In all, the cybersecurity company said it detected no less than 133 backdoored repositories as part of the campaign, with 111 containing the PreBuild backdoor, and the others hosting Python, screensaver, and JavaScript backdoors.

Sophos further noted that these activities are likely linked to a distribution-as-a-service (DaaS) operation that has been operational since August 2022, and which has used thousands of GitHub accounts to distribute malware embedded within trojanized repositories themed around gaming cheats, exploits, and attack tools.

While the exact distribution method used in the campaign is unclear, it's believed that the threat actors are also relying on Discord servers and YouTube channels to spread links to the trojanized repositories.

"It remains unclear if this campaign is directly linked to some or all of the previous campaigns reported on, but the approach does seem to be popular and effective, and is likely to continue in one form or another," Sophos said. "In the future, it's possible that the focus may change, and threat actors may target other groups besides inexperienced cybercriminals and gamers who use cheats."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

New Android Malware Surge Hits Devices via Overlays, Virtualization Fraud and NFC Theft

Cybersecurity researchers have exposed the inner workings of an Android malware called AntiDot that has compromised over 3,775 devices as part of 273 unique campaigns.

"Operated by the financially motivated threat actor LARVA-398, AntiDot is actively sold as a Malware-as-a-Service (MaaS) on underground forums and has been linked to a wide range of mobile campaigns," PRODAFT said in a report shared with The Hacker News.

AntiDot is advertised as a "three-in-one" solution with capabilities to record the device screen by abusing Android's accessibility services, intercept SMS messages, and extract sensitive data from third-party applications.

The Android botnet is suspected to be delivered via malicious advertising networks or through highly tailored phishing campaigns based on activity that indicates selective targeting of victims based on language and geographic location.

AntiDot was first publicly documented in May 2024 after it was spotted being distributed as Google Play updates to accomplish its information theft objectives.

Like other Android trojans, it features a wide range of capabilities to conduct overlay attacks, log keystrokes, and remotely control infected devices using Android's MediaProjection API. It also establishes a WebSocket communication to facilitate real-time, bi-directional communication between the infected device and an external server.

In December 2024, Zimperium revealed details of a mobile phishing campaign that distributed an updated version of AntiDot dubbed AppLite Banker using job offer-themed decoys.

The latest findings from the Swiss cybersecurity company show that there are at least 11 active command-and-control (C2) servers in operation that are overseeing no less than 3,775 infected devices across 273 distinct campaigns.

A Java-based malware at its core, AntiDot is heavily obfuscated using a commercial packer to sidestep detection and analysis efforts. The malware, per PRODAFT, is delivered as part of a three-stage process that starts with an APK file.

"An inspection of the AndroidManifest file reveals that many class names do not appear in the original APK," the company said. "These missing classes are dynamically loaded by the packer during installation, and include malicious code extracted from an encrypted file. The entire mechanism is intentionally crafted to avoid detection by antivirus tools."

Once launched, it serves a bogus update bar and prompts the victim to grant it accessibility permissions, after which it unpacks and loads a DEX file incorporating the botnet functions.

A core feature of AntiDot is its ability to monitor for newly launched applications and serve and serve a bogus login screen from the C2 server when the victim opens a cryptocurrency- or payment-related app that the operators are interested in.

The malware also abuses accessibility services to gather extensive information about the contents of the active screens and sets itself as the default SMS app for capturing incoming and outgoing texts. Furthermore, it can monitor phone calls, block calls from specific numbers, or redirect them, effectively opening up more avenues for fraud.

Another important feature is that it can keep track of real-time notifications displayed in the device's status bar and takes steps to either dismiss or snooze them in a bid to suppress alerts and avoid alerting the user of suspicious activity.

PRODAFT said the C2 panel that powers the remote control functions is built using MeteorJS, an open-source JavaScript framework that enables real-time communication. The panel has six different tabs -

• Bots, which displays a list of all the compromised devices and their details
• Injects, which displays a list of all target apps for overlay injection and view the overlay template for each inject
• Analytic, which displays a list of applications installed on victim devices and likely used to identify new and popular apps for future targeting
• Settings, which contains the core configuration options for the panel, including updating the injects
• Gates, which is used to manage the infrastructure endpoints that the bots connect to
• Help, which offers support resources for using the malware

"AntiDot represents a scalable and evasive MaaS platform designed for financial gain through persistent control of mobile devices, especially in localized and language-specific regions," the company said. "The malware also employs WebView injection and overlay attacks to steal credentials, making it a serious threat to user privacy and device security."

GodFather Returns

The development as Zimperium zLabs said it uncovered a "sophisticated evolution" of the GodFather Android banking trojan that makes use of on-device virtualization to hijack legitimate mobile banking and cryptocurrency applications and carry out real-time fraud.

"The core of this novel technique is the malware's ability to create a complete, isolated virtual environment on the victim's device. Instead of simply mimicking a login screen, the malware installs a malicious 'host' application that contains a virtualization framework," researchers Fernando Ortega and Vishnu Pratapagiri said.

"This host then downloads and runs a copy of the actual targeted banking or cryptocurrency app within its controlled sandbox."

Should the victim launch the app, they are redirected to the virtual instance, from where their activities are monitored by the threat actors. In addition, the latest version of GodFather packs in features to bypass static analysis tools by making use of ZIP manipulation and filling the AndroidManifest file with irrelevant permissions.

Like in the case of AntiDot, GodFather relies on accessibility services to conduct its information gathering activities and control compromised devices. While Google has enforced security protections that prevent sideloaded apps from enabling accessibility service starting Android 13, a session-based installation approach can get around this safeguard.

The session-based method is used by Android app stores to handle app installation, as do texting apps, mail clients, and browsers when presented with APK files.

Central to the functioning of the malware is its virtualization feature. In the first stage, it collects information about the list of installed apps and checks if it includes any of the predetermined apps it's configured to target.

If matches are found, it extracts relevant information from those apps and then proceeds to install a copy of those apps in a virtual environment inside the dropper app. Thus when the victim attempts to launch the actual banking application on their device, GodFather intercepts the action and opens the virtualized instance instead.

It's worth pointing out that similar virtualization features were previously flagged in another Android malware codenamed FjordPhantom, which was documented by Promon in December 2023. The method represents a paradigm shift in mobile threat capabilities that go beyond the traditional overlay tactic to steal credentials and other sensitive data.

"While this GodFather campaign casts a wide net, targeting nearly 500 applications globally, our analysis reveals that this highly sophisticated virtualization attack is currently focused on a dozen Turkish financial institutions," the company said.

"A particularly alarming capability uncovered in the GodFather malware is its capacity to steal device lock credentials, irrespective of whether the victim uses an unlock pattern, a PIN, or a password. This poses a significant threat to user privacy and device security."

The mobile security company said the abuse of accessibility services is one of the many ways malicious apps can achieve privilege escalation on Android, allowing them to obtain permissions that exceed their functional requirements. These include misuse of Original Equipment Manufacturer (OEM) permissions and security vulnerabilities in pre-installed apps that cannot be removed by users.

"Preventing privilege escalation and securing Android ecosystems against malicious or over-privileged applications requires more than user awareness or reactive patching—it demands proactive, scalable, and intelligent defense mechanisms," security researcher Ziv Zeira said.

SuperCard X Malware Comes to Russia

The findings also follow the first recorded attempts to target Russian users with SuperCard X, a newly emerged Android malware that can conduct near-field communication (NFC) relay attacks for fraudulent transactions.

According to Russian cybersecurity company F6, SuperCard X is a malicious modification of a legitimate tool called NFCGate that can capture or modify NFC traffic. The end goal of the malware is to not only receive NFC traffic from the victim, but also bank card data read by sending commands to its EMV chip.

"This application allows attackers to steal bank card data by intercepting NFC traffic for subsequent theft of money from users' bank accounts," F6 researcher Alexander Koposov said in a report published this week.

Attacks leveraging SuperCard X were first spotted targeting Android users in Italy earlier this year, weaponizing NFC technology to relay data from victims' physical cards to attacker-controlled devices, from where they were used to carry out fraudulent ATM withdrawals or authorize point-of-sale (PoS) payments.

The Chinese-speaking MaaS platform, advertised on Telegram as capable of targeting customers of major banks in the U.S., Australia and Europe, shares substantial code-level overlaps with NGate, an Android malware that has also been found weaponizing NFCGate for malicious purposes in the Czech Republic.

All these campaigns are united by the fact that they rely on smishing techniques to convince a potential victim of the need to install an APK file on the device under the guise of a useful program.

Malicious Apps Spotted on App Stores

While all of the aforementioned malware strains require victims to sideload the apps on their devices, new research has also unearthed malicious apps on the official Google Play Store and Apple's App Store with capabilities to harvest personal information and steal mnemonic phrases associated with cryptocurrency wallets with the goal of draining their assets.

One of the apps in question, RapiPlata, is estimated to have been downloaded around 150,000 times on both Android and iOS devices, underscoring the severity of the threat. The app is a type of malware known as SpyLoan, which lures users by claiming to offer loans at low-interest rates, only to be subjected to extortion, blackmail, and data theft.

"RapiPlata primarily targets Colombian users by promising quick loans," Check Point said. "Beyond its predatory lending practices, the app engages in extensive data theft. The app had extensive access to sensitive user data -- including SMS messages, call logs, calendar events, and installed applications -- even going so far as to upload this data to its servers."

The cryptocurrency wallet phishing apps, on the other hand, have been distributed through compromised developer accounts and serve a phishing page via WebView to obtain the seed phrases.

Although these apps have since been removed from the respective app stores, the danger is that the Android apps could be available for download from third-party websites. Users are advised to exercise caution when downloading financial or loan-related applications.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

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

Integrating VMware vCenter with Active Directory and LDAP: Best Practices for 2025

Introduction

Integrating VMware vCenter Server with Active Directory (AD) enables centralized user management and simplifies access administration. Instead of relying on vCenter’s local user database, you can use your AD domain or another LDAP service as a single source of authentication.

This means that vSphere administrators can use the same accounts and groups they use for other network resources to access vSphere objects. This approach enhances security by centralizing credential control and simplifies access management (e.g., adding a user to the appropriate domain group automatically grants them the necessary permissions in vCenter). Additionally, domain-based authentication allows you to use AD security mechanisms such as password policies, multi-factor authentication via federation, etc., to access vCenter.

This article provides a step-by-step guide for integrating vCenter Server 8.0/8.1 with Active Directory and LDAP, as well as the best practices for 2025 – including recommendations for security, high availability, and centralized administration. We’ll begin with system preparation and then cover the two main integration methods:

1. Joining vCenter to the AD domain (Integrated Windows Authentication – a legacy method);
2. Adding LDAP as an identity source (recommended method).

Next, we’ll explain how to assign roles to AD users in vCenter and offer tips for optimal configuration. Finally, we’ll summarize the key takeaways.

Prerequisites and Requirements

Before starting integration, ensure the following prerequisites are met:

• A configured Active Directory domain must be available – there should be at least one domain controller (not in read-only mode). For high availability, it’s recommended to have multiple domain controllers.
• Proper DNS configuration – the vCenter name or Fully Qualified Domain Name (FQDN) must match the domain, and vCenter must correctly resolve the DNS names of AD domain controllers. Please ensure that the vCenter Server Appliance (VCSA) is pointing to a DNS server capable of resolving the AD domain name to a domain controller’s IP address.
• Time synchronization – vCenter and the domain controller(s) must have synchronized time (e.g., using NTP). A time drift greater than 5 minutes may cause Kerberos authentication failures.
• An AD account with appropriate privileges – required to either join computers to the domain (if using the domain-join method) or perform LDAP queries (if using the LDAP method). It’s recommended to create a dedicated account (e.g., vmware_svc) with the minimum necessary domain permissions.
• SSO vCenter domain name uniqueness – the local vCenter Single Sign-On (SSO) domain (default: vsphere.local) must not conflict with your AD domain name. For example, if your corporate domain is company.local, the vCenter SSO domain should use a different name (e.g., vsphere.local) to avoid integration issues.

See configuration details in Image 1.

Image 1

 

Integration Methods with Active Directory

There are two main methods to integrate vCenter with Active Directory:

1. Joining vCenter Server to a Windows domain (Integrated Windows Authentication, IWA) – a traditional method where vCenter becomes a member of the AD domain. This includes Kerberos trust and enables the use of Windows Session Authentication (single sign-on for the account logged into Windows) for the vSphere Web Client.
   Important: VMware has announced the deprecation of this method – support for IWA will be removed in upcoming major versions after vSphere 8.0. Therefore, although this method is still available in vCenter 8.0/8.1, a transition to alternative methods is recommended.
2. Adding AD as an LDAP identity source (LDAP/LDAPS) – this is the recommended approach for 2025. With this method, vCenter does not join the domain. Instead, an external identity source is added in the SSO settings, pointing to the Active Directory domain via the LDAP/LDAPS protocol. It is preferable to use the secure LDAPS channel (LDAP over SSL) to encrypt authentication traffic. This method requires uploading the domain controller’s certificate for LDAPS manually and does not support single sign-on via the Windows session. However, it is more secure and better supported in the long term.

Below you can find step-by-step instructions for each approach.

Method 1: Joining vCenter 8.x to an Active Directory domain (IWA)

Note: This method is now considered deprecated; however, it is still supported in vCenter versions 8.0/8.1 for backward compatibility. Its use may be justified if you require login via the current Windows session (SSPI) or if your process explicitly depends on domain join integration. However, plan to migrate to the LDAP-based method (see below) in the near future.

1. Log in to the vSphere Client Using an SSO Account
Open the vCenter Web UI (vSphere Client) and log in using the SSO administrator account – typically administrator@vsphere.local (or another account specified during vCenter setup). This account has full rights to configure SSO. Make sure you have access to the administrative interface of vCenter.

2. Open Single Sign-On Settings
In the vSphere Client, click the Menu button (square icon at the top) and go to the Administration section. Under Single Sign-On, select Configuration. Switch to the Identity Provider tab.

See configuration details in Image 2.

Image 2

3. Join the Domain
In the Identity Provider tab, find the Active Directory Domain section and click Join AD to start the process of joining the vCenter Server Appliance to the domain. The following dialog box (See Image 3) will appear where you can enter domain parameters:

Image 3

4. Enter Domain Parameters

In the dialog window that appears, enter the credentials required to join the domain:

• Domain – the fully qualified domain name (FQDN) of the Active Directory domain, e.g., corp.local. Keep in mind that this name must be different from the vCenter SSO domain.
• Organizational Unit (OU) – this field is optional. You can specify the DN of the OU where the vCenter computer object should be placed in AD. If left blank, the object will go to the default “Computers” container. For example, the value OU=Servers,DC=corp,DC=local will place the record in the OU “Servers” of the corp.local domain.
• Username and Password – a domain account with permissions to add computers. Use the login format user@domain or DOMAIN\user. It is recommended to use a dedicated account (e.g., vmwareadmin) that is a member of the Domain Admins group, rather than the built-in Administrator.

After filling in the fields, click Join to submit the request. If successful, the operation will join the VCSA to the AD domain and prompt for a reboot of the vCenter Server.

5. Reboot vCenter

Restart the vCenter Appliance to apply the changes (a restart is often required when configuring domain services). After the reboot, vCenter will be a member of the specified domain (a corresponding computer account will appear in AD).

6. Add the Domain as an Identity Source

Log in to the vSphere Client again using the SSO administrator account (administrator@vsphere.local). Go to Administration > Single Sign-On > Configuration > Identity Provider, and open the Identity Sources tab. You should see a source of the Active Directory (Integrated Windows Authentication) type for the domain you joined. If not, click Add and manually choose the Active Directory (Integrated Windows Authentication) type. Typically, joining the domain causes vCenter to automatically register this domain as an SSO identity source. If this did not occur, add it manually: select your domain from the dropdown or enter its name and NetBIOS alias, then save. Once added, the domain will appear as a new entry of Active Directory type in the Identity Sources list (see Image 4).

 Image 4

7. Set the Default Domain (Optional)

If your environment is only going to use one external identity source (your AD domain), it makes sense to set it as the Default Domain – the default source for authentication. To do this, highlight the added domain in the Identity Sources list and click Set as Default. In the Type column next to the domain, you’ll see the label “(default)”. Now, when entering a username without explicitly specifying the domain (e.g., just john.dow  instead of CORP\john.dow), vCenter will attempt to authenticate it against your AD domain.

8. Verify Login via Windows Session (SSPI)

The key benefit of joining the domain is the ability to log into vCenter using your current Windows session, without re-entering a password. To verify this, use Internet Explorer/Edge or the vSphere Client launched from a machine that is part of the same domain, and select the Use Windows session authentication option on the vSphere Client login page. Alternatively, enter user@domain in the username field and leave the password blank with Windows Session enabled (See Image 5). If everything is configured correctly, you’ll be automatically authenticated using your domain credentials (SSO will pass the Kerberos ticket).
Important: This mechanism only works with the IWA method and when the browser/client supports SPNEGO authentication, and when you are logged into the AD domain on the client machine with the same user.

Image 5

 

Method 2: Adding Active Directory via LDAP/LDAPS (Recommended)

Integrating vCenter with AD via LDAP does not require the vCenter Server to be joined to the domain. vCenter will send LDAP requests to the AD controller(s) to validate credentials. As of 2025, VMware recommends this method because it avoids using the outdated IWA method and supports secure LDAPS connections. Below are the steps to configure an LDAP identity source:

1. Prepare an LDAPS Certificate

If you plan to use secure LDAP (LDAPS, port 636), prepare an SSL certificate for your domain controller in advance. Typically, domain controllers have a certificate (issued by an internal enterprise CA or self-signed) for LDAP over SSL. This certificate (or the CA certificate that issued it) must be imported into vCenter during identity source configuration.

Note: The vCenter’s web UI doesn’t offer an automatic way to retrieve a certificate from the LDAP server, so you’ll need to do this manually. You can either:

• Export the domain controller certificate from the Windows certificate store (if accessible), or
• Run the OpenSSL command on the vCenter Appliance:

openssl s_client -showcerts -connect dc01.corp.local:636

This command outputs the certificate chain. Copy the content of the

—–BEGIN CERTIFICATE—– … END CERTIFICATE—– block for the root or issuing CA and save it to a file (e.g. ldaps.cer).

It’s recommended to use the domain CA certificate so that when the domain controller’s certificate is updated, you don’t have to reconfigure the identity source.

• If secure LDAP is unavailable, you can temporarily use plain LDAP (port 389), though this is not recommended for security reasons.

2. Add a New Identity Source

Log in to the vSphere Client as the SSO administrator (administrator@vsphere.local) and navigate to Administration > Single Sign-On > Configuration. On the Identity Provider tab, open the Identity Sources section and click Add. In the identity source wizard, choose Identity Source Type = Active Directory over LDAP (see Image 6).
If you’re integrating a non-Microsoft LDAP service (e.g., OpenLDAP), choose the corresponding OpenLDAP type instead. The fields are similar, although Domain name and Alias are only applicable to AD.

Image 6 

3. Fill in LDAP Parameters

Enter the following configuration details for the new identity source (see Image 7):

Image 7

 

• Identity source name – a friendly name for the identity source in vCenter. Usually, the domain DNS name is used, e.g., corp.local.
• Base Distinguished Name for users – the base DN for user lookups. To cover the entire domain, use the root DN. For example, for corp.local, this would be DC=corp,DC=local.You can also specify a narrower context (e.g., a specific OU) if you only want users from a particular department.
• Base Distinguished Name for groups – the base DN for group lookups. You can use the same root DN or a specific OU if groups are stored separately.
• Domain name – the full domain name, e.g., corp.local.
• Domain alias (NetBIOS name) – the short domain name (NetBIOS), e.g., CORP. This is used for logins in the DOMAIN\user format. This field is not available for OpenLDAP sources.
• Username and Password – credentials for connecting to LDAP. Provide a domain user with read access to the directory. Basic browse permissions are sufficient – any standard AD user will do, since Authenticated Users can view the directory structure by default.
  It is recommended to use a dedicated service account with limited rights.
  Use either the UPN format (user@corp.local) or the DN format (e.g., CN=vmware_svc,CN=Users,DC=corp,DC=local). If you receive a DN syntax error while saving, try using the DN format for the username.
• Connect to – this sets the domain controller addresses. You can choose: “Connect to any domain controller in the domain” – vCenter will discover DCs automatically via DNS. This increases availability (vCenter will fall back to another DC if one becomes unavailable). Alternatively, you can specify domain controllers manually – select the “Specific domain controllers” option and provide one or two URLs.

URL formats:

• for LDAPS: ldaps://dc01.corp.local:636 (if required, you may also use port 3269 for the global catalog with SSL).
• for LDAP without SSL: ldap://dc01.corp.local:389 (use port 3268 for the global catalog without SSL).

If specifying two domain controllers, the first will be treated as primary and the second as a fallback if the primary is unavailable.

4. Import the SSL Certificate

If you chose to use LDAPS and your domain controller uses a self-signed or corporate (enterprise) certificate, click Browse next to the Certificate field and upload the certificate file obtained in Step 1 (See Image 8). vCenter will import it into the trusted store to establish an SSL connection with LDAPS.
Make sure the uploaded certificate is correct; otherwise, the connection will fail.

Image 8

 

5. Complete Identity Source Addition

Click Add to save the configuration. The new identity source will appear in the Identity Sources list. vCenter SSO now recognizes your AD domain and can authenticate its users. If needed, set this identity source as the default domain (click Set as Default) as described in the previous section to simplify login input.

6. Verify the Connection

After adding the identity source, it’s recommended to perform basic checks:

• Go to the Users and Groups tab in the Single Sign-On settings (under Administration). Try switching the domain (in the dropdown list) to the newly added AD domain – you should see a list of AD users or groups, confirming a successful connection.
• If the LDAP connection fails, double-check the Base DN and credentials, and ensure that the LDAPS certificate is valid. In case of authentication errors, review the vCenter SSO logs at /var/log/vmware/sso  on the vCenter Appliance.

Note on Other LDAP Services: integration with OpenLDAP or other third-party LDAP services follows the same general steps. Select OpenLDAP as the identity source type and specify the Base DN for users/groups according to your directory structure. If using LDAPS, a certificate will also be required. The main difference is that Domain Name and Alias fields are not needed (these are specific to Active Directory). After adding an OpenLDAP source, you can create SSO groups that include external LDAP users and assign roles to them, or assign permissions to individual LDAP users in a similar way.

Assigning Permissions to AD Users in vCenter

After connecting vCenter to an external identity source (whether AD via IWA or LDAP), domain users still don’t automatically have access to the vSphere infrastructure. You must explicitly assign them roles and permissions in vCenter. Best practice: assign privileges to AD groups instead of individual users – this simplifies administration, allowing user management at the AD level.

Let’s walk through the process of granting a group of virtual infrastructure administrators full access in vCenter:

1. Create an AD Group

Create a group in Active Directory, for example, vCenter-Admin, and add the appropriate domain administrator users to it (if the group doesn’t already exist).
This is done on the domain controller via the Active Directory Users and Computers console (see Image 9).

Image 9

 

2. Assign the Group Global Permissions in vCenter

In the vSphere Client, go to Administration > Access Control > Global Permissions. Global permissions apply to all vCenter objects (including all datacenters and clusters). Click Add. In the Add Principal window:

• Select your domain (if not selected by default).
• Start typing the group name (e.g., “vCenter-Admin”) in the search field.
  Once the group is found, select it (it may take some time for AD groups to appear).
• In the Role dropdown, choose Administrator (or another role depending on the required privileges).
• Make sure the Propagate to children checkbox is selected if you’re assigning permissions at the top level.
• Click OK to apply (See Image 10).

Now, all users in the vCenter-Admin group will inherit Administrator rights to all vCenter objects.

Image 10

 

3. Verify Authorization with a Domain Account

Open a new vSphere Client session (or log out from the current one) and on the login page, enter the credentials of the AD user who was added to the group with assigned permissions – for example, john.dow@corp.local and their password. If the domain has been set as “default” in SSO, you can enter just the username without the @domain.
Make sure the login is successful and that you can see vCenter environment objects. The name of the logged-in domain user will be shown in the top right corner of the interface. This user now has the permissions granted by the assigned role.
Repeat the process for other users or groups by assigning appropriate roles (e.g., a read-only role for an operators group, or a VM Power User role for developers at the folder level, etc.).

4. Minimize the Use of the Local Administrator Account

Once domain authentication is set up, avoid using the administrator@vsphere.local account for daily operations. Instead, treat it as a break-glass account to be used only in emergencies when AD integration is unavailable. This account must always have a strong password and be securely stored, but it should not be used for routine tasks. All regular operations should be performed using personal domain logins – this improves auditing and aligns with security policies.

Best Practices 2025: Security, Resilience, and Management 

1. Use LDAPS and Abandon Unencrypted LDAP

Since 2020, Microsoft has tightened LDAP security requirements – it is recommended to use LDAP Signing or fully switch to LDAPS. Always use LDAPS when integrating vCenter with an external directory. Without encryption, your credentials may be transmitted in plaintext. Moreover, vCenter with IWA previously used unsigned LDAP, which triggers warnings (Event ID 2889) on AD controllers and may be blocked by security policies. By using AD over LDAPS or federation, you avoid this issue. Make sure your domain has a certificate service set up for AD controllers and that vCenter trusts these certificates. If necessary, renew LDAP certificates on your controllers before they expire and import the new ones into vCenter – otherwise, authentication will break when a certificate becomes invalid.

2. Plan for Deprecation of IWA

VMware has announced that Integrated Windows Authentication (IWA) will be removed in future versions (post-8.0 Update 3). It’s recommended to migrate now from domain-join setups to AD over LDAPS or consider implementing federation via a third-party identity provider. Federation (e.g., ADFS, Okta, Azure AD, etc.) allows for modern authentication methods, including MFA, but requires additional configuration. If federation isn’t planned yet, switching to LDAP(S) integration is essential for long-term operations. VMware provides guidelines and tools for migrating from IWA to LDAPS and verifying configuration before upgrading. Bottom line: For new deployments, use LDAP; for existing IWA setups, migrate to LDAP before upgrading vCenter to a version where IWA is no longer supported.

3. Least Privilege and Role-Based Access

Follow the principle of least privilege. While it’s convenient to give Domain Admins full access to vCenter, it’s better to create separate AD groups for specific vCenter roles (e.g., vSphereAdmins, vSphereReadOnly, BackupOperators, etc.). Assign only the roles that a group actually needs – this prevents privilege sprawl. Avoid adding built-in groups like Domain Admins directly to vCenter – use dedicated vSphere-related AD groups for better control over access.
Also, avoid creating local users in the vCenter SSO domain (vsphere.local) unless absolutely necessary. All administration should be done using domain accounts, except in emergencies. Local users should only be created for integrations with external systems (e.g., a service account for a backup solution that doesn’t support domain authentication).

4. Centralized Management and Auditing

By using Active Directory for vCenter, you gain centralized control over user accounts – disabling or deleting a user in AD will automatically revoke their access to vCenter (provided the user doesn’t have other accounts). Take advantage of this and manage access using standard AD tools. In vCenter, regularly review the Administration > Roles and Permissions section to check which groups have which roles. When an employee leaves, simply remove them from the AD group – their vCenter access will be revoked immediately. Also, note that all user operations in vCenter are logged (Events, Tasks) under their domain names, which simplifies action auditing.

5. Ensuring Authentication Resilience

Plan for a backup scenario in case AD or LDAP becomes unavailable. Keep the SSO administrator credentials (and/or another local account with admin rights) readily available to access vCenter if the external directory integration fails. Regularly verify that the password for administrator@vsphere.local is known to a limited group of personnel and securely stored.
Additionally, if vCenter manages critical infrastructure, deploy at least two domain controllers (AD recommends a minimum of two per domain). By default, vCenter uses DNS to locate controllers when configuring LDAP, so if one fails, it will fall back to another. If you specify static controllers, define both primary and secondary. AD redundancy is crucial: losing the sole controller will block domain users from logging into vCenter. In disaster recovery scenarios (e.g., multiple node failures), it’s also beneficial to have offline backups of both AD controllers and the VCSA itself.

6. vCenter and AD Security

When running vCenter in a domain environment, ensure that both vCenter and Active Directory are regularly updated and patched. Restrict network access to services: LDAP/LDAPS ports on domain controllers should only be open to trusted hosts (including vCenter). The vCenter Appliance itself should be protected by a firewall, with management access limited to admins only. Consider enabling two-factor authentication (2FA) for the vCenter Web Client using VMware Identity Manager (Workspace ONE Access) or built-in support for RSA SecurID/SmartCard, if your policy mandates MFA – vCenter SSO supports configuring these methods in addition to AD.

By following these recommendations, you’ll build a secure, reliable, and easy-to-manage access control system for your VMware infrastructure that meets modern security standards and is ready for future updates.

Conclusion

Integrating VMware vCenter Server with Active Directory or another LDAP directory is a crucial step for organizations aiming to centralize account management and enhance security. We reviewed two integration methods for vCenter 8.0 and 8.1: joining a Windows domain (the legacy IWA method) and configuring an LDAP(S) identity source (the modern and recommended method). The provided step-by-step instructions guide you through configuring vCenter-AD integration and assigning the necessary privileges to domain groups and users.

Current best practices encourage administrators to use secure LDAP (LDAPS), phase out deprecated methods, ensure fault tolerance (with domain controller redundancy and backups), and reduce reliance on local accounts in favor of domain accounts. Perform regular permission audits and promptly remove or revoke access when team members change – AD integration significantly simplifies this. Centralized authentication reduces administrative overhead and strengthens the security of your virtual infrastructure, allowing you to focus on its growth rather than manual account management.

from StarWind Blog https://ift.tt/GkbofvI
via IFTTT