Friday, January 5, 2018

Extremely Evil Encryption - Tactics for advanced encryption protections.


One of the more advanced tactics for encryption, particularly when the subject wants to throw some complexity/difficulty into the mix is the use of multiple factor authentication/encryption.

Typical encryption systems use passwords and/or certificates for encryption. One of the weaknesses in this strategy is that these can be guessed or obtained in relatively simple ways.

Passwords are a relative novelty these days.. at least in the sense that a vast majority of people use them insecurely or fail to properly manage/use them correctly. Passwords (particularly cognitive ones) can be a pain to crack when properly used. Hash extraction and hybrid attacks can significantly reduce time in this area.

Passwords shouldn't be considered secure by themselves. Combining them with other methods significantly improve their viability and security.

Salting passwords is a good start. Significantly difficult salting increases time, but once again... passwords are merely a time/resources tradeoff. They're still crackable, it just takes more time.

There are a few strategies to sufficiently deter or otherwise protect that encrypted data. I'm going to go over two particularly nefarious ones.


Keyfiles are files that can be used to aid in encryption/decryption. Without a dissertation on this subject, just think of them as an additional "password." They're key materials that are "added" in to the encryption process as an additional control.

Keyfiles can be anything. Common ones are pictures, documents, etc. As securing your data requires storage of that file, this makes it an easier proposition for the attacker. If I can find it, I can try it. A general rule for password cracking/attacking is "the more complex it is, the higher likelihood that it's being stored insecurely and unencrypted, just in case."

Where do I get one?

Hiding in plain sight is a great tactic, particularly when you can virtually guarantee your file will be overlooked.

Forensic examiners are trained to look for anomalies. They're also trained to heavily filter things that appear irrelevant or unresponsive. System files are frequently discarded or filtered out because they clutter up your view.

Enter system files

System files, particularly ones that do not frequently change are a great candidate. You can virtually guarantee that some of these files will remain static over a long period of time. Additionally, the fact that the key file is on MANY computers and widely available in an emergency, they make a great alternative.

This is the difference between "lab" and "practical." In the lab, using a file like this is trivial. In the lab, you have unlimited time and materials. In practical terms, most examiners are over-worked. They miss things. "No one would ever do this." or "I have xxxx files to review.. key locked encryption is very difficult to crack and I wouldn't know where to start." The process of breaking this is tedious. They just don't have the time to invest.

For the person who wants to "stay secure", the management of this key is easy. Memorize the version number, what file you used and grab the matching distribution. It won't show up in most forensic suites and if you do it right, you can avoid the forensic footprints you leave behind.. or at least reduce them. Better yet, the keyfile is sitting out there in a jam.

Bad guys also filter out irrelevant files. If I'm inside a system, I'm on a clock. Throwing up a hail mary like this takes time.. plus you still need the original password. System files are nearly universally filtered out or discarded. Once again, doing it right.. you can make it look like a normal system file access. They need to stay quiet, not draw attention and exfiltrate the data for further attacks. If you're using a system file to encrypt, they may not figure it out. They're looking in the wrong place.

Granted, it's not perfect, but it significantly increases the time and resources needed. The process of cracking in this manner is extremely tedious and time consuming.

You can alter or play with things to make this a little more difficult as well. Using a hex editor or performing minor, manual file changes that you know about can also work as a good tactic. This will change the file hash and set off some alarms. The idea is to stay stealthy and not leave footprints.

Text Files

One of the interesting things about text files is that they don't contain file headers. One of the hiccups that you encounter is file hash analysis/comparison or obvious alterations/accesses of files. A text file is just raw text.

Applying this concept to keyfiles will drive an attacker crazy. It also leaves few traces and can sufficiently obfuscate or disguise your intent. Another interesting facet is that you can recreate this file anytime, anywhere and quickly. If you lose the original key materials, you just have to ensure it matches the original.

So, how do you go about it?

Glad you asked!

Password encrypt your data and use a text file as a key file.

Memorize the text you entered or the sourcing of it. (Doing this on your computer will leave obvious trails either in your file system, allocation table, journal or internet history. Be smart.)

For example, type out a long sentence or use innocuous looking text. A passage from a book, your grocery list, a bunch of code phrases.

Use this as your keyfile and immediately scrub it afterwards. If you need to look at your encrypted materials again, simply recreate from scratch. You've eliminated errors/alterations, scrubbed any evidence that you used it and gave the bad guy an entire filesystem (devoid of the actual keyfile) to crack.

Granted, in a "lab" or with sufficient resources, this is still crackable. In a practical sense, it's exceedingly difficult. You've given someone millions of files to try ALONG WITH A PASSWORD. This is effectively impossible to nearly every attacker (short of a nation-state or excellent cryptographer.)

There are a number of complications to this. If the file is small, on a windows system, it will end up being a resident file. It can end up in the journal, shadow volume or even in file slack. Making this file more than 1k can fix some of these issues. If you overwrite, make sure you're looking at all places it could potentially show up. I won't give up the forensics side of this and exactly how this can occur.

(This is not a posting on how to commit computer crime and hide your tracks.)

You can extend this out to include cloud based files or common pages. Internet archives, innocuous online content and other sources can provide this as well. HTML files work well, just make sure it's retrievable and static. Once again, remember that this can show up in your file system and history.

Making the file content appear innocuous or trivial is key if you can't remove all traces. Done the right way, it's nearly impossible. As always, practice good opsec.

Following these steps can really muck this process up for an attacker. There are a number of other novel ways to do this. I'll probably expound upon this in the future.

No comments:

Post a Comment