Hacker Leaks 12,000 Alleged Twilio Call Records with Audio Recordings

Customer’s Use of Flawed 3rd-Party Tool Exposes 12K Twilio Call Records, Recordings

September 23, 2024

4 minute read

A hacker has leaked 12,000 alleged Twilio call records, including phone numbers and audio recordings. The breach exposes personal data, creating significant privacy risks for businesses and individuals using the service.

The article and its title has been updated with a confirmation statement from Twilio.

A hacker, who has been quite active recently and goes by the alias ‘grep,’ has leaked over 12,000 (11,802) call records with audio, which they claim belong to Twilio customers. The leak’s timestamp ranges from 2019-06-14 to 2024-09-23.

Twilio is a San Francisco, California-based cloud communications platform that enables developers to integrate voice, messaging, video, and authentication features directly into applications using its API. As of 2024, the company has over 350,000 active customer accounts, which means the latest alleged leak is approximately 3.37% of the total accounts.

According to the hacker, the alleged breach took place in September; however, they did not specify whether this was a third-party breach or if the records were accessed directly from Twilio’s systems.

The Hackread.com research team managed to analyze the full leaked data. The leaked records are divided into two TXT files. The first file appears to be a log of calls, likely extracted from a telecommunications system.

Both files track calls, likely in the context of a telecommunication and interpretation service. File 1 is a basic call log, while File 2 has additional details specific to interpretation services, including languages, rates, and session details. Here’s a breakdown of the fields and the data it contains:

File 1

Start_time & End_time:

These fields store the timestamps indicating when the call started and ended.
Example: '2019-06-14 05:40:49.924214' to '2019-06-14 05:42:19.907792'.

Called_from & Called_to:

The phone numbers of the caller (called_from) and the recipient (called_to).
Example: +165******** is calling +144********.

Status:

Indicates the call’s status, such as whether it was ‘completed’, ‘failed’, or ‘no answer’.
Example: 'completed'.

Duration:

The duration of the call is in seconds.
Example: 90 seconds.

Notes:

It appears to be a placeholder for any additional comments or notes related to the call.
In most cases, this field is empty.

Agent_id, interpretation_session_id, Call_sid, direction, Call_type, interpreter_id: ID for the interpreter handling the call and seems to be metadata.

Agent_id: ID of the agent handling the call.

Interpretation_session_id: ID related to an interpretation session (suggests this may involve translation services).

Call_sid: Unique identifier for the call.

Direction: Whether the call was ‘inbound’ or ‘outbound’.

Call_type: Describes the type of call, such as ‘incoming’ or ‘interpreter outbound’.

File 2

The second file seems to contain more detailed records for calls, potentially involving interpretation or translation services. It includes a variety of additional fields for tracking various aspects of the call. Here’s a breakdown:

Start_time & end_time:

Same as in File 1, showing the start and end time of the call.

Called_from & called_to:

Phone numbers of the caller and recipient, just like in File 1.

Status:

Expanded statuses, such as ‘interpretation completed’ or ‘no answer’.
Example: 'interpretation completed'.

Incoming_call_sid:

The identifier for the incoming call. This could help map calls to their corresponding logs from File 1.

Duration:

Duration of the call in seconds, similar to File 1.

Language:

Specifies the language being interpreted during the call.
Example: 'English', 'Arabic'.

Rate:

Possible charge rate or interpreter cost rate for the call.
Example: '1.00'.

Interpretation_start_time:

Indicates when the actual interpretation session started.
Example: '2019-06-14 05:42:02.498291'.

Recording_url:

This field may store the URL for accessing a recording of the call (although it is often NULL in the sample data).

Agent_answered_time, payout, total_cost:

Metadata that tracks when the agent answered, and the financial details (e.g., payout for the interpreter and total cost of the call).
Twilio links with actual recording audio calls of customers

Conference_name, sms_callback, client_hold_time, department_code:

More metadata fields related to conferences, callbacks, and department tracking.

Queued_count:

Tracks how many times the call has been queued.

Is_video:

Indicates whether the call was a video call.
Example: 0 (No video).

Remarks, disposition_response_agent:

These fields may capture agent responses, call dispositions, or other follow-up actions.

Audio Call Recodings and Cybersecurity Risks

Although the leaked data by number is minimal, the presence of actual call recordings seriously increases the severity of the breach, as it exposes not just metadata but the contents of conversations.

This can lead to serious privacy violations, especially if the calls involve sensitive personal or business information. Attackers could exploit these recordings for blackmail, fraud, or impersonation. Businesses could face legal consequences under regulations like GDPR or CCPA for failing to protect this data.

The leaked phone numbers are also vulnerable to smishing (SMS phishing) and vishing (voice call phishing) scams. Both methods of attack are popular among cybercriminals and threat actors, particularly those supported by organized groups. A recent example is last month’s attack on businesses in the United States, where hackers were found calling employees to obtain their company’s VPN credentials.

Nevertheless, the situation may require immediate actions including notifying affected parties, securing the leaked recordings, and consulting legal experts. Organizations should also review access controls, implement encryption, and involve an incident response team to manage the breach.

UPDATE – 16:23 Tuesday, 24 September 2024 – (GMT)

Twilio swiftly responded to Hackread.com’s request clarifying that they were not breached, but a customer’s data was exposed due to a vulnerability in a third-party tool used by the customer’s developers, and the issue has since been resolved.

“At this time, we have no evidence to suggest that Twilio was breached. One of Twilio’s customers inadvertently exposed its own Twilio data when their developers used a 3rd party software tool that had a vulnerability. Twilio informed this customer and they’ve already taken steps to secure their account.”
A Twilio Spokesperson