The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

Network Forensics

4. Wireshark (OBJ 4.4)

In this lesson, I'm going to use a tool known as Wireshark, which is a packet analyzer, to be able to pull apart some network traffic and show you the different layers of the OSI model. But for right now, I just want you to focus on how I'm pulling apart these different layers and the type of information I can get from Wireshark. Again, this is going to be further and more in depth than you need to know for the exam, but it's going to help you understand the OSI model a little bit better as we start putting these pieces together from this theory into something that's actually used on the network. So let's jump into the environment and take a look. All right. Welcome to Wireshark. Now the first thing we need to do is have a file to look at. So I have a couple of different packet captures, and I'm just going to open one up here, and it's going to be right here. This is an HTTP connection. So what I'm showing here on the screen is everything that happened for one computer to make a request from my computer to a server and back. So as you can see here, it starts at time zero. The source IP is my machine that sent the request, and the destination IP is the server I'm trying to go to. That's how we read these things. It's time source, destination, the protocol used in this case, TCP, and then the information that was sent. As you go through, you'll see there's a two-way conversation going back and forth between the two. And what you're seeing here is actually the session traffic that was captured from one host to one server. Now, as I scroll down a little further, you're going to see it goes down to 43 different line items that happened. It took 30 seconds total. and we're going to go in and look at some of this information. So let me go into this first packet. And here in the middle section, you'll see that we have frame one. This was the first frame. Now, going back to our OSI model, what is frame? Where do frames operate? Well, they operate at layer two. So I should expect to see some layer-two data in here. What types of things are layer two data? Well, things like Mac addresses. So if I open this up, you're going to see that the encapsulation type was Ethernet, which is a layer-two protocol. We can see the time it arrived, wecould see the time that it left. We can see what frame number it was and how long the frame was. We could see how much was captured and all the types of information there. Next, if I go into Ethernet 2, this again is part of Ethernet, which is Layer 2. And inside layer two, we can see our destination and our source. So this is our destination. This is the server I was trying to get to; its Mac address is below it, and underneath it we can see the source, which is the machine that I had that made the request. And it happened over IPV 4. And if I bring this down, you can actually see even further details. Now, the next thing I'm going to look at is IPV 4. When I start talking about IP, what are we talking about? Now? We're talking about layer three because we're talking about the Internet Protocol. This means that we're going to have source and destination IPS, as you can see here, highlighted in blue. And if I open that up, you'll see that this was version four. We can see the header length, and then we can actually dig into that packet. but again, way beyond the scope. The big thing we want to take away is layer two, which is Mac addresses. Layer three was IPS. Now when we go to layer four, we're going to be talking about: did we use TCP or UDP? In this case, we use TCP. So this is our Layer 4 of the OSI model. And as you can see, we're building up each of these layers. And all of that was one 162-bit packet that we captured. So the next one I'm going to do is the one that came back from the server to the host. So we sent the sin over, and now we have a synagogue back. As we look at that, we can see the same type of information in the same layout each time. You'll see that we have our frame, our layer two addresses, our IP addresses, and then our TCP protocol, layer four. So layer two; layer two; layer three; layer four. And we can go through the entire packet and look at each and every one of them. Now, if I want to figure out what was happening during this session, I can do that as well. So if I go in here, I can see that there was a Get request over HTTP. Now, HTTP is a protocol; it's an application. So this is actually a layer seven capture here. And if I open this up, I can see that they went to the server ethereal.com, that they were using Mozilla, which is Firefox, and that they came from this ethereal.com development, HTML webpage. And they clicked on the link to download HTML. And that's what we're asking for. We're asking for the web page's download HTML at this point. This is then acknowledged by the server and goes back and forth as they get more and more data. And eventually, we get that web page downloaded. In fact, if I right click on this, I can tell it to follow the stream, and I can see what that Web page looks like. Now this web page is being shown to be in HTML because that's how web pages are sent. But this is exactly what this person got when they went to that website, and we captured all that in this network packet. I could actually copy this, make it into an HTML file, and then load it up inside of Internet Explorer or Edge or Google Chrome or Firefox and be able to look at all of that. So I think that's enough of that packet. Let's take a look at another one and see if it looks similar. The next one I'm going to look at is this one here that says FTP. And what FTP is going to do is use the file transfer protocol. It's going to be very similar. You're going to see that we went from a source to a destination, and they went back and forth a whole bunch of different times. And in this case, it was a much longer stream. 561 different packets went through that were captured. So if I go back to the first one, you'll see that there was this acknowledgement, and they went back and forth. And we can go through here and see frames again; that's layer two, Ethernet. So, once again, we can see the source and destination as far as those Mac addresses are concerned. If we go down to the next one, we go up to layer three. We're now seeing the source and destination IP addresses. And when we get to layer four, we're able to see that this was a TCP session transmission control protocol. And so again, if I wanted to, I could right-click this and follow that stream. Now when I follow that stream, what am I going to see? I'm not going to see a pretty Web page because this was FTP traffic. Somebody was downloading a file. all of this. If I convert it back into its hexadecimal or binary format, let's go to Raw, for instance. I can copy this in and try to figure out what type of file it was and put that back together. That's what happens with network forensics and digital forensics, which go way beyond the scope of this particular course. But that's the idea here. You can capture everything going over the network into these PCAP files packet capture files), and you'll be able to open them inside of Wireshark to see what type of traffic is being used on your network. Really, you're going to be focused mostly on the screen, the source and the destination, the protocol, and even the ports. You can see here that it went from port 80, the Web port, to port 2727. The server then answered up from port 2727 back to port 80, and they went back and forth throughout this communication. Let's open up one more. We're going to open up TELNET. Now telnet is a way to remotely control a computer. Again, you're going to see that we have the time, the source, the destination, and the protocol, just like we did before. We have our synacdoche, which is that three-way handshake. And again down here, we have layer two, layer two, layer three, and layer four. Now in the protocol column you're going to see TCP, but you're also going to see this telnet data, and that is an application. So this is layer seven again, just like we saw with HTTP before. And if I go over here, I can see that layer—even now that it is added—and I get different information for that if I go through and right-click it and follow that stream. Let's see what we get this time. There we go. So what we're seeing is the person and their session when they try to connect to a Telnet server. So what you see in blue is what the server sent back. So when they connected, the server said, Hey, I'm an OpenBSD server login. What the person did was type F-A-K-E, which you can see is red. That's what the user sent to the server. And the blue is what the server displayed on a screen, which was fake. So their username was fake. Then it asked for their password, which the user typed in, "user." So their username is fake, and their password is user. At this point, they were able to log into the server and start running commands. They run the LS command, which, if you remember from a plus on a unit system, is going to list the contents of a directory. And then they did it again, LSA theywanted to see it going across the sideand you saw this is what came back. This is a list of directories. Then they tried to run aprogram s bin ping www@yahoo.com. And that is showing that they tried to do a ping from this telnet server out to @yahoo.com, and they received this information back. Now we're seeing the entire conversation. We're seeing both halves. But if I wanted to see just what one person sent to the other, I could see it on the server side. It's a lot easier to read, right? But now I don't see that password. I don't see the commands that got sent over when I got here and switched over to the client side. This is what they typed in. I can see that they typed in User, which was their password, fake, which was their username, and then the commands, the list command, the list all, and the SBIN ping www.yahoo.com, and then exit. So you can see how this is useful and where we can start digging into this stuff. If you pursue a career with CompTIA and attend tent plus training, you will become very familiar with wireshark and will be able to dig in and grab this information from the wire. Now again. like I said. This video was a little bit beyond the scope of what you really need to know. But hopefully I've whet your appetite to the point where you're eager to learn more about wireshark and how you can use it both as a network technician and as a programmer. You need to be able to see where the breakdown of communication is. Whether it's layer two, Layer three. Layer four. Or layer seven. Or, from a defence standpoint, with cyber security analysts going through these packets and figuring out what the bad guys did on your system, because it will capture everything. both the server side and the client side. or if you're using it for Pentest. Furthermore, if you obtained this type of information, you now have access to that individual's username and password, which you can use as a follow-up in your account.

