Investigation Operational Security Tips

Operational security during an investigation is extremely important and there are a couple tips I’d like to share. While they may seem obvious at times, it’s imperative that they be kept in mind during an emergency or a normal investigation, especially for those organizations without a dedicated incident response team. Cutting corners in order to save time or ignoring some basic rules can compromise and inform unwanted individuals of your investigation.

1. DNS Requests

A common practice in many investigations is to gather information and observe a suspicious domain, if one is involved. While this preliminary information gathering can be beneficial it can also compromise your investigation. Making DNS requests to an attacker’s server could inform them that research is being conducted, or their activity has been detected. It is extremely rare for an average foe to monitor inbound DNS requests, but it is a reasonable practice for a targeted and much more sophisticated adversary. In theory, such an adversary could monitor their own DNS servers for communication. Once irregular inbound requests are detected an adversary then has a head start to immediately back out, cover their tracks. and change their tactics.

This mistake is most common with traffic capturing utilities used within a network for automatic name resolution. These tools can automatically give intelligence to the attacker around your monitoring capabilities. Here are two common examples of disabling automatic name resolution:

Wireshark:

This setting is disabled by default, but good to double check if loading a PCAP that may contain network traffic for an investigation or research. The setting can be found in Edit > Preferences > Name Resolution.Figure 1

Tcpdump:

Use the –n option. As stated in the manual, this setting will disable name resolution.Figure 2

1. Communication Timing

This one is more on the theoretical side, and again very dependent on the sophistication and focus of the attacker. If you are examining a file that could be malicious, the odds are this file will want to ‘talk’ outbound to its control server or request further downloads onto the network. There are obvious best practices when it comes to examining and testing malicious binaries, such as offline operations only, but that’s not always possible.

If you need the code to run, or perhaps you identified the URL holding the download file, be careful with your timing. As a small warning, the hosting location you are reaching has an increased possibility to spot the odd behavior. If they were to know all of their victim machines will reach out to them at a specific time, anything outside of that could inform them that you are researching and potentially identified their activities.

1. Upload and Sharing of Data

For many, the first step to discovering if a file is malicious or not is to upload it to all the free scanning websites. While this process will provide some quick details for an initial analysis, it can also inform its creator that you have found and are researching their efforts. Some of the more popular destinations for these actions would be VirusTotal, Malwr, and the new IBM X-Force Exchange. These are some of my favorites, and also Lenny Zeltser happens to have a great list of options focused on automated malware analysis. When it comes to using the numerous online scanning and analysis tools, avoid any aspect of sharing the upload during the initial investigation. Instead, simply search for the data names or hash when possible. An attacker can automate the ability to query the various sites for their binary to see if anyone has found and uploaded it. Searching instead of uploading will allow you to check for possible results while also keeping it concealed that you are performing an analysis on it. Sharing with the industry can be a great thing, but take caution in the timing and amount of information you decide to make public. VirusTotal does not currently provide the option to opt out of sharing data while Malwr along with X-Force Exchange do. Lastly, there is the option for setting up your own analysis environment with something like Cuckoo Sandbox, but that’s for another blog post! Figure 3

1. Defense On The Sea Begins On The Shore

We’ve all heard it, do not share anything private or confidential on social media, yet many people still do. An interesting trend I’ve seen recently comes from LinkedIn in particular. It is common among professionals to connect with each other over LinkedIn shortly after meeting. Think about the timing and viewpoint from individuals watching for this activity. They could find it rather helpful when the team of Company-A begins to connect with people from Company-B. For example, if you began connecting with multiple individuals from a particular security vendor, someone from outside could then assume there may be use of that vendor at the organization. Also, LinkedIn is one of the most widely used sources of information for the social engineering competition (SECTF) each year at DEF CON. The solution may be obvious, but avoid connecting with patterns like this, or just turn off the ability to publicize this information within the account settings.

Treat any social media information with the same paranoia. Tweeting your thoughts on how terrible your users are at clicking links in phishing emails, or taking pictures of your office for your friends on Facebook are the first that come to mind as bad practice. This awareness would also be helpful to TV broadcasts as well, such as the recent event at a London rail station. In conclusion, it all really comes down to the basic policy of “need to know” for all investigations or activity taking place. Individuals or groups targeting you can use the above methods to potentially gain the upper hand on your labors. None of this is a new idea or method to operational security, but in the ever changing world we must continually assess our practices to ensure its integrity.