You are viewing 'toolkit'
Many types of red team and physical security assessment toolkits are utilized across the industry. Through our experiences in the NTT Security Threat Services group, we have developed a mixed bag of devices and tools that we commonly use with hybrid assessment types.
The lists below are not intended to be comprehensive, but a quick reference for red team specific toolkits - which often include technical devices and physical tools.
As always, it is assumed that you have permission from your client, have the proper documentation on hand and the defined scope is your primary consideration before attempting to compromise a target facility. Please make sure that you have plenty of experience with bypass and lock picking tools in order to reduce the risk of damaging doors, locking cores and mechanisms etc. Always be... read more >
Find out how ELMO can assist with a live incident response situation
In most incident response situations, it is necessary to collect some form of volatile data. While disk forensics continue to play a role in incident response, we know that the tactics of today’s adversaries require different methods from incident responders. One of those tactics is live forensics to capture volatile data.
Much like traditional “dead box” forensics, most investigators will agree that no single tool can meet the needs of every investigation. Instead, investigators commonly use multiple tools to gather information based on the needs of the investigation. Some examples are memory acquisition, running processes, network connections and open file handles.
Running these tools in a Windows environment is most often achieved by scripting multiple tools through the use of a batch file. This achieves several goals. First, it allows the investigator to execute a single file, which will run multiple tools. Second, it ensures that all tools are... read more >
You are only as good as your toolset!
In my last blog I asked the question, “Have you ever tried to chop down a tree with a fork?” and told you about an incident response process that was made difficult by the lack of adequate tools. This is a common problem in the field of incident response and security as a whole, and shouldn’t exist. Unfortunately, however, many system administrators, network administrators and help desk personnel assume they can handle an incident, when in reality it is far more complex than they are aware.
A basic introduction to incident response is beyond the scope of this blog, but I do want to introduce the reader to the “Order of Volatility.” This is a common methodology that is taught across the security spectrum. It provides the responder with the ability to gather evidence from the more volatile to the less. This is extremely important when responding to breaches or malware infections. So, let us review the... read more >
Black Energy (BE) malware is back in the news as of early January 2016. This time it is being blamed for contributing to a power outage on December 23, 2015 in Ukraine, which left nearly half the populace in the Ivano-Frankivsk region without power for several hours.
Discovered in 2007, BE was originally designed as a distributed-denial-of-service (DDoS) toolkit but has since evolved to its current state, supporting a multitude of plug-ins. The newest features of the BE malware include:
- KillDisk, a destructive data-wiping utility capable of destroying an estimated 4000 file types, including registry files. This function could render the host unbootable, and depending on the infected host, could have dire consequences. Based on the malware’s typical target set of Industrial Control Systems (ICS), an infected host could prove to be disastrous, not to mention expensive.
- Researchers also identified a previously unknown Secure Shell (SSH) backdoor...
Hacked Apple toolset delivers thousands of infected apps
“Trust no one,” goes the mantra of a great 1990s TV show, The X-Files.
Some things, however, we nearly always trust. A carpenter trusts that his hammer will drive a nail, and if it doesn’t, the reason is usually obvious. All craftsmen have to trust their tools, because we don’t have the time to build our own hammers and ladders. Yet for software developers, this means trusting very complex tools we can’t easily validate.
The most important software tool is a compiler, often part of an integrated development environment (IDE) with a debugger and other tools. These tools are like a genie, translating a programmer’s wishes (source code) into something that does his bidding (binary machine code). But sometimes the genie is a bit of a devil. I’ve personally found compiler bugs, cases where it didn’t translate my source code accurately. My own... read more >