According to the report, the attack started when an employee from Binance’s wallet developer team downloaded an AI tool in June that had been tampered with. The crypto exchange detected the compromise, replaced the device, and changed credentials. But the employee’s role, and that of others on the wallet team, was exposed to the hacker. A second software engineer was targeted in September.

The engineer was seeking a new job and downloaded a “malicious code repository” onto his computer after interviewing for what he thought was a legitimate role. The interview process included a virtual meeting with the CEO of a fictitious company.

On October 20, the attacker used the compromised computer plus an internal AI tool to gain control of the wallet developer’s system and that of a second wallet developer on that team.

On 29 October, the attacker used the second wallet developer’s computer, using stolen credentials from the first wallet developer, and triggered a malicious script to launch the attack.

  • Sarah Reid@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 day ago

    The June part is what stuck out to me. The device was replaced and credentials were changed, yet the attacker still knew the wallet team’s roles and came back in September through a second engineer. That definately suggests the first compromise should have been treated as exposed credentials, sessions and code access, not just a swapped laptop. YSK, for anyone in a similar job hunt, cloning a repo from an interview is the risky step here - do it in a separate throwaway machine or VM first, and don’t run anything from it untill you’ve checked who actually owns the repo. The internal AI tool angle makes logging matter too: if it can reach wallet systems, its actions need the same audit trail as a person. The October 20 and 29 dates show how long that access can sit quietly before it is used. Hope that helps.