Ah I'm sure, but their incident report mentions that an attacker has a list of employee names & numbers like that's top secret, but the question of how an attacker could then test stolen credentials seems far more interesting.
Not sure what you mean. These attacks work by getting a victim to click on a URL that leads to a website that looks exactly like the company's own authentication site (Twilio uses Okta, so this is easy to mock up). They enter their username and password, and the fake site forwards the entered credentials to the real site. If the real site then transitions to a 2FA prompt, the fake site will also do that. The victim then enters their 2FA code, the fake site forwards the 2FA code to the real site, and then is rewarded with a valid session cookie. The fake site can then even redirect to the real site so the victim doesn't realize they've been duped.
The entire attack process includes testing the credentials as a necessary part of getting the 2FA code.
A reasonable (& previously common) defence against this was an IT-provided VPN setup, with a certificate. My old company didn't put employee endpoints on the public internet, so they couldn't be exploited without a working VPN connection. Asking victims to upload their VPN certificate isn't impossible, but raises the difficulty of the attack.
Twilio's VPN does use a certificate. I have no direct insider knowledge related to this specific incident, but I suspect the VPN wasn't breached. My guess is someone phished their way in through Okta SSO, and then was able to access something like Salesforce, or some other third-party hosted app that Twilio uses.
