All posts by Jacob Soo

[ Technical Tear Down : DIgiCOuppOan (PUP/Adware) ]

Recently while i was trying to troubleshoot my relative’s home network.
I happened to notice that their Chrome browser is infected with a PUP/Adware.

PUP stands for Potentially Unwanted Programs. The one that i’ve come across is DIgiCOuppOan.
I suspect that machine was infected when one of them went to some p0rn sites.

DIgiCOuppOan is classified as a potentially unwanted adware. DIgiCOuppOan claims to enhance your web browsing experiences and save your time and money by providing discounts and other bonuses and deals. DIgiCOuppOan program is compatible with the majority of the top retailers online.

DIgiCOuppOan program will display their ads with a pop up box which contains various ads according to yous queries when you browsing online. Currently DIgiCOuppOan adware program displays at least four basic types of advertising including sponsored links, coupons, video related ads and banner ads, “pop-unders” or interstitial ads.

Instead of writing what is it about. I’ll be doing my own technical tear-down of this PUP/Adware.
I’ve attached the link to the file here for anyone interested to try analysing it themselves.bkkdkcifjmepenkhibomliiocmpiejlj
The password to the attachment is “infected29A

[ Sample used in the analysis ]
MD5: c33dc4f0d10e233f6428ba8f35d5d16b
SHA1: 87fc5db935b95d0d3b84535bbffc36a8b8f1ba52

[ How it starts ]
Since it’s an Chrome Extension Adware, let’s check the permissions of this Adware and further dissect it.
Let’s try to understand how Chrome Extension works.
Chrome’s Extension will always require a manifest file, a background.html and possibly some JavaScript files as documented by Google here.

The manifest file, called manifest.json, gives information about the extension, such as the most important files and the capabilities that the extension might use.
For this particular Adware, we can see what sort of permissions did manifest.json request for below.

From the above manifest.json and the documentation from here.
We can see that it will inject content.js at the end of all webpages visited by user(s).
Once this Chrome extension started, it will start “background.html”.

From the “permissions”, we can also see the permissions that it require.
For a better understanding of the permissions and what each individual permission mean, the following will be a good reference.
https://developer.chrome.com/extensions/declare_permissions

[ Dissecting Background.html ]
Let’s take a look at “background.html” and we can see that once it’s loaded, it will start 2 other JavaScripts, “L7Y9.js” & “lsdb.js”
DIgiCOuppOan.01

[ Dissecting L7Y9.js ]
Let’s take a look at L7Y9.js and we can see that there is a decode function.
Even though on first glance, the string looks like it’s base64 encoded but in reality it is not.

Now let’s write a decode function without running the actual script. Below is a simple decoding script.

After decoding had been done. The decoded message or URL(s) in this case are

From first glance, it’s probably those links that will be injected into the webpages that the user(s) visits.
It is persistently writing data to the Local Storage as we saw that it requested “Storage” permission in the manifest.json file.

[ Conclusion ]
While this is not one of the state of the art Chrome Extension Malware, but it’s probably one of the many PUP/Adware out there.

I hope that this is fairly simple to understand technical tear down that people can repeat the steps on their own and learn how to analyse Chrome Extension PUP/Adware or even Chrome Extension malware on their own.

Happy Reversing,
Jacob Soo

[ Technical Tear Down : First Android Tor Trojan ]

This is probably the 1st Tor Android Trojan which Kaspersky was the first to report on this. I was lucky to be able to grab a sample of this off Mila’s website. But i’ll be doing my own technical tear-down of this malware.

[ Sample used in the analysis ]
MD5: 58fed8b5b549be7ecbfbc6c63b84a728
SHA1: 2e6dbfa85186af23a598694d2667207a254f8979

[ How it starts ]
Since it’s an Android malware, let’s check the permissions of this malware and further dissect it. Now, use apktool and run the following command:

You should see something like this after running the above command.

Now let’s take a look at the AndroidManifest.xml file, you should see the following and the permissions requested by the APK file.

