Reading Time: 28 minutes

Case 001 PCAP Analysis

Case 001 Brief and Materials.

Get the materials and follow along!

Have you built your DFIR Fort Kickass, yet? How to build a DFIR Analyst Workstation found here.

Make sure you understand the basic rundown of forensic artifacts.

This post assumes you have a DFIR Analyst Station ready to analyze the PCAPs from The Case of the Stolen Szechuan Sauce.

---

Learning Objectives

• Understand the advantages and goals of PCAP Analysis
• How to pivot into and away from PCAP Analysis (how to use findings for quicker analysis)
• Common tools to use
• How data reduction aids in investigations

Semi-Required Knowledge

• Networking basics
  • Private Address Spaces vs Public
  • TCP Handshake Basics
  • Common Port Assignments
• Basic Linux Command Line Fu
• Basic Wireshark Skills (Brad’s MTA Wireshark Tutorials)
• Basic Virtual Machine Operation

Common Tools

• Snort
• Tcpdump
• WireShark
• TShark

Tools Covered Here

• Snort
• Tcpdump
• Wireshark

Other Learning Resources on this Topic

• Book: “Mastering TShark Network Forensics: Moving From Zero to Hero“
• Book: “Practical Packet Analysis, 3E: Using Wireshark to Solve Real-World Network Problems“
• Book: “The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference“
• SANS Course: “SEC503: Intrusion Detection In-Depth“
• SANS Course: “FOR572: Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response“
• tcpdump man page

Music

• Robot Music
• Metal Forensics

Notes

• Keep solid notes on your thinking around evidence and data that you find
  • This is for team mates to understand your thinking
  • Understand your own thinking later… or after sleep.
• Notes should be accompanied by screenshots that tell a story
  • Examples: Highlights, Boxes, Arrows Text. The reader should quickly understand what they’re looking at
• A great note keeping App that teams can use to coordinate is OneNote.
  • Each host gets a tab etc.
• A great piece of software to take Screen Shots is Greenshot

Applicable Pivots

• From Disk Analysis: Malicious IP Addresses, Malicious Filenames
• To Disk Analysis: Malicious IP Addresses, Malicious Filenames
• From Memory Analysis: Malicious IP Addresses, Malicious Filenames
• To Memory Analysis: Malicious IP Addresses, Malicious Filenames
• From Log Analysis: Malicious IP Addresses, Malicious Filenames
• To Log Analysis: Malicious IP Addresses, Malicious Filenames
• And so on…

---

PCAP Analysis with SIFT REMNUX

Overview

Packet Capture (PCAP) files are tremendous resources for investigations when they are available. For an idea of how sensors are placed to gather network traffic check out my article, “Building a SIEM at Home”. An enterprise grade installation is the same general idea but a very different discussion beyond the scope of this post. Many Intrusion Detection Systems and Firewalls offer the ability to download the PCAP of a falgged event. For example, if the system suspects a particular exchange of packets is malicious shell code it will flag the event and save that exchange of packets (example investigation). These small slices of PCAP typically do not tell the complete story. The PCAP provided for this analysis is from the ‘edge sensor’ located on the victim network. It is small for portability, but large enough that only an insane person would begin digging through it starting at frame 1. An analyst must learn to pivot through the data effectively. Using data reduction, indicators of interest, or Indicators of Compromise (IOC) analysts can pivot through large data sets quickly and effectively. Snort is a great example of a tool an analyst can use to pivot through network traffic effeciently. Keep in mind this is merely an intro, and is being used to quickly triage the PCAP data.

Installing Snort

Add Snort to your analysis VM with: sudo apt update && sudo apt install snort. Alternatively, you can run those two commands separately as shown.

Setting HOME_NET

Snort works off of signatures, or ‘rules’, to detect anomalies in network traffic. Many of these rules are written with the idea that the Snort Intrusion Detection System (IDS) will as a permanent sensor in an environment. Snort runs more effectively when it has knowledge of the environment it is monitoring. The HOME_NET variable tells Snort what network it is defending. This variable is set in /etc/snort/snort.conf by default. The rules written for snort recognize this variable and alert accordingly.

Using our analyst station to do triage and incident response as a stand alone system requires that we inform snort of the network that was defended when the PCAP was collected. From the client interview we know the network is 10.42.something.something . We run a quick tcpdump command to sample the PCAP for hosts fitting this general description tcpdump -nr case001.pcap 'host 10.42' -c15. This reads the case pcap, disables DNS resolution, and pulls the first 15 packets that have a host with an address that starts with 10.42.

