BitDam Blog

Roy Rashti
Roy Rashti
3 minutes & 1 second read · November 20, 2018

Thanksgiving malware campaign

Happy thanksgiving… or is it?

In the last few days, BitDam detected several different malicious files that drop malware, many with names related to Thanksgiving.

The files, holding names such as “Thanksgiving-wishes.doc”, “Thanksgiving-greeting-card.doc” or “Greeting-Card-Thanksgiving-Day.doc”, pretend to be a nice and innocent Thanksgiving card.

A quick glance shows that when BitDam detected those files, they all had relatively low detection rate on VirusTotal (around 6% detection rate). This number is obviously growing as we speak. Why? As these files became popular, other engines adjusted their signatures to detect them.

I was interested to see what differs in those files that made them harder to detect. I randomly picked one – (Sha1 09b4a05719b24789c2a0511184ccd8ffc0a08ea0; Sha256 ed642de0c3636ede6a55294dd38d44a91ca69b07f9ce5d11cfbcf5f84b32aa2f), and here are the findings:

Attack analysis

When opening the file, it shows a screen that tries to lure the user into enabling macros as shown in Figure1.

Figure 1

A quick glance into the macro shows an ‘AutoOpen’ function that will run as soon as the file is loaded. The function contains obfuscated code. The attackers are using mathematical operations such as Sin, multiplication, division and so on.

Seeing such techniques is not rare when it comes to code obfuscation. I’m sure that most engines are used to handle such techniques. However, there was something that did catch my eye; It seems that the attackers tried to hide something inside an OLE object.

The code shown in Figure2 highlights the access to the text inside this object.

Figure 2

Let’s roll back for a second. If we take a closer look at Figure1, or the screen we see when the document is loaded, we can see something odd in the top left corner. I highlighted it in Figure3.

Figure 3

That small black square is a text-box. Enlarging the text-box reveals its actual value, which is an obfuscated CMD line, shown in Figure 4.

Figure 4

In the end of the function, the VBA script executes a command prompt with the data shown above. It’s easy to spot the ‘^’, which is used as an escape character and in this case – used to fool static scans.

My personal opinion is that using the text-box object and accessing it through code is the differentiator that helped the attackers bypass many solutions at this time.

The obfuscated CMD line is used to start a Powershell process with the code shown in Figure 5.

Figure 5

I think that the code is self-explanatory; The attackers try to download the payload from the following domains-






The payload (Sha1 38eba0f30f4ae52916ba75f10d30376c675bda6e, Sha256 db5794255ef6c3f576d39fc8b69ec3af020a1a30dcacfbc25c6fa176fe40445e) seems to be Emotet, one of the famous malwares of 2018.

Here are some other droppers using similar techniques (Sha1s):

  • 7482ff036f86b35288fdd78bb159e883f911f08f
  • 747c1de46ef95cf12543a0c9e61529fdad9da96b
  • bb277708c03a5f3d4b76f82563a68312a6424981

How come it wasn’t detected?

How come that this attack bypassed 94% of the engines listed on VirusTotal? I guess that being reactive rather than proactive makes the big different. Again. Unlike other solutions, BitDam detects any malicious file, no matter if it’s known, a variation of a known file or completely unknown. Check it out yourself for free here.

Read more
Too old to be detected
Roy Rashti
Roy Rashti
3 minutes & 12 seconds read · October 18, 2018

Too old to be detected

Back in 1992, when Personal Computer were not yet a common property, Microsoft attempted to base their stance as pioneers in the new emerging industry of office tools for PCs as they released Excel 4.0.

As part of their offering in that version, XLM was the default macro language used in Excel 4.0. XLM provided the users with a broad functionality to analyze and edit workbooks.

XLM provides a toolset relatively similar to the VBA (Visual Basic for Applications) that is vastly used these days. Among others, it lets the user load DLLs into the applications, run external software and so on.

Macros are a known attack vector

Due to the capabilities of the macros, using it to attack is a path most traveled by attackers these days. It’s very common to see a VBA code that automatically executes being used as a first-level attack surface.

