{"id":4025,"date":"2017-03-28T00:00:00","date_gmt":"2017-03-28T00:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/blog\/how-azure-security-center-helps-reveal-a-cyberattack"},"modified":"2025-06-17T08:13:52","modified_gmt":"2025-06-17T15:13:52","slug":"how-azure-security-center-helps-reveal-a-cyberattack","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/how-azure-security-center-helps-reveal-a-cyberattack\/","title":{"rendered":"How Azure Security Center helps reveal a Cyberattack"},"content":{"rendered":"\n

The Azure Security Center (ASC) analysts team reviews and investigates ASC alerts to gain insight into security incidents affecting Microsoft Azure customers, helping improve Azure Security alerts and detections. ASC helps customers keep pace with rapidly evolving threats by using advanced analytics and global threat intelligence.<\/p>\n\n\n\n

Although we have come a long way as far as cloud security is concerned, even today security factors are heavily discussed as companies consider moving their assets to the cloud. The Azure Security Center team understands how critical it is for our customers to be assured that their Azure deployments are secure, not only from advanced attacks but even from the ones that are not necessarily new or novel. The beauty of ASC lies in its simplicity. Although ASC uses machine learning, anomaly detection, and behavioral analysis to determine suspicious events, it still addresses simple things like SQL brute force attacks that Bad Guys\/Script Kiddies are using to break into Microsoft SQL servers.<\/p>\n\n\n\n

In this blog, we\u2019ll map out the stages of one real-world attack campaign that began with a SQL Brute Force attack, which was detected by the Security Center, and the steps taken to investigate and remediate the attack. This case study provides insights into the dynamics of the attack and recommendations on how to prevent similar attacks in your environment.<\/p>\n\n\n\n

Initial ASC alert and details<\/h2>\n\n\n\n

Hackers are always trying to target internet connected databases. There are tons of bad guys trying to discover IP addresses that have SQL Server running so that they can crack their password through a brute force attack. The SQL database can contain a wealth of valuable information for the attackers, including personally identifiable information, credit card numbers, intellectual property, etc. Even if the database doesn\u2019t have much information, a successful attack on an insecurely configured SQL installation can be leveraged to get full system admin privileges.<\/p>\n\n\n\n

Our case started with an ASC Alert notification to the customer detailing malicious SQL activity. A command line \u201cftp -s:C:zyserver.txt\u201d launched by the SQL service account was unusual and flagged as by ASC Alerts.<\/p>\n\n\n\n

The alert provided details such as date and time of the detected activity, affected resources, subscription information, and included a link to a detailed report of the detected threat and recommended actions.<\/p>\n\n\n\n

\"graphical<\/figure>\n\n\n
\"Graphical<\/figure>\n<\/div>\n\n\n\n

Through our monitoring, the ASC analysts team was also alerted to this activity and looked further into the details of the alert. What we discovered was the SQL service account (SQLSERVERAGENT) was creating FTP scripts (i.e.: C:zyserver.txt), which was used to download and launch malicious binaries from an FTP site.<\/p>\n\n\n

\"table\"<\/figure>\n\n\n\n

The initial compromise<\/h2>\n\n\n\n

A deeper investigation into the affected Azure subscription began with inspection of the SQL error and trace logs where we found indications of SQL Brute Force attempts. In the SQL error logs, we encountered hundreds of \u201cAudit Login Failed\u201d logon attempts for the SQL Admin \u2018sa\u2019 account (built-in SQL Server Administration) which eventually led up to a successful login.<\/p>\n\n\n

\"Table\"<\/figure>\n\n\n\n

These brute force attempts occurred over TCP port 1433, which was exposed on a public facing interface. TCP port 1433 is the default port for SQL Server.<\/p>\n\n\n\n

Note:<\/strong> It is a very common recommendation to change the SQL default port 1433, this may impart a \u201cfalse sensation of security\u201d, because many port scanning tools can scan a \u201crange\u201d of network ports and eventually find SQL listening on ports other than 1433.<\/p>\n\n\n\n

Once the SQL Admin \u2018sa\u2019 account was compromised by brute force, the account was then used to enable the \u2018xp_cmdshell\u2019 extended stored procedure as we\u2019ve highlighted below in a SQL log excerpt.<\/p>\n\n\n

\"text\"<\/figure>\n\n\n\n

The \u2018xp_cmdshell\u2019 stored procedure is disabled by default and is of particular interest to attackers because of its ability to invoke a Windows command shell from within Microsoft SQL Server. With \u2018xp_cmdshell enabled, the attacker created SQL Agent jobs which invoked \u2018xp_cmdshell\u2019 and launched arbitrary commands, including the creation and launch of FTP scripts which, in turn, downloaded and ran malware.
<\/p>\n\n\n\n

Details of malicious activity<\/h2>\n\n\n\n

Once we determined how the initial compromise occurred, our team began analyzing Process Creation events to determine other malicious activity. The Process Creation events revealed the execution of a variety of commands, including downloading and installing backdoors and arbitrary code, as well as permission changes made on the system.<\/p>\n\n\n\n

Below we have detailed a chronological layout of process command lines that we determined to be malicious:<\/p>\n\n\n\n

A day after the initial compromise we began to see the modification of ACLS on files\/folders and registry keys with use of Cacls.exe (which appears to have been renamed to osk.exe and vds.exe).<\/p>\n\n\n\n

Note:<\/strong> Osk.exe is the executable for the Accessibility On-Screen Keyboard and Vds.exe is the Virtual Disk Service executable, both typically found on a Windows installation. The command lines and command switches detailed below, however, are not used for Osk.exe or VDS.exe and are associated with Cacls.exe.<\/p>\n\n\n\n

The Cacls.exe command switches \/e \/g is used to grant the System account full(:f) access rights to \u2018cmd.exe\u2019 and \u2018net.exe\u2019.<\/p>\n\n\n

\"text,<\/figure>\n\n\n\n

A few seconds later, we see the termination of known Antivirus Software using the Windows native \u201ctaskkill.exe\u201d.
<\/p>\n\n\n

\"text\"<\/figure>\n\n\n\n

This was followed by the creation of an FTP script (c:zyserver.txt ) which was flagged in the original ASC Alert. This FTP script appears to download malware (c:stserver.exe) from a malicious FTP site and subsequently launch the malware.
<\/p>\n\n\n

\"numbers,<\/figure>\n\n\n\n

A few minutes later, we see the \u201cnet user\u201d and \u201cnet localgroup\u201d commands used to accomplish the following:<\/p>\n\n\n\n

a.    Activate the built-in guest account and add it to the Administrators group<\/p>\n\n\n\n

b.   Create a new user account and add the newly created user to the Administrators group<\/p>\n\n\n

\"text\"<\/figure>\n\n\n\n

A little over 2 hours later, we see the regini.exe command which appears to be used to create, modify, or delete registry keys. Regini can also set permissions on the registry keys as defined in the noted .ini file. We then see, regsvr32.exe silently (\/s switch) registering dlls related to the Windows shell (urlmon.dll, shdocvw.dll) and Windows scripting (jscript.dll, vbscript.dll, wshom.ocx).<\/p>\n\n\n

\"text\"<\/figure>\n\n\n\n

This is immediately followed by additional modification of permissions on various Windows executables. Essentially resetting each to default with the \u201cicacls.exe\u201d command.<\/p>\n\n\n\n

Note:<\/strong> The \/reset switch replaces ACLs with default inherited ACLs for all matching files.<\/p>\n\n\n

\"text\"<\/figure>\n\n\n\n

Lastly, we observed the deletion of \u201cTerminal Server\u201d fDenyTSConnections registry key. This is a registry key that contains the configuration of Terminal Server connection restrictions. This led us to believe that malicious RDP connections may be the next step for the attacker to access the server. Inspection of logon events did not reveal to us any malicious RDP attempts or connections, however:<\/p>\n\n\n\n