Listen to this Post
Introduction:
Microsoft Defender XDR’s introduction of the `IdentityAccountInfo` table is a paradigm shift for proactive identity security, providing unprecedented visibility into password hygiene and account sensitivity. This new data source allows security teams to move beyond reactive alerts and towards a continuous assessment of their identity attack surface, specifically targeting weak password practices that are a primary vector for breaches.
Learning Objectives:
- Master the structure and key fields of the `IdentityAccountInfo` table for Advanced Hunting.
- Build and customize KQL queries to identify stale passwords and unsecured sensitive accounts.
- Implement automated workflows and hardening policies based on query findings to mitigate identity risk.
You Should Know:
- Decoding the IdentityAccountInfo Table: Your New Security Treasure Map
The `IdentityAccountInfo` table is a goldmine for identity-focused defenders. It provides a near-real-time inventory of your identities (users, service accounts) enriched with critical attributes not previously aggregated in Advanced Hunting. The most significant fields includeLastPasswordChangeTime, `Sensitivity` (e.g., Normal, Sensitive, HighlySensitive),AccountDomain, andAccountName. This table is populated by Microsoft Defender for Identity sensors and integrates seamlessly with other Defender XDR tables like `IdentityLogonEvents` andAlertInfo.
Step‑by‑step guide:
First, explore the table’s schema to understand available data.
// Preview the IdentityAccountInfo table structure and sample data IdentityAccountInfo | take 10 | project AccountUpn, AccountDisplayName, Sensitivity, LastPasswordChangeTime, AccountDomain
This foundational query helps you verify data ingestion and see the key attributes for your identities. The `LastPasswordChangeTime` is crucial; it’s stored in UTC, enabling precise calculations of password age.
- Hunt for Stale Passwords: The KQL Query That Finds Aging Credentials
Passwords that never change are a severe security risk. Using the `LastPasswordChangeTime` field, you can identify accounts with passwords older than your organizational policy (e.g., 90 days). This is a direct measure of poor security hygiene.
Step‑by‑step guide:
Build a query to flag accounts with passwords exceeding a defined age threshold.
// Identify accounts with passwords older than 90 days
IdentityAccountInfo
| where isnotempty(LastPasswordChangeTime)
| extend PasswordAgeDays = datetime_diff('day', LastPasswordChangeTime, now())
| where PasswordAgeDays > 90
| project AccountUpn, AccountDisplayName, Sensitivity, LastPasswordChangeTime, PasswordAgeDays, AccountDomain
| sort by PasswordAgeDays desc
This query calculates the difference in days between the last change and the current time. Filter and sort to prioritize the oldest passwords. Consider extending the `where` clause to `PasswordAgeDays > 90 or isempty(LastPasswordChangeTime)` to also catch accounts with no recorded change.
- Pinpoint High-Value Targets: Correlating Sensitivity with Password Age
A stale password on a normal user account is bad; on a “HighlySensitive” account, it’s catastrophic. The `Sensitivity` field allows you to perform risk-based prioritization. Combine sensitivity with password age to create a true criticality heat map.
Step‑by‑step guide:
Layer the `Sensitivity` field into your hunt for stale passwords.
// Find sensitive & highly sensitive accounts with old passwords
IdentityAccountInfo
| where Sensitivity in ("Sensitive", "HighlySensitive")
| where isnotempty(LastPasswordChangeTime)
| extend PasswordAgeDays = datetime_diff('day', LastPasswordChangeTime, now())
| where PasswordAgeDays > 90 // Or use a stricter policy like > 30 days for sensitive accounts
| project AccountUpn, Sensitivity, LastPasswordChangeTime, PasswordAgeDays, AccountDomain
| sort by Sensitivity, PasswordAgeDays desc
This query enables you to focus remediation efforts on the accounts where a credential compromise would cause the most business damage.
- Enrich Findings with Logon Data: From Inventory to Active Risk
Static inventory is useful, but combining it with activity data reveals true exposure. Join `IdentityAccountInfo` with the `IdentityLogonEvents` table to see if accounts with stale passwords are actively being used, and from what devices or locations.
Step‑by‑step guide:
Create an enriched query that shows active use of vulnerable accounts.
// Find active logons for sensitive accounts with old passwords
let StaleSensitiveAccounts = IdentityAccountInfo
| where Sensitivity in ("Sensitive", "HighlySensitive")
| where isnotempty(LastPasswordChangeTime)
| extend PasswordAgeDays = datetime_diff('day', LastPasswordChangeTime, now())
| where PasswordAgeDays > 90
| project AccountObjectId, AccountUpn, Sensitivity, PasswordAgeDays;
IdentityLogonEvents
| where Timestamp > ago(7d)
| join kind=inner StaleSensitiveAccounts on AccountObjectId
| project Timestamp, AccountUpn, Sensitivity, PasswordAgeDays, DeviceName, Application, Country
| sort by Timestamp desc
This join operation contextualizes your inventory data, showing you not just which accounts are vulnerable, but which are actively at risk based on recent authentication events.
- Harden Your Environment: Enforcing Password Policies on Windows & Linux
KQL identifies the problem; system policies fix it. For Windows domains, enforce password expiration via Group Policy (gpedit.msc). Navigate toComputer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy. Set “Maximum password age” to your standard (e.g., 90 days). Apply with `gpupdate /force` on domain controllers.
For Linux, enforce password aging using the `chage` command. To set a 90-day maximum password age for a user:sudo chage -M 90 <username>. To view current settings:sudo chage -l <username>. Integrate these settings into your provisioning scripts or configuration management tools like Ansible or Puppet. -
Automate Remediation: Building a Sentinel Playbook for Proactive Defense
Manual review doesn’t scale. Use Azure Logic Apps within Microsoft Sentinel to automate response. Create a scheduled analytics rule that runs your core KQL query (from section 3) periodically. For each incident triggered (representing a stale, sensitive account), a Logic App playbook can:
1. Fetch the account details.
- Look up the manager/owner in Azure AD via the Microsoft Graph API.
- Send a tailored notification via email or Teams, requesting a password change.
-
Optionally, create a ticket in your ITSM system (ServiceNow, Jira).
This closes the loop from detection to actionable remediation task without analyst intervention. -
Secure the Foundation: API Security for Your Identity Data
The power of `IdentityAccountInfo` is accessed via the Advanced Hunting API. Secure this critical data pipeline. Always use the principle of least privilege when granting API permissions to applications. In Azure AD, register your app and grant only the `AdvancedHunting.Read.All` scope for read operations. Use certificate-based authentication instead of secrets for daemon apps. Always embed API calls within a secure, server-side function (like an Azure Function) rather than client-side scripts, and ensure all traffic is encrypted via TLS 1.2+.
What Undercode Say:
- Visibility is Control: The `IdentityAccountInfo` table transforms password security from an opaque policy hope into a measurable, queryable security control. You cannot manage what you cannot measure.
- Proactivity Beats Reactivity: This tool shifts the focus from responding to password spray alerts to preventing the conditions that make sprays successful. It enables a preventative security posture centered on continuous compliance.
The introduction of `IdentityAccountInfo` represents Microsoft doubling down on identity as the new perimeter. By baking these critical attributes directly into the hunting schema, they are empowering defenders to treat identity metadata with the same seriousness as network logs or endpoint process trees. The true power isn’t in a single query, but in the ability to weave this data into a comprehensive identity threat detection and response (ITDR) strategy. It forces a conversation about password policies that are often set and forgotten, providing the data needed to justify stricter controls or investment in phishing-resistant authentication for high-sensitivity accounts.
Prediction:
The `IdentityAccountInfo` table is a precursor to a more AI-driven, predictive identity security model within Defender XDR. We predict Microsoft will soon leverage this foundational data, combined with behavioral signals, to power risk-based authentication challenges automatically. For example, a logon attempt for a “HighlySensitive” account with a 200-day-old password, originating from a new location, could trigger a step-up authentication requirement without any manual rule configuration. Furthermore, expect this data to feed into Copilot for Security, allowing natural language prompts like “Show me all sensitive service accounts with non-expiring passwords” and receiving not just the list, but also automated, reasoned remediation steps. This evolution will make identity security posture management an integral, automated component of the larger XDR narrative.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Verboonalex Exploring – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
