Bad Rabbit

The Bad Rabbit outbreak that started Tuesday morning UK time has produced enough analysis through the rest of the week to write about properly. The first wave hit a number of Russian media organisations, the Kiev metro and Odessa airport in Ukraine, and a small number of organisations in Bulgaria, Turkey, Germany and Japan. Approximately two hundred organisations affected on initial counts; the actual operational impact has been moderate compared to NotPetya in June (ESET preliminary write-up, October 24, Kaspersky Securelist analysis).

The technical pattern is interesting because it is a hybrid. The initial-access vector is a drive-by-download on compromised legitimate websites, presented as a Flash Player update — a 2010-era technique brought back into service against a population of users whose browser-and-Flash-update-prompt training has not held up. The dropped binary then attempts internal lateral movement using two mechanisms: credential-harvesting via a Mimikatz-like component (the same approach as NotPetya), and brute-force authentication against SMB shares using a built-in dictionary of common passwords. Network propagation does not, in the analysed samples, use EternalBlue — which is the most interesting differentiation from NotPetya. The actor has either chosen not to use the SMBv1 exploit (perhaps because the post-WannaCry, post-NotPetya patching environment has reduced the productive target population), or did not have access to it. The ransomware payload, unlike NotPetya, appears to be functionally a real ransomware (decryption is feasible if the operators chose to provide keys, although the operational evidence on this is limited).

The attribution question is the part that is going to take time to resolve. The technical signatures have substantial overlap with NotPetya — the partial code reuse has been documented by ESET, Kaspersky, and Cisco Talos in independent analyses — and the targeting (Russian and Ukrainian organisations, with the operational pattern suggesting reconnaissance-led targeting rather than mass spread) is suggestive. The initial-access vector — compromised legitimate Russian and Ukrainian news websites — is itself an operational indicator: the actor had to compromise multiple legitimate sites to seed the drive-by, which is non-trivial work and reflects sustained pre-positioning. Whether the same actor is responsible for both Bad Rabbit and NotPetya is being assessed, and the public attribution will firm up over the coming months.

For the operational response, the action items are similar to NotPetya. Verify the EternalBlue-related patching, even though Bad Rabbit does not use it, because the conditions that made unpatched SMBv1 productive have not changed. Ensure credential-hygiene posture (no shared local-admin passwords, regular rotation, network segmentation that prevents administrative tools from spanning the network). Monitor for the specific indicators-of-compromise published by ESET and Kaspersky. For the user-facing defence, the Flash-update social-engineering vector is a useful reminder that consumer-style attack patterns continue to be effective against enterprise users in numbers that should embarrass us in 2017. User awareness training is ineffective at scale; the technical mitigation — enforce browser-managed update channels, block direct downloads of plugin installers from non-vendor domains, segment the user-population endpoints from the operational systems — is more reliable.

The thing I keep noticing across the WannaCry-NotPetya-Bad Rabbit sequence is the iteration on technique. WannaCry was the unsubtle worm-grade case. NotPetya layered EternalBlue with credential-theft lateral movement. Bad Rabbit uses drive-by initial access with credential-theft and dictionary-based lateral movement, dropping the EternalBlue dependency. The actors involved (and they may be one actor, or different actors observing each other) are clearly learning from the public analysis of each previous incident and refining their tradecraft accordingly. The defensive posture has to assume continuous iteration; the controls that worked against the previous case are not, by themselves, sufficient against the next case.

For the customer estates, this week has been mostly verification rather than incident response — none of our customers have been affected — but the verification has surfaced a few configuration findings that are worth recording. One customer had local-administrator password reuse across a portion of their workstation fleet that we had assumed was addressed in the WannaCry follow-up; it was not, the change had been partial. Another customer's network-segmentation posture between the corporate workstation network and the production-systems network was less strict than the documented design intended. Both findings are being remediated this week. The pattern — that customer-estate configuration drifts away from documented intent over time, and that incident-driven audit is what surfaces the drift — is one I want to write a longer piece about. The discipline of continuous configuration audit, separately from incident response, is one that few customers have at the level the threat landscape requires.

I will write more if the Bad Rabbit attribution firms up substantially. The signal-to-noise on attribution at one week is low, and the operational lessons do not depend on the attribution.


Back to all writing