Learning Path 7 - Lab 1 - Exercise 7 - Create Detections

Lab scenario

You are a Security Operations Analyst working at a company that implemented Microsoft Sentinel. You are going to work with Log Analytics KQL queries and from there, you will create custom analytics rules to help discover threats and anomalous behaviors in your environment.

Analytics rules search for specific events or sets of events across your environment, alert you when certain event thresholds or conditions are reached, generate incidents for your SOC to triage and investigate, and respond to threats with automated tracking and reMediation processes.

Task 1: Attack 1 Detection with Defender for Endpoint

In this task, you will create a detection for Attack 1 on the host (Win1) with the Microsoft Defender for Endpoint configured.

  1. In the Microsoft Sentinel portal, select Logs from the General section in case you navigated away from this page.

  2. Run the following KQL Statement again to recall the tables where we have this data:

     search "temp\\startup.bat"
    
  3. This detection will focus on data from Defender for Endpoint. Run the following KQL Statement:

     search in (Device*) "temp\\startup.bat"
    
  4. The table DeviceRegistryEvents looks to have the data already normalized and easy for us to query. Expand the row to see all the columns related to the record.

    Important: If you do not see the DeviceRegistryEvents table in the results, an alternative for the following two queries is to use the DeviceProcessEvents table as replacement. Being that said, use one of the two provided examples below, depending on the table you see in the previous query.

  5. From the results, we now know that the Threat Actor is using reg.exe to add keys to the Registry key and the program is located in C:\temp. Run the following statement to replace the search operator with the where operator in our query:

     DeviceRegistryEvents | where ActionType == "RegistryValueSet"
     | where InitiatingProcessFileName == "reg.exe"
     | where RegistryValueData startswith "c:\\temp"
    

    Alternatively, you can Run the following KQL query using the DeviceProcessEvents table:

     DeviceProcessEvents | where ActionType == "ProcessCreated"
     | where FileName == "reg.exe"
     | where ProcessCommandLine contains "c:\\temp"
    
  6. It is important to help the Security Operations Center 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:

     DeviceRegistryEvents
     | where ActionType == "RegistryValueSet"
     | where InitiatingProcessFileName == "reg.exe"
     | where RegistryValueData startswith "c:\\temp"
     | extend timestamp = TimeGenerated, HostCustomEntity = DeviceName, AccountCustomEntity = InitiatingProcessAccountName
    

    Screenshot

    Alternatively, you can Run the following KQL query using the DeviceProcessEvents table:

     DeviceProcessEvents | where ActionType == "ProcessCreated"
     | where FileName == "reg.exe"
     | where ProcessCommandLine contains "c:\\temp"
     | extend timestamp = TimeGenerated, HostCustomEntity = DeviceName, AccountCustomEntity = InitiatingProcessAccountName
    
  7. Now that you have a good detection rule, in the Logs window, select the + New alert rule in the command bar and then select Create Microsoft Sentinel alert. This will create a new Scheduled rule. Hint: You might need to select the ellipsis (…) button in the command bar.

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

    Setting Value
    Name MDE Startup RegKey
    Description MDE Startup Regkey in c:\temp
    Tactics Persistence
    Severity High
  9. Select Next: Set rule logic > button.

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

  11. For Query scheduling set the following:

    Setting Value
    Run Query every 5 minutes
    Look data from the last 1 Day

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

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

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

  14. For the Automated response tab select the PostMessageTeams-OnAlert under Alert automation (classic) and then select Next: Review button.

  15. On the Review tab, select the Create button to create the new Scheduled Analytics rule.

Task 2: Attack 2 Detection with SecurityEvent

In this task, you will create a detection for Attack 2 on the host (Win2) with the Security Events connector installed.

  1. In the Microsoft Sentinel portal, select Logs from the General section in case you navigated away from this page.

  2. Run the following KQL Statement to identify any entry that refers to administrators:

     search "administrators" | summarize count() by $table
    
  3. 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"
    
  4. 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
    

    Screenshot

    Note: This KQL might not return the expected results because of the small dataset used in the lab.

  5. 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
    
  6. 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.

  7. 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
  8. Select Next: Set rule logic > button.

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

  10. For Query scheduling set the following:

    Setting Value
    Run Query every 5 minutes
    Look data from the last 1 Day

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

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

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

  13. For the Automated response tab select the PostMessageTeams-OnAlert under Alert automation (classic) and then select Next: Review button.

  14. On the Review tab, select the Create button to create the new Scheduled Analytics rule.

Proceed to Exercise 8