This is a report on the “sim-swapping” attack Skip suffered on December 17th, the immediate steps the team took to mitigate it, and the longer-term changes the team is making to improve its security posture structurally.
The report has two basic goals:
- Give Skip’s community of partners, customers, and users insight into the extent of the attack and into how the team is enhancing its security moving forward.
- Share learnings with to the broader crypto community about how these attacks transpire, how to prepare for them, and how to respond most effectively. The end of the report provides several recommendations for other teams based on the Skip team’s experiences and conversations with experts.
Description of the Attack
- Sunday, December 17th at 3:01 PM ET: Barry (Skip Cofounder) received an automated text message from his cellphone carrier that his account pin had been changed. He immediately called his carrier to report the change as unauthorized.
- 3:06 PM ET: Barry received another text that a new sim card had been activated on his line, while still on hold with the carrier’s support
- Moments later: His service cut out entirely, as the attacker’s sim card activated and his deactivated.
- 3:10 PM ET: the attacker had used his phone number to access the SkipProtocol X account. X allows users to use SMS as a single-factor authentication mechanism for resetting the password, making it particular vulnerable to this kind of attack. Unless SMS is disabled and device-based 2FA is enabled, an attacker only needs a phone-number — not an email or password — to access X.
- 3:11 PM ET: To prevent the Skip team from regaining access to the account, the attacker removed the phone number from it, changed the password, and added device-based 2FA associated with their device. These actions fully locked the Skip team out of the account. Only manual intervention from X would restore their access to the account at this point.
- 3:26 PM ET: The attacker began posting tweets promoting a fake “$SKIP” token and airdrop with a link to a phishing site (skip[.]finance) designed to look like Skip’s real website (https://skip.money). The phishing site requested users to sign a transaction that authorized a contract (deployed on all major EVM networks) to drain the user’s wallet once they signed it
The phishing site the attacker posted. It looked like the real website and referenced real Skip products.
Notably, only 25 minutes passed between the first sign of the attack and when the attacker first posted the scam website. This underscores the importance of taking effective preventative measures. No degree of realtime incident response could have fully prevented the attack.
Immediate Response
As soon as he lost service, Barry informed several core members of the Skip team that he was being attacked before going to his carrier’s local store to re-associate his phone number with his sim and remove the attacker.
Several core members of the immediately began responding along 5 different dimensions:
- Establishing an E2E encrypted communication channel: Several team members, including Skip’s cofounder Mag and the Head of DevOps, established an E2E-encrypted communication channel to coordinate the response securely.
- Privately informing partners and customers: One of the team members immediately went through all active Telegram and Slack channels with partners and customers (e.g. Keplr, Leap, Osmosis, dYdX, etc…) and informed them that there was a sim swap in progress and that they shouldn’t trust any communications from Barry or the Skip X account until the team understood the extent of the attack and purged the attacker from their systems.
- Publicly informing the community: The team members with the largest X followings informed the Skip community and broader public not to trust posts coming from the Skip X account (i.e. that the account had been compromised, that there was no token or airdrop, and that folks should not click on any links in the accounts posts until receiving an all-clear signal from un-compromised members of the team)
- Revoking Barry’s access to all systems: Mag immediately revoked Barry’s access to all systems, including HR platforms, software infrastructure (e.g. AWS, Tailscale, etc..), Github, financial platforms, and email.
- Contacting professional incident response teams to assist: The team got in touch with several incident response teams including Groom Lake, Efani, and ZeroFox to get assistance taking down the fraudulent domains, temporarily suspending the compromised X account, and ensuring the response generally abided by all industry best practices. samczsun also reached out the team to personally help add the fraudulent domains to Metamask/Phantom’s list of blocked domains.
At approximately 3:36, Barry’s carrier removed the attacker’s SIM card from his phone number, reinstated his, and escalated the security on his account. This limited the duration of the primary attack to 30 minutes.
The team still needed to assess whether the attacker had managed to move laterally into any of Barry’s other corporate accounts (now fully suspended and deactivated) or personal accounts.
Damage Assessment, Account Reactivation, and Account Security Improvements
At approximately 4:00 PM (54 minutes after the attack began), the team began assessing whether the attacker had moved laterally (or could have moved laterally) into any systems beyond Barry’s phone number and the Skip X account.
By the end of this process (about 11:15 PM ET), the team had high confidence that the attacker had not moved and could not have moved into any of the team’s other services.
For each service the company uses, the assessment and reactivation process consisted of three basic steps:
1. Evaluating whether the attacker could have accessed the system by determining whether SMS-based 2FA or 1FA was enabled on the account. The team classified the company’s systems into 3-tiers based on their security at the time of the attack according to authentication factors:
- SMS-based 1FA services (aka High Vulnerability Services) are those where the password can be reset or the account can otherwise be accessed using SMS-based authentication alone (i.e. with no step involving email, app-based, or password authentication). Accessing these services would have only required gaining control of Barry’s phone number.
- SMS-based 2FA services and email/password 1FA services (aka Moderate Vulnerability Services) are those where the password can be reset or the account can be accessed using SMS in addition to some other form of verification (i.e. password or email-based verification) AND those where the password can be reset or the account can be accessed using email or password verification alone. Accessing these services would have required gaining control of Barry’s email in addition to his phone number.
- Non-SMS-based 2FA services (aka Low Vulnerability Services) are those where resetting the password or accessing the account in any way requires access to an app-based 2FA method (e.g. Google Authenticator or Authy) or physical 2FA method (e.g. a Yubikey). Accessing these services would have required gaining control of Barry’s physical device.
2. Evaluating whether the attacker actually did access the service using a combination of access logs, active session reports, and conversations the support/security team at the vendor where necessary.
3. Enhancing security of the service by:
- Changing the password on Barry’s account
- Activating device-based 2FA if possible and not active (or changing to Google SSO), and disabling SMS-based 2FA if it was being used. In other words, migrating the service to a Low Vulnerability posture if necessary.
Importantly, this analysis hinged on the attacker having not moved laterally into Barry’s email or iCloud. (If they had, the team would have reclassified all services using email-based authentication as high vulnerability services.) As a result, the team began their analysis with iCloud and the team’s email vendor (Google Suite).
Analysis of the iCloud account with support from Apple found that:
- No one had attempted to login to the account
- No new devices had been associated with the account
- Activating a new device on the account would have required a 2FA pin sent to one of Barry’s other devices (all of which he had physical possession of)
Analysis of the email accounts found that:
- Barry’s company and personal emails were both properly configured with device-based 2FA and did not have SMS-based 2FA enabled (i.e. Low Vulnerability)
- No one had logged into either of the emails
This information indicated the attacker had not AND could not have accessed Barry’s email accounts or iCloud account. This enabled the team to reactivate Barry’s email account and to confidently classify the remaining services into the tiers above.
The table below highlights the team’s findings. In summary:
- The were zero additional High Vulnerability Services beyond the @SkipProtocol X account
- There were only three Moderate vulnerability services found: the ATS, the Notion, and the PEO.
- All of Barry’s personal communication and social media accounts (e.g. Telegram, Slack, Discord, personal X account) were Low Vulnerability Services.
- All of Skip’s services that are involved directly in software development and deployment processes, including infrastructure services (e.g. CSPs, mesh VPN, alert software, publishing software), secret / password managers, etc.. were Low Vulnerability Services.
Findings from internal security analysis of all Skip services & platforms
A more detailed analysis of the Moderate Vulnerability Services indicated:
- The attacker should NOT have been able to access any of them, since accessing them or changing their passwords would have also required access to Barry’s email (which the team already determined was properly secured)
- The attacker had NOT accessed them, based on access logs and discussions with relevant vendor support/security teams
All together, the above analysis indicated the attacker hadn’t and couldn’t have moved laterally beyond Skip’s X account.
Regaining access to the X Account
By 12:00 AM ET on the day of the attack, X had suspended the account’s ability to post. This came after the account had posted about the fake airdrop with the link to the drainer website 11 times. Finally though, there was no further damage the attacker could do because:
- The account was unable to post
- All previous posts had been taken down (as a result of the team & community reporting every post as a scam when each went live)
- The drainer websites themselves had been blocked by Metamask and by DNS servers
But the team still could not access the X account. The team only regained access at 10:30 PM ET on Monday December 18th, after being locked out of the account for 31.25 hours. Regaining access proved difficult for several reasons:
- X experienced major layoffs after Elon Musk purchased the company. As a result, many of the team’s personal contacts and their network’s contacts at the company are no longer there
- X’s Trust and Safety org in particular experienced massive layoffs. One incident response team told the Skip team that the org had shrunk by over 50% and that many of their clients had failed to regain access to their accounts after MONTHS of effort.
- X automatically closed numerous support tickets the team opened to report the incident. Within moments of opening a ticket reporting that the team could not access the account, Barry received an email saying “We’ve investigated your report and it seems like you still have control of your account.” When he responded to this email, he received another automated response saying, “This case has been closed and we aren’t able to reopen it at this time, but we’d like to make sure you get the help you need. We encourage you to visit our Help Center or create a new case.”
The team took several measures to regain access in the face of these obstacles, including:
- Reaching out directly and through investors / partners to over 2 dozen current and former X employees, in search of some way to have the cases reopened / escalated
- Obtaining an official activity log of changes to Barry’s mobile carrier account to share with X — a task which required spending 9 hours on the phone with customer service, fraud, and legal representatives from the carrier
- Filing a police report with the NYPD to share with X — which can help protect X from legal liability in the event the claim that an account owner has been locked out turns out to be fraudulent
Ultimately, X restored the team’s access to the account at 10:30 PM ET on Monday December 18th — more than 31 hours after the attack began. The team is unsure which of these efforts (or which combination of them) lead to the restoration.
After regaining control of the account, the team properly secured it:
- Terminating all active sessions
- Removing SMS-based 2FA
- Removing the phone number from the account altogether
- Adding device-based 2FA
- Changing the password
- Removing all accounts that had the attacker had delegated permissions to (a common but not often discussed part of the scam)
Structural Security Improvements At Skip
As a result of the attack, the team is making several long-term and structural changes to enhance Skip’s security posture, including:
- Upgrading all Moderate Vulnerability Services to Low Vulnerability Services by requiring app-based 2FA or SSO for the entire Skip org
- Activating advanced anti-phishing and email security software for Skip’s Google Workspace
- Enabling Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) for Skip’s company email
- Conducting quarterly security audits and preparedness trainings with the help of a professional IT security auditing firm to ensure practices evolve appropriately as we scale
- Adding 2 new security focused steps to new employee onboarding, including 1) a security information & best practices session, and 2) manual verification of account security with another member for all relevant personal and corporate accounts
- Instituting mandatory GPG commit signing for all developers to ensure proper provenance of all Skip source code
- Requiring all team members use company laptops to isolate company activities from personal online activities and using mobile device management (MDM) software to further secure and monitor company machines.
Additional Information about the attack
In addition to responding to the attack, the team tried to learn about the attackers behind it. This is a summary of learnings:
- This is the drainer contract used to syphon user funds: https://etherscan.io/address/0x00000f312c54d0dd25888ee9cdc3dee988700000
- This is wallet that the contract sent the stolen funds to: https://etherscan.io/address/0x63605e53d422c4f1ac0e01390ac59aaf84c44a51
- The wallet + contract indicate the attack was perpetrated the Pink Drainer group — a well-known threat group that has run numerous other phishing and draining scams, including against OpenAI’s CTO (Mira Murati), Vitalik Buterin, Orbiter Finance, and others. More information about the group and its attacks can be found here and here
- The contract drained approximately 10ETH during the time the X account was compromised. Given that the group has perpetrated numerous other draining scams, the Skip team is unable to determine at this time whether all of this was drained from users accessing the fake Skip websites or whether the group was running other scams in parallel with the same contract.
- Barry’s carrier was unable to produce standard security metadata for the sim swapping event that precipitated the attack (e.g. location of the store / store ID, employee name / ID who performed the manual override, override code used etc…) despite having all of this data for the legitimate SIM swapping event where Barry re-associated his sim card with the phone number. As a result, the team believes it’s very likely that at least one carrier employee with significant security permissions was bribed or otherwise complicit in the scheme.
- When Metamask/Phantom and DNS providers blocked the first domain (skip[.]finance), the attackers reposted the phishing site to a new fake domain (skipprotocol[.]com) within minutes.
Recommendations to Other Teams
Below the team has compiled a few operational security recommendations for other teams based on their experiences and learnings.
- Assume you will be sim-swapped and that your carrier will not protect you. According to the many security professionals the team spoke to in the aftermath of the attack, all major cell phone carriers (Verizon, AT&T, and T-Mobile) are extremely vulnerable to this kind of attack. If you rely on one of them, no amount of personal preparedness or vigilance will prevent you from being attacked. You need to operate under the assumption that your phone number can and will be compromised, and prepare your team accordingly.
- Still, there are some steps you should take to improve the security of your phone numbers. These include paying for a higher tier of carrier security, flagging your account as likely to be the target of fraud, and placing high-visibility team members’ phones under a business service plan with additional authentication factors required for account changes. Alternatively, some teams may wish to use a secure-sim provider like Efani for comprehensive, enterprise-grade security
- Have a standard, well-documented incident response plan in place and educate/prepare your team to execute against it. Ideally, your incident response plan should include establishing a core/minimal group of responders; identifying the E2E-encrypted channel first-responders will use to coordinate (eg Signal); appointing an incident commander to lead the response; and setting a plan for 1) informing stakeholders, 2) preventing lateral movements, 3) assessing scope of the attack, and 4) reestablishing full control of accounts & services.
- Establish a regular cadence for reviewing and modifying your security policies and practices. Things in this industry change exceptionally quickly. Your wallet balances, X followers, users, TVL, volume, and other threat attractors can 10–100x in days or weeks — and can do so several times over in the matter of months. What made sense last month or last quarter might not be sufficient this quarter
- Don’t hesitate to involve the relevant law enforcement agencies (e.g. police, FBI, etc…) during the attack. Law enforcement can help service providers (e.g. X, cell phone carrier, etc…) prioritize your requests by 1) demonstrating the seriousness of your situation and 2) defraying legal liability for reinstating accounts or providing private account information where necessary. (This second point is subtle and worth explaining: After you file a police report, service providers can more easily take super-admin actions on your behalf because the report protects them from the risk you’re making a false claim, since now you will face criminal charges if your report is false)
- Squat on domains and X handles that sound like they could belong to your team. During the attack, the attackers purchased multiple domains that were very similar to Skip’s real domain (skip.money), including skip[.]finance and skipprotocol[.]com, and reposted the phishing site to new domains as necessary to avoid DNS and wallet blacklists. If the team had been squatting on all domains that sounded plausible, the scammers might have been forced to use a less credible-sounding domain that users could have more easily identified as fake (e.g. skip2[dot]money)
All Comments