URL does not use a recognized protocol
When your SQL Directory Traversal attempt misses it's mark.
The above code is right out of the training manual for testing techniques.
See here: OWASP.ORG
It seems their are some students testing their class assignments again.
188.8.131.52 is from Germany (DE) in region Western Europe
canonical name: srv001.ostermaier.net
Registered Domain: ostermaier.net
6/25/2016 11:35:05 AM
184.108.40.206 is from Spain (ES) in region Western Europe
canonical name: server.alfastar.es
Registered Domain: alfastar.es
220.127.116.11 is from Russian Federation (RU) in region Eastern Europe
canonical name: vm3-ext.ru
Registered Domain: vm3-ext.ru
6/26/2016 4:26:46 AM
18.104.22.168 is from Germany (DE) in region Western Europe
canonical name: powerc159.galaxy-gmbh-service.de
Registered Domain: galaxy-gmbh-service.de
6/25/2016 8:45:47 PM
22.214.171.124 is from Spain (ES) in region Western Europe
canonical name: vps-1033659-743.cp.noc.softec-internet.com
Registered Domain: softec-internet.com
6/25/2016 5:52:28 PM
126.96.36.199 is from Germany (DE) in region Western Europe
canonical name: srv01.wkw2k.de
Registered Domain: wkw2k.de
7-10-2016: 188.8.131.52 is from Ecuador (EC) in region South and Central America
canonical name: mail.mundomotriz.com.ec
Registered Domain: mundomotriz.com.ec
and... (Changed up, not using domain networks this week)
Master system human input:
Lookup failed: 184.108.40.206 No data
220.127.116.11 is from Russian Federation (RU) in region Eastern Europe
Lookup failed: 18.104.22.168 No data
22.214.171.124 is from Indonesia (ID) in region Southern and Eastern Asia
7-21-2016: Lookup failed: 126.96.36.199 No data
188.8.131.52 is from Brazil (BR) in region South and Central America
and (script with a touch of human)
7-21-2016: 184.108.40.206 is from Ukraine (UA) in region Eastern Europe
canonical name: customer.optima-east.net
Registered Domain: optima-east.net
and (back to scripted)
7-21-2016: Lookup failed: 220.127.116.11 No data
18.104.22.168 is from United States (US) in region North America
7-21-2016: Lookup failed: 22.214.171.124 No data
126.96.36.199 is from United States (US) in region North America
7-21-2016: 188.8.131.52 is from Indonesia (ID) in region Southern and Eastern Asia
canonical name: ln-static-139-255-47-149.link.net.id
Registered Domain: link.net.id
7-21-2016: Lookup failed: 184.108.40.206 No data
220.127.116.11 is from United States (US) in region North America
7-21-2016: Lookup failed: 18.104.22.168 No data
22.214.171.124 is from United States (US) in region North America
7-21-2016: Lookup failed: 126.96.36.199 No data
188.8.131.52 is from United States (US) in region North America
7-21-2016: Lookup failed: 184.108.40.206 No data
220.127.116.11 is from Iraq (IQ) in region Middle East
7-21-2016: Lookup failed: 18.104.22.168 No data
22.214.171.124 is from United States (US) in region North America
7-21-2016: Lookup failed: 126.96.36.199 No data
188.8.131.52 is from United States (US) in region North America
7-21-2016: Lookup failed: 184.108.40.206 No data
220.127.116.11 is from United States (US) in region North America
7-21-2016: 18.104.22.168 is from United States (US) in region North America
22.214.171.124 is from Russian Federation (RU) in region Eastern Europe
126.96.36.199 is from United States (US) in region North America
I know, it's boring reading my reports but if you made it this far, look way below for the old payback.
(You guys might need to take a look at your servers, seems you have been Zombied by the Bot Machine!)
UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Here's the error you will see on your IIS Server Logs.
It's also a very simple error trap that can if you would like drop the connection IP into your banned IP list.
Description: The URL does not use a recognized protocol
The code that can trigger this error, really anything, a function call was this trigger in the header.
I'll give you a big hint to why this error is shown on my side.
First, the Query String that you attempt to cancel out with a single quotation mark is actually the URL. Once it's gone the URL is not formed correctly. Yes, you don't see it because it's a query string designed to encode the actual query then decode needs specific data which is not working when you change the string.
It's more important to view the string and to understand how it works before you spend time writing a script. To simply insert a quote after the first querystring is just lazy. Unless you are looking for some type of validation that nothing can be found.
But wait, this is an API so it actually doesn't query any database directly.
What a waste of time, I think next time you need to create a new hack script you should ask me what just wont work.
So, let me ask the Botnet creators how they determine a good successful directory traversal attack?
- Do you some how know the errors the site reports?
- Do you guess that you were successful?
- Do you keep scanning the same URL with the same script thinking or expecting something will change to give you different results? (Einstein Insanity)
- Are you doing this just so I can post your Botnet Zombie computers?
- ..../.../.../.../.../../../../././././ really?
Now that we have more than enough results to setup our counter scripts let's get started.
We all know cross site scripting, this script seems to pick a specific query-string to modify with a single quotation mark.
To find out if the script is intelligent or if a human checks it from time to time we need to add another query string field name to see what the script is really looking to modify.
I've always had at least one dumby query-string named for just this reason.
I'll update you on the results.
Update: There was a pattern, I thought the days of feeding search engines with bad URL's was over. Guess I was wrong.
You see, this bot was taking advantage of my good nature programming.
When an API tosses an error or no data is found using the API I display the page that actually says there was no data retrieved.
I forget about the bad URL submission bots that most search engines ignore but it was an issue years ago.
So to make sure all is well, instead of showing the page API data not found I just show the page as if the URL was not changed.
Simple InStr(search for, replace with) did the job.
I don't mind the bots spreading the word about my sites, I just want to make sure the words are showing up correctly in those search engines.
WinHttp.WinHttpRequest error '80072ee6'
The URL does not use a recognized protocol
That's it for the code.
Now for the Security Feedback.
I have 4 API's that use external sites. This one API that was hit came from only one site, CareerBuilder so my guess is they were hired by another job board to make my job board links see to be bad or out of date. I do have 3 other feeds that have not been touched so it might have been a contractor working with one of them. Just saying when you have job boards with investors you only have profits in mind. Lucky for me, 20 years of working my oldest website has shown more ways of dealing with investor related websites claiming to help the masses. My Operating budget on my job board is just at $5.00 per day. Try to do that with $100M salaries... Again, just saying you shouldn't get rich off of peoples sufferings and blight.