• <1 minute

How Azure Security Center detects vulnerabilities using administrative tools

Earlier this year, Rob Mead wrote a great article on the techniques used at scale by Azure Security Center to detect threats. In this post, we’ll go into the details on one such example, enabling Azure Security Center to detect usage of backdoor user account creation.

This blog post is authored  by Dotan Patrich, Senior Software Engineer, Azure Security Center and by Yossi Weizman, Security Software Engineer Intern, Azure Security Center.

Earlier this year, Rob Mead wrote a great article on the techniques used at scale by Azure Security Center to detect threats. In this post, we’ll go into the details on one such example, enabling Azure Security Center to detect usage of backdoor user account creation.

Backdoor user accounts are those accounts that are created by an adversary as part of the attack, to be used later in order to gain access to other resources in the network, open new entry points into the network as well as achieve persistency. MITRE lists the create account tactic as part of the credentials access intent of stage and lists several toolkits that uses this technique.

While it might seem at first glance that detecting such malicious account creation actions is easy, it is not often the case as creation of new accounts are mostly part of a legitimate administrative operation. Therefore, security products usually won’t alert on it as most organizations will have hard time coping with the volume of alerts to be triaged. This makes the account creation tactic a powerful adversary tactic.

Earlier this month, Azure Security Center released a new analytic to detect suspicious account creation operations that might be used as backdoor accounts. This analytic includes several criteria to distinguish between benign administrative account creation and suspicious activities that need to be alerted on. Some of those are derived from indicators that are seen at scale across many tenants.

As with all security analytics that are released as part of Azure Security Center, it is being monitored and investigated to see its noise ratio, performance and correctness. Monitoring the user creation analytic revealed an interesting case, showing that account creation can also be a symptom of a system vulnerability when not done right by benign tools. That vulnerability would not be flagged by other kinds of security alert since there was not malicious action being taken on the hosts, however it is essential for users to know that they have a potential high-risk vulnerability in their environment.

A deeper look at such alerts recently raised by Azure Security Center, showed cases where a user account was created by a command line that included the user name and password in plain text. What made it even more interesting, is that a deeper look at those incidents showed that the user creation operations were not performed by an adversary, but by a technical support software coming from a well-known vendor.

Further investigation of that software revealed that not only does it use an identical user name across different installations, but it also uses an identical password.

A malicious adversary could potentially probe different machines and try to login into them using those credentials. In cases where the hosts are configured to allow remote management connections, using PowerShell, WMI or remote desktop, etc., that would enable entry point into the network. In cases where the malicious adversary already has a foothold on the network, he could use those credentials to move laterally across the network to any machine that have the support tool installed, thus exposing all information on those machines including any other account that were logged on to those machines. Given that this account was created by a support tool, it is most likely that an administrator would install it, thus these hosts would probably have cached credentials of high privileges account which might be exploited.

Moreover, when we installed the software on a machine which is a Domain Controller, the created account was set as a domain user. That means that is such scenarios, the installation of the software causes to a security vulnerability for the whole domain.

image

A key take-away from this is to make sure to review and assess any account creation operation within the network, including local accounts. In addition, evaluating the configuration changes that each tool installation makes is essential to assess and mitigate any risk associated with it.

Azure Security Center makes it easier to automate the process of evaluating account creation actions and detects anomalous configurations with its Anomalous User Creation alert. So, if you see such an alert in your Azure subscription be sure to look into it:

image