Development and operations a practical guide
Download 4.62 Mb. View original pdf
|
- Navigate this page:
- Tools and Tool Examples
| Consider This A phishing attack leading to organizational compromise is NOT the fault of an end-user. Instead, it is the insufficient security controls of a target environment! As noted above, Social Engineering simply works. Users are often provided many different types of training on social engineering, phishing, information security, operational security, etc however, a well researched, constructed, and targeted phish will be successful inmost scenarios. This idea has been proven multiple times by multiple professionals with multiple write-ups on techniques and successes. A well-planned phish avoids common indicators of phishing, does not alert the user to malicious intent, and can ultimately provide threat access to the end user's system. Combined with a threat's effective use of good tradecraft, the user has no "indicators of bad. At this point, the user's responsibility ends. Anything beyond (and arguably including) the initial compromise of the end user's system is the responsibility of the organization. For all intents and purposes, the threat has become a logical insider. If the threat has the capability to move laterally throughout the network, elevate privileges, access sensitive information, exfiltrate data, or cause operational impact so do other (perhaps all) users within the organization. It's likely they just don't know how. Tools and Tool Examples A Red Team can and should use any tool that supports its end goals. Although many Red Teams use the same tools used by penetration testers, this does not mean tools are employed the same or chosen carelessly. A team must understand the capabilities and limits of a tool. The team must have the ability to control or tune a tool to fit the needs of an engagement not only in technical capability but also the ability to tune a tool to model a specific threat. The choice of tools may lead to custom development, the purchase of commercial tools, or the simple use of builtin operating system commands. In the end, the toolset is chosen based on a Red Team’s goals. The way a Red Team uses common security tools can be quite different from the way of other security testers. A Red Team often needs to customize the code to ensure it performs in a specific way or change the indicators a tool may leave behind. At a minimum, a good operator must understand how a tool functions and what impact or risk is introduced to an engagement. Good Red Team operators maintain control over their actions. This includes how, when, and if a tool is used. This section refers to many common tools used in the security community. Many of these tools are older or not appropriate for modern Red Teaming engagements. The purpose of discussion is to provide context in Red Teaming. Download 4.62 Mb. Share with your friends:
|