Checkmate » Incident Response http://niiconsulting.com/checkmate An Information Security Blog by NII Consulting Fri, 02 Dec 2011 08:26:35 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 A Phishy Story http://niiconsulting.com/checkmate/2009/11/05/a-phishy-story/ http://niiconsulting.com/checkmate/2009/11/05/a-phishy-story/#comments Thu, 05 Nov 2009 12:17:40 +0000 TAS http://niiconsulting.com/checkmate/?p=80 Phishing sounds similar to fishing. Fishes are to the volume of internet users today much like fishermen are to phishers. Zillions of fishes falling prey the nets is nothing less compared to internet users being phished through their own in boxes and messengers. Phishers tend to have some personal favorites – personal information, credit cards numbers, debit cards numbers with ATM pins, etc. Though phishing has been around for a long time, it became more prominent back in 2003. You can read more here on the big scams here.

How does it all work?

A typical modus operandi:

1) The Phisher would either go out and buy a phishing kit from the underground channels or create a look alike page himself.

2) He would then need hacked websites or a server where the pages can be hosted. This can also be easily made available. He would pay or trade for a list of hacked websites on IRC channels, underground forums etc. These are some very common sources for such deals. He could also target systems that are vulnerable to a particular vulnerability or weakness in the website – vulnerability in the hosting providers control panel software, exploit for popular CMS like Joomla, 0day vulnerability in web server, etc. A zero-day (or zero-hour) attack or threat is a computer threat that tries to exploit computer application vulnerabilities that are unknown to others, undisclosed to the software vendor, or for which no security fix is available. (ref : http://en.wikipedia.org/wiki/Zero_day_vulnerability)

3) Once the hacked infrastructure is ready it’s time to spam. They would ideally send out emails in large volumes. These emails are crafted to perfection. They would have the company logo, an appealing message in the email; use the CSS as the company that is phished, etc. All this together make it look perfect. It’s like decorating the devils face with cosmetics to make it look innocent. But not to forget the devil under a thin layer of cosmetics. They will have a crafted link and the hyperlink actually pointing to some website where the pages are hosted.

However, the entire process is a gamble. Some may fall prey to their phish nets while others may not. Over the years, phishing scams have grown from simply stealing accounts into much more dangerous criminal intention. Assuming the user is a prey of the phish net, let us understand the ways in which a phisher can harvest the data of the victim. There are various ways in which this can be done.

1) The attacker here uses services of websites that let you send HTML forms embedded in your email. On submit of this HTML form the phished page will redirect you to the legitimate website. This often tricks the user. They don’t realize what just happened. The details entered on the form are then emailed to the phisher’s inbox that is supposed to collect the details. The most common examples where you can see them are when advertising on the internet.

2) Second, the email is scripted in a way that a user is tempted or forced to visit the copied website. The attacker can also use the tactic mentioned above and use services like www.emailmeform.com. Attacker creates an account here and links his entire phished page to use their service to capture the details and then email it to them. This is the most common method used by phishers. Also the pages are scripted in server side programming languages like PHP, .NET, JSP etc. Doing so it does not expose the modus operandi or the attacker’s identity in any way or other details in any way.

3) The third type is where the phishers use nothing like above and instead writes all the output to a predefined file. In this way he needs no email address or anything mentioned above to capture the user details. This is what I am exactly going to write about.

Since I had some time off before I could start with the next takedown, I decided to dig further. Before we begin let me give you a brief about our service and the client. We offer take down services to a large public sector bank. We have a strict timeline defined of 24 hrs for every takedown. Every time a customer or their monitoring reports a phished page we have to takedown the site to protect the loss of financial and other details. While doing takedowns I also get a chance to research on understanding the modus operandi behind the operation. It is very interesting.

I have just started my day checking my email over a cup of coffee. I receive a new email on Tue 11/3/2009 10:22 AM about a phished link being up with the URL and we need to immediately start the takedown. He also sends me a sample email. We did the usual process and the link was down by noon. Have a look at a sample phishing email.



The email looks so real. It has the logo of the customer and perfect login URL. On hover I found it was actually pointing to some server in Russia. The page ‘retails.html’ simply redirects to the next URL where the phished page is hosted. Have a look at the closing lines of the email below. The phisher uses pressure tactic that will force the user to browse the URL.

Ok I now click and I am now redirected to the URL http://200.119.X.X/retail/login.php. The page looks like this

I then enter some fake details on this page and press the Enter key. I am now redirected to another page called ‘accounts.php’ on the same domain. I quickly check the html source code (view source) of the page to check for the

tag. This is where I would see where the page is going on hitting ‘submit’. I am now redirected to another page hosted on a hacked domain called hxxp://stirileprotv.fnhost.org/bi/ib.php

I go a level up in the URL hxxp://200.119.X.X/retail/login.php and now I see the directory listing. I see 2 files under the retail folder namely ‘login.php’ and ‘accounts.php’. Directory Listing has been common in all my takedowns. They don’t really care for the directory listings. What I also observed, at the bottom of the ‘account.php’ page is more interesting. The page is has an IFRAME with src pointing to http://statanalyze.cn/lib/index.php. This is some malware getting downloaded on victim system.

My anti virus immediately pops up an alert that a malware is getting downloaded. And it immediately blocks it. Coming back to ‘accounts.php’ it asks for my Name, email address, credit card number, ATM pin and expiration date. On entering some fake details I am now redirected to a third domain hxxp://stirileprotv.fnhost.org/bi/ib.php. And from ‘ib.php’ it redirects me to the legitimate page of my client website. I have changed that to hxxp://www.google.com in the code snippet. Aren’t these guys sick of so many re directions? Not really they have a smart modus operandi. They don’t use one domain to complete their operation.

I again go a level up on the http://stirileprotv.fnhost.org/bi/ib.php. What I happen to find is something even more interesting. It had a page ‘ib.php’ under the ib folder and a .txt file. When I tried accessing the file what I find is the actual account details of the people who have fallen prey to the trick with their usernames, credit card numbers, internet banking IDs and passwords. Check file snippet below

I then contact the client to freeze the accounts and get in touch with the hosting providers. I make sure I ask the hosting providers to provide me with the pages as they aid to my research in understanding various modus operandi out on pr0wl. Most of the time they don’t give the pages but this time I was lucky. The tech support guys actually emailed me the contents of the ib folder. Have a look at the php code

Let me explain the code in brief. It opens a stream to a file called x-account-all.txt and then captures the post variables from the URL http://200.119.X.X/retail/accounts.php. The following table explains what each variable means

I thought that was it. I was done with my research. I relaxed a bit and stretched my arms. But hold on readers I recollect that the website was also vulnerable to IFRAME injection. No more research on this malware guys I have colleagues who enjoys this. I will send this to him. Till he comes up with his analysis there are some who have already done it. Check the link below

http://wepawet.iseclab.org/view.php?hash=363c95666cf1e80072656c7b562c4dbb&type=js

http://anubis.iseclab.org/?action=result&task_id=1c109b3e2cc07d1f49168943cc884e1d2

http://www.virustotal.com/analisis/837508d65acc78ec684c0d7a907bea7f49ce223052a18a076240018fc61a0d7f-1257141946

I was still way too itchy to pull down a full stop. I picked some arbitrary entries from the file and picked the ‘ea’ and ‘bb’ field. Why only them? (I got this particular combination after trying out a few) I was able to login to the Yahoo accounts of the victim since the password used was the same for both the accounts. I then checked the spam box and found the email that the victim had received. There were similar emails and to my surprise I found another URL hosting the phished page. Ok guys that’s it, I need to get back to my next takedown immediately  Oh! By the way, this time it is some Windows 2003 server behind some ADSL router running the phished page on a XAMP server. I did RDP to the box, 3389 was found open. I will come back if I find something more interesting.

All the details in this post have being changed or rename to protect real identity of our client.

Adios!
Taufiq Ali

]]> http://niiconsulting.com/checkmate/2009/11/05/a-phishy-story/feed/ 0 Computer Forensics Volunteer Project http://niiconsulting.com/checkmate/2006/08/28/computer-forensic-volunteer-project/ http://niiconsulting.com/checkmate/2006/08/28/computer-forensic-volunteer-project/#comments Mon, 28 Aug 2006 08:38:46 +0000 Bhushan Shah http://www.niiconsulting.com/checkmate/2006/08/computer-forensic-volunteer-project/ by Bhushan Shah, NII Consulting

Mrs Carol L. Stimmel has taken upon her to start a Computer Forensic Volunteer Project to provide low-cost services to those who cannot assert advantage from our skills.

Here is a bit taken from the press release:-

“As expert members of the international computer forensics community which provides unique and highly desirable services to the legal system, we assume a responsibility to provide services to those in need yet unable to pay. As a result, the Computer Forensics Volunteer Project (CFVP) provides pro bono and low-cost forensic services to individuals and organizations who normally would not be able to take advantage of the distinct litigation advantage provided by these techniques.”

On behalf of NII Consulting I have volunteered to take part in the project and would like to help people who cannot afford such services.

]]> http://niiconsulting.com/checkmate/2006/08/28/computer-forensic-volunteer-project/feed/ 1 Understanding Apache and Squid Logs http://niiconsulting.com/checkmate/2006/07/16/understanding-apache-and-squid-logs/ http://niiconsulting.com/checkmate/2006/07/16/understanding-apache-and-squid-logs/#comments Sun, 16 Jul 2006 11:29:44 +0000 Kush http://www.niiconsulting.com/checkmate/2006/07/understanding-apache-and-squid-logs/ By Kush Wadhwa, NII Consulting

Welcome to the world of log analysis. Log analysis plays a crucial role in intrusion detection. If the compromised system is running on Linux platform one of the first steps which the investigator will perform is the analysis of log files.

Linux has an ability to store the logs of different services like for apache, squid logs, syslogs, and cron logs. These logs help users to resolve different problems and auditing of user actions. In this article we will talk about apache logs & squid logs since they are very closely related to each other and we will also see how to read apache & squid log files.

In Apache, there are two important log files from the incident response perspective. They are :-

(1)error log

(2)access log

The error log contains messages sent from Apache for errors encountered during the course of operation. This log is very useful for troubleshooting Apache issues on the server side. Location of these files depends on the user; the location is described in the Apache configuration file i.e. /etc/httpd/conf/httpd.conf. Let’s look at the error log configuration code from httpd.conf.

ErrorLog /Path/to/error/log/file

The directives which are used in httpd.conf file are ErrorLog & CustomLog.

Now lets assume our error log file is in /etc/httpd/logs/error.log & access log file is in /etc/httpd/log/access.log. The output of the error.log file will look like this

[Sun Feb 19 13:32:33 2006] [notice] suEXEC mechanism enabled (wrapper:/usr/sbin/suexec)

[Sun Feb 19 13:32:34 2006] [notice] Digest: generating secret for digest authentication…

[Sun Feb 19 13:32:34 2006] [notice] Digest: done

[Sun Feb 19 13:32:34 2006] [notice] LDAP: Built with OpenLDAP LDAP SDK

[Sun Feb 19 13:32:34 2006] [notice] LDAP: SSL support unavailable

[Sun Feb 19 13:32:34 2006] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.

[Sun Feb 19 13:32:34 2006] [notice] Apache/2.0.52 (Red Hat) configured –resuming normal operations

First field tells the date & time when apache service was made to run. The second entry lists the severity of the error being reported. Actually, the ‘LogLevel’ directive is used to control the types of errors that are sent to the error log by restricting the severity level. The following levels are available, in order of decreasing significance:

emerg- Emergencies – system is unusable. “Child cannot open lock file.Exiting”

alert – Action must be taken immediately. “getpwuid: couldn’t determine user name from uid”

crit- Critical Conditions. “socket: Failed to get a socket, exiting child”

error- Error conditions. “Premature end of script headers”

warn- Warning conditions. “child process 1234 did not exit, sending another SIGHUP”

notice- Normal but significant condition. “httpd: caught SIGBUS, attempting to dump core in …”

info- Informational. “Server seems busy, (you may need to increaseStartServers, or
Min/MaxSpareServers)…”

debug-Debug-level messages “Opening config file …”

Third field will show the error which blocked the Apache service or the steps taken while starting apache service.

Now we will talk about the second important file i.e., access log file.
Access log file will give web page access information. Output of access log file will look like this

192.168.0.231 – - [19/Feb/2006:13:53:58 +0530] “GET / HTTP/1.1″ 304 – “-” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 1.7.5)

Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4″

192.168.0.231 – - [19/Feb/2006:13:53:58 +0530] “GET /favicon.ico HTTP/1.1″ 404 289 “-” “Mozilla/5.0 (X11; U; Linux i686;

en-US; rv: 1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4″

192.168.0.231 – - [19/Feb/2006:13:54:35 +0530] “GET /favicon.ico HTTP/1.1″ 404 290

192.168.0.231 – - [19/Feb/2006:13:54:35 +0530] “GET / HTTP/1.1″ 200 12

To understand access logs better, lets look at this example.

192.168.0.231 – - [19/Feb/2006:13:53:58 +0530] “GET /favicon.ico HTTP/1.1″ 404 289 “-” “Mozilla/5.0 (X11; U; Linux i686;

  1. 192.168.0.231- Hostname or IP Address of a client.
  2. - – RFC 931 information
  3. - – Username entered by the client for authentication. Since the page does not require username for authentication, the field is blank
  4. [19/Feb/2006:13:53:58 +0530]- Date and time when the page was requested.
  5. GET /favicon.ico HTTP/1.1 -Request method made to access the page. Mostly the method is GET.
  6. HTTP/1.1 – Protocol.
  7. 404 – Status code.404 status code is for “Object not found”. Click here to see other status codes.
  8. 289 – Bytes transferred.
  9. Mozilla/5.0 (X11; U; Linux i686-Browser was used to access the web page & the operating system used.

Squid Logs

Squid is a proxy server which can be configured to pass/restrict sites for a particular domain. The squid logs give valuable information of workloads and performance. Besides storing the access information, it also stores system configuration errors and resource consumption (e.g., memory, disk space) values. A user can easily find squid log files in /var/log/squid. The logs available are

access.log (current)

access.log.0 (last week – uncompressed)

access.log.1.gz (week before and is compressed)

The common format of squid logs is

remotehost rfc931 authuser [date] “request” status bytes “referrer” “user_agent”

remotehost-Remote hostname or IP number.

rfc931-The username associated with the client connection, determined from an Ident (RFC 931) server running on the client host.By default Ident lookups are not made, but may be enabled with the ident_lookup option.

authuser-The username as which the user has authenticated himself. This is only available when using Access Authorization (password protected WWW pages).

[date & time]-Date and time of the request.

“request”-The request line exactly as it came from the client i.e., the file name, and the method used to retrieve it. GET in most of the cases

status-The HTTP status code returned to the client. Whether or not the file was successfully retrieved, and if not, what error message was returned.

bytes-The content-length of the document transferred.

“referrer”-The previous URL visited by the accessor

“user_agent”-Information about the browser used to access

Example of squid file is shown below.

  1. pglab39.pg.cc.md.us – - [13/Mar/1995:09:09:03 -0800] “GET /webcom/gstbk.html HTTP/1.0″ 200 35727 “http://www.webcom.com/cgi-bin/cust_sites” “Mozilla/3.0 (Win95; I)”
  2. pglab39.pg.cc.md.us – - [13/Mar/1995:09:17:18 -0800] “GET /webcom/gstbk.html HTTP/1.0″ 304 0 “/gstbk.html” “Mozilla/3.0 (Win95; I)”
  3. xroads.wr.usgs.gov – - [13/Mar/1995:09:17:53 -0800] “GET /webcom/order.html HTTP/1.0″ 200 2344 “” “Mozilla/3.0 (Macintosh; I; PPC)”
  4. 148.241.22.29 – - [13/Mar/1995:09:21:09 -0800] “GET /webcom/order.html HTTP/1.0″ 200 2344 “http://www.lycos.com/” “Mozilla/3.0Gold (Win95; U)”
  5. nameless.house.gov – - [13/Mar/1995:10:00:30 -0800] “GET /webcom/graphics/hp.gif HTTP/1.0″ 200 2690 “/order.html” “Mozilla/3.0 (Macintosh; I; PPC)”
  6. splitter.amnh.org – - [13/Mar/1995:10:01:10 -0800] “GET /webcom/order.html HTTP/1.0″ 200 2344 “http://www.webcom.com/” “Mozilla/3.0 (Win95; I)”

Now lets look at the first entry in the log file
pglab39.pg.cc.md.us – - [13/Mar/1995:09:09:03 -0800] “GET /webcom/gstbk.html HTTP/1.0″ 200 35727 “http://www.webcom.com/cgi-bin/cust_sites” “Mozilla/3.0 (Win95; I)”

In the given log

  1. pglab39.pg.cc.md.us- This represents the remote hostname.
  2. - – RFC 931 information.
  3. - – The third field is the username which was authenticated. Since there is no Access Authorization i.e. password protected pages so this field is blank.
  4. [13/Mar/1995:09:09:03 -0800]-Date and time when the page was accessed.
  5. “GET /webcom/gstbk.html HTTP/1.0″-Method which was used to retrieve the web page.
  6. 200 – The HTTP status code returned to the client. There are many other status code which are returned to the client.
  7. 35727 – Number of bytes which were transferred.
  8. “http://www.webcom.com/cgi-bin/cust_sites” – Last page which was accessed by the squid proxy server.
  9. “Mozilla/3.0 (Win95; I)”- Browser which was used to access the web page.

This was a very simple and brief discussion on how to interpret the Apache and Squid logs. This is just the first step in the journey towards mastering the art of log analysis.
Happy learning!

]]> http://niiconsulting.com/checkmate/2006/07/16/understanding-apache-and-squid-logs/feed/ 7 File Slack Vs RAM Slack Vs Drive Slack http://niiconsulting.com/checkmate/2006/06/21/file-slack-vs-ram-slack-vs-drive-slack/ http://niiconsulting.com/checkmate/2006/06/21/file-slack-vs-ram-slack-vs-drive-slack/#comments Wed, 21 Jun 2006 19:11:36 +0000 Chetan Gupta http://www.niiconsulting.com/checkmate/2006/06/file-slack-vs-ram-slack-vs-drive-slack/ by Chetan Gupta, NII Consulting

A small experiment…Create a new text file. Edit it using Notepad and type “Hello” in it. save and exit the editor. Right click the file and check its properties. Did you notice the two attributes “Size” and “Size on disk”. It looks something like this on my Windows XP system

Size: 5 bytes (5 bytes)

Size on disk: 4.00 KB (4,096 bytes)

Have you ever wondered why this difference? If the size of file contents is only 5 bytes, why are the remaining bytes assigned to the file? Do they serve any purpose? Well, atleast not to any average user of computer systems!

This is one thing that many people are confused about and forensic investigators like me are happy about!

The answer lies in the understanding of a simple jargon called “slack”. Associate the terms file, RAM and Drive with it, it becomes even more confusing!

All these terms look so similar yet understanding and appreciating the difference between them could be daunting task at times! Ill try to simplify the terms as much as possible.

File Slack

File sizes vary! Ok everybody knows that. But what may not be very widely known fact is that to store files, the filesystem uses fixed sized containers or blocks called Clusters. Clusters are nothing but groups of sectors which are used to allocate the disk storage space in Microsoft Operating Systems . So, any new file is assigned a number of clusters such that

file size <= no of clusters * size of a single cluster
Quite obviously, file sizes rarely match the size of one or multiple clusters perfectly. So what happens is that a small space is left between the end of the file contents and the end of the last cluster allocated to it. This space is called File Slack. File Slack is created at the time a file is saved to disk. File slack can be broken down into RAM Slack and Drive Slack. Let us define these two terms in detail.
RAM Slack

Lets add a little twist to the whole thing! Microsoft Windows based systems normally write in 512 byte blocks called Sectors. That means whenever the OS wishes to write to the file system, it would write in chunks of 512 bytes with a minimum of atleast 512 bytes. So, if there is not enough data to fill the last sector in the last cluster, the OS innocently writes random data from memory (RAM) to the unfilled area in the last sector. What if that area of memory contained something sensitive such as password for an encrypted disk or partition which had been mounted sometime in the past! The investigator in me is not complaining!

This area which is filled by the random data from the RAM is called RAM Slack.

Drive Slack

RAM slack pertains only to the last sector of a file. What about the remaining sectors which are a part of the last cluster assigned to the file but not filled with any file data. The OS doesnt take further pains like it did with the last sector to be written with file data. Instead it doesnt write anything to the remaining sectors of the cluster. The result? Whatever was stored on that area of the disk remains there and could contain remnants of previously deleted files or the pattern which should be there if the disk is fresh and being used for the first time or even the data which existed before the last format!
Welcome to the world of Drive Slack!

From a computer forensic viewpoint, file slack is very important as both a source of computer evidence and investigative leads. File slack can also be analyzed to identify prior uses of the subject computer and could contain fragments of email messages, word processing documents and any other sensitive data which may help nail the culprit!
Cyber criminals beware!

I hope I did manage to simplify the mystery to some extent!

Happy forensics!

]]> http://niiconsulting.com/checkmate/2006/06/21/file-slack-vs-ram-slack-vs-drive-slack/feed/ 8