Interesting. Doubt if anything could have been done to prevent this since it would be reasonable to assume that required regulator software would be malware free. On the other hand, an example that no PC base software from anywhere from anyone can be fully trusted. Also appears this was 0-day malware since I assume the clients were being scanned by AV software? Or perhaps, its scan parameters excluded the regulator software? Or in the worst case, the clients didn't have AV software installed.
Even if they had AV software installed: The malware was obfuscated, encrypted and was not detected by any available AV-solution: Edit: change of URL
an external JS file was loaded, which could have executed malicious payloads on selected targets This implies the script was executed remotely. Appears the KNF server was infected. Receiving bank client PCs were of course configured to receive remote traffic from the KNF server which could also include remote execution on receiving bank client computers. To be determined was if the KNF server had adequate security software to process packed and obfuscated scripts. For example, Win 10 client OS has the AMSI interface that was designed to do just this which some third party AV security products utilize.
You're kidding me right? Why do you think that "Next Gen AV" is so popular. It's because of behavioral monitoring, you should never blindly trust apps, unless you haven't got a choice. So what I'm saying is, this hack could be easily stopped with HIPS/BB.
No I don't. The point that I'm making is that even apps that are "most likely" not malicious should still be monitored with HIPS. This means you could block the malware from making certain outbound connections and getting access to certain files/data. There are also examples of legitimate tools like GOM Player and Ammyy Admin that were replaced with malware by hackers. If people only relied on AV's (easy to bypass) they were owned, but HIPS can easily identify unusual/suspicious behavior.
Thanks Ronjor...it's a bit less shame when we know that it can be broader attack than we considered earlier.
Eset has a detailed analysis of this attack here: http://www.welivesecurity.com/2017/...Feed: eset/blog (ESET Blog: We Live Security) . Also it was used against Mexican banks.
Care to explain? If you block code injection and restrict exploitable apps, then even "in-memory" malware will have a hard time doing any damage. Just what I thought. So HIPS/AE can block the execution, but let's say it somehow still manages to run, you can still block service loading. If that fails, you can block code injection. Like I said, none of these "highly advanced" malware attacks can not be stopped with current security tools.
True. But in reality, not practical since the user will receive constant alerts whenever any system or app process is updated. Whereas app changes to registry can be HIPS "whitelisted," not so easy to do for system processes. Nor do I think "global" parameters like allow trusted system processes to perform these activities is advisable since they can be injected with malware or credentials hijacked. Also, just exactly how would you block service loading in a HIPS? Most service based .exe's load at startup time. Also, I know of no HIPS that has options to monitor service loading other than changes to registry startup keys; if that is what you are referring to.
You're overthinking it. HIPS have always monitored installation of new services and drivers. And only system services should be trusted automatically to avoid system malfunctioning. Plus most apps have no business registering a service. Perhaps it's a good idea to read about behaviors that HIPS should be monitoring: http://www.matousec.com/info/articles/features-of-modern-security-suites-part-2.php
Depends on the HIPS used. Also many will allow w/o alert, service/driver installation from trusted installers and Win system processes. The only "foolproof" way to prevent malware installation is direct monitoring monitoring of reg. keys where same are stored. In regards to the Matousec article in the "Potentially Dangerous Actions and Techniques" section:
The latest "twist" on this hack is the perpetrators used "blame the other guy" tactics: Malware Used to Attack Polish Banks Contained False Flags Blaming Russian Hackers https://www.bleepingcomputer.com/ne...ontained-false-flags-blaming-russian-hackers/
Yes of course, but if it's not monitoring service/driver loading and manipulation, it's not a good HIPS. And I already mentioned that it's probably best not to auto-trust apps, I almost never use the trust option. BTW, in AutoRuns you can see all services and drivers that are installed by non-system apps.
BTW, totally forgot to mention that HIPS should always monitor system tools like powershell.exe, netsh.exe and sc.exe, because they can also be used for stuff like network access and service loading. That's why a tool like EXE Radar is so handy, it will always alert about the launch of these system tools, no matter if the parent process is trusted.
I wouldn't make any assumptions on what a HIPS does or does not monitor. You would be surprised what is not monitored by default. You have do your own "leak" testing to verify what is monitored.
Where do you see me making the assumption that all HIPS do in fact monitor the same stuff? I just said they SHOULD be monitoring the stuff that is mentioned in the Matousec article, and then some.
Why am I not surprised by this. I also mentioned this possibility in the recent U.K. banking attacks.