Diversionary Tactics 101

By Jeff Horne ·

When organizations are hacked or infected with malware, an important question they ask themselves is, “Who is attacking us?” Understanding an attackers profile gives your organization insight into their motives, tactics, and what they are after. The more you know about them, the more effective your strategy will be. 

But in most scenarios, hackers want to remain anonymous in order to carry out a successful attack and avoid being caught. Sophisticated attackers even take this one step further and use diversionary tactics to shift the focus away from themselves. They go to great lengths to attribute the attack to another party, sending response teams on an erroneous man-hunt that ultimately goes nowhere. 

Attackers can throw malware analysts and response teams off their trail by adding in clues to the malware that attributes the attack to another party. Below are several tactics:

  • Disguising the intent of the attack.
    • APT-style malware often differentiates itself from commercial malware by its small size and specific focus. By including code to specifically obtain information irrelevant to the attacker’s goal, the attack can be easily dismissed as non-targeted. For example, an attacker could add functionality to malware allowing it to search for banking credentials, when it is really designed to look for and exfiltrate company-specific intellectual property. The malware could be mistaken for a simple banking Trojan, when it is in fact an APT.
  • Including a program database (PDB) file location.
    • A PDB file location can be inserted that suggests the attacker’s identity. I wouldn’t give any credit to a PDB location within a sophisticated or targeted piece of malware, because I would know it was likely left there on purpose and any name, language, or location specific information is likely a diversion.
  • Including information within the code to target a specific group or country.
    • Adding language specific characters or foreign language strings copied from other sources.
    • Using translation services to translate a phrase into another language to be placed within the malware.
    • Copying strings and elements from malware used by a specific group.
    • Reusing code present on development/hacking forums of a specific country.
    • Reusing unique obfuscation algorithms present only in malware of a specific group.
    • Using the same programming language and compiler version as a known malware author. If this is C/C++ and Visual Studio, verify against the generated “Rich Signature.” 
    • Many pieces of malware are easily re-targetable without requiring source code, and can be reused through fixed-length configuration arrays in the binaries or as simple configurations present in the binary's overlay.
  • Including information in the metadata to suggest a specific country.
    • Choosing a PE timestamp that would place the malware’s build-time during working hours of the targeted region the attacker wants attributed with the attack.
    • Involving a ZIP in some way that includes a binary in it. PE timestamps are stored in UTC time whereas the ZIP will store the binary’s file in local time. The difference in the times will suggest an exact time zone to be attributed.
    • Developing and building the malware inside a VM with a version of Windows using the specific language of the targeted country. This helps prevent legitimate information from leaking into the malware, ensuring that PE timestamps, resource languages and other metadata remain consistent with the region targeted for attribution.
  • Associating command and control (C2) with known malware.
    • Using the same communication protocol as an existing malware family and reusing some of its known C2 servers. As the attack is targeted, the malware should never have to end up connecting to the secondary C2 servers.
    • C2 servers are often compromised hosts, so many of these hosts could be compromised again using the same exploitation vector.

In reality, any “mistakes” or “oversights” that clearly point toward a specific party are rarely done by accident; they are intentionally added to point response teams in the wrong direction. 

It is important to note that attackers like to focus response teams on a party that is willing to take the blame/responsibility for the attack. This works to the true attacker’s advantage because the heat is off them, and the case is closed when the “framed” party takes the credit (or refuses to deny their involvement; which is most of the time seen as an admission of guilt). Groups can have different motivations for taking credit for an attack that they didn’t truly commit; a sophisticated attacker will understand these motivations and use them when formulating diversionary tactics.

In sophisticated attacks, finding the responsible party can be next to impossible. Response teams should be extremely skeptical of cut-and-dry information that leads to attribution in a sophisticated attack. It is important for analysts to keep in mind the difference between author and attacker; most forensic clues derived from binary analysis do not in fact point to the latter. Due diligence is needed when investigating an attack to help ensure that the focus is on the true attacker.