Weird Results for this File

Sandbox Breaker - DFIR

Level 12
Thread author
Verified
Top Poster
Well-known
Jan 6, 2022
538
1,723
1,069
Inside a sandbox.
1691693869891.png

Not Signed


1691694045165.png

Signed and Trusted?

GPT Says its Emotet.
1691694105519.png


Just wanted to post this...

File can be downloaded on triage.
 
Last edited:
I didn't spend any time on this busy was wondering why it says signed when VT says it's not.
I wouldn't trust a verdict from GPT. I think of GPT as a WebMD version when comes to indicators of compromise or in human terms.... medical symptoms.

"Web MD, I got a headache"

WebMD: it's probably cancer
 
Just a thought- the dropboxupdate.exe connections out to their server (162.125.8.20 and 162.125.3.13) has been classed as suspicious by some for a couple of years, probably (but not certainly) due to Emotet at one time hijacking DropBox to spread.
 
Where exact does this specific file come from/found = source?
DropboxUpdateSetup.exe 1.3.761.1

Some of the data is a bit weird. The certificate looks manipulated:

2023-08-12_10-49-56.png


but that does not automatic means, malicious. One have to compare it with a original " update " file from Dropbox main site. I was actually able to find the exact same version number that also have zero flags on VT, and where VT shows the signature correct/valid:


2023-08-12_11-03-32.png


Same version number, but different Hash values. Even the compile date on these 2 files is exact the same, so that's weird. But the first submissions dates are different. Lets see what the original file from Dropbox url shows with the signature:

2023-08-12_11-13-45.png



2023-08-12_11-32-01.png


2023-08-12_11-32-25.png


PE Header and the Overlay Hash is different. Also got some " appended " data.
 
This is exactly the same issue as with the Glasswire download we also analysed. Dropbox is also one of those vendors who save data in the certificate, so that the certificate is not broken.

It is not VirusTotal that is weird but Microsoft Windows being weird in allowing manipulated certificates as valid unless you opt-out.

And the reason for allowing it is, well, companies like Dropbox abusing this vulnerability in legit installers. Why? Imagine you download something from a dropbox link but have no dropbox installed. How will it know what you wanted to download without putting this information into the installer somehow? That is why. They cannot sign the installer for each and every download and they do not want to use non-signed ones. So they inject the data into the certificate instead.

@upnorth was completely correct here in his assessment and despite the manipulation the file is clean. VT is also correct.
 
Last edited: