Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: Ruining a phising database

  1. #11
    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.

  2. #12
    AO Senior Cow-beller
    Moderator
    zencoder's Avatar
    Join Date
    Dec 2004
    Location
    Mountain standard tribe.
    Posts
    1,177
    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.

    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.
    "Data is not necessarily information. Information does not necessarily lead to knowledge. And knowledge is not always sufficient to discover truth and breed wisdom." --Spaf
    Anyone who is capable of getting themselves made president should on no account be allowed to do the job. --Douglas Adams (1952-2001)
    "...people find it far easier to forgive others for being wrong than being right." - Albus Percival Wulfric Brian Dumbledore

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •