|
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: https://www.shodan.io/host/189.40.40.159 Please post a comment, thanks! Didier Stevens |
DidierStevens 316 Posts ISC Handler |
| Reply Subscribe |
Jan 21st 2019 1 month ago |
|
First look the url's could be privatebin url's AKA pasebin
|
Anonymous |
| Reply Quote |
Jan 21st 2019 1 month ago |
|
Here's a not the first one to wonder...
https://www.reverse.it/sample/e5012144f3b85261f1035730aafdb7ae1c123ca6872b651c3ca86f2a0eb51770?environmentId=120 I also found https://www.virustotal.com/#/url/40b3c1d5d30784fc448b6bbd0e8f9c09e89e8f993364ef480ed8e2022cc1d5fd/detection and https://www.virustotal.com/#/url/f1208e94f83eb37d21f0b02c32deb5e6fc1291ff7b7b88de526bfad054b13133/detection in case that helps. |
Martijn 5 Posts |
| Reply Quote |
Jan 21st 2019 1 month ago |
|
I guess you found this already:
https://www.reverse.it/sample/e5012144f3b85261f1035730aafdb7ae1c123ca6872b651c3ca86f2a0eb51770?environmentId=120 The response from the server changes. So far not pattern recognized. |
Anonymous |
| Reply Quote |
Jan 21st 2019 1 month ago |
|
I also found another related http request same IP and pattern but with different URI and returned content on URLscan.io
https://urlscan.io/result/e5fe3dec-d145-4526-a68d-26a42beccfe1#summary |
SuspiciousLink 5 Posts |
| Reply Quote |
Jan 21st 2019 1 month ago |
|
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. |
parseword 9 Posts |
| Reply Quote |
Jan 22nd 2019 1 month ago |
|
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.
|
afbach 4 Posts |
| Reply Quote |
Jan 22nd 2019 1 month ago |
Sign Up for Free or Log In to start participating in the conversation!
