[SANS ISC] Common Patterns Used in Phishing Campaigns Files

I published the following diary on isc.sans.org: “Common Patterns Used in Phishing Campaigns Files“:

Phishing campaigns remain a common way to infect computers. Every day, I’m receiving plenty of malicious documents pretending to be sent from banks, suppliers, major Internet actors, etc. All those emails and their payloads are indexed and this morning I decided to have a quick look at them just by the name of the malicious files. Basically, there are two approaches used by attackers:

• They randomize the file names by adding a trailing random string (ex: aaf_438445.pdf) or the complete filename.
• They make the filename “juicy” to entice the user to open it by using common words.

[Read more]

[The post [SANS ISC] Common Patterns Used in Phishing Campaigns Files has been first published on /dev/random]

from Xavier

FinFisher exposed: A researcher’s tale of defeating traps, tricks, and complex virtual machines

Office 365 Advanced Threat Protection (Office 365 ATP) blocked many notable zero-day exploits in 2017. In our analysis, one activity group stood out: NEODYMIUM. This threat actor is remarkable for two reasons:

• Its access to sophisticated zero-day exploits for Microsoft and Adobe software
• Its use of an advanced piece of government-grade surveillance spyware FinFisher, also known as FinSpy and detected by Microsoft security products as Wingbird

FinFisher is such a complex piece of malware that, like other researchers, we had to devise special methods to crack it. We needed to do this to understand the techniques FinFisher uses to compromise and persist on a machine, and to validate the effectiveness of Office 365 ATP detonation sandbox, Windows Defender Advanced Threat Protection (Windows Defender ATP) generic detections, and other Microsoft security solutions.

This task proved to be nontrivial. FinFisher is not afraid of using all kinds of tricks, ranging from junk instructions and spaghetti code to multiple layers of virtual machines and several known and lesser-known anti-debug and defensive measures. Security analysts are typically equipped with the tools to defeat a good number of similar tricks during malware investigations. However, FinFisher is in a different category of malware for the level of its anti-analysis protection. Its a complicated puzzle that can be solved by skilled reverse engineers only with good amount of time, code, automation, and creativity. The intricate anti-analysis methods reveal how much effort the FinFisher authors exerted to keep the malware hidden and difficult to analyze.

This exercise revealed tons of information about techniques used by FinFisher that we used to make Office 365 ATP more resistant to sandbox detection and Windows Defender ATP to catch similar techniques and generic behaviors. Using intelligence from our in-depth investigation, Windows Defender ATP can raise alerts for malicious behavior employed by FinFisher (such as memory injection in persistence) in different stages of the attack kill chain. Machine learning in Windows Defender ATP further flags suspicious behaviors observed related to the manipulation of legitimate Windows binaries.

Figure 1. Generic Windows Defender ATP detections trigger alerts on FinFisher behavior

While our analysis has allowed us to immediately protect our customers, wed like to share our insights and add to the growing number of published analyses by other talented researchers (listed below this blog post). We hope that this blog post helps other researchers to understand and analyze FinFisher samples and that this industry-wide information-sharing translate to the protection of as many customers as possible.

Spaghetti and junk codes make common analyst tools ineffective

In analyzing FinFisher, the first obfuscation problem that requires a solution is the removal of junk instructions and spaghetti code, which is a technique that aims to confuse disassembly programs. Spaghetti code makes the program flow hard to read by adding continuous code jumps, hence the name. An example of FinFishers spaghetti code is shown below.

Figure 2. The spaghetti code in FinFisher dropper

This problem is not novel, and in common situations there are known reversing plugins that may help for this task. In the case of FinFisher, however, we could not find a good existing interactive disassembler (IDA) plugin that can normalize the code flow. So we decided to write our own plugin code using IDA Python. Armed with this code, we removed this first layer of anti-analysis protection.

Removing the junk instructions revealed a readable block of code. This code starts by allocating two chunks of memory: a global 1 MB buffer and one 64 KB buffer per thread. The big first buffer is used as index for multiple concurrent threads. A big chunk of data is extracted from the portable executable (PE) file itself and decrypted two times using a custom XOR algorithm. We determined that this chunk of data contains an array of opcode instructions ready to be interpreted by a custom virtual machine program (from this point on referenced generically as VM) implemented by FinFisher authors.

Figure 3. The stages of the FinFisher multi-layered protection mechanisms

Stage 0: Dropper with custom virtual machine

The main dropper implements the VM dispatcher loop and can use 32 different opcodes handlers. Th 64KB buffer is used as a VM descriptor data structure to store data and the just-in-time (JIT) generated code to run. The VM dispatcher loop routine ends with a JMP to another routine. In total, there are 32 different routines, each of them implementing a different opcode and some basic functionality that the malware program may execute.

Figure 4. A snapshot of the code that processes each VM opcode and the associate interpreter

The presence of a VM and virtualized instruction blocks can be described in simpler terms: Essentially, the creators of FinFisher interposed a layer of dynamic code translation (the virtual machine) that makes analysis using regular tools practically impossible. Static analysis tools like IDA may not be useful in analyzing custom code that is interpreted and executed through a VM and a new set of instructions. On the other hand, dynamic analysis tools (like debuggers or sandbox) face the anti-debug and anti-analysis tricks hidden in the virtualized code itself that detects sandbox environments and alters the behavior of the malware.

