Phishy Forensics

[tonybradley]

I am looking for information to use for a project I am doing:

Does anyone have any experience or insight into how they would go about investigating a phishing incident? I am not referring to the normal spam sent to the general population with a link to a phishing site. I am referring to a targeted phishing attack, where an attacker sends an email to employees of a specific company and creates a spoofed web site- possibly mocking their internal intranet web site somehow- in order to trick employees into surrendering their usernames and passwords so the attacker can gain access to the company network for other malicious means.

Since this is hypothetical, I can't give you a solid answer on what the network looks like. Assume they have a firewall between them and the outside world. But, what flaws or vulnerabilities would need to exist for an attacker to spoof email to employees so that it appears to come from the company's own tech support? What flaws or vulnerabilities would need to exist for an attacker to spoof an intranet web site or convince users that their malicious web site was legitimate?

Lastly, after such an attack is discovered, what logs or applications would you review to perform a forensic investigation and trace the source of the attacks?

[SirDice]

Spoofing e-mail is simple as you probably know.. Something like "Support" <support@company.com> or "Helpdesk" <helpdesk@company.com> as the senders address will probably trick a lot of users...

As for spoofing the intra/Internet sites.. A lot of companies put their housestyle guidelines (type of fonts, logos, colors etc.) on their websites.. They don't realise how valuable this information is for phishers

Hypothetical there are no flaws or vulnerabilities needed

As for investigating after the fact.. a couple of original phishing e-mails with the full headers should be enough to trace where they came from..

[Tiger Shark]

I have some thoughts.....

1. The outsider should not know what the Intranet site looks like... There should be no external access to it.

2. The first flaw would be letting any outsider have access to either the intranet site or an image of it.

3. The intranet site should be entirely different in design, colors etc. than any publicly accessible web site related to the organization - it's easier to fool someone if the two sites look similar.

4. It's easy to fool the user into believing that the email came from their administrator. I get numerous calls a week from people asking me why I am disabling their email account. It's one of the viruses going round..... No matter how many times I tell them they still call me or forward it to me..... You just need to use OE and change the name to display on the outbound email. That fools 99% of the users.

5. Once you have convinced the user that the email came from the organizations tech support it's trivial to place a link that states intranet.mycompany.com when it really points to xxx.xxx.xxx.xxx somewhere out on the internet.

6. This is a biggie..... Do not let users use the same login and password on an intranet or any other asset as they do for domain access.... Duh!!!

7. Even bigger.... Why have anything publicly accessible that anyone can log in to that is within your trusted domain?

8. Dual Authentication prevents this attack. Make the users who need external access to internal assets authenticate to a VPN where you provide them with a username and password that does not reflect their username and password within the domain. Then make them authenticate again to the domain to gain access to it with their normal username and password.

9. Strictly limit the number of people that can access via VPN. The less people that can the lower the chances of the attacker getting an authentication pair that actually works at the VPN gateway.

10. Since the email that was spoofed would almost certainly have been sent from somewhere other than the attackers home IP and the web site was redirected to a site that the attacker pwns rather than his personal web page a forensic investigation isn't going to turn up much unless you are the federal government - or you can get them involved because your loss was sufficient to interest them.

11. Do not use windows authentication to allow access to an Intranet site - everyone knows what it looks like and it can be easily spoofed.

In short, the mechanics of the attack are trivial. The "art" of the attack is based entirely on the mistakes made by the administrators that leak the vital information required to pull off the social engineering followed by the other mistakes made that would allow such a trivial exploitation be effective within the trusted domain from the public network.

Hopefully that gives you some things to mull over....

[thehorse13]

would need to exist for an attacker to spoof email to employees so that it appears to come from the company's own tech support?

Very simple. Relay SMTP mail off the SMTP server. This is the ol' telnet to port 25 on the SMTP box then issuing the commands manually. Also, this can be done with a packaged SMTP engine and scripted on the infected host. I see this crap all the time. Very simple to spot.

