Post Sunburst MDR

Introduction

On April 22, 2021, many SOC’s and MDR services were going about their normal day-to-day operations, when some of us across the community received an alert from our EDR platforms for some or all the following Dell binaries:

The first of a series of problems was that these binaries were originating from the Dell SupportAssist agent. In previous years, when Software Supply Chain attacks were less prevalent, many of us would have marked the alert as benign and moved on without giving it too much of a closer look, because we inherently trust hardware and software suppliers like Dell.

However, you’ve been in multiple meetings lately and read articles such as the below from multiple agencies pushing Zero Trust, Zero Trust, Zero Trust, because of the SolarWinds SunBurst incident. But realistically we know there are difficulties of a full end-to-end Zero Trust implementation, especially for a small to medium business (SMB) managed detection and response (MDR) provider who provides services to other SMBs.

First the SMB may not have implemented, be prepared for, or even have considered implementing a Zero Trust model. So kudos to you as a service provider for trying to build that into your service, but it may not bolt into the customer’s existing policies or environment. Then as a third-party service provider for the SMB, you may not have the authorization to perform inquiries on behalf of the SMB or you may not have access to the accounts, serial numbers, service tags, product numbers, license keys, or other necessary items necessary to ring up their suppliers. It continues from there, but we don’t necessarily have to take that as a hard stop to deconfliction do we?

So, we continue our analysis, with Zero Trust in mind. If you tracked it down a little further, you would have found that Dell was really pushing out updates. That may have then given you a warm and fuzzy and you may have stopped there. But, maybe still you just could not let it go.

Maybe you saw articles a couple of years back about vulnerabilities with SupportAssist, so you still look a little closer. You look for release notes for SupportAssist, but cannot find any on this BDBICExtractor.exe. But, eventually, you exhaust all efforts short of reverse-engineering the binaries that triggered your EDR, especially BDBICExtractor.exe with its weird creation timestamp, lack of signature, and other weird behavior.

What really gets you is you know that the ServiceShell is legitimate, but what if it was being used for malicious purposes?

Resolution through Community Collaboration

You share your thoughts with the community on VirusTotal and even on Twitter since others are wondering the same thing.

Then you take a leap, and you decide to call Dell. I am not really going to focus on Dell’s processes, because this post is not a knock on Dell. I think they responded well to the whole situation.

• This blog post is really meant to focus on the whole community, so I will summarize:
  • First, I went to a support page, and I had to look around through categories of products until I found “Dell SupportAssist for Business PCs”.
  • Once I found that option, I couldn’t proceed without a service tag.
  • I had to cross-reference hostnames that were in the alerts from the EDR with my customer’s asset management solution to then find a Service Tag that was still under warranty and after submitting several, finally I found one that got me a chat window.
  • In the chat, I got a bot that I had to play with that eventually got me to an agent. The agent was great, I explained the problem.
  • She asked me to revert to an old version of SupportAssist to solve the problem.
  • I kindly asked her to escalate it to the Dell Security Team and she gave me a number to the Dell Data Security Team which would be available the next morning (it was late in the evening Eastern time when I was doing this).
  • The next morning, I spoke with a very knowledgeable gentleman with the Dell Data Security Team who explained to me that the Carbon Black team (Dell internal) had also alerted to these binaries and that they were working with the Dell SupportAssist Team to deconflict.
  • I explained everything up to this point, including the binary not being signed, others with the EDR in the community trying to deconflict, the need for Zero Trust post SolarWinds and I asked if they could post something back out to the Threat Intelligence Feeds or release some type of article to update the community.
  • I also recommended a deconfliction method going forward and I stated that it is not a Dell problem it is a whole of community problem that we need policy to address the whole thing.
  • I gave him contact info which he kindly took down.

Sometime later they did post an article stating that they did sign the binary and made some other updates.

Recommendations to Suppliers and Policy Makers for the Future

Going forward our major recommendation is not specific to Dell, it is really to all major hardware and software suppliers. To better implement a Zero Trust framework and alleviate the pain points, particularly for your customers’ internal and third-party cybersecurity providers:

• We need a central deconfliction point with knowledgeable cybersecurity personnel who sit between your different business units that we can come to for rapidly deconflicting situations like these. This includes:
  • A message board of articles post with deconfliction articles.
  • Include MD5, SHA1, and SHA256 hashes
  • A phone number and/or chat window with a real human.
  • No requirements for serial numbers, etc to initiate contact with a human.
• As COTS, GOTS, and FOSS suppliers develop more secure code and defenders shrink the attack surface with the Enterprise, attackers are going to continue to seek alternative ways in, as we saw with SolarWinds and we continue to see with several of the open source repos like NPM. Software supply chain attacks will continue to grow to be more prevalent than ever.
  • We need to encourage customer cybersecurity personnel to deconflict activity more often instead of inherently trusting it and marking it benign. This should not be seen as an inconvenience to major software suppliers. This should be seen as a community extension of the security team and tools you already have in place.