AVLab - "Test of software for online banking protection"

Discussion in 'other anti-malware software' started by ichito, Mar 19, 2019.

  1. Brummelchen

    Brummelchen Registered Member

    Joined:
    Jan 3, 2009
    Posts:
    4,138
    i dont have doubt on such tests, but the goal should be NOT to be intruded this way. the defense line should be established before and not after.
    some need to advise users to change behavior and thinking - the web is not evil in general but it has benefit not to trust all.
     
  2. Spec7re

    Spec7re Guest

    Thanks for the clarification!


    I have to agree with this.

    I think it would be fantastic if everyone around the world can just surf the web, do what ever they want and not have to worry about getting infected, however this isn't our reality. Everyone has to pay attention, just like driving a car. Problem is, people make assumptions that x,y and z product will protect them 100% of the time because a test(s) says so. It's far easier to blame the product rather than oneself. I read all the time on various forums and websites people saying well if you use x product it's why they are getting infected. I feel like saying, no... it's because they did things like open email attachments, click on ad's downloaded and installed random programs, etc... One could argue yes, maybe using y product may have saved you, but there's no guarantee that it would have. No product can protect you 100% of the time, every time, that's the reality. No matter what product someone chooses to use, you still cannot ignore common sense and follow good surfing/security habits, just because you feel like what ever program you are using will save your bacon every single time. If you fall into this trap/mindset, unfortunately you will get bit at some point. It's like when people are shocked that a particular product missed a piece of ransomware, my answer would be, well did you back up your data? It's these simple things, that (ie: having regular backups of your data) will make your life easier in the long run IMO.

    In regards to this test, one point that I haven't seen brought up is the fact that if the website/server itself is compromised, none of these "banking protection" features will keep your data safe unfortunately. These protections are on the assumption that your system is compromised. TBH, I feel like hackers are targeting websites more than home users as they can get more data in a shorter period of time, instead of trying to infect individual's system. Not that they won't try to infect individual's systems, but IMHO, it far more lucrative to infect the site then it would be to infect individual systems, one by one.
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    If this happens, the bank is liable for any monetary losses. However, banks will always invoke "plausible deniability" in any like incidents in an attempt to minimize their losses. Most likely, you will be refunded part but not all of your losses until it can be proven the bank was 100% at fault. One classic example is debit card fraud where money was withdrawn from an account. The bank will argue they are not liable since you must have given someone your PIN. Etc., etc. In any case, one's best protection against bank "shenanigans" is to use a highly rated security product with banking and payment protection. If for no other reason than to counter the bank's almost certain claim that your device was compromised security wise.

    One other thing I forgot to mention about Win 10 native SmartScreen protection. It really cannot be taken to seriously because it runs as medium integrity level process and can be easily disabled programmatically as shown in the below screenshot . In other words, it has no self-protection mechanism. Microsoft just announce they have "beefed up" Windows Defender's self-protection mechanisms. As best as I can determine that does not include SmartScreen.

    SmartScreen.png
     
  4. Spec7re

    Spec7re Guest

    This is very true.

    Usually you can hopefully get some of it back, but like you said they never want to take the blame, so they always try to pin it on the user. Unfortunately its the same if you are using a password manager and you store a long very complex password for your bank account. If you account get's compromised some how, the bank will more than likely blame you for using a password manager (even though password managers are a good idea) and say well, it was the password manager's fault, not ours, so to bad so sad. Furthermore, many banks have introduced 2FA, which is good, however many of them use SMS, which has been proven to be a terrible idea and should not be used. If something were to happen, my guess is that the bank will say, "well it's not our fault, we implemented 2FA, it's very secure", meanwhile there's ample data to prove that SMS 2FA is not as strong as it's thought out to be.

    I have to admit I'm quite happy that they are finally doing this, IMO it was long over due. I'm not to sure if it will include Smartscreen or not, when I first read about it, I was under the assumption that it was to protect more than just WD, so I assumed Smartscreen as well. Their release on this feature was pretty vague (as is many things with MS), as they kinda of said it was to help protect security features, but didn't elaborate which features initially, but it does seem like its WD for now. My assumption is that they will expand what it protects down the road, but I guess we will have to wait and see what happens.
     
  5. FanJ

    FanJ Updates Team

    Joined:
    Feb 9, 2002
    Posts:
    3,982
    Hi itman,
    Would that special crafted .txt file be put on the harddisk of the "attacked" PC?
    If it is and if understanding you right that "the only way to detect it is manually", then I think that file-integrity-checker ADinf32 will detect it.
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    Yes. It is in essence a hidden executable. The author tested it against:
    -EDIT- I also assume here he means WD ATP which is standard issue on Win 10 Enterprise.

    Whether other AV's would be able to detect it would have to be tested. Since WD uses AMSI to examine Powershell scripts prior to loading into memory and it did not detect anything, it is reasonable to assume that other AV's relying on AMSI to do so would also be bypassed. Why? Because the script has already been loaded into memory via the hidden executable. It remains to be determined if any of the dedicated anti-execs are able to detect the hidden .txt executable start up.

    As far as your ADinf32 solution, it appears to be a sandbox that returns whatever activities a process is performing. Again, it would have to detect the hidden .txt file as an executable. If it just scan the code within the file, all it will see is packed, encrypted, and obfuscated Powershell script code. Seriously doubt it would be able to decipher any of that.
     
    Last edited: Mar 31, 2019
  7. FanJ

    FanJ Updates Team

    Joined:
    Feb 9, 2002
    Posts:
    3,982
    If that file is put on disk, then I really think it would be detected by ADinf32. As far as I know it does detect hidden files.

    No, ADinf32 is not a sandbox like program. It is a file integrity checker, on demand. There is more to say about it but that is out of the scope of this thread. We have a special thread for it:
    https://www.wilderssecurity.com/threads/adinf32-version-4-19-08-feb-2015.375574/
    The site is https://www.adinf.com/

    Edit to add:
    If ADinf32 tells you that there is suddenly a new file (in this case from what I understand from you a .txt file) on your disk, then it is up to the user to decide whether that is a legitimate one or not. It just tells you: hey, you have this new file on your disk.
     
    Last edited: Mar 31, 2019
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    The problem is this. If it tells you have you have a new file on the disk, then fine. In the null-byte article, the file isn't hidden, it is in fact sitting on your desktop, or perhaps received as an e-mail attachment, you name it. The assumption here is that some type of phishing trickery is being employed to induce the user to open the file. Note to get to this status, it would have been already scanned by your AV and deemed not malicious.
     
  9. FanJ

    FanJ Updates Team

    Joined:
    Feb 9, 2002
    Posts:
    3,982
    Hi,

    Maybe we have some misunderstanding.
    Actually I was just only replying to this:
    (BTW it could be that your AV is missing detection on whatever file; no AV is 100% sure-proof or how do you say that in English).
    Anyway, I like to leave it to that. Thanks as always itman.
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    Let me explain the article in detail.

    The author chose the hidden .txt executable file method because most will open a .txt file without hesitation. Also I have seen numerous articles over the years stating the same; a .txt file is safe to open. In this regard, nothing received from the Internet can be assumed to be safe.

    The use of notepad in the imbedded .bat script is just a diversion tactic. Notepad will open in response to the clicking the .txt executable as it should. In his example, all that would be shown is a blank file. Hence the author's statements to "embellish" that by showing some actual text. All that is happening at this point is to allow the PowerShell script to run without any suspicion of nefarious activities in process.

    In the code example, PowerShell is running locally. So most Wilders folks who are blocking/monitoring all PowerShell execution are covered. Since Win 10 Enterprise was the test OS, it can be assumed this pen-test is aimed at corps. who do let PowerShell run for various maintenance and monitoring activities.

    If one wanted to pull off a remote execution attack, it might be better to encapsulate wscript; e.g. VBS2EXE, since it is easier to code the remote connection code. However, the same could be done from .bat script running a Win system .exe. For example, regsvc32 scr "Squibbly Doo" method, rundll32.exe, etc..

    The main point of the article was that his PowerShell code was able to bypass the AVs tested against.
     
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    Time to tackle the use of local PowerShell.exe in our hidden .txt executable. Two publicized techniques are PowerShdll and InsecurePowerShell.

    I am not going to spend any time on PowerShdll since it requires either .Net 2.0 or 3.5; neither of which are installed by default on Win 10. It also can be defeated via PowerShell Language mode setting. You can read about it here: https://github.com/p3nt4/PowerShdll .

    InsecurePowershell is the ultimate PowerShell attack method. It will bypass all known methods to stop its execution other than absolute whitelisting. Additionally, it will disable all existing system detection methods to detect PowerShell attacks. Finally, any attempt to detect its modified System.Management.Automation.dll via blacklisting can be easily circumvented by recompiling it as the author explains in his detailed writeup:
    https://cobbr.io/InsecurePowershell-PowerShell-Without-System-Management-Automation.html
     
  12. guest

    guest Guest

    This is just a method amongst many...
    Thinking of relying on whitelisting methods to stop malware is foolish, the only way? strict blacklisting of LOLbins, including dlls and drivers (SRP is favored mechanism ) plus memory protection if possible.
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    I have found another method yet to run PowerShell code without using PowerShell.exe. Will only work on Win 10 Enterprise.

    Reference for this technique is in regards to the publicized LOL SyncAppPublishingServer.exe and SyncAppPublishingServer.vbs abuse: https://safe-cyberdefense.com/malware-can-use-powershell-without-powershell-exe/ .

    We need to use VBS2EXE to build out hidden .txt executable. Copy the following code from SyncAppPublishinServer.vbs:

    untitled.png untitled.png
    Replace the existing PowerShell code with your malicious code. Save as a new .vbs script. Copy that script into VBS2EXE to create our hidden .exe. Your now "good to go." Also believe this would bypass AppLocker's Constrained Language mode restriction since SyncAppPublishinServer.exe is trusted system process.
     
    Last edited: Apr 2, 2019
  14. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,894
    Location:
    The Netherlands
    It's informational, but what does this all have to do with the AVlab test? Because this thread is starting to become cluttered. And did you ask for the PoC? I also wonder where did adrian_sc go. I'm still wondering about how SpyShelter managed to pass all of the tests. Don't get me wrong, I'm glad it did.
     
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    My point is ………. there are an unknown number of ways to deliver malware. When testing malware protection capability, it is imperative to simulate the actual malware delivery as close as possible. Why because these are the methods by which AV vendors build their detection methods against. It is not two decades ago when antivirus protection was 100% static detection on-demand scanning using exact code signature matching. As I keep stating in this forum, there is a distinct difference between malware detection and penetration testing. Just because I can breach a device's external perimeter defenses does not necessarily imply that the technique employed will ever be actually deployed by malware for a number of reasons. And please don't "kid yourself" that existing post execution behavior detection methods will detect every known malware misbehavior when such methods are being discovered on a daily basis.
     
    Last edited: Apr 2, 2019
  16. guest

    guest Guest

    ask user mode?
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    Case in point on the point I am trying to make. Here's the latest and greatest version of the infamous Ursnif banking Trojan: https://securityaffairs.co/wordpress/83396/breaking-news/ursnif-banking-malware.html . All the major AV vendors detect the dropper malicious macro code imbedded in a Excel spreadsheet e-mail attachment. None of the Next Gen vendors which are behavior based detect it.

    If you can stop the dropper from executing, you don't have to worry about any other .exe or otherwise code since they would have never been executed.
     
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    I am going to wrap up my postings in this thread with reference to an excellent technical article by Eset on the Emotet banking Trojan: https://www.welivesecurity.com/2018/12/28/analysis-latest-emotet-propagation-https://www.welivesecurity.com/2018/12/28/analysis-latest-emotet-propagation- .

    As far as I am concerned this is a must read on the "modus operandi" on how banking Trojans infect. In this study, the delivery method was e-mail as is the norm. Of particular note is how the macro based dropper was deployed. If one was to only look at the macro script, there is nothing malicious about it. However, it is designed to execute hidden code within the document. And maybe some have better eyesight than yours truly, but I had to view the Word 365 web page multiple times to see the box in the top left hand side of the web page containing the hidden malicious code.

    The best part of the article is however, how Emotet is actually deployed:
    The persistent aspect of banking Trojans is common and is one of the first system modification activities performed. This could be modification of registry autorun keys, creating a WMI consumer event, creating a scheduled task to run at boot time, you name it. Also characteristic is that this is all that is done during the initial infection phase in most cases. This is simply because it is much more difficult to detect subsequent malware activities at system startup time.

    Again, this is an example why you don't want malware to establish a presence in any form on your device.
     
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,894
    Location:
    The Netherlands
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.