# Massive Password Spray Campaign Targeting Azure CLI: 81 Million Login Attempts Traced to Hosting Provider


A coordinated password spray campaign involving over 81 million login attempts has been detected targeting Azure CLI—Microsoft's command-line interface for managing Azure cloud resources. Security researchers have attributed the attack infrastructure to systems associated with LSHIY, a hosting provider, raising questions about credential security practices and the sophistication of large-scale cloud infrastructure attacks.


The campaign highlights a persistent threat vector: attackers continue to leverage brute-force and password spray techniques against cloud management tools, betting that some accounts will use weak or reused credentials. With Azure's prevalence in enterprise environments, successful compromises could grant attackers direct access to production cloud infrastructure, databases, and sensitive applications.


## The Threat


The scale of this campaign is striking. Over 81 million login attempts targeting Azure CLI endpoints were observed originating from infrastructure linked to LSHIY, a hosting provider known for offering low-cost, minimal-oversight virtual private servers. This volume suggests a highly automated, distributed attack rather than a targeted effort against specific organizations.


Key characteristics of the attack:


  • 81+ million login attempts across Azure CLI endpoints
  • Infrastructure source: Systems associated with LSHIY hosting provider
  • Attack type: Password spray / brute-force credential attack
  • Target surface: Azure CLI authentication mechanisms
  • Timeline: Detection and reporting through SecurityWeek

  • The attackers appear to be attempting to gain valid credentials by cycling through username and password combinations. Unlike traditional targeted attacks, password spraying casts a wide net, assuming that among millions of accounts, some will have weak passwords, default credentials, or credentials already compromised in previous breaches.


    ## Background and Context


    Azure CLI and Why It Matters


    Azure CLI is a cross-platform command-line tool that allows developers, system administrators, and DevOps engineers to manage Azure cloud resources. It's used to deploy applications, configure infrastructure, manage databases, control networking, and automate cloud operations. For organizations relying on Microsoft Azure—a dominant cloud platform serving Fortune 500 companies, government agencies, and enterprises globally—Azure CLI is often central to infrastructure management.


    Access to Azure CLI credentials translates directly into cloud infrastructure access. An attacker with valid credentials can:

  • Deploy malicious workloads
  • Access sensitive data and databases
  • Modify security configurations
  • Launch lateral movement within the cloud environment
  • Establish persistence for long-term access

  • The Role of LSHIY


    LSHIY is a budget hosting provider known for offering VPS and dedicated server hosting at low cost, often with minimal identity verification or abuse monitoring. Such providers have historically become staging grounds for cybercriminals because:


    1. Low barrier to entry – minimal verification required to rent infrastructure

    2. Weak abuse policies – slow response to abuse reports

    3. Anonymity – attracts bad actors seeking to obscure their true location

    4. Scale – hosting providers offer many IP addresses, useful for distributed attacks


    The concentration of 81 million login attempts originating from LSHIY infrastructure suggests attackers either directly controlled many instances on that provider or leased botnet-compromised machines from LSHIY.


    ## Technical Details


    How Password Spray Attacks Work


    Password spray differs from traditional brute-force attacks. Instead of repeatedly attacking one account with many passwords, spray attacks target many accounts with a smaller set of common passwords. This approach:


  • Evades detection – distributed across many accounts and time, avoiding rapid-fire lockouts
  • Exploits human behavior – relies on common passwords like "Password123," "Azure2024," or reused corporate credentials
  • Leverages breached datasets – attackers often use usernames and passwords from previous breaches

  • With 81 million attempts, the scale suggests automation at an industrial level—likely using tools like HashCat, Hydra, or custom scripts cycling through credential lists.


    The Attack Infrastructure


    LSHIY-hosted systems provided the distribution point. Attackers likely:


    1. Rented or compromised multiple VPS instances on LSHIY

    2. Configured them with automated credential-testing tooling

    3. Distributed the 81 million attempts across these systems to avoid IP-level rate limiting

    4. Harvested any valid credentials discovered


    Detection and Attribution


    Security researchers identified the campaign through Azure's own telemetry and threat intelligence feeds that track login attempts. The concentration of traffic from LSHIY's autonomous system number (ASN) and IP blocks made attribution straightforward.


    ## Implications


    Immediate Risk for Azure Organizations


    Any organization using Azure CLI is potentially in scope:


  • Developers and DevOps teams – whose credentials are most likely to be tested
  • Service accounts – often created with simpler passwords for automation
  • Contractors and third parties – with Azure access but less secure credential practices
  • Legacy accounts – inactive but still valid, sometimes forgotten by administrators

  • Broader Cloud Security Trends


    This campaign reflects a troubling pattern: attackers are moving beyond application-level attacks to target cloud infrastructure directly. Other recent campaigns have targeted AWS, Google Cloud, and Azure credentials through similar mechanisms. As organizations move workloads to the cloud, credential security becomes *infrastructure security*.


    The Reuse Problem


    Many of the 81 million login attempts likely used credentials from previous data breaches. If an Azure account holder has reused a password from an old breach, attackers may already have their credentials in leaked databases. This campaign may represent an attempt to discover which breached credentials still work against live Azure services.


    Detection Gaps


    Organizations relying on standard Azure logging may have missed these attempts entirely. Azure does log failed authentication attempts, but in high-volume environments, suspicious login patterns can be buried in normal noise. Without proper SIEM configuration or alert tuning, these 81 million attempts might not have triggered actionable alerts.


    ## Recommendations


    Organizations using Azure CLI should implement layered defenses:


    ### Authentication & Access Control


  • Enforce multi-factor authentication (MFA) on all Azure accounts, especially service accounts and administrative roles
  • Use managed identities instead of storing credentials in code or configuration files
  • Implement conditional access policies to detect and block logins from unusual locations or IPs
  • Review service principal credentials – many organizations create them once and never rotate them

  • ### Monitoring & Detection


  • Enable Azure Sign-in Logs and configure alerts for failed authentication spikes
  • Set SIEM alerts for multiple failed login attempts from the same IP or targeting the same user
  • Monitor for impossible travel – logins from geographically impossible locations
  • Track Azure CLI usage – audit which accounts are using CLI and from where

  • ### Credential Hygiene


  • Rotate credentials regularly – especially service account passwords
  • Audit password reuse – check if Azure passwords appear in any breach databases
  • Use strong, unique passwords – enforce minimum complexity; consider passphrases
  • Eliminate hardcoded credentials – migrate to Azure Key Vault and managed identities

  • ### Infrastructure Hardening


  • Restrict Azure CLI access via network policies and IP allowlisting where possible
  • Use short-lived credentials – Azure access tokens are temporary by design; don't persist them
  • Implement just-in-time (JIT) access – grant elevated privileges only when needed
  • Regular security audits – review who has Azure CLI access and why

  • ---


    ## HackWire Analysis


    Why This Matters Now


    The 81 million login attempt campaign represents a shift in attacker sophistication: they're no longer just targeting applications or databases—they're going after the keys to the kingdom. Cloud credentials are the new currency of cybercrime. If you compromise Azure CLI credentials, you don't need to exploit a vulnerability; you *own the infrastructure*.


    The scale here is telling. 81 million attempts from LSHIY infrastructure suggests either a massive botnet at work or a committed, well-funded attacker group testing their entire credential database against Azure. This isn't a targeted spear-phishing campaign; it's industrial-scale credential harvesting. And it's likely working—some of those 81 million accounts probably had weak passwords or reused breach credentials.


    Pattern Recognition: The Broader Trend


    This fits a documented pattern we've seen accelerate over the past 18 months. Attackers have shifted from exploiting zero-days to exploiting humans. CVEs require active technical work; compromised credentials require only patience and scale. We saw similar campaigns against AWS (the now-infamous "silentpush" credential stuffing), Google Cloud, and GitHub. Azure's turn was inevitable. What's concerning is how *easy* it appears to be—attackers still believe password spray works, and statistically, they're right.


    The Hidden Risk: Detection Blind Spots


    Most Azure organizations don't have comprehensive logging or alerting for failed authentication attempts. They're flying blind. Azure logs these attempts, but without proper configuration of Azure Monitor, Log Analytics, or a SIEM integration, those 81 million attempts are invisible. An attacker only needs *one* account with a weak password to succeed—and they get thousands of chances to find it.


    What Defenders Should Do Today


    1. Check your Azure logs – if you haven't reviewed failed login attempts in the past 30 days, do it now. Odds are high you'll find spikes.

    2. Enforce MFA universally – not "where applicable," but everywhere. No exceptions for service accounts.

    3. Rotate credentials for service accounts – especially any that haven't been touched in over a year.

    4. Run a breach check – use Have I Been Pwned or similar tools to check if your corporate email domains appear in leaked credential databases.


    The good news: this attack is noisy and detectable. The bad news: many organizations won't notice until it's too late.


    HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)