At this stage, the analysis can only continue by manually investigating the individual code blocks and opcode handlers, which are highly obfuscated (also using spaghetti code). Reusing our deobfuscation tool and some other tricks, we have been able to reverse and analyze these opcodes and map them to a finite list that can be used later to automate the analysis process with some scripting.

The opcode instructions generated by this custom VM are divided into different categories:

1. Logical opcodes, which implement bit-logic operators (OR, AND, NOT, XOR) and mathematical operators
2. Conditional branching opcodes, which implement a code branch based on conditions (equals to JC, JE, JZ, other similar branching opcodes)
3. Load/Store opcodes, which write to or read from particular addresses of the virtual address space of the process
4. Specialized opcodes for various purposes, like execute specialized machine instruction that are not virtualized

We are publishing below the (hopefully) complete list of opcodes used by FinFisher VM that we found during our analysis and integrated into our de-virtualization script:

INDEX	MNEMONIC	DESCRIPTION
0x0	EXEC	Execute machine code
0x1	JG	Jump if greater/Jump if not less or equal
0x2	WRITE	Write a value into the dereferenced internal VM value (treated as a pointer)
0x3	JNO	Jump if not overflow
0x4	JLE	Jump if less or equal (signed)
0x5	MOV	Move the value of a register into the VM descriptor (same as opcode 0x1F)
0x6	JO	Jump if overflow
0x7	PUSH	Push the internal VM value to the stack
0x8	ZERO	Reset the internal VM value to 0 (zero)
0x9	JP	Jump if parity even
0xA	WRITE	Write into an address
0xB	ADD	Add the value of a register to the internal VM value
0xC	JNS	Jump if not signed
0xD	JL	Jump if less (signed)
0xE	EXEC	Execute machine code and branch
0xF	JBE	Jump if below or equal or Jump if not above
0x10	SHL	Shift left the internal value the number of times specified into the opcodes
0x11	JA	Jump if above/Jump if not below or equal
0x12	MOV	Move the internal VM value into a register
0x13	JZ	JMP if zero
0x14	ADD	Add an immediate value to the internal Vm descriptor
0x15	JB	Jump if below (unsigned)
0x16	JS	Jump if signed
0x17	EXEC	Execute machine code (same as opcode 0x0)
0x18	JGE	Jump if greater or equal/Jump if not less
0x19	DEREF	Write a register value into a dereferenced pointer
0x1A	JMP	Special obfuscated Jump if below opcode
0x1B	*	Resolve a pointer
0x1C	LOAD	Load a value into the internal VM descriptor
0x1D	JNE	Jump if not equal/Jump if not zero
0x1E	CALL	Call an external function or a function located in the dropper
0x1F	MOV	Move the value of a register into the VM descriptor
0x20	JNB	Jump if not below/Jump if above or equal/Jump if not carry
0x21	JNP	Jump if not parity/Jump if parity odd

 

Each virtual instruction is stored in a special data structure that contains all the information needed to be properly read and executed by the VM. This data structure is 24 bytes and is composed of some fixed fields and a variable portion that depends on the opcode. Before interpreting the opcode, the VM decrypts the opcodes content (through a simple XOR algorithm), which it then relocates (if needed), using the relocation fields.

Here is an approximate diagram of the opcode data structure:

Figure 5. A graphical representation of the data structure used to store each VM opcode

The VM handler is completely able to generate different code blocks and deal with relocated code due to address space layout randomization (ASLR). It is also able to move code execution into different locations if needed. For instance, in the case of the Execute opcode (0x17), the 32-bit code to run is stored entirely into the variable section with the value at offset 5 specifying the number of bytes to be copied and executed. Otherwise, in the case of conditional opcodes, the variable part can contain the next JIT packet ID or the next relative virtual address (RVA) where code execution should continue.

Of course, not all the opcodes are can be easily read and understood due to additional steps that the authors have taken to make analysis extremely complicated. For example, this is how opcode 0x1A is implemented: The opcode should represent a JB (Jump if below) function, but its implemented through set carry (STC) instruction followed by a JMP into the dispatcher code that will verify the carry flag condition set by STC.

Figure 6. One of the obfuscation tricks included by the malware authors in a VM opcode dispatcher

Even armed with the knowledge we have described so far, it still took us many hours to write a full-fledged opcode interpreter thats able to reconstruct the real code executed by FinFisher.

Stage 1: Loader malware keeps sandbox and debuggers away

The first stage of FinFisher running through this complicated virtual machine is a loader malware designed to probe the system and determine whether its running in a sandbox environment (typical for cloud-based detonation solution like Office 365 ATP).

The loader first dynamically rebuilds a simple import address table (IAT), resolving all the API needed from Kernel32 and NtDll libraries. It then continues executing in a spawned new thread that checks if there are additional undesired modules inside its own virtual address space (for example, modules injected by certain security solutions). It eventually kills all threads that belong to these undesired modules (using ZwQueryInformationThread native API with ThreadQuerySetWin32StartAddress information class).

The first anti-sandbox technique is the loader checking the code segment. If its not 0x1B (for 32-bit systems) or 0x23 (for 32-bit system under Wow64), the loader exits.

Next, the dropper checks its own parent process for indications that it is running in a sandbox setup. It calculates the MD5 hash of the lower-case process image name and terminates if one of the following conditions are met:

1. The MD5 hash of the parent process image name is either D0C4DBFA1F3962AED583F6FCE666F8BC or 3CE30F5FED4C67053379518EACFCF879
2. The parent processs full image path is equal to its own process path

