Welcome to Part 4 of our series on MITRE’s ATT&CK Tactics! At this point in the attack, adversaries have pulled the trigger on an attack and defenders have had their first fair shot at detecting the transgression. Like a fortress’s defenders seeing the build-out of siege weapons and the digging of trenches, defenders now know from where a part of the attack is coming. For the attacker, they are relying on their preparation, coordination, and focus to overcome defensive efforts. For the defender, they are likely depending on the training and processes – and their garrison’s trust and cohesion – to disrupt and repel. How able are the attackers to carry out their plan, to sap the fortifications, to breach the walls? This is the MITRE ATT&CK Execution Tactic, and it is the phase from which all later phases branch.
Whether an adversary is hoping to steal data, move laterally, escalate privileges, or evade defensive efforts, they will need to Execute malicious code, commands, or scripts in order to do so. So let’s take a look at this phase!
Transitioning to impact tactics
In our last post on Initial Access, we saw how an attacker transitions into a concerted offensive on their victims. But did the victims/defenders see or detect that action? Often times, the first indication that someone has snuck into their environment is when they begin to cause mayhem using techniques covered by the ATT&CK Execution tactic. Maybe they are destroying vulnerable buildings, or hurting unarmed civilians? In the cyber realm, this might be when screens begin to flash with the tell-tale signs of a ransomware event, or a critical system becomes unreachable.
There is no worse feeling than knowing an attack is happening. Hopefully most of us can only imagine the fear and dread that defenders experience when they realize something bad is afoot. No matter the field (cyber, traditional warfare, martial arts, etc.) there is a grim certainty of taking a blow. We’ll see that the reaction to those blows is much more important than we realized. Not all is lost! Did they fight valiantly despite the odds? Did they counterattack? Or did they seek to truly understand their adversary’s TTPs so intimately that they were able to defeat the adversary?
Escaping Execution in every sense of the word
Cities besieged by Genghis Khan’s forces certainly felt this – they knew of the Mongols’ undefeated record and the consequences of resistance. Each Khan from Genghis onward flipped the Medieval script. They tended to treat the lower classes and soldiers well and offer them a place in the empire, but execute the leaders. Kings, Sultans, Emperors – all of them were fair game. Mongols surmised that most uprisings were launched by ruling-class folks looking to regain power lose. While the TTPs that they used evolved continuously, the Mongols always aimed to incorporate first, and retaliated only when provoked.
To avoid being executed, most defenders began with similar goals – keep them out, retreat within the walls, show no weakness. Some adapted quickly and found a much more peaceful path than others. How they reacted to those events actually impacted the outcome long-term more than the initial attack’s effects. The Khans’ siege skills and engineering were cutting edge, but savvy defenders found ways to lessen the blows or to give just enough to avoid certain death.
Data is different – where history and technology diverge
In cybersecurity we expect to soak up our fare share of damage. Attackers always find a way to land Initial Access methods, and they will attempt to execute their malicious code. Countering that effectively means having a good guess as to what the enemy plans to do accomplish. ATT&CK is a tool that can help interpret the tactical side of this (we are discussing Tactics, after all). Strategy is arguably more important – attackers use tactics as stepping stones on their path to an end goal, after all. The more we grasp both, the better we anticipate their next moves and can disrupt them. The ATT&CK Execution phase happens as part of a bigger plan. That plan holds the keys to enlightenment!
Consequently, it wasn’t until the 1260 defeat by the Mamluk’s of Egypt that someone cracked his descendants’ code – 80 years and 3 generations of dominance on the battlefield! With forces consisting of former Mongol slaves who understood their prior masters’ tactics instinctively, the Mamluk slave army repelled the Mongols at Ayn Jalut and notched the first real defeat of this relentless force. Their tactics were quite similar – hit-and-run tactics, feigned retreats, and ambushes leveraging geography.
Execution – plenty of ways to ruin a victim’s day
There are a plethora of ways an adversary can leverage the ATT&CK Execution (TA0002) array of techniques on a victim’s environment. As we can see in the snapshot below, it is a pretty massive grouping of 14 techniques and the variety can seem overwhelming at first.
Something worth noting on the ATT&CK Execution tactic: it is often combined with Initial Access or any subsequent tactic for the type of impact warranted. If an adversary wants to establish Command & Control (TA0011), Execution might help kick off the beacon. If they are looking to implement Discovery (TA0007) before attempting some Lateral Movement (TA0008), Execution might be needed to run the LOLBins or custom tooling that enable these ends. In the end, the Execution Tactic is the enabler for all of the tactics that are to the right of it. MITRE CTID’s own APT3 Emulation Plan demonstrates this – Initial Access and Execution are actually combined by the adversary (section 3.1.3 of the document). That being said, we can discuss the many ways Execution can be achieved below.
Execution via CLI – leaving the door wide open
The move to cloud environments has somehow made it acceptable for enterprises to claim naivety as an excuse for a lot of breaches. The tools may look different, the prompts might be unfamiliar. But the same issues on-premises environments have been plagued with for years are just adapting to the times.
When we look at the ATT&CK Execution techniques for Cloud (T1651) and Container (T1609) Administration Control, they are just new looks to the tried-and-true Windows Management Instrumentation (T1047) and Command and Scripting Interpreter (T1059) techniques. System Services (T1569) fit in here as well, but focus on piggy-backing malicious code onto legitimate daemons or services. All of these techniques (and Command & Scripting’s 9 sub-techniques) take advantage of a mix of poor (or non-existent)access control, segmentation, and monitoring to do their dirty work. Even scarier, these techniques rarely require external code to begin – they leverage tools that are available natively on the systems. An attacker using living off the land binaries (LOLBins) may seem unavoidable, but the key is in controlling who can invoke them where.
A fourth technique, Deploy Container (T1610), also sort of fits in here. If the above three techniques are an issue, so is the relative lack of control most enterprises have in their container environments. Loose CI/CD processes with lax security make it trivial for an attacker to instantiate or swap in a tainted container. These containers can both cause havoc while avoiding detailed detection, as anything running in them can be hidden from the defenders’ tools.
We should also mention Software Development Tools (T1072) in here as well. Many supply-chain attacks leverage these tools to deliver malicious payloads. Attackers have capitalized on the fact that very few companies can properly secure and monitor their development tool set. This makes these tools fertile ground for adversaries to tackle without fear of detection, and they often are able to dwell in them for a significant length of time. It is like taking over a victim’s own factory to continually build the weapons you use against them!
Execution via normal developer and control paths
Sometimes application developers are too smart for their own good. Serverless functions, for instance, offer a chance to save lots of money and tighten up applications to bare essentials. Well, it also happens that most folks are clueless about how best to protect these capabilities! Serverless Execution (T1648), much like hiding malicious activity in a Container, allows attackers to use the application environment against itself. Likewise, APIs commonly used to administer these new environments are much too powerful not to secure. While some tools exist, a vast majority of organizations are powerless to counter Native API (T1106) abuse in their environments. These techniques owe a lot to the tried and true use of Inter-Process Communications (T1559) and Windows Management Instrumentation (T1047) paths that once again, just keep on bearing fruit!
No matter the environment, there is bound to be a task management or job scheduling function, and Scheduled Task/Job (T1053) is a popular place for adversaries to focus their time. Whether the environment uses at, cron, or something similar, adversaries know that these often come with their own access level quirks and poor monitoring or understanding. While these first appear in the ATT&CK Execution tactic, they are common Persistence and Privilege Escalation TTPs, which makes them well-suited for building flexible operations.
Turning the victim against themselves
Last but not least, we have User Execution (T1204), Shared Modules (T1129) and Exploitation for Client Execution (T1203). All of these involve implanting or downloading code to a target to be run, but what varies is the path. Users obviously have multiple ways in which they can inadvertently welcome an attacker’s executable. Attackers can also sneak the code in via vulnerable code (sometimes in concert with developer tools) or run their code inside of another process. This last one is super tricky. Like running within containers, it is going to be very tough to detect before a lot of damage is done.
What can we do to counter Execution?
Before and during an attack, defenders can do much to absorb and lessen the impact. They may:
- Find ways to turn a jarring blow into a glancing strike
- Cede territory on purpose, knowing it will expose the attackers to a counter attack
- Goad the attackers into attacking a costly yet unimportant area
- Absorb and direct the attack, allowing them more options to sever coordination or communications
The key to choosing responses is ensuring that you take the adversary further from their strategic imperative. Allowing a glancing blow to carry momentum into your vital organs or your mission critical services = bad news! But allowing it to dull their sword on the wall or blunt their attack against a tar pit? Genius! Strategic understanding is what gets us to this next-level awareness. Don’t just check boxes for TTPs on ATT&CK Navigator. Understand how an adversary ties these TTPs together to cause mayhem! Head them off at the pass, or nudge them off course.
Alternatives
Unlike our historical examples, we really can’t afford to surrender. We can’t just take the “if you can’t beat ’em, join ’em” path. (Or can we? Future topic unlocked š ) And if we’re giving up in the ATT&CK Execution phase, we’re really jumping the gun.
But we sometimes have a middle ground that – while polarizing – might offer a pathway out. Ransomware can sometimes be unlocked through the paying of a ransom, but caution is advised. Ensure the best legal and technical counsel are involved and advising through the process. It is also highly advisable that law enforcement (in the US, the FBI’s IC3 is a good place to start) are in lock step with you. You are ceding that they got you. You better have a plan for recovery that cuts off that vector for future use. And you must sanitize the environment so as to eliminate dormant, persistent attacker behavior.
Conclusion
Our systems are mission critical for a reason. Our data is often more than just our own, but that of our customers, partners, and other businesses. If you are a healthcare system, the ATT&CK Execution phase might spell trouble for patients. If you operate a critical infrastructure company, you can’t let the attackers deprive folks depending on fuel, water, or electricity. These are life and death consequences. For these reasons, defenders definitely need to find other ways to absorb these blows that don’t result in catastrophic system outages, data loss, or losing control. Ideally, we do that through reducing our attack surface, monitoring and detecting anything we can, and ensuring our staff is well supported and trained on the tools at hand to get the best possible outcomes!
I hope that this post was useful. As we saw in Parts 1-3, we’re progressing through the phases of an attacker’s general operation. Despite that, much of the guidance remains the same. This should reinforce that if we’re doing the basics well, we stand a much better chance against the adversaries. Let me know what you think and have a great night folks!
Mike
0 Comments
1 Pingback