8 min read

What building a realistic Azure attack environment teaches you about cloud security

Most companies now run at least part of their environment in the cloud, and attackers have moved there with them. Training material has not kept up. You can find a lot of content on on-premises Active Directory, but much less on realistic Azure and Entra ID attacks.

Erkan

November 9, 2026

At Hack The Box, we watch the market and listen to our customers, and both pointed to the need for an advanced Azure ProLab. The result is Altairus, an Advanced Azure Red Team ProLab with 15 flags.

Building an Azure attack environment teaches you a lot about cloud security. To misconfigure something in a realistic way, you first have to understand why the setting exists and how it works. This post collects what building Altairus showed about Azure security, both for people who attack Azure environments and for people who defend them. It is not a walkthrough, though. Nothing here describes the attack path, and you won't find a flag in it.

Identity and hybrid identity

On premises, you could draw a line around the network and defend it. Azure has no such line. Who can reach a resource depends on identity: users, groups, service principals, managed identities, and the roles assigned to them.

Most companies are not cloud-only either. They connect their on-premises Active Directory to Entra ID, so the same people, and often the same accounts, exist in both places. That is why Altairus combines Azure resources, Entra ID and hybrid identity in one lab.

A weakness on one side rarely stays there. A mistake in on-premises AD can lead into the cloud, and a cloud identity can lead back on premises. When you assess or defend a hybrid company, spend real time on the link between the two.

The human step

Many technical attacks still need a person to do something they shouldn't at one point. Altairus needed that too, but a lab cannot hire employees. Instead, it has a simulated user, which is a PowerShell script that runs in a loop on a management host. It uses Selenium to drive a real browser through Microsoft's real sign-in pages. Faking the sign-in with direct HTTP requests would have been easier, but then the lab would only be as realistic as its builder's guess about what those pages do.

If you defend a tenant, build your controls on the assumption that some user will eventually make a mistake. Conditional Access, phishing-resistant MFA and sign-in monitoring are designed for exactly that case.

Secrets in automation

The simulated user signs in again and again with nobody at the keyboard. A password was the obvious choice, but it had several problems. The script would need to read it from somewhere on the host. MFA would block the sign-in, and handling MFA codes with a command-line tool means storing yet another secret. Passwords expire as well, so one day the automation would quietly fail.

Altairus uses certificate-based authentication instead. The private key still needs protecting, but the password problems are gone.

Your own automation has the same weak point. Every password or client secret stored on a host is something an attacker can find and reuse. Prefer certificates or managed identities where you can, and keep private keys on hosts that very few people can reach.

The management plane

Behind every lab there is machinery that players should never see, such as the hosts that run the automation and the accounts that deploy resources. In Altairus, players cannot reach the management hosts at all. If they could, the automation would become part of the attack surface.

Companies have the same kind of machinery, and it is often protected less carefully than the systems it manages. Deployment service principals, automation accounts, CI/CD pipelines and admin workstations usually hold more privilege than anything else in the tenant. An attacker who gets there can often skip the rest of the attack path. Keep these assets separate from everything else, and give them your strongest protection.

Shared resources

Altairus runs many instances at once. Some parts belong to a single instance, and others are shared by all of them, which caused a few practical problems. For example, several instances can need the simulated user at nearly the same moment. A lock file makes those sign-ins take turns, because two browser sessions starting together would fight over the same profile and certificate.

The shared parts also revert to a clean base on a regular schedule, so nobody starts in the mess the previous player left behind. The automation has to recover from every revert by itself.

In a real tenant, ask the same question about anything shared. If one user or workload misbehaves, what else can it reach? A storage account, service principal or subscription that several teams use connects all of them.

Configuration drift and versions

Every Altairus instance is deployed with Terraform, and the Hack The Box infrastructure team helped a great deal with that work. Each instance has to come out the same. One instance built by hand would slowly drift from the others, and players would hit problems that nobody could reproduce. With Terraform, a broken instance is destroyed and rebuilt from the same code.

Drift is a security issue as well. A setting that someone changed by hand, outside any review, is the kind of misconfiguration attackers hope to find. Infrastructure as code gives you a known good state to compare against.

Software versions need the same care. Firefox, geckodriver and Selenium have to match each other (geckodriver supported platforms), so a single automatic browser update can stop the simulated user overnight. In practice, that means pinning almost everything:

What can change	How to keep it stable
Windows image	Use a fixed image version in Terraform, not "latest"
Firefox	Use a fixed version and turn off automatic updates
geckodriver and Selenium	Pin them together with the Firefox version
PowerShell modules	Use a fixed version for each module your scripts use
Azure and Entra ID	You cannot pin them, so test again before every release

Changes on Microsoft's side

Much of a cloud platform sits on the provider's side, out of your control. Microsoft changes sign-in pages, APIs and default settings on its own schedule. During development, Microsoft renamed some elements on the sign-in page, and the simulated user's automated steps could no longer find them, even though nothing in the lab had changed.

PowerShell modules change too. For example, starting with Az 14, Get-AzAccessToken returns the token as a SecureString rather than plain text (Microsoft migration guide). Scripts that used the token directly began sending a broken token, with no clear error, and the Altairus test scripts ran into this before release.

Defenders face the same risk with their own tooling. A detection rule or audit script written last year may now check nothing, and it will not tell you so. Test your scripts after module updates, and follow Microsoft's change announcements for the services you rely on.

Before you start: your attack machine

Altairus comes with setup scripts for the attack machine, one for Windows and one for Linux, and both are part of the official writeup. PowerShell runs on Linux, and so does much of the Azure and Entra ID tooling written in it. Some tools still need Windows. MicroBurst, the well-known Azure toolkit by Karl Fosaaen at NetSPI, is written in PowerShell, but its documentation says it runs only on Windows, and some of its scripts use the older AzureAD and MSOnline modules. Keep a Windows option ready for tools like that.

On Windows, watch the module scope. Modules installed from an elevated session with -Scope CurrentUser go to the account that approved the elevation. If that was a different admin account, the user who needs them gets nothing, so install with -Scope AllUsers.

What you get from Altairus

Altairus brings all of this into one environment, with Azure resources, Entra ID and hybrid identity connected as they are in real companies. The attack path is one linear chain, so each step builds on the previous one, and somewhere along the way there is a user who makes a mistake. These are the topics you will practice: