She asked me to revert to an old version of SupportAssist to solve the problem.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.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.Once I found that option, I couldn’t proceed without a service tag.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”.This blog post is really meant to focus on the whole community, so I will summarize:.
I think they responded well to the whole situation. 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. You share your thoughts with the community on VirusTotal and even on Twitter since others are wondering the same thing. 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 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. 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.
#Trusting obscurity serial
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.įirst 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?
#Trusting obscurity software
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.
#Trusting obscurity series
The first of a series of problems was that these binaries were originating from the Dell SupportAssist agent. Dell SupportAssist binaries SupportAssistLauncher.exe DSAPI.exe BDBICExtractor.exe