Friday, August 5, 2016

INFO: Upcoming Projects

Hello again!

I am here, once more, to apologize for how quiet this blog has been. I have been extremely busy, but that does not mean I have not been gathering information for future posts! In fact, let's go over some of the future things I will be doing around these parts...

1. I will be updating the blog in general. The reading list is out-of-date, and I have not updated my list of projects in quite some time. I intend to remedy these things and other blog aspects in general.

2. I will be writing some new malware analysis posts. I have ran into a few new infections (new to me, at any rate), and I will be writing up some analyses of those incidents.

3. I am going to ramp up my creation of threat intelligence. I am going to focus more on OpenIOC, Yara, and a third format that I cannot disclose at this time (or rather I am choosing not to). I want to do a better job of contributing to the community in general; plus, my threat intelligence skills are nascent at best and could use the practice.

4. You may have noticed that post #8 disappeared. I pulled it down for a few reasons, but mostly because I have decided to change the format of what I was doing with my fake BSOD/fake tech support web page research. I am going to continue to gather samples (as I have been doing this whole time) until I feel I have what I want/need. Then, I am going to write up a serious, legitimate report on what I have found. The report will include prevalence of certain TLDs, prevalence of certain countries, prevalence of certain registrars, as well as a table of unique phone numbers and registrant e-mails being used in these scams. I will even include pie chart for all of you graph lovers out there!

Anyhow, that is all I have to say for now. Stick around, and get ready for some exciting times around here.


Thursday, April 28, 2016

Post #19 (Or... "Anyone Want A .JAR Of .DOCX?")

It happened like it happens so many times on a daily basis. “Yes, you see, I took my company issued laptop home. Yes, and I got an e-mail from someone I trust, and it had an attachment, and I clicked on it. When the attachment just wouldn't open, I realized I had done something wrong. Oh, the e-mail? Yeah, no, it wasn't corporate e-mail. I was checking my personal e-mail. I was at home!”

The, attachment, in this case, was very succinctly named “Docx.jar”. Now, as a novice in the arena of malware analysis, I like .JAR files, because all I need to do is dump them into JD-Gui and start rummaging through code. However, before we do that, let's at least get the footwork out of the way.

Filename: Docx.jar

Size: 212Kb

MD5: ab3e11b7a5fd924be74d3d737fddb9f8

Basic file information. That having been said, let's get right to it!

The first thing I did, as previously stated, was open the .JAR file in JD-Gui.

Those are some wonderfully obfuscated class names right there. However, the class names are not really what drew my interest. That was all in the META-INF > MANIFEST.MF section:

So, I have taken the liberty of researching each of these libraries and summarizing them below:


This is json. Not a whole lot more to say other than that, but if you want a description: "JSON is a light-weight, language independent, data interchange format." Also, as of this writing, this is the current version of JSON, so we know the malware sample can't be any older than 2 months, again as of this writing.



"Synthetica is a Look and Feel for Swing and is based on Synth which is part of the Java Platform version 1.5. Synthetica provides many different looks through Themes for the core components of Swing with rounded borders, shadowed popup menus and nice icons. Moreover it enables you to modify existing Themes and to create your own look and feel only by editing a XML-based configuration file - you don't have to write complex Java-GUI-Code." So, this is used for making the GUI component of the malware (as seen by the attacker) appear as desired.



This is a theme for Synthetica. So, this is what the GUI will look like to the attacker. The reference website has screenshots and a demo.



"Java Look and Feel for cross-platform Swing applications." So, more GUI stuff. Enough said.



"Global keyboard and mouse listeners for Java." Okay, now we are getting into the meat of things here. If I had to take a guess, I'd say we are spying on keyboard and mouse actions.



"BridJ aims to be the ultimate Java / native interoperability library (BSD-licensed). Call C, C++, ObjectiveC libraries without compiling native code." Again, just conjecture here, but this should let us reach a little more deeply into the OS itself, rather than relying solely on outside Java code.



"The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time." Gonna guess that this will be used to feed verbose data back to attacker.



"This library allows you to use your build-in or external webcam directly from Java. It's designed to abstract commonly used camera features and support multiple capturing farmeworks." Scary beyond reason, but also fairly obvious.


So, if it wasn't already painfully obvious, this malware is a spying utility. It can access the webcam, as well as perform mouse/keyboard logging. From the attackers side, they will see a nice web GUI from which they can spy on their targets.

NOTE: When I initially started looking at this in my office's VM, I could've sworn that I saw a library that dealt with microphone/audio hooking, but I haven't been able to confirm that while analyzing at home.

I didn't dig any further into the source code, mostly because it was too obfuscated for my nascent skillset to handle. I did, however, have a basic idea of what the malware would do, so it seemed the time to switch over to dynamic analysis mode.

So, I first did some diffing, then I did some packet captures. But, before we even go that far, let's look at what happened when I opened the command line and just launched the malware:

C:\Users\Malware Inspector\Desktop\Samples\Samples\Downloads>java -jar Docx.jar

Main-Class : qua.quaverse.qarallax.Bismillahirrahmanirrahim




khSixtyThousandSixHundredThirtyFive Error for Resource : embedding

Looking for Resource on Linked : sun.misc.Launcher.AppClassLoader

id=72000000095 to_id=71000000095

C:\Users\Malware Inspector\Desktop\Samples\Samples\Downloads\Docx.jar

C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwpDqN9EMt3c\XvBa_


Downloading Library:

=> C:\Users\MALWAR~1\AppData\Local\Temp\1664903225628141467460795952903701664903

2279860 => C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwpDqN9



Downloading Library:

jar => C:\Users\MALWAR~1\AppData\Local\Temp\166502376151971210550982508354760166

50237642460 => C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwp



Downloading Library:

0.3.10.jar => C:\Users\MALWAR~1\AppData\Local\Temp\16650368914530208876014234498

671816650368931477 => C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c



Downloading Library:

=> C:\Users\MALWAR~1\AppData\Local\Temp\166506227099993837444470750942358166506

22728788 => C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwpDqN



Downloading Library:

=> C:\Users\MALWAR~1\AppData\Local\Temp\166507268013941068474720167227991166507

26818341 => C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwpDqN



So, despite ALL of that obfuscation effort, I now see where the library files are being downloaded from. First, let's get some info on that host!

Grabbed the WHOIS information for the host, and here is what we get:


Registry Domain ID : 2002157315_DOMAIN_COM-VRSN

Registrar WHOIS Server :

Registrar URL:

Updated Date: 2016-04-23T08:02:50Z

Creation Date: 2016-02-12T09:44:30Z

Registrar Registration Expiration Date: 2017-02-12T09:44:30Z


Registrar IANA ID: 1454

Registrar Abuse Contact Email:

Registrar Abuse Contact Phone: +90.2122132963


Domain Status: ok

Registry Registrant ID: CID-901373.G3Z7E1G2

Registrant Name: NicProxy Customer

Registrant Organization: Whois Privacy Protection Service.

Registrant Street: Elif Sok. No 4

Registrant City: Istanbul

Registrant State / Province: Sisli

Registrant Postal Code: 34394

Registrant Country: TR

Registrant Phone: +90.2122132963

Registrant Phone Ext:

Registrant Fax: +90.2122132963

Registrant Fax Ext:

Registrant Email:

Registry Admin ID: CID-901373.G3Z7E1G2

Admin Name: NicProxy Customer

Admin Organization: Whois Privacy Protection Service.

Admin Street: Elif Sok. No 4

Admin City: Istanbul

Admin State / Province: Sisli

Admin Postal Code: 34394

Admin Country: TR

Admin Phone: +90.2122132963

Admin Phone Ext:

Admin Fax: +90.2122132963

Admin Fax Ext:

Admin Email:

Registry Tech ID: CID-901373.G3Z7E1G2

Tech Name: NicProxy Customer

Tech Organization: Whois Privacy Protection Service.

Tech Street: Elif Sok. No 4

Tech City: Istanbul

Tech State / Province: Sisli

Tech Postal Code: 34394

Tech Country: TR

Tech Phone: +90.2122132963

Tech Phone Ext:

Tech Fax: +90.2122132963

Tech Fax Ext:

Tech Email:



DNSSEC: Unsigned

URL of the ICANN WHOIS Data Problem Reporting System:

Also, we can see that the IP address is, and the website title is “Jrypter | Jrypt it!”

Did a quick Google on that site name, and it turns out Jrypter is a “Java binary crypter”, according to their website. It also claims to be provided by QUAverse. So, I performed another Google query, and we see that:

"Quaverse RAT or QRAT is a fairly new Remote Access Tool (RAT) introduced in May 2015. This RAT is marketed as an undetectable Java RAT. As you might expect from a RAT, the tool is capable of grabbing passwords, key logging and browsing files on the victim's computer...

...Attached to it was a .zip attachment containing an executable .JAR file." (source:

Well, that is starting to sound very familiar, I'd say. But, I don't want to call it a day just because I think I found the malware family to which this file belongs. That isn't very fun, nor does it teach me anything.

So, interestingly enough, the path to which the files are dropped are the same in my test environment as they were when I discovered the malware initially on the victim's machine. Files are dropped to “C:\Users\{USERNAME}\.3ojHSEnbdL” and additional subdirectories.

At this point, a startup entry is created as well:

"C:\Program Files\Java\jre1.8.0_77\bin\java" -jar "C:\Users\Malware Inspector\.3ojHSEnbdL\Q5Dn8.1H8FbR9Is0x\c6x84fwpDqN9EMt3c\XvBa__DMv6TPoRppl.jar"

That file “XvBa__DMv6TPoRppl.jar” is just “Docx.jar” again. At this point, I started looking at network traffic to/from my machine, and I noted this in CurrPorts:

java.exe 2956 TCP 50989 1714 Established C:\Program Files\Java\jre1.8.0_77\bin\java.exe

So, there is our established connection to the malware's server over port 1714. Time to perform another host lookup!

Domain Name:

Registry Domain ID: 1968501325_DOMAIN_COM-VRSN

Registrar WHOIS Server:

Registrar URL:

Updated Date: 2015-10-14T15:33:47Z

Creation Date: 2015-10-14T15:33:46Z

Registrar Registration Expiration Date: 2016-10-14T15:33:46Z

Registrar:, Inc.

Registrar IANA ID: 9

Registrar Abuse Contact Email:

Registrar Abuse Contact Phone: +1.8773812449


Domain Status: clientTransferProhibited

Registry Registrant ID:

Registrant Name: Genenergy Padicious

Registrant Organization:

Registrant Street: 848 N. Rainbow Road #8001

Registrant City: Las Vegas

Registrant State/Province: NV

Registrant Postal Code: 89107

Registrant Country: US

Registrant Phone: +1.7754326453

Registrant Phone Ext.:

Registrant Fax:

Registrant Fax Ext.:

Registrant Email:

Registry Admin ID:

Admin Name: Genenergy Padicious

Admin Organization:

Admin Street: 848 N. Rainbow Road #8001

Admin City: Las Vegas

Admin State/Province: NV

Admin Postal Code: 89107

Admin Country: US

Admin Phone: +1.7754326453

Admin Phone Ext.:

Admin Fax:

Admin Fax Ext.:

Admin Email:

Registry Tech ID:

Tech Name: Genenergy Padicious

Tech Organization:

Tech Street: 848 N. Rainbow Road #8001

Tech City: Las Vegas

Tech State/Province: NV

Tech Postal Code: 89107

Tech Country: US

Tech Phone: +1.7754326453

Tech Phone Ext.:

Tech Fax:

Tech Fax Ext.:

Tech Email:

Name Server:

Name Server:

DNSSEC: Unsigned

URL of the ICANN WHOIS Data Problem Reporting System:

The IP address is Now, I will NOT port scan an IP address I do not own nor do not have written permission to scan, but I can see if the IP address has ever been hit by one of Shodan's scanners. Unfortunately, it had not been hit by Shodan, but the original IP address that was listed in my packet captures (so, where the host lived on 04/15/2016) was, and that had been hit by Shodan:

22 - SSH

25 - SMTP

53 - DNS

80 - HTTP

110 - POP3

143 - IMAP

465 - SMTPS

587 - SMTP

993 - IMAP-SSL

995 - POP3-SSL

3306 - MySQL

All common ports, but I did not see that 1714 port listed anywhere, which is a shame.

Dug through my packet captures with Wireshark and Network Miner, but the traffic is encrypted, so couldn't get much deeper at this step.

Now, I did go ahead and run wget against the first host we encountered, and I managed to pull down a bit more than just the original library files:


