How to handle Phishing emails

Hi-

This is one of those areas that is sort of a mystery to me. I use Thunderbird so I consider myself much better off than some people out there. Anyway, I get this note in my in box "Please update your records" from box says comcast, and the sender address says: yd61382322@comcast"dot"net

So, sparing no time and expense, I look up the email address to forward the thing to (abuse@comcast.net, if you want to know) and send it, innocently thinking I am doing my part to protect the happless user.

That evening I have a response from comcast. words to this effect: This letter does not appear to come from comcast.net This address is only for abuse from someone at comcast.net the address in the from box is usually forged, you have to read the address from the full address header. Now, they are starting to P me O!

First of all, this is obviously a scam directed at one of their customers (me), and the perpetrators are sullying the good name of comcast in the process. Now I don't know about you, but if I work for comcast, this is not the way I would respond to the incident!

Secondly, what do they mean full header? I use email, I did not invent it! Would it involve me actually opening the email? I thought that was considered a bad idea when you get a suspicious email! Which is it? Is it safe to open or not. If not then why is comcast suggesting that I do so instead of put the matter in their hands?

Okay, I did stray just a bit, but I actually am interested.

- Is it safe to open?

- where do I get the real address, if the address that I see appear to be forged?

- and finally, are these guys and comcast jerks, and should I file a complaint about the response I got?


-HandsOff

 

Hi HandsOff

Quote : Know that simply reading the text of an email is harmless
as long as you are not automatically opening or activating any attached files.

To view Headers etc.
Open the message
Click the File menu
Click Properties
Click the Details tab
Click Message Source
Highlight, copy and paste everything from this window

Probably of no use unless they are amateurs


Further info from these sites
http://spamcop.net/fom-serve/cache/19.html
http://www.bath.ac.uk/bucs/email/anatomy.shtml#headers

 

Would`t you also need TB to be set to view in plain text only, block images as well? Seems I have read that allowing of images etc. can now be dangerous. Of course we all know not to click on links in e mails, as this only verifies our existence to the sender, or open\execute attachments . Last I knew just opening of an e mail, with these settings in place was still safe.

 

My advice :
If you don't recognize the sender, just delete them without opening.

If you open them :
- use always text mode, not HTML mode, like ThunderZ suggested
- if you can't open them in text mode, don't touch anything.
- don't open any attachments of course
- never reply or unsubscribe, because you will get more spam-emails

If you want to report such emails, go ahead.

 

Thanks stapp for that additional information
Sorry for the late reply but I've just recovered from the BSOD

 

Sounds like someone at Comcast's abuse desk is working on autopilot.

Seriously, they probably get so many phishing emails (the spammers are probably stupid enough to include Comcast's abuse address on their list) that forwarding them on is of limited use.

A better idea is to sign up for a SpamCop reporting account (which is free, but paying subscribers get extra features). This will analyse the email headers to find the actual source and forward a report onto the ISP concerned. In addition, the source may be added to SpamCop's blocklist if enough spam is reported coming from it.

SpamCop has its limits (there are a lot of ISPs out there who don't seem to give a damn about compromised systems on their networks) but it is the best first step for dealing with spam and phishing emails.

 

Hi Handsoff,

Back in the old days, email viruses were jokes. The common wisdom was that you could not get a virus from opening an email. *sigh*. Oh for the good old days.

If you're not confident in your abilities, the best thing to do is simply delete the mail un-opened.

Mike

 

Hello,
Any email with "curious" subject or "curious" sender gets into trash, without too much thinking.
Mrk

 

However, like filtering, this does nothing to discourage the spammer/phisher from continuing to send further emails (or to work on more sophisticated ones). A better tactic with phishing emails is to visit the site and enter false details - or run a script to continually enter fakes.

 

I don't think this is sound advice for the casual user - only for the confident.

 

Depends on what is meant by "casual user" - if you mean someone who has virtually no net-savvy then I would agree, ignore and delete. However this won't stop further emails arriving in escalating quantities so those who want to work towards a more permanent solution (which does not involve changing email accounts) need to take more proactive measures.

The main risk with these sites is giving them real information. Forum members who have implemented basic security measures (switching from IE, using web filtering, etc) have little to fear by entering false details and making the phishers' work harder.

 

In thunderbird, just click view on the menu bar then headers and check all. you will see the full header information on your mail.

 

By "casual user" I mean that large chunk of users on the net who have not implemented the measures you speak of, that still run IE on their unpatched windows, use the version of Norton with the PC which has never updated, so they just turned it off because it's annoying

OK, I exaggerate, but you all know who I mean

The issue that I am most concerned about would be if you visited the phishing website and it was loaded up with exploits as well. Imagine going to do your civic duty, but then being infected by stealth and having your bank details stolen. If I were going to put together a phish, that's one of the treats I'd certainly include on my site, which is why I say that this sort of response is best performed by the prepared.

I agree with you that proactive measures are a great thing (and I noted your thread regarding the response script to spammers, which I think is great) - note that it's a trivial excercise to add IP logging to the webpage - filter by duplicate details and extract the data that you want so crapflooding their pages will not help.

If everyone just responded once by entering random details, taking care to put them in the right format for the bank in question, that would be most effective. But I still stick to my advice that people who aren't confident in what they are doing should just delete the mails.


Mike

 

Agreed there - though with the current crop of sites I'm seeing, the writer is so damn lazy they don't even bother changing the filenames. Makes it easy (less than a minute) for me to adjust my script though.

With automated retaliators, users can use proxies, in particular Tor which changes exit server every 10 minutes to counter this. It is still possible to filter/block by IP address and the spammers are certainly doing this in many cases - but they also risk losing "real" business with ISPs running users through a proxy server (AOL being a very notable example) and have to spend time maintaining blocklists.

Of course, the people that most need to resort to such measures are the least likely to have the expertise to do safely. Blue Security came close to an effective solution (close enough to get DDoS'ed) but this seems like a great opportunity for a security developer to supply a program that can run such retaliations against the biggest spammers. *nudge* *wink*

 

Believe me, when Blue Security went down, I did consider doing something there - but the risks outweighed the benefits at that time.

However, I would be very interested in adding a "Retaliator" function for Phishing emails into Online Armor. I just spent 45 mins on the phone discussing it with one of my partners.

Assumming the user Opts in and agrees to accept responsibility for sending the fake date to the phishing site, it would be great to know that *every* phishing email would be successful and receive at least as many hits with fake data as there were Online Armor users.

Initial thoughts are:

1) To randomly send a number of hits from each user (between 0 and 3 seems reasonable) to protect against the case where the user and online armor both respond - maybe this isnt such a good idea, and we should stick to 1 - because we have the webshield we could prevent the user from going to the phishing site. More thought needed.

2) To modify OA's mailshield to send the full mail (with headers) of phishing emails back to our central database for analysis. This would allow us to communicate with both the affected bank, and also the server that was hosting the site.

3) To make a realtime blocklist available somehow for inclusion in third-party web-proxies.

The main risks I see are:

1) Legal - collateral damage
Assuming the Phishing site is hosted on your compromised server, then a lot of OA clients coming to provide you with the data you asked for could cause a DDOS. If you owned the server, this would not be a bad thing and we could rely upon the argument that you invited the users to come and provide detail. However, since the sites are oft hosted on compromised third party servers there will be collateral damage. Personally speaking (not the view of Tall Emu) such collateral damage for me is acceptable on the basis that the sysadmin will at least become aware of an issue and investigate it. If my server fell over, and I saw lots of hits to a phishing site - I'd correct it. Additionally, the server being offline serves "the greater good" - I would not sue, provided that the moment the issue was resolved, the requests to the page promptly stopped.

2) Retaliation - DDOS
We're a small company, and OA is hardly on the top selling list. As a result our servers are unlikely to survive a directed DDOS attack... of course, we could add more servers, but this would increase costs - the net effect of which could certainly be the same as a DDOS. There's also the potential "9mm" retaliation to consider.

Aside from that, provided we got notification of the Phishing (hence the mail filter changes, also providing a way for others to notify us) it would be nice to know that the phishers would have to wade through "X" instances of invalid data in their system. If X is a large enough number, it becomes impractical to Phish. Then, I get shot




Mike

 

Automated Complaint System
The most "legal" option, this allows the user to choose, with a single click, to send a complaint to the ISP where the email originated, the ISP where the site is hosted and the domain registrar responsible for registering the domain (rather like SpamCop does now, though it does not cover the domain registrar). Since many spammers run their own DNS servers on compromised machines also, complaints to the ISP/registrar for the DNS server providing details on the phishing domain may be appropriate too.

"Stop spamming" Request
Fill in the fields with a "Don't spam me" request, rather like Blue Security did for persistent offenders. This could not be mistaken as a successful phish but if done in sufficient numbers, would cause extra work for the phisher plus bandwidth costs.

If only done once (or once per email) this could certainly be justified as a legitimate response but it would require site analysis and scripting (though it should be possible to identify new sites just by scanning the HTML - the phishers I see don't seem to bother changing it much). No personal details (like email address) should be given to avoid retaliation and the scripts for doing this could be made available as an "optional" extra (i.e. users would pay a small fee to cover extra download capacity and DDoS countermeasures).

Blue Security's option did allow users to submit such requests on behalf of others, allowing them to work around IP blocks which could be a useful feature.

Phlooding with Phakes
The highest level, submit forms with random but plausible data. Likely to be the most effective in causing pain but also needs to be either limited centrally or require user interaction (e.g. a click for each entry). Legal issues would need to be more carefully considered but it may be possible to seek the support of the bank concerned since this helps counter a threat to their business.

In Blue Security's case, they included the most heavily resourced spammers with the most to lose business-wise (the "online pharmacies") which likely explains the scale of the attack they received. Limiting action to phishers only may reduce possible retaliation (though they would have to have access or control of a botnet in the first place) but it would probably be inevitable (even non-retaliatory services like SpamGourmet get hit by botnets). As such, having a separate product/company/network may be the best option with everything as de-centralised as possible.

 

This is part of it - but, this part of things one would hope is taken care of well already by the bank security teams. Reporting back to the banks (possibly through OA to aggregate the reports) has some value, but doesn't really offer protection to users. However, this part of things should be an integral part of any solution.

If the Phisher is using a compromised machine, he's not worried about bandwidth costs. This option is probably the least desirable of all - it would slow down the phishing site, but depending on the data captured might end up being trivially easy to filter. It does have the advantage that it could be construed as a legitmate response to a mail, although by automating it we still run the risk of litigation should a server be downed as a result. Since there's still a litigation risk, you'd better hope to have done more damage to the phishing operation if you take that risk

This is the one I like. Lets say we have 2 million OA users - we receive a phish report - find the site - and the phisher gets 2M plausible-but-fake entries in their database. Regardless of who fell for the phish, we're providing to end-users on the basis that there is no logical way the Phisher can identify which responses are genuine in a short timeframe. (on the assumption that a massive automated login attempt might trigger warning flags at a bank).

Hopefully, prior to them figuring out which passwords are genuine the bank will be aware of the site and have it taken down, especially if we reported the site to the appropriate security team(s) at the bank(s) as soon as we became aware of it.

The inclusion of the bank is an interesting idea. Perhaps I am cynical, but if Joes Plumbing decided to sue - and quickly "Monster Bank Inc," said "Well, we're actually going to sue you for misuse of our trademarks, attempting to defraud our customers, etc, etc unless you drop this" then Joe would drop the suit quick smart, lest he be destroyed by the bank's legal team.

Unfortunately, I think the banks will baulk at the idea since they're cautious by nature.

If you have some central administration then it could be taken down. Unfortunately, you need centralised admin to avoid anarchy. It's a tough, but interesting call. I'd really like to do something with this at some point.

 

Depends on how network-savvy they are - the domain registrar may not seem an obvious point to complain to, but if successfully done it could take down dozens or hundreds of domains.

The key here is varying the wording of the request and including enough valid data (like state/Zip code where applicable) to pass any verification. Email addresses and names would be the best prospect here - like a Mr. DontSpamMe at devnull@phishersarelosers.com. If done right, this would be every bit as hard to filter as the option below.

Actual figures or wishful thinking?

There is also the scenario of the phisher trying to sell these details on and taking a reputation hit when the purchaser finds out how bad the data is. The problem area is emails - you don't want to list ones that may be in use but you don't want to make them too visiblly different either. The script I'm running includes a personname in the email for plausibility but (75% chance) adds 1-3 numbers to the end (e.g. bradley.john417@force9.co.uk). It has a 25% chance of not using numbers at all (so filtering on this criteria only won't work) so it reduces (but doesn't eliminate) the chance of a real email being used.

The only realistic lawsuit could come from someone whose server had been hijacked and it would seem that blaming the phisher (plus lack of security on their part) woud be a valid defence - you have no way of knowing whether they were a willing accomplice or not (though IANAL). However supplying some fake account details to the bank (or alternatively supplying fake accounts created by the bank) to allow the bank to track subsequent activity could pay dividends.

Well there are options like having the scripts hosted on a DDoS-resistant setup like Freenet (requesting a certain item of data repeatedly just results in more nodes caching it so increasing its availability) or Coral plus ensuring that the clients can run autonomously for a while. A P2P setup is another option but this has been discussed extensively for Okopipi.

 

For some reason, the thought of using the same dictionaries as the spammers tickles me pink. I mean, I receive messages from names such as Confidently. L. Outhouse - or one this morning from "Unnattractive Q. Faithfulness" - to use the same thing back as responses to phishes would be quite amusing. Or Maybe I'm just weird.

Sadly, wishful thinking.

Damn, that's a valid point. I read somewhere that the phishers typically onsell the data so if we could end up with a few Phishers getting burned onselling junk, that would be an excellent benefit.

Something like ebonanza@isp.com , DJOuthouse, etc... we can use the same technique... With apologies to Mr Toilet Q. Winningly, if he does in fact, exist

IANAL either - but I am not sure that ignorance is a valid defense. I would assume that a court could go either way on that one. In real life - What happens in the event you damage property in the process of preventing a crime, for example? In the age where robbers can sue their victims for falling down and hurting themselves it's a tough ask to believe that common sense will prevail.

Provision by banks of fake accounts would be fantastic, if they were sufficiently varied so that the list of fake accounts did not circulate.

Or, just get different infrastructre and plan to be DDOS'd - I saw a company promoting "Clean pipes" - but we could also work with our data center and their upstream providers as well. Better to prepare and not get slammed than the alternative.

Overall - I would like to do something here. I'm slightly concerned on the legal side of things, and I am also curious what doing something which amounts to vigilantism in some people's eyes might do to our reputation. I suspect, like pretty much anything, some people would love us for it and some would hate it - the question is where does the balance lie.

 

Warped sense of humour clearly. It would probably be better to choose names that aren't obviously artificial, otherwise filtering them (by eye) becomes easier.

If the site appears to be running from a hijacked system (and it isn't always easy to tell...) then obviously contacting the admin/ISP should be the first step (though they'd probably already be inundated with SpamCop reports). Aside from that though, the best bet would be to include some sort of backoff mechanism where the form-fill rate drops if the phishing-server doesn't respond.

That would be Prolexic - they are not cheap (hosting costs run into the thousands of dollars). Better to create an autonomous infrastructure where users could run independently for a while.

Well Blue Security had the same issue - though the hate mainly came from spammers rather than users. Given the attack by PharmaMaster though, I think more people will be prepared to look upon this as a war - with their ability to use email at stake. Limiting the active response to phishing sites only should help matters a lot here also since no-one can argue about them being legitimate businesses.

BTW, the Barclays Phishing thread at the Kill Spammers forum may be of interest as an example of a phishing retaliator though the URL will need updating (barclays.co.uk.brccontrol.taskstart.custbase.ferty.biz was still live at time of posting).

 

Heh, I just read your last post and it corresponds to the long conversation I just had with one of my partners (Hi Scott!)

Basically the main issue revolves around collateral damage to either the internet at large, or the hijacked server - who is liable, what about jurisdiction - are we responsible? What if the user is asked to click? What if the user accepts liability? What if the Bank got its big legal stick out too ?

A much simpler solution: Take great pains not to cause any damage. Don't just unleash a botnet. Don't make it retaliation. Don't try and knock the server offline - don't make it a free-for-all.

Assume even a basic webserver can handle 10 requests per second. That's 600 false pieces of data per minute. In an hour, we have 36,000 pieces of false data.

I'm not sure what the ratio of victims to fake data would be. Lets say that 100 people respond in the first hour? 100/36,000 = a bad ratio for the phisher.

Of course, the better hardware they steal - the more data we could pump at them. Now that the legal issue is out of the way we only have to worry about DDOS (yes, you're right, it was Prolexic) and 9mm issues.

Hmm... gets more compelling.


Mike

 

Oops! Outed!

This assumes that you can either centrally control the submission rate or the number of clients involved. If you instead tie the submission rate to the server response time (and the CPU/network limitations of the client PC), then the client can run independently.

If the client is also restricted to only acting on spam they receive then this adds another balance, the biggest spammers will receive the most attention - a proportionate response.

 

We considered that - but since it's trivial to change the site to log IP addresses and filter duplicates, then each client must submit one, and only one response.

Provided the quality of the details generation is sufficiently good, and the process of posting mimics a websurfer hitting the site then the fake responses should be indistinguishable from real responses. That's the objective as far as I can see (if we're talking about just phishing, that is).

Then it all comes down to the number of users in the network as to how many random bits of data get stuffed into the phish DB.

Since it's tightly controlled based on the central server, there should be no legal liability at all, although the central infrastructure is at risk of DDOS.

Again, for me the purpose is not to down the server but to make the collected data useless to the phisher. If we down the server, we've made a mistake.

With those principles in mind, I don't think the system could be really criticised.