McDonald’s: Alleged 1.7 Million-Record Azure Dump Offered for Sale

Private listing attributes theft to compromised credentials

On August 17, 2026, a listing appeared on an underground data marketplace titled “McDonalds 1.7M+ Azure Internal Employee Dump.” The author, identified as TheHatman, claims to have stolen approximately 1.7 million records from McDonald’s Azure tenant using compromised credentials.

The listing, posted at 4:08 AM according to the forum’s time zone, does not specify a price. The seller is inviting private offers and has attached a free sample containing 8,000 rows.

However, the theft of the entire claimed volume has not been demonstrated. Technical analysis of the sample identified numerous elements consistent with a genuine corporate directory export, but it cannot establish either the age of the data or the actual size of the full archive.

Sample contains traces consistent with Entra ID

The file uses a structure consistent with exports obtained through PowerShell tools for Microsoft Entra ID directories, formerly known as Azure Active Directory. Its fields include properties such as FacsimileTelephoneNumber and PhysicalDeliveryOfficeName, which would be difficult to obtain through a simple collection of publicly available information.

The sample contains addresses belonging to 50 email domains associated with McDonald’s. The records cover corporate staff, restaurant employees, franchisee accounts and guest users linked to suppliers in more than 30 countries.

Three rows use the integrated mcdonaldscorp.onmicrosoft.com domain. This detail is not normally exposed outside the organization and would not be easy to obtain by scraping public webpages alone.

The errors in the file also support the possibility of a corporate export:

• 233 rows contain corrupted characters, such as “Königswinter” instead of “Königswinter” and “München” instead of “München”;
• several professional titles in Ukrainian were damaged during character-set conversion;
• 85 titles end at exactly 30 characters, a pattern consistent with a fixed-width field originating from an HR system;
• an entry associated with the “556 Upton” location in Wirral contains a telephone number matching a publicly listed McDonald’s site.

The combination of incorrect encoding, regular truncation and internal fields is more consistent with an automated export process than with a manually assembled dataset.

The data cannot be dated, and the 1.7 million-record claim remains unverified

The sample contains no creation dates, last-login timestamps or other temporal indicators. It is therefore unknown when the directory was exported or how current the information is.

The absence of Russian records is consistent with McDonald’s exit from Russia in 2022. The lack of Kazakh users could also indicate that the data was collected in 2023 or later, but this remains only a hypothesis. The file provides no verifiable date.

The same applies to the claimed volume. The 8,000 rows distributed as a sample represent less than half of 1% of the advertised 1.7 million records. The figure is plausible given the size of McDonald’s workforce and global ecosystem, but it has not been verified. The seller may have rounded the number upward.

No specific software versions have been disclosed. The claim concerns an Azure tenant and an Entra ID directory, not a vulnerability identified by a CVE.

Nine listings appear to follow the same pattern

The operation attributed to TheHatman appears to be part of a broader campaign. The same account published nine listings over a 16-day period, collectively claiming approximately 3.6 million records belonging to McDonald’s, Vodafone, Gap, two unnamed hotel chains and four major IT outsourcing companies.

The organizations named include Kyndryl and Tata Consultancy Services. The listings share a structure consisting of 19 columns and nearly identical descriptions. This pattern is consistent with the repeated use of a script to export different directories, rather than with nine datasets produced independently.

One possible explanation is the use of infostealer malware to collect credentials saved on devices and resell them. If one of those credentials were still valid, access to the directory might not require a particularly sophisticated intrusion: in some Entra ID tenants, an authenticated account can enumerate users unless administrators have explicitly applied restrictions.

This scenario does not prove that a specific infostealer was used, nor does it identify the attacker’s initial access path. It is also unknown whether McDonald’s experienced direct unauthorized access, a supplier compromise or credential theft from a corporate device.

The primary risk is targeted phishing

The sample does not contain passwords or hashes. The most immediate threat therefore appears to be the use of the data for targeted phishing, impersonation and social engineering, rather than direct account access.

Names, job titles, locations, direct phone numbers and email-address formats can make a call to IT support or administration appear highly credible. A fraudster could already know the employee’s restaurant or office, request a password reset, pressure them to make a payment or submit a fake bank-account update request.

The risk also extends to franchisees, suppliers and guest accounts. Knowledge of the internal structure can help attackers craft more convincing messages, particularly when the recipient handles payments, access, personnel or local systems.

The organizations involved should investigate the use of compromised credentials, enforce resets for at-risk accounts and verify that multifactor authentication is actually being applied. They should also analyze anomalous access, suspicious sessions and any directory-export activity.

Where possible, user-enumeration activity in Entra ID tenants should be restricted. Organizations should also look for signs of infostealer malware on devices used by affected accounts and warn employees, franchisees and suppliers about personalized contact attempts.

For requests received by email or phone—especially those involving credentials, payments or operational changes—verification should take place through an independent channel. Prior knowledge of the recipient’s name, role and location does not prove the requester’s identity.