Blog Spotlight

todayJuly 9, 2021

Cyber security + Software Supply Chain Cybersecurity Daniel West

Software Supply Chain Targeting – Who Will The APTs Target Next?

Introduction After I saw the buzz about Kaseya on July 2nd, I decided it was time to start writing a blog post about targeting the supply chain.  Software supply chain “attacks” aren’t new, however, they will become much more mainstream now that there has been extended media coverage of the SolarWinds incident. You may have noticed a similar [...]

Top Voted Blog Posts
Sorry, there is nothing for the moment.

Post SUNBURST MDR, Zero Trust, and Deconfliction within the Supply Chain – A Case Example of a Broken Process

Cyber security + Service Line + MDR + Software Supply Chain Cybersecurity Daniel West todayMay 7, 2021 249 1

Background
share close

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:

FilenameMD5 HashSHA-1 HashSHA-256 HashVirusTotal
Dsapi.exe 52fdd8a255fd3d57b8ba3bb238306a32 90f76ea1907192720ec6a85301b0656004de78e6 9ae19f49304fbd27cf07a76e861f3288165bc809de20e32dd8f2dddda59066af https://www.virustotal.com/gui/file/9ae19f49304fbd27cf07a76e861f3288165bc809de20e32dd8f2dddda59066af/detection
Bdbicextractor.exe7c66b4197a3f583e185ca0d9fdbad175 3af2c7e037b09ca5fd301015f0c5b02c4d63ceab 62a8ef2ab3af3d1ed3b5db9a90df839299c6ab7effbce2fc88cc5430bc4d744d https://www.virustotal.com/gui/file/62a8ef2ab3af3d1ed3b5db9a90df839299c6ab7effbce2fc88cc5430bc4d744d/detection
SupportAssistLauncher.exe bd40d675e191b89c4f1d8267eef299a7 ec76370c4adefcc43ee28fb157202efd17ce4a1a ab3a3aaea895763c74000829d7d46582bd678aa8cb002977cf330c605bfd1127 https://www.virustotal.com/gui/file/ab3a3aaea895763c74000829d7d46582bd678aa8cb002977cf330c605bfd1127/details
Bradbury.invcol.9.5.2.1.dll 54ad701eae82f187de8709218e154995 9a146e76f254929bf7fd47fd2aebc3722e940cd8 eef5fc1e64f85981af7bffa11087667b8300b584bbcaf11b61fedfbc85b5d1e4 https://www.virustotal.com/gui/file/eef5fc1e64f85981af7bffa11087667b8300b584bbcaf11b61fedfbc85b5d1e4/detection
Table 1. Dell SupportAssist binaries
SupportAssistLauncher.exe
SupportAssistLauncher.exe
dsapi.exe
DSAPI.exe
BDBICExtractor.exe
BDBICExtractor.exe

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. 

https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

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. 

Written by: Daniel West

Tagged as: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , .

Rate it
Previous post

todayNovember 25, 2020

  • 227
close

Malware Alexander Rymdeko-Harvey

Match Made In The Shadows: Part [1]

Intro Not too long ago the security community was rocked with yet another leak from the #ShadowBrokers[1]; causing an impact worldwide with point and click Domain Admin vulnerabilities. Affecting nearly ...


Similar posts

Cyber security Daniel West / June 17, 2021

UNC2465 Software supply chain attack

Quick intel drop. FireEye has reported that the DarkSide affiliate, UNC2465, has infiltrated the website of “CCTVSecurityPros” and injected into one of their software downloads. Below are the details. FireEye Article: https://www.fireeye.com/blog/threat-research/2021/06/darkside-affiliate-supply-chain-software-compromise.html Joe’s Sandbox Report: https://www.joesandbox.com/analysis/432180/0/html  Malware for those of you who want to perform your own analysis: https://github.com/obscuritylabs/UNC2465/tree/main/21JUN2021_supplychainattack

Read more trending_flat