Category Archives: Malware

[ Sharing ] More ITW Exploitation of Internet Explorer ‘Unicorn bug’ found

These few days i have seen friends asking me whether i have seen any sites during work using CVE-2014-6332.
Sad to say, i can’t talk about work. So today i will talk about what i’ve seen during my free personal time.

[ How it starts ]
So what is this vulnerability known as CVE-2014-6332?
This is an interesting bug as it exploits Internet Explorer versions 3 through 11. This means that most if not all of Internet Explorer users are vulnerable unless they are using patched systems. It was first disclosed publicly by @yuange75 here back in 01st August 2014 :
However he found it long long ago.

I guess it’s only a matter of time that “malware writers” start using this knowledge and use it as part of their cybercrime. I’m not from any AV companies nor ThreatIntel team selling “APT” news, but i do want more people to know that there are now several compromised website(s) that are using this CVE-2014-6332 vulnerability to install malware on the computers of its unsuspecting visitors.

[ Compromised Website details ]
The very first one that i found is from www[.]uyghurweb[.]net
The page source contains 2 interesting thing that caught my “eyes”.

The 1st one is “http://122[.]10[.]91[.]20/2013/frame.js” but it’s down when i tried to grab it.
The other being the other JavaScript(s) in the page.

The one that is more interesting is “js/udg.js” as it’s actually redirecting visitors to another website serving “CVE-2014-6332

As you can see, the exploit is hosted on the domain “http://www[.]owner[.]com[.]tw
If you have seen the source of “new.htm” as shown below.
It looks almost identical to the one shared by @yuange75. I suppose this malware writer is quite lazy to change anything to it.

I actually found a total of 7 but some are sensitive to be shared. One of it was disclosed by ESET here:
The other 3 non-sensitive sites that i’ve found are from:

But interestingly for these 3, all are showing “Hacked by LulzSec” and the following is found in the page source.

My guess is the first one is probably not related to the other 3. But one thing is for sure, there are more of these websites serving “CVE-2014-6332” as we speak.
I’ll probably blog about the payload later.

[ Conclusion ]
Although i do not have the mass amount of data as AV companies or ThreatIntel companies to offer IOC (Indicators of Compromise), but i guess if i can find a few website(s) within a week. I suppose it’s is just a matter of time before ExploitKit(s) integrate this vulnerability to their existing toolkit. Since most of the Internet Explorer versions were affected, I guess user(s) of Internet Explorer should just update IE NOW!!!!!.

Happy Reversing
Jacob Soo

[ Technical Teardown: HongKong Protest Malware ]

[ How it starts ]
It all started when we saw Tsui Lokman mentioned about an executable that they received and it could be a malware.
This particular piece of malware could potentially be used to target Hongkongers participating in #OccupyCentral & #UmbrellaMovement .
Being the curious cat(s), we started asking for a copy of it to analyse it.

[ Sample used in the analysis ]

[ Updates ] Since @vietwow requested for a copy of the sample.
We have attached it here like always.
Letter To Hong Kong 20141011_pdf_viewer. The pw to the zip is “infected29A
[ Tool Used ]


[ Analysis of Dropper ]
1) The executable is being camouflaged as an adobe executable (pdf viewer) by using an adobe icon as shown here.
Image 1 : Screenshot of Dropper

A Microsoft Excel Icon is also found in the executable as well (using resource hacker tool). However the icon is not used at all. Probably there is another version of the dropper that disguise itself as a Excel document.

resource hacker Image 2 : Extra icon using ResHacker

2) Upon execution of the dropper, the malware copied itself to C:\Documents and Settings\Administrator\Application Data\WMService.exe. The path that the malware copied to varies depending on the operating system versions. For Win XP, the path would be [drive]:\Documents and Settings\[User Name]\Application Data\WMService.exe] while for vista and above the path would be [drive]:\Users\[User Name]\AppData\Roaming\WMService.exe.

envImage 3 : Screenshot of Dropped location

The first function of interest when running the malware is the decryption of the encrypted strings in the program. @address 00403E9A we can see that there is a function call to address 00401F70.


 Image 4 : List of Encoded Strings

From the above assembly codes, we can see several encrypted strings. Note that there are several calls to function 00401AAE. This function is called to decrypt the encrypted strings. Instead of going through the decryption routine… my approach is to use ollydbg to help me to decrypt the strings in runtime as shown below.


 Image 5 : List of Decoded Strings

now we can make a better educated guess on what the malware is doing with the decrypted string. Previously IDA Pro strings did not really churn out any useful strings for us but with the decrypted strings we can see the evil server domain name.

Moving on we can see that after the decryption routine, an argument -st is supplied to the executable.
On analyzing the dropper via IDA Pro, the dropper has 2 distinct paths.
1 of the paths (Path A) is taken when an -st argument is not supplied when executing the dropper while the other path (Path B) is taken when -st argument is supplied to the binary.
Path A is taken when the dropper is first executed by the user in which no arguments is passed in to the process. Path B is taken when the system boots up and execute the dropper via registry’s run in which an argument is provided to the process.


Image 6 : 2 Paths of Malware

[ Analysis of Path A ]

At address 00403FAF we can see that a function @00403B55 is being called. This function forms the cmd.exe’s command and execute it as shown below.


Image 7 : Command Line to add Registry Entry

A registry entry is added via  reg add hkcu\software\microsoft\windows\currentversion\run /v hotkey /t reg_sz /d “C:\Documents and Settings\Administrator\Application Data\WMService.exe -st”

After execution, the dropper “deletes” itself by moving itself to C:\Documents and Settings\Administrator\Application Data\WMService.exe via c:\windows\system32\cmd.exe.


Image 8 : Command Line to “Move” Malware to another location

[ Analysis of Path B ]

The first thing that Path B does was to create a Mutex object with the name “c8aabdc4” using CreateMutex function. In the event that the mutex already exists, the program will terminate.


 Image 9 : Creation of MutexName

The mutex is used to prevent 2 of such process running at the same time. The malware then continues to call function at address 0040264A where it gets the computer name and internal IP address of the computer.

Next GetTempPathA is called to form the path C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\s.bin which is used as the destination file path of the actual payload.

The function at address 00403D60 takes in the domain name and resolve it to an IP address –


 Image 10 : Possibly C&C of Malware

Function 00402350 is called to form the Get Request to the C&C server. In the function we can see that computer name and internal IP address as shown below.


 Image 11 : Data that are sent back to C&C

The appended information gotten from the victim  are encoded and appended to the URL.

URLDownloadToFileA is then called to upload user info and download the payload from the url below:

to C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\s.bin

However at the time of analyzing the sample, the server was already down…


 Image 12 : Download URL of another payload

should the actual payload (s.bin) exists we would expect that the first byte of the downloaded payload is the type of command to execute as shown in the switch statement below. The function responsible for reading the commands from the downloaded payload is at address 00402553.


 Image 13 : List of Commands for Malware

Based on the above switch statements, we can observe that the payload downloaded is in fact commands to be executed on the machine. We do not really need to download and analyze the payload to know what it is doing. The functions that the malware can perform are reading files, upload file to server, executing commands, delete file, find file and retrieving logical drive info.

Once the command to the malware is executed, the instruction file, s.bin, is deleted.

As we can see in the image below, the malware would call back to its server every hourly and retrieve new commands to execute.


 Image 14 : Hourly Sleep

[ Dropping of Persistent Backdoor ]
Earlier on, we have mentioned that the malware added an entry to the registry. This registry key is added for persistence.
Location: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Name: Hotkey
Value: C:\Documents and Settings\Administrator\Application Data\WMService.exe -st

You may find a screen shot of this at [ Analysis of Path A ] section

[ Anti Analysis Features ]
The author of this malware implemented time delay in the program possibly for the purpose of evading anti virus detection. It is known that anti virus executes program to detect for malicious codes however it would only execute the program for a short period of time. A time delay approach could potentially evades such scanning.

Using breakpoint in OllyDbg, we observed that IsDebuggerPresent is used to detect if a debugger is attached to the dropper. However there is no difference in the core operations even if the dropper detects that a debugger is present.

[ Whois Investigation ]
A quick Whois query using CentralOps revealed that the domain name ( is also pointing to the IP address ( which
we have had also found it earlier in the binary. As is a “Free Dynamic DNS” service offered by, the infiltrator can change the IP address easily without affecting the callback.

However the server is currently inactive. (Information correct as of 22/10/2014)

[ Domain Whois record ]

Queried with “”…

Domain Name:MYZ.INFO
Domain ID: D1182102-LRMS
Creation Date: 2001-10-26T05:20:59Z
Updated Date: 2012-07-12T14:25:25Z
Registry Expiry Date: 2017-10-26T05:20:59Z
Sponsoring Registrar:Network Solutions, LLC (R122-LRMS)
Sponsoring Registrar IANA ID: 2
WHOIS Server:
Referral URL:
Domain Status: clientTransferProhibited
Registrant ID:52605919-NSI
Registrant Name:ChangeIP Network OperationsZZZ
Registrant Organization:
Registrant Street: 1200 Brickell Avenue
Registrant Street: Suite 1950
Registrant City:Miami
Registrant State/Province:FL
Registrant Postal Code:33131
Registrant Country:US
Registrant Phone:+1.8007913367
Registrant Phone Ext:
Registrant Fax: +1.7862246593
Registrant Fax Ext:
Admin ID:52605919-NSI
Admin Name:ChangeIP Network OperationsZZZ
Admin Organization:
Admin Street: 1200 Brickell Avenue
Admin Street: Suite 1950
Admin City:Miami
Admin State/Province:FL
Admin Postal Code:33131
Admin Country:US
Admin Phone:+1.8007913367
Admin Phone Ext:
Admin Fax: +1.7862246593
Admin Fax Ext:
Billing ID:C1256251-LRMS
Billing Street: 1200 Brickell Avenue
Billing Street: Suite 1950
Billing City:Miami
Billing State/Province:FL
Billing Postal Code:33131
Billing Country:US
Billing Phone:+1.8007913367
Billing Phone Ext:
Billing Fax:
Billing Fax Ext:
Tech ID:52605919-NSI
Tech Name:ChangeIP Network OperationsZZZ
Tech Organization:
Tech Street: 1200 Brickell Avenue
Tech Street: Suite 1950
Tech City:Miami
Tech State/Province:FL
Tech Postal Code:33131
Tech Country:US
Tech Phone:+1.8007913367
Tech Phone Ext:
Tech Fax: +1.7862246593
Tech Fax Ext:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:

inetnum: –

netname: NWTBB-HK
descr: NWT Broadband Service
country: HK
admin-c: NC315-AP
tech-c: KW315-AP
remarks: For network abuse email <>
changed: 20101208
source: APNIC

address: 17/F Chevalier Commercial Centre,8 Wang Hoi Road, Kowloon Bay,Hong Kong.
admin-c: KW315-AP
tech-c: IDC1-AP
tech-c: NC315-AP
auth: # Filtered
changed: 20101207
source: APNIC

person: Kwong Ming Wong
nic-hdl: KW315-AP
address: 17/F Chevalier Commercial Centre,8 Wang Hoi Road, Kowloon Bay,Hong Kong.
phone: +852-21300120
fax-no: + 852 – 2133 2175
country: HK
changed: 20060814
source: APNIC

person: Network Management Center
nic-hdl: NC315-AP
address: 17/F Chevalier Commercial Centre,
address: 8 Wang Hoi Road, Kowloon Bay,
address: Hong Kong.
phone: + 852 – 2130-0120
fax-no: + 852 – 2133 2175
country: HK
changed: 20080804
source: APNIC

% Information related to ‘’

descr: NWT Route Object
origin: AS17444
changed: 20110114
source: APNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (WHOIS4)


Signing Off
D O & J Soo

[ Technical Tear Down: Fake Code4HK Mobile App ]

Today i’m going to talk about the Fake Code4HK Android application which the news reported here, The Code4HK guys had already long identified this Android mawlare this ( before the rest of the world did. However I probably should stop writing about Android malware but this one seems interesting for me to write though. 😛

As the thing happened almost 2weeks ago and the international activists only saw it yesterday. I was lucky to be able to grab a sample of this off Matthew Rudy Jacobs’s github. But i’ll be doing my own technical tear-down of this malware and hope to cover this comprehensively

[ Sample used in the analysis ]
MD5: 15e5143e1c843b4836d7b6d5424fb4a5
SHA1: c1e9ebd0b5ac7b6c50c69af219d163393d52df99

[ How it starts ]
It was first distributed via WhatsApp as shown in the image below.
As we can see, it’s asking participants of #OccupyCentral to download this url shortened link,
However, if you were to “Expand” this shortened URL, you will see the final url is,
That link is not valid anymore and furthermore, that suspicious url does not belong to code4hk.
The official url for code4hk is

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:

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

There are interesting meta-data available to us like the following found in the cert.rsa file.

The email could be useful but there are no hits on google using that.
Another interesting but not confirmed “findings” i have is maerts spelled backwards is “stream so could ITSC mean CSTI? Council of Science and Technology Institute? I’m not sure but i’ll let everyone’s imagination run. 😀

But let’s take a look at com.v1.MainActivity first, manually converting the initial Dalvik code back to pseudo Java code.
After disassembling the .apk file with apktool and checking the Android manifest file, the first thing that i check is the MainActivity class.
We will get back something like the one shown below. Looking through the codes, we can see that it’s starting another class, StreamService.

From my initial analysis, we can identify several things.
1.) It will open “qq.xml” from the Assets directory.
2.) It will create a new directory, “/sdcard/.qq/
3.) It read the contents of “qq.xml” and create a file, “/sdcard/.qq/temp.apk

If we had analysed the Android Manifest properly, “StreamService” will be started after reboot.
And if we were to analysed “StreamService” really carefully, it’s actually making use of AndroRat. 😛
If you had never seen AndroRat before, you can find a copy of it here.
So basically, it’s getting lots of other stuff from the victims as well. o.0″

[ PhoneReceiver ]
Now let’s take a look at “PhoneReceiver” class and we can see that it will start recording all outgoing calls made by the victim(s).
o.0″ Sounds malicious to me.

If we were to check the following Android documentations,
setOutputFormat –
setAudioSource –
setAudioEncoder –
We know that the Output format is 3GPP media file format.
The source for the recording is using Microphone audio.
The encoding used is AMR (Narrowband) audio codec.

There are other interesting findings such as the naming convention of the filenames are
out_” appended with the outgoing phone number followed by “_” and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.

[ StreamReceiver ]
One interesting thing is within the “StreamReceiver” class, it tried to read “getAll.dat” in a try..catch block and if it didn’t find it, it will activate the “features” of AndroRat”.
It will also try to read the contents of config.dat under “/assets/config.dat
This file actually contain an IP address, “” & a number “1430” which we can safely assume that it’s the port number.

It also tried to use Baidu to gather location data of the victim(s) as shown below.
The API could be found here:

Besides the IP address which we have highlighted earlier on, there are some other interesting IP address and domain name which are found within “StreamReceiver” class as shown below.

One thing which most people may not know is that mm usually stands for “木马” or “妹妹” in China context.
I highly doubt it meant the latter. xDDD
木马” means trojan horse. 😛

It also creates of other interesting files storing all the information that it “steals” from the victim(s).
But i won’t go through each and everyone of them.

From the whois information, we can gather more information on as shown below:

From the whois information, we can gather more information on as shown below:

[ FixTimeRecordReceiver ]
Now let’s take a look at “FixTimeRecordReceiver” class, we can see that the purpose of this is to record the audio using the MIC.
While it looks almost the same as “PhoneReceiver” but the recording starts in a fixed interval as it was set in “StreamService“.

There are other interesting findings such as the naming convention of the filenames are
FIX_TIME_” appended with “yyyyMMddHHmmss” (Date time of the system) and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.

[ Conclusion ]
While this is not one of the state of the art Android Trojan, but it’s probably one of the interesting one that makes use of a known coding group in Hong Kong and spread through WhatsApp.
But there will always be questions, why are they being targeted, why send through WhatsApp and i think the number used could be those easily available “pre-paid” data sim card in Hong Kong.

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

[ Technical Tear Down: Fake WeChat Android App (Packed using Bangcle)]

[ Sample used in the analysis ]

MD5: 35C0A075CBC6135D957BD10769E3A620
SHA1: 554FD3D80B696F0677231A54F35B61B5774F2940

This is an Android malware found in the wild. You may be wondering what’s so special about this malware as there are thousands of Android malware out there. Well, this is one of the first few Android malware that has been packed. By being packed, it make reversing almost impossible for  static code analysis. As mentioned in my previous writeup, script from @timstrazz is available if bangcle is used to pack the apk.

As we at always encourages people to get their hands dirty, we have attached the malicious sample here.
The password is “infected29A

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.

Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.

Android Emulator is used for the dynamic analysis portion.

[ Before debangcling the app ]

As explained in my previous writeup, if Bangcle is used to pack an apk, when you try to reverse the file, you will notice a certain pattern like additional library files and new Java class files (ACall.class, ApplicationWrapper.class, FirstApplication.class). As shown in the picture below, this particular .apk when we decompile using dex2jar or disassembled using Profiler also contains similar files.


One thing my team and i found out is whenever we see this class (com.secapk.wrapper.ApplicationWrapper) and it’s be instantiated by default whenever the process is started.
We can safely deduce that it could have been packed using bangcle. So I tried using the script from @timstrazz found  here to unpack it.

Success!! It could be unpacked 🙂

[ Debangcled APK ]

The resultant of the debangcling process is a dex file which can now be reversed.


There are some obvious clues which flags out as a sorethumb to the analyst analysing the apk. Like the package name is called “com.example.banksteal“!! Who names their application banksteal anyway? And furthermore if your package name contains words like “example”, you can’t upload your apk into Google Playstore as it is deem as a generic name. So there are 2 things you can conclude even without analysing anything. 1st: This .apk is obviously from some third party market or circulated elsewhere other than the official Google Playstore. 2nd: This .apk is highly suspicious due to the naming conventions used. You can’t be 100% sure that this is a malware based on the above mentioned 2 pointers. So let’s delve in deeper.


The app requests for the following permissions:


Upon installing the app, you will get the following icon. This is the popular WeChat Android app, a Whatsapp like instant messaging app. The App is named as “Wēixìn” in Chinese which is the pinyin name for WeChat and means micro message.



When the app is invoked, it will first ask you for device admin permission for lock your phone, it can be seen from the code snippet below taken from the Launcher class.




and then for your credit card details as shown from the screenshot below when the app is executed on an emulator:


Next, more details will be asked like the type of bank from which the credit card was issued, card’s cvc number, expiry date, social security number, address etc



Let’s say, I chose the JCB card as my credit card and fill in all the details and click next:


I am running this in an emulator and it prompts that, “The email/message is not sent out!” I hope that my Chinese translation is accurate but then this raises another question of why a messaging app needs to send out an email. Let’s look into the source code for more evidence.

If you look at the BankData class, it summarises the data it harvests:



Under the Const class you will also get the email address of the receiver.



There are more clues in the MailUtil class where the host of the receiver is resolved.


In summary, this app requests for your credit card details and mail out these details.

Well ok, what’s wrong you may ask.

Just that in an actual WeChat app registration/installation no such details are required.

[Actual WeChat App]

Now let’s look at the actual WeChat app’s permissions when downloaded from the Google PlayStore.


You may think, this looks more malicious as it requests for much more permissions as compared to the previous app!!! But hold on.

Let’s take a look at the registration portion:



And that’s it. No credit card nor any bank details is required during installation nor registration of the official WeChat app.


The analysed application is an Android malware masquerading as the WeChat android application and request user for their credit card details. Supposedly to give the user a surprise at the end of the month!! On the other end the original app even though it requests for much more permissions, it does not cause financial loss for the user. This reiterates the point that users must not install app from unknown sources or third party markets. Most importantly, whichever app from third party or even the official Google Playstore requests for your credit card details, you are highly recommended to uninstall the app unless you feel generous 🙂

Another unique feature of this app is the usage of a packer. In this case, it is using Bangcle and we already have an unpacker available which helps in our analysis. What if a more complicated packer is used? It will further impede the analysis process. Then we have to only rely on dynamic analysis and if the apk is advanced enough to have anti-emulator techniques etc, how do we overcome this ? I will have another writeup on the possible dynamic analysis paradigm in the near future. If you have ideas, do share with us too.

David Billa (@billa316)

[ Android Packers: Bangcle ]

In this writeup, let’s take a look at Android packers in general before focusing on one of the more popular packer, Bangcle.

[An Introduction to Android Packers]

There are many useful reasons packers are used in software engineering, like for code obfuscation, compression, protecting your work against reverse engineers etc. The more sinister usage are for AV bypassing, masquerading malware and making the job of whitehat reverse engineers harder.

The common packers used for packaging EXEs are UPX Packer, RLPack, NSPack etc. As till recent times, the bulk of computer usage has been limited to PCs thus these were commonly used.

With the increase in usage of Android devices, different types of malicious Android applications were beginning to proliferate. In recent times, Android malware packaged using packers are beginning to surface in the wild.

A more detailed analysis on Android packers can be found here.  In the next section, I will be focusing on one of the increasingly popular Android packer which is being used for Android malware.

[Bangcle: Android Packer]


Bangcle is a mobile application security services provider company based in China. One of the services it offer is Android app protection as shown in the screenshot above.

A user just have to register and subsequently use the dashboard to upload your apk file and you will get the bangcled apk ready for use.


I tested with a simple Hello World application. Before bangcling this is how the app’s structure will look like.



After uploading the hello world apk to be bangcled the resultant apk will be as shown below:

hello-world-bangcledAfter the app has been bangcled you will have additional library files (, etc) and new Java class files (ACall.class, ApplicationWrapper.class, FirstApplication.class).

And the new bangcled application will also have additional permissions. Do take note that the actual hello world had no permissions initially.


The ACall.class file loads the additional libraries, FirstApplication.class file calls the super.onCreate function to initialize the activity and the ApplicationWrapper class subsequently loads the encrypted dex file which will be then be decrypted in the memory by the loaded libraries and finally executed. As it is being decrypted in memory, this makes static analysis of an Bangcled apk hard and tedious.

A more detailed writeup from Virus Bulletin can be found here.

[Reversing Bangcled APK]

In DEFCON 2014, TIM “DIFF” STRAZZERE (@timstrazz) presented and subsequently released the solution to debangcle a bangcled apk.

The full source can be found at his github acct here. Below is his shellscript portion.

To run his script (in a Linux environment), configure an Android enmulator (using AVD from the Android SDK) and install the bangcled apk in it using adb tools (adb install <bangcled-app.apk>).

Now execute his script after starting the app in the Android emulator. The dex will be decrypted in memory as discussed earlier. The script actually scans the memory in areas where an odex shouldn’t be to detect the magic bytes (“dey\n036”) for the optimized dex file and subsequently dumps out the specific memory portion as an dex file using baksmali. So the end product is an decrypted dex file which can now be analysed 🙂

[In Summary]

As the usage of Android increases, more variants and complex malwares are being now detected. As it was in PC malware ecosystem, packers are making inroads into Android now. Bangcle which is a China based Android packer created as a means to protect one’s apk is currently being misused for packing Android malwares making reversing hard.

However, bangcled apks can now be reversed for static analysis thanks to the great work by @timstrazz.

The next writeup will be on an technical teardown of a bangcled apk found in the wild recently.

David Billa (@billa316)


[ Technical Tear Down: UUPlay, ANDROID Malware ]

[ Sample used in the analysis ]
MD55: E7D6FEF2F1B23CF39A49771EB277E697
SHA1: F5735DC4D9502F99D3B62C49EF083B403D627124

We gotten this sample from Jacob’s old friend, “Amnesia”. UUPlay application portrays itself as an legitimate Google playstore application but it also doubles up as an malware in disguise, sending out victim(s)’ information from the device. You can check the VirusTotal detection rate here.

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.

Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.

Android Emulator and Burp Suite are used for the dynamic analysis portion.

[ Permissions ]

From the permissions list above, you can notice that it also haves the capability to download and install applications. Users may think that since it is a Google PlayStore app , it needs such permissions. But in this case, it also have the READ,WRITE and SEND SMS permissions. These permissions can be abused to send premium SMSes to premium numbers resulting in additional costs for the victim(s).

[ Source Code Analysis ]
The .apk is most probably obfuscated using ProGuard. From the screenshot below, one can notice that after reversing the .apk file, it seems bloated with multiple alphabetical java class files like any typical .apk file that is protected by ProGuard.


Thus it makes analyzing the source code harder. For more information on what ProGuard actually does, you can refer here.  In this analysis, dynamic analysis was primarily done to map out the behavior of the application.

[ Analysing Manifest File ]
From the manifest file, there are quite a lot of activities declared under the “” package.


For the list of Google Package names available for Android, you can refer to the list here. When checked against this list, it does not have any “” package. It is a clear sign that these might potentially be malicious activities running in the background masquerading as Google services.

Other than these activities, from the manifest file, it can also be deduced that a total of 3 services are running.


Two of the services are linked to the fake Google packages and the third service is supposedly a log service linked to the “com.uucun” package which is the main package name as noted from the manifest file.

Now let’s move on to the dynamic analysis portion.

[ Dynamic Analysis ]

Upon installing the uuplay.apk, the app’s icon does not appear under the device home or the application’s display. However, it can be found under the apps’ listings under Android system’s settings.

uuplay -appinfo

As you can notice, the icon is the same as the Google PlayStore’s icon.

The app can be started using Android Debug Bridge (adb) commands. From the manifest file, the main activity’s name can be deduced as RootActivity. The following command was used to invoke the main activity:

adb shell am start -n

After firing up the application, the UI is displayed as below.


Next, we used Burp Suite to monitor the network traffic. For instructions on configuring Android emulator to work with Burp Suite you can refer here.

Upon installing the app, information like imei number, sim card type, os version, date timestamp, app version and airpush version (mobile ads) were double url encoded and was posted to h–p:// as shown in the screenshot from Burp Suite below.

uuplay-burpsuite1Next it checks for updates for all the pre-installed apps from h–p://


If you search for any app, e.g Whatsapp, you can see that the searched information together with the phone information being posted out and subsequently the relevant apk file will be downloaded from h–p://

h–p:// is one of many un-official Android Marketplace from China.

While all these can be considered “fairly” normal behavior for an “Google PlayStore”, there are also other suspicious activities. Like at certain intervals (even when the app is not in use) encrypted data are being posted to urls like h–p://


The URL to which the data is posted is not hard-coded.  Meaning, sometimes the data are being posted to other URLs. But the key point is data (judging from the long list of permissions, it could be anything the app has access to) is being encrypted and were being ex-filtrated from the device.

[ Conclusion ]

In conclusion, uuplay is an application that masquerades as the official Google PlayStore application. It does similar activities like installing applications fetched mainly from the following urls:

– h–p://


At the same time, it also posts out personal information masked as log data to the following urls:




In short, install at your own risk!!

David Billa (@billa316)

[ Technical Tear Down: SIMPLELOCKER, ANDROID Ransomware ]

[ Sample used in the analysis ]
MD5: FD694CF5CA1DD4967AD6E8C67241114C
SHA1: 808DF267F38E095492EBD8AEB4B56671061B2F72

This is one of the latest Android ransomware that we got. It can be found in Mila’s website and you can take a look at the VirusTotal analysishere. The ransomware is TOR enabled and goes about encrypting files in the Android system and subsequently requesting for ransom before the key will be given to decrypt the files. Now let’s look at the technical details of the ransomware.
I’ve attached the link to the file here for anyone interested to try analysing it themselves.
The password to the attachment is “infected29A

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.
Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.
Android Emulator is used for the dynamic analysis portion.

[ Files ]
Below is the list of files after using Cebero Profiler to disassemble the apk file.


[ Manifest File ]

Below is the full manifest file extracted from the .apk file:


[ Permissions ]
Now let’s take a look at the AndroidManifest.xml file. When installing the application, the user is prompted with a list of permissions the application requires.


The permissions are more or less harmless in nature and doesn’t throw a redflag as in the case with other malwares. The permissions that could raise any kind of suspicion are android.permission.RECEIVED_BOOT_COMPLETED and android.permission.WAKE_LOCK. RECEIVED_BOOT_COMPLETED permission is required to allow an application to receive a broadcast that the system has finished booting up. WAKE_LOCK permission is required to keep the processor from sleeping or screen from dimming.
Both these permissions look harmless at first look but could be used to run an application upon bootup and keep it running without being pushed to suspended state by the Android operating system.

[ Source Code Analysis ]
From the manifest file, Main.class file is first launched upon starting of the app. The Main.class checks whether the MainService.class is running and if not calls it. MainService.class is linked to 5 other classes. MainService1.class, MainService2.class, MainService3.class, MainService4.class and MainService5.class. These classes are all interlinked.  What it does:

• Checks whether the TOR connection is established.
• If not try to establish a TOR connection.
• Next it gets a list of predetermined file extensions..
• Gets the filename of all files in the external storage that has any of the file extension.
• Does an AES encryption of the files.
• Displays a message presuming asking for an ransom.

Now let’s look at 2 class files that is of special interest. As it reveals more information about how the ransomware works. First is the Constants.class file. Look at the screenshot below.


The first constant ADMIN_URL which point to http://xeyocsu7fu2vjhxs.onion/ is the TOR site the ransomware connects to. This explains why it checks and tries to establish TOR connection upon starting. 2nd piece of information we can find from the “Constants” class is that it contains a variable EXTENSIONS_TO_ENCRYPT which contains the following file extensions: “jpeg”, “jpg”, “png”, “bmp”, “gif”, “pdf”, “doc”, “docx”, “txt”, “avi”, “mkv”, “3gp”, “mp4”. As the name of the variable suggest, this is the file extensions which the Ransomware would encrypt.

Another key piece on information is the CIPHER_PASSWORD, “jndlasf074hr“. Is this the key used to encrypt the files? If yes, could it also decrypts the files? For this, we take a look at the FileEncryptor.class. Look at the screenshot below of two of the functions:


As you can see from the functions, the encrypt and decrypt routine is fairly straightforward, AES using “jndlasf074hr“. Now let’s take a look at the AesCrypt class.


AesCrypt has both the encrypt and decrypt functions. Thus for example if you have installed the app by mistake and your files are now encrypted, you can re-use the functions to decrypt the files without the need to pay the ransom!!!

2 other interesting classes are “HttpSender” & “HttpSender$1”, as it send data & fetches JSON data from “http://xeyocsu7fu2vjhxs.onion/“.

[ Dynamic Analysis ]

I installed the app onto an emulator to test how it works. As it was executed on the emulator it could not perform all the ransomware “features”. But from the errors thrown, you can confirm the flow of the features. And also another reason is so that I need not turn one phone into a brick just in case it does some irreversible damage to the device.

Upon installing, it is displayed as a porn app as shown from the name of the icon.


When the app is run, it shows a message in Russian and this screen just keeps on popping up consistently even when the app is closed.


So what does actually it do in the background. Let’s check the logcat.


Obviously it is trying to establish a TOR connection which it can’t and this is repeated continuously.


There are also a lot of error messages thrown by the external libraries (which are actually *.so files needed for TOR connection) and also error that the app could not excess the External Storage which it needs to access in order to encrypt the files.

These confirms the flow of the ransomware features/actions as discussed earlier in the static analysis portion.

[ Conclusion ]

In conclusion, the ransomware is most probably marketed as an porn app and upon installing will establishes a TOR connection to the C&C and  encrypts the victim’s files and will subsequently asks for an ransom in order to decrypt back the files. However on closer observation, a technically savvy person could decrypt the files without paying the ransom as the decryption key is hardcoded within the app itself. But to be absolutely safe, don’t install porn apps 🙂

David Billa (@billa316)




[ Technical Tear Down : Silver (.Net Keylogger) ]

This is a sample which i’ve found some time ago from VirusTotal but i totally forgotten to publish it until today. This is a very easy to analyse .NET Keylogger.

One of the first thing i usually do would be try to detect what compiler or packer/crypter did the exe used so that i could use the appropriate tools to analyse it. Usually I used ProtectioniD to determine it and this is the results.

From the returned results, we can see that the binary is developed in .NET. Now I’ll be doing the technical tear-down of this .NET binary.
I’ve attached the link to the file here for anyone interested to try analysing it themselves.
The password to the attachment is “infected29A

[ Sample used in the analysis ]
MD5: c326d834da742a9d00b54cf493857f8f
SHA1: 7d6ae63d942a57df62437e3a50a310edccb9c6fc

[ How it starts ]
Since it’s a .NET binary, let’s fire up ILSpy to decompile it try to understand how does it work.
Looking at ILSpy, we can deduce a few things:

  1. The application is developed in VB as it is referencing Microsoft.VisualBasic
  2. The application didn’t use any Packer or Crypter. This means it should not be too difficult to reverse it. 😛

Like any other .NET application(s), the entrypoint is always the “Main” method.
Looking at the “Main” Method, we can see that it’s firing up “Form1”

[ Dissecting Form_Load ]
Now let’s look at “Form1_Load” method and see what actually takes place when this “Form Load“.

At first glance, it appears that the “obfuscated looking strings” looks like it’s base64 encoded. But it’s not as it’s using the “ahbGUhSfA” method to decode the string. A quick and dirty way is simply re-using the decompiled VB source code for “ahbGUhSfA” method and grab out the “de-obfuscated” strings.

After de-ofuscation, we know that the values for the following variables are as follows:
EUehzMbhDfp = 666124593
TccIbaADsu =
xUsGccFea = < _redacted_ >
iRPfddGlUHcas = h
TuqbA = http://

Next let’s look at this.

We can see that it first checks whether silver.exe exists in the victim(s)’ AppData folder. In our case as i’m using Win 7, the folder path will be “C:\Users\-.-\AppData\Roaming
Then it do a check on whether the startup path is same as the folder path which i’ve mentioned earlier.
If it is, it will start the timer. I will come back to this later on.

Ok, so what if “silver.exe” doesn’t exist in the first place?
So let’s look at the portion after “else” statement.

As we can see that it’s calling “nuaMfm” method and converting the returned data into string.
A quick look at “nuaMfm” method and it’s actually generating a random number between 3 and 50000
Then it will copy “itself” to “C:\Users\-.-\AppData\Roaming“, execute the new copy and set the file attributes to “hidden
Next it will create a new registry key,”Windows applicaton”, in “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the value of “C:\Users\-.-\AppData\Roaming\silver.exe
Finally it will call “wZLdOsNpk” method.

[ Dissecting “wZLdOsNpk” method ]
A quick glimpse at “wZLdOsNpk” method and we can know that it’s trying to send out emails. But to whom, you may ask and what data is it sending? Could it to the email address which we have de-obfuscated earlier?

Let’s look at the part of the snippet here and it is indeed sending an email from the email address which we have found earlier to itself.
The email’s subject title is “Vulcan

Now's let's look deeper into this snippet. We can also see now that this malicious application will take a screenshot of the victim(s)' computer and attached it to the email as attachment.

Finally in "wZLdOsNpk” method, we can see that it will call several methods to grab the victim(s)’ information and add it into the email’s contents.
I’ll briefly describe what does the different methods do.
GetMyIP method – basically grabs the IP address of the data by visiting “h–p://
biIS method – try to determine which version of Windows is the victim(s) running
Environment.UserName.ToString – Grab the “username” of the trojanised system.
Environment.MachineName.ToString – Grab the “computer name” of the trojanised system.
Environment.MachineName.ToString – Grab the fully qualified path of the system directory.
Environment.UserDomainName.ToString – Grab the network domain name associated with the current user.
Then using the “credentials” which we have “deobfuscated earlier, it will send it back to itself.

[ Dissecting Timer events ]
If you remember earlier while we were reversing this application, it will start 2 “Timer” if this malware exists and is running. So what does the 2 “Timer” do?
If you read the MSDN, you will realise that once a Timer had started, a “Tick” event had been triggered. In this case, it had fired up the 2 methods, “Timer1_Tick” & “Timer2_Tick”.
If we look at “Timer1_Tick”, it will look almost the same “wZLdOsNpk” method. The author probably could reuse the codes but he/she didn’t.
Next we look at “Timer2_Tick”, it’s very long…but after i spotted the API, “GetAsyncKeyState“. We can safely deduce that “Timer2_Tick” activated the “Keylogger” feature.

[ Conclusion ]
While this is definitely not one of the best .NET Malware that i’ve analysed, but it’s probably one of the many similar type of “keylogger” out there.
If we did a quick search on “Vulcan keylogger”, we can see that there are many website(s) teaching how to use it as shown in this link here.

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 .NET malware on their own.

Happy Reversing,
Jacob Soo

[Technical Tear Down] Fiesta Exploit Kit – Silverlight Exploit (CVE-2013-3896 & CVE-2013-0074)

While analysing the Fiesta Exploit Kit, a number of “java applets” and a Silverlight application was downloaded by the exploit kit. This post will describe the Silverlight exploit. The purpose of this post is to give a better technical understanding of how exploits makes use of vulnerabilities and play with memory to acheive shellcode execution.

[ Sample used in the analysis ]
MD5: a920d4ead958746e4886859fc28dbcdb
SHA1: 12a3f08144d3d9f317a62cfefb4c54fe823e9724

[ Part 1: Getting Started ]

For those who want to follow along, this is a link to the Fiesta-EK-silverlight-exploit. Do note, this is a MALICIOUS file, so please run it in a “safe” environment. The password to the attachment is “infected29A”

Silverlight applications come in a .xap file. As .XAP file is a .zip compressed file that contains the client DLL for the Silverlight application as extra DLLs of assemblies that the Silverlight application could be using. This can be the author’s own assemblies of user controls or assemblies that are not part of the Silverlight runtime by default that gets installed on the client.

External resources like images or other types of files can also be added to the .XAP file if you do embed them into your client DLL. By renaming the .xap file to .zip you can view its contents. Inside the .xap file and we will see a manifest file and a DLL file:

The manifest file describes the entry point of the application so let’s take a look at that first.

In this case, the manifest file is quite straightforward. The “EntryPointAssembly” tells us that the application starts in the tuyngled30.dll and the “EntryPointType” tells us that it starts in the App class of that package.

The next step would be to decompile the dll file. For this purpose, I used .Net Reflector. Throw the DLL into it and you will get back the C# source of the internal classes. Let’s take a look at the entry point, the App class.


The constructor calls the InitializeComponent which actually loads in components based on a xaml file. Normally, you would want to look at the xaml file to see if it loads in any additional suspicious components but for this case, the xaml file does not load in anything extra. The Application_Startup method is also called when the Silverlight application is started. In this case, it creates a new “jake” object and passes it the InitParams (We will get back to these params later)

[ Part 2: Overview ]

This exploit uses 2 vulnerabilities to achieve code execution.

CVE-2013-3896 (Memory Disclosure vulnerability) bypasses ASLR by disclosing adjacent memory such that ROP gadgets can be reliably located within

After which, CVE-2013-0074 (Double-Dereference vulnerability) achieves code execution. DEP is also bypassed by overwriting the shellcode into legitimate executable memory addresses.

Also, this exploit seems to target only x86 (32-bit) architecture.

[ Part 3: Bypassing ASLR with Memory Disclosure CVE-2013-3896 ]

Let’s look at the “jake” class.


The constructor of the “jake” class assigns the init parameter of “dies” into the byte array named “curd” and then calls the “wake” method (we will get back to this “dies” param later).


The first interesting point of the wake method is on line 103. The “brab” method basically exploits the memory disclosure vulnerability and returns the address of the ROP gadget. For this part, we will examine the “brab” method. Part 4 will describe the rest of the code.


First, take a look at line 23 and 24. A “polk” object is created. Reading the source of the “polk” class will reveal that it is a subclass of the MemoryStream object. It will be used together with the BitmapImage and WriteableBitmap class to trigger this vulnerability.

The vulnerability lies in the BitmapImage.SetSource(MemoryStream ms) method. This method creates a BitmapImage based on a memory stream. The amount of memory that is read in is based on the “length” attribute within the stream. This value is controlled by user and can be manipulated to a larger value to read in adjacent memory.

In this case, the memory stream is manipulated to look like a PNG file with a declared PLTE chunk of 0x300 bytes. Those unfamiliar with the PNG format can read about it at the following links. These 2 chapters show how a PNG is represented and the idea of chunks within a PNG file. ( and


The constructor first writes 0x29 bytes into the memory stream. These 0x29 bytes is the header of a PNG file up till the PLTE chunk header.


The “racy.tunc” method then calls the BitmapImage.SetSource method which will call polk.Read method which has been overridden such that it will declare additional arrays in a specific order (specifically the scum and raps array). When these arrays are declared, they are stored right after the already written PNG header.


The last few array elements will store the PNG Footer.

When viewed as a contiguous memory chunk, it looks like a legit PNG file. The resultant memory layout of the “polk” object is shown below.


The main objective of this arrangement is to have the additional arrays be stored in the PLTE chunk of the PNG. If we look at the PNG specifications at under the PLTE Palette section, it says that

“The first entry in PLTE is referenced by pixel value 0, the second by pixel value 1, etc.”

On line 29 of the “brab” method, “racy.papa” method creates a WriteableBitmap object with the affected BitmapImage object. The disclosed memory in the PLTE Chunk can then be accessed with the WriteableBitmap.Pixels array. The method transforms this pixels array (which stores 4 bytes/pixel in a ARGB format) into a contiguous byte array and returns it. So why is the disclosed memory important? Let’s take a look at what is disclosed.


If you are not familiar with how C# stores objects/primitives in memory or about Runtime Type Information (RTTI), read this first ( . Don’t worry if your RTTI addresses are different from mine, this is because these addresses are ASLR-ed. Basically, all objects in C# has this RTTI pointer. The RTTI stores type information that can be used for dynamic type-casting.

The objective here is to get the RTTI address. The RTTI address points to somewhere in the which is ASLR enabled. However, this RTTI is always loaded at the same offset from the base address of the Therefore, with the RTTI address, the base address of the DLL can be calculated. With that, the exact location of the ROP gadget can be reliably determined thus bypassing ASLR.

[ Part 4: Achieving code execution with CVE-2013-0074 (Double De-reference vulnerability) ]


Looking back at the “brab” method again, these are what the other functions do.

  • vamp(p1, p2) – Reads 4 bytes from p1 array starting from offset p2 (Read Pointer)
  • oils(p1,p2,p3) – Writes 4 bytes (p3) into p1 array starting from offset p2 (Write Pointer)
  • racy.lisp() – Returns the offset to find the ROP Gadget on different Silverlight versions.
    • Based on this method, it seems to target the following Silverlight versions


The rest of the “brab” method does the following

  • Save the RTTI pointer (num)
  • Save the raps[] pointer (num2)
  • Save the scum[] pointer (mews)
  • Save the offset to ROP gadget (num3)
  • Calculate and save the memory location of ROP gadget (num6)
  • Get the memory address of 41 bytes before the end of the PNG (c) (Take note of this!)
  • Writes a total of 8 bytes starting from memory address c in the following format
  • c05_8bytes
  • Returns the value of c “pointer to itself” (Take note of this!)

Let’s return back to the “wake” method.


The next important step is on line 109. The “diam” class exploits the CVE-2013-0074 vulnerability. The vulnerability lies in the ScriptObject.Initialize method. Fortunately, this is a protected method, meaning only child classes can call it. Unfortunately, ScriptObject has a public child class called HTMLObject. By sub-classing the HTMLObject class, it is now possible to call the protected Initialize method.


The “diam” class inherits from HTMLObject and wraps the Initialize method in the “gain” method. Calling the “gain” method with “(IntPtr) a” will lead to a “call [a+4]” instruction, meaning the next pointer after “a” will be called.


Recall that in the “brab” method, the above 8 bytes was written in the IDAT chunk, 41 bytes before the end of the PNG? Line 109 calls the “gain” method with “pointer to itself” as the parameter. This would lead to a “call [ptr to ROP gadget]”, thus executing the ROP gadget.

So, what ROP gadgets are being used? Interestingly, this ROP chain only consists of 1 gadget. The gadget consists of the following byte sequence “83-49-34-40-B8-01-00-00-00-C2-04-00”. Passing this sequence into Capstone yields the following result.


The gadget simply performs an OR operation with the value in [ecx+0x34] with 0x40.

Analysing the memory with WinDBG reveals that ecx at this moment contains the value of the “pointer to itself”. Therefore, [ecx+0x34] actually points to somewhere after the PNG “file”. In this case, it points to the most significant byte of the length of the next adjacent array, jake.chap[].

By performing this OR operation, it changes the length of the jake.chap[] array from 0x00000003 to 0x40000003, effectively allowing jake.chap[] array to access the entire 32-bit process memory space.

[ Part 5: Executing the Shellcode ]


With access to the entire memory space, the next step would be to get the exploit to run the shellcode payload. From line 114 of the “wake” method, a “jake.loci” object is created. This object is responsible for putting the shellcode into memory and executing it.


Take note of the “bust” method. It is the first method declared after the constructor and it contains a lot of code that does nothing. It performs a whole lot of mathematical operations and the result is neither returned nor used.


On line 115, the “loci.pore” method is called next with the parameter “curd”. The “curd” here refers to “jake.curd”. Recall the initParams that was passed into this Silverlight application in the beginning? “jake.curd” contains the value passed in through the “dies” parameter. The “loci.pore” method basically transfers “jake.curd” into “loci.curd” variable.

This is actually the shellcode itself, it is Base64 encoded and passed in through the initParams of the Silverlight Application. In this way, the shellcode could be changed or modified without needing to recompile the whole Silverlight application.


On line 116, the “gnaw” method is called. The comments basically explain what this method is trying to do. Here is a summary. (Note: [“pointer”] means dereference the pointer)

  • Create “bust” method to make sure a vTable entry is created.
  • Create a new array “scum” which contains a marker value and the pointer to this “loci” object
  • Iterate through the jake.chap[] (with 0x40000003 length) to find the marker value
  • “loci” pointer = next pointer from the marker value
  • vTable pointer = [“loci pointer”] + 0x2c
  • “bust” function pointer = [“vTable pointer”] + 0x8 (I believe the value 0x8 is used because “bust” is the second function in the “loci” class)
  • Exchange the bytes from “loci.curd” (Shellcode) and the bytes at [“bust pointer”]
  • Call the “bust” method (Shellcode Execution Here!!!)
  • Exchange the bytes back from “loci.curd” and the bytes at [“bust pointer”]
  • Restore the length of jake.chap[] to its original value (Element 0x3fffffff causes an integer overflow, essentially becoming jake.chap[-1])

Shellcode execution is achieved by making use of the jake.chap[] array to override the “bust” function instruction bytes with the shellcode bytes and then calling the “bust” function. In this way, there is no need to bypass DEP as the shellcode is residing in a legitimate executable memory.

Although I am unable to confirm this, I believe that the length of the initial “bust” function instruction bytes must be the same as the length of the shellcode that will replace them. This would explain why there are a whole lot of useless instructions initially declared in the “bust” function.

[ Conclusion ]

I have discussed how this exploit made use of 2 vulnerabilities to achieve shellcode execution. I hoped that you gained a better understanding of how the exploit was able to work. Also, an additional point to note is that the exploit code is similar to the POC code initially released by Packet Storm for these 2 vulnerabilities.

This is also my first time writing such a technical article and there are some parts of the article that I found it difficult to explain the technical details in words. If you have any advice/suggestions on how to improve this, please let me know through the comments.

If not, I hoped you enjoyed the article!

Glenn (@_graypanda)

[ 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.

[ 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”

[ 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