APT28 Hackers Caught Hijacking Legitimate LoJack Software May 2, 2018 https://www.bleepingcomputer.com/ne...-caught-hijacking-legitimate-lojack-software/
Per the article: Is this config file extracted from an installer and if not how does it get put on the drive? I would think that it would have to exist in the installer to be modified as part of the installation. Are these installers not digitally signed? If so then yes, an AV should be able to detect these are being tampered with.
Because it's such a slight modification to the LoJack binaries, a lot of AV's will fail to detect it, the same happened with the rogue CCleaner version. Only way to block this or to limit damage is to monitor all processes with a behavior blocker. For example, with anti-exe you could have blocked it from running other malicious executables, and with file/folder protection you could have blocked it from getting access to important data. Not to forget, with anti-logger/HIPS you could block it from keylogging. I'm guessing that blocking outbound connections was not an option because it needs it to track and locate devices.
That's my point though. If the binaries were changed, a single bit flip would change the checksum and break any digital signature if there was one. And the CCleaner incident is the only reason I even thought about this. I find both of these highly suspect and will never use anything from either company again.
Well, apparently it doesn't work this way? Because I don't remember reading about AV's that were able to catch the rogue CCleaner version. It would be cool to test this type of malware against "machine learning" anti-malware tools who claim not to need any signatures in order to catch malware.
They weren't. Because it had a valid digital signature. A lot of AV will automatically trust such software. You can't alter the already signed file without breaking it. Else there would be no point in having one. Therefore it has to be altered before it is signed. I could speculate about how I think that is happening but nobody seemed concerned about the possibilities last time so I guess I will just make a personal note to self to ban these companies from any usage I have control over.
If AV will auto-trust signed software then it's a pretty crappy AV. I do believe that most AV's don't monitor signed/trusted software, and that's why specialized behavioral monitoring tools are often better. These kind of hacks on LoJack, CCleaner and GOM Player a few years ago, proof that it's not always enough to simply rely on the Win Def + Win Firewall + "not being click happy" strategy. Now that I think of it, this attack on LoJack could have been even worse because it involves a system service and driver, and because of the way that Windows is designed, security tools can't monitor the kernel. But I believe the driver part was not hacked/modified, if it was then it might have been game over.
That was somewhat my point. I'm not sure if we're agreeing or not... I don't know how possible it would be, but if all software had a database of checksums they registered with the AV vendors, anything that didn't match should be stopped until it could be verified as messed with or not. Probably too cumbersome.
What I'm saying is that I expect an AV to scan all, never seen before executable files (signed or not) with the signatures/heuristics scanner. You say that a lot don't do this, which is hard to believe, but you may be right. But apparently it's easy to bypass this AV component anyway. I also wonder if behavior blockers from AV's will monitor apps that are signed and deemed safe, probably not. That's why I still prefer stand-alone HIPS.
Depends on what component you are referring to. Signatures and heuristics/behavior checking are N/A to the realtime scan engine. However, signatures are factoring in to the reputation validation checking upon file download. There is a SmartScreen "glitch" that was demonstrated where it is possible to sign a malicious PowerShell script with a certificate from a validity signed one. What was shown was that SmartScreen wasn't verifying the downloaded file hash to that given in the certificate.
What do you mean that the real-time scan engine does not use signatures and heuristics? This doesn't make any sense. What I'm saying is that most AV's have got behavior blockers/HIPS but I bet they don't monitor apps/processes that are not caught by the signature/heuristics scanner. So this would mean that these kind of targeted attacks would probably easily bypass BB's in AV's. In contrary to specialized tools which you can configure to trust no app, not even signed ones.
First, note that reputational scanning is always performed prior to any other scanning activity. Here, certificate signature would be one variable in determining the ranking status of an executable along with other factors such as wide spread use, etc.. What I meant was the real time engine will scan a file regardless if it is signed or not. If there is no AV signature detection but suspicious activity is found via heuristics/behavior then prior reputational status will be factored in the determination of if the executable is safe or not. Also some security solutions allow for customization in regards to whether signed files should be always trusted or not.
New info on the hijacked LoJack (APT2 implants where the binary includes a fallback IP — the implant was able to connect to the C&C even if the domain was sinkholed or blacklisted. The threat is explained in greater detail here: https://www.lastline.com/labsblog/apt28-rollercoaster-the-lowdown-on-hijacked-lojack/
