French intellectual-property services provider Questel has confirmed that a voice phishing attack led to unauthorized access to part of its Microsoft 365 environment, specifically a Sales SharePoint environment. Questel told CyberInsider that the access was contained, some data obtained during the incident was published and its production tools, IP platforms and SaaS services were not accessed.
A fresh independent data point arrived on 1 September 2026. Have I Been Pwned added a verified Questel breach containing approximately 1.2 million unique email addresses, along with names, employers, job titles, phone numbers, physical addresses and support tickets. HIBP does not list passwords among the exposed fields.
The verified count is not the attacker's count
ShinyHunters claimed more than 21 million Salesforce records and more than 147GB of internal data. Questel did not confirm those figures or that system description. Its statement identified a Sales SharePoint environment and said it was still reviewing the published material for authenticity and completeness.
HIBP's 1.2 million figure counts unique email addresses in the corpus it verified. It should not be converted into 1.2 million affected people without further evidence, and it is not directly comparable with an attacker's count of database rows. One person can appear in several records, and a larger claimed archive can contain duplicates, synthetic data or material outside HIBP's account-based index.
Why contact and support data can make the next call convincing
Names, employers, roles and support-case context can help a caller sound legitimate. Someone who knows which product a customer uses, which issue was reported or which colleague owns the relationship can construct a plausible request to approve an MFA prompt, reset access or disclose a temporary code.
That does not prove that every exposed contact will be targeted, or that the leaked data contains credentials. It means organizations should stop treating knowledge of internal context as proof of identity. A caller can know real details and still be an attacker.
A verification channel that survives vishing
- Do not authenticate the caller with facts the caller supplied. Job titles, customer IDs and ticket details may all be exposed or researched.
- End the inbound call. Return the request through a pre-registered number, internal directory or approved service workflow.
- Never approve an unexpected MFA prompt. A help-desk or security employee should not need an unsolicited push approval to investigate an account.
- Require a second person for sensitive recovery. Changes to privileged accounts, authentication factors and export permissions deserve dual control.
- Separate context from the secret. Keep the customer, system and purpose in the ticket; deliver the temporary value through a different controlled channel.
- Make replacement access temporary. Use least privilege, short expiry and explicit revocation after the task.
- Revoke more than the password. Invalidate active sessions, refresh tokens, application consents, recovery codes and delegated access where the investigation requires it.
- Warn affected contacts through an official channel. Explain what categories were exposed without repeating sensitive values or directing people to unofficial login pages.
Where Secretus fits—and where it does not
After identity has been verified independently, Secretus can move a temporary password, recovery code or API key without leaving its plaintext in the support ticket, mailbox or chat history. A one-time link and short expiry reduce the lifetime of the delivery copy.
Secretus does not determine whether the caller is genuine. If a team sends a one-time link to an attacker-controlled account, the cryptography will protect delivery to the wrong recipient. Identity verification must therefore happen first, through a channel the inbound caller did not establish or control.
What remains unknown
Questel has not disclosed how the vishing interaction became working Microsoft 365 access, how long access lasted, the complete categories of affected information or the final number of people requiring notification. The company said it notified France's CNIL, filed criminal complaints and was contacting affected customers, but no public regulator finding is available. The attacker's 21 million-record and 147GB claims remain unconfirmed.