Cloud brute force login attempts

Threat snapshot

The AWS Management Console is the primary control plane for cloud infrastructure. An account that successfully authenticates to the console can provision resources, modify security configurations, access stored data, create or delete IAM identities, and interact with every service the account has permissions to reach. This makes the console login endpoint one of the most valuable targets for credential-based attacks against organisations running workloads on AWS.

Brute force and credential stuffing attacks against the AWS Console are a persistent threat. Attackers who obtain lists of corporate email addresses or IAM usernames through data breaches, phishing reconnaissance, or open source intelligence can systematically attempt authentication using password lists, previously breached credential pairs, or automated tools. Multiple consecutive login failures from the same source IP are the primary observable signal of this activity. Log360 detects it through the Multiple AWS Console Login Failures from Same Source IP rule, which fires when a threshold of failed console authentication attempts originates from a single IP address within a defined time window.

At a glance

How this attack works

AWS Console authentication failures are recorded in AWS CloudTrail as ConsoleLogin events with an errorMessage of Failed authentication. Each event includes the source IP address of the authentication attempt, the IAM username or root account identifier that was targeted, the AWS account ID, the timestamp, and the user agent string of the client making the request.

A brute force attack against the AWS Console typically follows one of three patterns. In a targeted password guessing attack, the attacker knows specific IAM usernames for the target account, obtained through phishing reconnaissance, LinkedIn profiling, or a prior data breach, and systematically tries password variations against those accounts. In a credential stuffing attack, the attacker uses username and password pairs from a previously breached third-party service, betting that the same credentials have been reused for the AWS account. In a distributed spray attack, the attacker attempts a small number of common passwords against many usernames to avoid per-account lockout thresholds, though this pattern generates failures across multiple usernames rather than from a single source IP and is therefore covered by complementary detection rules.

The single-source-IP pattern detected by this rule indicates that either the attacker is not attempting to disguise their origin, they are operating from a compromised host or VPN exit node, or they are using an automated tool that has not been configured for IP rotation. The source IP concentration is the detection anchor, because it allows the SOC to identify a specific origin for blocking and investigation while the failures are still occurring, before a successful authentication takes place.

Attack chain

The table below maps each stage of a cloud brute force login attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A software company runs its production infrastructure entirely on AWS, with 15 IAM users across engineering, DevOps, and finance teams. An attacker who obtained a list of the company's email addresses from a recent third-party data breach begins a credential stuffing campaign against the company's AWS Console using the breached email addresses as IAM usernames and the associated breached passwords as the first attempt for each account.

Over a 12-minute window, the attacker generates 47 failed ConsoleLogin events across 9 different IAM usernames, all originating from the same source IP address. The attack tool moves through the credential list sequentially. On the 48th attempt, the tool successfully authenticates as the company's DevOps lead, whose AWS password happens to match a password they used for a breached gaming platform account three years earlier and never changed.

Log360 fires the Multiple AWS Console Login Failures from Same Source IP alert after the 10th failure. The alert reaches the SOC queue two minutes later. The analyst reviewing the alert notices the high failure count and queries for successful ConsoleLogin events from the same source IP. A successful authentication as the DevOps lead is visible in the results, timestamped four minutes before the alert was reviewed. The analyst immediately revokes the active session, disables the IAM user, and begins investigating what actions were taken during the four-minute authenticated window. The attacker had created a new IAM access key under the DevOps lead's account before the session was terminated.

Why this happens
IAM users who reuse passwords across personal and corporate accounts create a direct link between third-party data breaches and AWS Console access. Password reuse is the primary enabler of credential stuffing attacks. The AWS Console does not enforce MFA for IAM users by default. In accounts where MFA is not mandatory, a correct username and password combination is sufficient for full console access regardless of the source IP. Without MFA as a second factor, the only line of defense against credential stuffing is detection and response speed.

Business impact: What can go wrong

A successful brute force attack against the AWS Console can have immediate and wide-ranging consequences depending on the permissions of the compromised IAM user:

• Data exfiltration from S3: a compromised IAM user with S3 read permissions can enumerate and download the contents of any accessible bucket within minutes. S3 buckets frequently contain database backups, application configuration files, customer data, and intellectual property.
• Infrastructure manipulation: IAM users with EC2 or networking permissions can modify security group rules to expose internal services, launch instances for cryptocurrency mining, or terminate production workloads, causing immediate service disruption.
• Persistence via IAM manipulation: an attacker with IAM write permissions can create new users, generate access keys, or attach policies to existing identities, establishing persistent access that survives a password reset on the originally compromised account.
• Lateral movement to connected services: AWS accounts are frequently integrated with other cloud services, CI/CD pipelines, and on-premises systems. Credentials and configuration data accessible in the AWS Console or in S3 buckets may provide the attacker with credentials for connected systems beyond the AWS environment.
• Regulatory and compliance consequences: unauthorised access to AWS accounts hosting personal data, payment data, or health records triggers breach notification obligations under GDPR, PCI DSS, and HIPAA. The inability to determine the precise scope of data accessed during an incident compounds the regulatory exposure.
• Financial impact from resource abuse: attackers who gain AWS Console access frequently launch high-compute EC2 instances for cryptocurrency mining, incurring substantial AWS costs that are billed to the account owner before the activity is detected and terminated.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Multiple AWS Console Login Failures from Same Source IP rule can fire reliably, ensure the following are in place:

• AWS CloudTrail is enabled for all AWS regions in the monitored account, with a trail that logs management events including read and write API calls. ConsoleLogin events are logged by CloudTrail as management events. If CloudTrail is disabled or limited to specific regions, login failure events from those regions will not reach Log360.
• CloudTrail logs are being forwarded to Log360. Configure the CloudTrail trail to deliver logs to an S3 bucket and configure the Log360 AWS log source to ingest from that bucket, or use the Log360 CloudTrail integration to pull events directly. Verify that Log360 is receiving CloudTrail events before enabling the rule by checking for recent ConsoleLogin events in the Log360 search interface.
• The AWS account or accounts to be monitored are configured as log sources in Log360 under Settings > Log Source Configuration. If multiple AWS accounts are in use across the organisation, each account must be configured as a separate log source to ensure the rule fires on login failures across the entire AWS estate, not only the primary account.
• CloudTrail log delivery latency is understood and accounted for in the alert configuration. CloudTrail delivers logs to S3 with a typical latency of 5 to 15 minutes. This means the rule fires based on events that occurred up to 15 minutes before the alert is generated. Configure the alert notification and SOC workflow to account for this latency when assessing whether an active attack session may still be in progress.

Note
ConsoleLogin events are global events in CloudTrail and are logged to the us-east-1 region trail regardless of which region the user selects after login. If your CloudTrail configuration only captures events in specific regions and does not include a global service events trail in us-east-1, ConsoleLogin events will not be logged. Verify that the CloudTrail trail used as the Log360 log source has Include Global Service Events enabled.

Detecting Active Directory backup extraction using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Multiple AWS Console Login Failures from Same Source IP. Configure an alert profile for the same. Review the default failure count threshold and time window before going live. The default threshold should be appropriate for most environments, but in accounts with a large number of IAM users or with known automated authentication activity, the threshold may need adjustment to reduce false positives during the initial deployment period.

Step 2: Tune the rule for your environment

After enabling the rule, review the following:

• Identify known IP addresses that may legitimately generate authentication failures. CI/CD pipelines, automated testing tools, and monitoring agents that authenticate to AWS using IAM credentials may occasionally generate ConsoleLogin failures. Identify the source IPs of these systems and consider whether they should be excluded or handled separately from the main alert threshold.
• Configure the alert to include the source IP address and the list of targeted IAM usernames prominently in the notification. This information is the primary data needed for the initial triage decision and should be visible in the alert notification without requiring the analyst to open the Log360 interface.

Step 3: Read the alert

When the rule fires, the alert will display the source IP address generating the failures, the count of failed authentication attempts, the IAM usernames targeted, the AWS account ID, and the time window of the activity. Review the source IP first and check it against your known legitimate IP list. Then review the list of targeted usernames: failures against a single username suggest a targeted password attack; failures spread across multiple usernames suggest credential stuffing. Finally, and most critically, check immediately whether any ConsoleLogin Success event has been generated from the same source IP in the same time window.

Investigating an alert

When the Multiple AWS Console Login Failures from Same Source IP rule fires, an L1 or L2 analyst should work through the following steps:

