Photo by Jakob Owens on Unsplash

Photo by Jakob Owens on Unsplash

Discovering indicators of compromise

Reconnaissance

Article from ADMIN 49/2019
By
Open source pen testing tools help you view an attack from the perspective of both the attacker and the defender.

Quite a lot has been written about pen testing and hacker lifecycles. Over the past few months, for example, I've written a couple of articles for ADMIN about penetration testing: one about automated tools for pen testing [1] and the other about improving defense through pen testing [2]. However, comparatively little has been written about the knowledge, techniques, and tools necessary to analyze an attack or pen test as it occurs (i.e., the "other side," as it were, of an attack).

Indicators of Attack and Compromise

Before I stampede into the tools an analyst uses, it's important to identify an essential principle of the security analyst: As an attack occurs, certain things are left behind. This concept was first articulated by Edmond Locard [3] almost 100 years ago, well before the first modern computers were created. In fact, the concept that attackers leave behind signatures and traces is named "Locard's Exchange Principle."

The defender – in this case, the security analyst – needs to figure out what indicators of attack (IoAs) and indicators of compromise (IoCs) were left behind. An IoA is evidence left behind even if a particular attack doesn't lead to a break-in or data breach. An IoC is evidence left behind if an attack has successfully tricked or breached a security control. For example, an IoA could be a system scan or an unsuccessful attempt to create or exploit a buffer overflow condition. An IoC could be a case in which an attacker was able to exploit a buffer overflow successfully or otherwise gain unauthorized access to a system – same activity, two perspectives, and two sets of tools.

According to the Exchange Principle, Table 1 gives a quick overview of the tools that pen testers and security analysts use. This "quick and dirty" table is nowhere near perfect or thorough, but it's sometimes useful to think about the same activity – hacking – from two different perspectives. This model isn't perfect, because, after all, a pen tester can use Wireshark just as effectively as a security analyst. The pen tester, though, simply would use it in a different way.

Table 1

Security Tools

Pen Tester Security Analyst
Discovery tools – open source intelligence (OSINT) tools, Nmap, Maltego Packet capture tools – Wireshark, tcpdump
Exploit tools – Metasploit, Meterpreter, and BeEF Security information event management and intrusion detection – AlienVault, Splunk, Bro, Snort, OpenWIPS-ng, Process Explorer
Crackers – John the Ripper, THC Hydra Logs, log analysis tools, and system analysis tools – Regshot, WinMerge, Lnav, Lynis, DiffNow, CyberChef, ManageEngine
Kali Linux or Parrot – Debian Linux; includes many tools Security Onion – Debian Linux; includes many tools

Red Team/Blue Team Exercises

In my experience, pen testers are often called "red team" workers and security analysts "blue team" workers, often because pen testers and security analysts work together in teams during security exercises or war games.

Sometimes, these exercises are conducted to upskill a team of security workers. However, I've found that the most proactive, forward-thinking companies use these exercises to help preprogram and reprogram automated security tools, because the best reason to have pen testers isn't really to play "whack a mole" to try and find hackers or weak systems: The real reason to have pen testers is to improve the quality of the security analysts.

Several companies I know regularly conduct exercises that generate various IoAs and IoCs so that the security analysts can identify them in real time. In this way, security analysts can help fine tune their intrusion detection system (IDS) and security information event management (SIEM) tools.

Isn't There an App for That?

Over the last five years of traveling around the world talking with IT techs and cybersecurity workers, I've asked them about "killer cyber analytics tools." Invariably, they talk about monitoring logfiles and system processes and reviewing packet captures. At first, this kind of surprised me, because I thought that they would tell me about nifty, cool SIEM tools and host- and network-based IDS tools, such as Snort, Suricata, and Bro. Pretty consistently, the security pros I've talked to tell me that, although these tools are, of course, very useful and essential, you can't just "plug and pray" these systems into your network or network hosts. You have to pre-program them with information (i.e., customize them).

The best way to get this customization info is to break out the tried and true tools, so I'll take a quick look at these tools and then look through an applied example of what a security analyst does with them. (See also the "Steps in the Hacker Lifecycle" box.)

Steps in the Hacker Lifecycle

First, no single, perfect hacker lifecycle can be described, but you can see quite a few useful pen testing/hacker lifecycle models, because pen testers and security analysts alike customize the lifecycle according to the systems and organizations on which they work. Two of the more popular models include:

  • The Cyber Kill Chain copyrighted by Lockheed Martin [4].
  • The Mitre ATT&CK model [5].

Just as a good hiker uses different clothing and equipment according to the conditions of the terrain being navigated, you need to modify your model and paradigm according to the current conditions. Nevertheless, make sure you understand the various stages: discovery/reconnaissance, weaponization, delivery, command and control, exploitation, persistence, and data egress – not necessarily in that order.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus