Think Before you “Brick”

Over the last year, insurance carriers have looked for innovative ways to expand coverage. One such area is coverage around “bricking”. As the bricking coverage was pushed out, MOXFIVE began receiving an influx of questions around what qualifies as a system being “bricked”, especially as it relates to ransomware incidents where devices have been encrypted and appear to be unusable. As it turned out, the definition of bricking varied greatly between many people, which only caused more confusion for all parties involved.

To help remove that confusion, MOXFIVE created the following blog post which provides the history around bricking, defines the current day meaning of bricking, and gives a work flow to determine whether a system is bricked.

What is Bricking?

The term bricking historically referred to mobile phones. A user would try to gain root access or super privileges to unlock a phone and administer software and other applications not usually allowed on a phone. During some of these attempts to gain super privileges, the user would often cause irreparable damages to the mobile phone causing it to be “bricked”. In those cases, there was nothing further the user could do with the phone and it became a piece of unusable hardware.

Once the term “bricking” caught on, it began spreading to other information systems such as computers. Today, bricking is generally known to have happened when a computer or device’s operating system and / or firmware has been corrupted to the point that the system is no longer functional. Like the term’s origin, the system or device turns into a brick and can no longer turn on or function as expected regardless of best practices to restore the device’s functionality.

Bricking commonly occurs in two forms:

• Overwritten boot instructions or an interruption to the firmware that results in the system not being able to be powered on.
• A soft brick where the system can power on but cannot boot into the operating system. This type of bricking occurs when the operating system becomes corrupted as a result of malicious software, poorly written software, or incompatible software altering or erasing the low-level operating system code.

In many cases, reinstalling the operating system will alleviate common symptoms that are often attributed to bricking. This should be the first step in attempting to restore a system that is believed to be bricked. While rare, there are situations where new hardware may be the only viable or most cost-effective remediation method.

Typical Causes of Bricking

Almost every piece of hardware will have its own firmware that if altered due to malicious software, poorly written software, or incompatible software leads to systems becoming bricked. Any interruption to the low-level operating code can cause data to become corrupted and/or erased, leaving the operating systems in a non-functional state.

In some cases, malicious software alters the foundation code for starting the operating system and in other cases malicious software erases the entire hard drive, both of which result in the system failing to boot. The latter example is most commonly known as a “Wiper” malware that destroys all data on the hard drive. The most notable example of such malware was the Sony hacks. In other cases, if an operating system is running on older hardware and an event or incident occurs such as malware or installing incompatible software, it could also cause a system to brick. This is commonly seen in embedded devices, such as point of sales systems, thin clients, and jump boxes.

Examples above lay out the typical causes of bricking. In recent cases, ransomware has been a topic on whether it can cause or lead to bricking. In most scenarios, ransomware affects data and applications, but does not affect the system’s hardware in such a way that it causes it to be bricked. While data corruption and/or application functionality can be rendered unusable, the underlying system is usually still intact. In some instances, ransomware and associated malware can cause systems to brick as unintended collateral damage. This is typically due to hardware being older or it being an embedded system.

The below diagram provides an easy to follow flow chart on determining if your system may be bricked: