Share:

When reversing malware samples, one of the things that we as analysts look for are places where the attackers slip up. This can be anywhere from using the same strings, to weak obfuscation routines, or re-using the same snippet of code. When we talk about the attackers, there is this misconception that they are these super villains who can only do evil, but keep in mind they are humans too.

Today’s sample is no different. While reviewing a Triage console, we came across an interesting phishing email that contained the following attachment. Here are the Yara rules that tripped:

 

Figure 1. Signatures that tripped

While we’ve seen tons of word documents that contain macros, it’s typically more rare to see this triggering in conjunction with XOR exe’s. These types of payloads are usually used in conjunction with an exploit and later unpacked. By using xorsearch, we can confirm that there is a malicious payload inside. * Note that an XOR of 00 is just the data itself.

 

Figure 2

Figure 2. XOR payloads

By opening the file, we can confirm the presence of a macro. Big surprise on this one.

 

Figure 3

Figure 3. Macros

However when we hit alt + f11 to try and bring up the macro code, it is password protected. Looks like it’s time to use our macro password breaker! (Figures 4, 5, and 6)

Figure 4

Figure 4. Password in word document

Figure 5

Figure 5. Breaking the macro password

Figure 6

Figure 6. Broken password shows macro code

Once the macro code executes, a copy of the word document will be saved to %temp%/300.rtf and %temp$/301.rtf, our malicious payload will be saved to %temp%/q2.exe, then executed.

When looking at q2.exe, we can see the compile path of “T:mandatoryHenceoneDateeffort.pdb” for the file. This gives us some information that the malware could have been compiled from the T directory, lies in the “mandatory” directory, and is the project name of “Hence”. But what about that XORed payload?

By performing a single-byte XOR with the key of 0x66 (or “f”). We know this was successful, as we can start to see other strings and structures of an executable.

 

Figure 7

Figure 7. Our XORed program, with PE sections

One thing to note is that the attackers really went the extra mile to make it hard to run, as it is missing the standard “MZ”. This is something that would be added at decoding time of this payload.

Figure 8

Figure 8. Missing headers

By scrolling down and looking at some of the strings, we can see that some of the data may be encoded with “aPlib”.

Figure 9

Figure 9. aPlib reference

 

For stage two, by scrolling further into the encoded data, we can see the domains that will be used for calling out.

Figure 10

Figure 10. C2’s

 

Or better yet, why not take a look at the user agent string that’s going to be used? And let’s not forget that “the malware is using HTTP/1.0 as well.

Figure 11

Figure 11. User agent for signatures

 

Or that it’s capable of grabbing a ton of credentials, mostly FTP.

Figure 12

Figure 12. Tons of credentials targeted

 

PhishMe customers already have detection for this type of attack.

The following combination of Triage rules can be used to detect this:

  • PM_Office_With_Macro
  • PM_xor_This_program_* (there are over 500 of these rules already in Triage)

The following PhishMe Targeted Phishing Intelligence reports have been available since the day this campaign started

  • Threat ID: 4445
  • Other related campaigns: Threat ID 4679 and 4696

In order to help protect others, we have provided the C2 and user agents identified within this malware on our github. You can download it here.