How Do I Fight Russian Site Cloners?
An anonymous reader writes "I used to run a small web design service, the domain for which I allowed to expire after years of non-use. A few weeks ago, I noticed that my old site was back online at the old domain. The site-cloners are now using my old email addresses to gain access to old third-party web services accounts (invoicing tools, etc.) and are fraudulently billing my clients for years of services. I've contacted the Russian site host, PayPal, and the invoicing service. What more can I do? Can I fight back?"
check the dns domain registrar of theirs and report domain abuse.
that's what whois information is about too.
Yes!! You've hit on the perfect answer. Hindsight and a time machine can solve any problem. Bravo!
I didn't immediately think "insider" but now you mention it... it makes total sense of a very unbelievable story.
Oh well yet another story that doesn't pass a reality check, and in good kdawson fashion no supporting links or so. Here we go:
The fraudsters copied the web site (that was presumably off-line for a long time). Trivial if it is all static pages, not trivial to impossible if it includes a lot of server-side scripting and you do not have access to the server directly. And quite unlikely that a web site is copied and kept archived by would-be fraudsters hoping that in the future the owner lets the domain expire so they can bring it back on-line? No. It just doesn't happen.
Then they need to know which third-party services you used. And that you were so trusting that you use a third-party web service for invoicing in the first place.
Then they know your clients (potentially through the third-party invoice service).
Then they have your passwords (I may assume password protection).
And how come your old accounts at those invoicing services are still accessible in the first place? From the fact that you let your domain expire after "years of non-use" I take it your business has closed years ago too. Third-party web services usually require payment, especially specialised stuff like invoicing. Not likely they keep that active without it being paid for.
So Russian hackers? No. Insider job? That's where you should look first indeed. Start with former employees I'd say.
The cloners are not trying to recreate your business--they just have to make it look like the business still has an active website. Then they use the emails that they now control to get back into old accounts.
As for knowing which third-party services were used, there may be some indication on the archived site or there may be something available with enough googling--maybe they find a former client from a "site design by..." tag and social engineer some answers out of them (they don't have to be an insider or client themselves...they just use your old email address and ask a former client). There can't be that many providers of some of these services that were active when the business was running and are still active now...just start using lost password forms.
They might have to reinstate your old payments, but a few months of invoicing service is a drop in the bucket compared to what they could then invoice your clients for (and bigger corporate customers might not ask questions before cutting a check to a company already in the system).
Bottles.
This is the fundamental thing to take away from this incident, and, while it may be obvious, it deserves stating plainly:
Domain control / email address control is an authentication tool.
We've brushed by the concept in prior conversations about validating new user sign-ups.
Implications include, as in this scenario, human verification by looking at a web page of a familiar domain, human verification by email correspondence with a familiar email address, and password resetting when in control of an email address; SSL certificate-based identity (if the decrypted certificate can also be acquired), URL -referenced data validity (executables for download), and probably a number of other authentication/control mechanisms reliant on domain/address -- your ideas are solicited.
DNS hijacking, then, should be a serious concern. DJB warned about cache poisoning via brute-force source port + transaction ID spoofing in 1999. A long time went by before the issue got enough publicity (in 2008) to force the major DNS software purveyors to clean up their acts. This guy needs to be taken seriously.