PCAP Analysis, DC and MITER ATT&CK

Let’s find out!

Analysis of the task: “How we investigated the defacement (PCAP Analysis)”

Given:

A new “beautiful picture” has appeared on the main page of the portal with CMS Joomla. Administrators say they did nothing, and a strong password is used to access the admin area! Fortunately, traffic was being written to the perimeter at the time of the attack.

Required:

Examine a copy of the traffic and find the flag that the attacker carefully left on our portal.

Solution:

Let’s find the flag using Wireshark’s “Search”

Where is my wareshark? Let’s begin!

The task hints at a picture with a flag that we must find. Let’s start with the classic Export Objects to extract all transferred data over various protocols:

Many pictures were transmitted via HTTP, but the treasured flag is not visible on them, but you can find a koala.

Searching for the string “flag” also does not give any results:

Since we are looking for a picture, let’s try to search not for the word “flag” and all its possible variations, but for picture signatures, for example, FF D8 in a hex or JFIF and EXIF ​​in strings:

This approach really pays off! We found a picture in the tcp stream, let’s save it and see what’s on it. And on it is no longer a koala, but a real flag in yellow and pink colors:

Seems too easy? Let’s try to find more solutions!

Let’s find the flag using statistics and dump analysis

Wireshark has a wonderful statistics section:

Using it you can see statistics on endpoints, ports, protocols and much more:

In our case, we see the three most active IP addresses: 11.0.30.138, 11.1.173.2 (our Joomla) and 200.200.200.200 (how beautiful…).

If we look at the IPv4 statistics by port, we will see the following:

You can see that host 11.0.30.138 is communicating from the “large ports”, most likely this is the client that is communicating with our web server.

But at 200.200.200.200 we see two interesting ports: 8101 and 4545.

And on 11.1.173.2 port 9090 (we’ll look at it a little later).

First, let’s filter port 8101 and look into the session:

Here we see a lot of things:

● and reconnaissance using the utilities netstat, ps, crontab and others;

● and successful elevation of privileges through misconfiguration in Sudoers (after exploiting a vulnerability in the CMS, the attacker received the privileges of the UZ daemon);

● and downloading a malicious elf file, communication with which probably occurs further on port 4545.

Let’s also filter tcp port 9090 and look at the session:

This is our flag session. In order to save it, you need to select the RAW format and save it as a picture.

Analysis of the task “Our DC is in trouble (we can do it without security)”

Given:

Blue Team has discovered that CyberCamp’s domain controller has been compromised. The attacker covered his tracks and deleted the main event logs. But, in addition to the Security and PowerShell logs, the incident response was able to extract several logs that will help find clues in the investigation.

We are given magazines:

●System

● Directory Service,

● Microsoft-Windows-TaskScheduler Operational,

● Microsoft-Windows-TerminalServices-LocalSessionManager Operational,

● Microsoft-Windows-TerminalServices-RemoteConnectionManager Operational,

● Microsoft-Windows-WMI-Activity Operational.

Required:

Answer the following questions:

● What is the IP address of the host from which the attacker conducted reconnaissance and launched the attack?

● What tool did the attacker use to make a horizontal move on the DC?

● What is the name of the scheduler task created by the attacker?

● What Windows tool did the attacker’s task run?

● Which user’s login to the DC triggered the attacker’s task?

Solution:

Manual event analysis

Let’s start with the system log and look in it for traces of service installation – event 7045. In this event you can find traces of PowerShell running as a service, and traces of horizontal movement to the host. Let’s see what this event will give us…

And it immediately gives us the answer to the second question:

We see that in System log event 7045 the PSEXESVC service is installed, indicating that this host was connected remotely using the PsExec.exe tool.

Next, let’s look at the Directory Service log. This log is configured through the registry on the domain controller and allows you to detect intelligence in the domain using the LDAP protocol. We will look for anomalies in event 1644, which contains the client address and LDAP request filter.

