Azure IR project with MDE
Hello everybody! In this post, I’m going to explain step by step how to create a VM in Azure, onboard the machine to Microsoft Defender for Endpoint, install a MySQL database onto the VM, and misconfigure the VM to allow all traffic to enter the VM as well as allow all traffic to query the MySQL database. From there, I am going to share how I investigated malicious actions taken on the database and VM. I will re-harden the VM and database. Lastly, I will create an incident report from my findings. To start, I logged into my Azure subscription, searched for “virtual machine” in the top search bar in Azure, then selected the virtual machine option. I went ahead and created my virtual machine.
I then grabbed the onboarding package from Microsoft Defender and downloaded it onto my VM so logs can start coming in for my VM.
Next, I went to verify that logs were being received in Microsoft Defender for my endpoint. In order to do this, I went to Defender and started querying logs under my device name.
Next, I went to download MySQL for my device.
Next, I configured the database to my liking in the configuration setup. I chose a full setup type and then left all the other configuration settings as is.
After the configuration was completed, I grabbed a script to run in Workbench so that I had a dummy database in SQL.
Next, I enabled MySQL audit and general query logging so that all queries to the database are logged.
I downloaded a my.ini file and replaced the current one in the “C:\ProgramData\MySQL\MySQL Server 8.0\my.ini” folder path. This file allows logging for everything on the database as well as allowing logins over the network. MySQL80 needed to be restarted. To do so, I ran services.msc in Run and went to the service to restart it. From there, I decided to run a few queries to ensure logs are populating from MySQL to the MySQL log file.
The next step is to create a custom text log DCR in Azure, pointing AMA at the MySQL log file so that it points to the MySQLAudit_CL table.
I waited a few minutes and then headed over to Microsoft Defender to verify logs were being ingested for MySQL.
The next step was creating a few analytics rules in Microsoft Defender to trigger once I officially open the VM to the internet.
This will be the query used for the first rule.
Here are some of the other configuration settings for the analytics rule that I set.
I then created a second rule to track MySQL activity and to alert on possible malicious activity:
The other alert enhancement parameters are the same as the first analytics rule I made. With the analytics rules in place, everything is now set to expose the VM to the internet. For the next section, I started by logging in to the VM and creating an administrator account in Local Security Policy. I also created a guest user as well.
From there, I added these two newly created accounts so they could remotely connect to the computer via the RDP application.
I also added the administrator account to the Administrator group:
I then created a new root user in MySQL.
I then went into Microsoft Defender to collect an investigation package on my VM in the Assets tab.
Now, I can turn off the firewall on the VM.
Lastly, I will create a rule in NSG to allow all inbound traffic to the VM.
Now, with these rules applied, I gave the open internet approximately 28 hours to see what malicious behavior happens on my VM. After waiting, I went to see if any alerts triggered (they did). I ran a query to see what type of action had been taken on the database. It would appear my database has been infected by ransomware.
Knowing that someone had logged into the admin account I created, I decided to dig around in the logs to see if there was any other suspicious activity taking place. I utilized multiple tables such as DeviceProcessEvents, DeviceLogonEvents, DeviceRegistryEvents, and DeviceNetworkEvents. After digging around some, I found a few logs that may have been of interest, but there was nothing to confirm that some other sort of persistence was installed on the virtual machine.
The file hashes came back clean but I found these two events odd and other events related to these logs. Knowing that the VM was officially compromised and I gave attackers sufficient time to play around in the environment, I went ahead and captured one more investigation package for later analysis and officially isolated the machine from the environment.
Now with the machine isolated, I decided to harden the virtual machine. The first thing I did was delete the administrator account and disable the guest account.
I then deleted the Bind Address field from the my.ini file; this prevents people from connecting to the database over the internet.
I also put in a query to make the root password stronger but then just added another query at the bottom to delete the user as a whole. This was just for proof of concept if you wanted to keep the root account.
I also went ahead and backed up the database that was encrypted so that I have my data again. I also went ahead and re-enabled the firewall from earlier, deleted the NSG rule that allowed all traffic, and ran a full AV scan on the VM.
Now, for the last step, I went ahead and created an incident report.
Get Dh’s stories in your inbox
Join Medium for free to get updates from this writer.
You can view the report with this link: Ir report 2.docx. Thank you for reading!
