Proxy Logs - HTTP

1121087443.547    169 66.29.187.48 TCP_MISS/302 680 GET http://auto.search.msn.com/response.asp?  DIRECT/205.161.4.166 text/html
1121087444.308    593 66.29.187.48 TCP_MISS/200 13787 GET http://search.msn.com/results.aspx?  DIRECT/205.161.4.166 text/html
1121087444.422     13 66.29.187.48 TCP_MEM_HIT/200 38739 GET http://search.msn.com/sa/1_1_0000_26239/common.css  NONE/- text/css
1121087444.472      9 66.29.187.48 TCP_MEM_HIT/200 28200 GET http://search.msn.com/sa/1_1_0000_26239/common.js  NONE/- application/x-javascript
1121087444.663      8 66.29.187.48 TCP_MEM_HIT/200 1734 GET http://search.msn.com/s/hgrad.gif  NONE/- image/gif
1121087444.669      1 66.29.187.48 TCP_MEM_HIT/200 2003 GET http://search.msn.com/s/logomsn.gif  NONE/- image/gif
1121087444.774     12 66.29.187.48 TCP_MEM_HIT/200 423 GET http://search.msn.com/s/sbtnbk.gif  NONE/- image/gif
1121087444.898      2 66.29.187.48 TCP_MEM_HIT/200 494 GET http://search.msn.com/s/more.gif  NONE/- image/gif
1121087444.952      1 66.29.187.48 TCP_MEM_HIT/200 675 GET http://search.msn.com/s/mgou.gif  NONE/- image/gif
1121087444.967      2 66.29.187.48 TCP_MEM_HIT/200 423 GET http://search.msn.com/s/snbtnbk.gif  NONE/- image/gif
1121087445.232      4 66.29.187.48 TCP_MEM_HIT/200 319 GET http://search.msn.com/s/bullet.gif  NONE/- image/gif
1121087469.903    124 66.29.187.48 TCP_MISS/200 3099 GET http://www.google.com/  DIRECT/64.233.161.104 text/html


Proxy Logs – HTTP - Download

1122923698.265 127692 66.29.187.48 TCP_MISS/200 369576 GET http://files.dvdr-digest.com/encode/dvdshrink23.zip  DIRECT/67.15.68.51 application/zip
**************************************************************************

Example #1 – Downloading of Tools

By examining the Proxy Logs for HTTP, an investigator can determine what types of files are being downloaded and from where.  This allows for a good picture of potential malware, and intrusion tools that the attacker may have utilized to commit his crime.

Proxy Logs – HTTP - Upload

1121191891.809    356 66.29.187.48 TCP_MISS/200 627 POST http://www.myhackersite.com/smfh/login.jsp  DIRECT/12.10.217.31 text/html
1121191958.064    750 66.29.187.48 TCP_MISS/200 1160 POST http://www.myhackersite.com/smfh/passwordupload.aspx  DIRECT/12.10.217.31 text/html

**************************************************************************

Example #2 – Uploading of Unauthorized Data

By examining the Proxy Logs for HTTP, an investigator can determine where stolen data could have been uploaded outside of the corporation.  By examingint he above logs, you can see the user “” logged into site www.myhackersite.com and uploaded data to the script “passwordupload.aspx”.  

Proxy Logs – HTTP – Malware Detection

1127162071.927    350 66.29.186.12 TCP_MISS/200 2360 CONNECT command.hacker.com:443  DIRECT/66.135.194.30 -
1127162099.925    386 66.29.151.9 TCP_MISS/200 5322 CONNECT command.hacker.com:443  DIRECT/66.135.213.40 -
1127162107.480    502 66.29.173.187 TCP_MISS/200 7343 CONNECT command.hacker.com:443  DIRECT/66.135.213.48 -
1127162579.189   2444 66.29.142.29 TCP_MISS/200 1999 CONNECT command.hacker.com:443  DIRECT/66.135.194.24 -
1127162579.194   1613 66.29.59.24 TCP_MISS/200 2012 CONNECT command.hacker.com:443  DIRECT/66.135.194.24 -
1127162579.197   2012 66.29.50.149 TCP_MISS/200 1997 CONNECT command.hacker.com:443  DIRECT/66.135.194.24 -
1127162579.199   1616 66.29.128.48 TCP_MISS/200 1998 CONNECT command.hacker.com:443  DIRECT/66.135.194.24 -
*************************************************************************************

Example #3 – Malware Detection

Most malware developed today are “smart”.  They will contact a predetermined location for software updates, instructions, and to drop off compromised data.  By examining the Proxy HTTP logs, an investigator can determine the spread of the infection.  This method will work with Transparent proxies also.


Analysis Proxy Logs

Proxy Logs 

  • HTTP Logs
  • HTTPS Logs
  • Telnet Logs
  • SSH Logs
  • FTP Logs
  • News Logs


Log Analysis – VPN & Radius Logs

VPN & Radius Logs
May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 physical addresses: remote 212.72.147.6 local 100.100.100.2
May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 assigned IP address 66.71.16.253, mask 255.255.0.0
********************************************************************************
May 15 22:41:23 test400-1  15639 05/15/2005 22:02:22 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176811 authentication failed using RADIUS
May 15 22:41:42 test400-1  15639 05/15/2005 22:02:49 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176815 authentication failed using RADIUS
May 15 22:42:35 test400-1  15639 05/15/2005 22:03:39 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176823 authentication failed using RADIUS
May 15 22:42:37 test400-1  15639 05/15/2005 22:03:47 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176829 authentication failed using RADIUS
May 15 22:43:12 test400-1  15639 05/15/2005 22:04:12 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176833 authentication failed using RADIUS
May 15 22:43:29 test400-1  15639 05/15/2005 22:04:28 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176836 authentication failed using RADIUS
May 15 22:43:47 test400-1  15639 05/15/2005 22:04:57 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176838 authentication failed using RADIUS

May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 physical addresses: remote 212.72.147.6 local 100.100.100.2
May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 assigned IP address 66.71.16.253, mask 255.255.0.0

***********************************
What does this tell you?
How can this be helpful to an investigation?


VPN & Radius Logs – Identification of External IP

May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 physical addresses: remote 212.72.147.6 local 100.100.100.2
May  9 03:02:32 66.71.0.3  312 05/09/2005 03:34:52 tEvtLgMgr 0 : Security [12] Session: IPSEC[jhatefield]:19656 assigned IP address 66.71.16.253, mask 255.255.0.0
**************************************************************************

Example #1 – Identification of External IP

Now that you have determined what the internal IP address was used to compromise the server, how would you be able to determine where from the external internet this person was coming in from?


VPN & Radius Logs – Brute Force Attacks

May 15 22:41:23 test400-1  15639 05/15/2005 22:02:22 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176811 authentication failed using RADIUS
May 15 22:41:42 test400-1  15639 05/15/2005 22:02:49 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176815 authentication failed using RADIUS
May 15 22:42:35 test400-1  15639 05/15/2005 22:03:39 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176823 authentication failed using RADIUS
May 15 22:42:37 test400-1  15639 05/15/2005 22:03:47 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176829 authentication failed using RADIUS
May 15 22:43:12 test400-1  15639 05/15/2005 22:04:12 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176833 authentication failed using RADIUS
May 15 22:43:29 test400-1  15639 05/15/2005 22:04:28 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176836 authentication failed using RADIUS
May 15 22:43:47 test400-1  15639 05/15/2005 22:04:57 tEvtLgMgr 0 : Security [13] Session: IPSEC[mbushe]:1176838 authentication failed using RADIUS
**************************************************************************

Example #2 – Detection of Brute Force Attack

In the course of the investigation, you have determined that the VPN was the point of entry.  How would the VPN Logs help you determine HOW the intruder was able to access the system?


VPN & Radius Logs – Patterns of Behavior

May  9 09:14:47 test400-1 15639 05/09/2005 08:35:36 tEvtLgMgr 0 : Security [12] Session: IPSEC[sbclark]:1160001 assigned IP address 66.51.1.60, mask 255.255.0.0
May  9 09:14:47 test400-1  15639 05/09/2005 08:35:36 tEvtLgMgr 0 : Security [12] Session: IPSEC[sbclark]:1160001 physical addresses: remote 12.65.67.244 local 66.196.147.3

**************************************************************************

Example #3 – Detection of abnormal patterns of behavior

How would you be able to utilize the VPN & Radius logs to determine abnormal patterns of behavior for a suspect employee?  

For example, if the employee is at work, however his account is being utilized for VPN from outside the company during his normal work hours, it might be suspected that somebody had compromised his account and was utilizing it without authorization.



Router & Switch Logs

Log Analysis – Router & Switch Logs Combined

Scanning Office: "Birmingham, AL"
Router: 66.113.24.1 and Switch: 66.113.24.2
 MAC Address: 0004dc804ac0   IP: 66.113.24.2   Port: 0     Manufacturer: Nortel Networks
 MAC Address: 00065ba2d734   IP: 66.113.24.242   Port: 7     Manufacturer: Dell Computer Corp.
 MAC Address: 080046da3913   IP: 66.113.24.175   Port: 8     Manufacturer: Sony Corporation LTD.
 MAC Address: 00065bea6579   IP: 66.113.24.182   Port: 9     Manufacturer: Dell Computer Corp.
 MAC Address: 000874a5b56c   IP: 66.113.24.71   Port: 3     Manufacturer: Dell Computer Corp.
 MAC Address: 00055d6f0638   IP: 66.113.24.245   Port: 5     Manufacturer: D-Link Systems, Inc.
 MAC Address: 000874f96725   IP: 66.113.24.243   Port: 2     Manufacturer: Dell Computer Corp.
 MAC Address: 000874f96736   IP: 66.113.24.244   Port: 6     Manufacturer: Dell Computer Corp.
 MAC Address: 000bdb28aa0c   IP: 66.113.24.232   Port: 12     Manufacturer: Dell ESG PCBA Test
 MAC Address: 000d5618b326   IP: 66.113.24.219   Port: 7     Manufacturer: Dell PCBA Test
 MAC Address: 000d564a33c2   IP: 66.113.24.178   Port: 11     Manufacturer: Dell PCBA Test
 MAC Address: 000e7f3a1b3a   IP: 66.113.24.10   Port: 4     Manufacturer: Hewlett Packard
 MAC Address: 00123f18da3f   IP: 66.113.24.176   Port: 15     Manufacturer: Dell Inc
 MAC Address: 00b0d013b9a3   IP: 66.113.24.248   Port: 10     Manufacturer: Dell Computer Corp.
 MAC Address: 00b0d0a6597a   IP: 66.113.24.70   Port: 18     Manufacturer: Dell Computer Corp.

Scan Completed.

Log Analysis – Router & Switch Logs – Physical Location

Router: 66.113.24.1 and Switch: 66.113.24.2
MAC Address: 00055d6f0638   IP: 66.113.24.245   Port: 5     Manufacturer: D-Link Systems, Inc.

**************************************************************************

Example #1 – Identification of Physical Location

You have now identified via the DHCP server that the machine used to compromise the servers was utilized MAC address “00055d6f0638” with IP address of “66.113.24.245”, how do you track this physical machine down in a country wide network?

Log Analysis – Router & Switch Logs – Fixed IP

Router: 66.113.24.1 and Switch: 66.113.24.2
MAC Address: 000e7f3a1b3a   IP: 66.113.24.10   Port: 4     Manufacturer: Hewlett Packard

**************************************************************************

Example #2 – Finding machines with FIXED IPs

After examining the DHCP logs in detail, it does not seem that the attacker utilized DHCP to obtain their IP address.  They must have utilized a FIXED IP address.  How would you be able to determine their MAC address and physical location from another subnet in the same WAN?

Log Analysis – Router & Switch Logs – Unauthorized Devices

Router: 66.113.24.1 and Switch: 66.113.24.2
MAC Address: 00055d6f0638   IP: 66.113.24.245   Port: 5     Manufacturer: D-Link Systems, Inc.
MAC Address: 080046da3913   IP: 66.113.24.175   Port: 8     Manufacturer: Sony Corporation LTD.

**************************************************************************

Example #3 – Determination of Unauthorized Devices with Fixed IPs

How would you be able to tell if a person attached an unauthorized piece of equipment to the target network?  By examining the above lines of the router & switch logs, you can determine that there were two devices that are “non-compliant” on the network.  For example, the D-Link device is a wireless router.  This could be the compromise point of the network.  Also, since the corporation only purchases Dell computers, the connection of a Sony device is also suspicious.


DHCP Logs Analysis : DNS Unauthorized Network Extensions

Example # – DNS “Unauthorized Network Extensions”
Trundle Motor company has reported that somebody has somehow compromised their systems.  However, a detailed review of their Firewall logs show that there were no attempts from the outside world.  Also, since they are a family company, they don’t believe that any of their employees would have commited this crime.  

How can DHCP logs help this investigation?


IP Address:66.111.113.141       => 00:06:5b:17:88:c3-(UHC05R01)[Dell Computer Corp.]
IP Address:66.111.113.146       => 00:11:43:3f:1e:8b-(J0W8L61)[DELL INC.]
IP Address:66.111.113.147       => 00:06:5b:17:89:0e-(6B05R01)[Dell Computer Corp.]
IP Address:66.111.113.153       => 00:06:5b:17:8a:1a-(8C05R01)[Dell Computer Corp.]
IP Address:66.111.113.154       => 00:05:5d:6f:06:38-(wireless)[D-Link Systems, Inc.]
IP Address:66.111.113.155       => 00:06:5b:17:8a:a0-(4D15R01)[Dell Computer Corp.]
IP Address:66.111.113.156       => 00:06:5b:17:87:9e-(BF15R01)[Dell Computer Corp.]
IP Address:66.111.113.157       => 00:06:5b:17:89:19-(1D05R01)[Dell Computer Corp.]
IP Address:66.111.113.158       => 00:06:5b:17:87:b3-(75Z4R01)[Dell Computer Corp.]
IP Address:66.111.113.177       => 00:0c:29:d2:64:53-(d8e63e7d5)[VMware, Inc.]


***********************************
By examining the above logs, you can tell that IP 66.119.191.94 comes back to a D-Link router.  This may be an unauthorized wireless extension of the network.  The intruder could have entered the network utilizing this method.  This method of entry would not leave any traces in the Firewall, VPN, or remote connection logs.

The first three octets of the MAC address can be looked up in the IEEE OUI and Company_id Assignment tables at
http://standards.ieee.org/regauth/oui/index.shtml

DHCP Logs Analysis : DNS Multiple IPs

Example  – DNS “Multiple IPs”
Nisco Food and Beverage reported that four of their servers had been compromised by an internal individual.  However each of the servers seems to be compromised by a different IP address.  This company is running a DHCP server.

How would you be able to determine how many users initiated this attack?

Jun 20 07:05:15 dhcp1 dhcpd: DHCPACK on 66.121.9.155 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1
Jun 20 08:14:12 dhcp1 dhcpd: DHCPACK on 66.122.2.103 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1
Jun 20 09:12:16 dhcp1 dhcpd: DHCPACK on 66.101.3.104 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1

***********************************
By searching through the logs for a specific MAC address, you can determine when individual IP addresses are being issued.

If this attacker in question was randomly walking around the company initiating attacks, this search would tell you that the same NIC card was utilized with all three target IP’s.

Analysis DHCP Logs





Jun 20 07:05:15 dhcp1 dhcpd: DHCPREQUEST for 66.121.9.155 from 00:0d:56:1a:6a:05 (GMMHF41) via xl1
Jun 20 07:05:15 dhcp1 dhcpd: DHCPACK on 66.121.9.155 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1
Jun 20 07:05:15 dhcp1 dhcpd: DHCPDISCOVER from 00:14:22:bc:09:94 via 66.121.66.1
Jun 20 07:05:16 dhcp1 dhcpd: DHCPOFFER on 66.121.66.203 to 00:14:22:bc:09:94 (DFVDJP81) via 66.121.66.1
Jun 20 07:05:16 dhcp1 dhcpd: Added new forward map from DFVDJP81.dhcp.mycompany.com to 66.121.66.203
Jun 20 07:05:16 dhcp1 dhcpd: added reverse map from 203.66.121.66.in-addr.arpa. to DFVDJP81.dhcp.mycompany.com
Jun 20 07:05:16 dhcp1 dhcpd: DHCPREQUEST for 66.121.66.203 (66.130.0.56) from 00:14:22:bc:09:94 (DFVDJP81) via 66.121.66.1
Jun 20 07:05:16 dhcp1 dhcpd: DHCPACK on 66.121.66.203 to 00:14:22:bc:09:94 (DFVDJP81) via 66.121.66.1

Jun 20 07:05:15 dhcp1 dhcpd: DHCPACK on 66.121.9.155 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1

***********************************
What does this tell you?
How can this be helpful to an investigation?


Example #1 – DNS “Malicious User”
ABC Lollipop Incorporated reported that one of their contractors turned bad.  It seemed that the malicious user had hooked up his laptop to their network and compromised various servers, however when they examined the laptop, they couldn’t find any trace of his malicious activities.  The company utilizes DHCP and they aren’t even sure that he used the laptop in question.

How would you be able to determine if the laptop was used to commit these crimes?

DHCP Logs - Intrusion

Jun 20 07:05:15 dhcp1 dhcpd: DHCPACK on 66.121.9.155 to 00:0d:56:1a:6a:05 (GMMHF41) via xl1
Jun 20 07:05:15 dhcp1 dhcpd: DHCPDISCOVER from 00:14:22:bc:09:94 via 66.121.66.1

***********************************

During the first DHCP request, the packet includes the MAC address of the machine requesting the IP address.  This request will traverse all routers and gateways intact.  This is seen under the DHCPDISCOVER line which designates the gateway of request.

From the above request, the IP of 66.121.9.155 was assigned to the physical NIC with MAC 00:0d:56:1a:6a:05 with machine name GMMHF41.

Even if the user decides to wipe his hard drive, the IP address is tied to his physical device.  The device can be seen as the “weapon” utilized to commit the crime.

Analysis – DNS Logs: Hi-Jacking

ADD Employment Agency states that somebody seems to be stealing usernames and passwords, but they can’t determine if what’s happening exactly.  The only thing strange that they can see is that the volume on their web server seems to be very slow.

  • How would you be able to determine where the intruder was obtaining their intrusion tools from?
  • How would you be able to determine where the intruder may have off loaded the stolen information to?

Sample A –

10:54:12.423228 66.121.2.33748 > 171.159.193.173: 21345 [1au] A? www.bankofamerica.com. (42) (DF)
10:54:21.313293 66.121.2.33748 > 216.239.38.66.53: 53735 [1au] A? www.google.com. (43) (DF)
10:54:27.182852 66.121.2.33748 > 149.174.213.7.53: 19315 [1au] A? www.netscape.com. (45) (DF)
10:54:43.252461 66.121.2.33748 > 66.35.250.11.53: 43129 [1au] A? www.linux.com. (42) (DF) 

Sample B –

10:55:01.193847 66.121.2.33748 > 12.115.29.29: 21345 [1au] A? www.bankofamerica.com. (42) (DF) 
10:55:03.834839 66.121.2.33748 > 216.239.38.66.53: 53735 [1au] A? www.google.com. (43) (DF) 
10:55:18.382739 66.121.2.33748 > 149.174.213.7.53: 19315 [1au] A? www.netscape.com. (45) (DF)
10:55:21.726354 66.121.2.33748 > 66.35.250.11.53: 43129 [1au] A? www.linux.com. (42) (DF) 

DNS Logs (Malware) Example #2- Intrusion

Ding-Bat Incorporated states that they have had one of their servers compromised.  However it seemed that the intruder had “cleaned” up after themselves by wiping the computer’s hard drive when they were done.  They are pretty sure that the intruder had sent a copy of the employee database to an external location.


  • How would you be able to determine where the intruder was obtaining their intrusion tools from?
  • How would you be able to determine where the intruder may have off loaded the stolen information to?

08-May-2006 14:07:43.845 client 66.111.51.102#51402: query (cache) ‘www.insecure.org/A/IN' approved
08-May-2006 14:09:43.847 client 66.111.51.102#51403: query (cache) ‘www.2600.org/A/IN' approved
08-May-2006 14:11:43.864 client 66.111.51.102#51410: query (cache) ‘ftp.attrition.org/A/IN' approved
08-May-2006 14:13:43.854 client 66.111.51.102#51415: query (cache) ‘telnet.cultdeadcow.com/A/IN' approved
08-May-2006 14:15:43.863 client 66.111.51.102#51416: query (cache) ‘www.hackinthebox.org/A/IN' approved
08-May-2006 14:17:43.865 client 66.111.51.102#51427: query (cache) ‘home.cyberarmy.com/A/IN' approved
08-May-2006 14:19:43.873 client 66.111.51.102#51428: query (cache) ‘mixter.void.ru/A/IN' approved

DNS Log Analysis

DNS Logs
08-May-2006 13:48:07.957 client @0x8b69800: udprecv
08-May-2006 13:48:07.958 client 66.66.0.63#62048: UDP request
08-May-2006 13:48:07.958 client 66.66.0.63#62048: using view '_default'
08-May-2006 13:48:07.958 client 66.66.0.63#62048: request is not signed
08-May-2006 13:48:07.958 client 66.66.0.63#62048: recursion available
08-May-2006 13:48:07.958 client 66.66.0.63#62048: query
08-May-2006 13:48:07.961 client 66.66.0.63#62048: query '70.0.130.66.in-addr.arpa/PTR/IN' approved
08-May-2006 13:48:07.961 client 66.66.0.63#62048: send
08-May-2006 13:48:07.961 client 66.66.0.63#62048: sendto
08-May-2006 13:48:07.961 client 66.66.0.63#62048: senddone
08-May-2006 13:48:07.962 client 66.66.0.63#62048: next
08-May-2006 13:48:07.962 client 66.66.0.63#62048: endrequest
08-May-2006 13:48:07.962 client @0x8b69800: udprecv
08-May-2006 13:48:07.748 client 66.66.24.169#1025: query (cache) 'instructions.hacker.net/A/IN' approved
08-May-2006 13:48:07.748 createfetch: instructions.hacker.net A
08-May-2006 13:48:07.748 fctx 0x8251c00(instructions.hacker.net/A'): create
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): join
08-May-2006 13:48:07.749 fetch 0x81ef040 (fctx 0x8251c00(instructions.hacker.net/A)): created
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): start
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): try
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): cancelqueries
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): getaddresses
08-May-2006 13:48:07.749 fctx 0x8251c00(instructions.hacker.net/A'): query

08-May-2006 13:48:07.748 client 66.66.24.169#1025: query (cache) 'instructions.hacker.net/A/IN' approved
*************************************
What does this tell you?
How can this be helpful to an investigation?

Example #1 – Malware
The “Fuzzy Widget” company states that they have been compromised by a network Worm.  This worm was custom written by a disgruntled employee.  Since this worm is not a world wide distribution, there are no Anti-Virus Products that can detect this program.  They think that the worm is capturing keystrokes and sending them off-site.

  • How would you be able to determine the extent of their infection?
  • How would you be able to determine which machines had been compromised?
DNS Logs (Malware)

08-May-2006 14:59:43.936 client 66.11.51.102#51563: query (cache) 'mail.hackedbox.com/A/IN' approved
08-May-2006 15:00:28.014 client 66.30.0.70#18380: query (cache) 'ns4.hackedbox.com/AAAA/IN' approved
08-May-2006 15:00:28.016 client 66.30.0.70#18380: query (cache) 'ns3.hackedbox.com/AAAA/IN' approved
08-May-2006 15:00:28.019 client 66.30.0.70#18380: query (cache) 'ns2.hackedbox.com/AAAA/IN' approved
08-May-2006 15:01:18.113 client 66.19.187.65#1607: query (cache) 'toolbarqueries.hackedbox.com/A/IN' approved
08-May-2006 15:01:38.227 client 66.13.24.169#1025: query (cache) 'www.hackedbox.com/A/IN' approved
08-May-2006 15:01:43.953 client 66.11.51.102#51572: query (cache) 'mail.hackedbox.com/A/IN' approved
08-May-2006 15:02:05.022 client 66.30.0.70#18380: query (cache) 'ns4.hackedbox.com/AAAA/IN' approved
08-May-2006 15:02:05.025 client 66.30.0.70#18380: query (cache) 'ns2.hackedbox.com/AAAA/IN' approved
08-May-2006 15:02:05.921 client 66.12.9.100#1026: query (cache) 'toolbarqueries.hackedbox.com/A/IN' approved
08-May-2006 15:03:43.942 client 66.11.51.102#51575: query (cache) 'mail.hackedbox.com/A/IN' approved
08-May-2006 15:03:55.610 client 66.12.9.100#1026: query (cache) 'toolbarqueries.hackedbox.com/A/IN' approved
08-May-2006 15:04:05.962 client 66.17.6.115#1604: query (cache) 'toolbarqueries.hackedbox.com/A/IN' approved
08-May-2006 15:05:43.946 client 66.11.51.102#51576: query (cache) 'mail.hackedbox.com/A/IN' approved

08-May-2006 15:07:03.262 client 66.13.123.203#3893: query 'hackedbox.mycompany.com/A/IN' approved

Infrastructure Logs and Overview


  • DNS Logs
  • DHCP Logs
  • Router & Switch Logs
  • VPN & Radius Logs
  • Web Proxy Logs
  • Syslog Logs


Windows Firewall Logs: Analysis Suspected logs


  • In this instance, the suspect had been visiting very specific web sites, however he wiped his Internet History and “scrubbed” his hard drive after every attempt.  The Internet Firewall Logs could provide you with data of where he was visiting.

2014-06-11 13:42:46 CLOSE TCP 5.1.2.140 171.161.161.173 3054 80 - - - - - - - - -
2014-06-11 13:42:46 OPEN TCP 5.1.2.140 171.161.161.173 3056 443 - - - - - - - 

Detection of Port Scanning

2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4884 83 48 S 1714153331 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4885 941 48 S 1344758057 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4886 2433 48 S 2885764181 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4887 2433 48 S 162617412 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4888 941 48 S 1655770406 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4889 83 48 S 4255030500 0 65535 - - - RECEIVE
2014-06-13 10:08:59 DROP TCP 29.39.187.22 29.39.187.182 4890 714 48 S 4125832776 0 65535 - - - RECEIVE
Finding Port Scanning
  • We can look for two types of scans:
    • Horizontal (Same port, many different machines)
    • Vertical (Same machine, many different ports)
  • Each type leaves a different signature in the logs
  • Import logs into Excel
Examining Scans Data
  • Import firewall logs into Excel 
  • This makes scans easy to spot manually
Horizontal Scans

Vertical Scans


Analysis Windows Firewall Logs


#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2014-06-06 11:34:01 DROP UDP 75.34.59.126 75.34.59.255 3210 3328 708 - - - - - - - RECEIVE
2014-06-06 11:34:01 DROP UDP 75.34.59.139 75.34.59.255 1040 3328 708 - - - - - - - RECEIVE
2014-06-06 11:34:03 OPEN TCP 75.34.59.183 75.34.101.20 1982 80 - - - - - - - - -
2014-06-06 11:34:03 OPEN TCP 75.34.59.183 75.34.101.20 1983 80 - - - - - - - - -
2014-06-06 11:34:04 CLOSE TCP 75.34.59.183 75.34.101.20 1978 80 - - - - - - - - -
2014-06-06 11:34:04 OPEN TCP 75.34.59.183 75.34.101.20 1984 80 - - - - - - - - -
2014-06-06 11:34:04 CLOSE TCP 75.34.59.183 75.34.101.20 1984 80 - - - - - - - - -
2014-06-06 11:34:05 CLOSE TCP 75.34.59.183 10.130.40.11 1925 389 - - - - - - - - -
2014-06-06 11:34:06 DROP UDP 75.34.59.126 75.34.59.255 3210 3328 708 - - - - - - - RECEIVE
2014-06-06 11:34:06 CLOSE TCP 75.34.59.183 75.34.101.20 1982 80 - - - - - - - - -
2014-06-06 11:34:06 DROP UDP 75.34.59.139 75.34.59.255 1040 3328 708 - - - - - - - RECEIVE
2014-06-06 11:34:07 DROP UDP 75.34.59.224 255.255.255.255 68 67 328 - - - - - - - RECEIVE
2014-06-06 11:34:07 CLOSE TCP 75.34.59.183 75.34.101.20 1983 80 - - - - - - - - -
2014-06-06 11:34:03 OPEN TCP 75.34.59.183 75.34.101.20 1982 80 - - - - - - - - -
*************************************
What does this tell you?
How can this be helpful to an investigation?


2014-06-06 11:34:03 OPEN TCP 75.34.59.183 75.34.101.20 1982 80 - - - - - - - - -
  • date - 2014-06-06
  • time - 11:34:03 
  • action - OPEN 
  • protocol - TCP 
  • src-ip - 75.34.59.183
  • dst-ip - 75.34.101.20
  • src-port - 1982 
  • dst-port - 80 
  • size - -
  • tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2014-06-08 07:34:29 OPEN TCP 48.28.28.182 48.28.28.195 1057 139 - - - - - - - - -
2014-06-08 07:34:29 OPEN TCP 48.28.28.182 48.28.28.195 1058 445 - - - - - - - 
  • From the logs, it can be determined that the intruder IP “48.28.28.182” opened and established a TPC session with “48.28.28.195” over ports 139 and 445.  This is commonly known as a “mapped network drive”
2014-06-08 08:01:43 CLOSE TCP 5.1.2.139 216.239.51.104 1476 80 - - - - - - - - -
2014-06-08 08:01:43 OPEN TCP 5.1.2.139 216.239.51.104 1478 80 - - - - - - - - -
2014-06-08 08:01:44 OPEN TCP 5.1.2.139 10.130.70.61 1479 443 - - - - - - - - -
2014-06-08 08:02:02 OPEN TCP 5.1.2.139 72.14.209.176 1480 80 - - - - - - - - -
2014-06-08 08:02:02 OPEN TCP 5.1.2.139 72.14.209.176 1481 80 - - - - - - - - -
2014-06-08 08:02:04 CLOSE TCP 5.1.2.139 64.233.169.103 1466 80 - - - - - - - - -
2014-06-08 08:02:05 CLOSE TCP 5.1.2.139 10.130.70.61 1479 443 - - - - - - - - -
2014-06-08 08:02:10 CLOSE UDP 5.1.2.139 12.127.16.68 1025 53 - - - - - - - - -
2014-06-08 08:02:15 CLOSE TCP 5.1.2.139 72.14.209.176 1480 80 - - - - - - - - -
2014-06-08 08:02:15 CLOSE TCP 5.1.2.139 72.14.209.176 1481 80 - - - - - - - - -
2014-06-08 08:02:24 OPEN TCP 5.1.2.139 64.233.169.103 1482 80 - - - - - - - - -
2014-06-08 08:02:24 OPEN TCP 5.1.2.139 72.14.209.176 1483 80 - - - - - - - - -
2014-06-08 08:02:35 CLOSE TCP 5.1.2.139 72.14.209.176 1483 80 - - - - - - - - -
2014-06-08 08:02:37 OPEN TCP 5.1.2.139 72.14.209.176 1484 80 - - - - - - - - -
2014-06-08 08:02:37 OPEN TCP 5.1.2.139 72.14.209.176 1485 80 - - - - - - - - -
2014-06-08 08:02:42 OPEN UDP 5.1.2.139 12.127.16.68 1025 53 - - - - - - - - -
2014-06-08 08:02:42 OPEN TCP 5.1.2.139 208.65.153.253 1486 80 - - - - - - - - -

Windows Firewall Logs

Kinds Of Connections

  • The most common types of firewall traffic:


  • Mostly we have Incoming TCP, ICMP, UDP (DNS separate), and some Outgoing connections


Windows Event Logs

Broad Categories of Windows Logs
  • Error: significant problem like data loss
  • Warning: Potentially serious problem, but not necessarily.  Something requiring further investigation.
  • Information: More for debugging purposes.
  • Success Audit: Successful security event.  Could be malicious.
  • Failure Audit: Opposite of above.  Could be benign.  
Application Logs
  • Pretty self-explanatory.
  • Not all applications choose to log via the Event Viewer
    • This should be checked before assuming
    • Often applications create their own logs
Security Logs
  • Contains records of:
    • Valid and invalid logon attempts
    • Events related to resource usage:
      • Creating files or objects
      • Opening files or objects
      • Deleting files or objects
  • The Local Security Policy will allow you to obtain more information about what can be logged
Other Built-In Logs
  • System:  Drivers and hardware, if they follow the Windows API, generate events that get logged in this category
  • Setup:  Windows Update logs here and everything that happens during installation.
  • Depending on the machine, could also have domain controller or DNS logs, etc.

Windows Event Viewer – Logins
Windows Event Viewer – SQL logs

Windows Event Viewer – Office Logs
Windows Event Logs Lookup sites : Microsoft Technet, EventID.net

Other Apache Logs

  • audit_log: Like the access log, but more complete
    • Has full Request Headers and POST data
    • Generated by mod_security
    • An Apache module for enforcing fine-grained and extensive security measures
  • ssl-access_log: the access log for SSL requests
  • ssl-error_log: the error log for SSL requests
  • ssl_request_log: same as ssl-access_log but without the status code
  • ssl_egine_log: information from Apache’s mod_ssl that combines entries from access and error
  • upload/: contains html files with Chinese characters in them 
    • Each file is labeled with a timestamp and IP (we’ll come back to this)


Log Analysis – Apache Logs

  • 131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "GET /scripts/auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.1" 302 268 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
*******************
  • What does this tell you?
  • How can this be helpful to an investigation?

192.168.10.1 - - [03/Sep/2012:14:40:53 -0400] "GET /cgi-bin/edit.pl HTTP/1.1" 404 305 

  • IP Address – 192.168.10.1
  • Date and Time offset - [03/Sep/2012:14:40:53 -0400] 
  • Method Invoked – GET
  • URL Requested - /cgi-bin/edit.pl 
  • Protocol Used - HTTP/1.1
  • Result Code – 404
  • Numbers of Bytes Transferred - 305
Directory Traversal Attack
192.168.10.1 - - [03/Sep/2012:11:11:05 -0400] "GET /../../../tmp HTTP/1.0" 400 352 

192.168.10.1 - - [03/Sep/2012:11:11:19 -0400] "GET /../../../ 
HTTP/1.0" 400 349 
192.168.10.1 - - [03/Sep/2012:11:11:22 -0400] "GET /../../../usr HTTP/1.0" 400 352 
192.168.10.1 - - [03/Sep/2012:11:11:26 -0400] "GET /../../../usr HTTP/1.0" 400 352 
192.168.10.1 - - [03/Sep/2012:11:12:04 -0400] "GET /../../home HTTP/1.0" 400 350 
192.168.10.1 - - [03/Sep/2012:11:12:10 -0400] "GET /../../cgi-bin HTTP/1.0" 400 353 

Note (in blue): Attempts to access directories outside standard web environment
    SQL Injection Attack
    192.168.10.1 - - [03/Sep/2012:14:38:19 -0400] "GET /cgi-bin/publisher/search.cgi?dir=jobs&template=;cat+/etc/passwd|&output_number=10 HTTP/1.0" 200 306 

    192.168.10.1 - - [03/Sep/2012:14:40:20 -0400] "GET /login.asp?user=masmith&password=123 or 1=1 " 200 308

    192.168.10.1 - - [03/Sep/2012:14:40:20 -0400] "GET products.asp?productid=123;DROP TABLE Products " 200 254

    Log Analysis – Apache Logs : Access Log

    131.108.45.81 - - [05/Dec/2014:23:57:13 -0500] "GET //auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.1" 302 260 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "HEAD / HTTP/1.1" 302 - "-" "Mozilla/5.00 (FusionVM/2.1.5)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "GET /auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.1" 302 260 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "GET /FusionVM/ HTTP/1.1" 302 214 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "\x16\x03\x01" 302 194 "-" "-"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "\x16\x03\x03\x02\xae\x01" 302 194 "-" "-"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "GET /cgi-bin/auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.1" 302 268 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "GET /scripts/auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.1" 302 268 "-" "Mozilla/4.0 (CriticalWatch-FusionVM)"
    131.108.45.81 - - [05/Dec/2014:23:57:14 -0500] "\x16\x03\x02" 302 194 "-" "-"
    131.108.45.81 - - [05/Dec/2014:23:57:28 -0500] "GET /../../../../../../../../../boot.ini HTTP/1.1" 400 226 "-" "Mozilla/5.00 (FusionVM/2.1.5)"
    131.108.45.81 - - [05/Dec/2014:23:57:28 -0500] "GET /../../../../winnt/repair/sam._ HTTP/1.1" 400 226 "-" "Mozilla/5.00 (FusionVM/2.1.5)"

    131.108.45.81 - - [05/Dec/2014:23:57:28 -0500] "GET /..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\boot.ini HTTP/1.1" 302 213 "-" "Mozilla/5.00 (FusionVM/2.1.5)"

    Apache and Its Logs


    • Very popular open-source web server
      • 15 years of active development
      • On 120 million Internet servers (as of April 2010)
      • 64.91% of all web servers as of January 2012
    • By default has two main log files:
      • Access log (logs all requests to the server)
      • Error log (logs all requests that caused an error)
    • Other types as well: ssl_access, ssl_error, etc.


    Log Analysis - IIS Logs

    Internet Information Service Logs (IIS)
    HTTP Result Codes
    1xx – Informational
    2xx – Successful
    3xx – Redirection
    4xx – Client Error

    5xx – Server Error


    Log Analysis

    Server/Machine logs 
    • FTP Logs
    • IIS Logs
    • Apache Logs
    • Windows Event Logs
    • Windows Firewall Logs
    1-Log Analysis – FTP Logs
    • #Software: Microsoft Internet Information Services 6.0
    • #Version: 1.0
    • #Date: 2014-03-17 22:11:28
    • #Fields: time c-ip cs-method cs-uri-stem sc-status sc-win32-status 
    • 22:11:28 66.38.28.183 [5]USER anonymous 331 0
    • 22:11:28 66.38.28.183 [5]PASS -iss@iss.iss.iss 230 0
    • 22:11:28 66.38.28.183 [5]MKD iss.test 550 5
    • 22:11:28 66.38.28.183 [5]RMD iss.test 550 5
    • 22:11:28 66.38.28.183 [5]QUIT - 226 0
    • 22:11:28 66.38.28.183 [6]USER anonymous 331 0
    • 22:11:28 66.38.28.183 [6]PASS scanner@test.net 230 0
    • 22:11:28 66.38.28.183 [7]USER anonymous 331 0
    • 22:11:28 66.38.28.183 [7]PASS scanner@test.net 230 0
    • 22:11:28 66.38.28.183 [7]CWD - 250 0
    • 22:11:28 66.38.28.183 [8]USER 3,255 331 0
    • 22:11:28 66.38.28.183 [8]PASS - 530 1326
    • 22:11:28 66.38.28.183 [9]USER anonymous 331 0
    • 22:11:28 66.38.28.183 [9]PASS scanner@test.net 230 0
    • 22:23:22 66.38.28.183 [12]USER anonymous 331 0



    22:11:28 66.38.28.183 [5]MKD iss.test 550 5

    • time - 22:11:28
    • c-ip - 66.38.28.183
    • cs-method - [5]MKD 
    • cs-uri-stem - iss.test
    • sc-status - 550
    • sc-win32-status - 5

    Result Codes – First Digit

    1yz – Positive Preliminary Reply
    2yz – Positive Completion Reply
    3yz – Positive Intermediate Reply
    4yz – Transient Negative Reply
    5yz – Permanent Negative Reply










    Understanding Common Log Attributes


    • What kind of information do logs contain?
    • Example entry:

    Feb  1 00:00:02 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0OUT=br0 PHYSOUT=eth1 SRC=192.150.249.87 DST=11.11.11.84LEN=40 TOS=0x00 PREC=0x00 TTL=110 ID=12973PROTO=TCP SPT=220 DPT=6129

    • WINDOW=16384 RES=0x00 SYN URGP=0
    • Quite a lot of information, but very little at the same time

    Cataloging the Information
    • Feb  1 00:00:02: Date and time (GMT or Local)
    • bridge kernel: NIC interface name
    • INBOUND TCP: Type of traffic flow, direction and protocol
    • IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1: Adapter traversal for the firewall
    • SRC=192.150.249.87 DST=11.11.11.84: Source and destination IP
    • LEN=40 TOS=0x00 PREC=0x00 TTL=110 ID=12973: IP Header information
      • Sometimes includes DF as well
    • PROTO=TCP SPT=220 DPT=6129: Protocol and port numbers
      • Also have PROTO=UDP and PROTO=ICMP
    • WINDOW=16384 RES=0x00 SYN URGP=0: Protocol specific information

    Programs for Log Analysis


    • Perl
    • Awk / Sed
    • SQL 
    • Oracle
    • MS Access / Excel
    • 3rd Party Programs – (Web Trends, Calamari, HP Open View, etc)
    • Analysis Appliances – (Niksun, SNORT, etc)
    • Built in Auditing Tools (Cisco, Active Directory)
    • Forensic Tools – (Encase, FTK, etc)


    Analyzing Logs


    • General approach no matter what type of log is being looked at (not in a particular order):
    • Understand the log information
      • Parse the particular log format currently being scrutinized 
      • Keep in mind what device the log came from
    • Understand the network topology
    • Find anomalous/suspicious patterns based on above knowledge 


    What can logs do for?

    • Tracks historic patterns of behaviors
    • Identification of compromised targets
    • Provides a trace of attack activity
    • Provides a log of malicious activity even if server is “cleaned up”
    • Provides evidence that is not captured at the Server or Application level

    Types of Logs
    • Server Logs
      • Windows, Unix, Linux, Macintosh, etc.
    • Application Logs
      • Active Directory, Novel, IIS, Oracle, etc.
    • Appliance Logs
      • Firewall, Router, Switch, etc.
    • Infrastructure Logs
      • DNS, DHCP, LDAP, Proxy, Router, Switch, etc.
    • External Logs
      • Upstream ISP, Upstream DNS, etc.

    Method of Obtaining Logs
    • System Administrator
    • Network Administrator
    • Information Assurance Personnel
    • Upstream Provider

    Log Sizes and Durations
    • Size – UP to 5+ GB of Text per day
      • Sample (1 Day at USSS) 
        • DNS Logs – 4 x 800 MB per day 
        • Firewall Logs – 6 x 100 MB per day
        • Internet Logs – 600 MB per day (URL only)
        • Intranet Access Logs – 200 KB per day
        • Switch Logs – 50 KB per day
    • Duration – 
      • Sample
        • Switch Logs – On device – Currently Hot
        • Mail Logs – 5 years
        • Squid Logs -  7 years

    Types of Log Servers

    • Pros and Cons to having a dedicated server
    • Two general approaches:
      • Push
      • Pull
    • Unix based (Syslog)
    • Windows based (Event viewer)


    What’s Logging?

    • A way for a computer to record events that occur during execution
    • An event is anything that causes a program to perform an action
    • Ranges from error conditions to normal functioning of equipment
    • Many crucial processes run in the background
    • These background process logs are generated without direct input from the user
    • Logging provides visibility into the operation of these processes


    Covert_TCP

    • http://www.psionic.com/papers/covert
    • Uses TCP and IP headers to create covert channels
    • Data can be hidden in various fields
      • –IP Identification field
        • One character embedded per packet
      • –TCP sequence number
        • One character embedded per SYN request and Reset packets
      • –TCP acknowledgement number
        • One hidden character per packet is relayed by a “bounce” server
    • Can send data over any TCP source/destination ports
      • –Can bypass firewall if use ports such as 25 or 53

    Covert_TCP


    Reverse WWW Shell (HTTP)

    • Allows an attacker to remotely access a victim machine with a command-line prompt
    • A Reverse WWW Shell server and Perl interpreter must be installed on the victim machine
    • A Reverse WWW Shell master software and Perl interpreter must be installed on the attacker’s machine
    • Can sneak past firewall
    • Perl code available at http://thc.pimmel.com
    • Every minute, Reverse WWW Shell server will contact the master to retrieve commands issued by the attacker
    • Reverse WWW Shell server executes the commands, sends the results to Reverse WWW Shell master (via http request), and retrieves the next command (via http reply)
    • Victim machine appears to be a web client sending HTTP Get commands while attacker’s machine appears to be a web server


    ICMP Tunnel / ICMPTX

    • Establishes a covert connection between two remote computers (client and proxy) using ICMP echo requests and relay packets
    • ICMP tunneling can be used to bypass firewalls rules through obfuscation of the actual traffic. 
    • Without proper deep packet inspection or log review, network administrators will not be able to detect this type of traffic through their network.
    • Programs such as Loki, Hans, ICMP-Shell, PingTunnel

    http://code.gerade.org/hans/

    Covert Channels (Tunneling)

    • Carrying one protocol inside another protocol
      • Eg. Tunneling AppleTalk traffic over IP
    • Any communications protocol can be used to transmit another protocol
      • SSH protocol used to carry telnet, FTP, or X-Windows session
    • Covert tunnel applications
      • Hans, Loki
      • Reverse WWW Shell


    Covert Channels

    • Communication channels that disguises data while it moves across the network to avoid detection 
    • Require a client and server 
    • Can be used to remotely control a machine and to secretly transfer files or applications





    Alternate Data Streams (NTFS)

    • NTFS allows every file to have multiple streams of data associated with it 
    • The normal contents of a file that can be seen and accessed by users is a stream itself
    •  Can be used to hide binary files

    Alternate Data Streams (NTFS)






    Creating Hidden Files in Windows



    Creating Hidden Files and Directories in UNIX



    Unix Shell History Files

    • stores a complete list of all commands entered by the user at the Unix command prompt 
    • Usually stored in users’ home directories 
    • Attacker may configure the length of the shell history file to be zero but may raise suspicion 
    • Careful attacker will remove unwanted lines from the history file via VI editor


    Altering Accounting Files in Unix


    • utmp, wtmp, and lastlog files are the main accounting files in Unix Written in special binary format 
    1. Can be edited using tools such as remove, wtmped, marry, cloak, logwedit, wzap, and zapper http://ftp.technotronic.com/unix/log-tools
    2. Tools included in RootKits


    Altering System Logs in Unix

    • Unix log files are stored in files specified in /etc/syslog.conf (eg. /var/adm/messages) 
    • Attackers can alter log files via editors such as vi or emacs


    Altering Event Logs in Windows


    • Opening or editing event log files cannot be done with a standard file editing tool 
    • Deleting event log files possible but may cause suspicion 
    • WinZapper tool allows attacker to selectively delete security events 
    http://ntsecurity.nu/toolbox/winzapper

    WinZapper – Windows XP/NT/2000/2003

    Hiding Evidence by Altering Logs


    • Attackers like to remove evidence from logs associated with attacker’s gaining access, elevating privileges,and installing RootKits and backdoors Login records 
    • Stopped and restarted services 
    • File access/update times
    • Security-related events such as failed login attempts or failed access to files 
    • System events such as inability in starting a system service 
    • Application events related to applications such as databases or web servers