• Check for a successful login from the same source IP immediately. Before any other investigation step, query Log360 for ConsoleLogin events with responseElements.ConsoleLogin: Success from the same source IP address in the same time window as the failures. If a successful login is present, escalate immediately to L3 and proceed to the post-authentication activity check in step 3 before completing the remaining steps.
• Assess the source IP. Look up the source IP address in a threat intelligence source or IP reputation service. Determine whether it belongs to a known malicious actor, a VPN or Tor exit node, a hosting provider, or a residential or corporate network. An IP geolocating to a country where none of your IAM users are located is a strong supporting indicator of a genuine attack.
• Review post-authentication activity if a successful login was found. Query Log360 for all CloudTrail API events from the authenticated session in the period following the successful ConsoleLogin. Look for IAM write operations (CreateUser, CreateAccessKey, AttachUserPolicy, PutUserPolicy), S3 data access events (GetObject, ListBucket), EC2 modifications (RunInstances, AuthorizeSecurityGroupIngress), and any other resource creation or modification events. Document every action taken during the authenticated session.
• Identify the targeted IAM usernames. From the alert detail, list all IAM usernames that received failed authentication attempts from the source IP. Determine whether the usernames match the format of your IAM naming convention, which would suggest the attacker has accurate information about your IAM user structure, versus generic username guesses, which would suggest a less targeted attack.
• Check for concurrent attacks from other source IPs. Query Log360 for failed ConsoleLogin events from IP addresses other than the alerting source IP in the same time window. Coordinated brute force campaigns sometimes use multiple source IPs against the same account to stay below per-IP thresholds. Failures from multiple IPs targeting the same set of usernames in the same window indicate a distributed credential stuffing campaign.
• Verify the status of MFA for targeted accounts. For each IAM username that received failed authentication attempts, check whether MFA is enabled on the account. Accounts without MFA that received failures are at higher risk if the attacker possesses the correct password from a credential breach. Consider proactively forcing a password reset for accounts without MFA that were targeted, even if no successful login occurred.

Escalation trigger
Escalate immediately to L3 if a successful ConsoleLogin event is found from the same source IP that generated the failures; if post-authentication CloudTrail events show IAM write operations, S3 data access, or resource creation in the authenticated session; if the attack targets IAM users with administrative or broadly privileged permissions; or if the source IP is associated with a known threat actor or anonymising infrastructure. Revoke the active console session and disable the affected IAM user before the investigation is complete if any of these conditions are confirmed.

Responding and remediating

Immediate containment

• If a successful login is confirmed, revoke the active console session immediately. In the AWS Console under IAM, navigate to the affected user and invalidate all active sessions. This terminates the authenticated console session but does not revoke any access keys the attacker may have created during the session.
• Disable the affected IAM user account immediately to prevent further authentication attempts. Use the IAM console or AWS CLI: aws iam update-login-profile to disable console access, and aws iam deactivate-mfa-device if the attacker may have registered an MFA device during the session.
• Block the source IP address at the AWS account level using an IAM policy condition or an AWS WAF rule on the CloudFront distribution fronting the console, if applicable. At minimum, document the source IP for firewall blocking at the perimeter if corporate users access the AWS Console through a managed network egress.
• If the attacker created new IAM users, access keys, or roles during an authenticated session, delete these immediately. Query CloudTrail for CreateUser, CreateAccessKey, and CreateRole events from the authenticated session and remove every identity and credential created during that window.

Forensic preservation

• Export all CloudTrail events associated with the attacking source IP and the affected IAM user for the full period from the first failure event to the time of containment. These events are the primary forensic record of both the attack attempt and any actions taken during an authenticated session.
• Document the complete list of IAM changes made during any authenticated session, including users created, access keys generated, policies attached, and roles modified. This list is required for full remediation and for assessing the scope of persistent access the attacker may have established.
• Preserve the source IP, user agent string, and timing data from the attack. This information may be useful for threat intelligence sharing and for identifying whether the same infrastructure is targeting other accounts or services.

Eradication and recovery