If these initial checks are passed, the loader builds a complete IAT by reading four imported libraries from disk (ntdll.dll, kernel32.dll, advapi32.dll, and version.dll) and remapping them in memory. This technique makes use of debuggers and software breakpoints useless. During this stage, the loader may also call a certain API using native system calls, which is another way to bypass breakpoints on API and security solutions using hooks.

Figure 7. FinFisher loader calling native Windows API to perform anti-debugging tricks

At this point, the fun in analysis is not over. A lot of additional anti-sandbox checks are performed in this exact order:

1. Check that the malware is not executed under the root folder of a drive
2. Check that the malware file is readable from an external source
3. Check that the hash of base path is not 3D6D62AF1A7C8053DBC8E110A530C679
4. Check that the full malware path contains only human readable characters (a-z, A-Z, and 0-9)
5. Check that no node in the full path contains the MD5 string of the malware file
6. Fingerprint the system and check the following registry values:
   1. HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid should not be “6ba1d002-21ed-4dbe-afb5-08cf8b81ca32”
   2. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId should not be “55274-649-6478953-23109”, “A22-00001”, or “47220”
   3. HARDWARE\Description\System\SystemBiosDate should not contain 01/02/03
7. Check that the mutex WininetStartupMutex0 does not already exist
8. Check that no DLL whose base name has hash value of 0xC9CEF3E4 is mapped into the malware address space

The hashes in these checks are most likely correspond to sandbox or security products that the FinFisher authors want to avoid.

Next, the loader checks that its not running in a virtualized environment (VMWare or Hyper-V) or under a debugger. For the hardware virtualization check, the loader obtains the hardware device list and checks if the MD5 of the vendor ID is equal to a predefined list. In our tests, the malware sample was able to easily detect both VMWare and Hyper-V environments through the detection of the virtualized peripherals (for example, Vmware has VEN_15AD as vendor ID, HyperV has VMBus as bus name). Office 365 ATP sandbox employs special mechanisms to avoid being detected by similar checks.

The loaders anti-debugger code is based on the following three methods:

1. The first call aims to destroy the debugger connection:

NOTE: This call completely stops the execution of WinDbg and other debuggers

2. The second call tries to detect the presence of a debugger:

3. The final call tries to destroy the possibility of adding software breakpoint:

Finally, if the loader is happy with all the checks done so far, based on the victim operating system (32 or 64-bit) it proceeds to decrypt a set of fake bitmap resources (stage 2) embedded in the executable and prepares the execution of a new layer of VM decoding.

Each bitmap resource is extracted, stripped of the first 0x428 bytes (BMP headers and garbage data), and combined into one file. The block is decrypted using a customized algorithm that uses a key derived from the original malware droppers TimeDateStamp field multiplied by 5.

Figure 8. The fake bitmap image embedded as resource

The 32-bit stage 2 malware uses a customized loading mechanism (i.e., the PE file has a scrambled IAT and relocation table) and exports only one function. For the 64-bit stage 2 malware, the code execution is transferred from the loader using a well-known technique called Heavens Gate. In the next sections, for simplicity, we will continue the analysis only on the 64-bit payload.

Figure 9. Heavens gate is still in use in 2017

Stage 2: A second multi-platform virtual machine

The 64-bit stage 2 malware implements another loader combined with another virtual machine. The architecture is quite similar to the one described previously, but the opcodes are slightly different. After reversing these opcodes, we were able to update our interpreter script to support both 32-bit and 64-bit virtual machines used by FinFisher.

INDEX	MNEMONIC	DESCRIPTION
0x0	JMP	Special obfuscated conditional Jump (always taken or always ignored)
0x1	JMP	Jump to a function (same as opcode 0x10)
0x2	CALL	Call to the function pointed by the internal VM value
0x3	CALL	Optimized CALL function (like the 0x1E opcode of the 32-bit VM)
0x4	EXEC	Execute code and move to the next packet
0x5	JMP	Jump to an internal function
0x6	NOP	No operation, move to the next packet
0x7	CALL	Call an imported API (whose address is stored in the internal VM value)
0x8	LOAD	Load a value into the VM descriptor structure *
0x9	STORE	Store the internal VM value inside a register
0xA	WRITE	Resolve a pointer and store the value of a register in its content
0xB	READ	Move the value pointed by the VM internal value into a register
0xC	LOAD	Load a value into the VM descriptor structure (not optimized)
0xD	CMP	Compare the value pointed by the internal VM descriptor with a register
0xE	CMP	Compare the value pointed by the internal VM descriptor with an immediate value
0xF	XCHG	Exchange the value pointed by the internal VM descriptor with a register
0x10	SHL	Jump to a function (same as opcode 0x1)

 

This additional virtual machine performs the same duties as the one already described but in a 64-bit environment. It extracts and decrypts the stage 3 malware, which is stored in encrypted resources such as fake dialog boxes. The extraction method is the same, but the encryption algorithm (also XOR) is much simpler. The new payload is decrypted, remapped, and executed in memory, and represents the installation and persistence stage of the malware.

Stage 3: Installer that takes DLL side-loading to a new level

Stage 3 represents the setup program for FinFisher. It is the first plain stage that does not employ a VM or obfuscation. The code supports two different installation methods: setup in a UAC-enforced environment (with limited privileges), or an installation with full-administrative privileges enabled (in cases where the malware gains the ability to run with elevated permissions). We were a bit disappointed that we did not see traces of a true privilege escalation exploit after all this deobfuscation work, but it seems these FinFisher samples were designed to work just using UAC bypasses.