Looking at the last 2 Octets of each host in the 10.x network we can make a fairly decent guess here that the Home Network is 10.42.85.0/24. This is close enough for our purpose. Edit the /etc/snort/snort.conf file where ipvar HOME_NET any is and change it to ipvar HOME_NET 10.42.85.0/24.

We disable DNS resolution for speed and to reduce noise the adversary may pick up on. Bad guys are smart enough to stand up DNS servers that the authority for their evil domains. You potentially tip your hand if you send traffic to their monitored DNS server; try and use -n as often as possible when using tcpdump for investigations.

Finding the Snort Config

As a side bit of training – to locate a file in Linux you can simply use the locate command. Update, and then ask. Notice the lack of results before updatedb was used.

Testing Snort

Test snort to ensure your changes didn’t break anything and you are ready to go with snort -c /etc/snort/snort.conf -T -i lo. This tells Snort to use the default config file at /etc/snort/snort.conf, run a Test against that configuration and use the loopback interface.

And hope for a result like this…

General Approach

The name of the game in most forensics is data reduction; this holds especially true in analyzing network traffic. Reducing the noise is key. If you have analyzed other artifacts prior to this and obtained a known Malicious IP address you could start your search that way. If you haven’t done analysis on other artifacts you must find interesting data using tools in your arsenal. Both approaches will be shown.

Assessing the PCAP

To quickly understand the scope of the PCAP use the command capinfos against it.

Important items to note:

• Packet capture date time range. Was this during the incident time frame?
• Number of packets. How much am I dealing with here?

An interesting note: this was not captured by a Kali box, despite what it says in the Capture oper-sys field. This was captured by a virtual router at the edge of the victim network.

Knowing that there are nearly half a million packets in this we must find a way to assess the data in quick meaningful ways.

Alerts

One way to pivot into the data quickly is to see if any low hanging fruit can be found with Snort. We are about ask snort to read the pcap and write alerts to the screen. The alerts will be ‘flags’ about anomalies in the traffic, or outright threats. Like any other ‘alert’ in this business they are not always full proof. It is up to the analyst to be… well… an analyst and ANALYZE the data. This is what separates the true analyst from the alert monkey. An alert monkey see’s the alert, pushes a button, and gets a banana. Alert monkey’s don’t get the top spot in the SOC. Be the analyst. Look into the data.

To begin the analysis ensure the pcap is living a directory in the appropriate case directory. As an example, for this case a directory titled /cases/szechuan/pcap. In SIFT analysts do most of their work in the /cases directory. A good practice is to ensure data is kept in an organized fashion. As always it is a good idea to use the tee command to create outputs every time a tool is run. Some tools take a long time to run. Simply reviewing the output can be much faster than running the tool a second time (looking at you memory analysis).

Before analyzing the results let’s talk about noise reduction. If you recall the PCAP has over 400k packets. If you count the number of lines in the output file you will find only a few hundred alerts.

wc -l snort.out

256 alerts is much easier to look at versus 411 thousand lines. Note: over time the exact number of alerts may change.

Take a look through the alerts. Look for things that stand out like references to hacking tools and malware. Alerts in this situation can be noisy due to a lack of tuning. There is also activity that won’t be flagged here that normally would be flagged by other tools. For example, Security Onion applies the Snort rule set: downloaded.rules. It flags an event that makes quick work of this PCAP. Security Onion will be covered near the end of this post. Yes, the downloaded.rules rule set could be added here but for now this will work great (adding rules here can be a real bear – let’s roll on). Look through the output either through scrolling, or using less snort.out (or whatever you named the output with tee).

Can you find evidence of hacking tools being used in the traffic?

---

Spoilers ahead.

 

 

 

 

 

 

 

 

 

 

---

In the alerts there was a great pivot point that should catch your eye. NMAP. This is an example of how understanding attack methodologies is a huge benefit to defenders. Network defenders should spend time attending Penetration Testing, and Red Teaming, courses to understand the tools of the adversary. A great hunter will understand what sort of animal left tracks in the mud. Likewise, defenders should understand when they are looking at evidence of a predator in their systems.

