The term Coventry Conundrum is sometimes used to refer to the dilemma faced by intelligence analysts as to whether to take action on knowledge they’ve obtained, because doing so might reveal what they know. The term comes from an incident in WWII, where British intelligence supposedly learned that the city of Coventry was going to be attacked by a large air raid from Germany. They could inform the city of Coventry of the coming attack and save the people of that city, but the Germans would realize the city had been evacuated, which would inform them that the British knew of the coming attack, which may have led them to realize the British had cracked the Enigma code, which would cause them to use something other than Enigma, which could ultimately have caused the British to lose the war. Whether any of that is true or not is unknown but it’s where the term comes from. This concept played a part in the movie “The Imitation Game”, but in the movie, they discussed a ship that would be torpedoed.

This same problem can come about in infosec. A very important, but very little talked about, concept in end-point security is not letting end-points know what you are looking for. This is one of the benefits of collecting data from end-points and then scanning that data with Threat Intelligence.

Imagine someone has told you about a new threat actor and given you a list of indicators that you could use to look for them. Let’s say some indicators are if the process is named evil.exe or bad.exe. Using various agent based solutions you could sweep your network in order to look for those indicators. You could ask each host “Is evil.exe or bad.exe running?”

However, you might have an attacker on one host that has disabled your agent, and is monitoring the requests you make to the agent. The attacker now knows you are looking for evil.exe and bad.exe and knows to never name his processes that, thereby making it even harder to find that attacker. Instead of finding the attacker, you’ve just let the attacker know what Threat Intelligence you use. You just gave away your own defensive TTPs (Tactics, Tools, Procedures).

So you see, if you send your Threat Intelligence out to every host in order to scan them, then you risk having an attacker learn what Threat Intelligence you have. Therefore, it is best to collect information from systems and then scan it with your Threat Intelligence signatures on your trusted network. Projects like Google’s GRR and Facebook’s osquery allow you to do this remote collection across your networks.

This is not security by obscurity. An attacker could know you monitor what IP addresses your systems communicate with, but they don’t know what IP’s you generate alerts for.

Ideas for when you need to query hosts

Unfortunately, there are some things that are hard to collect that you might want to check, or your collection tool might not be capable of collecting certain data. So you’ll have to weigh the risks, when considering querying your hosts.

Some things you could consider doing instead of querying every host for “Is evil.exe running?”:

• Collect more data than you need, then analyze that data. Ask “What process names are running?” and then check locally if any of those are evil.exe.
• Be loose in your questioning and iterate. Ask “Do any process names end with the letter ‘l’ before the extension?”. This may throw False Positives, but it could also rule out this threat, or reduce you to a subset of systems to check more thoroughly, at which point you could then ask another question to potentially reduce the set further. For example, “Do any processes have four letters and end with the letter ‘l’”?
• Obfuscate what you are looking for. Two techniques you can use, which work best in combination are:

  • Check for a hash of the data. Ask “Do any process names match the SHA1 a9993e364706816aba3e25717850c26c9cd0d89d?” The attacker can check if his process names match that, but it helps obfuscate things.

  • Send deceptive information. Ask “Do any process names match devil.exe, evil.exe, bad.exe?” Then an attacker won’t know you’re looking for him specifically.

• Ask loosely matching questions that are tight for your environment. Similar to checking for hashes and asking loose questions, instead of looking for a very specific SHA1, you could check for a loose hash that happens to be very specific for the given dataset. For example, if you know most of the processes you would normally find in your environment, you could check if any of these, when every letter is xor’d, match the value 0x40. In this case 'e' xor 'v' xor 'i' xor 'l' xor '.' xor 'e' xor 'x' xor 'e' = 0x40, as will many other strings, but it may be very rare in your environment for that to match on anything other than your threat.

  Exploit authors have used this technique in order to generate compact shell-code to search for export function names. Instead of looking for the whole string LoadlibraryExA, they will look for the hash 0x726774c as explained by The Last Stage of Delirium (LSD) in their paper “Win32 Assembly Components” available on their site. They obtain a list of all possible function names, then create loose hashing algorithms that they can ensure will only match on the value of interest to them. Similarly, Duqu 2 uses this technique to find the Kaspersky process on the system. From Kaspersky’s report:

  “Next the code iterates through the list of running processes and hashes lowercase name of each process. The hash is compared to a hardcoded value of 0x3E3021CB, which is a hash for the ‘avp.exe’ string.”

Conclusion

In general, I recommend not worrying about this. I don’t know of any malware, or examples of attackers, that monitor defensive products once they get on a host. In cases where an attacker cares at all about defensive products, they do one of the following:

• Bail if they find one.
• Try to kill the product.
• Try to exploit it to obtain better “privileges” where that may simply mean being in a trusted process, as was the case of Duqu 2.

So be aware of this, but it’s mostly just an intellectual game at this point to consider the options, and it’s better to try to find an attacker than to not try at all.