Ruining a phising database

Ok MsM's post in the phising forum got me thinking. We have all seen these scams which pose as a legit company and ask you to enter your username/password into a form on a mockup site which appears to be the real thing.

But could we not help to protect the people who have been caught by such a form by ruining the phiser's database?

Ok these forms are normally seup to record all usernames/password combos which are entered into them - the phiser has no way of checking these against the actual sites database through the form so they do not know if they are real until they attempt to try them later on.

So what if we were to develop some sort of tool or script which sent thousands of false requests to this form - filling their database with junk - kinda like a bruteforce password cracker

ok imagine this script has 2 dictionary files 1. contains false logins 2. contains false passwords. Script sends theses in 1000's of combinations to script filling phiser's database with all these incorrect details.

Phiser can not tell which login details are our false ones and which ones are actual logins and has to chuck database meaning that the details of anyone who was actually caught is now hidden amongst all the junk.

could it work? does anyone with more scripting knowledge then me think they can put something together to do this?

v_Ln

hey very very good idea,once we locate te website of the phishing scamster we can brute fore the site with all kinds of false id and p/w
real nice suggestion !!!

Quote:

---

You have given out too many AntiPoints today, try again later.

---

#1 We have a phishing forum :D
#2 Phisher may be working on a zombie, you'd be attacking an innocent most likely.
#3 There are easier ways to stop a phishing server, like reporting it ;)

Where you'd report it, I don't know. There seem to be places popping up for that sort of thing lately, however I don't know if there's a standard yet.

Quote:

---

#2 Phisher may be working on a zombie, you'd be attacking an innocent most likely.

---

i dun think so .The data finally reaches into the hand of the phisher,now that he has the data he will not be able to make out the real data from the brute forced one .....isn't it ?

Quote:

---

#1 We have a phishing forum

---

yup aware of that fact - but as this post is more about the devlopment of said script I thought was best here or in programming secuirty ;)

Quote:

---

#2 Phisher may be working on a zombie, you'd be attacking an innocent most likely.

---

your not really attacking as such - yes enough of these false requests would make up a DDoS but really the only thing you are harming is the phisers database which the zombie isn't even going to be aware is on their PC.

Quote:

---

#3 There are easier ways to stop a phishing server, like reporting it

---

yup but what about all the people's details the phiser has already harvested? this way they would be burried under the non-sense usernames/passwords - am not saying this should be done instead of reporting it - but perhaps along with so the reporting gets it closed down - the script ruins what he already has.

v_Ln

I agree that it would be effective in ruining their database, however if the box were to be confiscated, how would you determine which rows are real and which were brute forced? You'd be screwing up potential evidence.

It's a very interesting idea regardless of the obvious problems, perhaps the application can be used in one of those IRC rooms where you can give and take CC #'s. I haven't used them myself so I don't know how the protocol works, but the same problems arise.

Quote:

---

however if the box were to be confiscated, how would you determine which rows are real and which were brute forced? You'd be screwing up potential evidence.

---

welll this is true,but as far as i think the cops have enough resources to verify the ID's add P/w's they can contact the concerned website and ask them to check it up ! .

Quote:

---

I agree that it would be effective in ruining their database, however if the box were to be confiscated, how would you determine which rows are real and which were brute forced? You'd be screwing up potential evidence

---

agreed - but if you were to supply the goverment department involved with the investigation the original dictionary files used in database flood they could easily search remove them.

the only problem then would be ensuring the department had access to those files.

v_Ln

but wouldnt ..the more crap they end up with in their DB.. the less chance of a legit victem being targeted..

the database in use would have to be huge to be useful, first thing I would be doing, if I was running this sort of scam, is eliminating duplicates and obvious false entries like
u/n fa king wan kers
p/w ****off*******s
could these boxes also be logging IP's, this would make a script attck less effective.. see my comment regarding eliminating dups, and sus entries..
many of these sites forward you on to the legit site after getting your details.. so your script would need to keep reopening the scamm page..

are these fair consideration? I thought it was an excellent idea at first..

hmmmm fair point Und3ertak3r - the first points about the un/pass being believable i had thought of thats why i suggested a dictionary based attack rather than random characters. But the Ip could pose a problem - If they do record the IP's of attempts they would know straight away if 1000's of requests all came from the same IP.

Only thing I can think of is using a database of proxy servers so each attempt seems to come form a different IP but then you would need a different proxy for each attempt which would make your proxy list huge and could also slow down the effectiveness of the attack.

Or a DDoS type attack where 1000's of users are assigned a fake un/pass combo which is then used for that attack - this would need to be done in a SETI@home style distributed system where when a new scam site is found it is entered into the database for attack and as each user on the network connects to the net they recieve the address of current sites for attack and the un/pass to use on each. Thus providing a single IP for each attempt.

The second method I think would be the most effective but that would be a huge task

1. Developing a complex distributed attack system
2. Maintaining it so is kept current with sites to attack
3. Getting enough users involved to make it effective

v_Ln

Interesting concepts and ideas. That puts us in the business of doing greyhat work, but sometimes I think that the trends in the network may force that. Val's thought that it would be a huge task is valid. However, the task of educating users to not fall for phishing (biting the hook, as it were), open virus-infected email, and use better security and passwords has proven to be monumental and damn near impossible to accomplish.

So, that leaves us with trying to find something more doable, proactive and all, huge as it may seem.

As for me, I'm getting my graphite fly rod all preened up, new line, leader and tippet, new bugs. I'm going after the really tasty fish. ;)

Quote:

---

Hats are obvious, behavior isn't. And what is white to one person may be gray to another.
--Gene Spafford

---

I just used this and it was still in the clipboard. :D

I see several ways to make this work. I like the idea, just as I liked the idea of the Lycos screensaver performing near-DDoS attacks against spam companies. Would I participate? Probably not.

However, some points, and possible solutions, to what I've seen so far.

IP blacklisted by phisher = c'mon guys, there are tools all over to fix this. TOR from the EFF is one of them. Also...who says it has to be a real IP? Hack the packet headers...depending on the phishers web page and source validation, this may not even be an issue.

Bogus entry filtering = you'll have to use some common sense when populating your dictionaries. Fa King Wanker is probably gonna get past a filter, whereas ****OFF YOU***** probably won't. Undertaker mentioned these would get caught...if the database is big enough, do you REALLY think a phisher is gonna check it by hand? Hell no. Scripts and filters...so write your dictionary with that in mind.

Rate of submission = write your script so it varies how often it sends the info. Then you aren't spamming the phishers DB (hmmm...spam...notice any trends in my suggestions?) This also has more to do with the possibility that the phisher is using a zombie. If you slow down the rate to a reasonable level and avoid a DoS, then you aren't impacting the zombie-victim as much.

Integrity of evidence = I don't think this is much of a concern. If the US Attorney (or whomever happens to get one of these cases developed to the point of actually seeing a jury) has a case that hinges so determindly on the integrity of the DB contents...they've already lost that case. They will be concerned with things like Intent to Defraud, Intent to Steal, Intent to Impersonate, etc. What data the suspects collect will be of value...but not definitive to the case. Trust me...I've worked enough of these to know.

Caveat Haxor I can not vouch for the legality of any of these options in your, or any other, jurisdiction.

well what are the chances that the phisher takes us to the court on spaming,populating and spoiling his data base of phished coustomers ???