Analyzing a Hostname Blacklisted by HoneyShare
HoneyShare maintains a blacklist of hostnames and IPs. Let's take am example of a hostname and analyse it.
mail.telegrkwb.com
Fetching Data
Using HoneyShare API Python library, we can get some basic information out of the hostname.
from pprint import pp
from honeyshare import HoneyShare
hs = HoneyShare(key=API_KEY)
Hostname = "mail.telegrkwb.com."
print("Hostname Information")
hn = hs.Hostname(Hostname).hostname()
pp(hn)
print("IP Information")
IP = hn['IPv4']
ipv4 = hs.IPv4(IP)
pp(ipv4.ipv4())
print("Other Hostnames on the same IP")
pp(ipv4.hostnames())
Running the script we get:
Hostname Information
{'Hostname': 'mail.telegrkwb.com.',
'IPv4': '106.75.50.248',
'Timestamp': '2025-05-02T09:03:46.604421Z'}
IP Information
{'IPv4': '106.75.50.248',
'CountryCode': 'CN',
'Hostname': 'mail.telegrkwb.com.',
'LastSeen': '2025-05-02T09:03:46.604421Z'}
Other Hostnames associated to the same IP:
{'IPv4': '106.75.50.248',
'Hostnames': [{'Timestamp': '2025-05-02T09:03:59.779581Z',
'Hostname': 'mail.telegrkwb.com.'},
{'Timestamp': '2025-05-02T09:03:59.779581Z',
'Hostname': 'vxbyaeb.cn.'}]}
We see that there are two hostnames associated with the same IP:
mail.telegrkwb.com.
vxbyaeb.cn.
The IP has been geolocated to the People's Republic of China (CountryCode: CN).
We continue by getting an overview of the connections made by the IP to HoneyShare.
Connection Analysis
pp(ipv4.timeseries())
{"IPv4": "106.75.50.248",
"Connections": [
{"Timestamp": "2025-05-02T09:03:46.604421Z", "Port": "9200"},
{"Timestamp": "2025-05-02T09:03:46.137854Z", "Port": "9200"},
{"Timestamp": "2025-05-02T09:03:40.672056Z", "Port": "9200"},
{"Timestamp": "2025-05-02T09:03:40.21015Z", "Port": "9200"},
{"Timestamp": "2025-05-02T09:03:39.749384Z", "Port": "9200"}]}
There are a few connections done on the second of May within seconds of each other. All connections are done to port 9200, which is the default port for ElasticSearch, a widely used document store database used for text search and logging.
Elasticsearch's connections are HTTP based, so we can expect HTTP(S) requests being sent to HoneyShare. We continue by taking a sample of the payload of each request and printing them out.
IP = "106.75.50.248"
Port = "9200"
res = hs.IPv4(IP).payload(port=Port, base64_decode=True)
payload_list = [i["Payload"] for i in res["Connections"]]
for i, req in enumerate(payload_list):
print(f"Request {i+1} =================================")
print(req[:100])
print("")
Request 1 =================================
USER anonymous
Request 2 =================================
GET / HTTP/1.1
Host: 1xx.xxx.xxx.114:9200
Accept: */*
Request 3 =================================
GET / HTTP/1.1
Host: 1xx.xxx.xxx.114:9200
Accept: */*
Request 4 =================================
FgMBAPIBAADuAwPh2KtbYISDU91xdXrJBX1xm2w51X9vqk+/+ejjcIqqtyCFodpWngdlHCuAvhRg+QPXKjVWx1deHOBnFjgrfEc2
Request 5 =================================
FgMBAPIBAADuAwO6wcbTg829z6OsRcgM2Hj/PHa+omVyme84YR3EZcMoDSDZmjQ4lmCC3JARPYKavNj1gZc/AbOBnelQPWsTbVqT
Connection 1 is surprising. It seems to be an FTP command to initiate an anonymous login. FTP uses plain text usernames and passwords, and here it seems the attacker is trying to find opened FTPs that would allow such an unprotected login.
Connections 2 and 3 are the same. They are both a very simple HTTP request to the root of the server (GET /). Only the Host and Accept header are present. Host shows the IP and Port of the listener. Despite the port being an Elasticsearch one and these connections being HTTP, it doesn't seem that the attacker was trying to send any Elasticsearch commands (for example to list all indices of Elasticsearch), as these would have a path.
For connections 4 and 5, we get only hexadecimal values, so we need to go deeper.
Looking at the start of both connections, the first few bytes are \x16\x03\x01\x00\xf2. This sequence is characteristic of a TLS (Transport Layer Security) handshake, specifically the beginning of a Client Hello message. In TLS, the first byte 0x16 represents the handshake content type, and 0x03 0x01 is often the version number (TLS 1.0 in this case). The bytes 0x00\xf2 represent the length of the message.
Parsing TLS Handshakes
Using scapy, a third party library, we can parse the connections into something we can read. Below is an example of parsing one connection.
from scapy.all import *
from scapy.layers.tls.all import *
req = base64.b64decode(payload_list[3])
tls_packet = TLS(req)
tls_packet.show()
###[ TLS ]###
type = handshake
version = TLS 1.0
len = 242 [deciphered_len= 242]
iv = b''
\msg \
|###[ TLS Handshake - Client Hello ]###
| msgtype = client_hello
| msglen = 238
| version = TLS 1.2
| gmt_unix_time= Thu, 26 Jan 2090 00:20:43 (3789073243)
| random_bytes= 60848353dd71757ac9057d719b6c39d57f6faa4fbff9e8e3708aaab7
| sidlen = 32
| sid = b'\x85\xa1\xdaV\x9e\x07e\x1c+\x80\xbe\x14`\xf9\x03\xd7*5V\xc7W^\x1c\xe0g\x168+|G6<'
| cipherslen= 38
| ciphers = [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256]
| complen = 1
| comp = null
| extlen = 127
| \ext \
| |###[ TLS Extension - Supported Point Format ]###
| | type = ec_point_formats
| | len = 2
| | ecpllen = 1
| | ecpl = [uncompressed]
...
Learn more about HoneyShare, explore the API and library.