To trust or not to trust?
Trust brings together two hot topics that concern our users. First topic - Win32:Injected-AZ which is suspected by many users of being a false positive. Second topic - the reliability of digital signatures (authenticode). Here these two topics intersect with some interesting circumstances (that will be soon elaborated):
As you can see from the table, the Aventura package has a valid digital signature. In this case the detected binary is not signed, but its container (WebClient.cab) is properly signed. This means you are supposed to trust the binary when you approach it from outside (and so perhaps does your browser in default settings?!). As in real life - where you are responsible for everything you sign - the developer is responsible for what he puts into the package and what he certifies. Remember, the balance between benign code injection and malicious code injection is on a razor's edge. A similar example also arrived at our FP submission system:
First to mention, Win32:Injected-AZ is not a false positive at all. Binaries detected under this name contain evident signs of unintentional tampering (caused by a file infector - Win32.Foroux.a). When we look inside, we can see the following parts of code injection:
A close look makes it obvious - this injection (in the last section) is not a part of the original code. However, the digital signature should guarantee that a file really comes from its respective vendor in an unmodified state. Let's check the signature - is it broken?
What? It isn't? The signature is valid according to the WinTrust certificate verification. This implies that the binary was injected before the signature was added. A wild, sci-fi scenario is that there was a certificate leak similar to the Stuxnet case, but I seriously doubt it. I tend to believe a scenario where this binary has been passed through the signing and releasing process due to a human error. Well, everyone may fail from time to time, but there should be some methods in place to avoid such things. To be honest, this binary is quite old (v 18.104.22.168 signed in 2002) and I don't want bash Symantec for such old incident, but someone must still use this version when it appears in our FP submission system. This is an example of what can happen with an overlooked injection (and this injection seems to have been overlooked by many users and even SW developers for years). Fortunately the malcode inside seems to have never been executed, therefore this specific case is not a critical issue. But generally - such unintentional modifications (malicious or not) should not stay under the radar when we want to trust in the safety of properly signed binaries (especially that this injected and signed binary was a part of Symantec security products). What surprises me a bit is the fact that no one else detects the injection (or maybe they have suppressed their detection if they find a "valid" signature):
I'm now expecting more Win32:Injected-AZ hits from various edges of world. There's also a possibility that it has also penetrated clean sets of some respected testers (they can easily check it if they read this article). We often see MS redistributable packages containing this injection (but their digital signatures are broken):
Anyway - if you encounter this detection on your PC, replace the infected binaries with original ones. And if the original binaries are also infected, ask their vendor to provide you with clean binaries.
Highly effective Cerber ransomware is spread via phishing emails and demands more than $700 in ransom
Based on analysis of past Locky ransomware attacks, experts in the Avast Threat Labs predict that another attack is imminent.