on Sep 12 in IT, The Internet tagged disclaimer, howto, long, phishing, rogue by Chris
I realize that we’re probably going to get flagged for this big-time, but just to clear things up: this may not necessarily be strictly for malicious purposes, nor is it intended to be (the full disclaimer is at the end of this article). This is a simple guide for setting up a phishing website using strictly free software, intended as both educational and even useful in some circumstances.
The Required Software
We will be using this software for this guide:
- The Apache Websever
- Optional: DNS Server Software, e.g. BIND or PowerDNS
Apache Configuration
The crux of this tutorial centers around configuring Apache to “be” a certain website. For this example, we want to masquerade as Google. The first step is to configure Apache to pretend to be the site we wish to masquerade as, from the machine destined to be the phishing server.
The Apache master host configuration file (which is the traditional/deprecated httpd.conf within your installation directory) should have sections such as this for each website you wish to masquerade as:
(note that the paths are relative to a Unix/Linux installation; modify them for your system; comments are everything after the ‘#’ character for clarification)
NameVirtualHost: *:80 # Any hostname/IP, TCP port 80 (default for HTTP) # Virtual Host delimiter, e.g. a website under this installation ServerName www.google.com # main website name ServerAlias google.com google.com. www.google.com. *.google.com # Any other name for Google.com DocumentRoot /var/www/google # where the fake website's pages are stored # Per-directory configuration directives Options FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all # we phish for anyone, you could modify this for only select hosts, however CustomLog /var/log/apache2/google.log combined # log the visits to the fake website With Apache’s httpd.conf containing that, and optionally some other Apache optimization within the other configuration files, a service restart will make the fake site (Google in this case) “live”, but without any content or visitors.
Appearing as the intended site
In our configuration file, we told Apache that any requests for “Google.com” from our server should be directed to the “/var/www/google” directory for content (which should be empty). In order to appear as Google to the visitors we wish to phish, we need Google’s content within this directory.
The easiest way to retrieve content from the existing website is via the “wget” command, which is standard on Linux/Unix installations (Windows users can simply visit the page and save it directly to the content folder instead). For our example, our wget command:
user@Phisher:/var/www/google$ wget -O index.html http://www.google.com/
…would retrieve Google’s home page and store it within the file index.html within the content directory used by Apache2 for requests made to “Google.com” to our server. Keep in mind that “index.html” is (by default) the file sent to the users’ browser when a request is made to the root directory ‘/’ of a site.
Tailoring
Before we get to the step of directing users to our Google.com instead of Google’s Google.com, we should modify the site’s content so we can retrieve (phish) the content we want.
This is where this could easily turn malicious, and I would like to remind you, dear non-malicious reader, of the extensive disclaimer at the end of this article.
As a non-malicious example, we will pretend we are a parent seeking to monitor Google searches from a network of children (a very probable and applicable scenario). All that is required is a little modification of the index.html file, and/or creation of a Google-compliant search.php file.
Although the access logs for the server would suffice (providing IP information to identify the searcher), you will still probably want to return real Google results so as to convince the visitors that this is the real Google website.
Modifying the “form” HTML element to point to an alternative search processing file may be necessary, while in most cases it would suffice to create your own “search.php” file (with the Apache PHP module installed) to process search queries and retrieve results from Google.
Easiest way to retrieve search queries from Google is probably to pass the query string from your phishing site’s search.php as HTTP POST data to http://www.scroogle.org/cgi-bin/nbbw.cgi, and using some simple XML parsing and formatting to present the results in a results page that exactly mimics Google’s.
That last bit requires a bit of PHP/Perl programming skill (over the head of most parents I know), and represents the biggest challenge in phishing: changing the pages to get what you want.
Redirecting Visitors To Your Site
At this stage, your Apache server installation should be set up and ready to serve up requests aimed for the site you’re masquerading as, and it the content for the site should be filled with content that looks exactly like the real site, only providing you with the data the user thinks they are entering on the real site.
Now, for the process of sending users to your site instead of the real one: simple DNS manipulation.
DNS Re-cap: The Internet’s DNS (Domain Name System) is the process of translating a domain name (e.g. Google.com) into a routable IP Address, e.g. 70.89.148.9 or 192.168.3.1. As Apache’s virtual host system permits, multiple domain names can resolve to the same IP Address for the serving of separate web (HTTP) content.
In short, you need to make your target machines manually resolve “Google.com” (as in our example) to the IP address of your phishing server.
This means that you can’t make the entire Internet redirect a given domain name to your site, at least not without severe and easily-detectable DNS hijacking. Instead, you should focus on your target set of hosts, i.e. the children in our parenting example we explained earlier.
To do this manually, you must modify the host file of each system. The host file is a manually-editable “database” of domain names and their corresponding IP addresses, and takes authority over DNS queries to a remote system.
On Windows systems, this file is located at “C:\Windows\System32\drivers\etc\hosts”, and on Linux/Unix/Macintosh systems this file is at “/etc/hosts”. The format is extremely basic, with examples in both as to how to statically enter DNS entries.
On Windows systems, after entering this information, it is necessary to execute the command “ipconfig -flushdns” to clear the memory-cached DNS resolution entries so the new changes can take effect.
While this method works, it is not practical for, says, 5-100 hosts. In that case, it is then necessary to simply add a real DNS server to the network using one of the free tools mentioned above. I won’t go into detail as to configuring an individual piece of DNS server software to resolve a domain to your phishing server’s IP (RTFM), but I will tell how to make the server’s resolutions take effect for the whole network.
Most networks, especially those within homes, have a DHCP server, many times integrated into their router. Simply place the IP Address of your new rogue DNS server (presumably the same as your web server) to the top of the list of DNS servers within your DHCP parameters, and following the next renewal, your server will take the top authority for DNS resolutions for your network (other than the host file).
There is also a way to, using a *nix router, manually route all traffic to a host for processing – see theUpside-down-ternet page for these details (and for a guide to dick around with wardrivers).
What you’ve done…
…is this: everytime someone requests (in this example) Google.com, either a rogue DNS server you set up or a host’s host file will resolve the domain name to the IP address of your phishing server, which will accept the request and serve up content from a directory containing content that appears as the targeted site, only with some other purpose for your benefit.
There may be other ways to set this up, but this is certainly the fastest. Keep in mind that if your server goes down, all queries will still go to the real site unless you de-listed all DNS servers except the rogue one you set up.
Other Suggestions
Instead of drastically modifying the content for your site, for example if you wish to simply have a static web history via access logs, then you could simply make your rogue DNS server (via wildcards) resolve alltraffic to your phishing server, which simply retrieves the target content via wget and serves it to the client.
To accomplish this proxy solution, you would need to modify the VirtualHost directive to make the 404 (not found) error page the same page as the “index.php” page, which calls and processes the wget script (I recommend using stdout to redirect the content from wget to the browser as opposed to saving every piece of content to a file before serving it)
Also, please note that none of this guide applies to secure (HTTPS) websites. HTTPS communication takes place on port 443 instead of port 80, and there is a solid authentication process for verifying secure sites as opposed to insecure sites.
* Disclaimer *
Don’t use this guide for malicious purposes, despite how easily this guide could be adopted for such goals. The example I used throughout the article was for a parent wishing to monitor children’s Google searches, and as such any possible malicious purposes are not in any way implied.
We have no affiliation with Google, inc. We simply used their site as an example to phish because they are very popular and a parent may wish to monitor a child’s Google activity, realistically.
If you get detained for phishing, or any other criminal activity for that matter, then the mere visit to this page does not place any of the blame on us: you chose to do whatever you did based on your own decision.
This guide is educational only, and should not be interpreted as an invitation to violate one’s privacy.
Don’t be a jerk.
No comments:
Post a Comment