Stage III - Working Incidents and Incident Response
Next, investigate and work the incidents being generated within Azure Sentinel, in accordance with the NIST 800-61 Incident Management Lifecycle.
Step 1: Preparation
We initiated this already by ingesting all of the logs into Log Analytics Workspace and Sentinel and configuring alert rules.
Step 2: Detection & Analysis
- Set Severity, Status, Owner
- View Full Details
- Observe the Activity Log
- Observe Entities and Incident Timelines
- “Investigate” the incident and continue trying to determine the scope
- Inspect the entities and see if there are any related events
- Determine legitimacy of the incident
- If True Positive, continue, if False positive, close it out
Step 3: Containment, Eradication, and Recovery
Use this simple Incident Response PlayBook to remediate the incident.
Step 4: Post-Incident Activity
Document Findings and Close out the Incident in Sentinel
Incident 1 - Brute Force Success (Windows)
Incident Description
This incident involves observation of potential brute force attempts against a Windows VM.
Initial Response Actions
- Verify the authenticity of the alert or report.
- Immediately isolate the machine and change the password of the affected user
- Identify the origin of the attacks and determine if they are attacking or involved with anything else
- Determine how and when the attack occurred
- Are the NSGs not being locked down? If so, check other NSGs
- Assess the potential impact of the incident.
- What type of account was it? Permissions?
Detection & Analysis
Set Severity, Status, Owner
View Full Details
Observe the Activity Log
Nothing to show here.
Observe Entities and Incident Timelines
“Investigate” the incident and continue trying to determine the scope
Inspect the entities and see if there are any related events
The entity is involved with other Brute Force attempts during the same period.
Determine legitimacy of the incident
Determined to be a legitimate incident.
If True Positive, continue, if False positive, close it out
Determined to be a true positive. From the investigation you can see that the Attacker/Entity "63.143.47.155" is also involved in 4 other brute force attempt instances.
Containment, Eradication, and Recovery
I will address these sections later (in the environment hardening section), but am including the steps here from the Incident Response Playbook for reference.
- Lock down the NSG assigned to that VM/Subnet, either entirely, or to allow only necessary traffic
- Reset the affected user’s password
- Enable MFA
Post-Incident Activity
Document Findings and Close out the Incident in Sentinel.
Check out the Lessons Learned section for more details on this incident.
Incident 2 - Possible Privilege Escalation (Azure Key Vault Critical Credential Retrieval or Update)
Incident Description
This incident involves the unexpected reading of a critical secret from the organization's Key Vault.
Initial Response Actions
- Verify the authenticity of the alert or report.
- Identify the secret that was read and the user or application that read it.
- Determine how and when the secret was read.
- Assess the potential impact of the incident.
Detection & Analysis
View Full Details with Severity, Status, Owner
Investigate & Observe Entities and Incident Timelines
Containment, Eradication, and Recovery
None. This was me viewing key vault secrets at work. I'm authorized to do this. I don't think there is anything wrong with the rule logic here, just happened to be a legitimate and authorized incident-generating event.
Post-Incident Activity
Document Findings and Close out the Incident in Sentinel
Incident 3 - Brute Force SUCCESS - Azure Active Directory
Incident Description
This incident involves observation of potential brute force success against Azure Active Directory.
Initial Response Actions
- Verify the authenticity of the alert or report.
- Immediately identify and Revoke Sessions/Access for affected user
- Identify the origin of the attacker and determine if they are attacking or involved with anything else
- Assess the potential impact of the incident.
- What type of account was it?
- What Roles did it have?
- How long has it been since the breach went unattended?
Detection & Analysis
Investigate & Observe Entities and Incident Timelines
Containment, Eradication, and Recovery
- Reset the affected user’s password and Roles if applicable
- Enable MFA
- Consider preventing any logins from outside the US with Conditional Access
Post-Incident Activity
Document Findings and Close out the Incident in Sentinel.
This is another false positive. It could have been multiple login attempts with the incorrect password or MFA code. I recognize this IP from work, although, I'm not entirely sure how 35 events were produced - perhaps restoring multiple browser tabs simultaneously? MFA is already enabled on the user's account, and the logins occurred from an expected IP.
Incident 4 - Brute Force ATTEMPT - Linux Syslog
Incident Description
This incident involves observation of potential brute force attempts against a Linux VM.
Initial Response Actions
- Verify the authenticity of the alert or report.
- Immediately isolate the machine and change the password of the affected user
- Identify the origin of the attacks and determine if they are attacking or involved with anything else
- Determine how and when the attack occurred
- Are the NSGs not being locked down? If so, check other NSGs
- Assess the potential impact of the incident.
- What type of account was it? Permissions?
Detection & Analysis
Investigate & Observe Entities and Incident Timelines
Containment and Recovery
Lock down the NSG assigned to that VM/Subnet, either entirely, or to allow only necessary traffic
Post-Incident Activity
Document Findings and Close out the Incident in Sentinel.
There are 6 entities (218.92.0.118, 151.80.184.123, 123.49.33.102, 43.134.54.244, 43.156.227.146, 165.22.62.136), attacking this linux virtual machine, with no successful attempts. There is a total of 30 events grouped into 5 alerts. Suspected overexposure to the public internet.
