All CompTIA CySA+ CS0-002 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the CS0-002 CompTIA CySA+ Certification Exam (CS0-002) practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Endpoint Monitoring

3. Sandboxing (OBJ 3.2)

Sandboxing signature-based tools are becoming less and less effective in their ability to automatically block malware execution as malware creators get more advanced in their techniques to disguise their malicious intent. Now, to compete with this malware, analysts need to keep improving their techniques and their ability to conduct manual analysis of the malware. To do this, they have to run malware in a controlled environment to observe its effects. But they don't want to infect their own networks and systems. To do this, they use a technique called "sandboxing." Now, sandboxing is a computing environment that's isolated from the host system to guarantee that the environment runs in a controlled, secure fashion and that the communication links between the sandbox and the host are usually completely prohibited. Now, most often, you'll see a sandbox environment created by using a virtual machine, or VirtualBox.

This allows us to install whatever operating system we want, set up the parameters we need, take a snapshot, and then we can load malware inside of it and find out a couple of things about it. For example, if we run a malicious file inside a sandbox, we can determine if that file really is malicious. Also, we can determine any effects it's going to have on the system. And finally, we can identify any dependencies with files and the hosts that may exist when you run that piece of malware. By using sandboxing, it allows you to quickly test malware in multiple different environments across multiple different operating systems without affecting your underlying host. Now, to effectively analyse malware, we're going to use a sandbox, and we're going to use a lot of different features of that sandbox. For example, we can monitor any system changes without any direct user intervention. So if I run the file and all of a sudden some changes happen to the system, I can identify that within the sandbox. Also, I can execute files that are known to contain malware. And if they are known malware, I'm going to be able to monitor for any changes to processes that happen on that system, and I can use that as a way to develop my signatures.

Additionally, I can monitor network sockets for attempted connections, and that way I can identify any known bad IPS or any command and control nodes that might be getting called out to by using DNS. After that, I can also monitor for system calls. And this way, I can also see if there are any APIs that are going on that are being called out by this malicious program. Also, we can use the snapshot feature inside our sandbox. And this allows us to take a periodic snapshot of the environment before we run a program, and then we can run the programme and roll back to that previous snapshot. Another thing that allows us to do is to record any file creations or deletions that may happen when we run that piece of malware. And finally, it's going to allow us to dump the virtual machine's memory from that sandbox. We can do this at key points in time. So sometimes when we're dealing with a piece of malware, it may be packed or compressed, and it won't be unencrypted or decompressed until we run it.

And so by running it inside a sandbox, we can dump that virtual memory and capture the malware that way. Now, one of the big keys you have when you're dealing with a sandbox is that your sandbox host, which is a virtual machine, should not be used for any other purpose except for your malware analysis. This keeps your sandbox clean, and once infected, it keeps that infection from spreading elsewhere. Now, there are a lot of different tools we can use when we're sandboxing. One of my favourites is called Flare VM, as provided by FireEye. This is a free programme that you can install on top of a Windows 10 machine, and this will then allow you to run Windows binaries and see what the status is. I like to run all this inside of VMware or VirtualBox, and that way I have a nice sandbox environment to do my malware analysis. Another great tool that's out there is called Cuckoo.

And Cuckoo sandbox is a programme that will allow you to automatically run a bunch of different malware samples in it and be able to see what it does inside of a Linux environment, a Windows environment, or even a Mac environment. Cuckoo does a really great job of providing you with a lot of automation tools so you don't have to do as much manual analysis as you're going through and doing your malware analysis. Now, because the CompTIA exam is considered vendor-neutral, they're not going to ask you about these two specific tools. I'm just mentioning them because they are great tools if you want to get into the world of malware analysis. Now, if you want to do a complex analysis, you may need to create a honeypot lab. And this will have multiple sandbox machines and Internet access so you can actually study the malware and its C-level structure as it starts communicating with lots of other things. Again, this is beyond the scope of the cys exam, but it is something that, in the real world, if you're working as a malware analyst, you may set up and use.

4. Reverse Engineering (OBJ 3.1)

Reverse engineering. What is reverse engineering? Well, reverse engineering is the process of analysing the structure of hardware or software to reveal more about its functions. And in this lesson, we're going to focus on that software part, specifically when we're talking about malware. Now, when I was talking about malware in the last lesson, we were talking about dynamic analysis. where we would turn on a sandbox, install the malware, let something happen, and then observe those effects. Well, another way to do this is by doing a static analysis by reverse engineering something.

Now, a malware reverse engineer can determine who actually wrote the code by starting to learn their patterns. Most people who code have their own style, their own way of writing. If you've ever read somebody's handwriting, you can look at it and over time start learning whose handwriting belongs to which person. Well, coders are much the same. And as you start reading enough of somebody's code, you can start seeing exactly their processes, and you can start identifying this piece of malware with this particular person. And that's one of the benefits of getting a really strong reverse malware analysis. And that's one of the benefits of having a strong malware reverse engineer working on your team if you're doing a lot of incident response or working for a threat intelligence gathering agency.

Now, as you're reverse engineering malware, some malware is easier to reverse engineer than others. For example, if you're using something like Java, this can be easily decompiled back into the source code that looks like this. Once you have the source code, you can then understand what's being done inside the malware and figure out better ways to block it and prevent it from doing any damage to your systems. Now, unfortunately, not all malware is easy to read and dissect like this Java code. A lot of malware writers will actually obfuscate their code before it's assembled or compiled to prevent analysis by a reverse engineer. This makes it convoluted and very nonstraightforward in the way that somebody could read it. And this makes your job much harder if you're a reverse engineer. Now, there's a couple of tools that will help us with that though. For example, the first one is what we talked about in the last lesson, which was sandboxing. Whatever difficulty you may have when you're reverse engineering malware, if you're doing it in a sandbox environment, it's going to have no impact on your production systems. This is especially necessary for malware when you're trying to detect what is being done as it's being deconstructed or running something in a more dynamic method. Now, when you start doing things statically, you have to actually get to the code.

And we use a couple of tools to do this. The first one is known as a disassembler. Now, a disassembler is a computer programme that translates that machine language into assembly language. Now, machine code, when we talk about machine language, is simply the binary code that's executed by your processor. Typically, it's represented by two hex digits for each byte, and each byte is eight ones and zeros. Now what does this look like? Well, here on the screen, you can see the memory view, and I have that six-letter code highlighted in blue. That is the first byte that we're looking at at that particular memory location.

That is a two-digit hex code that translates to a series of ones and zeros, and that tells the computer what it should be doing based on that instruction code. Now, as a human, though, that doesn't mean much to me. Those codes are very difficult to read. And if I have a whole screen filled with those types of hex digits, it would be very hard to figure out exactly what that programme is doing. Now there are a couple of hex codes that are important for you to know, and these are known as file signatures or magic numbers. Now a magic number is the first two bytes of a binary header, and it indicates the file type. This is basically going to tell you what type of file it is. So when I look at a file, like an image file, and I see PNG at the end, that tells me it's a graphics file. But an attacker doesn't have to put PNG at the end. They can change that to Exe or something else, and you really won't know what type of file it is.

If you look at the first two bites of that file, though, it will always tell you what that file is. And that's what we're talking about, this magic number. If you want to look this up, you can go to filesignatures.net, where there's a whole database for all of them. So look at the first two to four hex digits inside the file. Look it up at file signatures.net, and you'll know exactly what it is because even if I change the extension to PNG but it's an executable, it's going to have the correct file signature on it. For instance, when you're reading the first two bytes of a Windows Portable Executable file, whether it's an Exe, a DLL, an S-Y-S-A DRV, or a.com file, they're always going to start with the hex digits that say this is a Windows Portable Executable file. So even if I renamed that file and put.jpg at the end or.doc at the end, it would still execute because of that. It knows that that is a Windows portable executable file. Attackers use this against you all the time. So this is one of those that you should know for the real world. Now if you translate that into ASCII, that's MZ, and if you translate this into base 64 encoding, it's TV.

So anytime you see any of those three codes, that tells you this is an executable file. Now the next step up from machine code is going to be assembly code, where machine code is written in ones and zeros, or hex digits. Assembly code is written in something that's more human-readable. Now this is the native processor instruction set that's used to implement a program. In the old days, we used to actually write programmes inside assembly, but nowadays that is also a little bit hard to do. So if we look here at the next screen, you can see up at the top that I've highlighted the first two lines of that hexadecimal machine code. Now if you see a highlighted section at the bottom of the disassembly section, this is the same hex code from the top. Again, not very easy for us to read. But if I look over to the right side, you will see the assembly code. Now this is more human-readable. You can read this. I see things moving, which tells me I'm probably moving stuff from one register of the memory to another. I have push, which says I'm putting something into memory. I'm calling, and I'm pulling things from memory.

These aren't necessarily the easiest things to read, but it is still something that a human can do. And back in the day, a lot of our computer programmes were written straight in assembly. Now, to get to assembly, we use a decompiler. And a decompiler is software that translates a binary or low-level machine language into a higher-level language. So if I take the binary and move it to assembly, a decompiler can do that or a disassembler can do that. Now that I have that, I can put it through a decompiler and get it to a higher level of code. Now, when I talk about a higher-level code, what is that really? Well, high-level code is real or pseudocode in human-readable form. That makes it easier to identify functions, variables, programming logic, and other things like that that are used in the code. Now when I talk about a higher level of code, I'm talking about things like C, Basic, Java, or something like that.

Those are all languages that, if I gave you some script from them, you could probably figure out what's going on just by reading it because it reads similar to English, not like assembly language, and definitely not like machine language. Now let's take a look here on the screen. On the screen, I have a programme called IDA Pro, which is a famous decompiler. It takes the ones and zeros of the binary and hex values and translates them into assembly language by doing a disassembly function, and then it can take that disassembly function and run it through a decompiler to come up with a pseudo code.Now, this code is not what the original programmer wrote, but this is an equivalent programme that would do the functions of what that person wrote. And so this will allow us to go through it as we're doing our reverse engineering and understand it a little bit more than using something like assembly.

Now, some languages like Java have their own decompilers, and they can take it from the ones and zeros all the way back up to something that looks like real Java, as you can see here on the screen. This is an example of a Java decompiler. And we've taken this binary class file, gone through it, and brought it back into the text where it's very easy for you and me to read it. Now, why do we care about getting all this stuff back into a human-readable form?

Well, there are a couple of reasons. One is that we can figure out what logic is being used inside this malware and what functions it's performing. And another is to identify strings because, as a reverse engineer, we want to attempt to identify malware by finding strings to use for signature-based rule detection. Now, by doing that, we can identify these different strings from the code. We can put that into our rules, and then we can flag it and alert on it when malware tries to attack us. Now, when I talk about a string, a string is simply any sequence of encoded characters that appears within the executable file. These strings can be lots of different things. You can find things like ASCII sequences that contain usernames or passwords, file names or function calls, or even things like a URL.

For instance, if a piece of malware contains a string with a function called "Internet Open URL" and another string that says "URL," you probably can guess that it's trying to attempt to download something from that web address as part of the malware. Maybe this is a dropper, and it's going to download some second-stage malware by going to this URL. Now, there's a tool that you can use to dump these strings very easily without having to go through all the reverse engineering. It's called strings. And the strings tool will dump all the strings that are over three characters in ASCII or Unicode encoding to a text file or to your screen. So you can then look at it and analyse it yourself. Now, the one problem when you're using strings is that it will find anything that is over three characters, which means it can find a lot of garbage too. When I run this, when I'm doing malware analysis—and I'm going to show you a demonstration of this later in the course—you will see that a lot of the stuff that it outputs is stuff that just looks like gobbledygook. It's something you can't even see, but you'll also find some valuable things in there too. And so that's why we still run strings against malware samples.

Now, the next tool we want to talk about in our reverse engineering of malware is programme packers. Now, malware can use a programme packer, which is a method of compression in which the executable is mostly compressed, and the part that isn't compressed basically just contains code to decompress the executable. Essentially, a packed programme is a type of self-extracting archive. Now, there are a couple of reasons why malware writers use these Pac programs. One is that it makes the file size a lot smaller, so it's easier to transmit this malware. And the second is that it makes it harder for us reverse engineers to see the file's contents because we have to unpack it first before we can see it. This is another way that they do this to obfuscate things. Now, some people think, "Well, anything that's packed must be bad, right?" So I'm just going to block it all. Well, not necessarily. A lot of organisations that share proprietary software will use programme packing to deter theft of intellectual property, copyright violations, and piracy.

So you can't just block every programme that's packed because that doesn't necessarily mean it's malicious, but a lot of them are. So you have to think about this as you're going through and developing your signatures, and you can't just automatically assume a Pac programme equals malware. This would lead to a lot of false positives, and it could have a lot of bad effects inside your operations if you blocked everything that was packed. So what do you do if you have a piece of malware? Well, first you're going to unpack it before you can analyse it because until it is unpacked, packed malware can mask literal strings and effectively modify its signatures to avoid triggering signature-based scanners. And this is why you're going to have to use this as one of your steps. So you'll unpack the malware and then perform your analysis on it. In fact, when I do malware analysis, we actually do the analysis on the packed programme first, and then we do it again once we unpack the programme because sometimes we can find different strings in there and use those to build our signature. The rules.

5. Malware Exploitation (OBJ 3.1)

Malware exploitation. In this lesson, we're going to talk about malware exploitation techniques, so we have to first define what an exploit technique is. Well, an "exploit technique" describes a specific method by which malware code infects a targeted host. Now there are lots of different ways that this can be be done. In the old days, we used to have malware that would go and rewrite or modify the code within an executable or a macrophile on a target disk. That way, whenever that file was run, the virus was loaded and could execute its payload and go out and do bad things. Now if you had worm malware, it would actually go out and try to infect only the memory and then go through a process of going through remote procedure calls over the network, trying to infect as many other hosts as it could. Now, modern malware, on the other hand, uses file-stealing techniques to avoid detection by signature-based security systems like antivirus and host-based intrusion detection systems.

By being file-listed, this means that the malware is executed directly as a script or a small piece of shellcode that creates a process in the system memory without having to use the local file system. Now some of these things will actually get installed to a temporary directory first and then be run, and then they'll delete themselves, but we'll still consider those relatively small files because there's not a lot of evidence on the drive for people to find them. Now this is one of the things that a lot of Apt will use, and so we have to ask the question, "How does an Apt use this modern malware to operate?" Well, first, it's going to use a dropper or a downloader. The first step is that the malware has to get onto your computer, and it's going to do that in a file-less manner.

The way they're going to do This is done by running lightweight shell code on your system. By doing this, this becomes what we call a "dropper," or stage one dropper, and it's then going to go out and download the rest of the code, so that dropper is just a very small file and can run very easily from memory. Now the whole point here is to try to trick the user into clicking on something or running the code, and that way they are infecting their own machine. At that point, the Apt then tries to maintain access. The malware is now on the system, and it's going to install that second-stage downloader. That downloader can download something like a remote access Trojan, and this will give the adversary two over that victim machine. After that, they're going to start strengthening their access, and to do that, they're going to use that remote access tool they have from the maintaining access phase, and they're going to start looking around and identifying and infecting other systems. As they're doing this, they're trying to find systems of higher value, like servers or domain controllers.

But even if not, they want to compromise other workstations too and do this lateral movement so they can gain additional privileges and an additional footprint. So if you find them on one machine, hopefully you won't find them on the other machine, and they get to stay there. After this, they move into step four, which is "Actions on Objectives." Now with Actions on Objectives, the attacker now has enough permissions and they've identified enough things that are of interest that they can start doing what they want to do, which is usually going to be copying or stealing files, encrypting files, or doing something else, whatever their motive was. And then finally, we have our fifth step, which is concealment. The attacker at this point is going to maintain their tool access, but they might just go ahead and start hiding themselves, and they're going to start covering their tracks by deleting log files and things like that.

They want to make sure they're eradicating any sign that they weren't there and that they infected your system because this way they can stay there longer if they need to and they can always go back in later on if they need to get something else from the machine. Alright, so those are the basic five steps of an attack. And I mentioned a couple of terms that I think we need to go back and define a little bit more deeply. I talked about things like droppers and downloaders, shellcodes, and lots of other things. So let's take a look at those. First, we have a dropper. Now a "dropper" is a specialised type of malware that's designed to install or run other types of malware embedded in a payload on an infected host. Usually, this will be stage one. Dropper is that code you first got, and once you get that code and run it, it's then going to go out and get some other code, and it uses a downloader to do that. Now, a downloader is a piece of code that connects to the Internet to retrieve additional tools after the initial infection happens by way of a dropper.

So often we'll call this stage one for the dropper and stage two for the downloader. Now, in my explanation of that process, I also mentioned the word shellcode. Now shellcode is any lightweight code that's designed to run an exploit on a target. This can include any type of code format, from scripting languages all the way down to a compiled binary. Now for the exam, I want you to remember, especially if you have some experience in the field, that shellcode originally referred to malware code that would give the attacker a shell or a command prompt on the target system. If you take the Pen Test Plus exam, that's how they're going to use that term. But here in CYSA for this exam, they want you to use the definition of the more generic shellcode that I just provided, which is any lightweight code designed to run an exploit on a target. It doesn't have to give you a command prompt. It just has to be something that's going to give you some kind of exploit that's going to be run. Now, once the shellcode is created as a process on the target system, all this bad stuff has to start happening to your system, right? How does that happen?

One way is through code injection. Code injection is an exploit technique that runs malicious code with the identification number of a legitimate process. So when I go to install this code and we're going to talk more about process exploration and how we can identify this type of behaviour later on, you're going to notice that every process has a unique ID number associated with it. And so if I have something that is allowed to run, like the Explorer for Windows, and I decide to run malware and make you think I'm running it as the Explorer for Windows, I can hide that malware by injecting the code into that. That's the idea of code injection. Now, there are a lot of other techniques we can use as far as different types of code injection. This includes things like masquerading, where your dropper is going to replace a genuine executable with a malicious one. You can use DLL injection, where the dropper starts forcing a process to load as part of the DLL. So it's going to load the DLL and the executable malicious code.

You also can do DLL side loading. This is where the dropper is going to exploit a vulnerability in a legitimate progress manifest to load a malicious DLL at runtime and essentially use sideloading by making it load this malicious thing. Or we can do the process of hollowing. This is when a dropper starts a process in a suspended state and then rewrites the memory locations containing the process code with the malware code. So essentially, we're taking over someplace in memory and putting our malicious code there. Now, droppers are likely to implement a lot of these different techniques. In addition to that, they also use some antiforensic techniques to help prevent detection and analysis.When we talk about anti-forensic techniques, these are things like encrypting their payloads, compressing their payloads, or obscuring their payloads. Now when they do this, it makes our job as reverse engineers a lot harder.

But we still find ways to find these people. And so one of the things that a lot of peasants and a lot of attackers are starting to do is a concept called "living off the land." Because when they live off the land, it's really hard for us to find them. When I talk about "living off the land," this is an exploit technique that uses standard system tools and packages to perform their intrusions. For instance, they might use something like this, which is PowerShell. PowerShell can be used to do all sorts of malicious activities. And so what we can do is, when we break into a system as a pentacle or as an attacker, we can actually use your own Power Shell against you.

If I'm on a Linux system, I can't use PowerShell, but I can use Bash scripting. And so again, if I use the tools that are native to your operating system, I am now using tools that were already installed for your administrators, and I'm using them in a malicious way. But it's going to be really hard for you to detect that because I'm living off the land. So if you fall victim to an attacker who is used to living off the land, the detection of that adversary is going to be much more difficult because they're executing malware code within those standard tools and processes, which makes it really hard to detect and is going to allow them to stay on your system a lot longer.

6. Behavior Analysis (OBJ 3.1)

Behavioral analysis. Now, in the last lesson, we talked about shellcode. And shellcode is really easy to hide and obfuscate because you can do a lot of things with it to evade signature-based antivirus detection if you're an attacker. Because of this, threat hunting and security monitoring must use behavioral-based techniques to really identify infections. Now, to do this, we're going to use a lot of different tools. And one of the most common ones we're going to use is a tool suite called Sysinternals. Sysinternals is a suite of tools designed to assist in troubleshooting issues with Windows. It was originally made for system administrators, but a lot of these tools are well suited to investigating security issues as well.

These tools are all available for free on Microsoft's website and are part of their tool suite. Now, the great thing about these tools is that they allow us to start building up a baseline to identify what normal is. One of the first areas we want to do this in is what's called "process analysis," where we want to start figuring out what processes are running on a Windows system. Now we can use a tool called Process Explorer to do this. And this is part of the Sysinternal tool site. Process Explorer can filter out legitimate activity—what we know to be good. And that way we can identify very quickly what is anomalous behavior. The way this works is essentially that we can run the system and see what normal looks like, and we can save inside a Process Explorer all those running processes. Then we can run some malware in a sandbox, and we can run that process tool again. And now we can compare what we had as our baseline with what is running now. and that can help us identify what the malware is doing. That's how you can do it inside a sandbox to identify malware patterns. But if you already have a good baseline for a system that's a production system, like your workstation on your desk, and then we think you're infected, we can run this tool again and compare it to that known good baseline to see if there are any changes.

And if there are, that could be a suspicious area that we want to investigate further. This is really great when you're doing threat hunting and incident response. The big concept here when we're doing this is to first understand what legitimate processes are so that way you can identify anything else and those would be suspicious. So to help you with that, let's go through and talk about a couple of processes on an atypical window system and what is considered legitimate. Anything outside of these would be something you should label as suspicious and look into further. The first two I want to talk about are system idle, which is PID zero, and system, which is PID four. Now, these two are always going to have a PIDS, which is the process identification number. These are kernel-level binaries that are used as the parent of the first user mode process, which is called Session Manager Subsystem, or SMS Exe. If you go into your Process Explorer or look at the Processes tab inside of Windows, you're going to see these two processes are always there. Next, we have the client server runtime subsystem, which is CSRSS Execute. This manages low-level Windows functions, and it's normal to see several of these running.

Now, as long as these are run from the system root system 32 and have no parent, they are legitimate. If you start seeing them and they have some kind of parent, it means it may be malware that's trying to masquerade as this process. The next one we have is Win in International. Now Win in IE is going to manage drivers and services and should only have a single instance running as a process. When you look at Process Explorer, if you see more than that, again, it could be masquerading as malware. The next one we have is Services.exe, and this is what I see a lot of malware trying to masquerade as. So this is what you want to look closely at. Service Exe is going to host non-boot drivers and background services for you, and this process should only have one instance of Service Exe running, and it should be a child of Win and End. Now, there are other service processes that you should see. Those will be children of Services dot Exe or Service host Exe. If it's a child anywhere else, it probably is something that is malicious, and you should look into it further. Now another thing about services is that any time you look at them, they should be started by the system's local or network service accounts. If it was started by somebody who has an unusual name, that is usually a malicious process. So you should flag it and look into it further.

Next, we have the local security authority subsystem, or LSAs exe. This is going to handle authentication and authorization services for the system, and it should have a single instance running as a child of Winin Exe.If you see it elsewhere, that might be suspicious. Next, we have Winlogon, which is Winlogin exe.This is going to manage access to the user's desktop, and it should only have one instance of each user session with the desktop window manager, the DWM Exe, as its child process in most of the modern versions of Windows. Another one that's very common to see is User Init.User-initiated Exe sets up the shell, typically your Explorer Exe file, and then it quits. So you should only see this briefly during your log-on process. If the computer has been logged on for, say, 30 or 40 minutes and you go look and you see Username Exethat would be something you should flag as suspicious. And finally, we have Explorer. Explorer. Exe. This is the typical user shell, and it's launched with the user's account privileges rather than the system's.

And it's likely going to be the parent for all of the processes that are started by the logged-on user. So when I go into Windows and I launch the computer, I'm starting up Explorer.exe, and that's my desktop. Then if I open up Microsoft Word, Word should be a child of Explorer.exe because I'm the logged-on user and I launched Word; anything other than that would be suspicious, and you should flag it and look at it. Now, I've mentioned a couple of times that you should flag something and say, "This is suspicious," and you should look into it further. What else might make a process look suspicious to you? Well, for me, any process name that I don't recognise is something that would be suspicious, and when I say something is suspicious, it means I should look into it further. That's all. It doesn't mean it's necessarily bad, but it's just something I don't know, and so I need to learn a little bit more about it. So if I see an unrecognised name, what I should do is start looking online to see if it's a known process, and usually I'm going to use Microsoft's website to do that since they are the official source. Second, any process name that's similar to a legitimate system process—if I see something like SCV host, that's very similar to SVC host, and so that looks like something that somebody is trying to trick me with.

So I'm going to look into that further. If I see something that has a scrambled name or something that looks like it was randomly generated, that would also be something that would be suspicious to me. Another thing I'd be looking at is any process that appears without an icon, version number, information, a description, or a company name. All of these are things that are just suspicious to me, which either means it's poor coding or it might be malicious. After that, I might look at any processes that are unsigned, especially if they're from a well-known company like Microsoft. Microsoft signs all of their stuff. So if you find something that says "Microsoft Corporation" and it's unsigned, it's most likely malicious or at least suspicious. The fifth thing I like to look at is any process whose digital signature doesn't match the identified publisher. Now, what this means is that sometimes somebody might have stolen somebody's digital key, and if they stole the developer's private key, they could then issue their own stuff and pretend to be that company. But if the company field and the digital signature aren't matching, that is usually an indication that this is a piece of malware or at least something very suspicious.

The 6th thing I want to look at is any process that doesn't have a parent-child relationship with a principal Windows process. Now, when I talk about a principle Windows process, what is that? Well, that's something like explorer exe.Remember, I said Explorer.exe should be launching pretty much all the processes for a logged-in user. And so if I'm not seeing that and I see those processes somewhere else that might be something that's suspicious, I'd look into them further. The second thing I like to look at, and this is obviously much further down my list, is any process hosted by Windows utilities like Explorer. Now, Explorer should have some things underneath it, but I like to look at all those and make sure they're ones that I know what they are and that I trust them. But I also want to look at things like Notepad and Task Manager because a lot of times malware will embed itself under those and try to have those things launch it as malware.

And so if I see something like Notepad calling some other executable, that's usually a little funny because Notepad doesn't usually run other executables; it runs text files, right? And so that would be something that would be suspicious, and we'd look into it further. The 8th thing is any process that is packed or compressed because, again, as I talked about earlier, yes, there are legitimate uses for packed files, but in general, that is something that is heavily used by malware. So it doesn't necessarily mean right away that it is malicious, but it is something I want to look further into. If you're using Process Explorer, anything that's highlighted purple is considered a packed or compressed file, and that should draw your attention to it pretty quickly and analyse that as potential malware. Now, what do you do when you find one of these suspicious processes? I just gave you eight different ways to identify things that may be suspicious.

What do you do with them now? Well, the first thing you are going to do is identify how the process interacts with the registry and the file system now that this file or process has been launched. What is it doing? Is it making changes to your registry? Is it putting additional files on the system? And if so, are those things allowed? This is something that malware likes to do. When you run malware, it tries to embed itself further, and it does that by going into the registry or the file system. The second thing is you have to ask yourself, "How is this process being launched?" Who started this process? Did the user do it? Did some service do it? Did some kind of scheduled task do it? And once you figure that out, that will help you eliminate it if it's something malicious and you need to turn it off. The third thing is, is that image file located in the system folder or a temporary folder? A lot of times, when you get malware, it's coming from and being launched from a temp folder, not from the system folder. So if a process is being launched from a system folder, It's probably a little bit more trustworthy than if it's coming from a temporary folder.

So it's another area I look at. And then, four, what files are being manipulated by the process? Again, when you launch this file, what is it touching? Is it reading files? Is it changing files? All that stuff is information you want to gather about this process so you can determine what it's doing and if it's malicious or not. The fifth thing you want to do is figure out if the process restores itself after a reboot if you deleted it. If I went in and deleted this process and then rebooted my computer and it came right back, that's an indication that there's something malicious or suspicious going on. And the 6th thing I want to look at is: is a system privilege or service getting blocked if I delete the process? Now, sometimes if you have shimmed something into it or injected that code into some kind of system DLL, that can cause problems if you delete it. And again, malicious people want to make sure their software stays intact.

And so if you take something out and delete that process, does that break your system? Does it cause privilege issues? If so, that's another thing that adds to your toolkit as you start looking at and investigating this piece of software. And then the 7th and final one is: is the process interacting with the network? This is a big one because we want to see if there's any communication going in and out because, again, malware likes to communicate with its owner. It goes out into a C2 network. We need to figure out what the domain is or what the IP is. So then we can potentially block that.

Now, in this lesson, I focused a lot on manual analysis, but a lot of these UEFA products that we talked about earlier can automate this process for you and make it much easier. Now, a lot of these UEFA programmes are relying on the capabilities of artificial intelligence and machine learning to help you orchestrate and automate a lot of this work for you. But it is still important for you, as well as anyone else, to know how to do this manually so you can identify these things on your own and know what you're looking at. We don't always want to be relying on the machines, even though the machines are there to help.

CompTIA CySA+ CS0-002 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass CS0-002 CompTIA CySA+ Certification Exam (CS0-002) certification exam dumps & practice test questions and answers are to help students.