From the extracted AndroidManifest file, we can see that it requires the following permission(s) and it’s starting in the Main class as indicated in the AndroidManifest file.

Hmmm, why does it require BIND_DEVICE_ADMIN?
The Device Administration API provides device administration features at the system level. These APIs allow you to create security-aware applications that are useful in enterprise settings.

Looking through the folder hierarchy structure on the image below, we also found some other files of interest which we will go through them later.
Tor.Android.Trojan.02

But let’s take a look at com.baseapp.Main first, manually converting the initial Dalvik code back to pseudo Java code.
We will get back something like the one shown below. Looking through the codes, we can see that it’s starting another class, MainServiceStart.

After a quick analysis of MainServiceStart, i’ve realised that it’s basically a module used to start Tor
Further checks revealed that the Tor module could be a variation of Orbot or using Orbot itself.
Why would it do that? Probably trying to make use of Tor to do data exfiltration. So i decided to do a quick grep and one of the more interesting things that i’ve found is this “Onion URL, yuwurw46taaep6ip[.]onion” in the constants & TorSender class. As of now, “yuwurw46taaep6ip[.]onion” seems to cease to exist.

[ What are the data that malware exfiltrates ]
So the question is “Is this malware exfiltrating any data? If it is, what is it exfiltrating.
So i was taking a look at all the Tor related classes, the one that caught my eye is “TorSender” class
Taking a deeper look at TorSender class, i’ve discovered several interesting findings as shown in the image below.
Tor.Trojan.01

From the above image, we can see that it is sending telephone data such as telephone number, country, IMEI, model & OS version to the C&C.
Looking at the rest of TorSender class, we also found out that it got the following functions :

  • sendInterceptedIncomingSMS – start/stop intercepting incoming SMSs
  • sendUSSDData – perform a USSD request
  • sendInstalledApps – send the C&C a list of apps installed on the mobile device
  • sendInterceptedIncomingSMS & sendListenedIncomingSMS & sendListenedOutgoingSMS- send an SMS to a number specified in a command
  • Another interesting finding came from “SMSProcessor” class.
    Looking at the snippet taken from “SMSProcessor” class, we can find the communication service and that it is intercepting sms to check for commands from C&C.

    While checking at the “TorService” class, there is an interesting function call, installFromRaw from the “TorBinaryInstaller” class.
    Within this function, we found out that it is copying a different iptables binary depending whether the infected device is ARMv6 as we can see from the code snippet below. Remember earlier when i’ve mentioned that there are some interesting binaries found while inspecting the folder hierarchy structure. These are the binaries that i’ve found.

    It also copy obfsproxy & privoxy binaries to the infected device. All these are used for Tor to work on the infected devices.

    Another interesting finding that i have is that the author of this Android Tor Trojan disguises the Tor binary and the MaxMind GeoIP database as .mp3 files.
    Probably just to avoid suspicion that why there are some files without extensions.

    [ Conclusion ]
    While this is not one of the state of the art Android Trojan, but it’s probably one of the first Android Trojan using Tor and a .onion url as C&C.

    I hope that this is fairly simple to understand technical tear down that people can repeat the steps on their own and learn how to analyse Android Malware.

    Happy Reversing,
    Jacob Soo

    ApiMapSet Hooking (short guide)

    ApiMapSet is already explained at this link : http://xchg.info/wiki/index.php?title=ApiMapSet  http://www.vxsecurity.sg/2012/02/14/apimapset-deroko-of-arteam/, but I didn’t mention that it can be used to perform hooking of certain APIs. In this example I’ve decided to take easiest one of them (only 4 exports) and to perform hooking of another process using this novel technique. Dll which I’ll fake is called : “API-MS-Win-Core-Debug-L1-1-0.dll” which exports:

    What we need to perform hooking is to create dll which exports these APIs, and to place it under “c:\windows\system32\”. In my case I’ll call it “fakedll.dll”.

    Procedure is very simple:

    1. copy fakedll.dll to system32 folder
    2. find in “ApiMapSet” entry which describes where “API-MS-Win-Core-Debug-L1-1-0.dll” is pointing (in my case it’s “kernelbase.dll”)
    3. find “not used part of ApiMapSet” section. I search on 16 byte boundary for 16 zeros, and this can be safely assumed to be unused space
    4. put there name of your fakedll.dll, and update “PREAL_ENTRY” so “NameOffset” and “Length” match name of this new dll
    5. Create new process with “CREATE_SUSPENDED” flag, and overwrite mapped “ApiMapSet” with the one you have modified
    6. Resume Process, and if everything went find you should see something like this in “DbgView”:

    Lets trace it:

    Isn’t this kewl?

    Now imagine, that somebody places such dll in “system32 folder”, and modifies “apisetschema.dll”, isn’t this good way of hooking whole system with dll injections? Who says that your dll has to hook APIs. Think about it, but I suppose that MS will change this very often, so it just becomes nice POC, or good reversing tool for dll hijacking.

    I have to note that this technique should work on Windows 7, and Window 8 as both should be using “ApiMapSet”. Sample source code has been tested only on Windows 7 SP1 with latest updates as of 02-11-2011. It might happen that code will not work on different Windows 7 if above mentioned api-ms dll has changed. I haven’t checked.

    deroko of ARTeam

    “Source code” : http://deroko.phearless.org/apimapsethook.zip

    ApiMapSet – deroko of ARTeam

    === Story in general ===

    When windows 7 came out first time, most of us were surprised to see kernelbase.dll and all weird imports in system executables and system dlls with names as :

    Most of us figured that those are used to redirect imports to kernelbase.dll, but funny thing is that no body really went into details of investigating it. Yes, we all figured that this is thunking or redirection to different dlls but no body went in details how it’s done. This is to me somehow strange, as I’m quite sure that 3-4 years ago many top reversers would be on this. Not because it’s security risk, or has something unique, but for sake of challenge of investigating something undocumented. This has been on my todo list for a while, and I’m really surprised that no body actually took this as a challenge, just for fun.

    Here we go with all details of implementation.

    === Where is API-MS* compare? ===

    First of all, in PEB there is field called PEB.ApiMapSet which is located at offset 0x38 from PEB, which points to some data (we will come to this later).
    Second, function which identifies dlls, and makes all these redirections is called _ApiSetResolveToHost. One of the arguments that is being passed in is PEB.ApiMapSet:

    Function checks if the first 4 characters are “API-“, and if so will proceed with identifying dll that should be redirected, otherwise, nothing happens and function simply exits. So we continue our quest:

    Function, simply skips 8 bytes of original string, as those are unicode “API-“ and UNICODE_STRING cares only about length in bytes, also function checks if there is “.” at the end of dll name to strip it, as ApiMapSet doesn’t contained “.dll” extension in names.

    Before I start explaining how everything is organized, and how dll name is found, I will show you binary representation of this data, so we can reference to it, and explain how everything is done. Dump is intentionally set to be with base 0x00000000 so it’s easier to follow, as all offsets inside of this binary data are relative to start of PEB.ApiMapSet.

    Now starts code which is dealing with searching and mapping dll names:

    At offset “[ecx+4]” or “PEB.ApiMapSet” is stored number of structures which is located at “0x00000004” and is set to be “0x23” or “35” decimal. Code checks immediately if number of structs is 0, if so, code exits with error. Also at offset “0x00000000” there is number “2” for which I assume is version of ApiMapSet, as I haven’t found that it’s used, I can only assume that this is version of structures so in the future code can be changed for future needs, and still keep backward compatibility. Yup, you have to like Microsoft because of backward compatibility, which is probably one of the things that make windows great operating system.

    From this code we can figure that struct which follows first 8 bytes of PEB.ApiMapSet are 0xC bytes wide. We can see also layout of these structures:

    So we examine 1st structure at offset 0x00000008

    0x00000008” tells us that dll name is located at “0x000001AC”
    “0x0000000C” tells us that dll name is 0x34 bytes long

    this sounds correct? Now that we have found our matched dll, we can go and extract real dll name:

    3rd DWORD bring us to more structures which point to name of a real dll to which redirection is applied. In our case that would be offset at “0x00000010” and relative offset “0x1E0”:

    We can document now first structure found at the beginning:

    Everytime 2nd stage structure is found, code checks how many of them are there. So far I haven’t seen more then 1, but only future knows what will MS introduce, also code is aware of this posibility. If there is only one structure code is straight forward:

    Now look at “0x000001E0” and you will see how code works. It skips “dwCount” at “77F252C6”, and gets from offset +8 relative offset to real dll name, and from offset +0x0C it gets length in bytes of dll name. If we follow this code we see that these values are:

    “000001EC” = “0x000001F4”
    “000001F0” = “0x00000018”

    And at offset 0x000001F4 we can clearly see name “kernel32.dll” which is returned back after redirection is properly applied.

    And we can document 2nd set of structures as :

    You might be wondering about NameOffsetRealName and LengthRealName. Well those are used only when dwCount > 2, and these names are used to compare dll which is loaded, and name which is compared comes from “LDR_DATA_TABLE_ENTRY” of currently loaded dll. Code snippet:

    Now we are in the code of function we previously looked at:

    and inside of this function, pretty much same search is performed as you have seen earlier seen with RtlCompareUnicodeString except offsets ”’+0”’ and ”’+4”’ are used to get name offset and Length. And they are compared with DllBaseName passed to this function. Maybe this is only prepared for future version of windows. Lets see how they will use it in the future.

    === Where is PEB.ApiMapSet set? ===

    If you have ever traced initialization of process you know where to start, and that’s “LdrInitializeThunk” as every created thread starts from there. And nowhere else! I’ve started my quest, and eventually after a while figured that this stuff definitely is not set in ntdll.dll, to verify this I wrote simple C program:

    Woops, running this program gave me some address :

    So second guess is that’s is either mapped by “NtCreateProcess/NtCreateProcessEx” or windows added extra shared user data memory. Logically, we need to check PEB creation from ntoskrnl.exe, and as always look for “MmCreatePeb” as that’s place where PEB is created for a new process, so any change to PEB will happen in this function, or after it. “MmCreatePeb” was no go, as obviously offset “0x38” wasn’t referenced from it, but after a little bit of looking after call to “MmCreatePeb” I found interesting name “_PspMapApiSetView@4” (heh next time just search symbols for whatever you are looking, much easier, right?), and critical code:

    That’s where PEB.ApiMapSet is initialized, so it comes from kernel. Full function:

    Note also 3 variables : “_PspApiSetMap”“_PspApiSetSize”, and “_PspApiSetOffset”. Follow references to them and you endup at : “PspInitializeApiSetMap()”.

    This functions is kinda long, but very simple:
    1. It opens file :

    2. Creates section, gets object of section, and maps it to system memory, and section object stays there forever:

    3. Goes through pe header until it finds section named “.apiset”

    And sets global vars to VirtualAddress and VirtualSize of a section:

    Now to make sure that we understood everything, open “C:\windows\system32\ApiSetSchema.dll”, look into section “.apiset” and you will see that it’s identical to stuff you see if you view “PEB.ApiMapSet”. Quest done.

    === Ending ===

    I have no idea why did MS introduce this. Only reason to me is that somebody at Microsoft was bored, and somehow managed to make huge mess. Maybe they want to keep this so in the future, they can separate various parts of kernel32.dll or other dlls to differently named dlls, and “apisetschema.dll” is the one to fix this mess. Probably code for kernel32.dll and other dlls which survived this thunking became huge, so for easier maintance split it into more new dlls, and keep backward compatibility through ApiMapSet rules.

    === Greetings ===

    I wish to say thank you to all my mates from ARTeam for being kewl guys and always sharing knowledge, to friendly people at woodmann.cjb.net for nice discussions, unpack.cn guys, and of course ex-29a virus writing group for sharing their knowledge.

    === Author ===
    deroko of ARTeam
    === Source Code ===

    “defs.h”

    “main.c”