BitDam Blog

The Hawk in the NET (CVE 2017-11882) – Part 2
Roy Rashti
Roy Rashti
5 minutes & 16 seconds read · July 8, 2018

The Hawk in the NET (CVE 2017-11882) – Part 2

The former post ended with the unusual CVE 2017-11882 exploitation shellcode running an executable.

That executable is used solely to run advanced staged payloads later on, as it drops jdcmaxm.cs and jdcmaxm.cmdline (random names) files in the temp directory and uses “csc.exe” to compile the C# file with cmdline parameter (see figure 1)

Figure 1

Once “csc.exe” finishes, the program executes the newly compiled exe.

The executable is .NET based, which made it possible to decompile. Judging by the level of ‘carefulness’, obfuscation and infection chain, it’s safe to say that the assemblies linked to that attack were made by people who knew what they were doing.

In my opinion, the attackers made the unusual choice of working with C# to create the malware due to several reasons; It’s easier to dynamically load assemblies while working in memory, it’s faster to code that way and it’s pretty safe to say that it’s highly unlikely for a windows computer not to have .NET installed.

Note: along some of the code samples in this document you will find comments. All of those comments were added by me to clarify things related to the code.

Decompiling the program has certainly made it easier to reverse.  While looking at that executable, we see a relatively straight forward main as shown in Figure 2

Figure 2

The executable contains a lot of code, most of it is unused. The main function loads a BMP resource, decrypts it into an array of bytes, loads it as an assembly and invokes it in a new thread.

We were able to extract the invoked assembly and look into it as well.

A quick glance at the assembly reveals interesting techniques. No strings were present in the code. All of the strings that the assembly needs existed as base64 encoded strings that it read from a resource whenever needed. Each call had an index that marked the beginning of the base64 string in the resource stream. See an example for that in Figure 3.

Figure 3

I was able to extract the strings from the resource and noticed that the obfuscation was made using a tool called ‘Dot wall’.

The attackers did their best to write the code as complex as possible. Most of the code is made with While(True) loops with an integer used as some sort of instruction pointer that navigates through the code with ‘Switch – case’ statements, “go to” and labels.

After a lot of deceiving code, irritating loops and decryption strings, we finally get to an interesting point; A base64 string inside the resource that holds the string, returns a name of another resource in the assembly.

That resource is loaded into a stream and contains an encrypted assembly (Figure 4).

Figure 4

Then the encrypted assembly is sent to the decryption function shown in Figure 5.

Figure 5

“num” is initialized with 2. That makes the function start with retrieving the decryption key. Using that key the function decrypts every byte of the assembly using XOR with the next byte in the key (cyclic to length of 16). When ‘index’ equals the length of the assembly, num is set to 0, the code jumps to label_6 that returns the decrypted assembly.

The loaded assembly contains exported types. After loading the assembly into the current assembly, the line shown in Figure 6 returns an exported type from the recently loaded assembly.

Figure 6

Once case6 is finished, num is 0 and the instruction pointer is at case4.

Figure 7 shows the code executed next.

Figure 7

num2” is our instruction pointer for this loop. Starting from case 4, instance is created using reflection out of the type loaded from the assembly and the string containing the path of “vbc.exe” which is a legitimate .NET executable is created.

After making sure the executable exists, the program goes to ‘case 0’, invokes a method in the exported type, the counter for ‘invoked types’ is increased and in the next step ‘break’ will exit the loop.

So far, the current assembly has done what it was supposed to do, invoking the exported type, sending vbc’s path as parameters.

That type is part of an assembly that has two interesting components I’d like to focus on;

The first one is what seems to be the persistency method which is made through scheduled tasks.

I took some time to beautify some of the code, so the variable names and strings you’re about to see are there to make the code a bit more clear.

The attackers used the same obfuscation method we seen before; all of the strings were encapsulated as base64 and hidden in a resource.

Figure 8 show that the malware queries the currently existing scheduled tasks.

Figure 8

