CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Bitcoin Transaction Malleability Theory in Practice – Ruxcon Australia 2014

Two weeks ago we gave a talk at the Ruxcon 10 conference in Melbourne, Australia titled "Bitcoin Transaction Malleability Theory In Practice". Despite having the same title as our Blackhat USA 2014 talk, we came to Melbourne with some new insights that we'd also like to share with you here on the SpiderLabs blog.

During the presentation we demonstrated one type of transaction malleability involving the manipulation of the length part of the "Scripsig" using PUSHDATA Opcodes (PUSHDATA1, PUSHDATA2 or PUSHDATA4), thus changing the hash of the transaction without harming its validity.

The block chain is the best place to look for signs of transaction malleability attempts that happened in the past. Tracking the demonstrated type of Transaction Malleability is also quite simple. All one has to do is search for transactions that use the PUSHDATA Opcodes redundantly.

We have used the following Python code to track suspected malleable transactions:


Figure1: Searching for transactions attempting to exploit Transaction Malleability

This code inspects the value of the first byte of Scriptsig. If it detects the use of one of the Opcodes (PUSHDATA1, PUSHDATA2 or PUSHDATA4), then it evaluates the length field. If this value could be represented without the use of this Opcode, there is a high probability that the transaction is attempting to exploit transaction malleability.

If, for example, the code detects the use of PUSHDATA2 (0x4d) Opcode at the beginning of the Scriptsig and the actual length denoted by the length field is lower than 0xff, then the use of that Opcode is redundant. It's redundant because the length of the Scriptsig could have been expressed by a single byte length field, and therefore the code marks this transaction as a malleable transaction.

We've searched the block chain for malleable transactions in the past year and a half and the results were quite surprising. In the following chart you can see a tremendous uptick in the use of "suspected" malleable transactions during February 2014:


Figure2: Malleable transactions accepted to the block chain

Basically, no-one used this technique either before or after this short period of time. A closer look tells the whole story:

Figure3: Zoom in on February 2014

Apparently, after the announcement that Mt.Gox was the victim of a Transaction Malleability attack, a lot of attempts were made to steal money through the Bitcoin network.

The total number of transactions that were mutated and inserted successfully into the block chain is approximately 5,585 transactions with approximately 60,000 Bitcoins involved and with more than 9,000 unique wallets addressed.

When taking a closer look at the suspected malleable transactions we were able to find, based on the source of the wallet address of the incoming Bitcoins, who were the targets of those so-called malicious transactions.

In general, according to our findings, the targets of the various malleable transactions could be divided into four main groups:


  1. Bitcoin betting services such as "SatoshiBones" and "SatoshiDice"
  2. Bitcoin trading services such as "BTCe" and "BITSTAMP"
  3. Testing
  4. Wrong usage of the attack


According to our findings, however, most of the attempts to attack those targets failed and didn't generate high revenue for the attackers. According to our calculations, the total amount of stolen Bitcoins is approximately 116 Bitcoins, which is much lower than the potential of 60,000.

The chart in Figure 3 shows that after February 11, 2014 the total amount of mutated transactions, which were successfully inserted in the block chain, has practically zeroed. Although the formal patch to the Bitcoin client was released only a month later on March 19, 2014.

We don't know for sure what caused this sudden drop but we do have two main theories that if they occurred simultaneously could explain what happened:

  • After the Mt. Gox announcement, trading and betting sites were extremely cautious - double-checking every transaction coming their way trying to avoid the transaction malleability scam. Therefore, most of the attempts to steal Bitcoins from those sites failed, which caused the attackers to give up on the attacks.

  • On February 11th, a fix to the transaction malleability was committed to the Bitcoin client code. We believe that the biggest mining pools applied this fix immediately and didn't wait for the official patch. Since those pools cover most of the mining power of the Bitcoin network , the effect was immediate and almost all of the mutated transactions were filtered out.

Although the patch to the Bitcoin client was released almost a year ago, it still doesn't guarantee that other types of transaction malleability will not pop up in the future. Since this problem is critical and has already caused damage to Bitcoin trading sites, we recommend that all companies dealing with Bitcoin rely on something else in addtion to transaction IDs when tracking the route of Bitcoin money. Especially when it comes to rejected transactions. In those cases, before generating a new transaction to compensate over the failed one, it is important to check for the rejection reason and to check whether another transaction with a different transaction ID didn't already pass the same amount of Bitcoin to the same wallet. This "double check" is important to avoid a heist.

To see our live demonstration of a transaction malleability please refer to our previous blog post.

This blog post was written by Daniel Chechik and Rami Kogan.

Latest SpiderLabs Blogs

EDR – The Multi-Tool of Security Defenses

This is Part 8 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

The Invisible Battleground: Essentials of EASM

Know your enemy – inside and out. External Attack Surface Management tools are an effective way to understand externally facing threats and help plan cyber defenses accordingly. Let’s discuss what...

Read More

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More