Read on Twitter
So, I’ve seen folks pointing out that Dominion Voting Systems uses #SolarWinds.
DVS definitely uses the SolarWinds Serv-U product; however, according to @AlexaCorse, they do not use the Orion product line. (1/n)
DVS definitely uses the SolarWinds Serv-U product; however, according to @AlexaCorse, they do not use the Orion product line. (1/n)
Folks suggesting the Dominion Vosting Systems use #SolarWinds products are basing it on this public facing system that bares the SolarWinds logo; however, this system runs Serv-U, a secure file transfer utility SW acquired from RhinoSoft in 2012. (2/n)
Since I first accessed the page around 6:30 EST 12/14, it appears to have been taken down. Regardless, the product is not part of the Orion suite. (3/n)
Before posting this thread this morning, I checked again and the page was back with all references to SolarWinds in the footer removed. While conspiracy theorists might say they’re hiding something, I think they are trying to avoid more press. Let’s dig deeper on Serv-U. (4/n)
The docs on SolarWinds site shows the product installing to “C:\\Program Files\\RhinoSoft\\”, which, at the time of this tweet, is not a directory included in any of the IOCs associated with the SolarWinds attack. I verified the path by downloading and installing a trial. (5/n)
I also checked for the infected DLL file, SolarWinds.Orion.Core.BusinessLayer.dll, in the install directory, and it was not present. (As expected since this tool is not part of the Orion suite). File hashes of all installed files included for comparison to non-trial version (6/n)
I noticed the Serv-U version I analyzed was released during the time of the known compromise, so I analyzed the binaries for strings unique to the malware included with the Orion suite, and found none. (Ex. avsvmcloud[.]com) (7/n)
![I noticed the Serv-U version I analyzed was released during the time of the known compromise, so I analyzed the binaries for strings unique to the malware included with the Orion suite, and found none. (Ex. avsvmcloud[.]com) (7/n)](https://pbs.twimg.com/media/EpSKt2ZXEAUZxA2.jpg "I noticed the Serv-U version I analyzed was released during the time of the known compromise, so I analyzed the binaries for strings unique to the malware included with the Orion suite, and found none. (Ex. avsvmcloud[.]com) (7/n)")
![I noticed the Serv-U version I analyzed was released during the time of the known compromise, so I analyzed the binaries for strings unique to the malware included with the Orion suite, and found none. (Ex. avsvmcloud[.]com) (7/n)](https://pbs.twimg.com/media/EpSKt2dW4AUfAes.jpg "I noticed the Serv-U version I analyzed was released during the time of the known compromise, so I analyzed the binaries for strings unique to the malware included with the Orion suite, and found none. (Ex. avsvmcloud[.]com) (7/n)")
2 possible ways to be completely sure the program was not infected.
1) Do binary diffs between the pre-breach 15.1.7 files and the mid-breach 15.2.1 files and rev. eng. the diffs.
2) Run the software in an isolated, domain-joined system and monitor closely for IOCs (8/n)
1) Do binary diffs between the pre-breach 15.1.7 files and the mid-breach 15.2.1 files and rev. eng. the diffs.
2) Run the software in an isolated, domain-joined system and monitor closely for IOCs (8/n)
I don’t have access to the 15.1.7 binaries, nor the time to hunt them down, at the moment. If the files had been compromised, the diffs should be pretty obvious since SW hasn’t even bothered to change the install path of this piece of software they acquired it 8 years ago. (9/n)
Last, I don’t plan to monitor this software package for 12-14 days because their is no evidence in the any of the SolarWinds breach reports, IOCs, or known public information that suggests it was part of the attack, and everything I analyzed supports that assertion. (10/10)