TechWizMac

For a lot of organizations, phishing attacks occur daily, coming in waves via predictable patterns of attack and leveraging legitimate websites that have been taken over and used to host phishing, malware driving or ransomware schemes. Sometimes these attacks use domain based deception to confuse targets. Cyber-criminals nowadays have moved away from static domain name generation to more dynamic, fluid methods. Their aim is to produce and test candidate domains before hand in order to better evade blacklisting and counter-measures. Enter DGAs (Domain Generation Algorithms). One clever way of targeting specific groups or organizations is by  detecting and generating domain names in "tune" with what individuals in that domain would be used to seeing daily. Once candidate domains have been identified, a DGA is used to create pseudo random sub-domains resembling non-malicious domains. It is a vicious circle where attackers could be gaining control of domain registration accounts perhaps through phishing of their legitimate owners. Once they get these building blocks, they create any number of sub-domains, which they could then use in exploit kits or phishing/spam campaigns. DGAs have evolved so rapidly and are being heavily leveraged for malicious purposes. In cases like the one below, the domain generation seems to use semantic and natural language processing techniques to detect names that can be used to obtain shadow domains.

What is being exploited? First, the ability to generate DNS names non restrictively. DNS is not sophisticated enough to verify if what is being generated is for a malicious intent. Second, domain ownership cooperation to participate in the shadow domain generation scheme. Third, the method by which humans evaluate text, at least in western cultures. Western patterns of writing evaluate text from left to right but DNS is technically evaluated from right to left in order to obtain the proper DNS hosting information. If the DNS name is long enough, a non-technically savvy person will miss the information required to properly ascertain the nature of the domain hosting a particular name.

How it happens:

1) Attack is assembled using a DGA generated domain name closely resembling a legitimate website such as this from a recent attack :

   Legitimate site:

DGA generated:

2) Send socially engineered emails to intended targets containing the bogus DNS name hosting the attack (phishing, malware driving ransomware).

As you can see above, both URLs are quite similar but for an individual not acquainted with precise URL formatting, this would very closely resemble the legitimate site. The recipient would be highly inclined to trust the link and visit it. Once there, the page would look precisely like the original page, down to using the same sources as the legit page to obtain CSS, images and scripts to properly format appearance. The only difference between the legitimate web page and the malicious one lies within the form section of the page handling the login process once submitted, in this case a PHP script set as the form-action:

The body of the email reveals the true nature of the socially engineered link:

Whois information about the hosting domain reveals the true owners of the bogus site:

============================================================= https://keybase.io/techwizmac --------------------------------------------------------------------

I hereby claim:

 * I am an admin of https://techwizmac.tumblr.com  * I am techwizmac (https://keybase.io/techwizmac) on keybase.  * I have a public key ASBvAIKrHJ5ThfIK6td95KyonjyKgJk9DsEWQh4_XDXWlAo

To do so, I am signing this object:

{    "body": {        "key": {            "eldest_kid": "01206f0082ab1c9e5385f20aead77de4aca89e3c8a80993d0ec116421e3f5c35d6940a",            "host": "keybase.io",            "kid": "01206f0082ab1c9e5385f20aead77de4aca89e3c8a80993d0ec116421e3f5c35d6940a",            "uid": "07b61ae11c1a5714d08ce90d82921919",            "username": "techwizmac"        },        "service": {            "hostname": "techwizmac.tumblr.com",            "protocol": "https:"        },        "type": "web_service_binding",        "version": 1    },    "client": {        "name": "keybase.io go client",        "version": "1.0.20"    },    "ctime": 1490968867,    "expire_in": 504576000,    "merkle_root": {        "ctime": 1490968804,        "hash": "4f770d64035d3313840698fe048c4e82186405673114594828658e400ae79268a575c9e1fa1eeea815dd8fc2af73c3a00bc209a64b3f19d0d4fc9cb711a6c45a",        "seqno": 991210    },    "prev": "25dc05543830c6de46aeac61ed4c0c2c0ad6e4c6adbe9e78b6e2fe4bf96a84e4",    "seqno": 8,    "tag": "signature" }

which yields the signature:

hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgbwCCqxyeU4XyCurXfeSsqJ48ioCZPQ7BFkIeP1w11pQKp3BheWxvYWTFAv97ImJvZHkiOnsia2V5Ijp7ImVsZGVzdF9raWQiOiIwMTIwNmYwMDgyYWIxYzllNTM4NWYyMGFlYWQ3N2RlNGFjYTg5ZTNjOGE4MDk5M2QwZWMxMTY0MjFlM2Y1YzM1ZDY5NDBhIiwiaG9zdCI6ImtleWJhc2UuaW8iLCJraWQiOiIwMTIwNmYwMDgyYWIxYzllNTM4NWYyMGFlYWQ3N2RlNGFjYTg5ZTNjOGE4MDk5M2QwZWMxMTY0MjFlM2Y1YzM1ZDY5NDBhIiwidWlkIjoiMDdiNjFhZTExYzFhNTcxNGQwOGNlOTBkODI5MjE5MTkiLCJ1c2VybmFtZSI6InRlY2h3aXptYWMifSwic2VydmljZSI6eyJob3N0bmFtZSI6InRlY2h3aXptYWMudHVtYmxyLmNvbSIsInByb3RvY29sIjoiaHR0cHM6In0sInR5cGUiOiJ3ZWJfc2VydmljZV9iaW5kaW5nIiwidmVyc2lvbiI6MX0sImNsaWVudCI6eyJuYW1lIjoia2V5YmFzZS5pbyBnbyBjbGllbnQiLCJ2ZXJzaW9uIjoiMS4wLjIwIn0sImN0aW1lIjoxNDkwOTY4ODY3LCJleHBpcmVfaW4iOjUwNDU3NjAwMCwibWVya2xlX3Jvb3QiOnsiY3RpbWUiOjE0OTA5Njg4MDQsImhhc2giOiI0Zjc3MGQ2NDAzNWQzMzEzODQwNjk4ZmUwNDhjNGU4MjE4NjQwNTY3MzExNDU5NDgyODY1OGU0MDBhZTc5MjY4YTU3NWM5ZTFmYTFlZWVhODE1ZGQ4ZmMyYWY3M2MzYTAwYmMyMDlhNjRiM2YxOWQwZDRmYzljYjcxMWE2YzQ1YSIsInNlcW5vIjo5OTEyMTB9LCJwcmV2IjoiMjVkYzA1NTQzODMwYzZkZTQ2YWVhYzYxZWQ0YzBjMmMwYWQ2ZTRjNmFkYmU5ZTc4YjZlMmZlNGJmOTZhODRlNCIsInNlcW5vIjo4LCJ0YWciOiJzaWduYXR1cmUifaNzaWfEQHRYoJJH67k4/ogngVe10vS9TmCG3SrYrouszZM8E85hb193EezHueVNMgm3LstLJ9Z3iSPuXtbVgjg3eLnUcwmoc2lnX3R5cGUgpGhhc2iCpHR5cGUIpXZhbHVlxCCqhvqfUDQncIafz+CRqbkE/soAAv5e6qAKCXXs3Uo+/6N0YWfNAgKndmVyc2lvbgE=

And finally, I am proving ownership of this host by posting or appending to this document.

View my publicly-auditable identity here: https://keybase.io/techwizmac

I read an article on how using encoded spaces in the URL could increase the chances of deception on a phishing campaign but it was not until I received an attack similar to it myself that I was able to see more clearly how it operates. It appears that since the bad guys have noticed that most people are not that dumb anymore and actually pay more attention to what the URLs actually contain, they decided to come up with a method that would conceal the real [and complete] URL behind the scheme. Essentially, the method uses the character space [escape encoding %20] as a filler in the URL to push the rest of the contents of it out of sight so that only the initial part remains reasonably visible. The scheme assumes that once the victim lands on the target site, that is where they would pay attention, to make sure they are at the “right place”.

It started with an innocent looking email asking to accept a refund :)

The email contains a link to “make a secure online refund” and which, on the source code of the email reveals this: 

The “secure” link [not secure at all since no SSL is enabled] is using a compromised website in Denmark which, when opened, jumps to another compromised site:

This is where things become interesting as  there is a base64 string on the next target of the jump and I can only imagine what that looks like on a browser when presented without restrictions. Here is what it looks like when intercepted:

If it is not intercepted, here is how the URL looks like:

A quick glance shows the URL looking totally normal and it appears that we have landed on a legitimate Bell.ca website. But after a second look, there is something unusual at the beginning of the URL. It reads:

data:text/html;https://....

When I saw this I was like, holy cow, this is not being executed as a URL but it is simply being displayed as a “visual label” to deceive the cautious observer into thinking that he/she has indeed landed on a legitimate URL - in this case monbell.bell.ca, the French language login portal. BUT if this is not being treated as a URL, what is going on here?! If I would have not intercepted the URL to see what is going on behind the scenes, I would have not noticed that there is actually spaces filling up the rest of the URL field where there appears to be more stuff! look further:

Another base64 encoded string starts after the spaces!  If I intercept the scheme and prevent any JS execution,  and simply display the URL content, I can see that there is a two-step base64 encoded string carrying out the deception. First the initial string after the second URL jump, which is HUGE:

After decoding the above first string, I start to see where this is going more clearly. The string contains a clever piece of JS code

where it first, ensures that the browser is Chrome and second, uses a variable called “space” to build and display the filler I was seeing displayed in the URL. Next to the spaces, there is the second base64 string which when decoded, it contains an HTML page with yet another inner JS script:

This final JS script contains the URL where the victim finally lands to. The interesting thing about this last script is that the code is “PACKED” using a known function as there is no practical way of easily concealing the purpose of JS code. By using an unpacker, we can finally see the open code at the heart of the scheme and which contains the malicious URL:

I came across yet another method of delivering malware via email, by using an attached ZIP file containing another ZIP file and this in turn containing a javascript file as shown. The double compression is most likely done to increase the chances of email AV evasion:

The javascript file is tightly packed and seems to be using some obfuscation to conceal the malicious part of the code

After some beautification, the code becomes more readable and easier to follow:

The second part of the code is where the real action seems to be occurring but it is hard to see what is really going on without decoding the contents of the variable “str”. I tried decoding the contents of it by using a straight base64 conversion but is it not showing anything meaningful. The real value of the encoded content is extracted by doing a REGEX replacement within the BCDEFGJMNPTUVWXYsdfgjt(str) function and after that it is being executed via an ActiveX Object. At this point it is clear that this JS code was designed to compromise Windows based systems. Finally I decide that instead of trying to decode the content of variable “str”  I can simply make it run safely - after I make some changes to the code:

and then call the JS file from within an HTML file:

Once I launch the HTML file I can start testing:

and VOILA, I can now see what the rest of the code is doing:

and the crux of the what the script does is finally evident. The encoded string contains lines of PowerShell commands that pull a file from a web location, drop it on to the Application Data portion of the user profile and launch it [load it on memory for execution]. It is also clear now that encoding the lines that contain Powershell calls using specific Win OS locations and names makes the code mode difficult to be picked up and blocked by AV technology. 

I have not examined payloaded files for a while but this one was interesting enough so i gave it a crack. The file came attached to an email urging the receiver to open it to see see a list of “terminated employees”:

The attached file is a small excel object which, when analyzed yielded the following:

and deeper inspection showed the following:

The above report indicates that the file auto-opens the file “d.exe” when launched, a sure sign that the XLS file in question is indeed payloaded. The rest of the report indicates that there are Base-64 strings most likely used to obfuscate code, and which, from experience I know by now that it is most likely the code used to retrieve a file from an malicious internet location and drop it locally so that it can be executed to compromise the victim system. This scheme is turning old but still remains true as there are many unsuspected users relaying on a Windows based system and perhaps running their local accounts in “elevated” mode. If not, it would still be possible to contaminate the user’s local profile and perhaps allow the malware to hook itself up so that it accomplishes its mission.

I wanted to see more clearly how this is was still being done so I extracted  the embedded code, which is obviously enough, Windows shell/ VB Macro based. The code  below shows the content of the macro:

A closer look at the above code shows a VBScript subroutine containing many variables being dimensioned to hold values and arrays and at the end, they are all assembled together to execute the  ‘real” code. The main code seems to lie within the contents of the arrays. I explored several tools to deconstruct the arrays easy and quick but I could not find anything specific that would do this. The obfuscation did not seem complex but rather done with some automated tool such and CrunchCode to make it more difficult to extract. In the end I resorted to a manual method:

I transported the result of each array back in to the VBScript code to see where everything fits and it is starting to make more sense now:

and after some more replacements and following the code I was able to finally obtain the clean VB Macro:

So, the final code above uses PowerShell/VBScript  to open a subroutine, create an ActiveX object and use that to download the file “officeup.exe” from the URL location and finally, silently execute it. Once this execution completes, the malware gets itself hooked up on to the system and compromises it.

Spotted this scam recently via a share from a FB friend:

The page shows more clearly some obvious signs:

I came across a different variety of payloaded ms-word file from a recent malware dropping attack via email. The interesting thing about this file was that aside from dropping a malicious Windows executable object on to the victim’s computer, it was using heavily compromised websites to host the bad file. As with most recent attacks, the file arrived via email:

Quick analysis of the file revealed obvious signs of being payloaded here:

and here:

and in-depth analysis showed details of its true purpose here:

and here:

Five different links were used to host the same file “hs.exe” - in case either one failed to deliver the file :

h~~p://natureshavenshop.com/system/logs/hs.exe h~~p://www.distributorhelm.co.id/system/logs/hs.exe h~~p://www.koffermann.at/system/logs/hs.exe h~~p://www.everybitbaby.com/system/logs/hs.exe h~~p://www.ancientherbsfoodproducts.net/system/logs/hs.exe

Upon further exploration of these web locations, I found out that they were badly compromised to say the least. I explored the first two sites from the above list and show here what I found. The first one appeared to be a site that sells natural products but the home page has been modified to include an obfuscated piece of javascript code that performed malicious activity if executed by a browser. 

The malicious code was not plainly clear as it was obfuscated using Base64 encoding:

But once decoded and beautified, a javascript code showed up:

leading to another malicious website!

The second site, showed obvious sings of defacement by a hacker group:

and the HTML code revealed details of the group claiming responsibility for it. 

The hash for the malicious MS-Word file used in this attack here:

Ms-Word objects are one of the preferred vehicles for internet scammers to carry payloads that lead to either downloading of malicious executable objects or subversion of existing objects in Windows systems. Concealing the true nature of the payload is a priority for this to work. I have been observing how this is done and wanted to show more details about the process so I pick one of the files I recently received to demonstrate this. Preliminary inspection of the file shows all the hallmarks of malicious activity:

The embedded VBA scripts create local objects...

and build a URL using the predefined FPATH VBA function...

The operation uses a string of integers to conceal the letters that make up the URL. The string of integers correlate to the decimal values from the ASCII table:

a quick conversion of the values show the corresponding characters matching indeed a URL, in this case H**P://im-journal.com/kjg7665rf. DNS lookup shows the IP being owned by the SFR from France but being located in the US.

Testing the concealed URL leads to a direct download of an EXE file:

and which TrendMicro classifies as a LOCKY trojan..

Recent email attachment submissions show a continued pattern of using MS-Word documents as attachments to emails appealing to Social Engineering techniques to get victims to open files. 

Preliminary check on the attached file shows usual signs of concern (VBA macros embedded, OLE formatted object):

Deeper analysis indicates specific tricks I have seen before on typically payloaded MS-Office objects:

Upon code inspection of the Macro portion of it, some new and interesting variation of the method of dropping a file is observed. The code is not obfuscating the URL where an EXE file is being dropped from - perhaps this file was crafted more hastily. Closer examination reveals that the code relies on specific features of certain DLL libraries to perform a number reversing and a binary writing to a specific memory location - perhaps to inject itself on to an existing process.

The code has been made to run better on Win-x64 operating systems that have an updated VBA engine (v.7) commonly part of newer versions of MS-Office.

Finally, the routine handling the file dropping and memory writing is set to run automatically on file opening.

The object’s hash signature indicates that the file has been picked up by other analyzing groups and the location of the download server is Toronto, Canada.

As mentioned in the previous post, I am showing here a slightly different type of Ms-Word file but essentially doing the same type of executable dropping method and malware site connecting. This MS-Word object arrived attached on an email pretending to be sent from my own account - a spoofing technique being used quite heavily recently to confuse unsuspected users into trusting the content of the email.

Details of the attached file show a word document containing macros and 3 VBA objects:

A quick examination using a trusted OLE checking tool reveals signs of a payload similar to the file on the previous post but there are a couple of extra ZIP library objects involved.

Now to the code examination part. Noticeably, variable names and functions are set using either Spanish or Italian language an indication of perhaps European origin. 

As in previously seen instances, there is a purposeful and naive method of obfuscating the intention of the code by using specific variable or function names, in this case trying to show that temperature calculations are being performed but in reality, it is just a smoke screen for the real intentions, which is deconstruct the string of integers by running the SPLIT operation within a loop and store the converted results in an array variable.

Next, a subroutine handling the auto-open of an executable file that is being dropped. A ZIP32 Library is used to assist in this operation.

And finally, the crux of the operation, dropping an executable file using an XML command. The string is again cleverly obfuscated to perhaps confuse AV engines and the curious observer.

I had to break the long XML line into two parts to show more clearly what I find is the evident intention of dropping a file on to temporary location and executing it.

By checking the SHA256 Hash signature of the file against VT I can confirm that the file in fact has been named and tagged as a VBA downloading agent.

I have been receiving numerous versions of malicious MS-Word files that arrived attached to emails recently and a few of them contained payloads that resembled ones I have seen other people analyze so I am posting here some of my own analysis of the same kind of objects.

The first object is a word document received via email using the same deceptive technique of luring recipients to either click or, in this case open the attachment. I am not posting the email details but I provide enough details about the malicious object. First lets have a look a the header information and details of its structure:

The file contains some macros/VBA modules that would get executed once the file opens - hoping that macro execution is turned on as it is the case with most default installations of MS- Office Products.

And using a different tool showing the existence of OLE formatted modules:

A quick check of the health of the file shows clear signs of being malicious. A few indicators immediately call my attention, one being the use of a particular string “Zodr” and also the use of Base64 Strings concealed as string of numbers, a clear indication of the need to obscure something in the code using an obfuscation technique of some sort:

The question is, just how exactly is this being done? To see this I need to extract the two VBA modules and look more closely:

And there it is in the code, what appears  to be a string of integer numbers within a VB function and assembled into an array of integer numbers using the function SPLIT. In between that, there is a number conversion calculation and also the use of the string “Zodr” as a separator for the string contained within the variable “HanSoloVud” :

I have cropped the full string of numbers but still, it is possible to see a pattern of 4 digit integer numbers aligned together and which, with the help of SPLIT, are disassembled and converted to make up a string of characters and stored within an array and then a variable, containing a malicious URL location from where the code downloads something, perhaps an EXE file with a malicious payload. A further examination of other streams within the file shows the suspicious sign of auto-execute behaviour:

