The use of cloud services brings broad network access to application and management (administration) planes thus enabling access to cloud services from any device at any time. While enhancing collaboration, this brings an increased risk of global access by potential attackers. This is especially true for the management plane as the accounts in question are likely to have higher privileges, and therefore able to do more significant damage to the assets of the organization.
Whilst the use of leaked or reused credentials and passwords are risks that are well understood and must be minimized by the cloud customer, another risk to consider is that of password spraying. Password spraying is the act of ‘spraying’ lists of common or custom crafted passwords against multiple cloud accounts in an organization.
Password spraying differs from brute forcing in that the target is not a single user, but multiple accounts. A simple limited example of password spraying would be to spray the password ‘123456’ which is accepted as one of the most common 'bad' passwords, against all known accounts and email addresses in an organization, to attempt a successful login.
Should the potential attacker be successful, dependent on the privileges granted to the compromised account, examples of their next steps may be to forward all emails to an external address, place themselves in line with email flow, attempt a request to transfer money to a member of the finance team, or gain administrator login credentials to a cloud management console.
In a recent high-profile attack on a large software company, it was publicized that the attackers gained an initial foothold in the organization via a password spraying attack. From here, they were able to move laterally and elevate their privileges. The business impact of a security breach could be fines, a share price drop, reputational effects, data/IP loss, loss of future business and probably a combination of all of these.
How can organizations protect users' accounts from password spraying?
The following steps should be considered in order to mitigate the probability of password spraying occurring in the first instance and of its impact.
1. Multi-Factor Authentication (MFA)
MFA adds additional factors on top of the traditional username and password pair, for increased security. A factor is an additional piece of information to assist in identifying valid users such as a PIN number, a hardware token or a fingerprint.
This method has been proven to be one of the most effective steps an organization can take in increasing its cloud security posture. It can be implemented as always ‘on’ or enabled outside of known public IP addresses. Organizations may enable MFA as always ‘on’ for administrators and enabled for standard users only when they are connecting from endpoints outside of known locations.
Taking MFA a step further is the use of adaptive MFA. Adaptive MFA brings additional layers of security such as contextual access management to minimize rogue connections. Contextual access management incorporates the use of known IP and geographical locations combined with time and date considerations. If users attempt to connect from unknown countries the connection is refused and logged. Similarly, if a user attempts to connect within a short time frame from geographical locations that are widely separated the connection is refused. Other advanced features that warrant investigation include risk profiling, behavioural analysis, and device profiling.
2. Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC)
In RBAC, users or groups are assigned roles. These roles are either predefined or custom and determine what the user can do to the resource in question.
For example, if ‘OWNER’ access to the ‘CORE SERVERS’ resource group is assigned to the ‘L3 Engineers’ group; these engineers have full administrative access at the cloud management plane level to the servers in this resource group.
ABAC is the next generation of access control. Here, access control is set by policy and allows increased granularity and security and is recommended by the Cloud Security Alliance (CSA) over RBAC due to this. For example, access will be granted to the enterprise payroll WebApp IF the user is in the finance group AND they are a Manager AND they are using a software or hardware MFA token.
By implementing RBAC or ABAC the organization is ensuring that users are only granted the privileges required to fulfil their role and no further.
Usernames in an organization may map to an email address. Attackers can either gather these manually or use Open Source Intelligence Tools (OSINT), websites, or scripts to automate the process of collection.
Example of targets for OSINT includes company websites, social media (personal and business), and publicly available documents created by the organization (data and metadata).
The attackers may have determined via social media that there is an administrator working for the organization called Joe Bloggs. The username structure of the organization is known to be joeb@[company].com, based on other known emails on the organization’s website. Based on this structure, lists of potential valid emails may be generated using either a list of the known employees or a localized list of common names.
After compromise of a single user, the attacker may be able to enumerate the directory, and therefore all usernames, groups, and applications. Shared/common usernames such as administrator@, or hr@, and service accounts will likely also be considered by the attacker.
Some portals may be two-step, allowing the attacker to first test for valid accounts. If prompted for a password, the attacker will be able to determine that the account is valid. Therefore, the use of non-easily identified usernames should be considered such as prefixing with letters or suffixes combined with special characters would hinder the threat progression.
The attacker now has a list of potential valid user accounts for the target service and organization. The next step will be to generate a list of likely passwords for use in the password spray attack. The directory service or local cloud database containing the users may have default complexity requirements, including a minimum and maximum password length. This may be taken into consideration when generating potential valid passwords for a password spray attack. The organization may not have modified the platform away from the default configuration.
Credential reuse may also be used as an avenue for investigation. The employees may have reused credentials from their personal user accounts that have been breached and publicly disclosed for their work accounts.
Common passwords are published online and included in penetration testing distributions of Linux. The attacker could utilize these as a base, also creating a customised list of potential passwords geared towards the organization, incorporating keywords scraped from public resources using OSINT tools.
It is recommended to investigate the possibility of implementing a banned password list, should your directory service include this feature, to reduce the risk of users setting easily guessed passwords that include strings related to the organization, locality or common/leaked passwords. Increased password complexity and more importantly password length will increase the entropy or strength of the password thus minimizing the probability that it can be cracked.
5. Lockout policy
Directory services may have a default account lockout policy. The service may lock the account for a set number of minutes after several failed attempts at login. Based on this knowledge, the attacker could set an appropriate time delay between each group of attempted logins to bypass this. Increasing the lockout duration combined with reducing the number of allowable failed attempts improves the resiliency of this feature.
6. Legacy clients, browsers and protocols
Attackers may be able to bypass MFA in certain situations due to legacy protocols not supporting MFA. Internet Message Access Protocol (IMAP) access is an example of this. Legacy clients, browsers and protocols should be reviewed with the intention of modernizing them, to reduce the risk of this attack. Full investigation and planning followed by phased testing and service modernization are highly recommended, to avoid breaking production services that rely on legacy protocols.
7. Monitoring of admin and user accounts
It is crucial that organizations regularly review their cloud management plane and directory service audit logs for both admin and user account activity. Scheduled reporting sent to email distribution lists, alerting, Security Information and Event Management (SIEM) integration, and event-driven security are all strongly recommended. Integration with a SIEM will allow the organization to correlate events with information from multiple feeds and logging systems. Some platforms and solutions also provide behavioural analytics and machine learning, and integration with partner threat intelligence feeds.
Monitoring will allow visibility into password spraying attacks in progress and allow for manual or automated remediation. Automating this remediation with event driven security will greatly improve the ability to combat such threats in a sustainable manner.
Native audit logging tools on the cloud platform management plane can be used in the above is not available, to augment these tools or in the planning stages.
Recommendations to counter the threat of password spraying attacks:
- Implement MFA
- Consider ABAC over RBAC
- Implement a banned password list
- Use a strong password complexity policy
- Strengthen your account lockout policy
- Investigate legacy protocol and service modernization
- Monitor your admin and user accounts for unusual activity
Due to the broad network access characteristic of cloud services, identity management requires even more focus than with traditional on-premises network security as by default both admin and standard user accounts are accessible from any location in the world, should the requesting party have a valid username and password. It is important to stay up to date on the security capabilities of your cloud applications, platforms, and identity providers, along with the following security best practice. It’s imperative that this exercise is incorporated into security operations to ensure day to day threats are minimized and not undertaken on a scheduled basis as the threat landscape is constantly shifting.