This will be the last blog in this series on OPSEC for Blue Teams. I will share some of my thoughts on sandboxes, secure communications and sharing of info & data when dealing with a targeted attack.
Sandboxes
Performing dynamic analysis by running a malware sample in a sandbox can provide you with valuable information. Again, keep in mind that certain OPSEC rules are less strict for non-targeted attacks. Such as sandboxes with internet connectivity.
VirusTotal
VirusTotal is doing much more than scanning your malware sample with multiple AV solutions. Behavioural information is added that comes from sandboxes. However, do not upload malware samples to VirusTotal and similar solutions. An adversary knows the hash(es) of the malware and can easily find out if they are uploaded. This kind of monitoring can often be automated using APIs offered by these services or by creating a wrapper around the web GUI.
Simulated Internet
Having internet connectivity on your sandbox can be a risk, more on this later. A good option is to have simulated internet. For example, INetSim and FakeNet-NG can provide this when integrated with your sandbox setup (there are also third-party sandbox services having these solutions integrated). INetSim and FakeNet-NG provide the capability to simulate various internet services such as: DNS, HTTP/S, IRC and many more. No traffic is actually going to the internet, but is simulated by these fake internet services which also allows you to configure how to respond to requests. Among other things, simulated internet can provide you with the first request the malware sample will sent. Such as the C2 domain or URL from which the second-stage payload is downloaded. Subsequent requests may fail if the malware gets confused by an unexpected response.
Internet connectivity
Be very careful with sandboxes with an internet connection. This includes your own sandbox and third-party solution/services (some allow you to disable internet access). I am aware that not having internet on a sandbox downgrade much of its strength and functionality. But having a sandbox with internet can result in sending signals that can be picked up by the adversary. Some of these signals overlap with the ones already discussed for OSINT. But also things like a hostname that is not corresponding with the naming convention of your company, and you are dealing with malware sending back the sandbox's hostname to the C2 server.
When you do really need the malware to connect to the internet, create your own sandbox (or be very sure you are not dealing with a targeted attack). Having a sandbox on which you have complete control is always a good idea. The main point here is to have a sandbox that shares as much characteristics as possible with a real company’s endpoint. Make it look as normal as possible. For example, think about the following:
Use real hardware instead of a virtual machine.
Run the same operating system and version.
Keep the system up to date.
Make it look like the sandbox is actually used by having traces of user activity, but do not have any personal/production data on it.
The hostname of the sandbox should correspond with the company's naming convention.
The same applies for the username that is logged on to the sandbox.
When connecting to the internet have its external IP look normal.
Very important, make it technically impossible for your sandbox to communicate with your production IT infrastructure.
Do not connect to your sandbox from a production system, use different hardware for this (i.e. a system not connected in any way to your corporate network).
Secure communications and sharing of info & data
OPSEC on how to share information within the blue team and stakeholders (board of directors, security officers, etc.) becomes extra important when dealing with a targeted attack. Imagine the adversary has access to all information from the blue team on your current investigation. You now have lost your advantage as a defender.
If you are convinced a security incident is a targeted attack on your company. The attack has been going on for a while, you have not detected the adversary very early in the kill chain, and before they have had any time to move up in the kill chain (on the latter you should be very certain). You should take extra precautionary measures on how you share information concerning the incident within the blue team and to stakeholders. Assume that things like Active Directory and mail servers are compromised and the adversary is reading your communications.
Think about the following:
Having systems you can use for performing parts of your investigation, communications and sharing of information that are not connected in any way to your corporate network. Obviously, you are still bound to use many of the tools you have within the blue team, running on the company's IT infrastructure, to be able to perform the investigation. For example, using Splunk to perform big parts of the analysis and an EDR solution to get additional information from systems.
Secure communication channels that are completely separate from your company's IT infrastructure. Think about instant messaging (e.g. Signal) and a secure platform to share documents, notes and data.
A topic I would like to explore further: what is the best way, taking feasibility into account, to make sure that all blue team systems and tools (client endpoints, data lake, security monitoring solutions, etc.) can be trusted, up to a certain level, within a compromised IT environment.