And the existence of an XML instruction using shell script to drop an executable file called “chester.exe” on to a TEMP location and using the string “Zodr” to conceal the intent within the string. The auto-execute is set to run the dropped EXE file once the document is opened.

The cleaned XML command string would read like this:

 “Microsoft.XMLHTTP/Adodb.Stream/Shell.Application/WScript.Shell/Process/GET/TEMP/Type/Open/write/responseBody/savetofile/\chester.exe”

I am not going to elaborate on the details of the rest of the content of the VBA scripts to avoid making the post too long. After checking for the file’s hash signature on VT and other malware sites, I can see that the same file has been classified and tagged as bad.

Analysis of a PDF file I received via email:

A PDF Exploit Analysis tool allows me to inspect the file and deconstruct it. The header of the PDF shows the creation date and time:

And the type of objects and actions included in the file and streams:

There is one suspicious /OpenAction setting which would be relevant if there were /JS or /JavaScript objects but there none present so I keep looking. The number of objects and streams is unusually high so there must be some interesting objects amongst them.

And bingo, I spot a couple of URI actions connecting to suspicious URLs:

and here:

On further inspection of all the URLs present in the file, a long list of malicious sites is discovered!

Some of the URLs match the ones I spotted previously within object definitions (OBJ 19). Upon  checking the URLs, most are active and most likely compromised to perform drive-by malware of some sort.

A check via VT shows results of analysis and classification from various sources:

This attack occurred in the form of an email containing an attachment of file type RAR. This extension would normally indicate a “rar” compressed file but indeed more than just an innocent compressed object was embedded in the file. The attached file was name CCE and was followed by the date and a random number - something like “CCE29032016_00058.rar” - 29032016 being the date the attack occurred. According to email data, the flood of emails containing the attack was released sometime in the early morning of the above date and originated from Eastern Europe, possible a Russian location.

The content of the attachment was a Javascript file that used clever obfuscation to hide the fact that it was performing a trojan-drop from various locations across the internet. URL locations indicated that the websites were legitimate but previously compromised due to poor security practices and being used to participate in the scheme by hosting the malicious objects that would be called to be dropped once the victim opened the attachment and the system executed the java file.

Initial examination of a sample attachment file shows the embedded object:

And using a different tool:

Post decompression, the embedded JS file was obtained and the contents of the java file made available:

The obfuscation technique of the code appears to be using a dictionary of random words to name variables and actions. The core of the attack lies on the URL that is being used to obtain the drop that would further contaminate the system:

The above function calls the URL “h**p://pasirputih-jbi.com/76g8h8y7″ (DNS 103.29.215.191). The list of URLs used in this attack indicates that a lot of effort went into preparing the scenario and resources and provide multiple methods of avoiding detection and network blocking.

Other URLs used:

h**p://demoweb.ir/76g8h8y7 h**p://pasirputih-jbi.com/76g8h8y7 h**p://divinite.mx/76g8h8y7 h**p://canceralia.eu/ h**p://slacwpa.org/

Virus Total provided several classifications for the malicious object:

Phishing scheme started with victims receiving an email containing a link purporting to be from the legitimate Bank:

From: C.I.B.C Alert Service <[email protected]> Message-ID: <[email protected]> Dear Client You have an important response from CIBC available in your secure online message centre. Please logon to online banking to view this message or send us a reply. To view your message Login here. Best Wishes CIBC Message Team

Contents of the link:

href="http://info-web.secureit.cibc.al/cibwealth3636/mm/CIBC/i/"

Once the link gets opened the fraudulent page comes up resembling the legitimate CIBC Online page:

Notice the URL and DNS hosting info (Albania). No HTPPS used for encryption.

Legitimate CIBC Online Banking Page hosted via Akamai Technologies (DNS info returns Germany).

HTTP Headers of web interaction to fraudulent site.