Often times, they will just buy a code signing certificate and sign their malware. I've tried to create Group Policies to prevent malware with these signatures from running (SRP). I even have a list of serial numbers, organization names, and issuing CA's of certificates associated with malware.
Unfortunately, I've only found one CA willing to provide the public key for the corresponding certificate serial number. Apparently "public" keys aren't really public. I'll just have to add the certs as I find infected EXE's and extract the public certs from them.
As you can see in the screenshot, it copied the SHA1 and the SHA256. The issue with Digital Signed files is that, there are a lot of security products that will not scan the file if the sample is "Signed" by a trusted company.
Another problem with digital signatures and AV products is that most have an option to just auto-allow programs which are digitally signed. This means that it will no longer matter if the malware is signed with a stolen certificate to an ethical and trusted company or if the certificate had only just been bought.. maybe even for personal uses and using a fake name.
The adware point you put in your post is very important because I can guarantee most or at least a large majority of adware is actually signed... meaning if that digital signature feature is present on the AV product to auto-allow digitally signed programs and was used because the user thought it would be good to use.. or if it was auto-enabled... then that adware is going to get through easily !
Peoples who have experience in the malware development field and have good knowledge to do bad should be able to afford a code certificate of their own to sign their samples anyway.. or can easily just steal another.
The third part is using the first and the second techniques and inject the file in a safe file. This technique is very good because it uses all what I said above and a clean file.
This method is easier said than done because it is much easier for malware to be caught out whilst trying to do this these days. You'd think that most products now have good behavioral protection against things like process hollowing.. Luckily for us there are indeed products out there like Emsisoft Anti-Malware which have BB protection against things like DLL or PE injection. If only more products out there had better behavoral based protection for new threats... In fact its the same principle with firewalls, inject into safe process and chances are it is bypassed and wont block malicious traffic as its a "trusted" process now doing the work.
The less experienced developers will just use the Windows API to quickly inject a DLL into another process (where the DLL contains the real malicious code to be done in a "trusted" process). But since these methods are so well-known it's improving to detect and prevent this activity. The issue becomes escalated when experienced developers use low-level features of the OS to actually evade detection of doing the activity and can easily outsmart BB/HIPS systems...
Maybe I will make a second part with more ways of bypassing security software and also to show how some security products work with this type of threat.
In other words, there is not quick fix for this type of attacks, the main reason is that security programs are not designed to work like that/this.
Maybe I will make a second part with more ways of bypassing security software and also to show how some security products work with this type of threat.
In other words, there is not quick fix for this type of attacks, the main reason is that security programs are not designed to work like that/this.
