The Sensitive Business Data Hiding Inside Support Tickets

A total of 24 breach events were found and analysed resulting in 12,426,483 exposed accounts containing a total of 34 different data types of personal datum. The breaches found publicly and freely available included HOCMAI, Microsoft Internal Tickets, GamerzPlanet, Square Trade and Freedom Hosting II. Sign in to view the full library of breach events which includes, where available, reference articles relating to each breach.

A support ticket is an unstructured data store

When someone needs help, they naturally provide context. They explain what happened, which service they were using and what they have already tried. A single ticket may accumulate:
- Names and contact details
- Account or subscription information
- Device models and software versions
- Screenshots of errors or settings
- Purchase receipts
- Diagnostic files
- Internal system names
- Email conversations
- Details about colleagues, customers or suppliers
- Attachments created for another purpose

These are examples of information commonly found in support workflows. They are not a description of the fields contained in this week’s events.

The difficulty is that free-text and attachments do not always follow the same controls as structured database fields. A form can require or reject a particular value, while a description box allows the user to paste almost anything.

The BreachAware team has recorded and reviewed the provenance of this material. The descriptions shared here are intentionally limited, providing defenders with useful context without publishing source locations, detailed contents or information that could encourage misuse.

The ticket label does not define the entire incident

“Microsoft Internal Tickets” is the recorded title of one event. It should not be treated as evidence that every Microsoft support system was affected, that current production access was obtained or that all records contained the same information.

Ticket datasets can include case metadata, communications, diagnostic context or other support-related information. The verified provenance determines what was present; the public label is a concise identifier rather than a complete impact assessment.

Microsoft’s current documentation provides a useful example of how support access can be designed. For Microsoft 365 support cases, it describes time-bound, least-privileged access to information needed for troubleshooting. [Read Microsoft’s documentation on support cases and data access](https://learn.microsoft.com/en-us/microsoft-365/admin/support-diagnostic-information-collection?view=o365-worldwide).

This is cited as a present-day control example, not as a description of the event found by BreachAware.

Claims and repairs generate particularly rich context

SquareTrade, now operating as Allstate Protection Plans, provides protection plans for products including phones, computers, appliances and other technology. Its support process can involve plan information, device details and evidence needed to assess a claim. [SquareTrade explains its protection-plan services](https://www.squaretrade.com/about/).

Again, this does not establish that claim documents, receipts or device information were included in the event.

It does illustrate why service and claims platforms need careful data handling. To resolve a legitimate problem, a customer may be asked to prove ownership, describe damage or supply supporting documentation.

The operational need may be genuine, but it should not result in supporting material being retained everywhere, indefinitely or by default. A useful design question is: “What is the minimum information needed to decide this case, and when can it be removed?”

Education-related support requires careful interpretation

HOCMAI provides online learning and exam-preparation services for school-age learners in Vietnam. [Vietnam’s government AI database describes the HOCMAI education platform](https://ai.dda.gov.vn/chi-tiet-he-thong-tri-tue-nhan-tao/VN-01-0000140-EDU-001-0).

Its inclusion should not be used to infer that children’s data, educational results or classroom activity was present. Those conclusions require evidence from the verified records.

The education context does, however, reinforce the importance of proportionate collection and age-appropriate support design. An account may involve the learner, a parent or guardian, a teacher or another service user.

Organisations should ensure that support staff can distinguish those roles and do not disclose account information merely because someone knows details about the student or service.

Forums combine public and private information

A forum account can contain several categories of information:
- Public posts and profile details
- Private messages
- Registration information
- Moderation records
- Support conversations
- Technical account metadata

Information intentionally posted in public should not automatically be treated as secret. That does not mean every piece of information associated with the account was intended for unrestricted reuse.

GamerzPlanet provides a forum or community context within this week’s sample. The source title alone does not establish which of the above categories was present.

Freedom Hosting II is similarly retained as the recorded event title without expanding its infrastructure or publishing operational detail. Further identification would add little value for the B2B audience and could encourage precisely the wrong type of attention.

Why staff and customers overshare in tickets

Most oversharing is not careless or malicious. People are trying to obtain help, and detailed information often seems likely to produce a faster answer.

Support staff can also request more information than necessary because they are following a generic troubleshooting process rather than one tailored to the particular case. Common causes include:
- Forms that provide no guidance about prohibited content
- Requests for complete screenshots when one error message would be enough
- Diagnostic exports collected without review
- Email replies that preserve long conversation histories
- Documents uploaded when a reference number would suffice
- Support staff copying data into internal notes
- Tickets being transferred between several teams or suppliers

The solution is not to discourage useful detail. It is to help users and support personnel distinguish relevant evidence from unnecessary exposure.

What the weekly totals do and do not show

The 12,426,483 exposed accounts should not be interpreted as the same number of unique or newly affected people. The total may include:
- Historical or inactive accounts
- Duplicate records
- Several accounts belonging to one person
- Information previously circulated elsewhere
- Records associated with services that have since changed

The 34 data types were identified across all 24 events. This does not mean that every record contained all 34, or that all event types held similarly detailed information.

The named examples also do not establish that technology support, education or protection-plan providers were disproportionately affected. They provide useful context from the wider material found during the week.

Three defensive checks for B2B organisations

1. Design support forms to prevent unnecessary collection
Tell users what information is required and what they should not submit. In particular, discourage passwords, authentication codes, complete payment details and unrelated personal documents.

Use structured fields where they improve consistency, but do not collect a field merely because it may occasionally be useful. Allow users to redact attachments and explain how submitted material will be used.

2. Separate attachments and diagnostics from general ticket access
Not every employee who can read a case summary needs access to every uploaded file.

Apply role-based controls to sensitive attachments, diagnostic material and customer environments. Record access and use time-limited permissions when specialist investigation is required.

Where a support supplier needs access to customer systems or data, define the scope, duration and removal process before access is granted.

3. Give tickets an end-of-life
Support records should have documented retention periods based on legal, contractual and operational needs.

When a case closes, review whether large attachments, screenshots or diagnostic files still need to be retained. Remove temporary access and ensure copied material is not left behind in email, local downloads or unrelated collaboration tools.

Retention should be long enough to support the legitimate purpose, not automatically permanent because storage is inexpensive.

The wider lesson

This week shows why support data deserves the same attention as customer databases and authentication systems.

A ticket may begin as a short request for help and develop into a detailed narrative containing several people, systems and attachments. That context is useful to support teams, but it also increases the consequences of unnecessary retention or overly broad access.

Businesses do not need to make support slower or less helpful. They need to collect deliberately, control access and remove temporary evidence when its purpose has ended.

The most useful question is not simply, “How do we protect our ticketing platform?” It is, “Why is each piece of information in the ticket, who needs it and how long should it remain there?”