I just thought the maintainers might want to know that I've had lots of spam registrations lately all with email addresses at the domain drupaler.org, which is a bit concerning. There's no website at www.drupaler.org so I'm not sure if this was ever a legitimate Drupal-related site. I've cancelled all those users in my site and blacklisted the domain in my Mollom account.

Comments

eshta’s picture

Hi there - thanks for the notification. I've alerted the engineering team and they will look into it as a pattern across Mollom users. With the holidays upon us this may take a little time. In the meantime, you were absolutely correct to utilize the blacklist functionality for this.

kopeboy’s picture

This is not only related to Mollom..

I have CloudFlare protection and Honeypot but still I get fake users registering on my site, all of them have @drupaler.org emails (all other spammers get blocked), and the weird thing is that they don't spam! They just register... wtf?

I guess just changing the login/register URL will fix this, but of course is inconvenient.

gpk’s picture

I wonder if it would be worth reporting the spam problem to evonames/evoplus, who are I believe the registrar of drupaler.org, and to whoisprotectservice.net, which the spammers seem to be using to hide their own details? There seem to be lots of reports on the internet (and on drupal.org also) of spammers using the drupaler.org domain.

briganzia’s picture

Also on one of my sites, two days ago, I've found some spam from drupaler.org

edop’s picture

Same here, since a couple of days ago. I have Honeypot installed.
Have tried to change the honeypot field setting from "URL" to something else, hoping the bot triggers on the default "URL" fieldname. Did not work. Increasing the timeout to 4 secs did not work either.

Also see this discussion.

UPDATE 21-6-2015: Brainhard.net domains are now giving the same problem as Drupaler.org. I have updated the rule below correspondingly.

If you want to go for a solution using the Rules module, this one does the trick. It looks for patterns in the email address of the new user ("drupaler.org" and "brainhard.net" in this case), by doing a text comparison using a regular expression (".*drupaler\.org|.*brainhard\.net"). You may edit the desired matching pattern by editing the regular expression. The rule then deletes the account and its content, but you may wish to edit the rule to do something less dramatic.

You can import this code in Rules, to get you started. Good luck and let me know how it worked.

{ "rules_delete_spam_accounts_by_domain_name" : {
"LABEL" : "Delete spam accounts by domain name",
"PLUGIN" : "reaction rule",
"OWNER" : "rules",
"REQUIRES" : [ "rules" ],
"ON" : { "user_insert" : [] },
"IF" : [
{ "text_matches" : {
"text" : [ "account:mail" ],
"match" : ".*drupaler\\.org|.*brainhard\\.net",
"operation" : "regex"
}
}
],
"DO" : [
{ "user_block" : { "account" : [ "account" ] } },
{ "entity_delete" : { "data" : [ "account" ] } }
]
}
}

ttravis’s picture

I am getting the same thing on a site that is only a couple weeks old and never been advertised in any way!

eshta’s picture

Status: Active » Postponed

It is amazing how fast spammers can work. You should know that Mollom already includes a honeypot field as well as other protections. In this scenario, however, the blacklist is your best bet when combined with textual analysis.

boran’s picture

FYI: A D6 site I have just got hacked, and 62 accounts were created with emails from "drupaler.org".
I've cleaned up (not too difficult thanks to a git repo of the site). Am not sure of the exact cause, D6 was at its current release and no secuirty updates to modules were outstanding. There were man references to the elfinder module, so removed that.

cdale’s picture

We've been having this as well. Adding access rules (Under User Management in D6) to block registrations for itregi.com and drupaler.org seems to stop the registrations. What's strange, is this will start happening within a few days of a site "going live", on an existing domain, that did not previously have a drupal site. We don't call back to drupal for updates, but the site is "published" to google etc.. though webmaster tools.

The general pattern seems to be the following:

1. Go to /user/register
2. Post form with fields filled in.
3. Site sends out verification email.
4. Some time later (Usually a few hours), login with account that was created (We believe it's because we have been sending the password in the welcome email. We're going to take that out, and see if that helps, though, if they're using the password reset link, this might be a different matter).
5. Go to node/add
6. Create any content they can
7. Attempts to access pages like node/add/page, node/add/story, node/add/webform are also made.

What's really strange about the created content, is it seems to bypass most normal node save routines. For example, we have a content type with CCK fields, many of which are required for the content to be created, however, the content is made with most of these required fields not completed. What even more confusing, the CCK type tables have no data in them for the created node, yet the node table does have an entry. We've been trying to figure out how this is possible, though no luck as yet. We're just thankful it only seems to be those two domains... so far.

It seems if registered users don't have access to create any content, the only thing that happens is spam user accounts. However, if you do have content that registered users can create, expect it to be filled with lovely spam content, XSS scripts and all.

thoughtcat’s picture

I confirm exactly the same behaviour on my site as cdale. I didn't go as far as checking the actual database, but the spammers were able to create & publish content of types accessible to authenticated users with some mandatory fields not completed.

etron770’s picture

I "solved" this problem with

  • creating a role spammer with no rights enabled
  • using module https://www.drupal.org/project/register_preapproved
  • setting the role spammer as preapproved: admin/people/register_preapproved/roles
  • adding @drupaler.org here: admin/people/register_preapproved
  • deleting frequently alls user with role spammer

be aware that there is a little bug: It is difficult to find the administration interface:
/admin/people/register_preapproved

rooby’s picture

For user registrations this module is good for stopping this: https://www.drupal.org/project/user_restrictions

jonahlyn’s picture

I'm having a similar problem with spam coming through the site-wide contact form protected with mollom on a site I maintain (we don't allow user registrations). At first the submissions came from @drupaler.org and later switched to @brainhard.net.

All the submissions exhibit the same properties: user portion of email address is random words strung together; the subject and body of the message submitted are random letters and very short, usually between 3 and 5 letters long.

I switched to mollom from a different spam fighting module because of the text analysis and blacklist feature among other things. I immediately added brainhard.net to the blacklist and it seemed to work for a while, but today I received another spam submission from brainhard.net.

I understand that mollom can't identfy spam 100% of the time. What has me worried is that every valid submission through the contact form has a link at the bottom of the message labeled "Report as inappropriate". The brainhard.net submission did not have this link.

leistiko_texvet’s picture

Comment/response #5 is a stellar fix. Thanks a ton for sharing this great, versatile, importable Rule.

tomarnold2’s picture

#5 rule was great! It was a little out of date from the latest version of Rules (the import wouldn't work for me), so I reconstructed it and pasted it below (I also removed the "block user" step in the example above - I just wanted to immediately blow-away the account):
-
{ "rules_spam" : {
"LABEL" : "Spam Blocker",
"PLUGIN" : "reaction rule",
"REQUIRES" : [ "rules" ],
"ON" : [ "user_insert" ],
"IF" : [
{ "text_matches" : {
"text" : [ "account:mail" ],
"match" : ".*drupaler\\.org|.*brainhard\\.net",
"operation" : "regex"
}
}
],
"DO" : [ { "entity_delete" : { "data" : [ "account" ] } } ]
}
}

tomarnold2’s picture

P.S. If anyone has a Rule written to look for new users registering with the same first & last name, that's the latest pattern I'm seeing. I'd like to have a rule in place that blows-away those as they create an account, too.

stanly64’s picture

Thanks for posting a nice solution here. It worked well.

Mean while, will you suggest how code can be modified to use with comparison operator "ends with".

I have created another way for achieving this. It works only one text comparison per rule. Following exported code doesn't work. Will you advise where to modify:

{ "rules_block_spamer_email_all" : {
    "LABEL" : "Block Spamer Email All",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "TAGS" : [ "Spam email" ],
    "REQUIRES" : [ "rules" ],
    "ON" : { "user_insert" : [] },
    "IF" : [
      { "text_matches" : { "text" : [ "account:mail" ], "match" : "drupaler.org", "operation" : "ends" } },
      { "OR" : [
          { "text_matches" : {
              "text" : [ "account:mail" ],
              "match" : "meangel.net",
              "operation" : "ends"
            }
          }
        ]
      },
      { "OR" : [
          { "text_matches" : {
              "text" : [ "account:mail" ],
              "match" : "brainhard.net",
              "operation" : "ends"
            }
          }
        ]
      },
      { "OR" : [
          { "text_matches" : {
              "text" : [ "account:mail" ],
              "match" : "bigsizetrend.com",
              "operation" : "ends"
            }
          }
        ]
      }
    ],
     "DO" : [ { "user_block" : { "account" : [ "account" ] } }, { "block_ip" : [] } ]
  }
}

Regards,