Once that finished, it reads the standard output, searching for the executable’s name. If it does not exist, creates a task for it as shown in Figure 9.

Figure 9

In addition to that, the attackers created some obfuscated delegates. After beautifying the code it looks as shown in Figure 10.

Figure 10

If the first thing that pops to your mind when seeing those functions is injection, you are absolutely right.

Remember vbc.exe that was sent when invoking the type? That very same executable path is being launched.

After that, the attackers are checking if the system is 32 or 64 bit in order to know if GetThreadContext or Wow64GetThreadContext should be used (see Figure 11)

Figure 11

After that, the malware does some calculations, setting thread context and writing some reserved code in specific offsets from the very same DLL sent to the type upon invoke to the new process.

After the injection, I noticed that vbc.exe reaches the internet. I sniffed the traffic to see the request shown in Figure 12.

Figure 12

Vbc.exe sends a post request to what seems to be the CNC server for this malware which is the same server from which we initially fetched po.doc.

In the request’s content, vbc.exe sent some information about the machine. Although the server is up, it returned ERROR 404 (file not found). It seems as if the server didn’t find the information sent to it interesting enough.

Our personal view regarding this attack is that someone worked hard to protect the well-designed payload. This threat should be taken seriously and we advise to take necessary actions if the mail was viewed by an end user.

Roy Rashti and Leon Berlin,


Read more
Roy Rashti
Roy Rashti
3 minutes & 54 seconds read · July 1, 2018

The Hawk in the NET (CVE 2017-11882) – Part 1

A few days ago, BitDam’s engine detected a malicious file named “PO.docx” (sha1 – ee77856ae686ad6e638f4ec05d3b70dd31e9adc4).

At the time of detection, the file was not publicly published nor existed on VirusTotal.

Although a week has passed, we still don’t see the payload published. It seems that whoever wrote this attack was very careful not to over-spread it and did their best to protect their assets.

We think that this might be the new variant of HawkEye trojan. Among their mutual characteristics we see the persistence mechanism, .NET payload, penetration through documents, creating and injecting to VBC.exe, and more.


Attack Highlights

  • The attack vector is very complex and sophisticated. Seems as if a lot of thought and work was put into it
  • Attack starts with a .docx file exploiting CVE 2017-8570.
  • The server sends the next chain of the attack only to certain IP addresses
  • RTF file is fetched. The RTF file exploits CVE 2017-11882 which uses a non-standard and very sophisticated way to avoid detections.
  • Equation Editor is launched. A buffer overflow leads to fetch and execute a .NET executable.
  • The executable dynamically drops and compiles an executable on the victim machine
  • The executable dynamically decrypts a resource (PNG file) into an assembly and loads it
  • That assembly dynamically decrypts a resource into an assembly, loads an exported type out of it and invokes it.
  • The new assembly’s code is used to set the persistency mechanism using scheduled tasks, creates ‘vbc.exe’ process and injects code into it to communicate with what seems to be the CNC server.
  • The payload shows many mutual characteristics with HawkEye Trojan

Attack Overview Diagram


Detailed Analysis

The file is very unique and differs from the majority of attacks we’re used to see in that vector. Docx file contains “rels” file, which is an xml that defines relationships within the document. The attackers used a logical exploit, in which they had a relationship file containing the record seen in figure 1.

Figure 1