The XLM is embedded in the workbook while the VBA is an external ole stream which makes it easier to analyze and extract.

As a result, solutions that aim to protect end users from such threats have learnt to deal with VBA-embedded attacks.

How many protection systems would detect such attack?

To demonstrate how this may work, I’ve created a simple ‘doc’ file with a malicious VBA code.

That code runs on startup launches a CMD that starts a Powershell process. That Powershell tries to download and execute an executable file. It briefly looks as shown in Figure 1

Figure 1

I used the VirusTotal platform to check if existing solutions would detect it. Although this might not be the ultimate way to benchmark, it’s quite reliable and can provide us with a significant feel about the detection rate of a file.

When I uploaded this file to VirusTotal, it showed about 40% detection (shown in Figure2).

Less than we’d expect, but it feels safe to say that substantial amount of solutions were able to notice the maliciousness present in this file.

Figure 2


Next: challenging detection engines with malicious XLM

Following that result, I was intrigued to see how the engines in VirusTotal will handle an XLM attack similar to the VBA one.

XLM macro is based on formula commands. One can use loops, call external DLL’s functions and a variety of commands supported by the engine executing the macro.

I created the following XLM macro in a macro enabled sheet, shown in Figure 3.

Figure 3

The “Name Manager” that you can see in Figure 4 allow us to control aliases given to registered functions in the module. I registered the top left cell as the entry point for the predefined ‘Auto_Open’ function that runs automatically when the file is being loaded.

Figure 4

The Powershell command executed here is exactly the same as the one before.

Testing this file in VirusTotal resulted the concerning result shown in Figure 5; zero detection!

Figure 5


Old attacks may be more dangerous than you’d think

Just imagine how easy it could be to attack someone using this simple mechanism that although old, still works. But you know what – I wasn’t so surprised. The inability to handle such attacks is originated in the fact that those kinds of attacks were not seen before by these cybersecurity vendors.

Most current solutions base their detection mechanism on attack structures that they have seen in the wild. Therefore, if an attack was not seen in the past years, it might not be detected.

XLM might be very old technology but it is still supported and can still be used to get a stranger inside your computer.

The horrifying part of it: an attack that was created back when I was born can still cause harm.

BitDam’s unique engine is completely agnostic to the structure of the attack and thus is able to detect attacks, whether it’s known or unknown, new or super-old, from the very first day it’s deployed.

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

Does Your Cyber-security Measure Up?

CISOs today find it difficult to gage how well the organisation is protected against attack. Enterprise security typically comprises multiple dedicated solutions, spanning across different security needs, technologies and organisational teams. One of the key challenges in achieving an integrated security assessment, is gaining an understanding of existing security gaps and what is needed to close them.

Security statistics can help illustrate some of the hurdles facing CISOs in assaying security readiness.  Organisations are reportedly receiving 1 malicious file for every 300K emails delivered. Over the past year, BitDam has encountered a ratio of 1 malicious file for every 5K-50K emails. This ratio changes between vertical markets, and depends on whether the organisation utilizes a SPAM filter responsible for eliminating most of the trivial attacks or not.

This gap between the different email attack vulnerabilities illustrates the difficulty of measuring up cybersecurity in an organisation.  Security penetration tests may be helpful in determining the effectiveness of your combined security tools, to identify strengths and weaknesses. We’ve created a simple penetration test available online to give you a sense of  your current level of security. The BitDam Email GW security penetration test lets you assay your existing security tools’ ability to detect and prevent advanced content-borne cyber attacks. And all that is done in 3 simple steps.

The BitDam PenTest

Upon providing a testing email address, BitDam will send a controlled penetration test that includes a series of advanced cyber attacks. These attacks are embedded in files that are sent to your designated account. Attack emails that are delivered to your test inbox indicate a failure point in your cyber-security. The BitDam PenTest report provides test result details that will give you insights into the strengths and weaknesses of your content security readiness across your communication channels.

Its safe and free.  Sign Up for the BitDam Pentest

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