I am referring to a targeted phishing attack, where an attacker sends an email to employees of a specific company and creates a spoofed web site- possibly mocking their internal intranet web site somehow- in order to trick employees into surrendering their usernames and passwords so the attacker can gain access to the company network for other malicious means.

Again, simple stuff. Run a webserver (duplicating the format just like a phishing scam does) on a compromised host and have a keylogger or any other data scraper running and every so often pop off an e-mail to a hotmail account. Typically they wont use protocols they know are egress filtered. They will (if they're smart) hide the data transfer in the white noise of normal network traffic (such as http or ssl). I wouldn't be surprised if the setup is from a malware library. There are many canned malware setups just like this all over the net.

What flaws or vulnerabilities would need to exist for an attacker to spoof an intranet web site or convince users that their malicious web site was legitimate?

None. Most phishes rely on the end user buying the look and feel of the site. They'll use simple features of whatever helper code they're running to hide the real IP (java, html, php, etc). A lot of times, the compromised site will have links to the real site it's mocking and literally only one link or action will be handled by the attacker. All the rest will simply redirect to the real site. Again, very common.

Lastly, after such an attack is discovered, what logs or applications would you review to perform a forensic investigation and trace the source of the attacks?

Without specifics, I can't be of much help. However, every forensic investigation starts just like a police investigation. Interview the victims and establish a window of opportunity. At that point, use tools such as NetAnalysis to look at all the web histories to see where when and how the user browsed the site. You can also look at the index.dat file and the ntuser.dat file (have to go behind the windows API to read ntuser.dat) and sift through the goodies. You may find the e-mail that gives away how the host was seeded.

The places to look are endless. I always check the uninstall reg key just to see if something was installed then removed to hide the seeding of malware, etc. Also look at the win event logs (duh) dr watson error messages, AV quaranteens, firewall logs IIS logs if you are lucky enough to find the server. If it's outside of your network, look at the perimeter FW logs. Also, if this was a DNS redirect, peek at the host file for a poisoned entry, check the DNS server to be sure its not poisoned and also look at the network settings on the host to be sure its not offloading lookups to a rouge DNS server. The routes of investigation are endless and specific to each case. This is a broad stroke across a blind amount of info you've provided. Sorry I can't do better without the exact details.


And finally, there are folks out there who chain vulnerabilities so a few small problems become one huge one. This is another way that they can force down activeX controls, etc to the poor end user. Again, without case specifics, no one here can pinpoint the proper route to go.
PS

This sounds a little more like a real life case than an exercise.

--TH13

[Soda_Popinsky]

I'd wait for a browser based exploit to spoof the URL... Then being a designer myself I'd put together a site that just looks professional, with publicly available graphics and whatnot. It doesn't have to be accurate, just convincing.

"Welcome to the new employee self service web page! Please activate your account with your RSA credentials"

Lastly, after such an attack is discovered, what logs or applications would you review to perform a forensic investigation and trace the source of the attacks?

I'd be interested in how accurate the phishing attempt is. If your intranet is strikingly different than your public site, and it was imitated almost 1 to 1 in terms of design with some phishing content... then you have an insider.

As far as spoofing email and such... good luck. Open relays exist all over that allow it, and those relevant logs would exist elsewhere (the relays). I'd go where the phishing goodies went, like the form's action URL used to submit the data to a geocities setup (or whatever). You'd need cooperation from the third parties, geocities, open relay (good luck)... Phishing doesn't exploit much other than human behavior, so there isn't much of an audit trail (where you want it).

Now if you're dealing with malware, exploits, whatever... then you're talking DNS, pharming, host files... that's some tangible stuff you can do forensics on. Otherwise pick up the phone...

[thehorse13]

Soda just reminded me of something. Thanks by the way.

If you find yourself in a position where you need to gather ISP logs, you better become very familiar with 2703(d). If you can't execute this, you're about done.

http://www4.law.cornell.edu/uscode/h...3----000-.html

--TH13

[browolf]

this i read today might interest you
http://www.theregister.co.uk/2005/12..._virus_attack/