Microsoft Sentinel Threat Detection

 This lab utilizes Microsoft Azure to configure and deploy a cloud-based SIEM, focusing on Microsoft Sentinel as the SIEM solution. A SIEM stands for security information and event management. It allows for the logging of information from multiple machines to a centralized source. That data can then be processed and analyzed by security analysts to monitor, detect, prioritize, and remediate potential threats that can arise. This lab will also be going over the MITRE ATT&CK framework and how it can be implemented into the SIEM.

Microsoft Sentinel Partner | WithSecure™

Create Azure Account:

This can be done for free by signing up for a free Azure subscription. It provides 30 days of free credit as a well as a 30 day free trial for Microsoft Sentinel and Microsoft Defender for Cloud. Click on the link below to sign up.

https://azure.microsoft.com/en-ca/free/

Create a Resource Group.

  1. When you reach the Azure portal, search for Resource Groups.
  2. Click Create located on the top left corner of the screen.

3. Provide a name and click on Review and Create > Create.

A resource group is a container used to hold, manage, and organize azure resources. Resources are like building blocks that you can use to create and manage different parts of your cloud application and services. Example would be virtual machines, databases, and storage accounts.

Create a virtual machine

A virtual machine(VM) is a software based emulation of a physical machine. It utilizes a software or hardware called a hypervisor which allows the creation and management of of VMs. It also allows for multiple VMs to be created.

  1. Search for Virtual Machine in the search tab. Click Create > Azure virtual machine.

2. Using the resource group you created earlier, create a name for the VM(virtual machine), and switch the image to Windows 10 Pro.

3. Create a username and password. Be sure to remember it so you can log into the VM.

4. Click Review + Create > Create.

After you created it, you should be able to see information about the VM.

When you create a VM in azure, it obtains an IP address and as well as a network interface. This is because it is placed on a virtual network(VNet). Azure also has something called Network Security Groups(NSG) which contains security rules that allow or deny traffic going inbound or outbound based on source and destination ports as well as network protocols similar to how a firewall functions.

Microsoft Defender for Cloud

Currently, the VM is facing the public side, meaning that anyone who knows our public IP address can attempt to connect to it. They can utilize methods such as password spraying attacks and brute forcing to try to log in. In order to prevent this, you can set a rule depending on your preferences. In this lab, you will be blocking all traffic except your own IP address.

To see the rules, go to:

Resource Groups > click on the resource you created > click labvm.nsg.

You can see that any source IP address is allowed through the NSG. To prevent this,

  1. Search for Microsoft Defender for Cloud > Getting Started.
  2. Check box the resource and click upgrade.
  3. Click on Enable all Plans > Save

Side note: You can see your overall security posture in the WorkLoad Protections of Microsoft Defender for Cloud.

Now you need to enable Just in time access. To do this,

  1. Go to your VM.
  2. In the Settings, click on Connect.
  3. Click on configure for this port > Configure.

Just in time blocks all inbound traffic. If you go to the NSG rules, you can see another rule preventing any IP address from connecting to your machine. Even though the rule below it allows it, the lower number takes priority.

But you still want our network to be able to connect ourselves to the VM. To do this,

Go to your VM > Connect > Request access > Local machine IP > Request Access.

Note: This rule expires so you periodically have to keep requesting access if you arent already connected and in the VM.

Now if you go back to labvm.nsg in your resource group or go to the Networking tab in your VM, you should see the new rule that allows our public IP address. Remember that the lowest number takes priority.

Adding Log Analytics Workspace

The Log Analytics workspace allows you to store, retain, and query all log data from Azure monitors and other Azure resources. In this case, it will be used for Microsoft Sentinel.

  1. Search Log Analytics Workspace and click Create.
  2. Use the research group that you created and give the instance a name.

4. Click Review + Create > Create.

Adding Microsoft Sentinel

  1. Search Microsoft Sentinel and click Create.

2. You should see your log analytics. Click on it and then Add.

Adding data connectors to Microsoft Sentinel

Data Collectors: Components that collect and ingest data from various sources into the Sentinel for analysis. These collectors could host different things such as data bases, files and software. In this lab, you will be using Windows Security event. It allows us to retrieve log data from Windows machines. This data includes information about the system, and object access, and security.

  1. Go to Microsoft Sentinel. Click on the instance you created.
  2. In the configuration, go to Data Collectors > Go to content hub.
  3. search for Windows Security Events and install it.
  4. Click on Manage > 1 item for Windows Security event via AMA.
  5. Create data collection rule.

