According to the Maryland Attorney General breach notice, Seyfarth Shaw became aware on 4 November 2024 of unauthorized access after an actor impersonated an employee to Service Desk staff, who modified MFA by replacing the registered phone number. That helpdesk re-enrollment put the second factor under attacker control. The actor then accessed the employee’s ADP payroll path and diverted direct deposit. Public reporting frames an intrusion window around 20-21 September 2024, paycheck redirects discovered around 3 November 2024, and impact limited to a single employee payroll account. Public reporting does not establish a named threat actor, AiTM tooling, or scope beyond that payroll account.
Helpdesk recovery that hands over a transferable factor is the same social-engineering class as coaching a fake login. A fix exists for that enrollment and recovery surface. If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
How did attackers get into a Seyfarth Shaw employee account?
The attackers got into a Seyfarth Shaw employee account by social-engineering Service Desk staff. According to the Maryland Attorney General breach notice, an actor impersonated an employee, and Service Desk staff replaced the registered MFA phone number. That helpdesk MFA re-enrollment gave the attacker control of the second factor, then access used to divert ADP direct deposit.
Did multi-factor authentication fail at Seyfarth Shaw?
Yes. Legacy phone-based MFA failed at Seyfarth Shaw on the recovery path, not because someone cracked a normal login form in public reporting. Service Desk staff replaced the registered MFA phone number after an impersonation call. Once the phone factor pointed at the attacker, later authentication could look like a legitimate employee login with MFA satisfied. Public reporting does not establish the exact verification steps Service Desk used.
What was diverted after the MFA phone-number swap?
After the MFA phone-number swap at Seyfarth Shaw, the actor accessed the employee’s ADP payroll path and diverted direct deposit. Public reporting frames unauthorized access around 20-21 September 2024 and paycheck redirects discovered around 3 November 2024. Public reporting does not establish impact beyond a single employee payroll account, and it does not document a ransom demand or payment.
Was this AiTM phishing or stolen session cookies?
Public reporting does not establish AiTM reverse-proxy phishing, device-code flow, or session cookie theft details for the Seyfarth Shaw incident. The documented path is helpdesk social engineering that swapped the registered MFA phone number, then ADP payroll access and direct-deposit diversion. Inventing a proxied login kit would go beyond the Maryland AG notice.
Is this the same problem as a helpdesk password reset?
Yes, for workforce identity it is the same attack class. Talking Service Desk into swapping an MFA phone number is live coaching of a transferable factor, just as talking helpdesk into a password reset hands over a primary secret. The M&S helpdesk password-reset social engineering path is another example of recovery abused by impersonation. Closing the phishable recovery path stops this route before ADP ever sees a “legitimate” login.
