Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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