"Global Keyboard / Mouse Hook for Java applications."



"SQLite JDBC, developed by Taro L. Saito, is a library for accessing and creating SQLite database files in Java."


jna/jna.jar, jna-platform.jar

"JNA provides Java programs easy access to native shared libraries without writing anything but Java code - no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes"


dumper/laz.qrc, outdmp.qrc, wtfdmp.qrc

NOTE: Had to tackle these a bit differently. Despite them all having the same extension, taking a look at the magic numbers for each file (or running them through trid) revealed that they were actually 2 executables and a zip archive file, respectively within the list.

laz.qrc => laz.exe

Once this file was renamed, I just launched it via command line and got the below result; I looked up the LaZagne project, and it is a one-stop application for dumping credentials from various applications:

outdmp.qrc => outdmp.exe

I recognized the icon for this file, and running it via command line confirmed that it was Outlook Password Dump by Security Xploded:

wtfdmp.qrc =>

Had to unzip this file first, but once I did I saw an executable named "qumper.exe". Ran it in command line. This looks exactly the LaZagne project except with a custom banner:

Truthfully, that is where my analysis ends. Seems we have a multi-faceted spying tool that has a range of capabilities, though I am not sure all of them are being employed by the attackers as of yet, or at least not with the dropper I encountered. I may come back and edit this post if I gain more information afterward.

Thanks for reading, as always, and remember to stay safe out there. You never know what risk you may be exposed to at any given time!

Friday, April 8, 2016

INFO: I Have Not Disappeared!

Hello, everybody!

It has been a few months since I last posted, and that is due to a variety of factors (personal/professional time is completely occupied, no good material to write about, etc.) However, I have a few articles lined up, and I should be back to posting in the next week or two.

That was all I really wanted to say. Hope you all are having a wonderful and secure day!


Sunday, January 3, 2016

Post #18 (Or... "Ogres Have Layers, Obfuscation Has Layers...")

So, let's talk about obfuscation.

I am by no means an expert on static malware analysis, but I recently came across a sample that employed a method of obfuscation that I have not yet seen. The sample in question was JS/Kryptik.AYR and the method of obfuscation was a combination of random variable names, string concatenation, hexadecimal values, and tertiary operators.

To start, let's take a block of text out of the malware sample:

Selected text from the original malware sample.

Wow, right? There are a few things going on here. Obviously, the variable names themselves are random to hide their purpose, but beyond that, we see weird operations going on. Those operations are tertiary operations, and they work as follows.

First, we set up a comparison, such as two numbers being compared to one another. Then, we add in the "?" operator, which signifies a tertiary operation. The next two values are the possible values for the variable we declared. So, if the operation we set up results in a "true" result, the first value is assigned, and if the operation is false, the second value is assigned. So, to use an example in JavaScript: var comparison=(1!=2?"true":"false"); will result in the variable "comparison" being set to "true", but if we change it to var comparison=(1==2?"true":"false");, it will instead be set to "false". This, in essence, is how tertiary operators work.

Bearing that in mind, we must then examine the obvious conclusion; obviously, half of the listed strings in the code are garbage, throw-away values that are only there to serve as clutter. Add this to the fact that a large portion of the string values are written in hexadecimal, and you have quite an effective source of obfuscation.

Again, I am not an expert, but if you want to look at what this code is doing, you can either manually decode it, which would be massively time-consuming, or you could perform dynamic analysis, but you will likely get vague results and won't understand the mechanics of the malware itself. Myself, I took the approach of debugging the sample with Firebug as it ran in the browser, along with cleaning up the code and inserting lots of document.write(variable_name). That looked a little like this:

A section of the code that I cleaned up. I chose to group the variables together to make it easier to read.

Once I cleaned up the code, I simply built a small HTML page and loaded it up. Below, you can see the ASCII, full-concatenated value of the variable shown in the last image:

And here we can see what had been hidden behind all that obfuscation. Well... we can see at least one variable, that is.

Well, that is basically all there was to it. Still, the code that had been inserted into the hacked website I reviewed was over 500 lines in length, nearly half of the original webpage's HTML total length, including malicious code.

Let this serve as a reminder that attackers will go to painstaking lengths to protect their assets and prevent analysis/detection of their tools.

Cheers, and stay safe out there!