Sleeper Malware Clobbering Everything: Maybe Add Transaction History
» Email someone you know about this article.
To prevent malware from infecting your computer, you must prevent sleeper malware from infecting your computers, backups, and mirrors. Sleeper malware is malware that sits quietly and does no harm until it wakes up, maybe seconds or months later. It can make your whole intranet and all your backups and mirrors useless or harmful.
A bad actor could send you bad software, lock up your software, and have their will with you. If it’s ransomware, they refuse to unlock it until you pay them. The software sneaks in, getting past your defenses.
A sleeper version is the same except that it does nothing for the time being. It does nothing noteworthy, or nothing at all, so you don’t know about it, so you don’t remove it. Even security software that monitors your software’s behavior for maliciousness doesn’t see any behavior during a program’s sleep, so it doesn’t protect you and you don’t know a problem is lurking under the hood.
It might be copied into other computers on your network. That depends on permissions found at the other computers (permissions by any name). For example, a text file may be allowed but a program not let in, or let in but not allowed to be run as a program. This risk is bigger if sleeper malware is copied to one machine and then to machines that are inferior to the first recipient. For example, in one organization, if the president’s computer is infected, it may be easy for the president’s computer to infect vice presidents’ computers with no one noticing.
Since no one sees the sleepers, your mirrors immediately receive it, too, so that if you switch to using a mirror, such as if your main hard drive breaks down, the sleeper is also on every mirror. It’s still harmless, but only because it’s sleeping for the time being.
Your backups also include it. While mirrors conform to your main storage within seconds to minutes (usually), backups might be made only once a day, or once an hour, or once a week, or on some such schedule that you probably set ahead of time. Some stay in the network, some are made and then disconnected from the network but kept on the premises or conveniently nearby, and some are made and disconnected from the network and then taken offsite, perhaps thousands of miles away, using a separate network or physical transportation system. (Backups are unlike mirrors because mirrors are always connected to your principal system, so they can be put to use anytime.) Eventually, you make room for new backups by erasing the older ones. Commonly, backups are up to a month old. If the sleeper is still asleep for a couple of months, it’s likely everywhere, in all of your backups, all of your mirrors, and maybe all of the computers on your intranet (your network).
Now the sleeper can wake up. Maybe it’s got a schedule built in; maybe it’s supposed to wake up on a certain day, or when 100 days have passed since infection, or some such internal timing. Maybe it responds to something another one of your programs does without malicious intent, maybe something that doesn’t happen often, like maybe something an operating system would rarely do. Maybe it checks files for a change in state, like if a certain name is no longer in the payroll. (It’s a sleeper, so it shouldn’t check the payroll right away. It can wait 100 days before it starts visiting payroll files.) Maybe it responds to some input, like from a keyboard, the input usually disguised as something benign, and maybe the input really is benign but is also accepted by the sleeper as a malicious signal. Maybe it responds to some input as a suppressor, such as if 100 days have passed and then must receive an input treated as a suppression signal at least once a week, or else do something bad. (Trains may have a dead-driver control, so that, for instance, an engineer’s failure to adjust some ordinary control or failure to touch a panel, one or the other at least once every 20 seconds, means a loud horn blasts, and if there’s still no action the train stops, just in case no one alive is at the controls.)
Whatever method it uses, it wakes up. Maybe it calls home. Maybe someone in another nation gets that call, and replies with “start the damage”. The sleeper encrypts your files (if it’s not ransomware, maybe the damage is without encryption) and calls home again (“mission accomplished”). When it’s told by the far-away mystery person “good job”, the malware executes whatever bad action it’s designed to do. Maybe it displays a dreaded message on your screen, complete with instructions on how to pay the ransom and how soon.
And soon it will be, because someone won’t want you to have time to fix the problem without paying. Besides, they want the money. Almost no one imposing ransom gets hauled into court, so law enforcement is probably not a major option, so your only realistic options are fast ones. Either you pay or you don’t. Either the ransomer decrypts your files or doesn’t. Either you solve the problem without paying ransom — or you don’t.
Say you try to solve it entirely within your organization. This is for any kind of malware. You search the hard drive for it. But you don’t know what it looks like. Not one file is called “malware.exe”. You can’t compare it to original installation media, because those are likely compressed or nonexistent (like if you installed from someone else’s server) or the installation process included settings that were too complicated for you to figure out which files your installation was supposed to write to your media. All the file names are benign or meaningless. And maybe the sleeper was inserted into an already existing file, either enlarging its size (when you don’t know what size it should be) or overwriting part of it (so the size doesn’t change although the file is probably now damaged). You have no idea what to delete or replace. And that’s if you can see anything meaningful, if the malware encrypted your hard drive.
You switch to a mirror. But it’s got the malware, too. No good.
You try the latest backup, the one that will be least disruptive of everyone’s work, since they’ll have to reconstruct whatever work they did since you made your last backup. But it has the malware, too.
You go through older backups, from younger to oldest. All are infected. No good; no good; no good.
You can erase everything, tell everyone all their files are gone, do a clean installation; or pay up; and then talk with your lawyer about your coming testimony and announce your new restaurant’s grand opening.
Solution
A way to be able to get out of this without paying ransom or suffering other damage, although requiring a substantial budget, is to compile a transaction history, starting from just before the last clean installation. This requires a lot of storage.
In the transaction history, no file would ever be changed. Instead, you would record that a change would have occurred. For instance, when a database is changed by a person’s record being deleted, the transaction history would show the database being created followed by it being populated one step at a time followed by a separate instruction for finding that person’s record in the database followed by a separate instruction for deleting that person’s record from the database. The history would not have a copy of the database but detailed instructions for creating and editing it. The same is true for all other kinds of files. Therefore, if there’s a mysterious file in there, it’ll stick out like a sore thumb. So, you apply the transaction history in chronological order to rebuild your files but you skip the sore-thumb files and steps.
The transaction history needs annotations, either in the history or in a parallel set of files. For example, if you’re about to reformat the main hard drive and do a clean installation of the operating system and applications, you need to annotate that you’re doing so from just before you start until you’re done with that process. That way, if mysterious files and steps turn up in the history, the annotations will explain them. The annotations likely have to be manual, at least written on another computer.
Some software installations would effectively be done twice and sometimes that will fail, because the software was designed so that multiple installations would fail, often because you paid only for a license to run one copy. The annotations would inform you of the multiple-installation situation, so you’d know what to do the next time: install from installation media or a comparable source, not from the transaction history. If your license is for, say, five copies, after installing once and making a transaction history your license may only be good for three more, not four; that loss of one is an expense.
Versions will matter. Occasionally, a feature is dropped or modified. So, recovery may have to be with an application’s version 0.5 until version 1 was installed, and only the annotations may make clear when that was. (A version like 0.5 is a beta version, which may be unstable, which may cause difficulty when reconstructing its output. By convention, any positive version number less than 1 is a beta version.) Even so, using an old application could be impossible. A manual or support may be unavailable. A software supplier may refuse to ship an old version even if it exists. Even if they have some older versions, they may not have all of the older versions, especially what they consider to be minor ones that were subsequently patched, especially those with known security flaws the supplier is unwilling to reintroduce to any customer, lest the supplier be sued. (An alternative is that you could buy the supplier’s whole company. Microsoft, lock, stock, and barrel, is a shade over a trillion dollars. Pass the hat.)
Passwords and other confidential content either have to be edited so that what’s confidential is replaced by representational placeholders in the transaction history or is copied but is secure. If you doubt how well you can maintain the security, editing is an option, but if editing is possible for you to do then it’s probably possible for malware to do, too.
Carrying out recovery will be complicated. Applying a transaction history for, say, a database would likely require database management software or a complement capable of applying a transaction history to rebuild a DB. If the DBMS is proprietary and lacks such a feature, recovery may be impossible except by hand, and it may not be feasible to do a manual recovery through the hand of more than one person per database. That’s labor-intensive, and it takes time. And it’s likely that applying the transaction history would be for files maintained by multiple applications at once, all of which will need recovery features unless manual reconstruction is performed; and, for a given file with a generic filename extension, which app is right may require human intervention.
The annotated transaction history should be backed up and perhaps mirrored.
A Plainer Half-Solution
This is potentially so expensive to implement that you may have no good way out.
The best idea may be to rely on how malware injectors likely operate. Some system owners refuse to pay, no matter what (a debatable decision). The bad actors, therefore, won’t always get money. So, they tend to enter many potential victims’ systems, so they’ll get money from some. That strategy requires some skill and resources but not top-level skill and resources. They, therefore, rely on scanning many systems to find those with low security or maybe average security. If your system has higher security than they can crack, that may be good enough protection. That won’t be sufficient if yours is a high-value target of interest to highly-specialized highly-funded attackers, but most of us are not quite that valuable in anyone’s eyes.
None of these are great choices, but they’re available.
