A rash of invisible, fileless malware is infecting banks around the globe

Discussion in 'malware problems & news' started by lotuseclat79, Feb 8, 2017.

  1. ExtremeGamerBR

    ExtremeGamerBR Registered Member

    Joined:
    Aug 3, 2010
    Posts:
    1,351
    I aparently don't use ANY PowerShell command. If I block execution on C:\Windows\System32\WindowsPowerShell I would be able to block this malware?

    EDIT: I wil have to autorize PS execution to update my Windows? There is any SIMPLE (I don't like bloated software like Comodo) that must be able to defeat this attack vector?
     
  2. TomAZ

    TomAZ Registered Member

    Joined:
    Feb 27, 2010
    Posts:
    1,131
    Location:
    USA
    Not to take this off-topic, but Is SSM somewhat similar to Winpatrol?
     
  3. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    For me it was Process Guard, then System Safety Monitor, then Malware Defender. After moving to x64, no more HIPS :)

    It looks like more and more system tools have to be "watched over" by some 3rd party application to monitor what they're doing.
     
  4. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590

    No it isn't, and this is off topic!!!!!
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I hate to bust the anti-exec's crowds "bubble" when it comes to monitoring Windows utility processes. Most if not all can be executed indirectly using the application programming interface i.e. API. Below is a coding example for creating a service using a C++ program:

    SC_HANDLE h_manager = NULL;
    SC_HANDLE h_service = NULL;

    h_manager = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS);

    h_service = CreateServiceW(
    h_manager, // SCM database
    L"MyService", // name of service
    L"My Service", // display name
    SERVICE_ALL_ACCESS, // desired access
    SERVICE_WIN32_OWN_PROCESS, // service type
    SERVICE_AUTO_START, // start type
    SERVICE_ERROR_NORMAL, // error control type
    L"c:\\abc.exe", // path to service's binary
    NULL, // no load ordering group
    NULL, // no tag identifier
    NULL, // no dependencies
    L"NT AUTHORITY\\NetworkService",
    L""); // no password

    CloseServiceHandle(h_service);
    CloseServiceHandle(h_manager);


    Ref: http://stackoverflow.com/questions/...windows-service-using-sc-exe-through-c-coding
     
  6. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,789
    https://en.wikipedia.org/wiki/System_Safety_Monitor
    Yes it is OT here, but it does explain several features which are in the context of this thread. Specifically how parent-child works.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    That is what Kaspersky said in its analysis of the malware. Note that this malware is a targeted attack against servers. So if you are concerned about your personal PC, I wouldn't worry.

    If you wish to block Powershell, here is the full path for it: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. I never "block" Windows system processes; I monitor them instead using a HIPS "ask" execution rule.

    No.
     
  8. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,796
    Location:
    .
    Definitely this is something I'm going to learn... Well, someday.
     
  9. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    But that is not what this thread is about. Please stay on topic
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    There is one part of this malware attack that does apply to client PC's. It is the malware's use of a packed and obfuscated PowerShell script that decrypts and runs in memory.

    The average user doesn't know what Powershell is let alone methods to block its execution. Let's proceed on that assumption. How can he or she be protected against malware that employs such a technique?

    1. They use Win 10
    2. They use a security product that employs the use of Win 10's anti-malware scan interface(AMSI).

    Note that the latest posting by Kaspersky stated that they have developed a signature for this malicious script. Other vendors have or shortly will have a like signature. Does that mean any AV can detect this malware? No! Only if the above two caveats apply. Why is that so?

    Win 10's AMSI interface allows participating AV vendors to monitor the script as it uncloaks in memory but prior to its execution. They can then examine it by signature detection. Additionally, many of these AV products employ sandboxed heuristics/behavior analysis to examine the script for malicious/suspicious behavior. In the case of this particular malware, it is questionable whether such analysis would have detected suspect behavior since the script didn't do anything overtly malicious. Installing a service or running the Netsh utility is not overt malicious behavior especially in this instance where it was running with Installer privileges.

    Bottom line - signature detection is indeed not dead as claimed.

    More on Win 10's AMSI interface here: https://blogs.technet.microsoft.com...-application-developers-new-malware-defenses/
     
  11. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,796
    Location:
    .
    On clients PCs, does it enters via the browser when visiting the infected bank site?
     
  12. Infected

    Infected Registered Member

    Joined:
    Feb 9, 2015
    Posts:
    1,134
    Just block PS..
     

    Attached Files:

  13. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Itman your words are ringing in my ears. See the FIDES thread.
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    As mentioned previously, this attack was done against the affected banks server/s. Whole purpose was to gather sensitive financial data e.g. account numbers, passwords, you name it. Once that was accomplished, it then erased all traces of its existence on the targeted servers.

    Again there was nothing malicious done by this malware other than the information harvesting activities.

    There are far less sophisticated financial data stealing Trojans such as Zeus and the like that target user PCs .
     
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    As I stated previously, direct blocking of Windows utility processes of which Powershell is one is only a partial mitigation since most can be executed indirectly via API calls. As given in another Wilders thread which I repeat below is any example of Powershell API's being used by another exploit kit named TheFatRat:

    In this case study different tools and methodologies have been shown to create shellcode and Windows executables trying to evade some security systems such as antivirus systems and preinstalled Windows systems.

    Making an overall analysis of the results obtained, we note that TheFatRat gives the best results, creating a fully undetectable payload (exe file with C# and powershell) that is recognized only by Kaspersky antivirus.


    Ref.: http://www.iswatlab.eu/wp-content/uploads/2017/01/Technical_Report_Evasion.pdf
    Note: The above bypasses the Win 10 AMSI interface since it only monitors direct Powershell script execution.
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Another simple Powershell.exe monitoring bypass is to use rundll32.exe:

    # PowerShdll
    Run PowerShell with dlls only.
    Does not require access to powershell.exe as it uses powershell automation dlls.


    Ref.: https://github.com/p3nt4/PowerShdll
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The "ultimate" guide to Powershell malware exploiting and mitigations is given at this web site: https://adsecurity.org/?p=2921

    The only way Powershell can be fully contained w/o the use of AppLocker is:

    If you’re really daring, lock down systems that should never use PowerShell to No Language Mods which means PowerShell is extremely limited.

    NO LANGUAGE (NoLanguage)
    In NoLanguage language mode, users may run commands,
    but they cannot use any language elements.
    Which is not recommended since you will truly "bork" something in your system.

    Note: A NoLanguage restriction bypass is possible on non-AppLocker systems. That is all I am going to say about it. Appears this previously known bypass is indeed not true. A Microsoft employee recently tested for same and found it not to be the case. As he related, most of internal Powershell behavior is undocumented and lays in "uncharted waters."
     
    Last edited: Feb 11, 2017
  18. Lockdown

    Lockdown Registered Member

    Joined:
    Oct 28, 2016
    Posts:
    772
    Location:
    Wilders Security
    You can disable processes on the system, but there are ways to circumvent process lock-down as noted by @itman's links. And these are just the tip of the iceberg.

    That's why it is important to also run such processes using a robust limited privileges driver - in the case that they are launched or loaded into active memory, even when disabled. As long as the exploited parent process is running with limited privileges and parent > child inheritance is forced, it should be OK. But nothing is guaranteed in IT security. A single exploitable syntax quirk can irradiate us all. You get into a real mess with certain attacks - for example an WMI attack using direct system calls - and in that case, unless you are using virtualization, your best option is simply to "duck and cover." It will all be over quickly... no more pain.

    @itman - thanks for the GitHub post. I checked it. We're good.
     
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    It also occurred to me than some are under the impression that blocking powershell.exe blocks all of Powershell's functionality - it does not. Powershell.exe is the script engine for Powershell as command.com is likewise for .bat scripts. In other words, all that is being blocked is any script execution of associated core processes.
     
  20. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    One of the known rundll.exe > powershell attacker techniques suggested using EMET's ASR feature to block System.Management.Automation.dll (https://github.com/iadgov/Secure-Ho...MET#blocking-rundll32-from-loading-powershell) although there are likely other DLL's which could be abused.

    A user would need to make use of a protection mechanism which can intercept and block command line interpreters to prevent this. It would be helpful to have some sort of sample/example of this malware play around with to understand more. We will most definitely start to see more malware utilizing built-in Windows binaries to bypass many security protections including Device Guard. This also means being much more vigilant with our defence layers.
     
  21. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    Although any press about the dangers of Scriptors (of whatever type) is always a good thing, one must understand that these guys are certainly not in any way new, and that the true targets of this sort of malware are not the likes of you or I, but instead Corporate Networks. The issue here is that Scriptors are used in legitimately in the Enterprise to automate various processes and so pre-exist. This leads to the issue that any Traditional Security routine that is in place really won't be able to distinguish between good or bad, and often detection of malicious scripts is a serendipitous thing.

    An example is a breach of a major Retailer that happened a few years ago- it was initially discovered only because someone in IT happened to be viewing firewall logs and noticed an Outbound connection to a server located somewhere on the Steppes of Central Asia (where they had neither a customer nor outlet). Backtracking through millions of connections it was found that there were pulse transmissions to this server on a weekly basis going back a few months. Only then was the vector uncovered.

    For the Home user, these Scriptors would have a more difficult time to hide. Personally a better concern for a Homie would be for process hollowing malware, the better examples of which can only be determined by volatile memory forensic analysis (or in a sandboxed environment where system calls are dynamically analysed).
     
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    @Minimalist just posted on web based malware abusing Powershell API's here: https://www.wilderssecurity.com/thr...on-before-infecting-them-with-malware.388954/

    Malicious code assigned different scores for user actions

    After taking a closer look at this file, researchers said they found a grading system inside it. Crooks had assigned scores to actions like clicking (16 points), scrolling (11 points), or moving the mouse (1 point).

    The plugin would wait for the page to load, and for user interaction. Based on what types of interactions occurred, if the total score surpassed 30, then it would load a hidden iframe on the same page.

    This iframe contained exploit code that attempted to run various PowerShell commands that took advantage of the CVE-2016-0189 Internet Explorer vulnerability to install the banking trojan.

    Obviously, since this was an Internet Explorer flaw, the malicious jQuery plugin triggered only for IE browsers, ignoring others.
     
  23. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    So blocking Powershell executable from running wouldn't block all functionality? Would adding PS1 and other file extensions to blocked extensions list help in mitigation?
    I know that getting to data is sometimes enough for malware author, but what about persistence and system compromise of such malware? Does it need admin rights? Would SUA and UAC on max prevent it from compromising whole system?
     
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Only way to limit Powershell functionality is to set it to "Constrained Language Mode" as recommended by Microsoft here: https://www.wilderssecurity.com/thr...ter-in-addition-to-locky.391770/#post-2650123 . This limits internal API use to Windows core processes.

    The only way to fully block all program based use of Powershell code is to set it to "No Language" mode as described previously in this thread. This will in all likelihood "bust" your Windows installation; especially on Win 10 that internally uses Powershell for a number of system monitoring functions.
     
    Last edited: Feb 10, 2017
  25. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    This seems too extreme IMO.
    What about breaking out of SUA + UAC on max? Would powershell somehow allow breaking out of this restrictions or would some kind of bypass be required to do it?
     
  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.