No matter how many tools you carry as a shinobi, remember, above all things, that you should always have your food on your waist.
—Yoshimori Hyakushu #21
While Hollywood depictions typically show ninjas brandishing throwing stars or a katana, real shinobi developed a vast and eclectic array of tools and weapons, and they were instructed to take great care choosing the right tool for the job.1 All three shinobi scrolls dedicate substantial space to describing secret tools, many of which were innovative technology for their time. Bansenshūkai alone includes five sizeable volumes about tools. It states, among other directives, that the best tools can be used for multiple purposes, are quiet, and are not bulky.2 Shōninki advises shinobi to limit the number of tools they carry, as any piece of equipment has the potential to arouse suspicion if it seems out of place.3 The scroll also recommends that shinobi seek out and sabotage the tools and weapons of their targets; such instruments were of central importance to a shinobi’s capabilities.4
Of course, shinobi did not acquire their tools from any big-box shinobi supply store. Instead, according to the guidance of the scrolls, they made effective tools from items that were easily bought, found, or made. This approach had several advantages. Such everyday items could be carried without attracting much suspicion5 and even act as corroborating props for shinobi disguises. For example, several rulers, including Toyotomi Hideyoshi and Oda Nobunaga, called for sword hunts—mass confiscations of all swords and other weapons from civilians—in an effort to reduce the ability of rebels to attack the ruling army.6 Under these conditions, any non-samurai who wore a sword or other armaments in public could expect to have their weapons seized. To bypass this tactic, shinobi discreetly modified common farm implements to be used as weapons, as there was no edict against carrying sharp farm tools in public. In the hands of a trained shinobi, everyday farm tools became lethal.
For all their practicality, Bansenshūkai asserts that the essential principle of using tools is not simply to wield them but to have an enlightened, Zen-like understanding of their purpose.7 Shinobi contemplated their tools’ usefulness deeply and frequently, constantly training with them and reimagining their uses in the field. As a result, shinobi regularly improved existing tools, invented new ones, and passed this knowledge on to other, allied shinobi.8
In this chapter, we will contemplate tools. We’ll touch on the dual nature of tools—how the same tool has the capability to do good or bad, depending on its operator. This binary in-yo, or ying-yang, concept is a useful model to understand how a hacker approaches digital tools. For example, consider how a tool designed to help a user might be used for malicious purposes.
In addition to possessing good-bad potential, each tool can also be repurposed or applied in different ways. Take a moment to think of a dozen or so ways one can use a hammer. Simple thought exercises like this can help deepen your understanding of what exactly a hammer is, how a hammer might be improved, and how a new type of hammer might be invented to accomplish something novel. These same creative skills can be applied to recoding digital and software-based tools. At the highest levels of mastery, this creative repurposing is analogous to the work of a master blacksmith. The blacksmith can forge new tools, machines, and systems that can dramatically change how they think about their own craft; open up new possibilities around what they can build; and enhance their capabilities to develop new weapons, defenses, and tools.
To be clear, the adversarial use of tools is likely a threat we will never fully escape. That said, in this chapter, I will describe the security best practices regarding tools, as well as some enhanced controls that may mitigate attacks.
In cybersecurity, tools are any instruments that aid the manual or automated operation of a task. If that sounds like a widely inclusive definition, that’s because it is. There are physical tools, such as BadUSBs, Wi-Fi sniffers, and lockpicks, and there are software tools, such as platforms, exploits, code, scripts, and executables. An entire computer system itself is a tool. A tool can have a legitimate use but, in the hands of a hacker, become a weapon. Think, for example, of the SSH client an administrator uses to perform remote maintenance on systems, which an attacker can use for reverse SSH tunneling to attack systems and bypass firewalls.
Much like shinobi, cyberadversaries rely heavily on tools to achieve their goals, and they continuously develop, customize, hone, and test their tools against existing technology in the wild. Sophisticated threat groups employ full-time, dedicated tool and capability developers to maintain and improve their tool set. In response, enterprising cyberdefenders work to reverse engineer these custom tools so they can build countermeasures, implement useful security policies and detection signatures, test malicious tool capabilities in sandbox environments, and create application whitelists that identify and block dangerous tools. In some cases, new defenses are so well applied that adversaries cannot download or install their tools to the target system, as the host-based security immediately quarantines the tools, blocks access to them, and alerts security personnel to their presence.
Because host-based security systems can detect and block specialized tools and malware, many adversaries now practice an infiltration tactic called “living off the land.” Using this approach, attackers first gather intelligence on the software and tools already in use on the target system. Then, they build their attack using only those applications, since the host system’s defenses do not consider those applications harmful. A living-off-the-land attack can use any file on the victim machine’s disk, including the task scheduler, web browser, and Windows Management Instrumentation (WMI) Command-Line Utility, as well as scripting engines such as cmd/bat, JavaScript, Lua, Python, and VBScript. Much as shinobi appropriated common items in the target environment, like farm tools, which they knew would be readily available and blend in, hackers, by co-opting what already exists on the target machine, can turn everyday user and admin tools, applications, and operating system files into tools for their purposes.
One common tool susceptible to exploitation on Windows machines is Microsoft’s potent PowerShell framework. Even Microsoft acknowledges that threat actors regularly target PowerShell to infiltrate systems, perform unauthorized actions, and otherwise compromise an organization’s systems. In turn, Microsoft offers security and mitigation capabilities, such as Privilege Access Management (PAM) to enforce Just Enough Administration (JEA) in combination with Just in Time (JIT) administration. Unfortunately, JEA/JIT turns PowerShell’s ubiquity into an access control nightmare for human IT administrators. How? I’ll spare you the more technical details. Just imagine a technician who is called to come troubleshoot a problem, but is only allowed to bring a screwdriver and can only access that screwdriver between 1:00 and 2:00 pm.
Using access control measures to lock down tools works only if an IT team is willing to severely restrict its own effectiveness. Even then, there’s an inherent danger when these everyday tools exist on the target system—cybersecurity professionals have observed threat actors freeing tools from their local lock with ease. A fact of cybersecurity is this: as long as these sophisticated tools exist, so does the potential to abuse them.
The paradox of having tools is that you need them to operate, but so does the adversary. One approach to this challenge is to reduce the number of tools—in terms of quantity, function, access, and availability—to the bare minimum. While this strategy will make it somewhat difficult for you to operate inside your own environment, with adequate security controls, it should make it even more difficult for a potential adversary. One downside to this approach is that you are weakening the resiliency and robustness of your capabilities to remotely manage your environment. So, if an adversary compromises essential tools by removing or breaking them, your own protections may sabotage your ability to manage and repair the system. For securing tools, the following steps are a good start:
| sc.exe | find.exe | sdelete.exe | runasuser.exe |
| net.exe | curl.exe | psexec.exe | rdpclip.exe |
| powershell.exe | netstat.exe | wce.exe | vnc.exe |
| ipconfig.exe | systeminfo.exe | winscanx.exe | teamviewer.exe |
| netsh.exe | wget.exe | wscript.exe | nc.exe |
| tasklist.exe | gpresult.exe | cscript.exe | ammyy.exe |
| rar.exe | whoami.exe | robocopy.exe | csvde.exe |
| wmic.exe | query.exe | certutil.exe | lazagne.exe |
Where relevant, recommendations are presented with applicable security controls from the NIST 800-53 standard. Each should be evaluated with the concept of tools in mind.
In this chapter, you learned about tools—how powerful they are and why it’s important to keep them safe. You learned about “living off the land” and the complexity of making systems both defensible and functional. You may have also started to ponder the distinctions between tools and malware, as well as how one might program a tool to identify the differences between the two. The thought exercise of the poisoned spindle challenged you to outwit the enemy who’s invading an environment you control.
In the following chapter, we will discuss different techniques used by shinobi scouts—smelling, seeing, and hearing—and what we can learn from them, particularly as we apply different types of digital sensors in our cyber environment.