Malware attacks are evolving and once common tactics are becoming a thing of the past. Attack strategies, like using a third-party hacking program or injecting viruses from external sources, are almost obsolete as they leave a distinct footprint. Most antimalware tools can now detect the presence of a foreign program or device and immediately block them.
In place of these once traditional malware attacks, there is a noticeable shift to malware-free or file-less attacks. Malware-free tactics accounted for 51 percent of attacks in 2019, compared to just 40 percent in the year before, and are predicted to increase in 2020. In these newer attack forms, malicious files are never written to the disk; the attacks are executed in-memory (RAM), and they blend in with legitimate system processes and leverage tools inherent in the Windows Operating System, such as PowerShell.
PowerShell was developed to enable administrators to automate tedious tasks. Since PowerShell is essentially an administrators tool, it offers unprecedented access to the restricted parts of the OS, and the fact that it is whitelisted, makes it a popular attack vector for hackers.
This blog demonstrates a few examples on how PowerShell can be abused by attackers. Since organizations are extending their on-premises environments to the cloud, and Azure Active Directory is a popular choice, we’ll show you how Azure AD can be attacked with PowerShell.
#1: Discovering the cloud with PowerShell
The first step of any attack process is to gather sufficient information. This is the phase where attackers analyze, survey, and search to obtain sensitive information and laterally plan their moves within the network.
There are many ways an attacker can intrude into your network. There are the two most common methods:
-
The attacker is an insider, such as a disgruntled employee or someone who gains access to a compromised user account.
-
The attacker is an external user who is not part of the domain or organization’s network.
Discovering Azure AD information as an external user
The focus of the attack is to compromise user accounts. Therefore, discovering user email addresses offers a way for hackers to bypass the initial infection phase.
To accomplish this, hackers often prey on the common but weak name formats used in many organizations, such as {firstname}.{lastname}.@example.com, by generating and attacking using permutations of user email addresses. This article provides more information about the process attackers often utilize.
In the login screen of Azure AD, a valid email address next leads to the password prompt in the login window. If the email address is invalid, it shows the “username may be incorrect” prompt.
A way to confirm the authenticity of the guessed email addresses is to enter them in the login screen manually. But that can cause numerous invalid login events, which could raise eyebrows in the IT department.
This script can automate the manual login process, but not actually create login events. PowerShell features several stealthy capabilities that hackers can exploit for unscrupulous purposes.
Office 365 email validation with PowerShell
Discovering email addresses as an internal user
Discovering the email address for an Azure AD user is pretty straightforward. Just login into Azure AD with PowerShell, and run a one-liner command that lists all users and their email addresses.
#2: A classic password brute-force attack with PowerShell
Now that attackers have a possible combination of valid email addresses, they could try to brute-force a set of predictable, yet commonly used passwords at the Azure AD login portal. The possibility is low that no one in an organization uses a trivial password.
But since manually brute-forcing passwords is a time-consuming process, hackers could use PowerShell to automate the brute-force attack. Of course, there are free scripts available on the internet to assist with this malicious activity. All that is needed is a text file with a set of user passwords and the victims’ email addresses. Look at the screenshot below :
PowerShell could be used to further filter the accounts subject to the brute force attack, for example, accounts with multi-factor authentication (MFA) enabled, to avoid red flags and conduct the attack as stealthily as possible. PowerShell also allows for execution of brute-force attacks on remote systems, without having to copy the script to the remote system.
#3: A password spraying attack using PowerShell
For an attack requiring a larger radius of blast, the password spraying technique is irreplaceable. Hackers can perform password guessing attacks on multiple Azure user accounts, and the only tool they need is PowerShell.
The script could be downloaded from the internet and obscured to avoid detection, or it could be directly downloaded from the URL in an open PowerShell session and executed in memory, making it an authentic, file-less attack.
#4: Exploiting the acquired credentials to vertically move up the network hierarchy
Now that hackers have the passwords of legitimate user accounts in Azure Active Directory, they can use acquired login credentials to gather more information about the privileged users and administrators in the organization.
Hackers might next try another password spray attack on privileged users. Or, they might try a targeted spear phishing email attack. At this point, hackers have a number of nefarious options available.
#5: Attacking Azure AD connect to obtain on-premises user passwords
If the organization uses an on-premises Active Directory, then the Azure AD Connect tool should have been used to sync user accounts.
Amazingly, with PowerShell, it is possible to determine the exact name of the server where Azure AD connect is installed.
A synchronization account is created by Azure AD Connect in the on-premises Active Directory. When Pass the hash synchronization (PHS) is used to sync passwords, this account is responsible for sending the password hashes to the cloud.
PowerShell can be used to extract the credentials of the Microsoft Online (MSOL) account. It is important to note the “Replicating Directory Changes” permissions of the MSOL account, which can be leveraged to obtain the password hashes of any user in the on-premises Active Directory.
As you can see, PowerShell enables attacking capabilities not just to the cloud, but also to on-premises environments. Stay tuned for our next blog post where we will walk you through the different ways PowerShell can be leveraged to establish a foothold in on-premises Active Directory.
Check our presentation on PowerShell attacks and how we could help you build an effective defense strategy using ManageEngine’s SIEM solution, namely Log360.
Register for our free webinar for a live demonstration of PowerShell-based attacks in your hybrid environments, and learn how to detect tell-tale signs, configure customized alerts alerts on malicious PowerShell use, and take remedial action.
