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