News for hackers. Stuff that matters.
Re:It is not possible to detect and block Chrome headless by adrr on Thursday January 18, 2018 @02:41PM (#16180600)
Poisoning the well is very effective. We employed it at a large ecommerce company that was getting hit by carders testing credit cards on low price point items(sub $5). We were playing cat and mouse with them for six months. Found certain attributes about the browser that the botnet was using and fed them randomized success/fail responses. After two weeks of feeding them bad data, they left and never came back. They did DDOS us though in retaliation.
Re:It is not possible to detect and block Chrome headless by dsacco on Thursday January 18, 2018 @03:21PM (#16180983)
I think this is a good example of "poisoning the well" in practice, and I was in a similar position as you describe when I was working in incident response at a consumer bank a few years ago.

That said, this is a very particular scenario, and I don't think you can generalize the effectiveness of the technique from this example. In situations where attackers are looking for boolean responses, i.e. to verify email addresses, credit cards, usernames, etc, this can work well.

But in most situations a crawler is looking for particular data. Moreover, it will have a strong expectation (and understanding) about what this data should look like. Poisoning the well is not going to work as well in that scenario, because a scraper will be aware that the data is incorrect.

In contrast, people testing credit cards don't need your data, they just need data from somewhere that verifies the card numbers. In that case it's easier to just keep rotating targets until they've tested all the cards instead of bootstrapping an in-house team to write bespoke crawlers.

Re:It is not possible to detect and block Chrome headless by civilian on Thursday January 18, 2018 @11:23PM (#16184135)
Man. I really like that idea, but is giving a random "success" to a supposed credit card charge PCI compliant?
Re:It is not possible to detect and block Chrome headless by linkregister on Friday January 19, 2018 @02:19AM (#16184655)
PCI is largely misunderstood. Spoofing a success on a transaction has nothing to do with proper storage and transmission of credit card information.

Most e-commerce sites will use a payment processor such as Braintree or Stripe so they don't even have to deal with PCI.

PCI applies to entities who store and process their own payments, e.g. Target, Amazon.

Re:It is not possible to detect and block Chrome headless by adrr on Friday January 19, 2018 @09:35PM (#16191726)
PCI doesn't care about what i return to the customer. It covers protecting the card number. It could be in the merchant agreement but most of those rules are never enforced. Its against card brand rules to require a person to show an ID but all merchants do it. Merchant account agreement requires you to prevent fraudulent purchases and that part is heavily enforced which is why the card brands turn a blind eye to the merchants asking for an ID.
Re:It is not possible to detect and block Chrome headless by stryk on Thursday January 18, 2018 @11:26PM (#16184145)
The whole cat and mouse game thing... for some strange reason that sounds fun to me. Probably because I don't know the details and the workload involved in actually doing it (and it's not my money or inventory at stake). It seems like it would be exciting, in that somewhat naive juvenile-ish fantasy sort of way, to try and figure out how to mitigate the threat, implement it quickly, and deploy it to watch it play out in real time on live production servers. I don't know, maybe I have the wrong idea about the whole thing?
Re:It is not possible to detect and block Chrome headless by _jal on Friday January 19, 2018 @12:20AM (#16184305)
There are aspects that are fun, but I feel like if you're doing it right, it is stressful. You are playing an antagonistic game with bad actors, so there's risk, and you'd better be well past just gaming out the probabilities and costs there. Just because you noticed them doesn't mean they can't do damage. You'd also better get informed buy-in from other relevant departments, etc.

Quite a while ago, I was involved in baiting an attacker in a somewhat different way, but with the same goal (destroying the value we were providing to them). After the attacker figured out what was going on, they issued a somewhat credible threat to damage the company's machines (they included some details demonstrating they had access to a couple internal machines at some point), attacked and DOSed them, and persistently tried spearphishing them for months afterwards.

I guess I'd just say, (a) doing this sort of thing responsibly sucks a lot of the fun out of it, and (b) don't underestimate the risks of things going pear-shaped. You could be buying yourself a lot of ongoing grief. Something as everyday as that spearphishing attack can be nerve wracking - even after making annoying the crap out of everyone by repeating how to be careful with email, there's no way to be sure it won't hit, and the next thing you know people are sitting around with upper management having conversations nobody wants to have about network segmentation and damage mitigation.

Re:It is not possible to detect and block Chrome headless by Washuu on Thursday January 18, 2018 @11:58PM (#16184236)
It is incredibly fun. I set up a Google Voice number specifically for site content managers to call me when comment/review spammers came around. I was fast enough at blocking spammers repeated attempts at evading registration blocking(email domains, IP address ranges, browser disguising) that I would usually make the spammers give up within an hour.
Re:It is not possible to detect and block Chrome headless by anonytrary on Friday January 19, 2018 @12:13AM (#16184282)
Your comment is why I feel automating engineers would be very hard. Cat and mouse game sounds like it requires a human... and a cat... and a mouse...
Re:It is not possible to detect and block Chrome headless by systoll on Friday January 19, 2018 @10:36AM (#16186959)
GANs are an automated ‘cat and mouse game’

https://en.m.wikipedia.org/wiki/Generative_adversarial_netwo...

Re:It is not possible to detect and block Chrome headless by anonytrary on Saturday January 20, 2018 @12:43AM (#16192251)
Indeed, I was going to mention those, but I feel there is an element missing from even GANs that we don't quite have yet.
Re:It is not possible to detect and block Chrome headless by imiric on Thursday January 18, 2018 @03:56PM (#16181368)
It's interesting that it came down to actual virtual warfare.

Good on you for sticking through it.