6. Give it a Rule Name and your resource group.

7. Under Resources tab, Add resource. you can scope it to your subscription or your resource group.

8. Under Collect tab, select All security Events. Then finish up the rule.

Now you should see that is says 1 connected in Data Connectors.

Configuring Virtual Machine

Since you are using RDP, you will use the Remote Desktop Connection Client. RDP(Remote Desktop Protocol) runs on port 3389 and allows you to connect to another machine over the internet, allowing you to control it with graphical user interface.

1.Type in your VMs public IP address.

2. Type in your username and password you set for the VM.

3. Once your logged in, go into Event Viewer.

4. Windows Logs > Security.

In the Event Viewer, you can see all of the security events such as your logons. Successful logons have the event ID 4624.

You can see account was successfully logged on.

You can also double click on it to see more details.

What you will be doing is instead of using the Event Viewer to see all of our events, you will view it in the SIEM. Typically in an organization, there will be many computers and you need a central location to view all of these security events instead of going to each machine. Another reason is so you can manipulate the data such as creating charts.

Kusto Query Language (KQL)

Every SIEM has a search language that is used to interact with the SIEM and the logs you are keeping track of.

  1. Go to logs in Microsoft Sentinel.

Here you will be using KQL to retrieve logs.

2. First you need to get the source of our logs. Type in:

SecurityEvent
| where EventID == 4624

This query will get the Event ID of 4624 allowing you will fetch all of the successful logon events.

3. Click on Run.

The results will show all of the logs with the event ID of 4624.

You can also filter the output to the specified columns. For example, you might only want to display the Time Generated, Computer, Account, Event Source Name and Activity. You can do this with the project command.

SecurityEvent
| where EventID == 4624 
| project TimeGenerated, Computer,Account, EventSourceName, Activity

MITRE ATT&CK

The MITRE ATT&CK framework is knowledge base with a collection of attacks and techniques that a threat actor will use to exploit an environment. Organizations can use these to help classify and identify attacks and assess an organizations risk.

The threat that you will be emulated in this lab is TA0003 Persistence. Persistence refers to the ability of a malicious actor to maintain a presence or access on a compromised system over an extended period.

You can visit the official MITRE ATT&CK page to get a detailed understanding of the Tactics & Techniques used by malicious actors.

https://attack.mitre.org/tactics/TA0003/

The technique you will be emulating is T1053 Scheduled Task/ Job. Essentially, MITRE ATT&CK defines it as malicious task that runs on an action or timely bases on the targets machine.

If you go the sub categories explaining how T1053 can be executed, .005 stats that Windows Task Scheduler may be used to execute malicious code on the victims Windows Machine.

Detection: Monitoring the Event IDs can identify scheduled task activity. Along with Event ID 4698, which is what you will be utilizing in this lab, MITRE also recommends the other IDs for detection.

Mitigation: MITRE ID M1018 User Account Management states that the creation of scheduled tasks should only be limited to authorized admins.

Enable Scheduled tasks Logging

You need to enable Scheduled tasks Logging so that Event Viewer can log scheduled Tasks. The event ID for it is 4698.

  1. Open Local Security Policy on your VM.
  2. Advanced Audit Policy Configuration > System Audit Policies — Local Group > Object Access > Audit Other Object Access Events > Checkbox Configure the following audit events > checkbox Success and Failure > Apply.

Create Scheduled tasks

  1. Open Task Scheduler.
  2. Create Task.
  3. Give it a name > click on Triggers > New > This section allows us to set when and how you want the task to run. Set the time to 2–5 minute after the current time for testing purposes. Note: Attackers can get creative with the this section such as running it on startup and even idle.

4. Under Actions > click New > Browse > iexplore.exe > click OK. Now when the specified time is reached, it will open Internet Explorer. This will act as a non-malicious threat.

5. If you go back to Event Viewer, you will see a log with the event ID 4698 has been created. At the specified time, internet explorer should also open.

6. Go back to your logs in Microsoft Sentinel and change to event ID value to 4698. Then click on the drop down in the results.

Here you can get more information about the event such as username,task name, and task content.

The problem with this query is that you have to go into the events and look through the large amounts of information if you want to discover something. In order to make this easier, type in this query.

SecurityEvent                             
 | where EventID == 4698
 | parse EventData with * '<Data Name="SubjectUserName">' User '</Data>' *
 | parse EventData with * '<Data Name="TaskName">' NameofSceuduledTask '</Data>' *
 | parse EventData with * '<Data Name="ClientProcessId">' ClientProcessID '</Data>' *
 | project Computer, TimeGenerated, ClientProcessID, NameofSceuduledTask, User

The parse command is used to extract relevant data from the EventData field. In this query, it extracts the SubjectUserName, TaskName, and ClientProcessId. With this extracted data, you can then assign it under new categories such as User, NameofScheduledTask, and ClientProcessID as shown above. Putting in into your own category allows you to present the information in a more structured and meaningful format for readability.

Creating an analytic rule

Next you will want to create an analytic rule:

An analytic rule alerts you when a specified event condition is met in your environment. The incidents generated from these alerts allows analysts to investigate and gain prior information about the incident before responding.

  1. Go into Analytics in Microsoft Sentinel workspace > Create > Scheduled Query Rule.

Here you will give the rule a name, description, severity, and the tactics and techniques from the MITRE ATT@CK framework.

2. Give it a name and a description that is related to the rule you want to create. This is important so that its easy for the analyst to identify the rule.

3. Set the tactics and techniques to persistence and its sub class Scheduled Task/Job. Keep the Severity as medium and keep the rule as enabled.

4. Go to the Set rule logic Tab. In the Rule Query, paste the previous query in the log:

SecurityEvent                             
 | where EventID == 4698
 | parse EventData with * '<Data Name="SubjectUserName">' User '</Data>' *
 | parse EventData with * '<Data Name="TaskName">' NameofSceuduledTask '</Data>' *
 | parse EventData with * '<Data Name="ClientProcessId">' ClientProcessID '</Data>' *
 | project Computer, TimeGenerated, ClientProcessID, NameofSceuduledTask, User

This is the script logic that will be used to identify whether a Scheduled Task has been created through identifying the Event ID.

Next, you will need to add Entity Mapping. It allows you to recognize and classify the data in the appropriate field. This allows you to give the analyst the necessary information they need to start an investigation. For example, if you set the event mapping to give the host name, when the alert goes off, the analyst can know the host name before starting an investigation by seeing the host name recorded in the SIEM.

5. Use the above settings for entity mapping.

Query Scheduling is how often the rule runs and how long it should look up data from.

6. Both are set for 5 minutes on default which is good for the sake of this lab.

7. The alert threshold is the number of times the event needs to occur before it gives an alert. You want it to alert you every time so by default it is greater than 0.

8. Next, you will need to checkbox Trigger an alert for each event. This way, it wont group all of the events into a single alert but rather you will get an alert each time the event occurs.

In this lab, you will not be doing anything in the Automated Response tab. This section allows you to utilize the Security Orchestration, Automation, and Response(SOAR) approach. This allows you to automate tools and processes to increase efficiency in incident detection, analysis, and response. For example, when the SIEM generates an alert, SOAR can further analyze that alert such as assessing the priority of the alert and determining an appropriate level of response.

9. Finish up the rule by clicking Review + create > Save.

Creating more Scheduled Tasks

  1. In order to test this rule, lets create two more scheduled tasks. (Note: Refer to the section “Create Scheduled tasks” above.)

2. In order to see this alert, you must go into the Incidents section in Microsoft Sentinel. You might not see it initially because of the query scheduling rule set for 5 minutes. When the set time limit is reached, the SIEM will retrieve and log the data.

3. Typically, these alerts would be assigned to specific individuals or groups so they can investigate it. To do this, click on one of the alerts. On the right, you can change the Owner, Status, and Severity of the alert.

You can also see the entity mapping information that will be useful for the analyst before they start further investigation such the user account, host machine, the name of the scheduled task, and the process ID of the task.

The analyst would then further investigate the above entities with different tools such as an EDR solution to decide whether it is a threat or a false positive.

Thank you for reading. Hope it helps.