Suspicious GET Request: Do You Know What This Is?

Published: 2019-01-21
Last Updated: 2019-01-21 20:10:01 UTC
by Didier Stevens (Version: 1)
6 comment(s)

Reader Vinnie noticed following suspicious GET request directed at his web server:

My first idea was an attempt to abuse his web server as a proxy, or log SPAM.

Vinnie executed this request (hxxp://189[.]40[.]40[.]159:7771/u9licfgnx56ryp0jfdmis6s3hez4wij), and got text back:


I was able to make some sense of this: the first 32 characters are hexadecimal digits, and the rest is BASE64. That BASE64 string decodes to binary data that starts with the magic header for "GPG symmetrically encrypted data (AES256 cipher)": "8C 0D 04 09 03 02".

The data has a high entropy:

That's as far as I got.

We don't know if the server replying with this data is under the control of the attacker, or not. It could be an "innocent bystander".

Do you have any idea what this might be about, or what the data is? Please post a comment!

We're not asking to interact with this server, there's no need. We want to know if you have ideas about the request type or returned data. Should you still decide to interact with this server, be careful. We don't recommend it, we don't know what this server is or does. Don't do anything that might be considered hostile and don't do anything illegal.

If you want a second example of data, take a look at Shodan's report:

Please post a comment, thanks!

Didier Stevens
Senior handler
Microsoft MVP

Keywords: GET HTTP Suspicious
6 comment(s)


First look the url's could be privatebin url's AKA pasebin
Here's a not the first one to wonder...

I also found


in case that helps.
I guess you found this already:

The response from the server changes. So far not pattern recognized.
I also found another related http request same IP and pattern but with different URI and returned content on
Typically if someone's doing "GET http://..." I assume they're scanning for open proxy servers. "u9licfgnx56ryp0jfdmis6s3hez4wij" might uniquely identify Vinnie's server in the actor's data set. When the listener on port 7771 gets a request, the actor can look up the string and figure out the endpoint for the open proxy. (Looking at the connecting IP may not be good enough, in case the victim server is itself being proxied.)

The payload is the interesting part. I suppose using encrypted data has two benefits here. One, if he gets back anything at all, he knows the proxy isn't dropping traffic it can't "read." Two, if he can decrypt it, he knows the traffic made a full round-trip without being tampered with.

My guess: this is someone scanning for open proxies that don't have any DPI happening along the route.
We had seen a few of those long string/GET URL requests last year (not seen one in a while) - I never was able to get a result when trying to fetch the URL myself. I was guessing it was a key string to show which server was vulnerable.

Diary Archives