3.64 million employee directory records advertised from nine corporate Azure tenants — and no confirmed breach.
A threat actor using the handle “TheHatman” spent seventeen days listing internal employee directories from nine Fortune 500-scale organisations on cybercrime forums. No passwords. No ransomware. No downtime. Just names, job titles, reporting lines, phone numbers, service accounts and privileged account rosters — the raw material for every impersonation attack that follows.
Between 31 July and 16 August 2026, a seller operating under the handle “TheHatman” posted a steady stream of listings on cybercrime forums, each advertising an internal employee directory said to have been exported from a corporate Microsoft Azure / Entra ID tenant. The named organisations span IT services, telecommunications, hospitality and retail: McDonald’s Corporation, Tata Consultancy Services, Vodafone, HCL Technologies, InterContinental Hotels Group, Kyndryl, Gap Inc., Hexaware Technologies and Wyndham Hotels. The advertised total across the nine datasets is 3.64 million records (BleepingComputer, 17 August 2026).
Hudson Rock published the first substantive analysis on 16 August 2026 and reached an uncomfortable conclusion: the samples look real. The corporate email addresses resolve, and the field names align precisely with the structure of a standard Azure directory export. What is on offer is not a credential dump. It is an organisational map — full names, employee IDs, corporate email addresses including tenant-specific .onmicrosoft.com domains, job titles, phone numbers, postal addresses, manager relationships, group memberships and, in some listings, service accounts and highly privileged account records (Hudson Rock, 16 August 2026; SecurityWeek, 17 August 2026).
The intrusion vector has not been established. Hudson Rock assessed that the victimology — exclusively very large enterprises rather than the broad cross-section a platform flaw would produce — points to targeted exploitation of infostealer infections rather than a systemic Azure zero-day, and said it identified infostealer-linked compromised Azure credentials associated with several of the named organisations. The firm listed four candidate paths: infostealer malware harvesting employee session tokens, phishing that yielded administrative access, tenants without strict multi-factor authentication on specific portals, or abuse of a third-party API or integration holding excessive read privileges across environments (Hudson Rock / InfoStealers, 16 August 2026; Cybernews, 19 August 2026).
The corporate response has been sparse and, where it exists, flatly contradictory to the seller. Tata Consultancy Services told the Indian stock exchange on 10 August 2026 that it had investigated and found no credible evidence of a breach of its systems or customer environments, adding that the data appears to be at least four years old and limited to basic employee information, and that the attacker’s claimed vectors — password spray and MFA fatigue — have been mitigated by safeguards in place for more than two years (BleepingComputer, 17 August 2026). As of publication, no named organisation has publicly confirmed a breach.
That leaves security and legal teams in a genuinely difficult position, and it is the reason this case belongs in front of a board rather than a SOC shift handover. There is credible third-party analysis, a criminal’s sales pitch, one formal denial to a securities regulator, and near-silence from everyone else — and against that evidence base, several of the named organisations must decide whether an incident-reporting clock has started under GDPR, NIS2, DORA or the SEC disclosure rules. Meanwhile, a directory cannot be reissued the way a password can.
- What Happened
- Between 31 July and 16 August 2026, a threat actor using the handle “TheHatman” advertised internal employee directories from nine corporate Microsoft Azure / Entra ID tenants on cybercrime forums, providing sample datasets for buyer verification, with an advertised total of 3.64 million records (BleepingComputer, 17 August 2026).
- The named organisations are McDonald’s Corporation, Tata Consultancy Services, Vodafone, HCL Technologies, InterContinental Hotels Group, Kyndryl, Gap Inc., Hexaware Technologies and Wyndham Hotels (Hudson Rock, 16 August 2026; SecurityWeek, 17 August 2026).
- Hudson Rock reviewed the sample datasets and assessed them as highly likely authentic, citing corporate email addresses and field names matching standard Azure directory exports (Hudson Rock / InfoStealers, 16 August 2026).
- The advertised fields include full names, employee IDs, corporate email addresses including tenant-specific .onmicrosoft.com domains, job titles, phone numbers, postal addresses, manager details, user group membership, service accounts and highly privileged account records (SecurityWeek, 17 August 2026; BleepingComputer, 17 August 2026).
- Hudson Rock assessed that the campaign most likely originates from targeted exploitation of infostealer infections rather than a systemic Azure zero-day, and reported identifying infostealer-linked compromised Azure credentials associated with several named organisations including TCS, Gap Inc., HCL Technologies and Kyndryl (Hudson Rock, 16 August 2026; Cybernews, 19 August 2026).
- Tata Consultancy Services notified the Indian stock exchange on 10 August 2026 that it had found no credible evidence of a breach of its systems or customer environments, described the data as at least four years old and limited to basic employee information, and stated that safeguards against the attacker’s claimed vectors of password spray and MFA fatigue had been in place for more than two years (BleepingComputer, 17 August 2026).
- As of publication, no named organisation has publicly confirmed a breach, and the intrusion vector remains unestablished (assessed from coverage by Hudson Rock, SecurityWeek, BleepingComputer, The Register, Help Net Security and Cybernews, 16–21 August 2026).
- Business Impact
[ESTIMATED] An advertised total of 3.64 million employee directory records across nine tenants (BleepingComputer tally of forum listings, 17 August 2026). This is a figure supplied by the seller in a sales listing and is unconfirmed by any named organisation, regulator or by Microsoft.
[ESTIMATED] Advertised per-organisation counts: McDonald’s more than 1.7 million; TCS approximately 800,000; Vodafone approximately 425,000; HCL Technologies approximately 250,000; InterContinental Hotels Group approximately 185,000; Kyndryl approximately 170,000; Gap Inc. approximately 80,000; Hexaware Technologies approximately 20,000; Wyndham Hotels approximately 9,000 (Hudson Rock, 16 August 2026, as reported by Help Net Security, 18 August 2026). All figures are attacker claims and remain unconfirmed by the named organisations.
[CONFIRMED] Hudson Rock, having reviewed sample datasets, publicly assessed the data as highly likely authentic on the basis of resolving corporate email addresses and field structures matching standard Azure directory exports (Hudson Rock / InfoStealers, 16 August 2026).
[CONFIRMED] The advertised data categories include service accounts and highly privileged account records. Hudson Rock noted that exposure of service accounts and global administrator names provides a direct roadmap for subsequent social engineering, spear-phishing and targeted privilege escalation (Hudson Rock, cited by SecurityWeek, 17 August 2026).
[CONFIRMED] Tata Consultancy Services made a formal disclosure to the Indian stock exchange on 10 August 2026 stating it found no credible evidence of a breach (BleepingComputer, 17 August 2026). This is the only formal regulatory-facing response by a named organisation reported in public coverage to date.
[ESTIMATED] The number of individuals actually affected has not been publicly disclosed by any named organisation, no data protection authority has confirmed a notification, and no financial impact has been quantified in public reporting as of 23 August 2026.
- Likely Root Cause
▸ Credential and session-token theft via infostealer malware on employee endpoints, with Hudson Rock reporting infostealer-linked compromised Azure credentials tied to several of the named organisations. Source: Hudson Rock / InfoStealers, 16 August 2026; Cybernews, 19 August 2026
▸ The precise intrusion vector remains unestablished. Hudson Rock set out four candidate paths: infostealer session-token theft, phishing yielding administrative access, tenants lacking strict MFA enforcement on specific portals, or abuse of a third-party API or integration with excessive read privileges across environments. Source: Hudson Rock / InfoStealers, 16 August 2026
▸ Microsoft Entra ID grants members of the directory read access to other users’ profile attributes by default, so any single authenticated foothold — including a low-privilege one — is sufficient to enumerate an entire tenant directory unless the authorization policy has been explicitly hardened. Assessed from Entra ID default authorization-policy behaviour; not stated in incident reporting
▸ The speed and consistency of the dumps across nine separate organisations indicates a systematic, likely automated extraction process applied once initial access was obtained, rather than nine independent manual intrusions. Source: Hudson Rock / InfoStealers, 16 August 2026
▸ Bulk directory enumeration appears to have proceeded without detection or containment at any of the nine organisations, since the first public indication in every case was a forum listing rather than an internal alert. Assessed from the disclosure timeline reported by BleepingComputer and Hudson Rock, 16–17 August 2026
- Control Failures
[CF-1] 🩪 IDENTITY Directory read permissions left at platform defaults, so a standard member account can enumerate the full tenant directory — including privileged account names, service accounts and reporting structure — rather than only the objects required for that user’s role.
[CF-2] ⚙️ TECHNOLOGY Authentication artefacts stolen from employee endpoints by infostealer malware remained usable against cloud tenants, indicating sessions were not bound to a compliant, managed device and stolen tokens were not invalidated by device or location context.
[CF-3] 🔗 THIRD PARTY Third-party applications and service principals holding tenant-wide directory read scopes represent a standing, un-recertified read path into the directory — explicitly named by Hudson Rock as a candidate vector — with no evidence of periodic scope review or credential rotation.
[CF-4] 📋 PROCESS No detection, alerting or rate-limiting on bulk directory enumeration or export. In all nine cases the first public signal was a criminal forum listing, not a security operations alert.
[CF-5] 👥 PEOPLE Employee directory data treated as low-sensitivity internal information, so it attracts no classification, handling or minimisation controls — and the workforce receives no preparation for the highly credible impersonation attacks that this data makes possible.
- Recommendations
5A — Organisational & Technical Controls (for security and IT teams)
↳ CF-1 Harden the Entra ID authorization policy so members cannot read the directory (ISO 27001:2022 Annex A 8.3 — information access restriction; NIST SP 800-53 Rev. 5 AC-3, AC-6)
Set defaultUserRolePermissions.allowedToReadOtherUsers to false on the tenant authorization policy (Microsoft Graph PATCH /policies/authorizationPolicy). Set “Restrict access to Microsoft Entra admin center” to Yes, and set guest access to the most restrictive option — guests limited to properties and memberships of their own directory objects. Disable allowedToCreateApps and allowedToCreateSecurityGroups for standard members. Recertify these four settings quarterly and alert on any change to the authorization policy object, because a single tenant-wide toggle is the difference between one compromised mailbox and a full org chart.
↳ CF-2 Bind cloud sessions to compliant devices and enforce phishing-resistant authentication for privileged roles (ISO 27001:2022 Annex A 8.5 — secure authentication; NIST SP 800-53 Rev. 5 IA-2(1), SC-23; NIS2 Article 21(2)(j))
Deploy a Conditional Access policy requiring a compliant or Entra hybrid-joined device for all access to the Microsoft Graph and the Entra admin portal, and enable token protection (sender-constrained sessions) so a stolen refresh token is unusable off the originating device. Set sign-in frequency to a fixed interval for administrative roles and disable persistent browser sessions. Require FIDO2/WebAuthn hardware keys via an Authentication Strength policy for Global Administrator, Privileged Role Administrator, User Administrator and any role holding Directory.Read.All. Password reset alone does not invalidate a stolen session cookie.
↳ CF-2 Monitor workforce credentials against infostealer and breach feeds, and respond as a device compromise (ISO 27001:2022 Annex A 5.7 — threat intelligence; NIST CSF 2.0 DE.CM)
Continuously check corporate identities against infostealer log and breach datasets. On a hit, run the full sequence rather than a password reset: revoke refresh tokens for the account (Revoke-MgUserSignInSession), force credential reset, re-enrol MFA methods from a known-good device, review and revoke consented application grants for that user, and reimage the endpoint. Deliver the user-facing rules below (5B) as a standing briefing so employees know to report suspected infection immediately rather than quietly changing a password.
↳ CF-3 Inventory and recertify every service principal holding tenant-wide directory read scopes (NIS2 Article 21(2)(d) — supply chain security; ISO 27001:2022 Annex A 5.19–5.22 — supplier relationships)
Enumerate all applications and service principals granted Directory.Read.All, User.Read.All, Group.Read.All or Application.Read.All, and record a named business owner for each. Set user consent for applications to “Do not allow user consent” and route all requests through the admin consent workflow. Rotate service principal credentials on a 90-day cycle, prefer federated credentials over client secrets, and remove any grant without an owner or a use in the last 90 days. Treat a vendor integration with directory-wide read as equivalent to handing that vendor your org chart, because that is what it is.
↳ CF-4 Detect and rate-limit bulk directory enumeration (NIST SP 800-53 Rev. 5 SI-4, AU-6; CIS Controls v8.1 Control 8 — audit log management)
Ingest Microsoft Graph Activity Logs into the SIEM — they are not on by default and sign-in logs alone will not show enumeration. Alert on high-volume GET /users, GET /groups and GET /servicePrincipals from a single principal, on paging beyond a defined record threshold within a short window, and on directory export actions from the admin portal. Wire the alert to automatic session revocation above threshold rather than to a queue, and baseline the thresholds against legitimate HR and identity-governance sync jobs so the alert is survivable in production.
| 5B — For the Employee Whose Details Are in the Directory
A ready-to-forward one-pager. No technical knowledge required — send it to your whole organisation. ↳ CF-5 (NIS2 Article 21(2)(g) — basic cyber hygiene practices and cybersecurity training; ISO 27001:2022 Annex A 6.3 — awareness, education and training) 1. Assume the person contacting you already knows your job title, your manager’s name and your office address. That information is not secret and it is not proof of anything. Someone naming your manager correctly does not mean they work here. The single most useful habit you can build is to stop treating accurate details as identification. 2. Never approve a sign-in prompt, a code, or a “link this device” request that you did not personally start seconds earlier. If a notification appears on your phone and you were not at that moment logging in, the answer is no — every time, even if it appears repeatedly. Then report it, because a repeated prompt means someone already has your password. 3. If “IT” or the “service desk” contacts you and asks you to do something, hang up and call back. Use the number in your internal directory or your usual support channel, not a number or link the caller gave you. A real colleague will never mind you doing this. Someone impersonating one will try to talk you out of it, usually by creating urgency. 4. Be more suspicious of the message that gets the details right, not less. The dangerous email is not the one full of typos. It is the one that names your actual project, copies your actual manager’s name into the signature, and asks for something small and plausible. Report those — they are the ones worth catching. 5. Do not install browser extensions, download converters, or “free” utilities on your work laptop. This is how the credential theft behind this kind of incident usually begins. These tools can quietly copy the sign-in sessions stored in your browser, which lets someone into your account without ever needing your password. 6. If you think your work account has been accessed, say so the same day — and do not just change your password. Changing a password does not remove someone who is already signed in. Tell IT explicitly that you want all your sessions signed out everywhere and your laptop checked. Reporting fast is never held against you; reporting late is what turns a small problem into a large one. Prepared by SEG (Security Expert Group) as part of the SEG Weekly Cyber Briefing. Free to circulate internally. |
- Regulatory Relevance
GDPR & UK GDPR Art. 4(1), 5(1)(f), 32, 33, 34; DPA 2018 [UNRESOLVED]
Employee names, corporate contact details, employee IDs, job titles and reporting lines are personal data under Article 4(1); several named organisations — Vodafone, InterContinental Hotels Group, Kyndryl, HCL, TCS and Hexaware among them — employ substantial EU and UK workforces. If a compromise is confirmed, Article 33 requires supervisory authority notification within 72 hours of awareness and Article 32 places the adequacy of access-control and monitoring measures directly in scope. Article 34 communication to data subjects would turn on whether the exposure creates a high risk, which for a dataset optimised for targeted impersonation is a genuine question rather than a formality. This mapping is conditional: no organisation has confirmed a breach and no DPA or the ICO has confirmed a notification as of 23 August 2026.
NIS2 Art. 21(2)(d), (i), (j); Art. 23 reporting (24h / 72h / 1 month)
Vodafone falls within the telecommunications scope of NIS2 Annex I, and TCS, HCL, Kyndryl and Hexaware operate as managed service and managed security service providers — a category NIS2 brings into scope explicitly under ICT service management (B2B). Article 21(2) risk-management obligations covering access control, multi-factor authentication and supply chain security are directly engaged by the failure pattern here, and Article 23 would impose a 24-hour early warning and 72-hour notification on any in-scope entity that determines a significant incident occurred. Note the practical difficulty: the trigger for the Article 23 clock is the entity becoming aware, and awareness arriving via a criminal forum listing rather than internal telemetry is precisely the scenario transposing legislation handles least clearly.
DORA Art. 28 — third-party ICT risk; Art. 30 — key contractual provisions
TCS, HCL, Kyndryl and Hexaware are significant ICT service providers to European financial entities. Where any is designated or contracted as a critical ICT third-party service provider, the financial entity carries its own obligations — maintaining the register of information, exercising contractual audit and access rights under Article 30, and assessing whether a provider-side incident constitutes a reportable ICT-related incident for the entity itself. A directory exposure at a provider is not a financial-entity breach, but it is exactly the kind of event Article 28 monitoring is designed to surface before it becomes one.
ISO 27001:2022 · CIS Controls v8.1 · NIST SP 800-53 Rev. 5 A 5.7, 5.15, 5.18, 5.19–5.22, 8.2, 8.3, 8.5, 8.16 · Controls 5, 6, 8, 15 · AC-3, AC-6, IA-2(1), SI-4, AU-6
The standards baseline converges on the same four gaps: information access restriction (A 8.3, AC-3/AC-6, CIS Control 6), privileged access rights and access-review discipline (A 8.2, A 5.18, CIS Control 5), monitoring and audit-log coverage of the identity plane (A 8.16, SI-4/AU-6, CIS Control 8), and supplier and service-provider management for the integrations holding directory scopes (A 5.19–5.22, CIS Control 15). For a certified ISMS, an unhardened default authorization policy combined with no enumeration detection would read as a direct nonconformity rather than an observation.
SEC Cybersecurity Disclosure Rules Form 8-K Item 1.05 — four business days from materiality determination; 10-K Item 106 [UNRESOLVED]
McDonald’s, Gap Inc., Kyndryl and Wyndham are US-listed. The four-business-day clock runs from the determination that an incident is material, not from the incident itself — which places the burden on each registrant to reach a documented, defensible materiality judgment on the basis of a forum listing and a third-party vendor assessment. Boards should be asking who owns that determination, what evidence threshold triggers it, and whether the determination process itself has been exercised. No Item 1.05 filing by any named registrant had been reported as of 23 August 2026.
India — CERT-In · DPDPA 2023 · SEBI LODR CERT-In Directions 2022 — 6-hour incident reporting; DPDPA 2023 data fiduciary duties; SEBI LODR Reg. 30
TCS, HCL and Hexaware are Indian-headquartered and listed. CERT-In’s 2022 directions impose a six-hour reporting window for specified cybersecurity incidents — the shortest such deadline of any framework engaged by this case, and materially tighter than the NIS2 24-hour early warning. The DPDPA 2023 creates data fiduciary obligations for processing Indian residents’ personal data, including employee data. TCS’s 10 August 2026 filing is a SEBI LODR Regulation 30 material-events disclosure, and illustrates the pattern to expect: a listed entity in a short-deadline jurisdiction moves to the market first, while entities in longer-deadline jurisdictions stay silent.
- How SEG Can Help
↳ CF-1 / CF-4 💡 SaaS Configuration Review
SEG reviews your Entra ID tenant against the settings that actually determine blast radius — the authorization policy, guest access restrictions, admin portal access, consent framework and privileged role assignments — and validates that Graph Activity Log ingestion and enumeration alerting are live rather than merely licensed.
↳ CF-2 💡 Penetration Testing & Vulnerability Management
SEG tests whether a stolen session token from an unmanaged endpoint actually gets an attacker into your tenant, and how far it reaches once inside. Conditional Access policies that look correct in the portal frequently fail under adversary conditions; the only way to know which yours are is to run the path.
↳ CF-3 💡 Third-Party Risk Assessment
SEG inventories every application and service principal holding directory-wide read permissions in your tenant, maps each to a named owner and a live business justification, and builds the recertification cadence that stops dormant integrations from becoming standing read access into your org chart.
↳ CF-5 💡 Security Awareness Training
SEG runs awareness programmes and simulations built from your own directory structure — real reporting lines, real job titles, real internal language — because a generic phishing test does not prepare anyone for a message that names their actual manager. Section 5B of this briefing is designed to be forwarded as-is to start that conversation today.
↳ CF-1 – CF-5 💡 vCISO
SEG establishes the governance this case demands: a classification standard that stops treating directory data as non-sensitive, and a documented disclosure decision framework that tells your board who makes the materiality call, on what evidence, and against which clock — GDPR 72 hours, NIS2 24 hours, CERT-In 6 hours, SEC four business days — before you are making that decision under pressure.
| 🎯 Strategic Signal
This case will not generate an incident report at most of the nine organisations, and that is the finding. Nothing was encrypted, no service went down, no customer data is alleged to be involved, and no ransom clock is running — so nothing triggers the escalation paths boards have spent a decade building. What was taken instead is the connective tissue of the organisation: who reports to whom, who holds the privileged accounts, who sits in which office, who can be plausibly impersonated to whom. That asset has no owner on most risk registers, no classification in most policies, and no detection in most SOCs. It also cannot be rotated, revoked or reissued. Boards spent 2025 asking whether their crown-jewel data was protected; the question for the rest of 2026 is narrower and more awkward — what would a competent attacker do with a perfect copy of our org chart, and would we know they had one? |
| 💬 SEG Expert View
Dmytro Yershov — CISO, SEG When I look at this case as a board would, three things stand out. First, the absence of a crisis is not the absence of a loss. There is no outage to report and no ransom to refuse, so the natural organisational response is to file it under monitoring — and that is the error. A complete employee directory is the highest-quality targeting input an attacker can obtain, and every social engineering attempt against that organisation for the next several years becomes materially more convincing because of it. Second, notice where the real difficulty sits. It is not the technical remediation, which is well understood and largely a matter of four or five configuration decisions. It is the disclosure judgment. Several of these companies must now determine, on the strength of a criminal’s sales listing and one security vendor’s assessment, whether a reporting obligation has been triggered under regimes with deadlines ranging from six hours to four business days. If your organisation has never rehearsed who makes that determination and against what evidence, you will make it badly and under time pressure. Build that decision framework now, while it costs you nothing. Third, and this is what I would want every executive to take away: you cannot reissue an org chart. Passwords rotate, certificates renew, tokens expire. Your reporting structure does not. That asymmetry is why directory data deserves a classification, an owner and a detection rule, and why the honest measure of maturity here is not whether you can prevent this — you may not be able to — but whether you would find out from your own telemetry or from a journalist quoting a forum post. |
📖 Sources
- Hudson Rock / InfoStealers — Massive Azure Exfiltration Campaign Exposes Millions of Enterprise Records via Compromised Credentials — August 16, 2026
- BleepingComputer — Hacker claims 3.6 million Azure account records stolen from major companies — August 17, 2026
- SecurityWeek — Fortune 500 Companies Hit in Azure Data Theft Campaign — August 17, 2026
- Help Net Security — Hacker claims millions of records stolen from corporate Azure tenants — August 18, 2026
- Cybernews — Hackers dump millions of records from McDonald’s, Vodafone, and Fortune 500 companies — August 19, 2026
- The Register — Crook hawks millions of records allegedly plundered from corporate Azure tenants — August 17, 2026