5. Flow Analysis (OBJ 3.1)

As you might have guessed, packet captures can take up a lot of storage space and can grow quickly in size. For example, if I'm conducting full packet capture on my home network each day, I would need several gigabytes of storage just for my small family because every single packet that goes in and out of my house would be captured. Every video my son is playing online, every YouTube video he watches, every Netflix show my wife binges—all of that would be captured bit by bit. This is known as a full packet capture. Now, a full packet capture, or FPC, is going to capture the entire packet. This includes the header and the payload for all traffic that is entering or leaving your network. As I said, this would be a tonne of information and quickly eat up all of our storage. Now, because full packet capture takes up so much storage space, a lot of times we won't collect it. Instead, we'll use something called flow analysis, and this relies on a flow collector. Now, a flow collector is a means of recording metadata and statistics about network traffic. Rather than recording each and every frame that's going over our network, this allows us to use flow analysis tools that provide network traffic statistics sampled by the collector. This way we can capture information about the flow instead of the data itself, saving us a lot of space. But we aren't going to have the contents of what was going over the network, just information about it. Now, this information can be stored inside a database and queried later by our different tools to produce reports and graphs. This is the idea of flow analysis. Now, the great thing about flow analysis is that it's going to allow us to highlight trends and patterns in the traffic being generated. It allows us to get alerts based on anomalies that we might see and different patterns and triggers that we might see. We can also have visualisation tools that allow us to quickly create a map of different network connections and flow patterns. And we can identify different traffic patterns that might reveal bad behavior, malware, and transit tunneling, among other bad things out there. Now, to do this, we can use several different tools. For instance, there is Netflix, Zeke, and Multirour Traffic Grapher. Let's talk about each of these. First. We have NetFlow. Netflix is a Cisco-developed means of reporting network flow information to a structured database. This was one of the first ones out there, and eventually it actually became the standard that everyone started using under the name IPFIX or IP Flow Information Export. Now this allows us to define a particular traffic flow based on the different packets that share the same characteristics. For instance, maybe it's the same source and destination IP, signifying that there's a session between two hosts. That would be one data flow, and we can get information about it. Now, some of the information we can capture inside of NetFlow is going to be information about the packets that go over the devices. things like the network protocol interface that's being used, the version and type of IP being used, the source and destination IP address, the source and destination port, or the IP's type of service. All of this information can be gathered, and then we can actually analyse it and look at it visually using different tools. For example, here on the screen, you can see that I'm using the Solar Winds tool to show the net flow data of a network. Or you can look at it in a text-based manner. For instance, here you can see the different flows that are there, going from one all the way down to flow 15. And as I increase the ability to look into flow 15, you can see the source and destination addresses, the source port, the destination port, and some basic information about it. But you don't see the content of any of those packets that have been going through. Now, because of this, NetFlow is going to provide you with metadata, but you're not going to have the full packet captures, so you're not going to have a complete record of what's happening. Now, if you want to be able to have the best of both worlds, you can use something like Zeke. Zeke is a hybrid tool that passively monitors your network like a sniffer, but it's only going to log full packet capture based on data of potential interest. So essentially, it's going to be sampling that data just like Netflix does. But when it finds something that's quite interesting, it's going to log the entire thing. So we can then go back and look at that. This helps reduce our storage and processing requirements, and it gives us the ability to have all this data in one single format. One of Zeke's great features is that it normalises data before storing it in tabbed or JavaScriptObject notation language JSON formatted text files. This allows you to use it with lots of other different tools. For instance, here you can see on the screen that since this file was normalized, I could import it into another tool for visualisation searching and analysis. In this image, I've imported the Zeke logs into Splunk, and from there I'm able to search for specific information during my analysis of a potential incident. The third tool we have is the multi-router traffic grapher, or MRTG. Now, if you took Network Plus, you've been introduced to this before because it was on that syllabus as well. The MRTG is a tool that is used to create graphs that show network traffic flows through the network interfaces of different routers and switches. SNMP, the simple network management protocol, is used to pull those appliances. This looks like this graph here on the screen. Now, what is useful about this? Well, you can see patterns emerging. For instance, in the top graph on the router firewall, where do you see a big spike in traffic? You can see that there's a big spike in traffic between two and 4:00 a.m. Now, is that normal? Maybe, and maybe not. But it's something we should go and further analyze. Because if we see a big spike between 2:00 and 4:00 a.m., that could be something normal, like we are doing offsite backups, and therefore we're going to do that during offpeak hours and you'll see a big spike in traffic as we're sending our data to our offsite facility. Maybe that's a reasonable explanation. Or maybe the server has been infected with malware, and at 2:00 to 4:00 a.m., when we're all home sleeping, they're sending all the data back to the bad guy, who is now collecting our data as part of data exfiltration. We don't know just by looking at this which of those two cases it is, but by looking at this, we can identify that we should zero in between two and 4:00 a.m. and figure out what that additional traffic flow was that happened and why. So based on this, we might make a hypothesis that we think data exfiltration is happening. In that case, we would want to set up a network sniffer in front of the server to see what traffic is leaving and where it's going to. Based on that, we can then dive deeper to see if it was something known good, such as a backup, or known bad, such as a bad guy. Bye.

6. IP and DNS Analysis (OBJ 3.1)

IP and DNS analysis. Now, many intrusions rely on C2 servers—or command and control servers—for the attack to download additional attack tools and exfiltrate data. As a result, analysing traffic for any access request to an external host is one of the specific areas of interest for a cyber security analyst. If you can identify these, you'll most likely be relying on an IP address and its DNS resolutions. If you subscribe to a service that provides reputation-based feeds, most of these are going to be based on IP and DNS as well. Now, in the old days, malware used to be configured to contact a specific static IP or DNS name as part of its code. So when that malware was downloaded and installed, it would call it from a specific static IP address or DNS server. When that malware was downloaded and installed, it would use a specific static IP or DNS name to contact it. Now, because of that, we would be able to develop what we call a known bad IP address. These are IP addresses or ranges of IP addresses that appear on one or more of our blacklists. And these blacklists were a way that we could basically play "Whack a Mole." A bad guy would start a new domain, we would find out it was bad, we would put it on the blacklist, and they would start another domain. and we'd keep doing this over and over. This is how reputation-based risk intelligence is done to create an IP or URL blacklist. We find something bad; we add it to the list. And so here you can see on my blacklist a thing called Bol.com BR. You'll notice that it's listed as a RAT because it is a remote access Trojan that's been associated with this particular DNS. Now, that's great, and that means that we can block this. But if they change their domain name, we're now going to have to go find that and block that too. As defenders, we try to outsmart the bad guys, but every time we find a way to block them, they find another way to get around it. And because we started using a lot of blacklists and blocking known bad IPS and known bad DNS, they started using what's known as domain generation algorithms to overcome those blacklists. Now, what is a domain generation algorithm? Well, a domain generation algorithm, or DGA, is a method used by malware to evade blacklists by generating domain names for command and control networks dynamically. Instead of having a static IP or a static name, they can create one and pick from a list of a lot of them, then keep moving through those until we block them all. And then they'll just create more. And they keep doing this over and over. Dynamically. Let's talk about how this works. There are five steps for an attacker to use. Now, the first thing an attacker is going to do is set up one or more dynamic DNS services. This allows them to be able to have domain names that can be automatically generated on the fly. When they do this, they'll sign up for a service using a fake payment or fake credentials, or they might use some host that really doesn't care if they're doing illicit activity. Once they do that, they'll move into step two. And this is where the malware code is going to implement the DGA. This DGA is then used to create a list of new domain names. Now, the way this works is that it's an algorithm, and it will use some kind of value to seed it. And then everybody who has that algorithm knows what that initial seed is and has the same key, essentially, to be able to use the same list. So if the piece of malware has it and their server has it, they both will have the same dynamically allocated names that they can jump to each time. The way this works is essentially like an algorithm that uses some kind of seed or random number or time-based basis or something like that. So for instance, we might have a start date that we're going to use, and that is going to be the seed. As we use that, it's going to create an output of a bunch of cryptic strings that basically have numbers and letters to make up domain names. This way, they're all randomized, and they won't already be on your block list. Then they move into the third step. At this point, a parallel DJ is going to be used to create the name records in the DDNS service. So now that we know what the malware is going to use, we also need the DDNS service to have it so those two can match up. And again, if they both use the same seed, they're going to have the same matching names. Then we go into Step Four. This is where the malware tries a selection of those domains that it created to connect to the C-2 server. This is in case the seed was off by a little bit. Hopefully they'll still match up, and they'll be able to make that connection. And then number five, the C-2 server, is going to communicate a new seed over time. So that way, they can change that DGA in case you reverse-engineered it and tried to block their attempts. This way, they can avoid being blocked and continue to do bad things. That's the idea with this DGA. It's this dynamic list that is constantly changing because it has this constantly changing architecture. This is often known as a fast flux network. Now, a fastflux network is a method used by malware to hide the presence of Two networks by continually changing the host IP addresses in the domain records using domain-generated algorithms Everything we discussed with DGA is essentially part of a fastflox network. So you may be wondering, as analysts, what can we do to detect a DGA? Well, there are a couple of giveaways that you're dealing with a DGA or a FastFlox network. Now, the first one that you'll see is if you start seeing a lot of call-outs from your systems to random IP addresses that look something like this. For instance, you see this random series on lettersandnumbers.com. That is a great sign that you are dealing with some sort of computer-generated label with some kind of constant to value ratio that just doesn't look right. Most people wouldn't buy a domain namelike a one Zwbr, 93, com. They would buy deontraining.com or CompTIA.org or something like that. So if you see things like this, it's usuallya sign that there's something malicious going on. The second thing that you can do to detect a DGA is if you start seeing a high rate of NX domain errors when you're resolving to DNS in your logs. This could be an indicator of a DGA. Now, what is an NX domain error? Well, have you ever gone to a website and got a message that looks like this? It says this site cannot be reached. The DNS probe was completed with the NX domain. That's an NX domain error. Essentially, you've tried looking up that domain name and can't figure it out. That's what it is. That's when you can't get the DNS resolver to resolve that DNS for you. And if you're using a dynamic DNS like this with a FastFlox network, they're often already moved off of that domain and onto another. And so you're going to get an NX domain error. Now, how do you mitigate these DGAs? Well, the best mitigation is to use a secure recursive DNS resolver. This is going to allow one trusted DNS server to communicate with several other trusted DNS servers to hunt down the IP address and return it to the client. So instead of going out to a generic DNS service to be able to get those domain names to IP resolutions, you should be using a trusted DNS server that uses recursive look up.If you do this and they keep track of what types of DNS are available, they will constantly block those for you and help protect your network.

7. URL Analysis (OBJ 3.1)

URL analysis. Now, at this point in your career, you should know what a URL is. A URL is a uniform resource. Locator. It's that little address that you type at the top of your web browser to get to deontraining.com, CompTIA.org, or whatever other website you want to go to. Now, a major portion of a cyber security analyst job is looking at different URLs in a proxy log or other security logs to determine what websites have been visited and what type of data has been passed to those websites. Now, URLs have the ability to encode some action or some data, and that can then be submitted to the server during the request. When you conduct a URL analysis, this is basically just an activity that's performed to identify whether a link is already flagged on an existing reputation list and, if not, to identify what malicious script or activity might be coded within it. Now this is important because there's some encoding that can happen inside the URL, and so you need to use the right tools to be able to resolve that percent encoding that might be there, assess what sort of redirection the URL might be performing, and show the source code of any scripts that are called by the URL without executing them. You also want to do all of this in a sandbox environment, so you don't have your own machine. Now, let's take a look at a simple URL. And I say simple, but it's not really that simple. You can see how long it is here on the screen. It's deentrain.com: upload PHP, question mark, postequals, and then this long thing. Now, as we go through this lesson, we're going to come back to this URL quite a few times. But first, before we start analysing it, we really have to understand some basics of URL analysis. That way we can better understand this URL and see if it's really good or bad or if there's some kind of malicious thing going on. Now, there are three things we're going to talk about in this lesson. We're going to talk about HTTP methods, we're going to talk about HTTP response codes, and we're going to talk about percent encoding. First, what is an HTTP method? Well, this is a set of request methods that indicate the desired action to be performed for a given resource. Now, when I talk about a resource, essentially think of that as something on the server. could be a web page, an image, a file, or something like that. Now, a request is going to contain a method, a resource, a version number, the header, and the body of the request. We put all that information together when we send something out through a URL. So when you go to Deontrain.com, you are actually sending an HTTP method saying, "Please go to this website, get the page, and send it back to me with the body and the header." And that's what our server does. There are many different methods that we're going to talk about here. The first one is GET. A get is the principal method that is used when you do an HTTP request, and it's used to retrieve a resource. So again, when you go to deontrain.com, you are using a get command to say, "Get me that page; get me the index page of that website." The second one we have is a post. and this is what you saw in the URL I showed you earlier. A POST is used to send data to the server for processing by the requested resource. So in the example I had, it was the upload PHP file, and the action was post. So we were sending data to the upload PHP file, which is a script that would then be run on that server. Next we have the put method, which is going to create or replace the requested resource. So if I put a file on the server, I'm going to upload it there and overwrite what's existing. The next one we have is delete. This is used to remove the required resource. So if I wanted to delete a file, I could use the delete command. Then we have heads. Head is going to retrieve the headers for theresource only, and it's going to ignore the body. So if I send out the head command to the server, I'm only going to get the head portion of the HTML and not all the body. This is often used as a penetration tester when you're doing a banner grab because all you want to know is information about the server and about the page, like the title of the page. Now data can be submitted via a URL, and it's going to be deliberated by the question mark character you saw earlier. When I had my upload PHP, there was a question mark there that then said "post equals," and that was saying, "For this resource, I want to do this; the next thing I want to post." And that is the concept behind submitting data via URL using the question mark character. Now you also have query parameters, and query parameters are usually going to be formatted as one or more name-value pairs, and they're going to use an ampersand to delineate each pair. So if you think back to our Google hacking lesson, we used the ampersand to connect different value pairs together as we sent them to Google to do a specific search. Now the next thing we want to talk about is a hashtag. And a hashtag is used to indicate a fragment or an anchor ID, and it's not actually processed by your web server. If you've ever coded HTML, you'll know that you can use a hashtag to say this is a particular part of the page. For instance, if a page is longer than what can fit on the screen, maybe you have a very long book that's on one web page. I can actually have a hashtag to show where those anchor points are for each chapter. And then, when you clicked the link at the top of the page, it would take you directly to that portion of the page and jump down again. It's not processed by the server, but you should be on the lookout for these as part of your URL analysis, because sometimes people will misuse that hashtag and inject JavaScript into your page by using that as part of the URL. So let's look at the URL one more time. Here, you can see the post method being used like we talked about. This is going to indicate that we're sending data to the server for processing by the resource. In this case, the upload PHP script, which is sitting on deontraining.com, Also, you'll see there's that question mark there that is being used to indicate that data being submitted to that page is going to use the postcommand and its values after the equal sign. Now, all that stuff after the equal sign We're going to talk about that in a little bit, but we have some more stuff to cover first. Let's go ahead and talk about HTTP response codes. Now, when you deal with an HTTP response code, the header value is going to be returned by the server when the client requests a URL. And these different codes are numerical codes, usually three digits, that are going to tell you some information that the server wants you to know. For example, if you get a code 200, this indicates a successful get or post request, meaning you went and got the page and it came back to you successfully. If you get a response code of 201, this indicates that your PUT request has been successful in creating a resource. If you have a response code of 300 or anything in the 300 range, this is going to indicate a redirect has occurred by the server. For example, there's a 301 redirect that we use when we move a Web page from our site to a different site. So that way, we tell Google that we want all that information they know about that old page transferred to the new page. That's a 301 redirect. You don't need to know all the codes for the 300 series, but you should know that 300 and anything is going to mean that a redirect has occurred on your server. The next series we have is the 400 Series, and this indicates that you're going to have an error in the client request. And there are some specific ones here that you should know. The 400 itself is going to indicate that a request could not be parsed by the server. If you have a 401, this indicates the request did not supply the authentication credentials. If you have a 403, this indicates that the request did not have sufficient permissions to access that thing. If you have a 404, this is very common. It indicates that the client has requested a nonexistent resource. The next series we want to talk about is the 500 series, and a 500 series with any code in that area means that there is some kind of server-side issue. Everything up to this point was really the client not getting what they wanted. Now we have some server-side issues. A 500 is going to indicate a general error on the server side of the application. A 502 indicates a bad gateway, and you'll often see this when the server is acting as a proxy. A 503 is going to indicate there's an overloading of the server, and that's going to be causing service unavailability. and a 504 indicates that the gateway timeout has occurred. And this means there's some kind of issue with the upstream server. Now for the exam, you do not have to memorise all of these error codes, but you should be aware of them in your role as a cyber security analyst inside the real world because you're going to be dealing with these, especially if you're dealing with web applications and web application testing. Now let's go ahead and look at our URL one more time here. Now does knowing those codes help with identifying anything in this URL? Well, not really, but if we tried opening the URL in your Web browser, you would get one of these codes back. You would get a 404 error. Now what does that mean? It means the page doesn't exist. Why is that? Well, it's because the requested resource, which was the upload PHP, can't be found. Now why can't it be found? Well, because I made up this URL. We don't actually have a page on our website called Upload dot PHP on our server, but there's still a lot in this URL that we don't know. Everything after the equal sign we haven't even looked at yet. And that's going to bring us to the concept of percent encoding. Now percent encoding is a mechanism to encode eight-bit characters that have a specific meaning in the context of a URL. This is also known as URL encoding. Now a URL can contain unreserved and reserved characters from the ASCII set. Unreserved characters are things like letters and numbers, a through z, zero through nine. It's the dash, the period, the underscore, and the tilde. Now we have some reserved characters as well. These are special characters like the colon, the backslash, the question mark, the hashtag, the brackets, the at sign, exclamation, dollar sign, ampersand, single quote, parentheses, star plus comma, semicolon, and equals. All of these are reserved characters. You can use these inside of a URL. There's nothing wrong with using them, but they do have a special meaning. For instance, we've talked about the question mark already, we've talked about the ampersand, and we've talked about the equal sign. All of these are special characters or reserved characters that can be used inside your URL. Now a URL cannot contain any unsafe characters. Now what's an unsafe character? Well, these are things like null string, termination, carriage returns, line feed, end of line tab, space, and things like the forward slash, the less than sign, the greater than sign, and the curly brackets. All of these are characters that are considered unsafe and cannot be used in a URL. Now, percent encoding is going to allow a user agent to submit any safe or unsafe character, or any binary data for that matter, to the server within a URL. So if I want to send a space, I can do that if I encode it with one of these percent encodings. Now here's where I need to bring up the warning, warning, warning, warning. Percent encoding can be misused to obfuscate the nature of a URL. This allows them to encode unreserved characters and submit malicious input as a script or binary or some other method like that to perform directories, transversals, and other bad things. So when you see percent encoding, you probably should think to yourself, "There's probably something being hidden here." I need to look further into this as an analyst; whenever I see that or on the exam, anytime you see that, you need to have the hair on the back of your neck standing up and going. I need to look further into this; there's probably something here. Now let's take a look at percent encoding. And here on the screen you're going to see a chart; on the left you'll see the characters, and on the right you'll see the code. Now, I'm not going to read them all to you, but you do have them here on the screen, and you do have them in your notes in the PDF study guide. Now, the thing I want to point out here is that this is not a list of all of the present encodings. These are just some of the most common ones that you should know and be familiar with. There are many, many others. When you're an analyst in the real world, I do recommend that you print out a PDF that has the entire list of these because you will use them in your URL analysis for the exam. You do not need to memorise all of these, but you do need to know a couple of them, and we'll talk more about that later. Now, some really tricky attackers have started to do what's called double encoding, and they can double encode the URL by encoding that percent sign too. So when you're looking at the URL, you won't see something like "percent to zero," even though that thing will be percent encoded. Now for the exam, when you see a URL, if they want to talk about URL analysis and they want to talk about percent encoding, they will use the percent sign. They won't do the double encode, but I want you to be aware of that. Because in the real world, this is something you should be aware of. All right, one more time, let's go back to our URL. Again, we have our URL, deentraining.com uploadPHP questionmark, post equals, as previously discussed. This is the website we're going to, the file on that website, and the action we're going to do: we're going to post something. Now let's get into what we are going to post. So if we look at the URL again, we have percent three C, script, and percent three E. Now, in percent encoding, what is three C and three E? Well, if we go back to our chart, you would know that percent three C is the less than sign and percent three E is the greater than sign. So essentially, this is saying "postequals bracket script bracket" in HTML. Now, if you know anything about HTML, you know that the bracket script bracket means we're calling JavaScript. And so that is something that we needto think about of what script is beingcalled and that may be something bad. So let's go a little bit further into this. The next area we have is percent 27 of http, percent three A, percent two F, percent two FABC, one, two, three.com. two percent F rats and two percent E JS What does that all translate to? Well, 27 percent is a single quote mark. Percentage three is a colon. "2 percent" is a backslash, and we have that twice. And then 2 percent of E is a dot. So, if I were to read that without the percent encoding, it would be single quotehttp ABC 1, 2, 3, com rat JS. And so now you can see what this URL really is saying.It says to go to deentrain.com, access the file upload PHP, and post, which means to upload and send this script file, this website address, and a link to rat JS. So we're trying to send this file, this JavaScript file, to this site, and if it is vulnerable, we can then upload malicious code. That's how we do this URL analysis. And for the exam, you are going to be asked to do some URL analysis. Now let me give you an example tip for this area of the exam. When we talk about URL analysis, you don't need to necessarily remember the values for all those percentencodings, but you should know what they are. If you see percent encoding, it is some kind of aURL analysis question and you're probably going to be asked totry to figure out what they're hiding in there. Now they're not going to be very specific in asking you exactly what's going on, but using this, you should be able to see certain things. For example, are they trying to do an SQL inject? If so, they're probably using that single quote, and they're using an equal sign. If they're trying to do something like XML, you'll see some XML being passed. If they're trying to load a Java script, they're going to do something like what I just showed you here in the URL. These are the kind of things you have to do. Now, what do you do if you don't remember all those codes? Because that's a lot of percent encoding all those different codes for remembering percent three F and percent two E and so on. Well, on the exam, it's all multiple choice, right? And so when you get a question, you may not rememberwhat percent three C and percent three E were because thatwas the brackets for the script on either side. But you did see the word "script." And so if you see the word "script," you might think, "Hey, they might be trying to pass an HTML script or a JavaScript there." And as you saw the rest of it, you could readthings like ABC one, two three.com, which is a web link. And so you're seeing that you're going to deon training, but now you're sending another web link as part of this URL, and that should flag to you that there's something wrong here. So even if you don't remember all of the colons, the backslashes, and the dots, you can probably put together most of this based on what you're reading in that URL as you're doing your analysis for the exam. In the real world, though, I do recommend having one of these charts handy because then you can read exactly what it is and really put it back together.

8. Conduct Packet Analysis (OBJ 4.4)

Conduct packet analysis. In this lesson, I'm going to show you how to do some basic packet analysis using Wireshark. To do this, I'm going to launch a piece of malware on my system, and we're going to see how it spreads out over time. Now, to do this, I'm going to use two pieces of software. I'm going to use Proc Man to look at the processes and make sure the malware is actually launching. And then I'm really going to dig into the packet analysis using Wireshark so we can look at how those packets are going out and what IPS they are, so we can develop indicators of compromise. Let's go ahead and jump into the environment. And next, I want to open up Wireshark. So I'm going to click on the Windows icon, type in the word Wireshark, and open that program. Now, Wireshark is a great program. It's one that is used heavily in network analysis. And what we're going to use it for is to capture our network traffic when the malware launches. And that way we can see those beacons that happen every 3 minutes, see what data is being sent, or see who it's calling out to. And so I'm going to go ahead and hit the start button, which is this little shark fin, and it's going to start capturing data going into or out of our network. So now I'm going to go ahead and right-click on Trickster and run it as administrator, then go ahead and hit yes. So now Trickster is running; this should be copying U.exe into that directory and running it. And it did. And you can see that it's now showing up as a process. So I'm going to go ahead and move this over just a tad so we can see it. and we're going to go ahead and open up Wireshark a little bit better so we can see it a little more. Now, notice the time is different on Wireshark. They do it as a T plus whatever time is being used, whereas Process Man is doing it as the time of day. Now, if I want to correlate these two, I need to make them look the same. And so to do that, I'm going to go over here to Wireshark, and I'm going to change the way the time is displayed by going to view time display format and then choosing the time of day. This will allow us to correlate the two. So in the example here, we have the process starting at 143 and 29 seconds. So I'm going to go ahead and let this run just for a couple of minutes, and we're going to come back at 147. When I come back, we are going to see what traffic there is and if we can capture and see those three beacons and see if we can figure out what IP addresses they're calling out to from these processes. OK, we're going to go ahead and stop the capture here. So now that we've stopped the capture, let's go ahead and clear up this mess a little bit so we can see a little bit clearer what we're dealing with. Let's go ahead and first turn off our registry activity changes and our file system activity changes. This is going to leave us with just the network activity and just the processes. Now, the first process you can see here started at 143 29 and finished right here at 143 29. And the following one begins at 144, 28. So let's see if we can find these events. So as we start looking through this, we see at 143 that there was a Windows Update call out. Then we noticed this source returning to our machineover port 443, which is almost certainly connected to that. So we can skip that one. We'll go ahead and keep going a little bit further, and if we scroll down, we see that process number 144 is the next to start. So 144-2829 somewhere around there would be what we're looking for. And right here we see 144,29 that we had a standard query over DNS for an API, ipifi.org. This call out is going from our machine to the Google DNS server. Once it finds out what that IP address is, it starts making that call out from our computer over TCP/IP port 80 to this remote IP address. So we're going to note in our notes that this is a possible issue for us. This may be one of those IP addresses, and this IP Fi might be part of our malware. So we'll keep looking as we go down. So the next one we have, if we go down here on the right, is 145. It tries it again about a minute later. Now, in this 145 time frame, we're going to scroll down here and see what we can see at 145:28, which would be right around here. It again tries to make a connection, this time from 542-541-3664 to our machine. And from there, we see that it now makes this two-way connection with an acknowledgement and finishes up that handshake. So that is a communication issue between our machine and a remote server that we're going to want to look into. Now, if we do this, we can go follow the TCP stream and see what was said. In this case, there's not much to it—it's just to keep a live connection. There was a standard request to basically get a webpage and an IP address back. Now, the reason why this particular piece of malware is a piece of training malware, And so what we're seeing here is that it's going to this website and saying, "Hey, what's my IP address?" This local IP address is the local IP address that you're finding here from this machine during this session. So as you can see, we can see those callouts, and we can start making a list of the IP addresses it calls to.If I left this running for a long period of time, like ten, fifteen, or twenty minutes, you would see that it actually calls out over several different IP addresses as it tries to make its way to some command and control server. Because maybe we are blocking this one because we already knew it was bad, but it can then move to the next one. That's the idea here. And what we're trying to figure out is where these TCP connections are going, so we can develop these indicators of compromise and block them in our firewall. So even if we are infected with Stage One malware, it can't go and get Stage Two malware and start installing it.