The Case of the Tricky Tool

Looks can be deceiving. There are times when you think an analysis is going to be easy, and everything points in that direction, until you hit a snag. This happens. Sometimes you've made an assumption that is wrong, sometimes there is a little trick the attacker is doing, and sometimes your tools fail you. This is one of those times.

The Malware

I received a malicious attachment in my email yesterday that uses a technique that I've started to see more and more in documents - utilizing the metadata fields to hold some of the malicious code. The advantage to this technique is that it spreads the code throughout the document and makes it more difficult to analyze. Despite this, all signs pointed to this being an easy document to analyze. As you'll see, I was wrong.

resume.doc
MD5: e618b9ef551fe10bf83f29f963468ade
SHA1: 93993320c636c884e6f1b53f9f878410efca02da
SHA256: d400d6392a17311460442e76b26950a0a07e8a85c210c31e87a042a659dc9c52

Once more, I used REMNux to statically analyze the file. Yes, I could have executed it with Lazy Office Analyzer to speed up my analysis, but frankly my Windows VM is temporarily fubar'd, so I was stuck doing it this way.

The first step in my analysis was to figure out what type of document I was dealing with. Relying on the trusty-old file command, we see that this is a composite document file. This means that we can use the oletools suite to analyze it.

Notice that file also gives us some information obtained from the metadata of the document. The metadata of a document is stored inside the document and contains information about it, such as the last time it was saved, how many characters are in it, and the author. As analysts, we can use this information as indicators, to track actors across multiple documents, and sometimes to provide attribution.

In this case, the author is set to "Caleb Cheng" and was last saved by the username "caive". Are these legitimate? There's no way for us to tell as they could have been modified after the document was saved, but we could at least create a yara rule to track these usernames and see if they pop up in other documents!

Speaking of Yara, my next step was to use the rules from the Yara Rules Project and see what they found inside of the document.

Two of the Yara rules indicated the document contained embedded VBA code. Not surprising as many malicious documents use VBA to execute their second stage malware. Yara didn't find any embedded executables, so this probably meant the document downloads its next stage to execute. The only way to find out was to extract the VBA and analyze it.

The olevba.py script from the oletools suite can be used to extract VBA code from Office documents. Initially, I didn't give it any options to so I could see how the code looked natively. Fortunately in this document, the VBA code was pretty short and easy to understand.

The code can be broken down as follows:

1. Declares a number of variables.
2. Reads the value of the metadata title field with the ThisDocument.BuiltInDocumentProperties("title") command.
3. Converts the title to ASCII from Unicode. In reality, this is just converting the characters to their integer equivalents and putting them into an array.
4. Loops through each letter of the title and subtracts 7 from its ASCII value.
5. Converts the array back to Unicode. This is just converting the array back to a string.
6. Reverses the string (e.g. turns "abc" to "cba").
7. Uses the shell() function to execute some of the string, after replacing and splitting it up with multiple values.

From this, it appeared that the title of the document contained the encoded command that gets run, so I wanted to see what this value was. There are multiple ways to do this, but one of the easiest is to use the metadata extraction tool exiftool. This is where my trouble started.

As expected, the title field contained obfuscated text that needed to be decoded in order to see exactly what the malicious document was doing. Before I could decode it, however, I needed to extract it properly.

The Problem

Exiftool will display periods for both actual period characters and binary data, so I first attempted to use some command-line fu in order to properly extract the characters. Normally, this can be done with the following command, which will convert all characters into a hex-encoded string that you can put directly into a python script.

exiftool -title -b  resume.doc | hexdump -v -e '"\\" "x" 1/1 "%02X" ' ;

Since the VBA code was fairly straight-forward, I wrote a quick python script to decode it. However, when I ran the script I didn't get the results I expected. While I saw some PowerShell commands and an obfuscated URL, there were some binary characters that shouldn't have been there; it should have decoded cleanly to text.

This is where I spent the next few hours trying to figure out what was going on.

At first I thought the VBA code was doing some value conversions when it converted from Unicode to ASCII integer values; this was not the case. I tested this by writing some similar VBA code, launching it in Word, and debugging it to see the values before and after the conversion - all was as expected.

Then I went over my python script to make sure I hadn't made a programming error (this would not have been the first time). Everything was good.

Finally, I went back to the Word document itself to see if I could figure out if my command-line fu had worked correctly. Thats when I noticed something interesting. If I opened the document in a hex editor and compared the location where the title string was located at to what was extracted by exiftool, some of the binary characters were different.

In the example above, the top hex dump is from the document itself and shows exactly what is within the document. The bottom is what exiftool extracted. You can see that in the original document, the highlighted byte was 0x83 but when exiftool extracted it, the byte was converted to 0xC6 0x92. This occurred multiple times in the extraction.

I'm currently not sure why exiftool did this. I tested it with multiple options and the latest version and all did the same thing. I'm waiting to hear back from the developers to see if I found a bug.

Unfortunately, I was unable to come up with some genius command line fu to extract the real title string in one fell swoop. So how did I do it? I copied the bytes from the hexdump command above and did some copy and pasting to get it in the right format. Sometimes thats just the easiest option. If anyone comes up with anything, please let me know.

I should also note that some other metadata extraction tools, like olemeta.py from oletools, crashed when attempting to extract the title. I suspect this is because they expect this to be a string and not have binary characters in it.

The final python code I came up with is below and can be downloaded from here.

When run, it gave me the output I expected.

As initially thought, the malicious document downloads an executable, saves it to the file system, and executes it. At the time of this writing, the file (61a5af5acea342ee5ca8dbd2fba0de06) is still accessible at that IP address. We'll save that analysis for another day.

This analysis is a prime example as to why you should trust, but verify, your tool results. In the beginning I assumed that exiftool was extracting the data properly - and why not? It had never failed me before. However, when the results were not what I was expecting I had to dig deeper to see what the issue was. Without the knowledge on how to look into a file and compare what my tool was giving me to what I was actually getting, I wouldn't have been able to figure out that my tool was giving me incorrect data and work towards a process of getting it rectified.

Update

I posted on the exiftool forum asking about the potential bug I found. Phil Harvey, the creator of exiftool, said the changing of the characters is because exiftool is attempting to convert the binary character to UTF-8. Unfortunately, outside of using the -v4 option to dump the output in hex and carve it back (which is what I did with hexdump), there is other workaround in exiftool at this time. I'll keep looking for a better way to do this going forward.

Document Analysis - 2018-newsletters.xls

Today I received what was clearly a malicious document in my email, so to celebrate the publishing of my second PluralSight course - Performing Malware Analysis on Malicious Documents - I thought I'd go through the analysis of the document.

The document came in as an attachment in email and was named 2018-newsletters.xls.

MD5: 46fecfa6c32855c4fbf12d77b1dc761d
SHA1: c028bc46683617e7134aa9f3b7751117a38a177d
SHA256: 4e8449f84509f4d72b0b4baa4b8fd70571baaf9642f47523810ee933e972ebd9

You can download the file from here. The password is the last 8 characters of the filename, all lowercase.

To analyze it, I'm going to use REMNux, the malware analysis Linux distribution put together by Lenny Zeltser. This distro has all the tools we need to analyze the document.

The first thing I need to do is figure out what type of Office document we're dealing with. By running the Linux file command on the document, it tells us we're dealing with the composite file format, or structure storage format, of Office. Knowing this helps us figure out what tools we can use on the file.

Next, I want to see if there's anything interesting inside of the document. There are lots of tools that can be used for this, but for now I'm just going to use Yara with the rules downloaded from the Yara Rules project.

Two yara rules get set off - Contains_VBA_macro_code and office_document_vba. Both rules indicate that the XLS contains VBA macro code. Macros are often used by attackers within documents to download additional malware or execute more code, such as PowerShell. If we didn't think this spreadsheet was malicious before, this certainly raises our suspicions.

Next, I'll try and extract the macro code. My favorite tool for doing this is olevba, which is part of the oletools by decalage. When I run it, I use the --deobf and --decode options to allow olevba to attempt to deobfuscate and decode any strings it can.

The resulting file is an excellent example of the obfuscation that attackers will go to in order to try and hide what they are doing from analysts. Lets look at a few of the functions and obfuscation performed.

In the example to the right, the first function that is executed by the XLS is Workbook_Open(). This function calls the VBA Shell() function; Shell() is used to execute operating system commands. The parameters to the Shell() function are other functions, which lead to other functions, which lead to obfuscated strings.

We can manually trace through the code to figure out what this is doing.

1. The first parameter to Shell() is a function call to a function named tabretable().
2. tabretable() calls 3 different functions, one of them being sunafeelo().
3. sunafeelo() has 4 lines in it.
1. The first line sets a variable to the string "external hard".
2. The second line sets a variable to the string "cM" using the Chr() function. Chr() returns the ASCII equivalent of the number given to it. This is a technique that is often used by attackers to obfuscate strings.
3. The third line creates the string "D.ex" by combining Chr(), a period, and the results from the Left() function. In this case, the Left() function returns the first 2 letters from the left side of the string "external hard", or "ex".
4. The last line combines all of these together, along with the results from the Right() function. Here, Right() returns the right-most two characters from the string "free ", which are "e " (e plus a space).

The result from the first parameter to Shell() is "cMD.exe /c ", so we know its creating a command to execute on the system. I could go through all of the rest of the code to figure it out, but why should I if there are tools that will do it for me?

To do this, I'll use Lazy Office Analyzer (LOA). LOA works by setting breakpoints on various APIs and recording their parameters. This allows us to watch when the malicious document writes files, connects to URLS, and most importantly, executes commands.

In the image above (click to enlarge), you can see how I ran LAO. In the end, the document executes obfuscated PowerShell that we could go in and deobfuscate some more. However, we see the URL hxxps://softarez[.]cf/mkeyb[.]gif in the code, which we can infer means that it will be downloading and executing whatever is returned.

This site was not up at the time I analyzed it, but fortunately it was analyzed by someone on hybrid-analysis, and shows that the downloaded files is a Windows executable, which VirusTotal indicates is a Zbot variant.

However, with regards to analyzing the malicious Excel file, we're done. Since documents are typically used as the first stage of a malware compromise - in other words, they download or drop more malware to execute - we've figured out it does. The malicious document downloads an executable and runs it.

From here, we can start looking on our network for anyone accessing this site, as they will most likely have opened this document.

As I stated in the beginning of this post, my second PluralSight course was published and teaches how to analyze malicious documents. If you want to learn how to do everything I discussed here, plus a lot more, go check out the course. I welcome any feedback on it - good or bad - and any new courses you'd like to see from me.

IOCs

2018-newslettes.xls

MD5: 46fecfa6c32855c4fbf12d77b1dc761d
SHA1: c028bc46683617e7134aa9f3b7751117a38a177d
SHA256: 4e8449f84509f4d72b0b4baa4b8fd70571baaf9642f47523810ee933e972ebd9

URLs

• hxxps://softarez[.]cf/mkeyb[.]gi

Malware Analysis Course on Pluralsight!

Since 2010, I have been running my Introduction to Malware Analysis course at various conferences and organizations, and have taught over 200 students. I've heard from many of my former students that they've used what they learned in the course to help them successfully combat malware in their organizations - some have even gone into the malware analysis field themselves!

I only teach my course once or twice a year; for the past few years it has only been at DerbyCon. The problem with that is the material sits unused for most of the year, with no one gaining benefit from it.

So, when I was approached by the great people at Pluralsight to record my course and put it online, I jumped at the chance. It was a long process to do, but well worth it. This week, the course was released under the name Malware Analysis Fundamentals.

Malware Analysis Fundamentals is an online version of my Intro to Malware Analysis course. The course takes you from knowing nothing about malware analysis to being able to manually analyze malware in a safe and consistent manner. Like my regular course, you still analyze real malware using the techniques used by incident responders everywhere.

The one thing that I found out while creating this was that its not possible to put everything from my sit-down course into the online version. If I did, the course would have been at least double the length and no one wants to sit through that! Therefore, Malware Analysis Fundamentals gets to the essence of the material and teaches the fundamentals needed to get the job done.

There is also more to come. I already have plans for other MA courses at Pluralsight, branching into more advanced techniques and courses on analyzing alternative forms of malware.

I hope you enjoy the course and I look forward to hearing everyone's thoughts on the course!

Malicious DNS Namespace Collisions

Over the last few weeks, I've noticed a problem come up again in multiple places that I first saw many years ago and apparently is still very common - DNS Namespace Collisions. DNS namespace collisions occur when a private domain name is able to be resolved on the public Internet; whether it is intentional or not. ICANN has a lot of information on this if you are looking for a deep dive on the subject; instead I will be focusing on the potential security issues.

The Issue

Let's start with an example. Suppose you own the Internet domain example.org. This is your Internet presence - all your emails are @example.org, your web servers are in this domain, even your Active Directory domain is corp.example.org. All is well in the world.

When configuring hosts in your organization, one of the things you will do is set up your DNS suffix search list. This is the list of domains your systems will add to a host name if they can't initially resolve it. In our scenario, your DNS suffix search list is example.org and corp.example.org. So, if a host attempts to resolve mailserver, they might also try mailserver.example.org and mailserver.corp.example.org.

And let's also suppose that you follow good security practices and have split DNS so no one on the Internet can resolve your internal host names. You also do not allow internal hosts to directly resolve Internet host names.

Your happy domain.

Any issues so far? Nope. The computer gods are smiling upon us.

As your organization expands, you find the need to add a new internal domain so you choose example.com. Uh oh! You don't own that domain on the Internet, but you'll only be using it on the internal network. Not an issue, right? No, it is a problem.

The issue lies in that you do not own the domain example.com but are using it internally; this is a DNS name collision. The issue comes into play soon as a host accesses the Internet directly (from home, a client's network, etc.). When this happens, they won't be able to resolve hosts with the suffix example.org or corp.example.org - but as soon as they try to resolve with the suffix example.com (which you don't own) they will succeed.

So how is this an issue? In the best case, it isn't. If your hosts try to resolve something that example.com can't resolve then aside from some information leakage things should be OK. However, what if they try to resolve something that does exist in example.com and then try to start using it?

On the Internet, only example.com will resolve.

For example, our hosts are on the Internet and are trying to the internal mail server host name. The only one that is resolvable is mailserver.example.com, which we don't own. They then start to send emails - your private, internal-only emails - through a server you don't own. See the issue now?


This only happens if that host name already exists in the external domain, right? Wrong.

If DNS wildcards are used, now all of a sudden any host name is being resolved beyond your control and your hosts are sending data to potentially malicious servers. Think of how easy it would be to gain information on your organization or compromise your hosts if I could tell your hosts where their proxy, active directory, or mail servers were when they were outside your organization. And how would you ever know?

This is not a theoretical attack. In the last few weeks I have found multiple organizations where this is occurring. Specifically, they are using domains internally that they do not own, their hosts go outside their organization and are resolving these domains to malicious IP addresses.

And there are organizations that are squatting on multiple domains (including obviously internal ones) and setting up wildcard DNS to point them to their own IPs. For what purpose? I don't know, but I suspect it can't be good.

Detection, Prevention, and Response

So how can you detect this? A few ways:

1. Create a list from your DNS for all domains being used by your clients related to your organization. Make sure you own all those domains. If not, what IPs do they resolve to? Consider switching from them. (This is also a good threat hunting technique!)
2. Windows hosts like to resolve wpad/wpad.dat when browsing. The DNS search suffix tends to get added to that, so look for any HTTP requests to the Internet for wpad.dat, then look for what domains the requests are to. Even if they are not your own hosts (e.g. consultants), you should still be concerned as they could be used as a pivot point into your network.

By the way, wpad.dat is not something you want your hosts doing this with.

Prevention of this is actually pretty easy - just make sure you own any domain you use, or use ones that do not have Internet TLDs. (However, from my research there may be issues on this with some versions of Windows.)

If you do find this happening on your network, I would suggest immediately looking to see what your hosts are resolving, what data is going out, and more importantly, what is coming back in.

I would also recommend blocking the IP addresses and external domains on your Internet devices to prevent internal hosts from accessing them.

In the end, this is a big problem that I don't think many realize is going on. Fortunately, its fairly easy to detect and start investigating. Doing it now will probably save you a lot of hurt in the long run.

MASTIFF Online

MASTIFF has been a pet project of mine for about two years now. While it has not progressed as far as I would have liked, we made a major announcement this week.

On Monday, a free online interface to MASTIFF was released at https://mastiff-online.korelogic.com/. This interface allows anyone to upload files, have MASTIFF process the files, and see the results generated.

If you are not familiar with MASTIFF, it is an open source framework for automating the static analysis of malware. It essentially will determine the type of file you are analyzing and only run the static analysis techniques for that file against it. This allows fast extraction of data the analyst can then examine.

The online interface was created for two reasons:

1. When you start processing a number of different file types, the pre-requisites start to get cumbersome and difficult to install. The online interface alleviates this by allowing you to analyze files without installing everything.

2. Our #1 request was a web interface to the system. While the interface used on MASTIFF Online is not open source itself, we are hoping this will give users what they want.

If anyone has any questions/comments/suggestions to MASTIFF or the site, please let me know!

Installing Yara into IDA Pro 64-bit Linux

tl;dr Install a 32-bit VM, compile Yara, copy files over. See link below for files to just install.

Last Friday, pnX posted that he updated his awesome IDA plug-in, IDAScope, to include Yara support. This means that you can now run Yara sigs against files you are reversing to help in the analysis process.

After I installed the new version of IDAScope into IDA Pro, however, I received errors stating that Yara could not be imported. I thought this was odd as I had Yara installed on my system, until I remembered how IDA works on a 64-bit Linux system.

The following is based off my observations and experiences. If I am incorrect on this, please forgive me and let me know in the comments.

IDA is a 32-bit program. Even the 64-bit version of IDA is compiled as a 32-bit program.

$ file idaq idaq64
idaq:   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0xcb635dd38de5c73f050de37a0f2e492688b3ab9a, stripped
idaq64: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x1f03dcff4bfd776b23df71c8d9d471fb63b0bf48, stripped

This causes a number of interesting issues on 64-bit Linux systems, especially with Python. Hex Rays has gotten the majority of these fixed in the default install so you don't worry about them, and the way it does this with Python is by allowing you to install a bundled Python into the IDA Pro directory. (There are other ways, but I have not done them.) This gives you a working "out of the box" product.

This also means that when you want to install a new Python library and use it in IDA, you have to install it into the IDA's bundled Python directory as well. If this is a pure Python module, then no problem. Just copy and it should work. Yara is different.

Since Yara compiles as a 64-bit library on a 64-bit system, and yara-python does the same, we can't just install it directly into the IDA Python directory. If you do, you'll receive errors that IDA is unable to load a 64-bit module.

In order to get Yara working, we'll need to compile it as a 32-bit library. The easiest way, IMO, to do this is to load a 32-bit Linux system into a VM, compile Yara, then copy the files into your IDA installation. I did this in a Debian 6.0.3 and it worked without a problem. Just to be safe, make sure you are using a system with Python 2.7 as well since that is what IDA bundles.

There are two files you will need: the Yara library libyara.so.0 and the Yara Python library yara.so (located in the Python dist-packages directory after installation). Follow the instructions to compile and install Yara in your 32-bit VM, and copy the files onto your 64-bit system. libyara.so.0 goes into your base IDA install directory, and yara.so goes into the python directory underneath that.

After you do that, Yara-python will be installed and will work great!

Don't want to go through all the trouble of installing a 32-bit VM, compiling, and copying? I don't blame you. I uploaded the version I compiled to my Google Drive here.

yara-ida-libs.tgz (SHA256: 38674b584adf3932e5cd1cafbd0bb288b7db3302304a83041bad9295472aa064)

Just untar this into your base install dir for IDA and you should be good to go.

Hex Rays has published instructions on how to install Python packages from Pip on a 64-bit system. I recommend checking them out. This time, my way just felt easier.

Installing BinDiff on Linux Mint 14

I recently upgraded my system to Linux Mint 14 and went about re-installing all my software. When I got to Zynamics/Google BinDiff, I found I had an issue:

$ sudo dpkg -i bindiff401-debian50-amd64.deb

Selecting previously unselected package bindiff.
Unpacking bindiff (from bindiff401-debian50-amd64.deb) ...
dpkg: dependency problems prevent configuration of bindiff:
 bindiff depends on sun-java6-jre; however:
  Package sun-java6-jre is not installed.

Unfortunately, BinDiff requires sun-java6-jre, which is not in the Linux Mint repository, nor any other repository I could find. I could circumvent this by installing BinDiff by using the --ignore-depends=sun-java6-jre option to dpkg. However, every time I went to install updates I would get an error message that BinDiff was broken, and be prompted to uninstall it before I could continue.

However, I found a work-around - create a dummy package named sun-java6-jre using the tool equivs. (There are some docs out there on this, but I was unable to find a non-Google cached copy, so here was what I did.)

Linux Mint has equivs in its repository, so if its not already installed, apt-get it.

Next, run equivs-control sun-java6-jre and this will create a file named sun-java6-jre that you will need to modify.

At minimum, you'll need to uncomment and/or fill out the following fields:

• Package
• Version
• Maintainer

I also filled out the description fields so I would remember what it was.

After the file is modifoed, run equivs-build sun-java6-jre and you should see something similar to below:

$ equivs-build sun-java6-jre
dh_testdir
dh_testroot
dh_prep
dh_testdir
dh_testroot
dh_install
dh_installdocs
dh_installchangelogs
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
dpkg-deb: building package `sun-java6-jre' in `../sun-java6-jre_6.0_all.deb'.

The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!

Once that has successfully completed, you should have a sun-java6-jre_6.0_all.deb file in your directory. If that failed, you probably forgot to modify one of the fields in the file.

Finally, just dpkg -i the new deb file and BinDiff, and you should be ready to go!

$ sudo dpkg -i sun-java6-jre_6.0_all.deb
Selecting previously unselected package sun-java6-jre.
(Reading database ... 237677 files and directories currently installed.)
Unpacking sun-java6-jre (from sun-java6-jre_6.0_all.deb) ...
Setting up sun-java6-jre (6.0) ...

$ sudo dpkg -i bindiff401-debian50-amd64.deb
Selecting previously unselected package bindiff.
(Reading database ... 237681 files and directories currently installed.)
Unpacking bindiff (from bindiff401-debian50-amd64.deb) ...
bindiff license has already been accepted
Setting up bindiff (4.0.1) ...

$

Then you are good to go!

My Take on the City of Akron Hack

On Thursday, May 16, 2013, a Turkish hacking group called Turkish Ajan hacked into the City of Akron and released a number of files that contain personal information on a number of Akron citizens. According to the city, the attackers were able to gain access into some internal systems where they obtained tax information.

The news has died down on this for the moment, but from the information that has been released, there are some things we can infer:

1. The attackers compromised the city's public website. From the errors that were being displayed on the site, information that has been released from the city, and the way this group works, it was likely through SQL injection (although this has not been specifically stated yet).

2. The attackers compromised the city's internal systems and obtained access to tax systems. It is unknown if they were able to do from the city's public website, through the tax paying system, or some other server. In any case, this appears to be where the attackers got the files they posted.

3. Around 25K people are affected.

4. The FBI is involved and was called in quickly after the compromise was discovered. IMO, this is good.

Any additional information on what happened is pretty much speculation. Trust me, I've been speculating alot and have a pretty good idea of what happened, but I have no proof. Hopefully whoever is doing the forensics for the city will have their findings released at some point. As an Akron citizen, and tax payer, I want to know this information.

However, there is one thing that I think needs brought up. Why was this information stored unencrypted? If it was encrypted, how did the attackers obtain access to the keys to decrypt it?

The information that was released contains social security numbers of both the taxpayer and their spouse, and credit card numbers. According to PCI standards (and my understanding), the credit card numbers should have been encrypted. The federal government is required to comply with PCI, what about the city of Akron government?

As for the SSNs, I don't know of any specific regulations that requires that information to be encrypted (please let me know if there is), but I can't imagine that there is any reason it shouldn't be. I have a feeling there are at least 25,000 people who agree with me.

One final item of note. The press has been getting quotes from Deputy Mayor Rick Merolla. With all due respect sir, shut up. I can only imagine your IT and information security people are cringing whenever they read your quotes pertaining to the security of the city of Akron systems.

I'm sure you are very smart, but its obvious you are not familiar with information security. Quotes such as "Our systems are all, all our virus protection, intrusion protection systems, all of our virus software is still up to date so we are still not sure how they got in" show this. Let those performing the investigation or the talented IT personnel you employ speak on these things.

If you like, I am personally offering to give you a training course on information security, hackers, and how attacks take place. This will at least give you an idea on why the things you have been quoted as saying are cringe-worthy.

MASTIFF 0.6.0 Released!

The latest version of MASTIFF, 0.6.0, has just been released! Run over to the download site and grab the latest version!

The official changelog is located here, but the major improvements are described below.

Upgrading MASTIFF to the latest version is easy. You can follow this process:

1. Download and install pydeep.
2. Download MASTIFF 0.6.0 and untar it.
3. Run "make test" to ensure you are not missing any dependencies.
4. Run "sudo make install" to install the latest version.
5. Copy the analysis plug-ins (the plugins directory in the tarball) to your location of choice and ensure the config file is pointing to that directory.
6. Add any new options to your MASTIFF config file. The easiest way may be to use sdiff.

Queue

MASTIFF now has a queueing system so multiple files can be analyzed by the framework. To utilize this, give MASTIFF a directory instead of a file to analyze. It will find all files in that directory and its subdirectories, add them to the queue, and begin processing.

The queue is maintained within the MASTIFF database. So, if you have to stop MASTIFF in the middle of its run, it will begin re-processing the queue when its restarted. Some additional options have been added to allow you to work with the queue:

• --clear-queue: This will clear the current queue.
• --ignore-queue: This will ignore the queue and just process the file you give it.

Analysis plug-ins are also taking advantage of the queue. The pdf-parser and ZipExtract plug-ins have a new option ("feedback") which allow you to feed files from the plug-ins back into the queue for processing. For example, the ZipExtract plug-in will add all files that were extracted from the archive into the queue for processing.

Fuzzy Hashing

Fuzzy hashing is not something new within MASTIFF. However, we have changed the Python library used for it. Previously, we used pyssdeep but found that there were a number of stability issues with it on OSX and when processing large amounts of files.

Therefore, we have switched to pydeep (https://github.com/kbandla/pydeep). Our testing has shown it to be much more stable thus far.

libmagic

There was some confusion on which Python libmagic libraries to use when installing MASTIFF. To help alleviate some of that, the framework has been modified to use two different libmagic libraries:

• libmagic Python extensions (ftp://ftp.astron.com/pub/file/) - This may be installed through the source code or is the library installed as python-magic in most Linux code repositories.
  
• Python-magic (https://github.com/ahupp/python-magic/) - This may be installed through the source code or via Python pip.

If either library is installed, MASTIFF will utilize them.

Other Changes

A number of other bug fixes and improvements have been made. Please see the changelog file for a complete list.

As always, if you have any questions, please email mastiff-project@korelogic.com.

We have alot of great things coming down the pipe for MASTIFF, but if you have any suggestions, enhancements or plug-ins, let us know!

MASTIFF: Automated Static Analysis Framework

Malware analysis is a process that begs to be automated. Messing up one step or running one tool incorrectly can cause you to have to restart the entire process. Fortunately, there are a number of automation frameworks or systems, such as Cuckoo or Threat Expert, that exist to help automate malware analysis.

While these automation frameworks are great, they tend to focus on dynamic analysis (behavioral analysis); static analysis (characteristic analysis) is mostly left out. The static analysis techniques that the frameworks do perform vary, but typically include hashing, strings extraction, some file-type specific tools, along with a couple other techniques. Additional static analysis programs or techniques usually have to be implemented on their own.

To do this, analysts typically create a master static analysis script that runs all of the tools desired against a file. However, if an analysis tool is run against a file type that it cannot analyze, such as a PE header analysis tool on a PDF, you run the risk of crashing the analysis program and, in turn, your automation script.

As an incident responder and malware analyst, I came up against these issues all the time, so I started to look for a solution. Nothing existed to automate the entire static analysis process and allow you to add in your own techniques.

That is why MASTIFF, an open source automated static analysis framework, was created. MASTIFF performs two functions for the analyst:

• The file type of the file being analyzed is automatically determined.
• Only those techniques which work on that file type are applied.

By automatically determining the file type for the analyst and ensuring that only the static analysis techniques that work on that file type are run, analysts can be assured that the risk of crashing the automated process is lessened, and that only relevant data is returned.


MASTIFF works by utilizing plug-ins for both file-type detection and static analysis techniques. The decision to utilize plug-ins was two-fold:

• The types of files analyzed and the techniques available within MASTIFF can be easily expanded by adding new plug-ins.
• MASTIFF is able to be "crowd-sourced".
  

The last reason was especially important. Anyone can create a new plug-in to add a new file type or analysis technique. As more people add plug-ins, the more useful the framework becomes. To facilitate easier plug-in development, template, or skeleton, plug-ins have been included with the project. In just a few minutes, someone can modify a few fields in the template and have a new plug-in ready to go.

In the coming weeks, I'll be posting information and tutorials related to MASTIFF, how to use it, how to create plug-ins for it, etc. Please let me know any questions you have on the framework or there is something specific that should be focused on.

Finally, I want to state that MASTIFF was funded through KoreLogic, the company I work for, and the DARPA Cyber Fast Track (CFT) program. If you are unfamiliar with CFT, I highly recommend looking at their site and submitting a proposal. Its a great program, but you only have until April 1, 2013 to do so and then no further submissions will be taken.

ShmooCon 2013

This past weekend I went to my first ShmooCon in Washington D.C. I have to say this was an experience that I was not expecting. I've been to many security conferences in the past, included RECon, BlackHat, GFIRST, and some SANS and OWASP conferences. ShmooCon ranks up there in the top 2 spots, if not one of the best that I've been to.

The best thing about ShmooCon is that it has a small con feel to it, while having everything the big cons have (e.g. big name speakers, contests, prizes, lots of smart people). It also has a small con price - if you can get a ticket, its only going to cost you around $150.

I was also lucky enough to be selected as a speaker this year, presenting a talk on my newly open-sourced tool MASTIFF. As a speaker, they one of the best run CFP processes I have ever used. After selection, they are constantly available for questions, have excellent moderators and are great in making sure you have what you need.

The talks at the conference were amazing. They are of the highest quality and even the ones I didn't like were full of good information. Since I was releasing MASTIFF the first day I was there, and I was freaking out about my talk (I was in the last speaking slot of the tracks), I didn't get to see all that I would have liked. However, these stood out:

• NSM and more with Bro Network Monitor by Liam Randall - This was the best talk of the conference IMO. Liam gave an excellent talk about what Bro is, how it works, and even how easy it is to extend it. His presentation was how all presentations should be - easy to follow and good at explaining a relatively complicated concept.
  
• Crypto: You're doing it wrong by Ron Bowes -  Ron gave an excellent talk about some crypto attacks, how they can be performed, and even did 3 live demos (that didn't fail) that performed these attacks. I'm not a crypto guy, but Ron's explanations of everything were easy to follow and entertaining. Plus he used The Call of Cthulhu as some of his encrypted text.

There were alot more that I saw that were excellent, and some that I unfortunately missed. Luckily, ShmooCon makes all their recordings available online for free and should be up in a couple of weeks. I look forward to next year!

2008 Malware Challenge

In 2008, Greg Feezel and I published the following malware analysis challenge. The goal was to answer the questions below and submit them back to us for prizes. While the challenge is no longer going on, we wanted to publish it again so those that wished to try it could.

The malware is contained within a password protected zip file named malware.zip. The password is “infected”. The MD5 hash of the files are:

• 59a95f668e1bd00f30fe8c99af675691 malware.exe
• 31d2ec3b312d0fd27940aae5c89e3787 malware.zip

Situation:

A system administrator within your organization has come to you because a user's PC was infected with malware. Unfortunately, anti-virus is unable to remove the malware. However, the administrator was able to recover the suspected malware executable. Your job is to analyze the malware.

Participants should download the malware sample and analyze it. The end result should be a document containing details on the analysis performed. The analysis document can be written in any form, but the following questions and statements should be answered within it. Participants should note when questions are being answered.

• Describe your malware lab.
• What information can you gather about the malware without executing it?
• Is the malware packed? If so, how did you determine what it was?
• Describe the malware's behavior. In other words - what files does it drop, what registry keys does it modify, what network connections does it create, how does it auto-start, etc?
• What type of command and control server does the malware use? Describe the server and interface this malware uses.
• What commands are present within the malware and what do they do? If possible, take control of the malware and run some of these commands, documenting how you did it.
• How would you classify this malware? Why?
• What do you think the purpose of this malware is?

Bonus questions:

• Is it possible to find the malware's source code? If so, how did you do it?
• How would you write a custom detection and removal tool to determine if the malware is present on the system and remove it?

Blog Post Down

Yesterday I published a post on the 2008 malware challenge that I helped put together and how I felt it was being mis-represented in another security company's (pay for) CTF.

The person responsible for that CTF posted a comment on the blog and asked me to contact him, stating it was really a mistake and no ill-intent was involved. I believe him.

The security industry we work in is very small. If your integrity is besmirched* then that can have negative effects on your career or company. I would not want to be responsible for that in the case of a simple oversight.

That is why I removed the blog post. In all fairness, I should have contacted them first before posting anything.

I am still posting the malware challenge and will do so later today.



* Woohoo! I got to use besmirched in a blog post!

NEOISF Puzzle Solution

A few people emailed me with the solution to the puzzle I posted, but I figured I'd post the solution for those that wanted it.

In the puzzle, Van Helsing is attempting to break the crypto that Dracula is using to try and find him. Fortunately for Van Helsing, the program is free and he can download it to see if he can crack it. He ran the program and typed in "vampire_vampire_vampire" and got back "R1lUR1hKXGhHWVRHWEpcaEdZVEdYSlw=". 

Anyone who has done any type of network analysis, or looked at a raw SMTP message, should recognize the output as base64 encoded. Base64 is an algorithm that converts binary data to ASCII so it can be transferred over protocols that do not natively allow binary (e.g. SMTP). It does this by converting every 3 bytes of data to 4 bytes of ASCII. The "=" character is used as padding in case more characters are needed and is often a give-away.

Base64 can be converted using many methods, but since Van Helsing is awesome he is using Linux and uses the base64 command to do so.

$ echo -n R1lUR1hKXGhHWVRHWEpcaEdZVEdYSlw= | base64 -d -
GYTGXJ\hGYTGXJ\hGYTGXJ\

NOTE: Van Helsing really should have redirected the output to a file since the characters could have been binary.

The base64 decoding produced a string that has 2 interesting qualities.

First, the base64 decoded string is the same length as the string he entered. This means that whatever algorithm the encryption program is using may be doing a 1-for-1 character encryption. In other words, the characters in his plaintext is being encrypted one at a time.

Second, there is a pattern of "GYTGXJ\h". The pattern is 8 characters long, which just happens to be the length of "vampire_". Coincidence? Probably not. 

The type of encryption that immediately popped into Van Helsing's head that can have these properties is XOR encryption. XOR is a boolean logic function that can be applied in encryption. This is done by taking a key and XOR'ing each of its bytes against the characters in the plaintext. 

One property of XOR encryption is that if you take the plaintext and XOR it with the ciphertext, it will reveal the key! Van Helsing knew this and XOR'd his plaintext against the ciphertext he got. (He wrote a quick Python script to do so):

$ python xordecode.py GYTGXJ\hGYTGXJ\hGYTGXJ\ vampire_vampire_vampire

18971897189718971897189

Voila! XOR'ing each byte of his plaintext with the ciphertext he received returned a pattern of "1897", which must be the key!

Taking that as the key, he then base64 decoded Dracula's message and applied the key of 1897 to get:

I will be at the Ohio Information Security Summit.

Now Van Helsing knew where he would be and could destroy the fiend!

For those in the know, the key does have some significance. :)

NEOISF Puzzle

This year, I designed a crypto puzzle for the Northeast Ohio Information Security Forum to use at the Ohio Information Security Summit (which I unfortunately was unable to attend). I found out that no one got the answer to it, although a number of people tried.

I decided to put the puzzle up here for everyone to check out and try to solve. I don't have any prizes to give away so this is just for fun. The solution will be posted on November 1.

Also, while I'd love to hear if you solved it, please don't post the answer in the comments so others have a chance.

Dr. Van Helsing is tracking Dracula again. Using his brilliant hacking skills, he was able to break into Dracula's email account and obtained the following encrypted message.

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

From: dracula@bloodbank.ro
To: renfield@sanitarium.edu
Subject: My Itinerary

eBhOXl1UGVVUGFhDEUxRUhF3UV5eGHBZV1dLWlBMUFhfGGpSUk1LXkVBGWREVVReRRY=

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

Through his previous interactions, Van Helsing knows that Dracula uses an encryption program called "31337 Crypt", that utilizes a proprietary encryption protocol. He downloaded the program and typed the following into the program to be encrypted:

vampire_vampire_vampire

The result was the encrypted line of:

R1lUR1hKXGhHWVRHWEpcaEdZVEdYSlw=

Within moments Van Helsing knew what the "proprietary" encryption was and had decrypted Dracula's message. What was Dracula's message?

Good luck!

Tools and News

So first an announcement. At the beginning of December (or close to that) I left my previous position and went back to KoreLogic Security, where I will be working to start up their malware services group, amongst other things. While I am definitely missing my old co-workers, this is a good move for me. Look for some interesting posts here.

A few weeks ago I tweeted: Want to find out how good someone is? Take away all their tools and say, "Now do it.". I wanted to make expand upon that because I got into a good discussion with @jwgoerlich and @rogueclown concerning it, and its hard to really explain what you mean in 140 characters or less.

A few years ago, Harlan Carvey posted about "Nintendo forensics". This was a statement that the forensic industry was becoming more "point and click" and analysts were understanding less and less of what the tools were doing. While some signs have pointed that this is starting to become less prevalent, I believe there are still niches in security where this is either in full-force or starting to become more so.

Fast forward to the present. In the last few weeks I've been building my new work computer while analyzing malware as I get the time. Unfortunately, I do not have all the tools I am used to since I'm waiting for things to be purchased, arrive, etc. This got me thinking - how much do I rely on tools? Could I perform the analysis I needed using that I know?

Now I realize that in information security, or IT in general, its almost impossible to do anything without having tools. Thats not my point - I'm not suggesting that we take away everyone's tools and tell them to analyze malware or perform a pen-test with nothing but a blank OS. Is it possible? I'm sure it is. Would anyone want to? Hell no!

My point was that you never really know how good you are, until you are faced with a situation when you are taken out of your comfort zone and have to rely upon your knowledge and the tools available to you at the moment. I don't always have access to a commercial version of IDA Pro. Does that mean I can't disassemble malware and analyze it? No - I just need to be flexible, use tools that I'm not as used to and use my brain just a little bit more.

I think its a useful exercise in anyone's career to do this. Imagine for a moment that you didn't have the tool(s) you use most in your job - how would you perform your job? What alternatives are available to you and how familiar you are with them? I'm as guilty as anyone else for relying upon specific tools, but this little exercise has helped me look and see where my weak areas are and how I can supplement them.

Perhaps I should have instead tweeted "Want to find out how good you are? Take away all your tools and say, Now do it." That seems to fit my point better.

Answers to the NEOISF Crypto Challenge

If you were at the 2011 Information Security Summit last week, you may have come across the Northeast Ohio Information Security Forum's booth and saw the crypto challenge I created for it.

The challenge was a series of three encoded messages, each more difficult than the last. It seemed to be popular as I had printed off 50 copies of the challenge and they were all gone by Friday morning. Only 2 people, that I know of, finished it (although more may have and just not told me).

The first encoded message was:

Olgrf Rapelcgrq Ner Yrff Rnfl!

This was a ROT13 message that when decoded changed to:

Bytes Encrypted Are Less Easy!

The second message was a bit harder.

Tymxmu Svpvwmeh sg xhp fpskwiu ms elf oej

To make it a little easier, a hint was given to use the first letter of every word from the first solution as the key. This was actually another hint that a key was even required to decode the message. The original message had been encrypted using a Vignere Cipher. Decrypting the message, using the key "BEALE" would produce the following message:

Summit Overview of the booklet is the key

The final puzzle was the hardest of all. The encoded message was:

10 11 32 35 177 42 50 54 44 50 42 82 132 71 100 157 54 60 147 66 50 193 3 60 81 100 157 75 36 106

The hint for this puzzle was "Items from the first two solutions will help you figure this one out!" Each of the first two solutions gave some type of clue as to the cipher used for the last one. The first puzzle's hint was the key for the second puzzle: BEALE.

If anyone searched for BEALE, they would have eventually come across the Beale Ciphers, encoded messages that supposedly point to buried treasure. The only message successfully decoded thus far used the Declaration of Independence as a key. To decode it, you find the word corresponding to the number you are given and take its first letter. IE. If you have a 10, find the 10th word and use its first letter. When you put all of these together you get the decoded message.

This is what you would have to do in order to solve the third puzzle. But what book do you use to decipher it? That is where the answer to the second message comes in. The solutions tells you to use the welcome page in the information security summit booklet. By taking the first letter of each word of the corresponding number, you would eventually get the following message:

now there are no more secrets for you

I hope that those who did this found it fun. I'd love to do another next year, but on a bigger scale. If anyone has any suggestions, I'd love to hear them!

Malware Analysis and Malicious Document Analysis Training Courses

This is a totally self-serving, marketing post. Feel free to click that little X in the upper right corner of your browser.

The Ohio Information Security Summit is coming up again from October 27-28 The conference agenda is starting to fill in and lots of great talks look to be scheduled! I will be speaking there with Greg Feezel and the NE Ohio Honeynet Project.

There will also be pre-conference training from October 24-26. There are more classes this year than last year, many of which look great!

I will be giving my 2-day hands-on Malware Analysis training course again this year. It is a 2-day course that covers the basics of malware analysis. The training is geared towards those who have never done, or performed very little, malware analysis. Plus, if you take the 2-day course, you'll get into my new 1-day Malicious Document course for free!

The Malicious Document training course I am doing for the first time this year will cover how to analyze malicious documents (duh). Specifically, I will cover malicious JavaScript, PDFs and touch on malicious Word documents. This is a 1 day course where the students will be very hands-on - analyzing malicious documents from the wild.

If you have any questions on the courses, please feel free to contact me!

Proactive Incident Response

A little while ago Harlan Carvey posted on Proactive Incident Response. I've been thinking about this for a while, but have a different perspective on Proactive IR than he does. (I agree with his take on it, I just look at Proactive IR differently.)

Computer Incident Response Teams (CIRTs) are often referred to as fire fighters. This analogy is very true - most of the time CIRTs are fighting fires; the fire being a hacked server, a malware outbreak or a targeted phishing campaign. We're often jumping from one problem to the next, determining who got in, how they did it, what damage they caused and how to prevent it in the future. However, is that all CIRTs should be doing?

The CERT Handbook for Computer Incident Response Teams states that CIRTs should offer three different services: reactive, proactive and security quality management services. Reactive services are the fire fighting done on a daily basis. Security quality management services include project and security consulting for other business units; you know, those meetings you get pulled into where they ask you what you think. What about proactive services?

If we look back at actual fire fighters, we see that they don't just spend their time putting out fires. One of their duties is to help fire prevention through education and fire inspections. In the security world, this is analogous to doing user education, vulnerability scanning and penetration tests. This is what proactive services are. But I believe these is another aspect of proactive services that CIRTs tend to miss.

One of my co-workers has coined a term: hunting trips. This basically boils down to proactively looking around the interwebs for attackers you've seen in the past. Since attackers tend to use the same, or similar tools and tactics, indicators of their compromises in other organizations appear if you know where to look. You can then use the new indicators you've just found to check for signs of compromise in your network.

Where can you look? Anywhere that information on security analysis can be found. This includes blogs, twitter, forums, online sandboxes, AV signature descriptions, etc. All of these places (and more) have information you can use to tie attackers to new attacks and malware they are using.

Of course, I wouldn't recommend hand-searching each of these places for information. Google is the obvious place to start, but be prepared to get back hundreds of results (at best) that are not of interest to you. I would recommend using the Google Malware Analysis Search, created by those behind the Hooked on Mnemonics Worked for Me blog, that narrows Google's search to 75 different security sites and feeds.

So, an example so this might actually make sense. In the last few days there has been an uptick in spammed emails that contain a link to a zip file named order.zip. Within this file is a SpyEye trojan. Analysis of the trojan shows that it drops itself as c:\recycle.bin\recycle.bin.exe (which to my knowledge is not a default location for SpyEye). This location is fairly unusual and can be a good indicator to use on a hunting trip.

Using the Google Malware Analysis custom search to look for "recycle.bin.exe", we come across a ThreatExpert report from March 2011 for the same filename being dropped for a SpyEye trojan. The TE report also shows that it attempts to contact zweor.com for its C&C server. We now have a new indicator to search our network for and to go hunting with.

This is a very simple scenario, but demonstrates the usefulness of performing information gathering to find additional indicators. I have a feeling most CIRTs are not doing this and would benefit greatly from setting aside time to make sure this is done.

Wanna be a mule?

Its been a while since I've posted and I apologize. As things get busy I find I have less time to post on there. However, one of my new year's goals is to post more so there should be more in the coming weeks.

I received an email today from my mother who received an email for a job and wanted to know if its legit. After skimming it my alarms went off and were soon verified. To be honest, I've always heard about money mule job requests but have never seen one so I found it interesting.

I'm currently trying to get mail headers to see where it actually came from. It is nice to know they offer insurance and a 401K. :)

From: "Ella D Dickinson"
Subject: RE: [1] Message from Careerbuilder: You have received a new job opportunity
Date: Wed, 19 Jan 2011 23:49:34 -0000

Hello,

Please allow me to introduce myself: my name is Ella D. Dickinson and I am the International Human Resource Manager of Medline Financial Industries PLC I am pleased to inform you that we have an open position for you within our company.

Medline Financial Industries PLC was founded in 1980 and has quickly grown to be one of the largest resellers of medical equipment and apparatus in the United Kingdom as well as in the rest of Europe. We work exclusively with hospitals and other medical companies and groups supplying several hundred types of products ranging from surgical needles and syringes to EKG and MRI machines and everything in between. We have dozens of agreements and contracts with top manufacturers around the world such as GE Healthcare, Medtronic, Baxter International, Cardinal Health, Tyco Healthcare, Siemens Medical Solutions, Philips Medical Systems, Zimmer Holdings, et cetera. Our company has grown very fast during the last few years so now we have expanded our market and business to the United States as well. As such we have a big number of openings in almost every state and we are looking for dedicated and hard working individuals to work for us and help us expand.

The reason for our success is the fact that we are able to meet our customer's demands wherever and whenever. We are very flexible and we can honor our orders when others cannot. This is due to the fact that we accept almost any type of payments and we have a very fast delivery system which combined with the great customer support we provide took us to where we are today. We take great pride in what we do because it is not always easy to satisfy all customer demands while still processing the orders very fast and receiving payments for the products in a timely manner. This is why we need you and bellow you will find the job description and what is asked of you.

Description:

-NO SALES INVOLVED
-While performing this job you will encounter no fees to be paid in advance whatsoever;
-No employee from our company will ever ask you for any sensitive information;
-You will not be involved in any contact with our customers;
-Everything you will do is legal under the European Union/United States and International laws as they are currently applied.

Your duties are:

1. Receive payment from our customers. All check will be write in your name. All checks are US checks, no international. You wil receive all checks via USPS (no signature required).
2. Cashing the checks at your existing bank account.
3. Deduct 10% which will be your percentage/pay on each payment processed.
4. Forward balance after deduction of percentage/pay to any of the offices you will be contacted to send payment to. (Payment is to be forwarded by Western Union Money Transfer).

Your benefits are:

-10% from each check your will process in the first month. Within one month after receiving the first check you will receive $1,000 as fixed salary. This is a commission based job, the faster your process orders the more your income will increase. This bonus is given to also cover internet, phone or gas bills. Please note that this salary will be sent after 30 days have passed since you received your first payment to process.

After two months of working for us an increase to 15% commission from all payments might be applied to your contract if you process and send all the transfers to us in a timely manner. In this case you will be earning around $1,200-1,300 per week as well as the $1,000 salary at the end of the month.

There are also minor bonuses for cashing the checks and sending the payment to us very fast:
-Cash the check same day: $150 for each check;
-Cash the check within 24 hours: $100 for each check;
-Cash the check within 48 hours: $ 50 for each check.

The $1,000 salary will be sent to you in form of a cashier check.

The today's situation on the financial market requires us to open and fill several of these job positions within our company; the job opening is that of a Representative within the US. This opening will help our company to reduce the time it takes to receive funding from orders that we receive each month. And we offer you one of the highest incomes on the market today and the minimal expenditures of time.

Presently with the number of orders we have we cannot put them on hold for fear of losing our customers, secondly we cannot cash these payments from the US soon enough, as international checks take about 28 working days to cash anywhere in Europe. We lose a lot of time and money each month because we have money transfer delays. Our clients could pay us where we want by sending checks to an US address. What we need you to do is to provide us an address where you can receive our customer checks. We need someone who can receive the money through this method of payment. Regarding the check process all you have to do is to receive the checks our customers will send to your address, take them to your bank, cash them and send the remainder amount to us after deducting all fees incurred and your commission. All fees for transferring the funds will be supported from our share. Bonuses will apply for cashing checks within 24 hours upon receiving a check. You will always take your commission upfront.

We make direct contact for sales of products. Once orders are received and processed we deliver the product to our customer (usually through USPS). The customer receives and checks the product and proceeds to send the payment. We accept all forms of payment but most of our customers pay using Bank Checks and so to solve this problem and not lose any of our customers we have decided to open this new job position. This job is legal according to the U.S. legislation as it is today. Local money transfers take but a few hours, so it will give us a possibility to get customer's payment almost immediately.

PAYMENT AND SALARY:

For example you receive a check as payment for 3000.00 USD, you deduct your commission (10%): 300.00 USD and then send to us the balance: 2700.00 USD. In the first month you will receive around 15-20 orders under 3,000.00 USD to process and after checking your performance records during that first month the orders you will receive, may increase from 3,000.00 upwards to 6,000.00 USD. For example 20 transactions each around 3000.00 USD gives you a total income of 6,000.00 USD per month and after establishing a close co-operation with us you'll be able to operate with larger orders and you'll be able to earn more. You will also deduct fees that are related to this job (gasoline, western union fees, bank commissions, etc) from our balance, not from your commissions. At first the checks you will receive will vary from: $500.00 to $3,000.00. We will also send you a 1099 Form for tax deduction on
your part. Our payments will be issued out in your name and you can have them cashed in your existing bank account, we don't accept newly created bank accounts because it slows the cashing process. Deduct your percentage and forward the balance to the company attorney manager via a western union money transfer, the name will be given to you later after cashing a payment.

This job takes only 3-7 hours per week. You'll have a lot of free time for taking up another job; you'll get good income and a regular job. This job is very challenging and you should understand it. We are looking only for the employee who satisfies our requirements and will be an earnest assistant.

We have health insurance and the 401K retirement savings plan as well as all the other standard benefits that a major company usually provides. Unfortunately we can only start talking about this after the first month has passed since you're working for us. We consider the first month as a trial period. In any case you do not have to pay for anything in advance; there are no hidden costs for performing this job. Any fee you might encounter will be deducted from our share of the funds before you send it to us.

You will receive next instructions step by step.

Unfortunately we cannot setup any interviews now, as we do not have any representatives in US. We will be able to come to meet within the next few months when the new offices will be opened in your area!

Please let me know if you are still interested. Within 24 hours after we will receive this information we will forward you a copy of the contract you have to fill in, sign and e-mail back to us.

Ella D. Dickinson
Medline Financial Industries PLC
Euston Road, London, NW1
United Kingdom
FAX 011-44-132-656-8743