Massive Azure/Entra ID Exfiltration Campaign: 1.4 Million Employee Records Reportedly Listed for Sale via Leaked Credentials
By ScruteX Published Updated
Between 1 and 10 August 2026, a single seller on BreachForums posted six listings advertising internal employee directories pulled from Microsoft Entra ID tenants. The claimed total runs past 1.4 million records. Four of the six named organisations are technology service providers, and roughly 86 per cent of the claimed records come from that group alone. Tata Consultancy Services has since told the BSE that the data referenced in the alerts appears to be more than four years old, and that it has found no credible evidence of a breach of its systems.
TCS breach status: TCS says it has found no credible evidence of a breach and believes the referenced data is more than four years old. The 800,000+ figure is the seller's claim and has not been independently verified.
That response matters. It also does not close the question this campaign raises.
Entra ID directory enumeration is the act of reading a Microsoft Entra ID tenant's users, groups, and group memberships through an authenticated session, using read permissions that ordinary member accounts hold by default. It requires no exploit, no privileged role, and no malware on a server. One working credential is the entire entry cost. That is the part of this story worth your attention, whether or not any of these six datasets turn out to be genuine.
This analysis covers what was listed, what the named companies have said, why the field schema points at a directory read rather than an HR breach, the permission model that makes it possible, and the detection and hardening work that follows.
What was listed, and when
Six sale threads went up under one handle, TheHatman, on BreachForums between 1 and 10 August 2026. Each advertises an internal employee directory the seller says was pulled from the target's Azure or Entra tenant using compromised credentials. Every figure below is the seller's own claim.
| Date posted | Organisation | Sector | Claimed records | Claimed fields |
|---|---|---|---|---|
| 10 Aug | Tata Consultancy Services | IT services (India) | 800,000+ | Name, employee ID, email, title, department, phone, address |
| 08 Aug | HCLTech | IT services (India) | 250,000+ | Name, email, title, department, phone, address |
| 02 Aug | InterContinental Hotels Group | Hospitality (UK) | 185,000+ | Plus manager, direct reports, group membership |
| 01 Aug | Kyndryl | IT infrastructure (US) | 170,000+ | Employee, service, and other tenant account records |
| 02 Aug | Hexaware Technologies | IT services (India) | 20,000+ | Plus manager, direct reports, group membership |
| 02 Aug | Wyndham Hotels | Hospitality (US) | 9,000+ | Plus manager, direct reports, group membership |
| Six listings, ten days | 1,434,000+ | Claimed total |
All six threads sit in one seller subforum under a single member account, with thread IDs running in near-sequence. Four of the six carry a proof sample: 2,200 records for Kyndryl, 1,500 for Hexaware, 6,000 for TCS, 7,500 for HCLTech. That is roughly 17,200 records given away free to establish credibility, against 1.43 million advertised. The IHG and Wyndham threads were posted without a sample.
The same listings run on more than one forum
The TCS and HCLTech listings do not sit on one board. Both were reposted, near-identically, to at least one other leak forum, and the TCS listing to three.
This matters for anyone who ends up on the receiving end. Getting a thread removed from one forum leaves the same data advertised elsewhere, so takedown has to run in parallel across every board carrying the listing rather than sequentially. It also raises the cost of monitoring, since watching a single well-known forum no longer gives coverage. Cross-posting for the remaining four listings is unverified rather than ruled out.
The wording changed halfway through, and that matters
The four posts from 1 and 2 August say the data came from the "Azure/Entra portal". The two later posts, HCLTech and TCS, say "Azure Tenant".
The drift tracks the field schema. Three of the four "portal" listings (IHG, Wyndham, Hexaware) advertise manager, direct reports, and user group membership, which are the attributes an Entra admin centre user detail page surfaces. The fourth, Kyndryl, lists no fields at all, only record types. The two "tenant" listings drop those three relationship attributes and add department instead.
Either the seller changed vocabulary while running one method, in which case this tells you nothing, or the earlier exports came through the portal interface and the later ones through a scripted path with a different default column set. ScruteX assesses the second as plausible but unconfirmed. Confidence: low.
If it holds, it matters operationally: portal and Graph enumeration leave different traces, and a detection programme built for one will miss the other.
Who is TheHatman? What we know about the seller
Almost nothing, and that is itself an observation worth recording.
TheHatman is a persona, not an identity. The account is new, carries no forum reputation score, and has no vouched escrow history behind any of the six sales. ScruteX makes no attribution to any known group, nation state, or prior alias, and we have found no tradecraft overlap that would support one. What follows is a behavioural profile built only from what the account has done in public.
| Attribute | Observation | Confidence |
|---|---|---|
| Handle | TheHatman | High |
| Account age | New at time of first listing (1 Aug 2026) | High |
| Forum standing | Lowest member tier. Reputation score of zero, minimal forum credit balance, no escrow-vouched sales | High |
| Posting venue within the forum | The seller marketplace subforum. Thread IDs run in near-sequence across the ten days | High |
| Role | Data broker or access-to-data seller, not a ransomware affiliate | Medium |
| Contact channels | Session and Tox on the first listing; Jabber added from the second onward. Identical strings thereafter. No Telegram presence observed. | High |
| Proof-of-access model | Partial CSV sample per thread, hosted on a single anonymous file service. Sample sizes 1,500 to 7,500 records, between 0.75 and 7.5 per cent of the claimed total. Consistent filename convention across listings. | High |
What the behaviour pattern suggests
A specialist, not an opportunist. Generalist brokers post mixed inventory: customer tables, health records, credential combos. This account posted directory exports and nothing else, six times, from one platform, with one schema. That is a method being run through a target list. The volume ramp fits the same reading: 170,000 to 800,000 across ten days with the biggest name last, which is either credibility-building before a headline sale or ongoing access worked outward from smaller tenants.
A broker, not an extortionist. No victim was contacted before listing, no countdown, no leak site. That places the actor a layer below ransomware in the criminal economy, and brokers at that layer sell to affiliates who do the intrusion later. A directory export surfacing in August can precede an attempt in October against the same organisation or one of its clients.
The invitation to name targets is the line to sit with. An actor offering to fetch whatever company a buyer names is either inflating perceived capability or holds a method they consider repeatable against arbitrary tenants. Since the method described works against a documented default, the second cannot be ruled out on technical grounds.
Zero replies across all six threads does not contradict any of this. On a forum where reputation is currency, public silence looks like failure, but the seller pushed every serious conversation to encrypted messaging in the first line of each post. What the silence actually removes is the one authenticity signal defenders would otherwise get from forum reaction.
Three things we are deliberately not saying
No country of origin. Posting hours and language patterns across six posts do not support geolocation, and a published guess would be worse than silence.
No link to Scattered Spider, UNC3944, or any tracked cluster. Those groups appear later in this analysis only as the documented origin of the service desk fraud technique a directory export enables. That is a statement about the technique.
No acceptance of the claimed access method. Password spraying with MFA fatigue is what the seller told buyers, relayed through a third party's filing. Sellers describe methods to make data sound freshly sourced rather than recycled, and TCS's four-year age assessment sits in direct tension with the claim.
None of which lowers the priority. Security teams triage by actor reputation, and a persona with no history scores low on that scale, but the data is real or it is not independent of who sells it. A no-name broker with a genuine 800,000-row directory does exactly as much damage as a famous one, and the next operator to run this method will also start with no reputation.
Was TCS Breached? What the Company Says
TCS filed a statement with the BSE on 10 August 2026, after receiving threat intelligence alerts about possible employee data exposure. The company said the data appears to be more than four years old, that it has not found credible evidence of a breach of its systems or customer environments, and that the information involved is limited to basic employee details. TCS also said the attacker claims password spraying and MFA fatigue as the attack vector, and that safeguards against both techniques have been in place for over two years and remain effective on current review.
Read the qualifiers, because they are doing real work. "Has not found" credible evidence is a different statement from "no breach occurred". "No indication" of customer impact is different from "no impact". "Based on the current review" ties the assessment to a moment in time rather than closing the file.
None of that is evasion. It is what SEBI Regulation 30 disclosure looks like when a material event must be reported before forensics finish, and any CISO who has signed a holding statement recognises the shape. The takeaway is not scepticism about TCS. It is that a statement issued four days into an investigation is a status update, not a verdict.
The four-year claim cuts both ways. If the data is old, the breach story weakens. The targeting value does not weaken at the same rate. Employee IDs, email formats, department structures, and reporting lines change slowly in a 600,000-person organisation. A 2022 export still tells an attacker how the company is shaped and which titles sit near money and identity systems.
HCLTech, Hexaware, Kyndryl, IHG, and Wyndham have not commented publicly. ScruteX has not purchased, downloaded, or redistributed any sample file.
Why these look like directory exports, not HR system breaches
Look at what is absent from every listing. No salary data. No bank details. No national identity numbers. No dates of birth. No performance records.
An HR platform holds those fields. A cloud directory does not. The absence is more informative than the presence.
The ratio is the proof
Compare each claimed record count against the organisation's approximate headcount.
| Organisation | Approx. staff | Records claimed | Ratio |
|---|---|---|---|
| Kyndryl | 75,000 | 170,000 | 2.27x |
| Tata Consultancy Services | 600,000 | 800,000 | 1.33x |
| HCLTech | 220,000 | 250,000 | 1.14x |
| Hexaware Technologies | 32,000 | 20,000 | 0.63x |
| IT services total | 927,000 | 1,240,000 | 1.34x |
Three of the four claim more records than the company has employees. That is the single most useful test available without touching the data, because a scrape and a directory read fail it in opposite directions.
A scraped website or a purchased sales-intelligence list returns fewer records than headcount. It only captures people with a public footprint. A directory read returns more, because a tenant holds every object, not every person: service accounts, shared mailboxes, guests, meeting rooms, test accounts, and leavers whose objects were never removed. Kyndryl at 2.27x is what an unfiltered object dump looks like.
Hexaware at 0.63x is the exception and reads as a partial export rather than a contradiction, which fits its listing being the smallest of the six.
Now look at what is present in the IHG, Wyndham, and Hexaware listings specifically: manager, direct reports, and group membership. Those three attributes do not appear in a scraped contact list or a sales-intelligence database. They are Entra ID directory properties. Their presence points at an authenticated read of the directory object graph itself, not a scrape of a public web profile or a purchase from a data broker.
An independent tracker that examined the Kyndryl sample reported it identified accounts holding the Global Administrator role, including break-glass emergency accounts. ScruteX has not examined the sample and relays this as a third-party finding. If accurate, that is not a staff list. It is a map of which identities hold the highest privilege in the tenant, including the accounts organisations deliberately exclude from conditional access to guarantee recovery.
This distinction changes the response. An HR breach is a privacy incident with regulatory duties. A directory export is a privacy incident with regulatory duties and a reconnaissance product that improves every subsequent attack against that organisation and its customers.
Why can a normal employee account read the entire Entra ID directory?
Because Microsoft designed it that way, and the design is documented.
Every user in a tenant receives default permissions, and the set depends on whether they are a native member or a B2B guest. Members hold the full set. Guests are limited by default, with a further restricted level available. Microsoft's documentation states plainly that guest users cannot enumerate the list of all users, groups, and other directory objects, which is exactly the capability members retain.
So through Microsoft Graph, a licensed member account can list users and their attributes, list groups, and read group membership. This is not a misconfiguration. Microsoft 365 collaboration depends on it: people search, mail address resolution, Teams membership, SharePoint sharing, and the Outlook org chart all read the same data.
Three consequences follow, and most organisations account only for the first.
The phished account does not need to belong to a cloud engineer. A contractor in facilities, a new joiner in marketing, or a leaver's account still active can pull the same directory. The permission model treats them all as members.
Tiered identity defence does not help. Programmes that spend their strongest controls on Global Administrators and treat staff accounts as low risk have not addressed this. If your lowest-privilege account can be taken over, your full staff directory is readable.
Restriction is possible but rarely applied. Member defaults can be changed in Entra user settings, and guest access tightened so guests see only their own profile and no group memberships. Microsoft also notes that the setting restricting access to the administration portal is explicitly not a security control, since Graph remains reachable underneath it. Teams that toggle it and close the risk have reduced nothing.
One change has gone the tenant's way. Microsoft migrated legacy tenants to a tighter app consent default in July 2026, narrowing an older path to directory-read scopes. It does not touch the member-user default read.
How does the attack chain work, step by step?
Nothing in this chain needs a vulnerability. That is what makes it durable.
1. Obtain a working credential. Password spraying against weak lockout or legacy authentication, credential reuse from a breach corpus, an adversary-in-the-middle proxy capturing the session rather than the password, or an infostealer log carrying saved credentials and live cookies together.
2. Satisfy or bypass MFA. Push bombing wears the user down until they approve. A stolen refresh token skips the prompt entirely. This is where password-plus-push fails and phishing-resistant methods hold.
3. Sign in as a member user. From here every action is a permitted read by a valid account.
4. Enumerate. Paged bulk reads against user, group, and service principal endpoints, through Graph, a PowerShell module, or the administration portal.
5. Export and sell. Write to CSV, post the thread, attach a proof sample, move buyers to encrypted messaging.
MITRE ATT&CK mapping
| Stage | Technique | ID |
|---|---|---|
| Pre-attack reconnaissance | Gather Victim Identity Information: Email Addresses | T1589.002 |
| Credential access | Brute Force: Password Spraying | T1110.003 |
| Credential access | Credentials from Password Stores (infostealer path) | T1555 |
| Credential access | Steal Web Session Cookie | T1539 |
| Defence evasion | Multi-Factor Authentication Request Generation | T1621 |
| Initial access | Valid Accounts: Cloud Accounts | T1078.004 |
| Defence evasion | Use Alternate Authentication Material: Application Access Token | T1550.001 |
| Discovery | Account Discovery: Cloud Account | T1087.004 |
| Discovery | Permission Groups Discovery: Cloud Groups | T1069.003 |
| Discovery | Cloud Service Discovery | T1526 |
| Collection | Automated Collection (paged bulk export to CSV) | T1119 |
| Persistence | Account Manipulation: Device Registration | T1098.005 |
| Exfiltration | Exfiltration Over Web Service | T1567 |
| Downstream (supply chain) | Trusted Relationship | T1199 |
| Downstream (service desk fraud) | Impersonation | T1656 |
The last two rows are where a directory export stops being a data problem and becomes an access problem. Voice-based service desk fraud against large enterprises is documented technique, most publicly associated with the clusters tracked as Scattered Spider and UNC3944. The point is narrow: the exact fields these listings advertise are the fields that make helpdesk impersonation succeed.
Why four of the six targets are IT services firms
TCS, HCLTech, and Hexaware account for 1.07 million of the claimed records between them. Add Kyndryl and the technology services share reaches 1.24 million, roughly 86 per cent of everything this seller has posted. That concentration is not random, and it is not only about headcount.
Those four run infrastructure, service desks, identity operations, and application estates inside thousands of client environments. Their staff hold privileged access into banks, insurers, retailers, hospitals, and government departments. So a service provider's directory is not just a list of that provider's employees. It is a filterable shortlist of people with standing remote access into other companies, sortable by job title. A row reading "Senior Cloud Administrator, Managed Services" is valuable for the access that person carries, not the data in the row.
The 2025 Marks and Spencer incident showed how that plays out commercially. M&S suffered a breach initially linked to a compromise involving its IT services provider, and ended a long-running helpdesk partnership six months later. TCS has said none of its own systems or users were compromised. The contract moved anyway.
Action for every reader. Pull your vendor register and check whether any of these six firms, or any managed service provider, holds standing access into your environment. If so, apply extra verification to inbound requests from their staff for the next 90 days, and review what that access actually permits. This is third-party risk management working as intended: your supplier's identity hygiene is part of your attack surface, and you inherit it whether you assess it or not.
What does each exposed field let an attacker do?
A directory export is not a leak of secrets. It is a targeting database. Each field converts into a specific capability.
| Exposed field | What an attacker does with it | Risk |
|---|---|---|
| Manager and direct reports | Business email compromise with a real reporting line. The fake instruction arrives from the person who actually gives instructions. | Critical |
| Group membership | Maps which accounts sit in privileged, production, or admin-adjacent groups. Removes guesswork from privilege escalation. | Critical |
| Phone number | Service desk fraud. The caller quotes name, employee ID, manager, and department, then requests an MFA method reset. | Critical |
| Employee ID | Passes the knowledge check most helpdesk verification scripts rely on. | High |
| Name, email, title, department | Targeted phishing naming the right project, team, and internal system. Filters the directory down to finance approvers and identity staff. | High |
| Home or office address | Identity fraud, account recovery abuse, physical targeting of senior staff. | High |
| Service account records | Identifies non-human identities that run continuously, rarely rotate credentials, and are seldom monitored. | High |
Phone numbers deserve more weight than email addresses. Email fraud has a decade of controls behind it. Voice does not. A service desk agent hearing a caller state their full name, employee ID, manager, and department hears a colleague, and resets the MFA method.
A human cost gets lost in the record counts. Several listings claim home addresses. Those people did not choose the tenant configuration, cannot check whether they are in the file, and mostly will never be told. Recovery-code abuse and identity fraud land on them personally, months after the security team has moved on.
Indicators, ATT&CK mapping, and what to hunt for
No hash to block, no C2 domain to sinkhole. The observable behaviour is a valid user reading a lot of data quickly, which is why it survives in environments tuned for failed logins and endpoint detections. ScruteX withholds sample-file links and live seller contact strings from published content; clients can request the full indicator set through their account team.
First-party client app IDs to baseline. Legitimate Microsoft applications, not malicious indicators. Scripted directory access usually authenticates through one of them, and their appearance under a general staff account is the anomaly.
| Application | App ID |
|---|---|
| Microsoft Graph Command Line Tools | 14d82eec-204b-4c2f-b7e8-296a70dab67e |
| Azure Active Directory PowerShell | 1b730954-1685-4b74-9bfd-dae2c8dc1743 |
| Microsoft Azure CLI | 04b07795-8ddb-461a-bbee-02f9e1bf7b46 |
| Microsoft Azure PowerShell | 1950a258-227b-4e31-a9cf-717495945fc2 |
Behavioural signals worth hunting.
| Signal | What to look for |
|---|---|
| Directory read tooling under non-admin accounts | Sign-ins to the four client apps above from accounts with no administrative role. Legitimate for an engineer, suspicious for a payroll clerk. |
| Portal-based enumeration | Sustained sign-ins to the Microsoft Entra administration portal and Azure portal first-party apps by general staff accounts, paired with sequential user detail page reads. Build this alongside your Graph detections, not instead of them. |
| Graph read volume | Paged bulk reads of /users, /groups, and /servicePrincipals running in sequence from one principal. |
| Hosting-provider sign-ins | Successful authentication from VPS and hosting ASNs, residential proxy ranges, or countries with no staff presence. |
| Token reuse after reset | Non-interactive sign-ins continuing after a password change. A reset does not kill a stolen refresh token. |
| New app consent | Applications granted User.Read.All, Directory.Read.All, or Group.Read.All in the past 60 days, and who approved them. |
| Dormant accounts waking | Leavers, contractors, and test accounts authenticating after months of silence. |
| MFA method changes | Authentication method registrations or resets clustered near a service desk contact, especially for finance and identity staff. |
How do you harden Entra ID security against directory enumeration?
Work in order. The first block is containment, the second removes the easy paths, the third removes the standing exposure.
Next 24 hours
- Preserve your Entra sign-in and audit logs before you do anything else. Default retention expires them in as little as seven days on lower licence tiers, and you cannot hunt a window that has already aged out.
- Hunt 90 days of Entra sign-in logs using the three queries above. If you are short on time, run 25 July to 11 August first, which covers the observed campaign window.
- Check your corporate domains against recent infostealer log sets. Password age is irrelevant if a session token was taken alongside it.
- Stop MFA resets on voice identification alone. Require a callback to the number of record plus manager attestation, and an in-person or video check for privileged staff.
- Brief finance approvers, executive assistants, and payroll staff by name. They are who the org chart points at.
Next 30 days
- Move administrators to phishing-resistant authentication: FIDO2 keys, passkeys, or certificate-based authentication. Password plus push does not stop an adversary-in-the-middle proxy. Microsoft has said passkeys become the default authentication method in Entra from 1 September 2026, replacing Microsoft-provided SMS and voice, with the transition completing 1 February 2027. Plan against that timeline rather than being moved by it.
- Block legacy authentication protocols outright through Conditional Access.
- Turn on token protection and continuous access evaluation so a stolen token stops working when risk changes.
- Review your member-user default permissions in Entra user settings, and set guest access to the restricted level so guests cannot read group membership. Treat the admin portal restriction as a usability control, not a security one.
- Audit every app registration and service principal holding
Directory.Read.AllorUser.Read.All. Remove what is unused, rotate secrets, and move surviving workloads to managed identities or certificate credentials. - Make session revocation a standard step in your account-compromise runbook. Resetting a password without revoking sessions leaves the attacker signed in.
Next 90 days
- Remove standing privilege. Put administrative roles behind time-bound activation with approval and justification.
- Run an access review across dormant accounts, leavers, contractors, and shared mailboxes. Every one of them can read the directory.
- Give every service account a named owner, a documented purpose, a permission floor, and a rotation schedule.
- Add directory enumeration to your detection engineering backlog and your purple-team scenarios. Test whether you would have seen it.
- Ask your managed service providers, in writing, what identity controls sit on the accounts they use in your tenant. Get the answer into the contract at renewal.
What this means if your company was not named
Three groups are reading this. Only one is on the list, and the other two still have work.
First-order: your people's data. Names, corporate emails, titles, departments, phone numbers, and in several listings addresses. For Indian employers this is personal data of data principals under the Digital Personal Data Protection Act 2023, with notification duties to the Data Protection Board, and CERT-In's April 2022 directions require reporting of specified cyber incidents within six hours of noticing them. For organisations with EU or UK staff, GDPR Article 33 runs a 72-hour clock in parallel. Australian entities under APRA CPS 234 have their own notification obligations. Every one of these clocks starts at awareness, not at confirmation.
Second-order: your org chart becomes an attack tool. With titles and reporting lines, an attacker identifies finance approvers, the identity and access team, the people holding production credentials, and the executive assistants who control diaries. Business email compromise stops being a guessing game.
Third-order: your suppliers. Covered above. You cannot patch a provider's exposure, but you can verify against it.
Assessment and confidence
The actor judgements sit in the profile above. Three further calls close out the analysis.
Low confidence in the record counts. Sellers inflate, recycle old data, and blend previously leaked material. TCS's four-year age assessment, if it holds, supports exactly that pattern for at least one listing. Treat every number as a claim.
High confidence in the technique. Authenticated directory enumeration against Microsoft cloud tenants is documented behaviour, requires no privileged account, and produces exactly the field set these listings advertise. Whether or not these six datasets are genuine, the method will be used again.
Two things are worth holding at once here. Microsoft's own identity stack does the in-tenant half of this well: Entra ID Protection scores risky sign-ins, Defender for Identity watches on-premises and hybrid identity, and Conditional Access enforces the outcome. Dedicated identity threat detection and response tools go deeper on session and privilege analytics, and large mature teams get real value from running them alongside. What none of that tells you is whether your directory is currently sitting in a sale thread on a criminal forum. That signal lives outside the tenant, and it is the half most programmes leave uncovered.
Key takeaways
- One seller listed six Entra ID directory exports between 1 and 10 August 2026, claiming 1.4 million records. TCS reports no credible evidence of a breach and assesses the data as over four years old. The other five named organisations have not commented.
- Two independent tests point at a directory read rather than a scrape or an HR breach: the field schema (manager, direct reports, group membership are Entra attributes) and the ratio (three of four IT services listings claim more records than the employer has staff).
- A licensed member account in a default Entra ID tenant can read users, groups, and memberships through Microsoft Graph. Guests can be restricted from this. Members are not, by default.
- Detection is behavioural, not signature-based. Watch scripted client app IDs under non-admin accounts, paged Graph reads, portal enumeration, and sessions surviving credential resets.
- Age reduces breach severity faster than it reduces targeting value. Employee IDs, email formats, and reporting lines change slowly.
FAQ
Q: What is Entra ID directory enumeration?
A: Entra ID directory enumeration is the act of reading a Microsoft Entra ID tenant's users, groups, and group memberships through an authenticated session. It uses read permissions that ordinary member accounts hold by default, so it needs no exploit and no administrative role. The output is typically exported to CSV.
Q: Can a regular user read all users in Entra ID?
A: Yes. Microsoft documents that member users in Entra ID hold the full set of default user permissions, which includes reading directory objects through Microsoft Graph. Guest users are limited by default and can be restricted further so they see only their own profile. Member-user defaults can be tightened in Entra ID user settings, but most tenants leave them as shipped.
Q: Was TCS breached in the August 2026 employee data listing?
A: TCS told the BSE on 10 August 2026 that it has not found credible evidence of a breach of its systems or customer environments, and that the data referenced appears to be more than four years old. The company has not confirmed the authenticity or source of the seller's sample. No breach has been confirmed by any organisation named in these listings.
Q: How do I detect Azure AD enumeration in my tenant?
A: Hunt for sign-ins to scripted client apps (Microsoft Graph Command Line Tools, Azure AD PowerShell, Azure CLI) from accounts with no administrative role, paged bulk reads of
/users and /groups in Microsoft Graph activity logs, successful authentication from hosting and VPS ASNs, and non-interactive sessions continuing after a password reset. Tune volume thresholds to your own baseline before alerting. Q: How can you tell a leaked employee list came from a directory export rather than a web scrape?
A: Compare the record count to the organisation's headcount. A scrape or a purchased sales list returns fewer records than the company has staff, because it only captures people with a public footprint. A directory read returns more, because a tenant holds every object rather than every person: service accounts, shared mailboxes, guests, meeting rooms, and unremoved leavers. Three of the four IT services listings here claim more records than the employer has employees. Absent fields matter too: no salary, bank, or national ID data means an identity platform was read, not an HR system.
Q: Does MFA stop directory enumeration?
A: Not on its own. Push-based MFA can be defeated by fatigue prompting or bypassed entirely with a stolen refresh token captured through an adversary-in-the-middle proxy or an infostealer log. Phishing-resistant methods (FIDO2, passkeys, certificate-based authentication) combined with token protection and continuous access evaluation are what raise the cost.
Q: What should I do if my managed service provider is named in a leak listing?
A: Confirm what standing access their staff hold in your environment, apply extra verification to inbound requests from their people for at least 90 days, review whether that access is scoped tighter than it needs to be, and ask in writing what identity controls sit on the accounts they use in your tenant. Record the answer for your next contract review.