After Lab 4.6 — Recap
After Lab 4.6 — Recap
You created an analytics rule that detects direct internal backend access, simulated the attack traffic that triggers it, and investigated the resulting incident using the core 7-step workflow. You understand the transition from manual KQL investigation to automated detection and incident response.
What You Should Understand
Analytics Rules — From Query to Alert
Analytics rules are the bridge between manual investigation and automated detection. A KQL query finds data. An analytics rule runs that query automatically on a schedule. When it matches, it creates an incident.
The Incident Investigation Workflow
| Step | Action | What to Look For |
|---|---|---|
| 1 | Review alert | Confirm the incident is not a false positive |
| 2 | Identify source IP | What IP accessed the internal backend? |
| 3 | Correlate with SDK data | Check Application Insights for same IP across all services |
| 4 | Determine if IP is internal/external | Is the IP in RFC 1918 ranges? |
| 5 | Check for additional requests | Same IP, different time periods or endpoints? |
| 6 | Assess impact | What data was accessed? Any exfiltration? |
| 7 | Determine next actions | Block IP, review NSG, check private endpoints |
Analytics Rule Properties
| Property | Description | Example |
|---|---|---|
| Name | Human-readable rule name | "Direct access to internal backend" |
| Description | What the rule detects | "Detects external IP accessing the internal backend API" |
| Severity | High, Medium, Low, Information | High |
| Tactics | MITRE ATT&CK tactic | InitialAccess, LateralMovement |
| Techniques | MITRE ATT&CK technique | T1021.004, T1190 |
| Query | KQL query | See query in lab |
| Schedule | How often the query runs | Every 5 minutes |
| Time window | How far back the query looks | Last 5 minutes |
Reflection Questions
Why does the analytics rule look back only 5 minutes when it runs every 5 minutes? What would happen if the look-back window was 1 hour instead?
The look-back window must be at least as long as the run interval to avoid gaps. If the rule runs every 5 minutes with a 5-minute look-back, it covers the entire period since the last run. A longer look-back (e.g., 1 hour) would catch events that occurred between scheduled runs but increases query cost and may produce duplicate incidents for overlapping windows.
The incident was created with severity "High". What factors determine the severity of an incident?
Severity is a human decision based on what the rule detects — not automatically determined by the data. A High severity reflects that external access to an internal backend is a serious security concern. The same rule could be Medium if it only triggered for internal IPs, or Low if it was testing a non-critical endpoint.
An attacker's IP is identified in the incident. What are the possible next steps after identifying the attacker's IP? List at least four response actions, ordered by priority.
- Block the IP at NSG level (immediate containment)
- Review access restrictions on internal backend (ensure VNet integration is correctly configured)
- Check Key Vault audit logs (verify no secrets were accessed)
- Review Azure Activity Log (check for resource changes by the attacker)
- Rotate credentials if needed (if secrets or keys may have been exposed)
- Document findings and update playbooks (improve future response)
The MITRE ATT&CK tactics for this rule are InitialAccess and LateralMovement. Why are both tactics assigned?
InitialAccess applies because the attacker accessed the internal backend from outside — gaining entry to a resource not directly exposed to the internet. LateralMovement applies because accessing an internal service often implies the attacker has already compromised another system or is trying to move deeper into the environment. The dual assignment reflects that this single event can be both an entry point and a lateral movement step depending on context.
Bridge to Challenge
You have completed all 6 labs for Day 4. The final challenge asks you to bring everything together — build your own monitoring dashboard, review coverage across all nine data sources, and design an analytics rule based on something you observed during the day's exercises.