How Namecoin Blockchain Research Predicted RTM Cyber ​​Attacks



    The Namecoin blockchain was created as an alternative to traditional DNS registrars, protected from censorship and forced domain seizure. In the past few years, botnet operators such as Dimnie, Shifu, RTM, and Gandcrab have begun to use it to manage the addresses of C&C servers.

    On the one hand, the decentralization and stability of the blockchain prevent researchers and providers from removing such domains or taking control of them. On the other hand, the infrastructure based on the blockchain has an architectural feature: all changes in the network are publicly available and can be used to study and track the actions of attackers.

    This paper presents the approach used to map botnets in Namecoin and further track them to extract new IOCs. Using the described approach, lists of assets (see the appendix) used by the botnets mentioned above were compiled.

    Lyrical digression


    Inventions that change the Internet often solve not only and not so much a technical problem as a social one. It is precisely such technologies and services that allow the community to take a look at some axioms that seemed unshakable, rethink them, recreate from scratch, leaving only an idea and dropping the load of legacy conventions and limitations accumulated over the years. Blockchain and Bitcoin, Tor, Wikipedia - behind the success of each of them is a small group of enthusiasts with burning eyes, sincerely believing that they are making a better society.

    Alas, others often come after them - alien to the strange ideals of the pioneers of the Internet, but much more practical. They find an alternative for technologyapplication that the creators did not think about (or did not want to think about). Being on the border (and more often, to hide, openly abroad) of the permissible, this alternative application, often not without the help of the media, for the majority turns into implied by default , or even the only one .

    The equivalence of technology as an idea and the most discussed method of its use can lead to rejection by the society of the technology itself. As a result of the criminalization of its use, an immature service can be reduced to the level of a marginal culture or completely destroyed. So it happened a long time ago with Napster , not so long ago - with BitTorrent and Tor, right now this is happening with Bitcoin.

    This is not past the hero of this work - Namecoin. Namecoin is a blockchain designed to store arbitrary key-value pairs, the most famous of which is a decentralized, censorship-resistant DNS name registration system - Dot-Bit.

    Our interest in Namecoin grew after the RTM botnet management group started using Dot-Bit to manage their C&C servers. At some point, we wondered - is it possible to detect new C & C-servers immediately after they are registered in Dot-Bit? And if there were no problems with the updates of well-known domains, the development of an approach that allows one to detect strong evidence of the connection of new domains with a person of interest suddenly turned out to be an exciting research task, the result of which was this work.

    In general, Namecoin research and the collection of indicators of compromise in Dot-Bit were carried out earlier. The most detailed work can be considered an article by Kevin Perlow . He was the first to draw attention to the fundamental possibility of extracting data from Namecoin and described several heuristic techniques that allow an expert to find domains similar in characteristics to the well-known C&C servers of a particular group.

    The approach presented in this study has several significant differences from the expert indexing and pivoting technique described by Kevin. The heuristic rules we developed for determining domain owners are derived from the principles of the operation of the blockchain and the formation of transactions in it and, in addition to the general description, are presented in the form of strict logical formulations. Together with a formal description of the bypass algorithm, this allows you to automate the search for IOC, which significantly increases the effectiveness of the investigation. In addition, the developed algorithm helps not only to find other names that were once used by the study group, but also allows you to track the creation of new domains that are controlled by the same person.

    All work is divided into three chapters. The first chapter describes the basics of Bitcoin, the code of which was used as a platform for creating Namecoin. Many entities, relationships, and their implementations defined in Bitcoin have been inherited by Namecoin. Their understanding is crucial for further discussion.

    The second chapter is devoted directly to Namecoin and its main application - Dot-Bit.

    The third chapter describes the proposed approach for extracting data from Namecoin, and also gives a formal description of the blockchain bypass algorithm and heuristic rules used to establish relationships between domains.

    The appendices contain IOCs collected using the described method for some botnets, as well as a list of references and repositories that will help researchers who want to continue working on this topic.

    Bitcoin 201


    Most of the information in this section is collected from the materials of the series of articles by Sergey Pavlov_dog Potekhin “ Bitcoin in a nutshell ”. For Russian-speaking readers, this source, in our opinion, is the most comprehensive and deepest publicly available, but it is surprisingly easy to read. Researchers interested in the internal device of Bitcoin, we urge not to limit ourselves to the excerpts given in this section, but to familiarize themselves with the full text of the articles, available by reference in the application. The rest of the information presented below will be enough to understand the description of the algorithm and heuristic rules for finding the relationship between the addresses in Namecoin, given in the last chapter.

    Although it is customary to start the story about the blockchain with blocks and the cryptography that connects them, we will start with transactions.

    Transaction


    As you know, the closest analogue to Bitcoin is an account book in which all transactions with coins are recorded. But, strangely enough, in Bitcoin there is no general table of the form <адрес, баланс>, just like there is no chief accountant who would edit this table.

    Instead, the very notorious blockchain is used, that is, all transactions are generally stored. For simplicity, we can assume that these are messages of the form:

    sent BTC to

    So, if you go around the entire blockchain, you can calculate how many coins “belong” to a particular address.

    Inputs and outputs


    A real transaction on a Bitcoin network is a bit more complicated than the one described above. This is a structure whose main components are inputs and outputs.

    Inputs are transactions to which you "refer". Imagine that three transactions were sent to your address X once:

    TXN_ID: 123456, VALUE: 40 BTC
    TXN_ID: 645379, VALUE: 10 BTC
    TXN_ID: 888888, VALUE: 100 BTC

    If you need to spend, for example, 45 BTCthen you can refer to a transaction 888888or two transactions at once: 123456and 645379.

    Outputs - literally "outputs". We can assume that these are “addresses” to which coins will be “sent” as a result of the transaction. There can also be several exits; each of them has its own amount.

    In the picture below, a new transaction is created Cthat refers to two exits - Aand B. As a result, at the input, the transaction is obtained 0.008 BTC, which are then divided into two outputs - it is sent to the first address 0.001 BTC, and to the second 0.006 BTC.

    image

    The ability to specify multiple exits at once is a very important feature, becausetransaction output can be used as input only once and only in its entirety . If you have an incoming transaction on 10 BTC , and you need to spend 8 of them, you simply create a transaction with one input and two outputs: to the 8 BTC seller and 2 BTC back to your address. If you create a transaction in which the sum of the outputs is less than the sum of the inputs (as in the picture), then the difference is sent to the address of the miner who wrote your transaction in the block.

    Fee


    It is this difference between the sum of the inputs and outputs and the sum is called the "Transaction Fees" transaction fee. It is the second most important source of income for miners, and the time it takes for the transaction to be included in the blockchain depends on it. This is due to the fact that each miner has a certain pool of unverified transactions that claim to be in the block, and, as a rule, the miner simply sorts them in descending order, thereby maximizing their profit. Therefore, the higher the commission, the higher you will be in the queue and the faster your payment will go.

    The general view of the transaction is described in the official specification of the protocol , here one of the most common particular cases is given.



    previous output hash- identifier (hash) of the transaction to which we refer.previous output index- since we need to refer not to the transaction itself, but to one of its exits, then in this parameter we indicate which particular exit we are interested in. Numbering starts from scratch. value- the number of Satoshi ( 1/100000000BTC) sent to the exit. It is written in little-endian form, that is 62 64 01 00 00 00 00 00- it 0x016462or 0.00091234 BTC.

    Parameters block lock timeand sequenceare rarely used in practice. We are not interested in them, so we will omit the description of their purpose.

    But on the parameters with the word scriptin the title we dwell in more detail.

    Script


    The Bitcoin network has a mechanism based on cryptographic algorithms with a public key that allows you to create a system in which only the owner of the key can use the coins associated with the address obtained from this key. We will figure out how this is implemented under the hood.

    To begin with, inside Bitcoin there is a simple stacked programming language called Script. Here is the simplest Script program:

    2 3 OP_ADD 5 OP_EQUAL

    Each instruction is called opcode, there are about 80 in total. The picture below shows the process of executing the above program.











    In Bitcoin, it Scriptis used to set a condition under which it will be possible to spend an output, and to be able to confirm that the condition is fulfilled. Condition ( locking script) is stored in the transaction in the field scriptPubKeyfor each output. Confirmation that the condition is met ( unlocking script) is written in the field scriptSigfor each input.

    To check the right to use the output, you need to connect unlocking script+ locking scriptand run the resulting program as a whole. If after execution the top of the stack remains TRUE, then the transaction is valid.


    Pay to Public Key Hash (P2PKH)


    The script is P2PKHused in most transactions, so you should understand how it works. Here is its general view:



    This script has been known since the advent of Bitcoin, and it is he who performs the task that was mentioned at the beginning of the chapter - to make sure that only the key owner can use the coins associated with the address obtained from this key.

    The idea is this: let your friend Bown a pair of keys - P(private) and K(public). Using the hash function, he gets the address from the public key Aand reports the address to you. Then you send, for example, 1 BTCto the address Aand in the field you locking scriptwrite approximately the following:

    Only someone who owns the private key for the address Acan spend this transaction. As a proof, write down unlocking script, firstly, the public key K, and secondly, the signature of the transaction with the private key P.

    When he Bdecides to use your transaction as an input, he will create his own, for example, on 0.5 BTC, and in the field unlocking scriptwill put the signature of his transaction with the private key P- sigand the public key K - itself PubK.

    Here is the execution process of the combined program:















    Blocks and blockchain


    If the entire blockchain is a book, then individual blocks can be represented as pages on which transactions are recorded. Each block "refers" to the previous one, and so on until the very first block ( genesis block). This is what creates such a feature of the blockchain as immutability. You can’t take and change a block #123so that no one will notice: the blockchain is designed in such a way that it will entail a change in the block #124, then #125and so on, to the very top.

    The structure of the block looks like this:



    The first six parameters (all except txn_countand txns) form the title of the block ( header). The header hash is called the block hash; Transactions themselves do not directly participate in hashing. Responsible for their immutabilitymerkle_root- if simplified, then this is a hash of all transactions in the block. You can read more about the algorithm for constructing the Merkle tree here at this link .

    Nonce and bits are directly related to the process of the appearance of blocks - mining.

    Mining


    Mining is a critical process for Bitcoin, consisting in creating new blocks and pursuing two goals at once. The first is money supply production. Each time a miner creates a new block, he is rewarded for this with the Nth number of coins that he then spends somewhere, thereby launching new funds into the network.

    The second, and much more important, goal is to control compliance with the rules on the network. It is the miners who check the scripts and transaction inputs before including them in the block.

    Those who wish to learn more about the financial foundations of Bitcoin can advise this article . I will not pay much attention to the first aspect of mining and concentrate on the second - checking transactions and launching them on the network.

    Proof of work


    Let you be a miner. You have 10 transactions that you want to include in the block. You check these transactions for validity, form a block out of them, noncespecify 0 in the field and consider the block hash. Then change nonceto 1, count the hash again.

    Your task is to find one noncein which the block hash (256-bit number) is less than a predetermined number N. The search for such a hash is possible only by brute force nonce. Therefore, the faster you want to find nonce, the more power you will need.

    The number Nis exactly that parameter (it is also called target), which the network adjusts depending on the total power of the miners. If tomorrow the blocks begin to come out, relatively speaking, once every three minutes, thenNwill be reduced, the time it takes to search for nonce will be longer and block timewill increase again to 10 minutes. And vice versa.

    This is how the Proof-of-Work algorithm underlying Bitcoin and many other blockchains looks like. With apparent simplicity, it has a number of important characteristics:

    • Creating a new block is a computationally difficult task. At the same time, checking the block for correctness is a simple and almost instantaneous operation.
    • The entire network takes 10 minutes to calculate a new block (on average). The specific time is different for each blockchain, but the bottom line is that the average time is pre-set. Moreover, this time does not depend on the number of network participants. Even if one day there will be a hundred times more miners, the algorithm will change its parameters so that it becomes more difficult to find the block and block timedescends back to the vicinity of the specified time.

      As was written above, the mining process comes down to finding a block hash less than the number called target. In the block structure, this number is written in the bits field. For example, for a block #277316 targetequals 1903a30c.

    As it was written above, the mining process comes down to finding a block hash less than the number called target. In the block structure, this number is written in the field bits. For example, for a block #277316targetequals 1903a30c.

    $ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
    {
        "hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
        "confirmations" : 35561,
        "size" : 218629,
        "height" : 277316,
        "version" : 2,
        "merkleroot" : "c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e",
        "tx" : ["d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f", ...],
        "time" : 1388185914,
        "nonce" : 924591752,
        "bits" : "1903a30c", // <-- Вот он
        "difficulty" : 1180923195.25802612,
        "chainwork" : "000000000000000000000000000000000000000000000934695e92aaf53afa1a",
        "previousblockhash" : "0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569",
        "nextblockhash" : "000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
    }

    In bitsfact, two numbers are recorded at once: the first byte 0x19is the exponent, the remaining three bytes 0x03a30care the mantissa. To get targetfrom bits, you need to use the following formula:

    target = mantissa * 2^(8 * (exponent - 3))

    But it is bits, as a rule, indicated in all online block registries, such as, for example, https://namecha.in/ - Namecoin block registry.

    And yes, enough theory. Everything that we talked about above when applied to Bitcoin equally applies to Namecoin - except for the small differences, which we will talk about in the next section.

    Namecoin


    Namecoin is a blockchain based on the algorithms and source code of Bitcoin, the main idea of ​​which is to use a distributed transaction registry scheme to manage a domain name system, an analog of traditional DNS.

    Namecoin copies the main Bitcoin approaches (Proof-of-Work, 10-minute block generation interval) and data formats, with the exception of small additions, which we will talk about later.

    Namecoin domains have the suffix .bit. This zone was not allocated by IANA and was not assigned to the list of special purpose domains . Regular DNS servers typically respond to such NXDOMAIN requests. But there are gateways from DNS to Namecoin (for example, OpenNIC ), public proxies with Namecoin support, pluginsto browsers, as well as an open source project that allows you to launch your own DNS server with Namecoin support.

    In order to manage a domain with a name, say, facebook.bitit is enough to register a key d/facebook(the d / prefix is ​​used in Namecoin for domains) and determine its value. The JSON format is used to set the values. The entry that sets the domain resolution to IP address 1.2.3.4looks like this:

    {"ip": ["1.2.3.4"]}

    Namecoin allocates names on a first-come-first-served basis . Even for Mark Zuckerberg himself, it will be cryptographically impossible to take the domain from the owner facebook.bit.

    In fact, nothing restricts the use of Namecoin to just managing the DNS name bundles - IP address. Namecoin can be used (and used) as a distributed table to map arbitrary keys to values. But we will concentrate precisely on the scenario of its use in which it represents an alternative DNS over blockchain.

    Domain management


    Namecoin uses a transaction to store a domain record. Namely, the field scriptPubKeycontaining the program is the condition for using the exit of the transaction to which we devoted so much time in the previous chapter. To manage records, Namecoin introduced three new operators (more precisely, redefined existing ones):

    • NAME_NEW
    • NAME_FIRSTUPDATE
    • NAME_UPDATE

    Their meaning is clear from the names, but nevertheless we will analyze the purpose and format of use of each of them.

    You may notice that the domain deletion or invalidation operator is missing. To clean the registry from unused names, a mechanism is built into the network that automatically releases a name that has not been updated for 36,000 blocks (~ 250 days).

    NAME_NEW


    The first step is to announce the intention to register a new name on the network. To do this, it is enough to create a special coin (output) with a weight of at least 0.01 NMC, output scriptwhich will look something like this:

    OP_NAMENEW <20 byte hash> OP_2DROP 

    To demonstrate, I will use the transactions that Stephen Morse made to illustrate his article .

    So, if we want to announce the registration of a name d/stephenmorse, then we need to do the following:



    Looking at the resulting transaction, you can notice two interesting facts. Firstly, despite being output scriptcompiled in Namecoin notation, it is still valid from the point of view of the original Bitcoin. The creators of Namecoin have so successfully chosen codes for their operations that in Bitcoin they correspond to operations that are essentially equivalent to writing to the constant stack. The code NAME_NEW (0x51)in Bitcoin matches OP_1that pushes on stack 1. A similar story with NAME_FIRSTUPDATE( 0x52or OP_2, pushes 2) and with NAME_UPDATE( 0x53orOP_3puts 3). So the first two steps of the script only put two values ​​on the stack. And the next operation OP_2DROPremoves them from the stack, so that it P2PKHworks “from scratch”. Therefore, all those script tricks that we covered in the chapter on Bitcoin are also applicable to Namecoin, despite the redefinition of some operations.

    Secondly, the keys that open a special coin and change are different. Although technically nothing prevents you from using the same key repeatedly, it’s common practice to generate a new key for each receipt. This is done to make it difficult to identify correlations between transactions and increase the level of anonymity in the network.

    At first glance it seems strange that, contrary to common sense, it is impossible to immediately take and register a name plus an IP address for it. This is done so that no one can intercept the name as soon as they see that you want to register it (and then resell it to you).

    For example, miners, analyzing unconfirmed (not yet included in any of the blocks) transactions in the network, could create their own transaction for registration of the same domain and include it (and not yours) in their block. To implement this attack, it is not even necessary to mine your block. It will be enough to put your transaction on the network with a large fee. Therefore, two separate operations were introduced NAME_NEWand NAME_FIRSTUPDATE, and the second can only be carried out by the one who carried out the first, and only after he NAME_NEWgets into any block.

    In fact, this restriction is even a little stricter: NAME_FIRSTUPDATEit is possible no earlier than 12 blocks after NAME_NEW(which is about 2 hours). To understand why the blocks in this restriction are not 1, not 2, not 3, namely 12, we will have to step back a little from the main story and figure out what is forkand 51% attack.

    Fork
    Imagine that miners are looking for a block #123456. And at about the same time, he was found independently by two miners, one of whom lives in Australia, and the other in the United States. Each of them begins to scatter its version of the block over the network, and as a result it turns out that one half of the world has one blockchain, and the other has another.



    Возможно ли такое? Да, возможно. Более того, такое происходит довольно часто. В этом случае каждый узел продолжает придерживаться своей версии блокчейна до тех пор, пока кто-нибудь не найдет следующий блок. Предположим, что новый блок продолжает зеленую ветку, как на картинке ниже. В этом случае те узлы, которые придерживаются красной версии, автоматически синхронизируют зеленую, потому что в Bitcoin (и, соответственно, в Namecoin) работает правило: истинна самая длинная версия блокчейна. Красная версия блокчейна будет попросту забыта, вместе с наградами для тех, кто ее нашел.



    Конечно, теоретически на втором шаге ситуация может повториться и одновременно с фиолетовым найдут еще один, который будет продолжать красную версию блокчейна. И на третьем, и так далее. Но вероятность даже первого форка довольно мала, второго — еще меньше и так далее. Самый длинный форк за всю историю Bitcoin составил всего четыре блока. Так что в какой-то момент одна из веток все-таки вырвется вперед, и вся сеть перейдет на нее.

    51% attack
    На том факте, что в блокчейне самая длинная цепочка — доминирующая, основана атака, носящая имя 51%.

    Представьте, что вы мошенник и покупаете товар на 1000 BTC в каком-нибудь магазине. Вы договариваетесь с продавцом и отправляете ему деньги. Продавец проверяет блокчейн, видит, что такая транзакция действительно была, прошла все проверки и даже попала в какой-нибудь блок, например #123. После этого продавец идет на почту и отправляет вам товар.

    В это время вы включаете свою майнинг-ферму и начинаете майнить, начиная с блока #122. Если у вас достаточно мощностей, то вы можете обогнать всю остальную сеть и быстрее всех досчитать до блока #124, после чего весь мир перейдет на вашу версию блокчейна. При этом свою транзакцию на 1000 BTC, вы не будете включать ни в один из блоков, а значит она будет навсегда забыта, как будто ее никогда и не было. В результате продавец лишится товара и не получит своих денег.

    Гарантировано осуществить такую атаку получится только в том случае, если у вас в распоряжении более половины хешрейта всей сети. Меньшие мощности дают меньшую вероятность успеха. В разделе 11 вот этой статьи приведены вычисления, показывающие, что длины цепочки в 6 блоков достаточно, чтобы снизить до величины ниже 0,1% вероятность успешной атаки злоумышленника, контролирующего не более 10% хешрейта. Эту цифру до сих пор считают общепринятой границей, за которой вероятностью исчезновения транзакции из блокчейна можно пренебречь. Вероятно, создатели Namecoin решили перестраховаться и удвоили эту планку, застраховавшись от атакующих с 20% мощности сети.

    Но вернемся к процессу регистрации доменного имени. Итак, я объявил сети о намерении зарегистрировать новое имя. С момента моей транзакции, содержащей NAME_NEW, прошло 12 блоков, и теперь сеть позволяет мне выполнить NAME_FIRSTUPDATE.

    NAME_FIRSTUPDATE


    The purpose of the operation NAME_FIRSTUPDATEis to publish the name that I announced in NAME_NEW, and specify a value for it. To do this, I need to launch a transaction on the network, the input of which is the very special coin that I generated at the output NAME_NEW. In order to confirm the right to use it, I present in the input script my public key and the signature of the transaction NAME_NEWmade by the private pair key, exactly according to the scheme that we examined in the chapter about P2PKH.

    One of the outcomes of the transaction will be a new special coin weighing, like the previous one, no less 0.01 NMC. Her output script should be like this:

    OP_NAME_FIRSTUPDATE  OP_2DROP OP_2DROP 

    SaltIs the very random number 0xd5eeb22ee8117f57that we created in the first stage of preparing the script for NAME_NEW. Name- it is d/stephenmorsein hexadecimal 0x642f7374657068656e6d6f727365.

    The field Valueshould contain an associative array representing the rules by which the name will be resolved. A complete list of possible keys and rules for filling them out here . In a first approximation, this is an analogue of the zone file; the link above shows the mapping of Namecoin entities to familiar DNS entities. The most popular of them are ip, an example with which was higher, and ns, which we use now.

    To indicate what the NS server will be for the domain, we will 1.2.3.4put a value in Value {“ns”:[“1.2.3.4”]}, but, of course, in hexadecimal - 0x7b226e73223a5b22312e322e332e34225d7d.

    Like last time, close the coin with P2PKH. In his example, Stephen deliberately created a coin at step NAME_NEW with a weight not exactly 0.01 NMC, but with a margin, so that in the next step this margin would be enough for the commission to the miner. In the general case, the transaction will have one more entrance to ensure the commission - and one more exit for delivery.

    We collect everything into a transaction and throw it into the network .



    When the transaction falls into the block, the hosts will update in their tables the value for the key d/stephenmorseon {“ns”:[“1.2.3.4”]}. All browsers with Namecoin support will now resolve the domain stephenmorse.bitand its subdomains to IP addresses through the DNS server located at 1.2.3.4.

    NAME_UPDATE


    The “table” with keys and their meanings, which I mentioned at the end of the last section, is actually called UTXO set (unspent transaction output). Since it is critical for the network to prevent repeated spending of funds, before adding a transaction to the block, the miner checks to see if the inputs previously specified in the transaction were used. To speed up this operation, all unused outputs are stored in a separate data structure. This structure does not exist at the network level, but is calculated and stored by each node locally.

    After I completed the transaction NAME_FIRSTUPDATE, the output of my coin with a weight 0.01 NMC, to which the value for the key is attached d/stephenmorse, hit the tableUTXO. If this output is not spent for 36,000 blocks (which is more than 8 months with 10 minutes per block on average), then it will be considered as invalid, and the corresponding name as free.

    This period of 36,000 blocks (as well as the minimum value of a special coin in 0.01 NMC) is clearly defined at the start of the network and is unchanged. To extend the registration of the name, as well as for any changes to the record or transfer it to another owner, a transaction is used NAME_UPDATE.

    The rules for the formation of such a transaction practically do not differ from those described above. The input for the transaction should be the output of the coin obtained in the transactionNAME_FIRSTUPDATE. An additional input is needed to ensure commission. Of the two outputs of the transaction, one is a new coin with an updated value for the name, and the second is designed to transfer change from the commission. The output script format for the coin is:

    OP_NAME_UPDATE  OP_2DROP OP_DROP 

    As in the previous case, Namethis is d/stephenmorse, and Value- JSON with a value, both in hexadecimal. Close the exit using P2PKH and throw the transaction into the network .


    In general, this is almost everything that I wanted to tell about name management in Namecoin. All that remains is to say a few words about the costs of owning a domain.

    Expenses


    Let's calculate how much the content of the name in Dot-Bit(the name of the DNS zone .bit, which operates on the basis of Namecoin) costs in cryptocurrency and, translating the numbers into fiat currency, is comparable to the cost of a “normal” DNS domain.

    So, as can be seen from the previous section, for a transaction, the NAME_NEWcosts of the domain owner will be 0.01 NMCto create a coin to which the zone will be attached, plus the commission of the miner. For a transaction, a NAME_FIRSTUPDATEnew coin is created at the expense of the old one, and in addition the owner pays only the commission. After about 8 months, the owner will have to complete the transaction NAME_UPDATEto retain the registered name. And this is where the required costs for the first year end.

    Most articles about Namecoin (including the previously cited article by Stephen Morse) are based on data from the first years of the network’s existence and claim that the miner’s commission is 0.005 NMC. But since then, the median value of the commission has gradually decreased and at the beginning of 2019 is about 0.0003 NMC. The NMC exchange rate against the US dollar, on the contrary, having undergone several ups, returned to the level of 2015 and amounts to about $ 0.7 for 1 NMC. It is easy to calculate that the domain in the .bit zone in the first year will cost the owner from 0.0109 NMC or $ 0.00763. Perhaps it will be easier for someone to remember an approximate analogue of this amount in Russian currency - 50 kopecks.

    Well, this is the lower limit that matches the scenario for buying a name for future use or cybersquatting. What about the upper limit? Since the input from each transaction updating the zone should be a coin from one of the previous blocks, the theoretical maximum of the name update frequency is equal to the frequency of the appearance of new blocks. Recalling that the average value of this value was set at the start of the network and is about 10 minutes, it can be estimated that the upper limit of the cost of maintaining a domain will be 15.7744 NMC or a little more than $ 11.

    As you can see, even such a fantastic scenario of using a name in Namecoin at a cost is approximately equivalent to the first year of owning a regular domain in the most popular .com zone. If we compare a more realistic scenario with an update on average once a day, then the name in the .bit zone will cost about 8 cents a year, which is an order of magnitude cheaper than the most advantageous offers in the traditional DNS, which do not fall below $ 1. In the scenario of short-term use of the domain (from several hours to a month), the difference in favor of Namecoin will already be two orders of magnitude.

    Taking into account the financial attractiveness of the service, as well as the anonymity of the domain owner, including the lack of a traditional “money trail” for ordinary DNS, it becomes clear why Namecoin has become a popular network for service owners with an increased risk of disconnection or blocking, in particular botnets.

    Botnets in Namecoin


    Indeed, the fact that botnet operators began to use anonymity Dot-Bitto protect their C&C servers is not surprising. Another thing is more interesting - how long botnets in .bit remain active.

    C&C domains registered in “ordinary” DNS zones are sooner or later withdrawn from the owner, which forces the operator to pay for registering a new name and launch a new bot assembly on the network, with a new management server. The fundamental impossibility of removing a domain in the .bit zone increased the botnet lifetime by orders of magnitude.

    Take for example the pationare.bitdomain registered in December 2016. It was used to control a botnet Chthronic(distributing a banking trojan built on the basis of the famous ZeuS). Distribution campaignChthronicwas associated with the use of the exploit pack RIG and was described in detail by various researchers (for example, malware-traffic-analysis.net ) at the end of 2016 and the first half of 2017.

    It could be assumed that this botnet was destroyed long ago. But no — more than two years after the launch, the botnet’s C & C domain and its network are still active. As can be seen from the screenshot below, the last update was made in December 2018.



    It looks tempting, right? Since the management server’s DNS name remains intact, there is no need to frequently update the bot code and restart the distribution campaign. There remains only the cost of changing the hosting after blocking the IP address, but these costs can also be reduced by using hacked web servers as proxies, the shells of which cost less than a dollar.

    On the other hand, all transactions in the blockchain are publicly available to any participant. As we discussed in detail in previous chapters, coins in Namecoin do not disappear without a trace, which means we can track their redistribution between addresses. And knowing the rules and restrictions, taking into account which transactions are formed in Namecoin, we can find meaningful patterns in which the uniform management of some addresses involved in the transaction will be obvious. In this case, the domains paid with coins from these addresses will have a common owner - the group we are managing, which controls the botnet.

    We will develop this idea further.

    General IOC Collection Scheme


    Let us describe the general search scheme using the example of a real botnet of the RTM group. We will build on this sample , which was identified as Win32/Spy.RTM.N.





    As you can see from the screenshot above, after starting it tries to get the IP address for the name stat-counter-4.bit. We get information about the transaction history for this name in Namecoin.



    The identifier of the transaction that created this domain, we get by clicking on the link to the operation NAME_NEW. The input address of this transaction, with the help of which the domain was created, is obviously managed by the group of interest to us. He will be the initial set of data: N3KPt8py24EAsAiKquyFgoKGyTYeR5Tmry.



    Based on the initial data set, we iteratively go around the blockchain, moving in the direction of its growth (upward movement, or upstream movement). At the beginning of each step, we get a transaction, a certain coin at the input of which belongs to the person we are interested in. In the first step, we check the transaction from the initial data set, the owner of the coins at the input of which we know a priori.

    The transaction is checked for compliance with heuristic rules (we will formulate them below), which guarantee that a certain coin (or coins) at the exit of the transaction belongs to the same person as the known input coin. If the transaction in question satisfies one or more heuristics, then such guiding coins will indicate the direction of further movement. The transaction that spends the guiding coin will be the next step in the iteration.

    At each step of the iteration, we replenish the list of domains that participated in the transactions and the list of IP addresses to which these domains were resolved. These are historical identifiers of compromise (IOC), which can be used for forensists, as well as to identify tactics and grouping methods.

    The movement stops if the transaction in question does not satisfy any of the heuristics. This means that we cannot say with certainty that any of the outputs of the transaction in question is controlled by the person we are interested in.

    Another situation that stops the movement is the lack of transactions from the output address. We will save such addresses in a separate list of unspent coins (UTXO). They represent the greatest value in the entire study. Since we are confident that these addresses are managed by the person we are interested in, any future transaction using these addresses will generate a new, previously unknown IOC — the domain name or IP address — that has not yet been used by the grouping. But with high probability it will be soon.

    To bypass the blockchain, it is convenient to export it to the database. For this, you can use, for example, the modified rusty-blockparser utility , in which we improved support for Namecoin by adding operations recognition NAME_*, data structures Auxiliary Proof-of-Workand expanding the export format.

    The Python pseudo code for the upward movement is presented below. Hereinafter, it is assumed that the blockchain transaction data is stored in MongoDB.

    
    start = "37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16"
    tx = namecoin.transactions.find_one({"id": start})
    def upstream_movement(tx):
      global names
      global IPs
      global utxo
      global known_addresses
      heuristic_result = upstream_heuristic_test(tx)
      if heuristic_result and heuristic_result.guiding_outs:
        if tx.has_name_op():
          names.add(tx.name_op.name)
          for ip_address in tx.name_op.get_ip():
            IPs.add(ip_address)  
        for guiding_out in heuristic_result.guiding_outs:
          known_addresses.add(guiding_out.address)
          tx = namecoin.transactions.find_one({"in.id": guiding_out.id})
          if tx:
            upstream_movement(tx)
          else:
            utxo.add(guiding_out)
    

    The second part of the blockchain bypass is the movement against the growth of the blockchain (downward movement, or downstream movement). In general, the downward movement algorithm is no different from the upward algorithm. A movement begins with a transaction from the original data set. At each step, the transaction is checked for compliance with heuristic rules (in general, different from the rules for upward movement). The only difference is that the coin, whose membership is known a priori, is at the exit of the transaction, and the heuristics guarantee that the same person has one or more coins at the entrance.

    A downward movement also stops if the current transaction does not satisfy any of the heuristics. Unlike the upward movement, we cannot meet unspent coins among the guides, and this option to exit recursion in the downward movement will not work. But, as with the upward movement, we replenish both the list of names and the list of IP addresses.

    Python pseudo code for the downward movement would look like this:

    
    start = "37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16"
    tx = namecoin.transactions.find_one({"id": start})
    def downstream_movement(tx):
      global names
      global IPs
      global utxo
      global known_addresses
      heristic_result = downstream_heuristic_test(tx)
      if heuristic_result and heuristic_result.guiding_ins:
        if tx.has_name_op():
          names.add(tx.name_op.name)
          for ip_address in tx.name_op.get_ip():
            IPs.add(ip_address)  
        for guiding_in in heuristic_result.guiding_ins:
          known_addresses.add(guiding_in.address)
          tx = namecoin.transactions.find_one({"out.id": guiding_in.id})
          if tx:
            downstream_movement(tx)
    

    Now consider the heuristic rules that we will use when moving along the blockchain.

    Heuristic rules


    Common change


    Let's look again at the transaction, a screenshot of which is given above. An address N3KPt8py24EAsAiKquyFgoKGyTYeR5Tmrycontaining money to create a new name is sent to the transaction input . There will be two addresses for transactions NAME_FIRSTUPDATEand NAME_UPDATEat the entrance - a special coin with a zone from the previous transaction by domain and additional funds to cover the commission.

    I will immediately note that in the context of transactions, we will talk about both coins and addresses. Despite the fact that in some works these concepts are considered almost equivalent, it’s important for us to clearly indicate the difference between these terms, since in the course of the study we will draw conclusions about both coins and addresses.

    Saying "coin", we will mean a positive balance formed as the output of a transaction. This coin is identified by the transaction number that generated it and the exit index. For example, a coin at the input of the transaction considered above has an identifier 5778be8e1901e9931e9b41a128a0b7f963e6e1ae72e461df2cba26e6279d433a:1, since it was formed as an output (with index 1) of the transaction 5778be8e1901e9931e9b41a128a0b7f963e6e1ae72e461df2cba26e6279d433a.

    A special coin, as before, we will call a coin with a face value of b 0.01 NMC, locking scriptwhich contains the operation with a domain name. We examined in detail the mechanism for the formation of such coins in the Domain Management section. An ordinary coin we shall call a coin of arbitrary denomination, to which the operation with the domain is not tied.

    The main property of coins is their immutability. Any coin can be spent only once and only in its entirety. Thus, any is mentioned on the Namecoin network a maximum of two times: once at creation, and a second time at expenditure.

    Saying “address”, we will mean an identifier that uniquely identifies a key pair that can open a locking script in a format P2PKHthat closes a coin located at the input or output of a transaction. Since only the key corresponding to the address can spend a coin, the closest analogy of the physical world to the address is the wallet in which the coins are stored (and from which they are spent).

    Despite the fact that in Namecoin an address is often also used only twice, it is not necessary to receive and consume a single coin. The facts of reusing addresses will help us a little in the future.

    We spoke in more detail about inputs, outputs and addresses in the chapter of Bitcoin 201.

    So, two coins are formed at the exit of the transaction. The N2hgZoWaTKoJ7FPmLuytTow3XrCCfEj2casame special coin, weighing 0.01 NMC, to which the domain is bound, went to the address . An NKMMLwyMw4nwGuke6vd3AuDBMP18FWRaF1ordinary coin with change was sent to the second address .

    This is the most common transaction scheme. There are still options when there is more than one coin at the entrance, but their common property is that the coin with change is always exactly the same.

    You can guess that such a transaction corresponds to a simple update of domain information. Payment for updating is carried out using one (less often several) coins belonging to one person. Indeed, since a transaction always has only one author, it must manage all the input addresses. Without this, he will not be able to create an unlocking script, which is needed in order to use the coins from this wallet.

    Well, since all the change from this operation is collected in one coin, it is clear that this coin belongs to the same person as the coins at the entrance.

    A similar scheme for Bitcoin is described in this work , where it is called one-time change. It reflects the method by which native Bitcoin applications conduct transactions - bitcoindandbitcoin-qt. One-time (one-time) it is called because of another feature of these applications. By default, they generate new addresses for coins at the output of the created transaction.

    Namecoin, along with the Bitcoin code base, has inherited the bulk of the code for these applications, which are called namecoindand namecoin-qt. Regarding ordinary coins, we can safely use this heuristic without any changes.

    The statistics of reuse of addresses for storing special coins shows that this rule is in most cases also observed for them. Reuse of such addresses is quite rare. Addresses used more than once, about 6% of the total; more than two times - about 1%. Based on the purpose of Namecoin, it seems reasonable to assume that most transactions with special coins on the network are simple creation and update operations, during which the domain owner does not change. Therefore, we can argue that such an operation corresponds to the withdrawal of a special coin to a new, previously unused address.

    Now let's look at an example of a transaction with a reused address for a special output coin. To do this, take another transaction of the RTM group -b3c7ce9ca3a689c6236b9d6df3c257c5fab6c3985187669ccf731ac42a127a11.



    The address NDpWDEx1mBkUYywqxDTAZZeGCfUV4GkVE8to which the special coin went was already used in previous transactions.



    As mentioned earlier, the default scripts in native client applications for Namecoin do not result in address reuse. To send a special coin to an existing address, the owner will need to make separate, optional efforts, finding out and indicating the exit address explicitly at the stage of transaction formation.

    Why might this be required? The only mention of the situation in which the exit address is specified manually, I met only in the instructions for transferring the domain to another owner.



    The conjecture is confirmed if we consider the further fate of the addresses at the exit of the transaction in question. In the diagram below, this transaction is marked by a bright green milestone. It can be seen that the next transaction 9e16f6beon the stat-counter-4 domain took place using a money address NJ8xUePvthat does not have an explicit connection with the address used in the "parent" transaction. Obviously, the domain was transferred to the management of another person.



    In the general case, this can be either the sale of a domain to another owner that is not related to the activities of the person in question, or the transfer of a domain between the accounts of one person. The second option is the simplicity and low cost of registering a new domain, as well as the lack of visible interest of organizations and trademark owners in registering domains in the .bit zone. We were not able to come up with at least a little justified motivation for buying a domain, noticed in malicious activity. Therefore, we believe that despite the possibility of transferring the domain to another person, transactions with reusable addresses for the withdrawal of a special coin represent a rearrangement of assets between several accounts controlled by one group.

    We formulate the above arguments in the form of a heuristic rule, which we will call common change:

    Если на выходе транзакции находится лишь одна обычная монета, то будем считать, что эта монета принадлежит той же персоне, что и монеты на входе.

    Если при этом на выходе есть еще и специальная монета, то она также принадлежит персоне, владеющей монетами на входе.

    Все адреса, использованные в такой транзакции, будем считать управляемыми одной персоной.

    The scheme for using this rule is shown in the figure. Gray streams - ordinary coins, green - a special coin. The guides will be all the coins from the end of the transaction opposite the coin through which we came to this transaction: all outputs are for upward movement, and all inputs are for downward movement.



    We note several features of this heuristic. Firstly, bi-directional: it works both for the upward movement, when we know the owner of the entrance, and for the downward movement, when we know the owner of one of the coins at the exit.

    Secondly, the optional availability of a special coin: despite the fact that in its absence the transaction is not related to updating the domain, the logical reasoning given above regarding the owner of a regular coin remains valid.

    The pseudo code for testing a transaction for compliance with the common change rule would look like this:

    
    def common_change(tx):
      result = {"guiding_outs": [], "guiding_ins": []}
      if len(tx.outs.money) != 1:
        return {}
      addr = tx.outs.money[0].address
      first_tx = namecoin.tx.find_one({"out.id": addr}, sort=[("block", 1)])    
      if first_tx.id != tx.id:
        return {}
      else:
        result["guiding_outs"] = tx.outs.all
        result["guiding_ins"] = tx.ins.all
      return result
    

    Common spending


    The heuristic considered above has another important property, in addition to bidirectionality. Common change - heuristic "without memory"; the verification result is determined only by the characteristics of the transaction in question and does not depend on the results of other heuristics and accumulated data. Such a heuristic is indispensable in the first iterations of a traversal, for the initial filling of a data set. On the other hand, it is easy to notice the limitations of its application. For example, she will focus on a transaction containing two or more cash outputs.

    As an example of such a transaction, consider db4ff4082f39d0a501508706e627f26aa92712d27b4f633ded59917d201cfae5. This transaction relates to the activities of the group managing the Dimnie botnet.



    We went down this transaction through the addressMy7Ap3nH5f4X6Us2KiUWisd77wRpMG1MDYthat was used in the previous CC transaction as the login address. Despite the fact that his attitude towards the person being studied is beyond doubt, we cannot say the same (as well as the opposite) about any of the other exits and entrances. This may be a redistribution of coins between group addresses, in which case all addresses are controlled by the person we are interested in. Or is it, perhaps, a recharge from the addresses of any of the exchanges selling Namecoin tokens. Or a transfer from another network member who is not related to the activities of the person being studied. It is impossible to make a definite conclusion on the attributes of this transaction alone.

    Consider the addressN4XtLb7xpC4Zk72T8QcshKhTW17ZCyQ1j1at the input of this transaction. This address has already been used previously (“earlier” for a downward movement means “in the future”, “in the direction of blockchain growth”) at the input of a CC transaction 6bffc741eb66de074c09a380fb5e6bd13d4bd5205c36a76e3682674dba08461e, which allows us to consider this address to be managed by the person of interest to us. And since, as has already been shown, the keys to all the coins at the input of the transaction are controlled by one person (which cannot be said about the outputs), we have reason to believe that all other inputs also belong to the group of interest to us.

    The strict condition of the heuristic common spending looks very simple:

    If it is known that at least one of the addresses at the input of the transaction is controlled by a certain person, then all other addresses at the inputs of this transaction are controlled by the same person. Coins at these entrances belong to the same person.

    As you can see, this heuristic makes sense only for the downward movement. When moving in the direction of blockchain growth, we come to the transaction under study through one of the inputs. In this case, the rule condition is satisfied automatically, but does not say anything about the outputs of the transaction and does not allow you to continue moving in the upstream direction. In other words, this is a unidirectional heuristic.

    The second feature of this heuristic, which is worth noting, is that here we first used the data accumulated as a result of checking previous transactions - a list of addresses managed by the person under investigation. For this reason, this secondary heuristic cannot be used for independent movement, without any primary heuristic that does not depend on the accumulated results (such as common change).

    The pseudo code for testing a transaction for compliance with the common spending rule would look like this:

    
    def common_spending(tx):
      result = { "guiding_ins": [] }
      for input in tx.get_ins():
        if input.address in known_addresses:
          return {"guiding_ins": tx.ins.all}
      return {}
    

    Known address


    The last heuristic that we will consider in the framework of this section is the simplest of all. This is a secondary bidirectional heuristic that (since it is bidirectional) can be used for both upward and downward movement. The strict formulation of the heuristic known address for the upward movement looks like this:

    If it is known that the address at the input (output) of the transaction is controlled by a certain person, then the coins received at this address (spent from this address) belong to the same person.

    Although the heuristic looks like a frank truism, this rule helps find branches and intersections in coin flows and adds connectivity to the transaction tree. In addition, it allows you to not stop the movement on transactions that do not fall under other heuristics. An example is the transaction of the 7a35b9cb0a16b3eba92781be014555eaa4255bd17655bb00f2b3f42c3950ac69already mentioned Dimnie botnet.



    Having reached it in an upward movement, we will not be able to move forward with the help of common change, since the output is more than one ordinary coin. Looking at a transaction, we cannot say how many coins in the output belong to the same person as the coin in the input - both, one, or none at all. The use of the known address heuristic allows you to move forward due to the fact that the addressMwMdTb8WQvoRW9jEW5dHn9SkkCJTRn31wQwas involved in the CC transaction cf7ac8986f9855246c6cf26df9a24aa5645cb9258bf787e034a33e75101ae1fcthat created the domain that was met earlier in the upstream movement d/sectools.

    For the sake of completeness, we give the pseudocode of the heuristic known address:

    
    def known_address(tx):
      result = { "guiding_outs": [], "guiding_ins": [] }
      for output in tx.get_outs():
        if output.address in known_addresses:
          result["guiding_outs"].append(output)
      for input in tx.get_ins():
        if input.address in known_addresses:
          result["guiding_ins"].append(input)  
      return result
    

    So, now we have both the general bypass algorithm and the heuristics necessary for moving along the blockchain, so that we can put them together to get some IOC from Namecoin.

    Go!


    We will go through the RTM transactions with the upward and downward movement, starting with 37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16. In the course of advancing on the blockchain, we will collect not only the IOC, but also the transactions themselves that satisfy the heuristics. Coins flows between transactions we visualize using the Sankey chart.

    The full diagram is too large to be displayed in the format of this document, so I will give here only part of it that is necessary for the further story.



    A stream of ordinary coins is highlighted in gray. The remaining colors correspond to the flows of special coins. A separate color is selected for each name. White milestones correspond to transactions that satisfy the heuristic conditions. The bright red milestones on the right are UTXO.

    The chart element that I would like to draw attention to is highlighted with a blue milestone. This is a dangling entry - a coin that arose at the input of a transaction that the algorithm passed on the upward movement, but the transaction that created this coin did not meet him.

    Dangling inputs are signs that the structure under study has side branches that are not connected to the main trunk along which the algorithm moves. In the case shown, this is another independent account. It, as can be seen in the diagram, begins to be used to pay for changes in the domains we already know. From this fact we can conclude that this account is also controlled by the person under investigation. To get the IOC associated with operations on this account until it appears on the chart, we will start a separate downward movement, starting in a transaction with a dangling entry.

    Similarly, in a downward movement, dangling exits may occur. For each of them, we will launch a separate upward movement starting from the corresponding transaction.

    In addition to the transactions of the group that controls the RTM botnet, we also examined the transactions of the groups that control the Shifu, Dimnie, and GandCrab botnets. As a result, 164 domains registered in the interests of these groups and 277 IP addresses associated with these names were found. At the time of this writing, of the collected UTXO belonging to these groups, 39 coins remained in effect.

    The IOC lists, as well as the Namecoin addresses on which the unused coins of the groups remained, are given in Appendix A.

    Conclusion


    Real-life testing is a challenge to almost any technology. By the mid-2000s, Wikipedia had become such a popular trusted source of information, that by changing the texts of articles it became possible to control public opinion, get started, earn money. This period in the history of the service is famous for its enormous revision wars - the aggressive use of the mechanism for correcting articles and the rollback of edits by several warring parties in order to win the dispute over the content of the article. Wikipedia pages turned into an international vanity fair, where everyone wanted to literally say the last word.

    On the one hand, they began to fight the war of amendments, setting special rules that allow, in case of a dispute, to temporarily exclude the possibility of editing the article - until the debaters in the section "Discussion" find a compromise wording. On the other hand, the edit war forced Wikipedia to launch a dynamic mechanism for managing administrators' resources, which allowed them to be quickly involved in resolving conflicts in the hottest areas. Moreover, the encyclopedia took advantage of the public attention that clashes around individual articles drew to it in order to attract more participants to the editing of these articles and achieve the most correct and complete coverage of a particular topic.

    Can Namecoin, like Wikipedia, grow up and cope with its challenge? Wait and see.

    PS Tables with indicators of compromise are available on GitHub .

    Posted by Alexey Goncharov, PT Expert Security Center

    Also popular now: