Exercise overview

You’re a Security Operations Analyst working at a company that implemented Microsoft Sentinel. You must learn how to detect and mitigate threats using Microsoft Sentinel. After connecting your data sources to Microsoft Sentinel, you create custom analytics rules to help discover threats and anomalous behaviors in your environment.

Threat hunting queries enable and empower SOC analysts to proactively monitor and investigate potential attacks as they are developing or before they happen. Hunting within Microsoft Sentinel allows for queries that are similar to analytic rules be used to audit the environment for potentially malicious activities while allowing analysts to escalate results to incidents if needed. Sometimes, hunting threats may require data that goes beyond the retention of the analytics (hot) tier, this is where features like Search/Restore jobs can be used to ensure that the SOC has the data it needs.

Exercise instructions

Task 1: Perform a simulated priviledge escalation attack

In this task, you will perform a simulated attack on the VM1 Azure virual machine.

1. In the Edge browser, navigate to the Azure portal at https://portal.azure.com.

2. Type Virtual machines in the search bar and select Virtual machines.

3. Select the VM1 virtual machine.

4. In the left navigation menu, expand the Operations section and select Run command.

5. In the Run command pane, select RunPowerShellScript.

6. In the PowerShell script box, clear any previous commands, then copy and run these commands to simulate the creation of an Admin account. Remember to press Enter after the last row::

    net user theusernametoadd /add
    net user theusernametoadd ThePassword1!
    net localgroup administrators theusernametoadd /add
   

7. Monitor the Output section to verify the commands completed successfully.

Task 2: Create KQL hunting queries

In this task, you will create a hunting query and bookmark a result.

1. Log in to WIN1 virtual machine as Admin with the password: Pa55w.rd.

2. In the Edge browser, navigate to the Azure portal at https://portal.azure.com.

3. In the Sign in dialog box, copy and paste in the Tenant Email account provided by your lab hosting provider and then select Next.

4. In the Enter password dialog box, copy and paste in the Tenant Password provided by your lab hosting provider and then select Sign in.

5. In the Search bar of the Azure portal, type Sentinel, then select Microsoft Sentinel.

6. Select your Microsoft Sentinel Workspace.

7. Select Logs

8. Enter and Run the following KQL Statement in the New Query 1 space:

   Important: You may want to paste the KQL queries into Notepad first, and then copy from there to the New Query 1 Log window to avoid any errors.

    search "administrators" 
    | summarize count() by $table
   

   Note: A result with the event might take up to 5 minutes to appear. Wait until it does.

9. The result might show events from different tables, but in our case, we want to investigate the SecurityEvent table. The EventID and Event that we are looking is “4732 - A member was added to a security-enabled local group”. With this, we will identify adding a member to a privileged group. Run the following KQL query to confirm:

    SecurityEvent 
    | where EventID == 4732
    | where TargetAccount == "Builtin\\Administrators"
   

10. Expand the row to see all the columns related to the record. The username of the account added as Administrator does not show. The issue is that instead of storing the username, we have the Security IDentifier (SID). Run the following KQL to match the SID to the username that was added to the Administrators group:

     SecurityEvent 
     | where EventID == 4732
     | where TargetAccount == "Builtin\\Administrators"
     | extend Acct = MemberSid, MachId = SourceComputerId  
     | join kind=leftouter (
         SecurityEvent 
         | summarize count() by TargetSid, SourceComputerId, TargetUserName 
         | project Acct1 = TargetSid, MachId1 = SourceComputerId, UserName1 = TargetUserName) on $left.MachId == $right.MachId1, $left.Acct == $right.Acct1
    

11. Extend the row to show the resulting columns, in the last one, we see the name of the added user under the UserName1 column we project within the KQL query. It is important to help the Security Operations Analyst by providing as much context about the alert as you can. This includes projecting Entities for use in the investigation graph. Run the following query:

     SecurityEvent 
     | where EventID == 4732
     | where TargetAccount == "Builtin\\Administrators"
     | extend Acct = MemberSid, MachId = SourceComputerId  
     | join kind=leftouter (
         SecurityEvent 
         | summarize count() by TargetSid, SourceComputerId, TargetUserName 
         | project Acct1 = TargetSid, MachId1 = SourceComputerId, UserName1 = TargetUserName) on $left.MachId == $right.MachId1, $left.Acct == $right.Acct1
     | extend timestamp = TimeGenerated, HostCustomEntity = Computer, AccountCustomEntity = UserName1
    

12. Now that you have a good detection rule, in the Logs window, select + New alert rule in the command bar and then select Create Microsoft Sentinel alert. Hint: You might need to select the ellipsis (…) button in the command bar.

13. This starts the “Analytics rule wizard”. For the General tab type:

    Setting	Value
    Name	SecurityEvent Local Administrators User Add
    Description	User added to Local Administrators group
    Tactics	Privilege Escalation
    Severity	High

14. Select Next: Set rule logic > button.

15. On the Set rule logic tab, the Rule query should be populated already with you KQL query, as well the entities under Alert enhancement - Entity mapping.

    Entity	Identifier	Data Field
    Account	FullName	AccountCustomEntity
    Host	Hostname	HostCustomEntity

16. If Hostname isn’t selected for Host Entity, select it from the drop-down list and use the parameters in the preceding table to populate the fields.

17. For Query scheduling set the following:

    Setting	Value
    Run Query every	5 minutes
    Lookup data from the last	1 Days

    Note: We are purposely generating many incidents for the same data. This enables the Lab to use these alerts.

18. Leave the rest of the options with the defaults. Select Next: Incident settings> button.

19. For the Incident settings tab, leave the default values and select Next: Automated response > button.

1. 1. On the Automated response tab select the Next: Review and create > button.
2. On the Review and create tab, select the Create button to create the new Scheduled Analytics rule.