The setup code receives an installation command from the previous stage. In our test, this command was the value 3. The malware creates a global event named 0x0A7F1FFAB12BB2 and drops some files under a folder located in C:\ProgramData or in the user application data folder. The name of the folder and the malware configuration are read from a customized configuration file stored in the resource section of the setup program.

Here the list of the files potentially dropped during the installation stage:

FILE NAME	STAGE	DESCRIPTION
d3d9.dll	Stage 4	Malware loader used for UAC environments with limited privileges; also protected by VM obfuscation
aepic.dll, sspisrv.dll, userenv.dll	Stage 4	Malware loader used in presence of administrative privileges; executed from (and injected into) a fake service; also protected by VM obfuscation
msvcr90.dll	Stage 5	Malware payload injected into the explorer.exe or winlogon.exe process; also protected by VM obfuscation
<randomName>.cab	Config	Main configuration file; encrypted
setup.cab	Unknown	Last section of the setup executable; content still unknown
<randomName>.7z	Plugin	Malware plugin used to spy the victim network communications
wsecedit.rar	Stage 6	Main malware executable

 

After writing some of these files, the malware decides which kind of installation to perform based on the current privilege provided by the hosting process (for example, if a Microsoft Office process was used as exploit vector):

1. Installation process under UAC

When running under a limited UAC account, the installer extracts d3d9.dll and creates a persistence key under HKCU\Software\Microsoft\Windows\Run. The malware sets a registry value (whose name is read from the configuration file) to C:\Windows\system32\rundll32.exe c:\ProgramData\AuditApp\d3d9.dll, Control_Run. Before doing this, the malware makes a screenshot of the screen and displays it on top of all other windows for few seconds. This indicates that the authors are trying to hide some messages showed by the system during the setup process.

When loaded with startup command 2, the installer can copy the original explorer.exe file inside its current running directory and rename d3d9.dll to uxtheme.dll. In this case the persistence is achieved by loading the original explorer.exe from its startup location and, using DLL side-loading, passing the execution control to the stage 4 malware (discussed in next section).

Finally, the malware spawns a thread that has the goal to load, remap, and relocate the stage 5 malware. In this context, there is indeed no need to execute the stage 4 malware. The msvcr90.dll file is opened, read, and decrypted, and the code execution control is transferred to the RunDll exported routine.

In the case of 32-bit systems, the malware may attempt a known UAC bypass by launching printui.exe system process and using token manipulation with NtFilterToken as described in this blog post.

2. Installation process with administrative privilege

This installation method is more interesting because it reveals how the malware tries to achieve stealthier persistence on the machine. The method is a well-known trick used by penetration testers that was automated and generalized by FinFisher

The procedure starts by enumerating the KnownDlls object directory and then scanning for section objects of the cached system DLLs. Next, the malware enumerates all .exe programs in the %System% folder and looks for an original signed Windows binary that imports from at least one KnownDll and from a library that is not in the KnownDll directory. When a suitable .exe file candidate is found, it is copied into the malware installation folder (for example, C:\ProgramData). At this point the malware extracts and decrypts a stub DLL from its own resources (ID 101). It then calls a routine that adds a code section to a target module. This section will contain a fake export table mimicking the same export table of the original system DLL chosen. At the time of writing, the dropper supports aepic.dll, sspisrv.dll, ftllib.dll, and userenv.dll to host the malicious FinFisher payload. Finally, a new Windows service is created with the service path pointing to the candidate .exe located in this new directory together with the freshly created, benign-looking DLL.

In this way, when the service runs during boot, the original Windows executable is executed from a different location and it will automatically load and map the malicious DLL inside its address space, instead of using the genuine system library. This routine is a form of generic and variable generator of DLL side-loading combinations.

Figure 10. Windows Defender ATP timeline can pinpoint the service DLL side-loading trick (in this example, using fltlib.dll).

In the past, we have seen other activity groups like LEAD employ a similar attacker technique named proxy-library to achieve persistence, but not with this professionalism. The said technique brings the advantage of avoiding auto-start extensibility points (ASEP) scanners and programs that checks for binaries installed as service (for the latter, the service chosen by FinFisher will show up as a clean Windows signed binary).

The malware cleans the system event logs using OpenEventLog/ClearEventLog APIs, and then terminates the setup procedure with a call to StartService to run the stage 4 malware.

Figure 11. The DLL side-loaded stage 4 malware mimicking a real export table to avoid detection

Stage 4: The memory loader Fun injection with GDI function hijacking

Depending on how stage 4 was launched, two different things may happen:

• In the low-integrity case (under UAC) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates
• In the high-integrity case (with administrative privileges or after UAC bypass), the code searches for the process hosting the Plug and Play service (usually svchost.exe) loaded in memory and injects itself into it

For the second scenario, the injection process works like this:

1. The malware opens the target service process.
2. It allocates and fills four chunks of memory inside the service process. One chunk contains the entire malware DLL code (without PE headers). Another chunk is used to copy a basic Ntdll and Kernel32 import address table. Two chunks are filled with an asynchronous procedure call (APC) routine code and a stub.
3. It opens the service thread of the service process and uses the ZwQueueApcThread native API to inject an APC.

The APC routine creates a thread in the context of the svchost.exe process that will map and execute the stage 5 malware into the winlogon.exe process.

The injection method used for winlogon.exe is also interesting and quite unusual. We believe that this method is engineered to avoid trivial detection of process injection using the well-detected CreateRemoteThread or ZwQueueApcThread API.

The malware takes these steps:

1. Check if the system master boot record (MBR) contains an infection marker (0xD289C989C089 8-bytes value at offset 0x2C), and, if so, terminate itself
2. Check again if the process is attached to a debugger (using the techniques described previously)
3. Read, decrypt, and map the stage 5 malware (written in the previous stage in msvcr90.dll)
4. Open winlogon.exe process
5. Load user32.dll system library and read the KernelCallbackTable pointer from its own process environment block (PEB) (Note: The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode.)
6. Calculate the difference between this pointer and the User32 base address.
7. Copy the stage 5 DLL into winlogon.exe
8. Allocate a chunk of memory in winlogon.exe process and copy the same APC routine seen previously
9. Read and save the original pointer of the __fnDWORD internal User32 routine (located at offset +0x10 of the KernelCallbackTable) and replace this pointer with the address of the APC stub routine

After this function pointer hijacking, when winlogon.exe makes any graphical call (GDI), the malicious code can execute without using CreateRemoteThread or similar triggers that are easily detectable. After execution it takes care of restoring the original KernelCallbackTable.

Stage 5: The final loader takes control

The stage 5 malware is needed only to provide one more layer of obfuscation, through the VM, of the final malware payload and to set up a special Structured Exception Hander routine, which is inserted as Wow64PrepareForException in Ntdll. This special exception handler is needed to manage some memory buffers protection and special exceptions that are used to provide more stealthy execution.

After the VM code has checked again the user environment, it proceeds to extract and execute the final un-obfuscated payload sample directly into winlogon.exe (alternatively, into explorer.exe) process. After the payload is extracted, decrypted, and mapped in the process memory, the malware calls the new DLL entry point, and then the RunDll exported function. The latter implements the entire spyware program.

Stage 6: The payload is a modular spyware framework for further analysis

Our journey to deobfuscating FinFisher has allowed us to uncover the complex anti-analysis techniques used by this malware, as well as to use this intel to protect our customers, which is our top priority. Analysis of the additional spyware modules is future work.

It is evident that the ultimate goal of this program is to steal information. The malware architecture is modular, which means that it can execute plugins. The plugins are stored in its resource section and can be protected by the same VM. The sample we analyzed in October, for example, contains a plugin that is able to spy on internet connections, and can even divert some SSL connections and steal data from encrypted traffic.

Some FinFisher variants incorporate an MBR rootkit, the exact purpose of which is not clear. Quite possibly, this routine targets older platforms like Windows 7 and machines not taking advantage of hardware protections like UEFI and SecureBoot, available on Windows 10. Describing this additional piece of code in detail is outside the scope of this analysis and may require a new dedicated blog post.

Defense against FinFisher

Exposing as much of FinFishers riddles as possible during this painstaking analysis has allowed us to ensure our customers are protected against this advanced piece of malware.

Windows 10 S devices are naturally protected against FinFisher and other threats thanks to the strong code integrity policies that dont allow unknown unsigned binaries to run (thus stopping FinFishers PE installer) or loaded (blocking FinFishers DLL persistence). On Windows 10, similar code integrity policies can be configured using Windows Defender Application Control.

Office 365 Advanced Threat Protection secures mailboxes from email campaigns that use zero-day exploits to deliver threats like FinFisher. Office 365 ATP blocks unsafe attachments, malicious links, and linked-to files using time-of-click protection. Using intel from this research, we have made Office 365 ATP more resistant to FinFishers anti-sandbox checks.

Generic detections, advanced behavioral analytics, and machine learning technologies in Windows Defender Advanced Threat Protection detect FinFishers malicious behavior throughout the attack kill chain and alert SecOps personnel. Windows Defender ATP also integrates with the Windows protection stack so that protections from Windows Defender AV and Windows Defender Exploit Guard are reported in Windows Defender ATP portal, enabling SecOps personnel to centrally manage security, and as well as promptly investigate and respond to hostile activity in the network.

We hope that this writeup of our journey through all the multiple layers of protection, obfuscation, and anti-analysis techniques of FinFisher will be useful to other researchers studying this malware. We believe that an industry-wide collaboration and information-sharing is important in defending customers against this complex piece of malware. For further reading, we recommend these other great references:

• Devirtualizing FinSpy [PDF], Tora (2012)
• Finfisher rootkit analysis, Artem Baranov (2017)
• A Walk-Through Tutorial, with Code, on Statically Unpacking the FinSpy VM: Part One, x86 Deobfuscation, Rolf Rolles (2018)
• FinSpy VM Part 2: VM Analysis and Bytecode Disassembly, Rolf Rolles (2018)
• ESETs guide to deobfuscating and devirtualizing FinFisher [PDF], Filip Kafka (2018)

 

Andrea Allievi, Office 365 ATP Research team
with Elia Florio, Windows Defender ATP Research team

 

Sample analyzed:

MD5: a7b990d5f57b244dd17e9a937a41e7f5
SHA-1: c217d48c4ac1555491348721cc7cfd1143fe0b16
SHA-256: b035ca2d174e5e4fd2d66fd3c8ce4ae5c1e75cf3290af872d1adb2658852afb8

 

 

