Some Comments and Thoughts on Tradecraft

in , ,

I have been writing a series on the new Windows Defender Exploit Guard features on Attack Surface Reduction where I cover my research on it. I'm researching the controls to add the information in to my personal playbook. Surprisingly in conversations with some Red Teamers I know they dismissed the information as it is a Blue/Defense technology. These comments surprised me and I would like to share why it surprised me.

Let me start by saying that this is only an opinion. The steps and tradecraft for me would vary on level of skill of the defenders, scope, time and rule of engagements. This is blog post is only for me to share my though process and opinions on this area.

When it comes to attack and defense, red and blue, attack simulation. However, you want to call it in its essence it is an adversarial process, it is one team or person against another. Sometimes it can be a attacker against a defender or it can even be the attacker against a vendor research team that adds new features or modifies existing one. But it is one person trying to outwit another. So, if you are an attacker why are you not studying about defenses and mitigations?

What is the purpose of a red team or pentester? For me it is to show alternate ways of thinking and exercise the current controls in place to show areas of improvement to mitigate risks. To be able to do this knowledge on how systems works, how different lack of controls or misconfigured ones can have a negative impact for a given customer environment is of the upmost importance.

When it comes to the tradecraft one applies it will depend on the red team exercise you are conducting. If you are performing a simulation of a specific threat with blue your TTPs will be dictated by the threat intelligence you have on the adversary you are simulating to test the controls.

Knowledge of one’s tools, the opponent, his tools and how each implements them and uses them determines the actions. As Sun Tzu said:

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

Operational Thoughts

In the case you are performing an exercise where you are not simulating a specific threat you only constraints will be Rules of Engagement, Time and the level of skill you have to simulate a determined skilled attacker. Of the 3 limitations you have the most control on the third one and this is the one I will comment about.

On important phase is like any adversarial process it has to be practice and it has to be constantly improved upon. Opponents will always have different skills levels and processes. No organization behaves and operates the same due to skill, leadership, indoctrination and even organizational politics. Because of this it is important to practice and role changes, red team members should be placed in defense situation where they must defense and track others in their team and rotate between roles. This will insure that the level of knowledge and skill moves up. You cannot have a champion boxer if he only shadow box and hit the heavy bag, he needs to spar and be challenged. If you do not provide the IOCs and recommend proper controls and open your kimono, how do you expect for the security to improve? And as a result how do you expect to be challenged and improve yourself?.

 

The Tools of the Trade

Base Infrastructure

Let’s start with your infrastructure. From where you operate you have to see it as it is actively being targeted by another Red Team. Remember there is a risk you will be detected and you may be targeted and you should prepare and practice for that eventuality. Some point to take in to account:

  • Do you control access to your infrastructure both for management and for implants/agents?
  • Do you log all connections and connection attempts and alert on unwanted ones?
  • Do you use properly configure cryptography parameters for data at rest and in transit? (Encrypted file system, certificate pining, SSH keys..etc)
  • Can you redirect your implants/agents to other servers if needed?
  • Are you using multiple providers for the connection back from the implants/agents in case of detection?
  • Can you change how your listener responds to request and protocol to avoid fingerprinting?

Recon Methods

Recon takes many forms, from doing Google searches for domains, information and files all the way to calling sales and acting as a customer to see screens showing apps used in their machines, files from which one can extract metadata showing servers, versions and other information. Recon is an active and noisy endeavor when it relates to a network. One of the constraints in commercial engagements when it comes to network recon is time, it forces one to be noisier than one may like. Some considerations to take in to account:

  • Are your command and control server different than your recon ones? you do not want to get all of your infrastructure blacklisted.
  • Have you run your recon process through several network monitoring and detection solutions to tune your discovery process?
  • Are you collecting the information in to formats easy to process or in to a database that allows you con parse and leverage the information quickly?
  • Are you collecting the information you need and not to much or to little? (don’t be a hoarder)

Execution Methods

When launching the initial exploit, abusing features of programs and/or human nature more often than not you are executing your code in an environment where the information on its control is limited so “assume the worst and hope for the best” may be a mantra to consider. For this you need to test and know:

  • What files it creates, reads and modifies if any
  • What controls may block your execution and how complex these controls are to implement (OS features, EDR, AV ..etc).
  • What login may catch the execution in a default configuration and what would be an enhanced one that would log it.

The more you know your target and the complexity of the controls will play in to decision process. If your recon shows that the target is not one that has invested in having proper teams and technology then there may be no need to limit oneself to more complex method that are more prone to fail due to many variables and limit your flexibility. Be as complex as needed.

Post-Exploitation

You are now on a system, either on a segment of the internal segment. Now that you are in you have every chance to be discovered and at the same time you are closer to the goal to showing failure of multiple controls to contain, mitigate and prevent actions from an attacker.  

You are in the system, every action you take can get you caught by a logging system, EDR, AV or blocked by a OS control. You must know what each tool you use modifies on the system and what can alert on it.

  • Have you ran your Post-Exploitation processes on systems with EDR, AV and Controls enabled to see which one flags it and how? Did you document it?
  • Have you ran your tools and look at how their actions look at different configuration levels? Captured the execution with ProcMon from Systinternals at least to have a clear understanding of DLL’s Loaded, Registry Key accessed, process created, where it fails and has success in it actions?
  • Have you looked at the network traffic generated?

I have heard many times vendors, researchers and hacker say that they are completely stealthy with zero footprint. This is just impossible. There is always a trace either in memory, disk or both. Keep in mind always the Locard Exchange Principle:

 "Every contact leaves a trace"

I normally follow this initial step:

  1. Find out under what context am I running one.
  2. What is the privilege level of the context I’m running on.
  3. Enumerate thecontrols on the host:
    1. Audit Policy (If privilege level permits it).
    2. Process List (look for applications that may report, mitigate or block my actions)
    3. Service List (same as applications)
    4. Driver/Kernel Module List (same as applications)
    5. OS level controls
    6. Applications Controls and Configuration (AV exceptions ..etc)

This initial step should provide me with enough information on what I can do and not do on the system and will provide me with an idea of the level of skill of the administrators/blue team of the target organization.

Example if there is process logging and PowerShell logging is configured do I use Cobalt Strike with its PS feature or Empyre? Probably not, even more if it is a newer version of Windows and the PowerShell 2.0 feature is not installed. Does my tool create another process? Would the process tree be unique to an attacker? Would the command line parameters be? Now you see why I mention you need to understand what your tools do and how do they look. If they look out of place and cannot be masked by the noise of operation in a properly monitored and configured environment then I should look at other tools or change my environment in a way it will not raise alarms.

Now that I have an idea of the controls on the host and initial perception of the skill level of my opponent I look at the network details.

  1. Is the host in a domain or not.
  2. On what part of the domain is it in.
  3. Listening ports
  4. Firewall rules
  5. Netstat, ARP, NDP, Routes DNS Cache to identify other hosts.

Now with this info I have a better idea of the value of the host and how it relates to the network. I can now look for files, user tokens, saved credentials, keys and any other information I can exploit.

Once I’m done with the host I can decide if I should persist on it or not. I do not want to persist on all hosts I’m in, that would be of high risk. So I need to determine:

  • Are there pending reboots?
  • How often does it reboot?
  • Is it in a position in the network with privileges I want to persist on?

 

If persistence on the host if of value for the given risk and my techniques are tested against the controls on the host I need to choose if the method for it would be an active or dormant one. As you move through the network you must vary your persistence techniques sine once detected Blue will look for this IOC across host, they will also look at connections so a varied infrastructure is of help. A active one is that it will do its best to maintain connection back to you. A dormant one you must see as a backup, it is one that you initiate the connection to the host via WMI, SSH, HTTP, Stolen Creds, Injected Account ..etc this will give you back door access. It may also be a time triggered one if no stimulus is received, this would be the case that you were pushed out of the network and this is your ace in the hole.

I do not want to go to deep and cover all variables but this should give you an idea of my though process and why I do believe one must master both defense and offense. Also mastery of self must come first.

I hope you find this information useful as always.