There are 3700 events in this log, and it will be difficult to view each of them. For convenience, you can filter the event log by user and not view duplicate legitimate requests:

This way you can discard duplicate events with RID 1156 from host 192.168.1.254 and other legitimate events. When viewing events 1644 by user, you can find the user with RID 1206 and see one “small” event:

In this event we see the client address and LDAP request:
( &sAMAccountType=805306368)(userAccountControl&4194304).

With this request, the attacker searches for all users in the domain with the DONT_REQ_PREAUTH attribute set to carry out an AS-REP Roasting attack.

We can be congratulated – we have found the answer to the first question! The host address from which the attacker conducted reconnaissance and launched the attack is 192.168.1.51.

The third in line is the Microsoft-Windows-TaskScheduler Operational log, and we will try to find traces of the creation and launch of scheduler tasks in it.

The event for creating or registering a new task can be found in Event 106 of the TaskSheduler log. We were lucky and there is only one such event in this log:

Let’s see whether this task was launched, and if so, what process it launched. Event 200 will help us with this – “Action started when task started.” And again luck: we see that quite a lot of tasks were running, but the newly created UpdatePowerShell task started and called powershell.exe, which is very alarming:

Let’s also pay attention to the task launch time – 11:50:26 (we will need this later, and in principle it is always useful to record the time for constructing a timeline).

Thanks to this magazine, we found answers to questions 3 and 4:

● What is the name of the scheduler task created by the attacker? – UpdatePowerShell

● What Windows tool did the attacker’s task run? – powershell.exe

We only have to answer the last question: which user’s login to the DC triggered the attacker’s task? This question itself leads to the necessary logs, and we will look at the LocalSessionManager Operational log. Based on the question, the most interesting event for us will be event 21 – “Successful login”.

There were few such events in the log, and we immediately find the one we need, correlating it in time with the launch of the scheduler task:

We can also confirm the entry we found in Event 1149 of the RemoteConnectionManager Operational log. Apparently, the attacker created a scheduler task with the /sc onlogon parameter, so it started when the user RND\camp_user logged in via RDP.

We found answers to all the questions, and based on the sequence of events, we can conclude that the attacker began his attack with reconnaissance, then, using the AS-REP Roasting technique, obtained an account in the domain, from which he then moved to a domain controller using PsExec .exe and created a scheduler task to pin.

We use automation

Out of curiosity, let’s see if automation will help solve this case. To do this we will use the tools Hayabusa (aka Sapsan) from the team Yamato Security And Timeline Explorer by Eric Zimmerman.

Hayabusa contains more than 2,500 thousand rules, which include both Sigma Rules and Hayabusa’s own rules. The result is as follows:

As we can see, the creation of a scheduler task, the launch of tasks, RDP logins, horizontal movement via PsExec, and clearing of logs are recorded. If we view the output of the utility in Timeline Explorer, we will see convenient and understandable alerts:

Note that Sapsan was unable to cope with the Directory Services log, but it would have significantly reduced the speed of investigation of this incident.

Analysis of tasks: “The magic of MITER ATT&CK” and “This is the base. Working with MITER ATT&CK”

Most of the questions and mini-cases were aimed at developing basic skills in working with the matrix interface, search tools and navigation bar of the ATT&CK website with sections Groups, Software, Data Sources and are examples of simple exam tasks for obtaining certifications MITER ATT&CK DEFENDER™ (MAD). We will look at several tasks that required the use of the right techniques and/or ATT&CK Navigator. Once you understand the algorithm, other tasks can be solved in a similar way.

ATT&CK Navigator is an open source web application that provides basic navigation and expands your project experience by creating and overlaying individual layers, heat maps, and more.. ATT&CK Navigator available linkworking with key functionality is well described on the MITER ATT&CK website here Here.

Case 1

Given:

You are investigating an incident that occurred at the company. The attacker bought leaked infrastructure access passwords on the black market, used valid accounts, and remotely connected to the server using the RDP protocol, on which 1C was published for remote accounting access.

