It's been a little while since this was posted, but I'm here to report that this does NOT appear to have been some sort of attack after all.

Rather, this particular URL string indicates a cookieless session.

It seems that this was nothing more than one (or multiple) of our users hitting our site with cookies disabled, and our app wasn't set up to properly handle this being inserted into the URL string.

I suppose it is still possible that someone was trying to manipulate this effect (the timestamps and frequency were of interest), but I believe this was more likely a case of us jumping on the "we're being attacked!" train a bit too early. It was surprisingly difficult to find information on this!

Ultimately, we figured this out when I encountered this exact URL pattern in our (isolated) test environment and decided to do some additional research on the issue.

Thanks everyone for your help with this, and sorry for any confusion! I'm leaving the initial question intact to avoid invalidating the answers that are already present.

Original Text:

I work for a company that has a public facing website for our customers. In the past several weeks, we have been seeing a series of log entries that look like this:

The controller for path '/(x(1)s(mpwcjessdyhikng0a1kyud1z))/' was not found or does not implement IController.

These entries are typically about 1 second apart and always start with x(1)s followed by a random string of characters, followed by various paths to different pages, especially /account or /account/recoverpasswordrequest/. This tends to go on for 10-30 minutes, and then we don't typically see it again until the next day, although it does happen pretty much every day.

We've blacklisted several IPs that this has happened from, but this person(s) is obviously using many different IPs to run whatever script is doing this.

Can anyone help me understand what is going on here, especially with what x(1)s is, or what kind of information this person might be trying to obtain? The attack happens to be failing because we don't have a randomly named controller that will accept this information, but it would be wonderful to be able to put a stop to this or at least have a better understanding of what's happening.

EDIT: This "request" always follows the same (x(1)s(random)) pattern. There are 3 URLs primarily being hit:

The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/register' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/recoverpasswordrequest' was not found or does not implement IController.

The full URL would be: https://example.com/(these requests)

The site uses MVC, so these particular error messages are due to us not having a controller named (x(1)s(blah)) that this URL can resolve to. The log entries show the same random string being used for all 3 URLs, then a new random string is generated and the same pattern is tried again.

These log entries are from this request failing and causing an exception in our application logic. Therefore, they are bypassing the firewall and actually failing inside our code.

  • I dont recognise the pattern but I do want to suggest you look into Snort, it should help prevent this random traffic
    – Purefan
    Jun 1, 2015 at 14:21
  • 1
    @Purefan thank you, I'm looking in to this. I should point out that I'm not the one responsible for our security (if that isn't obvious from this question), I'm one of the developers and am interested in trying to figure out what's going on here. At this point, it's not something we have an answer for. Thanks for the input! Jun 1, 2015 at 14:29
  • Can you post the full URL and some other frequent URLs so we can see a bigger picture of what the attacker is trying to do? Do you have a log with the full URL? (Be sure to obfuscate/change any identifying information of course) Jun 1, 2015 at 15:11
  • @LindsayMorsillo I have updated the question with some additional information. Unfortunately, I don't have much more to go on than this. Jun 1, 2015 at 15:46
  • 1
    @levelonehuman, the reason can be to fingerprint your infrastructure and/or get/find any bug in your web software which can be explited further and/or find nonsecured resources in web site for stealing some internal/customer info. The usage of fuzz logic also seems to be for getting valid path in the web site/app(s) Jun 1, 2015 at 18:23

4 Answers 4


I agree with @RomeoNinov that this is likely fuzz logic/testing or just a scanner sweeping all available applications. In terms of stopping this, you're best off white-listing all acceptable requests. Otherwise you're playing whack-a-mole by blocking all unnecessary requests which is far too large to keep up with.

My recommendation is to leverage IIS Request Filtering since it is native functionality within IIS7+. Add all of the application's URLs (i.e. cs-uri-stem) to the alwaysAllowedUrls setting. Then set the allowable file extensions to the following as it will only allow the default document and no others. Just having these two items in place would have returned an HTTP 404 very early in the IIS pipeline so the request wouldn't have been processed by application code.

<fileExtensions allowUnlisted="false">
    <add fileExtension="." allowed="true" />

FWIW, I've been posting to my blog about defining thresholds for IIS Request Filtering. There's still much to add but hopefully it will help get you started.

  • We've discussed putting in IIS Filtering as well - ultimately the goal is to stop this on its way in, it should never reach our application code to begin with. This is an excellent recommendation, thank you. I think this is ultimately the way we'll try to mitigate this traffic, at least in the short term. Jun 2, 2015 at 12:23

This pattern look for me like fuzz logic/testing.

The reason can be to fingerprint your infrastructure


Get/find any bug in your web software which can be explited further


Find nonsecured resources in web site for stealing some internal/customer info.

The usage of fuzz logic also seems to be for search for valid path in the web site/app(s)

P.S. Of course this above is worst case scenario, but in security IMHO this is the way to get good evaluation of particular issue


It appears this can occur if the user has cookies disabled, so it falls back to including information in the URL:



Some unix systems do not handle unescaped parentheses correctly in path names, especially if the system is using some kind of script to do URL rewriting or something like that.

I don't know what you mean by "MVC" (System.Web.Mvc framework?).

There is nothing you can do to stop such probing except ban IPs. In the old days when I used to run a web server I had to block the entire island of Taiwan (because at that time all of China's traffic ran through Taiwan).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.