back caretBlog

DoublePulsar Detected

Healthcare organizations have been the unfortunate targets of cyber ransom for years. In fact, according to research by SANS, they suffer more breaches than any other industry. This likely happens for a few reasons. The first is the simple fact that it's easy to get them to pony up—healthcare isn't exactly a luxury, so if all systems go offline, most orgs will take any steps necessary to get data back—including paying the bad guys.

Healthcare organizations also have a lot of connected devices. This includes PCs with medical software and IoT devices. Some equipment might be managed by in-house IT staff, while specialty connected devices might be managed by third parties. It's all a giant pain to inventory, patch, and monitor every device, and the bad guys know it.


Tightening Healthcare Security

I was doing some training with a healthcare organization who was actively bucking that industry trend: They had recently adopted ExtraHop Reveal(x).

We start with Overview. We saw two security detections in the last hour. One detection is for DoublePulsar.

Double Pulsar Detection in Reveal(x)

Some quick background on DoublePulsar: It's a nasty backdoor implant that was leaked by a hacker group back in 2017, and it affected something like 200,000 Windows machines. It was used in the notorious WannaCry ransomware attack that (among a long list of other victims) nearly shut down England and Scotland's National Health Service (NHS). Ambulances were diverted, patients were turned away. It was bad.

DoublePulsar works like this:

  1. Ping: Look for targets
  2. Kill: Terminate program
  3. Execute: Implant code, take over target

EternalBlue: Also a backdoor. Also bad. Also used in the WannaCry attack.

Back to the detection:

The offender is a medical device (a PC running medical software) at one facility doing a DoublePulsar SMB/CIFS scan of a Windows 10 workstation at a different facility.

DoublePulsar SMB/CIFS Scan in Reveal(x)

Red Flags Galore

Red flag number one: Cross-facility traffic shouldn't happen. A medical device reaching directly to a win10 workstation at a different facility really shouldn't happen. We flag this as an action item for the network team.

Red flag number two: The offending medical device had been previously infected. This device in particular is one that is managed by a third-party vendor. The vendor who managed the device attempted to surgically remove the contagion. As a rule of thumb, that's either lazy, or incompetent, and you can never really be sure you got all the infection. The only way to be sure you removed the contagion is to wipe the PC and completely re-image, aka nuke and repave.

While it had been isolated via network containment once it was found to be infected, the isolation was removed about a week before. It seems the cleanup wasn't full and complete.

It's pretty clear at this point that the offending device is still sick, which leaves us all wondering, "what did the vendor do?" Flag this as another action item for the team managing the vendor.

Adjusting Detection filters for the offending medical device as Offender, we saw 54 detections in the last 3 days: TCP SYN Scan, DoublePulsar Scan, DoublePulsar Implant, and EternalBlue. In other words: recon, recon, attack, attack.

Signs of Reconnaissance and Attack in Reveal(x)

The class comes to a full stop.

Student #1: "Ok, Student #2, I'll call you on your mobile. This workstation is infected. We need to take this machine offline."

I offer to pause the class while the customer investigates and hopefully drops Lucifer's Hammer on the offending medical device.

I'm paraphrasing Aliens (1986) here, but Ripley was right: Nuke the site from orbit, only way to be sure.

Ripley was right: Nuke the site from orbit.

Related Blogs

Sign Up to Stay Informed