[untitled] reprint melting ice - track icedid server with a few simple steps

[ translate ]Melting Ice- Use a few simple steps to track IcedID The server Just look at the landlord 1# Dreamy other bank collection 2021-9-12 17:03:18 Note the address of the original post ：https://research.checkpoint.com/2021/melting-ice-tracking-icedid-servers-with-a-few-simple-steps/ Original title ：Melting Ice – Tracking IcedID Servers with a few simple steps Original post information ：May 26, 2021 Research by: Alex Ilgayev Introduction Tracking Botnets usually requires a lot of effort 、 Time and threat intelligence knowledge . If it is a multi-stage complex malware family , Such as IcedID、Emotet and QakBot, Tracking is even more difficult . therefore , As a malware Analyst , We tend to look for as many automated processes as possible – Collect large-scale samples , Identify them , Extract their configuration , Then let these produce the value we are interested in , Such as clearer Threat Intelligence pictures or the latest domain reputation engine . Although the life of malware analysis is often as difficult as described above , But it doesn't have to be like this . Sometimes , If we are smart ,10% Your work will get us interested 90% Result . In this article , We showed such a clever method , It also shows how to quickly track IcedID C&C The server , And there is no need to track or analyze any samples .IcedID background IcedID banker Malware first appeared in 2017 year 9 month , Since then, significant progress has been made . This threat , Also known as BokBot, It has been growing over the past year , And has a wide range of malicious functions , Such as browser interception , Certificate theft ,MiTM Proxy settings and VNC Module etc. .Malwarebytes、Group-IB and Binary Defense Past publications on the internal functions of this zombie program , Including the infection chain and malicious components are thoroughly described . According to the latest infection chain proposed by binary defense researchers , Recently iterated IcedID Contains three malicious components – Entry points containing malicious macros DOC/XLS; A first stage payload; And the last second stage payload, It itself consists of two sub parts – One 64 position DLL loader , And being disguised as ".dat " The actual zombie program of file encryption . Every second stage payload Usually contains 2-4 A unique embedded domain name , These domain names can be resolved to the same IP Address . Suppose we set a goal , Track these domain names /IP And stop them ; natural , We are interested in the fastest and painless way . The victim's communication protocol is HTTPS, So we checked the bundled TLS certificate . As we observe below ,IcedID People are more concerned RSA-2048 Hard and specific guarantee provided , Not too concerned about following safety rules ; The default name of the certificate issued to is “ Internet Widgits Pty,Ltd” Institutions , The organization is located in “ A state ”.IcedID C&C Sample certificate ： If we put this IcedID Compare the certificate with a default self signed certificate , The most obvious difference is the common name field . Public server FQDN（ for example ） Should appear in this field , Not like in this case Checkpoint.comlocalhost like that . You may understand what's going on ; We immediately began scanning a wide range of Networks , Look for other servers that present this certificate . Enumerating servers we don't want to reinvent , Choose to use the popular Internet scanning platform Censys To create a potential C&C A list of candidates . image Shodan Such other network scanning platforms can also be used for this purpose .Censys The engine provides us with a lot of certificate query control . After some adjustment and adjustment , We constructed the following query :443.https.tls.certificate.parsed.issuer_dn: “CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd” and 443.https.tls.certificate.parsed.subject_dn: "CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd"Censys One of the certificate results of ： If you doubt the uniqueness of using common names in certificates , This can be easily proved by a short experiment ： The dozens of servers we searched seem to be many , But if you omit the requirement in the search query , The result will be an explosive increase in size and quantity by one thousandth ：localhostCN=localhost at present , We cannot assume that each of these servers is active IcedID malice C&C, So we need to verify them . Fortunately, , It's possible , This is due to another unique feature we found in the research process . Verification server when we reverse engineer the functions of zombie programs , We noticed that zombie programs are in contact with C&C A quite interesting test was done before the server communicated . The following code is part of a callback function , With the C&C.WinHttpSendRequest Called before contacting . Certificate verification code : In short , This code runs on the public key of the certificate Fowler-Noll-Vo 32 Bit hash function , And compare it with the specified serial number of the certificate . Only when the comparison results are consistent , Communication will continue （ Or use XOR-ed value ）.0x384A2414 The certificate serial number field is assigned by the certification authority , And provide a unique identifier for each generated certificate . The certificate issuer must ensure that no two have the same certificate issuer DN Different certificates of contain the same serial number , But no one can guarantee this . In our case , The certificate is self signed , Malware operators uniquely allocate their C&C Serial number field . Use this verification algorithm yourself , For a suspicious server , We can make sure it is IcedID Part of the infrastructure . We're in the appendix A A simple python Script to verify this logic , For a provided remote server . Apply this method , We found that most of the potential results before are related to IcedID of , And narrow the list down to 52 Servers . Consider the unique certificate attributes and uncommon hash functions , We can safely infer that these servers are IcedID C&C Components of infrastructure . With this list , We went to check these servers carefully . Server analytics analyzes their Internet facing slogans , We can find that most deployed servers have several similar properties . The most common attribute is open port 、 Operating system and network server . Open port - All servers have 443 port ,94% Your server also listens 80 port ,77% Server listening SSH port （22）. operating system - 77% Your server is running Debian operating system . Network server - 94% The server is running nginx Network server . We can still see that , Most servers live in Romania 、 The United States and Germany .IcedID Location of the server : Another analytical perspective is through passivity DNS service , Such as RiskIQ. Using this service enables us to provide services for everyone we have IP Address find the relevant domain , And expand our Threat Intelligence picture . These additional fields must be logically embedded in some samples that we cannot access directly . for example , One of the addresses we found is , It does not resolve to the following IcedID Domain ：152[.]89.247.60formgotobig[.]topponduroviga[.]toptranmigrust[.]clubaswenedo[.]space To sum up, a sad fact is , do " The right thing " It may backfire .IcedID This is the case with the maintainer of the activity ; They made a self signed certificate , And let their malicious operations support HTTPS, This is a commendable effort , Most malware are dismissive , Even some long-running legal websites have been dismissive for a long time . By doing so , They make it more challenging to incite hostility to take over their network – But they also make all their servers basically happy " hi , I am a malicious C&C " In response to the standard scanning service . Once these servers are exposed , We can keep tracking them , Analyze their behavior , Instead of running regular expressions , Not to mention launching the debugger or disassembler . For those who run malicious activities , This is a nightmare scene ; Their purpose is to be constantly updated C&C In the server list " Prize " Put it out of reach , At the top of the hierarchy list . contrary , Because this is too clever TLS Business , Collection server （ And get a bunch of juicy information , This is beyond the scope of this article ） Become within the capabilities of analysts , As long as you have a week's experience . As a wise man once said , Think before using a technology , Otherwise your opponent will use it against you .IOCIcedID C&C servers:83[.]97.20.24983[.]97.20.174194[.]5.249.5245[.]153.240.135194[.]5.250.104152[.]89.247.6091[.]193.19.97194[.]5.249.8183[.]97.20.73194[.]5.250.3583[.]97.20.176194[.]5.250.46212[.]114.52.18691[.]193.19.3745[.]147.231.113188[.]119.148.75185[.]38.185.9045[.]138.172.17991[.]193.19.5183[.]97.20.122194[.]5.249.103139[.]60.161.63194[.]5.249.86139[.]60.161.48185[.]33.85.35194[.]5.249.9779[.]141.164.241194[.]5.249.90193[.]109.69.52194[.]5.249.54185[.]70.184.8779[.]141.166.39146[.]0.77.9231[.]184.199.1145[.]129.99.241194[.]5.249.46185[.]123.53.202146[.]0.77.1831[.]24.228.17045[.]147.230.8883[.]97.20.25445[.]147.230.82194[.]5.249.7246[.]17.98.19145[.]153.241.115185[.]70.184.41139[.]60.161.50194[.]5.249.14379[.]141.161.1765[.]149.252.17945[.]147.228.19891[.]193.19.251 appendix A Test a server IcedID certificate :import idnafrom socket import socketfrom OpenSSL import SSLfrom cryptography.hazmat.primitives.serialization import Encodingfrom cryptography.hazmat.primitives.serialization import PublicFormatdef fnv1a_32(data: bytes) -> int: “”“Fowler–Noll–Vo hash function variation. Args: data (bytes): Input data Returns: int: Output 32 bit hash “”” hval_init = 0x811c9dc5 fnv_prime = 0x01000193 fnv_size = 2 ** 32 hval = hval_init for byte in data: hval = hval ^ byte hval = (hval * fnv_prime) % fnv_size return hvaldef get_certificate(hostname: str, port: int): “”“Connects to the remote server, and retrieves the certificate. Args: hostname (str): Remote hostname port (int): Remote port (usually 443) Returns: Certificate object “”” hostname_idna = idna.encode(hostname) # We are building a SSL context on top of a raw socket. sock = socket() sock.connect((hostname, port)) ctx = SSL.Context(SSL.SSLv23_METHOD) ctx.check_hostname = False # the cert is self-signed so we don’t want to verify it ctx.verify_mode = SSL.VERIFY_NONE # making SSL handshake sock_ssl = SSL.Connection(ctx, sock) sock_ssl.set_connect_state() sock_ssl.set_tlsext_host_name(hostname_idna) sock_ssl.do_handshake() # retrieving certificate and converting it to an cryptography object cert = sock_ssl.get_peer_certificate() crypto_cert = cert.to_cryptography() sock_ssl.close() sock.close() return crypto_certdef test_is_icedid_c2(hostname: str, port: int) -> bool: “”“Testing whether a remote server is part of IcedID C&C infrastructure. Args: hostname (str): Remote hostname port (int): Remote port (usually 443) Returns: bool: True if the server is IcedID verified, or False otherwise. “”” try: # We query the server and retrieve its certificate. cert = get_certificate(hostname, port) serial_number = cert.serial_number # Getting the public key, and hashing it. public_key = cert.public_key().public_bytes(Encoding.DER, PublicFormat.PKCS1) fnv_hash = fnv1a_32(public_key) & 0x7fffffff # Finally comparing the hash to the serial number. if serial_number == fnv_hash or serial_number == fnv_hash ^ 0x384A2414: return True except Exception as e: return False return False