We identify the attack of the encryption virus, gain access to the domain controller and try to resist these attacks.





WannaCry, NotPetya, BadRabbit and others are ransomware viruses that rattled the whole world about a year or two ago. Today there is less noise about attacks of these types of viruses, but stories with attacks still occur. In this article, I will show one of the tools to stop the attack of such a virus: quickly detect an intrusion and localize the problem. All this with the help of a log analytics and intrusion protection tool Quest InTrust . Under the cat are screenshots and a link to the repositories of malicious scripts. Let's go!



Quest InTrust is an integrated solution that includes collecting different types of logs, syslog data and ready-made parsers for different types of equipment. There are predefined rules for taking actions to prevent attacks. Now we’ll take a closer look at all of this with examples of parsing an encryptor virus attack and gaining access to a domain controller



Ransomware attack



The principle of the attack is to create new encrypted files or folders and delete the original ones. Well, then a ransom request in bitcoins or in another way. The definition of this type of attack is based on identifying bulk deletion and file creation. Especially if it happens after school hours.



A couple of repositories with examples of encryption scripts
Powershell-Ransomware

Ransomware-encryptor-decryptor



To collect change events, we use integration with the Quest Change Auditor audit solution (it was already written about in the previous article and even compared with a product from a competitor ). For events from this source, InTrust has predefined rules for detecting anomalies. Of course, you can add any event processing logic here. In my example, it is determined that when creating files in bulk (more than 5 pieces in 1 minute), the user account will be blocked and access to shared directories will be denied.







The policy settings indicate the directory to which the rule applies and the list of notifications. If there is information in AD about employee subordination, you can send a letter to his supervisor. A useful case is the identification of attempts to access files that, it would seem, are not necessary for the performance of duties by this particular employee. It can be especially important before dismissal, when you want to take ready-made developments with you.







After checking all the settings, let's move on to the pre-prepared script-encryptor. And run it.







In the settings for detecting an attack, “more than 5 files” were indicated, as you can see, after 7 files the virus was stopped (the user was blocked and access to the directory was disabled). Easy to get off. At the same time, responsible employees received notifications.



Attack on a domain controller



Below is the attack scenario, which allows you to access the administrative account and, as a result, the domain controller. Detection of the execution of specialized malicious cmdlets (for example, unloading domain accounts) are also included in the list of predefined Quest InTrust rules (the first line in the selection in the image below). In addition, in my example, users from the “white sheet” are indicated to which the rules do not apply (the second line in the selection in the image below).







Using the invoke-mimikatz script, the creation of a dump of account details is enabled. At the same time, no files are created on the file system. First, check the name of the account under which the login is made. As you can see, this user is from the white list, who can freely execute any cmdlets.







Then we execute the pre-prepared script. At the output, we get a conclusion in which we find the details of our test user.







In the next step, we find out which groups this user belongs to. Administrator groups are present.







Now we learn the names of the domain controllers. In my example, he is alone.







The next step in a potential attack is to log on to a domain controller. It remains to enter the password that has already been highlighted.







And get access to the execution of any commands on the domain controller.







Now let's try to do the same algorithm of actions, but on behalf of a user who was not added to the “white list” in InTrust. For the purity of the experiment, we check the username. Then we execute the invoke-mimikatz script.







Among the actions specified in InTrust were the termination of the terminal access session and blocking the user. Which is what happened.







Now check this account again.







The attack is prevented, the user is blocked, the world is saved.



If you have your own policies against various types of intruders, you can also specify them in InTrust. Together with other Quest products ( Change Auditor and Enterprise Reporter ) based on InTrust, you can build a full-fledged SIEM system to identify and prevent the serious consequences of digital attacks on business.



InTrust and other Quest products can be tried in your environment as part of a pilot project. Leave a request to find out more.



All Articles