Required:

It is necessary to determine what techniques the attacker used.

Solution:

Let’s methodically analyze this case using an algorithm that offers us Best Practices for MITER ATT&CK® Mapping from CISA. To decompose the attack into its components, you need to go through the following steps:

We will skip the first two steps, since the description of the attack is already in our case, we have a basic understanding of the matrix, connections between the main objects (TTPs) and have opened the project website at least once. To determine the final set of techniques, you must first complete steps 3 (Research the behavior) and 4 (Translate the behavior into a tactic) to better understand the attacker’s goals and narrow down the search area from more than 200 various techniques:

The attack, broken down into three main blocks with verbs highlighted, looks like this:

● Pre-compromise: attacker bought leaked infrastructure access passwords on the black market.

● Initial-compromise: used valid accounts, connected remotely to the server via RDP protocol, on which 1C is published for remote access of the accounting department.

● Post-compromise: in the case under consideration this stage was missed.

For such a simple attack, these steps may seem redundant, but for a complex case, this exercise greatly simplifies the identification of tactics and techniques.

By matching the verbs and structure of our attack with the description of the tactics, we should end up with the following tactics: Reconnaissance (found in the PRE Matrix) and Initial Access:

To go to step 5 (Figure out what technique applies to the behavior) and determine the techniques, you can use one or several methods at once:

There are not many techniques in the highlighted tactical steps, and they can be viewed with your eyes, but the easiest way is to use a matrix search or look for the keywords remote, valid, RDP, dark web and then check the found techniques with their description:

After all the exercises we should be able to:

The attacker bought leaked infrastructure access passwords on the black market (Reconnaissance: Gather Victim Identity Information: Credentials, T1589.001), used valid accounts (Initial Access: Valid Accounts, T1078) and connected remotely (Initial Access: External Remote Services, T1133) to the server via RDP protocol, on which 1C is published for remote access of the accounting department.

Case 2

Given:

When forming their threat model, the SOC team decided to focus on countering the APT33, BlackOasis, Axiom and Windshift groups. Below is a heat map of the SOC’s current technology detection capabilities.

Required:

Determine which additional equipment is worth paying attention to, taking into account the heat map of SOC capabilities:

Solution:

This task is an example of building a threat landscape or Threat Modeling: collecting information about groups potentially capable of attacking a company, taking into account the type of company, geography and other factors. It is simplified by developing a heat map with overlay of layers used by various groupings of techniques and subsequent determination of the gap based on the possibilities of their mitigation or detection. The groupings themselves have already been given to us as introductory ones; the task is to create a heat map and find blind spots.

First, let’s create a new layer in ATT&CK Navigator (Create New Layer – Enterprise). Using the “research&multiselect” tool (1), we will find and select the first grouping (2), color the selection (3) and set the scoring to “1” for our first layer:

For the remaining APTs (BlackOasis, Axiom and Windshift), we sequentially repeat the steps, creating a new layer and increasing the scoring by one.

The next step is to apply our layers. To do this, use the “Create Layer from Other Layers” tool (1), after which we enter the addition formula for our layers: a+b+c+d (2):

The output is a color overlay diagram:

Taking a closer look at the original SOC coverage map and legend, we see that a number of techniques, such as Exploit Public-Facing Application and OS Credential Dumping, are used by groups, but have low detection confidence in our SOC. Given that detecting an attacker’s actions is most effective in the early stages of an attack, the correct answer is the Exploit Public-Facing Application (T1190) technique performed in the Initial Access step.

Case 3

Given:

Your company has decided to focus on detecting and blocking the TOP 7 attacker techniques (marked in blue):

Required:

Determine the Data Source that provides the greatest coverage.

Solution:

The solution to this problem comes down to working with the Detection section, available in the description of each technique. Consistently transferring (in XLS or simply screenshots) the data sources necessary to detect the techniques described in the task, we get the following picture:

The most commonly cited source is Application log, which is the correct answer.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *