Suspicious activity

reputation

[Kendo]

Last few days I have been suffering a deluge of attempts to create new subscriptions. At first I thought that a useless plight, but then realised that each new member gets an email to click a link and validate their intention. So perhaps they are reporting those emails as spam to ruin my reputation. Have staved off those attempts by using a hidden input field but it won't be long before they catch on.

In the meantime I have been researching fingerprinting to prevent bot activity at web forms.

Being in a more than suspicious mood, I noticed something peculiar in my custom logs that track search engine referrals. I discovered this by accident because it found "foo" in the referrer as part of "footer". For example the referrer was logged as:

example.com/banners/footer/go.asp?url=youtube.com/watch?v=example

But the link that was used was <a href="#" title="example.com/banners/footer/go.asp?url=youtube.com/watch?v=example">

Now the strange thing is that link will not work at all because go.asp does not exist on example.com and only produces a 404. However if I visit the YouTube link I see a video about pill supplements.

The hits are being recorded as visits to the home page of example.com and becoming more frequent.... today they comprise 1 in every 6-7 visits from search referrals. IP addresses are random.

Anyone seen this type of activity before?

[thecoalman]

I would presume the links are referral spam. If example.com is not your domain then it probably had the exploitable script in the past. If it is your domain then /banners/footer/go.asp is probably a common exploitable script. By using a redirect script you might miss the fact it's going to Youtube and click it.... Could just be they are hoping you copy and paste the URL for the video. <wink>

Most of the spam accounts on my forum are Gmail. Quick tip in case you are unaware, periods are not considered by Gmail. [e-mail], [e-mail], [e-mail] and any other variants are all the same email account. Anything with plus is also same account, e.g. [e-mail] Lastly [e-mail] and [e-mail] are also same account. I allow any form but check for and reject duplicate variants.

Have staved off those attempts by using a hidden input field but it won't be long before they catch on.

If it's common script you are using this might be the most effective thing you can do. For example on phpBB forum something that was highly effective was checking the submitted timezone. Since the post data was scripted they were just using the first selection which was UTC-00:00, conveniently uninhabitable. For this to be legitimate user they would have to change the default to somewhere no one can live.

[Kendo]

Beats me. /banners/footer/go.asp may have been used more than 10 years ago to display banners in page footers.

The links are useless as the redirect doesn't work and the # link is merely a placeholder for a title tag. The links do vary, most going to a different video YouTube video about pill supplements.

[lucy24]

IP addresses are random.

What about other elements, such as headers or UA? At any given time, I've got about half a dozen seemingly benign UAs blocked as botnet_agent (self-explanatory name).

[Kendo]

The visitors following that link, which may be redirection by my site for a 404, seem to be unique.

[Kendo]

In the meantime I have been researching fingerprinting to prevent bot activity at web forms

I did a lot of testing and found fingerprintjs the best all round that is free. They have a Pro version but the free version has everything needed.

I started by logging all "wp-" and "xmlrpc.php " requests on our main site. We don't use PHP or WordPress on that site so such requests are not welcome. At first I recorded the fingerprint to cookie (uses JS) to retrieve it server-side using ASP and log it. But what I found was that only my own tests were using cookies. Then I changed method to add the fingerprint to a hidden text field and auto-submit a form to log the results. Again, no fingerprint was recorded other than my own tests, but for one individual.

IP address was ignored because all requests were rotating IP address. However none seem to rotate user-agent.

Conclusion:

Fingerprinting is absolutely useless for logging bots. These bots are either spoofing user-agent, using an old browser, disabling cookies, disabling JavaScript, or are basic GET requests with no browser support at all. Only modern web browsers with JavaScript enabled can be "fingerprinted".

To prevent spamming at contact and signup forms, the best we can do simply, is check for a fingerprint and if none, prevent form submission and instead display a message like "You need to use a modern browser with JavaScript enabled to access this web site".