• Force a password reset for all IAM users that were targeted by failed authentication attempts, not only the one that was successfully compromised. Targeted usernames indicate the attacker has an accurate list of your IAM users and may attempt further attacks with different password lists or from different source IPs.
• Enforce MFA for all IAM users with console access if it is not already mandatory. Apply the AWS managed policy that denies all actions unless MFA is present to all IAM users, or use an IAM permission boundary to enforce this requirement. A successfully guessed password is insufficient for console access when MFA is enforced.
• Audit all IAM access keys, users, roles, and policies for unexpected additions or modifications created within the timeframe of the incident. Any identity or permission change that cannot be attributed to a documented administrative action should be removed.
• Review the AWS account's password policy. Enforce a minimum password length of 14 characters, require a mix of character types, and enable password expiration. A strong IAM password policy reduces the effectiveness of password guessing and limits the window of exposure for reused or compromised passwords.

False positive guidance

Multiple failed AWS Console logins from a single source IP can occur in legitimate contexts. The following scenarios are the most common sources of false positive alerts:

• User with an expired or forgotten password: an IAM user who has forgotten their password may make several failed login attempts before contacting IT support or using the password reset flow. These will typically involve a small number of failures against a single username from a corporate or residential IP address. Verify the source IP matches the user's known location and the failure count is low (fewer than 10 attempts). A password reset request or helpdesk ticket from the same user at approximately the same time confirms this is legitimate.
• Misconfigured CLI or SDK tool: developers and DevOps engineers who rotate IAM credentials may temporarily have a misconfigured CLI profile that attempts authentication with outdated credentials. These failures will come from a known corporate or developer IP, target a single IAM username, and typically stop once the engineer realises their tool configuration is outdated. A follow-on successful authentication after the engineer reconfigures their tool is a normal outcome.
• Automated monitoring or health check tools: some infrastructure monitoring tools perform periodic authentication checks against the AWS Console to verify account accessibility. If these tools are not configured to use dedicated credentials or are using expired credentials, they may generate recurring failure events from a consistent source IP on a regular schedule. Identify the tool, verify the source IP matches the monitoring infrastructure, and configure the tool with valid credentials or exclude the source IP from the rule.
• Password manager autofill with outdated credentials: users who store AWS Console credentials in a password manager and have changed their password may encounter autofill failures if the password manager has not been updated. These will come from the user's known workstation IP and will stop once the password manager is updated. The failure count will be low and the pattern will not recur after the credentials are refreshed.

Key differentiator
Legitimate failed authentication events are low in volume, target a single IAM username, originate from a known IP address associated with the user or a managed corporate system, and are typically accompanied by a subsequent successful login or a helpdesk contact from the same user. An attacker-initiated brute force or credential stuffing attempt will have a higher failure count, frequently targets multiple usernames, originates from an IP address that does not correspond to any known user location, and will not be accompanied by a helpdesk contact or change request. The source IP reputation and the number of distinct usernames targeted are the two most reliable differentiators.

Hardening and prevention

The following controls significantly reduce the risk of successful brute force or credential stuffing attacks against the AWS Console:

• Enforce MFA for all IAM users with console access using an IAM policy condition that denies all console actions unless aws:MultiFactorAuthPresent is true. MFA is the single most effective control against credential stuffing: even a correctly guessed password is insufficient for access when a second factor is required.
• Enforce a strong IAM account password policy. Set minimum length to 14 characters, require uppercase, lowercase, numbers, and symbols, enable password expiration at 90 days, and prevent password reuse for the last 24 passwords. A strong password policy reduces the effectiveness of password guessing and limits the value of older breached credentials.
• Use IAM Identity Center (formerly AWS SSO) with a corporate identity provider instead of native IAM user passwords for console access. Federating console access through an identity provider that enforces MFA, conditional access policies, and session management removes the IAM password as an attack surface entirely.
• Apply IP-based IAM condition policies to restrict console access to known corporate IP ranges where operationally feasible. An IAM policy condition using aws:SourceIp to allow console access only from documented corporate egress IPs prevents authentication attempts from external addresses regardless of whether the credentials are correct.
• Enable AWS GuardDuty in all regions. GuardDuty provides additional behavioural detection for post-authentication actions in the AWS environment, including IAM anomaly detection and unusual API call patterns, complementing the Log360 brute force detection with coverage of the post-compromise phase.
• Conduct periodic credential hygiene reviews. Identify IAM users who have not logged in for more than 90 days and disable their console access. Dormant accounts with valid credentials are particularly vulnerable to credential stuffing because their owners are unlikely to notice authentication failure notifications.