An embedded OLE object where the source is an external document (that would be fetched from http://abatii.web[.]id/isupa/PO.doc).

When I tried to fetch that document, the server returned “ERROR 502”. That caught my mind since I didn’t expect the server to be down as the dropper is being sent. Since the attack was aimed to harm a Europe-based company, I thought that the attackers wish to limit access to the infector and filter it by the IP address.

I tried to get “PO.doc” from the very same server from a different IP address, and gladly – it served the document.

The received document is an rtf file (SHA1-2f45ba716f96e0cdb4162ba874b1a39d52321e87).

Looking at the RTF file, we can see that the attackers tried to evade static checks made by many security vendors. We concluded (looking at the CLSID of the embedded OLE) that the target is EQNEDT32.exe (Equation Editor).

A well known OLE embedding that targets EQNEDT32.exe (as shown in Figure2).

Figure 2

The RTF’s OLE data (Figure3)

Figure 3

Linking the CLSID to the registry mapping, reinsures our hypothesis that it is indeed Equation Editor (shown in Figure 4).

Figure 4

The vulnerability that is being exploited in this case is CVE-2017-11882, which is a stack overflow vulnerability caused by an unchecked memcpy.

Moreover, the EQNEDT32.exe binary was compiled long before Windows XP SP2 (March 2003 according to the metadata). Windows XP SP2 was released in August 25, 2004 – that’s where DEP was first introduced to Windows.

Figure5 shows that the binary have no DEP and of course no ASLR (that was added after the Vista release)


Figure 5

That, of course, makes the vulnerability much easier to exploit.

The attackers ran their payload from the stack by returning to the payload’s location (as shown in Figure 6)

Figure 6

Briefly, the shellcode decrypts 0x36D bytes of itself and jumps to the decrypted part (see Figure 7)

Figure 7

(It decrypts itself in 0x36D / 4 iterations and jumps to the decrypted part when finished).

As the decrypted code is evaluated, the shellcode finds kernel32.dll, gets LoadLibrary and GetProcAddress addresses, and using these abilities it can now:

  • Load urlmon.dll
  • Get the base address of shell32.dll
  • Load all the following functions:
    • kernel32! ExitProcessImplementation
    • kernel32! ExpandEnvironmentStringsW
    • urlmon! URLDownloadToFileW
    • shell32! ShellExecuteW
  • Expands the string “%TMP%\mahshhdkkdlidjujddj.exe” (Figure8)

    Figure 8

  • Download a file from hxxp://abatii[.]web[.]id/isupa/PO.exe to the temp directory (Figure9)

    Figure 9

  • Use ShellExecuteW to execute the downloaded executable
  • Exit EQNEDT32.exe using ExitProcess

Further overview and drilldown to the payload will be published soon. See cont’ here.

Leon Berlin & Roy Rashti


Read more
Leon berlin
Leon berlin
4 minutes & 40 seconds read · May 22, 2018

PropertyBomb – An Old-New Technique for Arbitrary Code Execution in VBA Macro

A few days ago, BitDam’s Deep Immunization (DI) Engine detected a malicious file with an interesting behaviour, which we suspect was designed to bypass common dynamic analysis solutions.

The file uses a VBA macro in order to run a binary-level shellcode, used to download and execute a second-stage payload.

The file was found in the wild back in February, under the name ‘ADV_13022018.xls’.

However, it’s modus operandi was quite different from “standard” VBA macro attacks, and no information about this file nor it’s operation techniques were found out there in the web.

This technique is unique, as far as I could find online. It’s “Old-New” because the file was found in the wild back in February, but as it seems, no one has paid attention to its operation, which I found quite interesting. The “PropertyBomb” is using window’s property lists as a trigger for running arbitrary code that was made in VBA macro.

Detailed Analysis

When the file is opened, it asks the victim to “Enable Content”, using social engineering in order to make the malicious macro run automatically.

When the content is enabled, the “regular” scenario is that Excel exits.

It was time to dig a little deeper in order to understand what the file does:

When opening the VB editor, we can see very long, complex, obfuscated code. The code deals with both VBA 7 and under – for compatibility reasons. We can see that clearly with If-Else statements in the next figure:

We can see that the attackers used “Sub WORkBooK_oPen()” instead of “Sub Workbook_Open()” in order to try to bypass static analysis. We can also notice the declarations of some WinAPI functions (in yellow).

The code that uses these imports:

In order to simplify, I’ve converted it’s logic to a simple “C” code:

“C” code summary:

The attackers created an execute-enabled heap object to allocate an Execute-Read-Write memory region in the heap. After creating an array of numbers from 0-255 in VBA (represented in “Shellcode”), the numbers (Chars) are copied into the allocated heap. The calculated array is actually a shellcode that will run later on. Using a handle to the desktop window, an entry in it’s property list is added, and by calling EnumProps – the shellcode starts to run (now in “Callback” after being copied from “Shellcode”).

We can see the Callback buffer before and after the initialization using Windbg:

PropertyBomb Internals

Filling an array in VB that will contain an arbitrary code is pretty easy. The file used a lot of de-obfuscation techniques in order to build the code that will run later on.

However, the interesting piece was just how the callback was triggered later on.

The call to SetPropA gets a handle to window, string and data as parameters.

So in our case it adds to the Global Atom Table a new entry (“sj1m6”), and gets an ATOM. This ATOM is then passed to NtUserSetProp routine in win32k.sys, where a new property list entry is added.

So now we have a new entry in the window’s property list (in our case – the Desktop Window), and a new entry in the Global Atom Table.

Moving forward to EnumProps, the function gets two parameters – the Handle to the window and a PROPENUMPROC callback.

Briefly, it allocates memory in heap, calls NtUserBuildPropList routine in win32k.sys which fills the buffer with PROPERTY_LIST_ITEMs (tries to do so every time until gets STATUS_SUCCESS, each time with a bigger buffer by shifting left by 4).

After it got successfully all the property list items, it searches for the atom name in the Global Atom Table (added previously in SetProp).



When it was found, it proceeds to calling our Callback:

So this way, we can easily pass an array of bytes, made in VBA macro, copied into executable pages and run it. Nice!


The Shellcode

The shellcode itself is mostly XOR-encrypted, and only few portions if it are used to decrypt it (or more precisely – 1145 bytes of it:

After decryption it is hard to miss the parts of strings that appear in memory.

By extracting the decrypted code and viewing it in a disassembler, we can see the hardcoded strings much better:

(Note: address 0x0000007B is actually “mov eax, dword ptr fs:[30h]”. Because I extracted a binary blob, IDA fails to understand it’s the PEB we’re looking for 🙂 )

We can also see the memory of the stack, and notice that all of these constants are actually strings that are passed to the stack memory:

Following up with the shellcode’s flow, the malware does the following (not necessarily in that order):

  • Finds kernel32.dll base address from the process’ PEB
  • Finds kernel32!LoadLibraryAStub and kernel32!GetProcAddressStub using pre-calculated hashes
  • It will later on find urlmon.dll and shell32.dll bases using kernel32!LoadLibraryAStub
  • It finds the pointers to functions:
    • kernel32! ExitProcessImplementation
    • kernel32! ExpandEnvironmentStringsW
    • urlmon! URLDownloadToFileW
    • shell32! ShellExecuteW
  • It expands %TEMP% using ExpandEnvironmentStringsW, it tries to download a second stage payload from hxxp://msudryuyer[.]org/sql/omoku.exe into the Temp directory, and save it as a file named “elam.exe”.
  • If it downloads the file successfully – it will then call ShellExecuteW and execute elam.exe.
  • Either way, it will call ExitProcess right after it is done.

The second-stage payload itself is a subject for future investigation, in this post I wanted to describe this original method for executing arbitrary binary code from inside a VBA script.

Hash: 51bd21d308fdf70ba455780d06b71db326faeee8dffa8031b569ee424a7574b9


About the author

Read more
Banker In The Bunker
Roy Rashti
Roy Rashti
3 minutes & 21 seconds read · May 8, 2018

New Threat Report: Banker In The Bunker

Detected New Advanced Threat Alert by BitDam – Technical Analysis

By: Roy Rashti (Cyber Security Expert) & Leon Berlin (Security Researcher)

BitDam’s engine detected an interesting malicious file called “Request.doc” in one of our customers.

The file, with sha1 of ebe28e25e2e976120afb0a687fc19618fcf9003d was not present in VirusTotal or any other site at the time we’ve detected it.

That file uses interesting obfuscation methods, running a vba macro that launches a cmd, launching a Powershell, downloading and invoking an executable that drops a Banker Trojan and registers it to run on startup.

Afterwards, it restarts the computer to make the Trojan run.

Relevant sha1s –

Doc file – ebe28e25e2e976120afb0a687fc19618fcf9003d

Dropper – 13f76ea4c868004e1720395bc2737318e45c0d0c

Trojan – 79dde9c7e0cceee8e5d9626819e2c33f9cce0425


Technical drilldown;

Upon opening, the file asks the user to enable macros, as shown in Figure 1.

Figure 1


When I was looking at the file, I expected to find a simple macro, but as I looked at it, I found that it’s more interesting than I initially thought.

A quick glance at the macro is enough to see that it’s obfuscated, like most of the macros.

The authors of this macro used interesting techniques to avoid static detections;

The macro is over 800 lines, which is far more than the usual malicious macros we encounter. In addition, instead of using the common ‘Chr’ functions, this has an excessive use of ‘Hex’ and ‘Atn’ (arctangent) functions to perform the obfuscation.

Once the execution line was ready, instead of using the obvious WScript.Shell (or one of the obvious permutations), the authors wrapped ‘Shell’ with brackets, which probably spared them a decent amount of detections (as you can see in figure 2).

Figure 2


Once the Shell’s arguments were evaluated, it started a command prompt, running the monstrous command line shown in figure 3.

Figure 3


This command line is not common nor a simple one; It obfuscates the execution line into several environment variables, avoiding the need to write suspicious keywords such as ‘Powershell’ or ‘WebClient’ implicitly.

The Powershell command (Figure 4) itself is also obfuscated, but we can see strings like ‘Syst’, ’em.Net.Web’, ‘Clien’ that can state the obvious – this Powershell line is a downloader that downloads an executable and invokes it.

Figure 4


As expected, Powershell reaches the domain ‘9qwe8q9w7asqw[.c]om’ (See the request in Figure 5).

The server sends the executable (Sha1 – 13f76ea4c868004e1720395bc2737318e45c0d0c) and Powershell invokes it.

Figure 5


Attempting to avoid arousing suspicion and being detected by AVs, the executable itself doesn’t seem to do much and is not the last part in the attacker’s chain.

A short static and dynamic analysis of the executable shows us what it’s intended to do;

It drops another executable called ‘credocker.exe’ (sha1 – 79dde9c7e0cceee8e5d9626819e2c33f9cce0425), which is placed in “%appdata%\Roaming\Microsoft\Bicore”.

The programs don’t invoke “credocker.exe”, perhaps due to the suspiciousness of such actions.

The program creates a registry key whose value is automatically executed on startup.

The key is created under ‘Run’, which is created under the path shown in Figure 6.

Figure 6


In order to validate the execution of ‘credocker.exe’, there’s an irregular execution in the end of the program’s flow.

In Figure 7, the program acquires the current process’ token, adjusting its privileges with ‘SeShutdownPrivilege’.

Figure 7. Adjusting token privileges


After that, as shown in Figure 8, the program calls ExitWindowsEx function.

edi register, which represents the ‘uFlags’ parameter of ExitWindowsEx, stores the value 2, which stands for ‘EWX_REBOOT’.

Figure 8


Once the system was rebooted, the registry value, which by now looks as shown in Figure 9 is read by the OS and ‘credocker.exe’ is launched.

Figure 9


‘credocker.exe’ is the attacker’s final payload. It seems that this Trojan is Banker Trojan, aiming to hijack passwords and files.


Read more
0 minutes & 49 seconds read · May 1, 2018

Liron Barak, our CEO, talks cyber security and BitDam at vpnMentor

This week, Liron Barak, BitDam’s CEO was featured on vpnMentor, the leading source for web privacy advice.

vpnMentor is a web portal that centralizes VPN reviews by real users. They rank 300 VPN software using reviews written by real users and are not influenced by VPN companies. They also provide different web tools like Web Proxy, Chinese Firewall Test and IP Leak test for VPNs and Tor browser. In their blog they write about products and services as well rising new technologies in the fields of web privacy and internet security.


Ditsa Keren, vpnMentor’s chief editor, has interviewed Liron last week to hear more about the dangers that cyber crime poses, the future of cyber crime, and how BitDam’s product and technology solve that. Keren is a web developer and technology enthusiast. She is also the co-founder and VP of marketing at Spirulina.Network, A leading Spirulina supplier.

Read more about how to secure your important files right at the source at vpnMentor.

Read more
Roy Rashti
Roy Rashti
2 minutes & 35 seconds read · April 30, 2018

Sandboxes Are Not Foolproof

Sandboxing cyber security solutions are based on opening files in a ‘controlled environment’. As such they monitor file actions – api calls, file access, network – to characterize  their behavior and determine if they’re malicious.

Popular evasion techniques

Since Sandboxes became more popular, attackers have developed sandbox evasion techniques. Some of those techniques are simple. For example, ‘sleep’ modes to avoid scan detection. But attackers also use more sophisticated evasions such as sandbox presence detection, where malware runs ‘clean’ code in case a sandbox is detected. Another example is malware mouse movement detection which simulates human interactions to deceive sandboxes.

Evasion techniques that emulate human behaviour are used to check whether the machine is physical or virtual. Here are some examples:

  • Checking popular ports (VMware for example) to see if they are taken
  • Reading vendor mac addresses, which is a hardcoded unique identifier
  • Reading CPU id, which provides malware with processor details
  • Reading of registry values of known hypervisors or sandboxes

In addition, most sandboxes employ very ‘weak’ machines, characterized by low processor counts, ram, etc. This too, makes it possible for malware to distinguish between an actual computer and a sandbox. This includes reading sandbox specific dlls/files/processes that can be used to identify the sandbox, or surveying the environment to see if it’s a real machine. Lack of USB ports, small hard drive, no personal files, no mail client and more can indicate that this is a sandbox. Once the malware identifies that this is a sandbox, specific techniques are then designed to evade detection.

Examples from the field

  • An interesting example of a sandbox evasion posted by LastLine uses ‘GetProcessAffinityMask’ to discover the number of cores in the system and avoids the need to check that value using wmi or parsing PEB, a known evasion tactic.
  • Cerber ransomware employs API calls that sandboxes monitor (using hooks) with ‘bad’ parameters to analyze their impact. In a monitored environment these calls will typically cause a crash, while in non-monitored environments, the exception handler enables the code’s execution, unhindered.
  • Locky ransomware. Authors of this ransomware execute their malicious code when documents are closed, to evade detection.

Sandbox aware code is another evasion technique where malware employ ‘time bombs’ to dynamically modify sleep duration and extend malware analysis timeslots using methods such as NtDelayExecution, among others time bomb evasions.

As a dynamic solution, sandboxes offer a means of effectively scanning a file, to detect malware. Unfortunately, they remain susceptible to evasion.

BitDam ‘Proactive Cyber Security’ offers another approach to protect against advanced malware. BitDam blocks alien attacker code, before execution. Whether the code aims to check for a sandbox as part of an evasion technique, to encrypt personal files or perform any other malicious activity, BitDam detects it. By ensuring that only valid code is running on the machine, BitDam secures against attack malware execution, at their source, before code is executed. This makes sandbox evasions moot. With BitDam, if there is an attempt to run alien code the attack is immediately blocked, regardless of when and where code is executed.

You can try it yourself here.

Read more
Roy Rashti
Roy Rashti
2 minutes & 31 seconds read · March 21, 2018

GandCrab – The new Ransomeware in the block

A few days ago, I was examining files that we’ve detected in one of our customers.

I encountered an interesting PDF (SHA1 – d75e3d2c235bf1e52cca16f597fe05fcfce89ad6) which is the dropper and installer of the new version of GandCrab Ransomware.

A lot was said about Ransomwares, dozens of solutions claim to protect against it and yet we encounter new ones, almost on a daily basis.

As most of the malwares these days, the creators of GandCrab used emails as their primary attack vector to install the Ransomware. Here’s how they did it;

When the PDF is opened, the user sees the captcha shown in figure 1.

Figure 1


This captcha is an image that leads to the following URL –


When clicked, the server sends a doc file.

The docfile (SHA1 – 9742c3bd6845af4134f53764afcc60de6458f0d9) is a simple doc file that like most of the VBA Macro-based infectors, asks the user to ‘Enable Content’ (shown in figure 2)

Figure 2


When the user enables the content, it allows the VBA code to run.

The file contains an invalidly signed macro that holds a lot of code, probably used to deceive and have a legitimate-macro look at first glance.

Looking at the code’s entry point, we see an AutoOpen function that runs automatically when the document is being opened and the content is enabled (shown in figure 3).

Trying to avoid signatures, the authors of this infector are avoiding some of the suspiciously looking strings in their code. This is why we don’t see “Powershell” or “WebClient” here.

Figure 3


We can see “cmd.exe”, some url and strings concatenated from a form’s labels. A quick glance at the embedded objects of the document reveals what’s probably going to be the rest of our cmd line (figure 4).

Figure 4


As the code is running, a cmd process is started with the arguments shown in figure 5.

Figure 5
Figure 5


This powershell command downloads a script from http://sorinnohoun[.]com/sc1/sct5  and calls a function called “Invoke-GandCrab”.

Looking at the powershell script (SHA1-d9fb7d948fb35550a6fe82c9c94fb609d9a1f682), we see a large, well documented function called “Invoke-Inj” that injects a dll into a process. Just after that, there’s a function called “Invoke-GandCrab” (visible in figure 6, without the base64 content).

Figure 6
Figure 6


That function has a base64 string that holds the entire malicious dll which is the ransomware itself. The dll is being decoded and transferred into the injector.

Once the PS code is loaded, “Invoke-GandCrab” is called. The dll is loaded and in that point- the bad guys has won.


About the author



Read more
Maor hizkiev
Maor hizkiev
2 minutes & 51 seconds read · February 21, 2018

What’s the story behind Spectre?

In January, a severe hardware flaw was discovered in Intel’s microprocessors (named “Meltdown”). An additional vulnerability, named “Spectre” has also been discovered. This one is much more severe, and it challenges the design of modern CPUs. These two are vulnerabilities in computer hardware, not software. As such, they affect virtually all high-end microprocessors produced over the last 20 years. Patching them requires large-scale coordination across the industry, and in some cases drastically affects the performance of computers. Moreover, sometimes patching isn’t possible; the vulnerability will remain until the computer is discarded.

An attacker can create a foothold inside any organization, using an email containing a specially crafted DOC or PDF file that utilizes Spectre. He can then use this foothold for any malicious activity such as malware or ransomware.

Spectre and Meltdown aren’t anomalies. Instead, they represent a new area to look for vulnerabilities and a new avenue of attack. An evidence to this is that several different groups of unrelated people had individually discovered the aforementioned exploits during the same few months. And it all happened while exploring the field of hardware exploits more intently.

How are modern CPUs designed today?

Microprocessors have become so fast that they spend a lot of time waiting for data (CPU instructions) to move in and out of memory. The speculative execution mechanism was designed to increase performance. A processor guesses what are the instructions that it is going to receive (e.g., following a conditional branch) and executes them. If the guess turns out to be correct, it’s a performance win. If it’s wrong, the microprocessor throws away what it has done without losing any time.

CPUs are not the only ones using speculative execution. The media world, for example, is using it all the time. Weren’t you surprised that immediately after the super bowl all the news were filled with analysis and articles about the Eagles? The reporters have prepared in advance for both cases, working hard to create 2 story versions. Then, when the game ended, they discarded the wrong story where the patriots were winning. And didn’t it give you as a reader the feeling that they are extremely fast in writing in-depth articles?

Getting back to the CPU world, the problem with the speculative execution mechanism is that there’s no permission check when the speculative execution code is running. As a result, the data is left exposed for everyone to read.

What are the implications of the Spectre vulnerability?

The Spectre and Meltdown vulnerabilities allow malicious applications to bypass memory isolation mechanisms and access sensitive data. A large number of the effective mitigations today are based upon secrets, i.e. ASLR is based upon the low chance of an attacker guessing the locations of randomly placed areas in the memory, and a stack cookie is based on placing a runtime value before the stack ends.

An attacker can leverage these vulnerabilities to discover the secrets and bypass the mitigations. ASLR and other mitigations have been extremely effective and practically caused thousands of vulnerabilities to become un-exploitable.

BitDam can protect you against Spectre, Meltdown and future microprocessor vulnerabilities. It entails zero effort and no updates are required. BitDam can do this since its unique approach is not based on secrets nor on information about how attacks work. If you want to get better protection against malicious email attachments check out BitDam’s solution or schedule a trial.

Read more
Roy Rashti
Roy Rashti
3 minutes & 27 seconds read · January 22, 2018

A Small Change Is the Best Evasive Technique

We all know that email is the path most traveled by cyber attackers when targeting organizations. Email attachments are used by attackers to inject malware into an organization in order to create the beachhead that facilitates the rest of the attack. We know that people can’t resist opening attachments.

In this post I will demonstrate how easy it is to bypass most security means that scan email attachments. We use the score on VirusTotal to show how we take a malicious Word attachment and transform it from a score of 17 (/60) to a score of 1 (/60) through a set of simple manipulations. VirusTotal is the de-facto benchmark for most security products that analyze attachments. The 1/60 score basically means that the file we have created will get through most relevant security products on the market today.

Technical details

Let’s assume that I’m an attacker and that I have put together an excellent ransomware attack. I plan to deliver a document via email that would drop and launch my malicious code. This is pretty easy to do using VBA macros. Under relevant security settings, Office applications allow me to run Visual Basic code that executes under the application’s process with the user’s privileges.

Let’s assume that I have a server, waiting to deliver my ransomware, and that I’ve created a Word document with the macro shown in figure 1. This macro implements the ‘Document Open’ function that runs automatically when the Word opens the document. It creates a powershell process that downloads the executable, places it in “c:\windows\temp” and launches it.

Figure 1

It’s pretty straight forward; the code is neither obfuscated nor sophisticated so I would expect very high detection rate in VirusTotal. The results are rather disappointing; less than a third of the vendors marked this file as malicious.


Still, if I want to spread this file, I would prefer a much lower detection rate for my file.
I assume that many attackers use Document_Open() to autorun their code. Since most security solutions today base their signatures on past attacks, I need to come up with a slightly different method, so I may be able to bypass them. Instead of Document_Open(), I will use Document_Close(), which means that my code will run automatically when the document is closed. That did the trick for four more vendors.

So far I have managed to bypass 47 out of the 60 vendors – not bad!

Next, I will try not to have “exe”, “http” and “powershell” strings in the code. Instead of spending my time trying obfuscating, I have broken-up the very same string I had before and concatenated it into one variable, whose name was changed to ‘a’. The code shown in figure 2 managed to bypass one more vendor. 48 vendors are out, 12 are still in the game.

figure 2
Figure 2


At this point I had to think a little bit out of the box. Almost every attacker uses obfuscation, so that road is probably well covered. I’ll just place the Powershell execution line in the document properties, under the “Subject” field, and read it from there. Figure 3 shows what the code looks like.

Figure 3

The code is running as expected, and when I tested the file on VirusTotal, I saw the pleasing result that you can see in figure 4.


Figure 4

Only one vendor detected this file! My guess is that the other vendors didn’t see this kind of technique before. If I want to start spreading my ransomware at this point, all I need to do is to decorate the email with nice emojis and spread it to any email address I know.

In contrast with almost all other security products, BitDam does not rely on chasing the “attack du-jour”, and thus is able to “see” the maliciousness of the file despite any manipulations we use. If you want to get better protection against malicious email attachments check out BitDam’s solution or schedule a demo.

About the author

Read more

Schedule a Demo

Enter your email to get a free trial invitation