BitDam Blog

Maor hizkiev
Maor hizkiev
1 minute & 24 seconds read · August 23, 2018

Leveraging Your Application’s Own Code to Protect Against Attack.

Every content-borne cyber attack starts when malicious code, embedded in files and links, is being launched by applications and executed on the machine.

Most content security solutions focus on identifying the structure or behaviour of attacks. Thus, these security approaches are limited in their ability to detect unknown threats or overcome sophisticated evasion techniques, which leaves organizations vulnerable to today’s advanced content-borne cyber attacks.

BitDam proactive security delivers a new paradigm in content-security. Focusing on the standard applications that open malicious files and links, BitDam is the only solution in the market that prevents attacks from running alien code. This way it protects against any exploit, any ransome threat, and any known or unknown vulnerability.

Standard business applications such as Microsoft Office Suite (Word, Powerpoint, Excel), Adobe PDF, and Internet Browsers are based on quality assured code. Code that was developed and supported by known software vendors. BitDam’s technology is based on that assumption. The company’s deep application learning and alien code detection ensure that only valid code is executed when opening files and links on our machines.  If an attempt to run alien code is detected, BitDam immediately recognizes it as an attack and blocks it.

BitDam automatically learns the legitimate behaviour of any application. It continuously maps CPU-level code paths to detect any deviation from them. Since it benchmarks code flows launched by files and links with authorised application code flow, BitDam’s content security is unaffected by changes in attack techniques.

Performed in the BitDam Cloud,  our unique security approach makes it possible to forever protect applications and prevent any content-borne attacks before they are delivered. This approach ensures that all files and links are safe to click.

Read more
Maor hizkiev
Maor hizkiev
1 minute & 4 seconds read · August 23, 2018

Make Cloud Hosted Office 365 Immune to Content-Borne Attacks.

Office 365 has become one of the most popular cloud-based Software-as-a-Service (SaaS) products for businesses.

Organisations of all sizes, verticals and regions are migrating their on-premise exchange Email servers to the cloud-based Office 365 (O365). They do so to gain the benefits of scalability, cost reduction, and to eliminate data loss while reducing ongoing updates and service overhead. When migrating to the cloud, organisations need to replace existing on premise security tools with cloud-based security services. These cloud-based services need to be fully integrated with 0365 while minimising friction within the organisation.

BitDam is a cloud-based content cyber security service that protects email from advanced content-borne attacks. It provides organisations that use O365 with advanced detection and prevention of malicious attachments. The solution is fully integrated with O365 as well as other cloud-based providers. BitDam’s cloud-based content security service employs O365 APIs to protect the organisation’s email – and secure email gateways against attacks embedded in URL’s and files.

BitDam’s solution seamlessly integrates with existing IT infrastructure. Its on-boarding is easy, requiring no changes to security infrastructure policies, or processes. It is typically deployed in a non-intrusive mode. During our POC, acquiring a copy of organizational traffic is usually completed in under 5 minutes and protection of all email traffic commences immediately.

Sign up for BitDam Cloud Trial.

Read more
Liron Barak
Liron Barak
1 minute & 54 seconds read · August 23, 2018

BitDam Eliminates the Collaboration Content-Security Tradeoff

Content sharing is everywhere.

The number of collaboration channels that we use to share files and links keeps growing…Starting with email services such as Gmail and Microsoft O365, through web drives like Box, Dropbox and Google Drive and up to instant communication channels including Zoom, Skype and Slack. There is no doubt that content sharing is everywhere and we use it more than ever. However, when embedded within communications that look innocent, the same files and links are also the main entry point for targeted and advanced attacks.

Collaboration channels as an entry point for attackers

Up to 90% of cyber threats handled by IT and security teams in the the past 12 months, entered organisations as email attachments, links, or via web-based drives. In addition, content-borne attacks are increasing in both volume and severity. Data breaches are doubling annually. Moreover, email spam grows by 100% every month, with over 80% of these communications containing ransomware.

Attackers also become more sophisticated. Ever changing malware with ‘moving parts’, ‘barely-there’ sleep mode strategies while scanning, among other evasion techniques, all aim to bypass security solutions in order to attack organisations. In addition, today’s attacks are identified in the wild for under 24 hours only. This makes existing security approaches – that react to known attacks – untenable when attempting to prevent ever evolving content borne cyber attacks.

A new approach to content security

BitDam proactive content security service makes it possible to immediately detect and block both known and unknown attacks in links and file attachments. The result? eliminating the collaboration and security tradeoff.

BitDam couples deep application learning with alien application code flow detection. Based on that, it stops illegal attack code hidden in links and documents from being run by enterprise applications. BitDam proactive cybersecurity delivers the highest detection rates of advanced attacks launched from within the communication stream. No need for ongoing security updates or patches. By nature, BitDam protects applications forever. Our content-security approach is capable of meeting today’s content-borne cyber threats, preventing the full range of logical exploits, hardware vulnerabilities, macro-based attacks, ransomware, malware, APTs, spear phishing, one day, and zero day attacks.

By preventing advanced content-borne threats across all enterprise communication channels, BitDam empowers organisations to collaborate safely. To lean more, contact us or try it on your own.

Read more
Liron Barak
Liron Barak
0 minutes & 59 seconds read · August 20, 2018

Introducing BitDam Total: Detect Advanced Cyber Threats Online

BitDam Total is a free file scanning service for malware that enables the detection of advanced content-borne attacks.

The service scans all standard document formats including PDF, DOC, PPT, XLS, and ODP among others. It detects sophisticated and advanced threats previously undetected by other scanning services. BitDam Total addresses the growing need for content security scanning that can determine whether a file is malicious before it is opened, to thwart today’s advanced threats. While Anti-Virus scanning services exist, they provide only a partial solution as they focus primarily on known attacks and signature based detection methods. What’s missing are scanning services that can detect and block any exploit, any payback and any known and unknown vulnerability.

Used online, BitDam Total detects malicious files that contain both known and unknown threats within seconds. No payment and subscription needed. Our proactive attack prevention couples deep application learning with alien code flow detection, making it possible to immediately identify malicious files. These include the full range of logical exploits, hardware vulnerabilities, macro-based malware, ransomware, spear phishing, one day, and zero day attacks.

Try BitDam Total, to experience the BitDam advantage yourself. Scan a file. Its simple and free.

Read more
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

Schedule a Demo

Enter your email to get a free trial invitation