Take a look at the NMAP alert. Is this an internal system or an external system reaching into the network? You have Private IP Address ranges (RFC 1918) memorized don’t you? Also, what is the host at .10? In a real case you would want to ask the victim company what system is at this address since they likely didn’t provide a network map. The Administrator of the victim network would tell you this is the Domain Controller! You are looking at an outside system sending an NMAP probe to a key piece of the network. The Domain Controller is the heart of a Windows Enterprise. Both the attacker and the Defender want complete dominance of this system. NMAP, or Network Mapper, is a common tool for attackers to probe and and map out systems and open ports on target systems. This is a key moment in the ‘kill chain’. A good analyst looks at activity prior to and after a key event to try and understand the whole picture. What occurs just minutes later? By the way ‘minutes later’ in the PCAP is a tremendous amount of data versus only a few lines of text in the Alerts output. See how data reduction helps?

Moment later we observe rapid connections from an outside source to an inside source; in this case the Domain Controller. Side note: there is no good reason to have the DC exposing anything to the Internet. Ever. It should be in a private network. If Admins need access from the outside world the only ingress route should be a VPN tunnel. What sort of attack methodology would involve multiple connections per second to a service? A brute force! This remote system is likely attempting different username and password combinations! There is more to the story however. Take a closer look at the details. What are the source and destination ports?

 

 

Do not make the mistake of simply observing the destination port! Let’s walk through this together.

1. Outside system connecting inbound to
2. An inside host; the Domain Controller’s
3. Remote Desktop Protocol Port 3389
4. The host attempting the connection increments the source port by 2 every attempt.

Take a screenshot of this event and take notes. This source IP just became interesting as it is attempting to brute force its way into the server. This activity is very normal for any server that is exposing services to the Internet. In fact, it will begin experiencing attacks soon after it is connected. This article from “All Things Considered” discusses how a device was started experiencing logon attempts after only 41 minutes!

Now we have an indicator of interest to look into! Now we can use this IP address as a pivot into the data.

Pivots

Pivots are data points discovered elsewhere in the investigation that are used to speed up your analysis. For example, an IP Address found in something like Memory Analysis from the same case can be used as a “search term” in the PCAP. You will hear about pivots often here at DFIRmadness. That’s because it is one of the most import skills for an analyst to wield through the course of an investigation.

Who is Going Where?!

We now have an indicator to work with. Let’s table that for a moment and look at how we can explore a large PCAP quickly. A great tool to do this from the command line is tcpdump. There are some common switches you will seen thrown with the tcpdump you should be familiar:

-r simply reads the provided PCAP filename
-n Disables DNS resolution
-t Do not print the date time stamp
-tttt Print the time as hours, minutes, seconds and fractions of a second since midnight.
-v Verbose
-X Provide the Hex output of the frame.
-c Number of packets to display before exiting.

You are encouraged to do man tcpdump and read through the capabilities of the tool.

A quick lesson on how to read the IP and port pairing: the IP and Port are displayed as IP.PORT. For example, 192.168.10.24.80 would be 192.168.10.24 port 80.

To get start let’s read a sample of the activity in the PCAP related to 194.61.24.102.

Flags to Keep an Eye On

[S] SYN
[S.] SYN/ACK
[.] ACK
[R] RST (Reset)
[F] FIN

Remember TCP basics like the 3 way handshake? [S] , [S.] , [.]

If not it is a good time to go review!

• NetworkLessons.com YouTube Video
• Sunny Classroom YouTube Video
• Cisco YouTube Video
• Jeremy Druin’s Packet Analysis Intro <<<
• Jeremy Druin’s TCP Walk-through

A lot of hacking tools break the rules or look like anomalies. As an analyst you want to look for these. Keep in mind sometimes there are actual anomalies due to bad captures or bad connections; though these are the exception not the rule.

A Quick Peek

Now that we have an Indicator that in interesting to us we can take a quick glance at any traffic involving our interesting host. Let’s pull the first 20 packets:

tcpdump -nr case001.pcap 'host 194.61.24.102' -c 20

The first thing to glance at is the date of the first packet. Notice that the date time stamp is not as useful as it could be. Let’s try that again with tttt.

A full date time group can be obtained with tttt and is often helpful in increasing situational awareness. In this example, we can now say with confidence when the first observed contact occurred with the interesting remote host of 194.61.24.102. Is that time UTC or local? What do most forensics tools log their time in? We know this event took place in Mountain Time (recall the info from the client interview – or from data obtained in the forensics). It took place in September – which makes it 6 hours behind UTC. This means that if you want to correlate this to local time you need to subtract 6 hours from the time displayed by the tool. Keep in mind some tools can be off! Again, the analyst must be on their toes at all times.

Look at the data. What are the first few events between this host and the Domain Controller? Does this look normal? Let’s walk through this.

Here we see the ICMP Echo Request and its related reply. That’s easy enough to understand. The remote host sent a ping and our Domain Controller replied. Note, and screenshot, this as information leakage the client should shore up during the Recovery stages of the Incident Response process. We should not allow our machines to respond to pings to outside machines. We know this request and reply pair together due to the matching id number. This is a great example of why learning protocols and their internal functions is key.

Let’s look a bit deeper. Have you seen anything odd yet? Look at the traffic that occurred at the same time as the ping. Does this look like a standard 3 way handshake for port 80 and 443?

No. This is not normal. It could be some error with the capture- but it’s unlikely. We see the remote host try to SYN (initiate communication) with port 443, and then it immediately sends an ACK to port 80. It is even more odd that these two weird packets are seemingly related when we look the Seq and Ack numbers. They’re seeming related but also very odd! Take a look at other 3 Way Hand Shakes in the data. What we expect to see is a Seq number displayed, followed by an Ack of Sequence + 1. The increment of 1 in the handshake is due to the 1 bit flag being exchanged. Many folks incorrectly assume that this increment is a design of TCP regardless of the bits exchanged. In other words, it is not simply incrementing because it is supposed to do that as some sort of pattern to show a relation. It is a typical pattern because of the 1 bit flag typically being exchanged. Apply this knowledge to the odd pair we see above.

Now that we know it is odd, what do we do about it? We could simply flag this as odd and move on. However, we can also quickly spin up some VM’s and take a deeper look. Before we do that, let’s put together a hypothesis as to what is going on here. We see an ICMP probe from a system prior to that system initiating a suspected brute force. At the same time as this ICMP probe we see some very odd behavior in the packets from that system. Additionally, look back at the Snort alert. We saw a reference to NMAP. Let’s test in our lab and see what we find. For an accurate test we must set up a lab where the two systems are in separate networks – in geekier terms: we need the traffic to transit layer 3 just like it did in the real world. In other words, 2 machines in the same subnet won’t be an accurate test.

To test if this was in fact NMAP two virtual machines were spun up in separate virtual networks connected via a virtual router. We know that the attack centered on 3389, and that there was not a broad port scan prior. Let’s see what the traffic looks like when we conduct a Service Scan against a single port of 3389.

Well, lookie here! We have proven our theory! That is the exact same signature! Take a look at the odd activity again. It even includes the ICMP’s!

This next screenshot is simply a comparison of the port values when tcpdump is run without the -n flag.

Why would an attacker send a single probe to 3389? A better question is: how did they know 3389 was open!?!? Are you familiar with shodan.io? If not you really should be regardless if you are an attacker or a defender. Head over to YouTube and get caught up with a great channel, Lawrence Systems. The take away is that if you hook something up to the Internet it will be found and indexed. Attackers can go “shopping” for open RDP servers (as an example) to attack.

We have now confirmed that 194.61.24.102 probed our RDP server with NMAP; and then likely initiated an RDP Brute Force attack (a very common breach technique (sadly)).

Can you figure out which tool was used to do the Brute Force? Hint: it was not NMAP.

Who is Who in The Zoo

When an IP Address is identified as “Interesting” it should be investigated further. A quick way to do this is to look it up on VirusTotal. Keep in mind that if there are no detections for the IP Address, domain, or hash it does NOT mean it is clean! It simply means it isn’t identified as malicious… yet.

This is great for initial situational awareness but there is more to the story. Select the “Details” tab.

 

Note the country that this IP might reside in. Does this organization do business in that country? Do they have admins operating from there? Is it simply an Admin using a VPN? The point is country code alone isn’t damning even if it’s accurate. The modern Internet is very flat. It is not unusual to see legitimate traffic from all over the world – to inlcude “the usual suspects”. That said, TOR Exit nodes are almost always interesting. This may not be current or accurate! Always try and validate with other tools. Give shodan.io a try for example. The details tab offers a lot of information. Take a look at what it has to offer and then scroll down to the “Google Results” area of the Details page.

Well. Isn’t that interesting?! This IP Address has been seen conducting RDP Brute Force attacks elsewhere! This is a key piece of historical information. It helps confirm some of the key pieces of our hypothesis and findings. Attackers like to do the same dance move over and over again. Keep this is mind when doing investigations. Sometimes the smallest piece of information about an artifact can break a case wide open by pushing you in a new direction. These new directions can lead you to look in places you hadn’t thought of yet.

The “Relations” tab is also a “must see”. It’s good for your situational awareness to understand the domains related to the IP Address in question. Note the date!! IP Address and Domain relationships drift over time! What is true today may not have been during the incident (if you are late to the party) or even a few weeks ago. Look the rest of the page for things like prior instances of malware associated with that indicator.

Another great resource are open source threat intel feeds. Understand these are partly crowd sourced and your mileage may vary on the accuracy of their claims. Go ahead and see what you can find at Threat Miner and Threat Crowd.

Who Went Where

Another approach to investigating PCAPs is to look at what internal systems were reaching out to remote systems. This works exceptionally well if you already have some hosts, or protocols, identified as interesting. We can locate hosts initiating connections by searching for SYN flags. We can search for hosts reaching out to external hosts by narrowing this search to destinations not inside our network. These searches are done using tcpdump and Berkley Packet Filters.

Berkley Packet Filters seem challenging at first but are in reality pretty easy to work with. BPF is used to select packets with particular flags. A great starting point on learning the tcpdump flag combinations is either SANS SEC503 or the manual for tcpdump.

man tcpdump

The man page for this tool is a small book on the matter and well worth the read if you plan on really getting into network analysis.

Macros are built in combinations of BPF that can be called with keywords. There are some key macro’s in tcpdump that can be used to select packets with things like particular networks or hosts. When testing BPF and macro combinations limit the results as initial test to ensure you are on the right track.

This initial glance is a decent start. However, if we look for SYN flags specifically we can quickly find out who in the network was reaching out to initiate a TCP connection. To hunt SYN flags we need to tell TCPdump to look at the 13th field of the TCP header and find packets where the TCP flags are set to 0x02 – which is BPF for the SYN flag. Remember that handshake in the beginning?

tcpdump -nttttr case001.pcap 'src net 10.42.85.0/24 and not dst net 10.42.85.0/24 and tcp[13]=0x02'

You are now looking at every SYN packet that left the network… almost. There are ECN packets we are not taking into account.

ECN Flags

Explicit Congestion Notification flags will break some of the magic of using the BPF filters to find certain flags in the PCAP. An overly brief explanation is that certain Operating Systems will have their TCP Stacks set bit in the ECN bits area and we have to filter accordingly. In other words, simply looking for the exact bits set in the TCP Flags portion of the header isn’t through enough. We have to account for that by slightly changing the filter to: tcp[13]&0x3f=0x02. Now we can see SYN flags sourced from the Domain Controller that cannot be seen with tcp[13]&0x3f=0x02.

Linux-Fu and TCPdump

Using the Linux commands: cut,awk,sort,uniq and BPF Filters can you determine things like:

• Which internal hosts reach out to remote systems?
• Can you determine a list of remote servers that our internal hosts reached out to?
• Which remote machines connected to our local machines?
• How many times?
• How many times did internal hosts reach out to remote systems?

---

SPOILERS AHEAD

 

 

 

 

 

---

It is far easier to experiment with only a few packets. Limit the count to a small amount when testing. When you are done testing remove the count limit.

Examples of Exploring the PCAP from Command Line Only

Frequency Analysis of Internal Machines Initiating Outbound Connections

tcpdump -nttttr case001.pcap 'tcp[13]&0x3f=0x02 and src net 10.42.85.0/24 and not dst net 10.42.85.0/24'|awk '{print $4}'|cut -d '.' -f1-4|sort -n|uniq -c|sort -nr

Don’t simply cut and paste this and move on. Learn the command shown above. This powerful combination of Linux commands can be rearranged to answer many more questions about what happened on the network.

Can you get these answers on your own?

Remote Systems Contacted by Our Internal Systems by Frequency

Connections Initiated to Our Internal Systems From the Outside by Frequency

RDP You Say?!

We also noticed that there was some RDP in these packets. Let’s get situational awareness around RDP events.

tcpdump -nttttr case001.pcap 'tcp port 3389' will dump out every RDP packet in the PCAP- so long as it used the standard RDP port of TCP 3389. Remember to control for source and destination networks to answer questions accordingly.

Did we see any RDP from the outside? We already know this from the Snort Alerts. However, as a point of learning lets see it in tcpdump.

tcpdump -nttttr case001.pcap 'tcp port 3389 and (dst net 10.42.85.0/24 and not src net 10.42.85.0/24)' -c5

Were there any RDP sessions between internal hosts?

tcpdump -nttttr case001.pcap 'tcp port 3389 and (src net 10.42.85.0/24 and dst net 10.42.85.0/24)' -c15

What is this data telling you? Look at the handshakes. Treat [SEW] like [S].

PCAP Carving Interesting Packets

Searching a PCAP is easy when you have a starting point. Looking for evil is faster when you have indicators to hunt for. You have seen how to find indicators in the PCAP; or you could have found them elsewhere in the case. Either way, at this point you should have 194.61.24.102 on the “whiteboard o’ doom”- or where ever you are tracking the enemy. The process may look like this:

1. Search the PCAP for the Indicator 194.61.24.102
2. Carve out all packets where this host is present into a smaller PCAP
3. If this resultant PCAP is small enough open it in something like Wireshark.
4. If the PCAP is still hundreds of megabytes try carving it with multiple indicators. This doesn’t apply to this case but it could easily happen in the real world.
5. Use secondary tools to look for files that flew on the wire like Wireshark, Network miner etc.
6. Continue scoping the incident by finding other internal hosts talking to the adversary

The following walk-through is one example of roughly following this template. Every case is different. Learn the tool. Understand the goal. Don’t learn clickology. Be a hacker!

TCPdump Carving

Tcpdump can be used to easily ‘carve’ out packets with our suspect system from the larger PCAP. You should be running this from a directory containing the PCAP from the case in the /cases folder. You’re not still using the Desktop are you????

tcpdump -nr 'host 194.61.24.102' -w /tmp/host194.cap
mv !$ .

This will carve out packets where the interesting host appears and write it to a cap file in the tmp directory. Tcpdump prefers to write to world writable directory. These settings can be over-ridden with some work. However, the easy button is to write to /tmp and move it over with mv. Notice the !$ shortcut?

Notice the reduction in the data! This training PCAP was kept small on purpose. This carving technique becomes far more important with PCAP’s that are GIG’s or several hundred Megs! Run capinfos on both and note the differences.

Wireshark and File Carving

Once you have a smaller PCAP we are ready for a more focused look with Wireshark. Wireshark will easily handle the 189 MB Case PCAP. However, this is all about learning and practicing. Carve it down, then open it from the command line. It is tempting to run Wireshark as root. Don’t do it. It’s a bad habit and dangerous. Simply open a new terminal or drop out of sudo for a moment.

exit
wireshark host194.cap &

Exit the root prompt. Use Wireshark to open our PCAP focusing on host 194.61.24.102 and run it in the background (of the prompt). A Wireshark window should open and load the PCAP.

Searching for Keywords in PCAPs with Wireshark

Wireshark makes searching for items of interest in the traffic easy. To search for keywords in the buried in the traffic that you are interested in you can start with a strings search in the bytes. This is an effective way to look for previously discovered IOC’s or other items of interest.

Press CTRL+F to bring up the search bar.

1. Select ‘String’
2. Select ‘Packet Bytes’
3. Input interesting string
4. Click ‘Find’

Gaining Situational Awareness

A great place to start looking into a PCAP is the Statistics Menu.

The Protocol Hierarchy, Conversations, Endpoints and I/O graph are good starting points for getting your situational awareness.

As an example, let’s look at the Endpoints menu option.

Let’s close this and take a look at the traffic.

Using the Wireshark display filter ip.addr==10.42.85.115 we can isolate the packets in this PCAP to the internal host of our network. Knowing we are already looking at a PCAP that only contains packets involving 194.61.24.102 we know we are looking at a conversation between the suspect remote host and the internal host. Look at the opening volley of traffic. See the TCP Handshake followed by an HTTP request? Selecting the packet where the HTTP Request occurred we can find out if the host went to a domain or directly to an IP Address. This is an important distinction in network analysis. Wireshark interpolates the data and presents its belief in what the host had requested. This interpolated data is known as ‘Expert’ data. It is information not found directly in the Packets, but rather it is derived from the data. Information like this is indicated by [ and ]. We can tell this host went direct to an IP Address. This is interesting since most normal user traffic doesn’t behave that way. Do you type IP Addresses into web browsers usually?

Let’s follow the stream to see what these two system exchanged. Right Click the HTTP Request Packet, Select Follow, and then select the Follow HTTP or Follow TCP options.

Examine the findings.

We see three interesting items. An internal host reached out to a remote suspect host and downloaded a suspicious file from a Python Simple HTTP Server; a common attack technique. Together these paint a bad picture. Note this is a common PenTesting trick and more skilled attackers are likely not going to be as obvious with a Python Simple HTTP Server. That said, downloading malware over HTTP in 2020 is still a thing.

The next step is to inspect this file. We need to carve it out of the PCAP. There is a quick win for this using Wireshark.

Save the file to the same directory where the PCAP for the case is located. This makes it easy to remember this file was extracted from the PCAP. Stay organized! Remember that Wireshark is running as a regular user. Chances are the cases folder you are working in is owed by root. Simply save this file to a new folder in the the /tmp directory, and then move it to /cases/szechuan/pcap.

File Inspection and Triage

A great starting point to check if a file is malicious is to send the hash of it to VirusTotal. Sending the hash is a good start because some advanced attackers will be watching VirusTotal for their own malware. If it is something special they cooked up for you they will know they are burned when you submit the file. When they know they are burned they may start changing their behavior, speed up their attack, or begin removing all the evidence. Send the hash, not the file.

sha256sum coreupdater.exe

Copy the hash into VirusTotal.

To simulate finding unknown malware a single character will be changed. Even if VirusTotal reports the file as malware you should continue examining the file to ensure you aren’t missing anything.

No findings? No problem. Let’s use some SIFT and REMnux pre-installed tools to investigate further.

CAPA

FireEye is always putting out great tools for the industry to use in the fight against evil. One of the most recent additions is Capa. Simply run Capa against the file to try and gain an understanding of what this suspect file might be capable of.

Interesting! The executable is using obfuscation to attempt to hide information. Moreover, it is using XOR! These are known techniques the bad guys use to bypass network defenses and make life harder on investigators. We have some tricks up our sleeves too. Let’s keep going.

FLOSS

FLOSS is yet another FireEye tool in our arsenal. It does an exceptional job of trying to cut through obfuscation and return meaningful strings. We are hoping some of these strings will reveal IOC’s like IP Addresses and Domain Names the malware will call home to.

Floss wasn’t able to retrieve the IOC’s we were hoping for (if they are there). However, there are still interesting findings. The word PAYLOAD: should make the hairs on an investigators neck stand up. We also see some indicators this executable may be importing the functions need to do process injection! This is not definitive. It’s just an indicator that when combined with everything else we are starting to get an idea this executable intends to do evil.

Clam Av

Update clamscan and let it have a crack at it as well.

freshclam
clamscan -v coreupdater.exe

Nothing this time around.

Sandbox Detonation

It looks like static analysis of this file is not giving us any quick wins. At this point a junior analyst needs to send the file to a reverse engineer, or detonate the file in a sandbox. Up until this point we have been conducting static analysis. The next phase is to see the file actually run and do what it is designed to do. This is called dynamic analysis. Executables that are obfuscated must de-obfuscate themselves to run. “Malware can hide but it has to run”. Systems designed to detonate malware and safely observe its behavior are called sandboxes. Advanced adversaries use malware that is aware of sandboxes and will not detonate if it detects, or suspects, it is “sandboxed”.

A quick easy option are online sandboxes. Be careful. Some adversaries watch these public sandboxes for when their malware is detonated there and will act accordingly (see above). For this exercise we will use one of the many free online sandboxes, any.run.

Once logged in you can search for the hash to see if someone had previously detonated this malware. If nothing is found you can submit the file.

When you go to submit this file it doesn’t run! Hmmm. Could it be this is a 64-bit file? Did you notice that it only supports 32-bit?

Let’s try another Sandbox, Joe Sandbox.

Notice even Joe tries to warn you that you are about to tip your hand to the World that you found this malware.

Once you confirm the payload detonation it will take a few minutes. However, the results are worth the wait.

WHAM! We have successfully uncovered the secrets of coreupdater.exe. When the IOC tab is selected we find a new IOC to add to the Board ‘o Doom: 203.78.103.109.

We now know we are dealing with a malicious Trojan that is part of the Metasploit toolkit and it’s calling back to 203.78.103.109, a server likely residing in Thailand.

An amazing feature Joe Sandbox offers free users is a full report generated on the Malware for you! Grab a copy.

Select the PDF Report.

Read through it until you find the MITRE ATT&CK portion of the report.

This is also known as a “Cross Walk”. The MITRE ATT&CK Matrix is one of the best resources to hit the industry in the past decade. It deserves its own post. For now, understand that this is here and is one of the easiest ways to understand the capabilities and intent of an adversaries malware. Take a look through the report. It’s pretty epic for no money, and 5 minutes of waiting for it to detonate.

Back to the PCAP!

We have new information! The new IP address added to the “Doom Board”! We need to investigate this new finding! Knowing at least one piece of malware communicates with 203.78.103.109 we can use this information to see which systems successfully reached out to the Command and Control (C2) platform for this adversary. You know how to do this! Look at at previous commands with tcpdump. Knowing 10.42.85.115 is the internal host inspect the PCAP with tcpdump and use your new found skills.

Examing the first 5 packets of the case001.pcap file what do we see here? What is significant about the time stamps and the flags? What does the P flag mean? What other tool can we use to understand the systems in our network that had conversations with this malicious host?

In the end we can say for sure that 10.42.85.115 reached out to a known malicious IP and started communicating with it. Before you move on, ensure you understand how we are able to say that definitively here.

PCAP Analysis with Security Onion

Overview

Security Onion is about to retire. It is being replaced by Hybrid Hunter (aka Security Onion 2). For this reason a full write-up currently would be a bit of sour investment. However, understand the Security Onion OS as a stand alone Virtual Machine is an absolute beast of a PCAP Analysis station. For now, understand that it is a great option to explore on your own.

Guides

The official documentation is fantastic. In the Table of Contents you will see selections for building it in VMware or VirtualBox.

Build Notes

When you build the VM ensure you have two virtual network cards installed.

Importing the PCAP

To import the pcap, download it, then import it with sudo so-import-pcap case001.cap.

General Idea

Security Onion allows the analyst to easily detect anomalies by seeing alerts in the Sguild client. From here they can easily extract malicious files and gather intelligence.

Further Updates

In the future this post will get an update when Hybrid Hunter is officially released and I have had time to learn the new system.

Conclusion

We started off by reducing the noise and running an open source Intrusion Detection System (IDS), Snort, against the case001.pcap. This highlighted the brute force activity from 194.61.24.102. TCPdump was used to explore activity between internal hosts and external hosts in addition to internal RDP communications. We further reduced the data by carving out the packets that contained communication with this host from the larger case001.pcap. By analyzing this smaller PCAP we discovered that both the Domain Controller and the Desktop machine were likely compromised. We also easily carved the suspect file, coreupdater.exe, from the PCAP which was downloaded to both hosts. This suspected malware was examined with static analysis. Little information was obtained with static analysis. Dynamic analysis with a sandbox was used next.
Using Joe Sandbox the file was confirmed to be malware calling back to 203.78.103.109. This malware was explicitly identified as being from the Metasploit family; meaning this is meterpreter. To summarize, it appears that the adversary brute forced RDP to gain access to the Domain Controller. Next they RDP’d to the user machine and downloaded the same malware to infect that machine as well. We can assume the malware successfully executed because we can see traffic to the Command and Control Platform from both machines. This information is key to directing other teams. For example, the firewall team should begin inspecting traffic to scope out which hosts in the Enterprise are infected with this malware. Armed with a solid set of IOC’s we are now ready to pivot to other artifacts in the case.

IOC’s to Take Away and Pivot with

We don’t know if we will find the IOC’s in next moves listed below, but they are great pivot points to start with things like keyword searches etc.

To Disk: Filename coreupdater.exe, and malicious IP’s 203.78.103.109, 194.61.24.102.

To Memory: Malicious filename: coreupdater.exe and malicious IP Addresses of 203.78.103.109, 194.61.24.102.

To Autoruns: coreupdater.exe

Things to Study or Try Next

• TCP Protocols in depth
• UDP Protocols in depth
• TCP/UDP Headers
• TShark

This was merely an intro to the deep well of knowledge that is Network Analysis. If you enjoyed it, use materials at the beginning of this post to keep studying!

Choose Your Next Move

I want to look at the Memory!

I want to look at the AutoRuns (Coming soon)

Also, I want to look at the Disk Image and Timelines (Coming soon)

Don’t forget to leave any thoughts or questions you have on PCAP Analysis in the comments.