---

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

from Windows Defender ATP

Best practices for securely moving workloads to Microsoft Azure

Azure is Microsofts cloud computing environment. It offers customers three primary service delivery models including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). Adopting cloud technologies requires a shared responsibility model for security, with Microsoft responsible for certain controls and the customer others, depending on the service delivery model chosen. To ensure that a customers cloud workloads are protected, it is important that they carefully consider and implement the appropriate architecture and enable the right set of configuration settings.

Microsoft has developed a set of Azure security guidelines and best practices for our customers to follow. These guides can be found in theAzure security best practices and patterns documentation. In addition, were excited to announce the availability of the Center for Internet Securitys (CIS) Microsoft Azure Foundations Security Benchmark, developed in partnership with Microsoft. CIS is a non-profit entity focused on developing global standards and recognized best practices for securing IT systems and data against the most pervasive attacks.

The CIS Microsoft Azure Foundations Security Benchmark provides prescriptive guidance for establishing a secure baseline configuration for Microsoft Azure. Its scope is designed to assist organizations in establishing the foundation level of security for anyone adopting the Microsoft Azure cloud. The benchmark should not be considered as an exhaustive list of all possible security configurations and architecture but as a starting point. Each organization must still evaluate their specific situation, workloads, and compliance requirements and tailor their environment accordingly.

The CIS benchmark contains two levels, each with slightly different technical specifications:

• Level 1 Recommended, minimum security settings that should be configured on any system and should cause little or no interruption of service or reduced functionality.
• Level 2 Recommended security settings for highly secure environments and could result in some reduced functionality.

The CIS Microsoft Azure Foundations Security Benchmark is divided into the following sections:

Section	Description	No. of Rec. Controls
Identity and Access Management	Recommendations related to setting the appropriate identity and access management policies.	23
Azure Security Center	Recommendations related to the configuration and use of Azure Security Center.	19
Storage Accounts	Recommendations for setting storage account policies.	7
Azure SQL Services	Recommendations for securing Azure SQL Servers.	8
Azure SQL Databases	Recommendations for securing Azure SQL Databases.	8
Logging and Monitoring	Recommendations for setting logging and monitoring policies on your Azure subscriptions.	13
Networking	Recommendations for securely configuring Azure networking settings and policies.	5
Virtual Machines	Recommendations for setting security policies for Azure compute services, specifically virtual machines.	6
Other Security Considerations	Recommendations regarding general security and operational controls, including those related to Azure Key Vault and Resource Locks.	3
Total Recommendations		92

 

Each recommendation contains several sections, including a recommendation identification number, title, and description; level or profile applicability; rationale; instructions for auditing the control; remediation steps; impact of implementing the control; default value; and references. As an example, the first control contained in the benchmark is under the Identity and Access Management section and is titled: 1.1 Ensure that multi-factor authentication is enabled for all privileged users (Scored). A control is marked as Scored or Not Scored based on whether it can be programmatically tested. In this case, recommendation 1.1 can be audited leveraging the Microsoft Graph and PowerShell commandlet. The specific steps for auditing the control are contained in the “Audit” section for this specific recommendation. This recommendation is listed as a Level 1 control because it is only applied to Azure administrative users and would not have a company-wide impact or produce less functionality for users. The rationale for recommendation 1.1 is that Azure administrative accounts need to be protected due to their powerful privileges, and with multiple factors for authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk to the Azure tenant.

The benchmark is freely available in PDF format on the CIS website.

You can also find more information on Azure Security Center and on Azure Active Directory. Both are critical solutions to securely deploying and monitoring Azure workloads and are covered in the new CIS benchmark.

from Jenny Erie

How to mitigate rapid cyberattacks such as Petya and WannaCrypt

In the first blog post of this 3-part series, we introduced what rapid cyberattacks are and illustrated how rapid cyberattacks are different in terms of execution and outcome. In the second blog post, we provided some details on Petya and how it worked. In this final blog post, we will share:

• Microsofts roadmap of recommendations to mitigate rapid cyberattacks.
• Outside-in perspectives on rapid cyberattacks and mitigation methods based on a survey of global organizations.

Because of how critical security hygiene issues have become and how challenging it is for organizations to follow the guidance and the multiple recommended practices, Microsoft is taking a fresh approach to solving them. Microsoft is working actively with NIST, the Center for Internet Security (CIS), DHS NCCIC (formerly US-CERT), industry partners, and the cybersecurity community to jointly develop and publish practical guides on critical hygiene and to implement reference solutions starting with these recommendations on rapid cyberattacks as related to patch management.

Roadmap of prescriptive recommendations for mitigating rapid cyberattacks

We group our mitigation recommendations into four categories based on the effect they have on mitigating risk:

EXPLOIT MITIGATION
Mitigate software vulnerabilities that allow worms and attackers to enter and/or traverse an environment

BUSINESS CONTINUITY / DISASTER RECOVERY (BC/DR)
Rapidly resume business operations after a destructive attack

LATERAL TRAVERSAL / SECURING PRIVILEGED ACCESS
Mitigate ability to traverse (spread) using impersonation and credential theft attacks

ATTACK SURFACE REDUCTION
Reduce critical risk factors across all attack stages (prepare, enter, traverse, execute)

Figure 1: Key components of mitigation strategy for rapid cyberattacks

We recognize every organization has unique challenges and investments in cybersecurity (people and technology) and cannot possibly make every single recommendation a top nor immediate priority. Accordingly, we have broken down the primary (default) recommendations for mitigating rapid cyberattacks into three buckets:

1. Quick wins: what we recommend organizations accomplish in the first 30 days
2. Less than 90 days: what we recommend organizations accomplish in the medium term
3. Next quarter and beyond: what we recommend organizations accomplish in the longer term

The following list is our primary recommendations on how to mitigate these attacks.

Figure 2: Microsofts primary recommendations for mitigating rapid cyberattacks

This list has been carefully prioritized based on Microsofts direct experience investigating (and helping organizations recover from) these attacks as well as collaboration with numerous industry experts. This is a default set of recommendations and should be tailored to each enterprise based on defenses already in place. You can read more about the details of each recommendation in the slide text and notes of the published slide deck.

In prioritizing the quick wins for the first 30 days, the primary considerations we used are:

1. Whether the measure directly mitigates a key attack component.
2. Whether most enterprises could rapidly implement the mitigation (configure, enable, deploy) without significant impact on existing user experiences and business processes.

Figure 3: Mapping each recommendation into the mitigation strategy components

In addition to the primary recommendations, Microsoft has an additional set of recommendations that could provide significant benefits depending on circumstances of the organization:

1. Ensure outsourcing contracts and SLAs are compatible with rapid security response
2. Move critical workloads to SaaS and PaaS as you are able
3. Validate existing network controls (internet ingress, internal Lab/ICS/SCADA isolation)
4. Enable UEFI Secure Boot
5. Complete SPA roadmap Phase 2
6. Protect backup and deployment systems from rapid destruction
7. Restrict inbound peer traffic on all workstations
8. Use application whitelisting
9. Remove local administrator privileges from end-users
10. Implement modern threat detection and automated response solutions
11. Disable unneeded protocols
12. Replace insecure protocols with secure equivalents (TelnetSSH, HTTP HTTPS, etc.)

There are specific reasons why these 12 recommendations, although helpful for certain organizations/circumstances, were excluded from the list of primary recommendations. You can read about those reasons in the slide notes of the published slide deckif interested.

Outside-in perspectives on rapid cyberattacks and mitigation methods

In late November 2017 Microsoft hosted a webinar on this topic and solicited feedback from the attendees which comprised of 845 IT professionals from small organizations to large global enterprises. Here are a few interesting insights from the poll questions.

Rapid cyberattack experience

When asked if they had experienced a rapid cyberattack (e.g. WannaCrypt, Petya or other), ~38% stated they did.

Awareness of SPA roadmap

When asked if theyre aware of Microsofts Securing Privileged Access (SPA) roadmap, most, 66%, stated that they were not.

Patching systems

When we asked within how many days (<7 or 30 or 90) they can patch various systems, it seems most respondents believed their team is good at patching quickly:

• 83% can patch workstations within 30 days; 44% within 7 days
• 81% can patch servers within 30 days; 51% within 7 days
• 54% can patch Linux/Other devices within 30 days; 25% within 7 days

Removal of SMBv1

When asked where they are on the path towards removing SMBv1, 26% said they have completed removing it, another 21% said they are in progress or in the process of doing so, and ~18% more are planning to do so.

Adopting roadmap recommendations

When asked what is blocking them from adopting Microsofts roadmap recommendations for securing against rapid cyberattacks, the top three reasons respondents shared are:

1. Lack of time
2. Lack of resources
3. Lack of support from upper management/executive buy-in

To help organizations overcome these challenges, Microsoft can be engaged to:

• Assist with implementing the mitigations described in SPA Roadmap and Rapid Cyberattack Guidance.
• Investigate an active incident with enterprise-wide malware hunting, analysis, and reverse engineering techniques. This includes providing tailored cyberthreat intelligence and strategic guidance to harden the environment against advanced and persistent attacks. Microsoft can provide onsite teams and remote support to help you investigate suspicious events, detect malicious attacks, and respond to security breaches.
• Proactively hunt for persistent adversaries in your environment using similar methods as an active incident response (above).
  Contact your Microsoft Technical Account Manager (TAM) or Account Executive to learn more about how to engage Microsoft for incident response.

Contact your Microsoft Technical Account Manager (TAM) or Account Executive to learn more about how to engage Microsoft for incident response.

More information

We hope you found the 3-part blog series on the topic of rapid cyberattacks and some recommendations on how to mitigate them useful.

For more information and resources on rapid cyber attacks, please visit the additional links here:

On-demand webinar Protect Against Rapid Cyberattacks (Petya, WannaCrypt, and similar).

Additional resources

Tips to mitigate known rapid cyberattacks with Windows 10 (and Windows Defender Advanced Threat Protection):

• New ransomware, old techniques: Petya adds worm capabilities
• Windows 10 platform resilience against the Petya ransomware attack
• Windows 10 Creators Update provides next-gen ransomware protection
• Windows Defender ATP thwarts Operation WilySupply software supply chain cyberattack

Mitigate backup destruction by ransomware with Azure Backup security features

Detect leaked credentials in Azure Active Directory

Rapidly detect polymorphic and emerging threats and enable advanced protection with Windows Defender Antivirus cloud protection service (formerly Microsoft Active Protection Service (MAPS))

Apply network protection with Windows Defender Exploit Guard

Safeguard integrity of privileged accounts that administer and manage IT systems by considering Securing Privileged Access (SPA) roadmap

Mitigate risk of lateral escalation and Pass-the-Hash (PtH) credential replay attack with Local Admin Password Solution (LAPS)

Mitigate exploitation of SMBv1 vulnerability via Petya or other rapid cyberattack by following guidance on disabling SMBv1

 

from Jenny Erie

How a national cybersecurity agency can help avoid a national cybersecurity quagmire

This last October we saw more countries than ever participate in initiatives to raise cybersecurity awareness. What was once largely a US approach has evolved into events and initiatives around the world by governments, civil society groups, and private sector partners. This increased breadth and depth of activity reflects governments increased understanding of the importance of cybersecurity, not only for their operations but for the lives of their citizens. My teams research indicates that today over half of the worlds countries are leading some sort of national level initiative for cybersecurity, with countless other efforts at sectoral, state, city, or other levels.

However, developing effective approaches to tackling cybersecurity at a national level isnt easy, especially if they are going to have widespread or long-lasting effects. The complexity of developing approaches for an issue that truly touches all aspects of the modern economy and society cannot be understated and if approached in the wrong way can create a quagmire of laws, bodies, and processes. The different aspects of cybersecurity such as promoting online safety, workforce skills development, and critical infrastructure protection, all cut across an unprecedented range of traditional government departments, from defense and foreign affairs, to education and finance. Effectively, cybersecurity is one of the first policy areas that challenges traditional national governance structures and policy making. It is unlikely to be the last, with issues such as artificial intelligence hard on its heels.

To deal with this challenge, governments are exploring new governance models. Some countries have created a dedicated department within a particular ministry, such as India. Others have looked at extending the work traditionally done by the police or a national computer security incident response team, such as Malaysia. Moreover, countries as diverse as Australia, France, Brazil, Indonesia, Tanzania, Belarus, Israel, and Singapore, already have specific bodies of government responsible for cybersecurity.

However, despite the fact that many countries have already taken steps to establish or strengthen their own cybersecurity bodies; no single, optimum, model can be pointed to. The reasons are many, from different governance set ups, to varying levels of investment and expertise available, to the fact that dealing with cybersecurity is a relatively new endeavor for governments.

Taking this variety into account, and coupling it with our own perspective and experience, Microsoft has collected good practices that we believe can support national engagement on cybersecurity. Today we are releasing a new whitepaper: Building an Effective National Cybersecurity Agency. Its core insights center around the following set of recommendations for governments in order to avoid becoming bogged down in cybersecurity challenges that are otherwise avoidable:

1. Appoint a single national cybersecurity agency.Having a single authority creates a focal point for key functions across the government, which ensures policies are prioritized and harmonized across the nation.
2. Provide the national cybersecurity agency with a clear mandate. Cybersecurity spans different stakeholders with overlapping priorities. Having a clear mandate for the agency will help set expectations for the roles and responsibilities and facilitate the intra-governmental processes.
3. Ensure the national cybersecurity agency has appropriate statutory powers. Currently, most national cybersecurity agencies are established not by statute but by delegating existing powers from other parts of government. As cybersecurity becomes an issue for national legislature, agencies might have to be given clear ownership of implementation.
4. Implement a five-part organizational structure. The five-part structure we propose in the paper allows for a multifaceted interaction across internal government and regulatory stakeholders, as well as external and international stakeholders, and aims to tackle both regulatory and other cybersecurity aspects.
5. Expect to evolve and adapt. Regardless of how the structure of the national cybersecurity agency begins, the unavoidability of change in the technology and threat landscape will require it to evolve and adapt over time to be able to continue to fulfill its mandate.

As the challenges and opportunities that come as a result of ICT proliferation continue to evolve, governments will need to ensure they are sufficiently equipped to face them, both today and in the future. Bringing together diverse stakeholders across different agencies, such as defense, commerce, and foreign affairs, and backgrounds, including those from law, engineering, economics, ad policy, will enable our society to both deal with the threats and harness the opportunities of cyberspace. It is this diversity of stakeholders that contributes to the challenge cybersecurity poses for traditional governance.

But cybersecurity is the first of many emerging areas that necessitates new and creative solutions that allows policymakers to work hand in hand with their counterparts across government, civil society and industry. For cybersecurity, as well as the issues to come, cooperation is the underpinning of achieving these goals. However, cooperation cannot be created organically, it must grow from an effectively structured governance system. Establishing a national cybersecurity agency will enable governments to do just that.

from Jenny Erie

[SANS ISC] Malware Delivered via Windows Installer Files

I published the following diary on isc.sans.org: “Malware Delivered via Windows Installer Files“:

For some days, I collected a few samples of malicious MSI files. MSI files are Windows installer files that users can execute to install software on a Microsoft Windows system. Of course, you can replace “software” with “malware”. MSI files look less suspicious and they could bypass simple filters based on file extensions like “(com|exe|dll|js|vbs|…)”. They also look less dangerous because they are Composite Document Files… [Read more]

[The post [SANS ISC] Malware Delivered via Windows Installer Files has been first published on /dev/random]

from Xavier

Imap2TheHive: Support of Attachments

I just published a quick update of my imap2thehive tool. Files attached to an email can now be processed and uploaded as an observable attached to a case. It is possible to specify which MIME types to process via the configuration file. The example below will process PDF & EML files:

[case]
files: application/pdf,messages/rfc822

The script is available here.

[The post Imap2TheHive: Support of Attachments has been first published on /dev/random]

from Xavier