I've been asked a lot by many of you guys to make this specific CompTIA security plus performance-based question and I did a lot of research that was 10 days ago. I thought I'm going to make a video in a day and oh boy was I wrong. A lot of different comments, a lot of different reviews about this question and almost all of them are incorrect. So I did a ton of digging, a ton of review, a ton of thought process asking here and there about this specific questions and what would be the right answer to it. So what I'm going to do is to present you the question, give you some time to think about it and then we will go and answer this question. So let's jump in. Now the question is this one. It is specifically asking you as a security administrator to look to look into possible network infection. Your task is to click through each host and firewall, examine their logs and figure out which host started or originated the infection. After that, you're going to have to determine if every other host is clean or infected. So, that is the question. Since it is a performancebased questions, uh I tried to simulate it a little bit, but my hands are tight. Now, here is what we have in term of our structure. We have a bunch of different PCs or host and there is a firewall. You can see their IP address like this guy 192 16811.22 and so on which is part of the research and development network. This is our firewall. And then we have our engineering network which has this IP address and this guy. So three to the top, two to the bottom, the network let's say A and network B and then firewall which has its own separate logs. So if I click on this guy, the log is going to show up and then you can read through the log, understand what's happening there. And I'll do it one by one. I'll start with this guy and then this guy, this guy, this guy, this guy, and eventually the firewall. Then I'll give you a couple of seconds. You can pause the video, go back and forth through the logs and understand what's what. Ultimately, you're going to have to decide which host is clean or infected and ultimately which one originated the infection. So, you're going to have to select in here, is this guy clean? You're going to check mark it. Is this guy clean? You're going to check mark it. And so on and so forth. So that would be the question. Now let's go through every single one of these logs. And I'm going to click on this guy. This is the log for 222. Give you a couple of seconds. Now let's go to the next one. this guy 11.37 and let's go to the 41. This is the log for 41. And let's go to the2. This is the log for2. And let's go to 18. This is the log for8 and ultimately the firewall. Let's go to the firewall logs. And there you go. So at this point, you have all the information that is necessary for you to decide which host is clean and infected and which one originated the infection. So go ahead, pause the video, go back and forth if you want, and then we'll jump into the answers. All right, so initially I thought it's going to be super easy and I'm just going to go through the logs, but there are a ton to consider. Ultimately, I did not even came into a 100% conclusion with 100% certainty that this would be the right answer. But I'm quite sure that most probably this is the right answer and this is what they wanted you to think and conclude. However, I'm going to have to give you this disclaimer that you need to develop your own thoughts as well with the discussion that we are going to have throughout the video. You may have more information and more data to decide. So, if you had other questions, if you had anything to ask, anything to add, write it down in the comments. All right. So going through the very first machine, we have the 222 machine in here and these are the logs and all of the logs in relation to the machines are within the same format. We have the time stamp in here in this section, the date with the time itself. We have the type of the message that we are getting. Is it info or is it warning or is it error etc. And then the message itself. So for instance the very first message says scheduled scan initiated and then it goes through checking for updates, no available updates. Checking for definition updates, no available updates. scanning full and going through system files, temporary files, services, etc., etc. Not finding anything. And next schedule scan is going to be on 18 and this hour. And this is important. So, we want to take a note of that that at 14:30 or 2:30 p.m. we are going to have our scan basically every day for every single machine. That's the timeline. Now, you can see that we have a warning here. So, a warning around 2:31, that's technically. on 18 says that scheduled scan disabled by process SV or SVC host this is a zero which makes it a little bit different than O.exe and then again uh at 232 another warning schedule update disabled by process svcchost.exe exe. And this is very very suspicious. And if an scan is disabled or update is disabled, you're going to have to be worried that your system is probably infected. So we we might want to write that down as our note. So I'm going to write it down in here. I'm going to say that this SVC host with zero in here um is activated at 2:31 a.m. on 18, right? All right, let's keep that note. And we don't have anything else in here. Let me put this back and go to the second machine. So in the second machine when I click on the logs oh before uh we do that I should also tell you that since we suspected that this machine is infected I'm going to mark that as infected as well. So this process was activated. The scan was disabled. We are highly suspecting that this machine is infected because of that. And thus we will choose this machine to be infected. And for the next one, we're going to look at the logs. The 37 log is a little bit more in comparison to the 22. And then we have some uh initiating scan. This is on 17 at 2:30 p.m. technically 14:30 and uh as I've mentioned earlier at 2:30 p.m. or 14:30 the scan is going to be initiated. You're going to get to know that when you go through every single log. You're going to see the pattern and then no update available etc etc scanning uh nothing found nothing removed blah blah and next scan is going to be next day so this was 17 next scan is going to be 18 at 2:30 p.m. and then this is 17 uh 2:45 p.m. And then the next message is 18 2:30 p.m. which is supposed to do the scan. It's going to go through the updates. No update available in here. Check for definition update. There is a definition update available. It's going to download it. It's going to do the updates uh to be completed. Scanning again. Checking file systems. Hey, we have found this SVC host to match this definition and thus we quarantine this specific process and then scanning temporary file services etc etc. Nothing found there. So ultimately we found one malicious uh software and we quarantined it. Boot sector is clean and next scan is going to be on the next day on the 19th same time 2:30 p.m. All right. So, let's make a uh log about this specific uh host. And we did not find something on 17, but we quarantined this malicious malware or software on 18 at this specific hour. You can see that all the way in here in this section. can see that we have quarantined the SVC host at 2:37 p.m. So we take a note of that and with that said this machine is killing cuz we found something right. So initially it was infected but it found the virus or malware whatever that was and now it's quarantined in an isolated environment and thus the machine is clean according to whatever information that we have currently. Now going to the next one to the 41. We can see that some stuff are happening in here as usual. But all the way in here we have the boot sector clean on 17. But the next day on 18 the scan is initiated. No update found. No definition update is available because we cannot reach the update server and it's a little bit suspicious that you cannot reach the update server. It doesn't say that no update available. So somehow maybe the IP address was blocked and then it's going to go through the file system. It says hey this guy uh matches the heristic pattern. However, even though it matches the heristic pattern, we are not able to quarantine this guy. There is an error for whatever reason. And thus, we don't have any file removed or quarantined. Even though it says boot sector clean, we know that there is something wrong with this guy. And uh when did this happen? At this specific time 1437. We are trying to see some pattern in here. For this guy at 1437, we quarantined the malware. But for 41 machine, we could not do that. So let's take a note of that. We couldn't find something initially on the day 17, but next day even though we found something, we couldn't quarantine it. So it's still there. Thus the machine is infected. Now let's go to the engineering network and let's take a look at this guy. If I click in here, I can see that the same log as the 37 all the way till here we have next schedule scan on the day 17 we didn't find anything but checking for definition update update available downloading and all the way in here match the definition quarantine the guy and one file was quarantined. So if we take a note of this guy on day 17 we did not find anything but on the day 18 we found the SVC host and quarantine it just like this guy. So the logs are actually identical now this means that the 12 is clean now. So, even though it was originally infected, but right now it's cleaned. Now, marking this one and going to the next to the last machine. If I click on this guy, it says that uh there are some scans all the way up to day 18. And on the day 18 when the scan is initiated the definition update we cannot reach the server just like this guy. This is also uh a little bit suspicious. We found this guy but unable to quarantine it. An error occurred and thus no file was either removed or quarantined. Next schedule scan uh is on the day 19. So exactly identical to 41. So 18 is identical to 41. And if I take a note, it's going to be exactly similar to this one if not identical. And uh on the day 17, nothing found. On the day 18, we found it, but we could not quarantine it. So SVC host is still there. Thus, this machine is infected. Now we answered everything right and I thought so I thought what else is left out there. However, probably the hard part is to understand which one was the origin, which one originated the infection. Now we have one more log to go which is the firewall log. And there are a ton of things that are happening there. So before I go there, I investigated 10 days to answer this question. And I would appreciate it if you put a like. It's not going to only help the channel but also it's going to help all other people who wants to take the exam and who wants to have some sort of database to understand how are the questions uh is are going to be in the PBQ format. So I would really appreciate it if you drop a like. It's not going to cost you anything. So let's go to the firewall logs. And in the firewall logs, you can see a lot of things that are happening. So I'll try to dissect it and make it simplified. Just like before, we have the time stamp in here. We have the source of IP address and the destination of the IP address. So these two source and destination, they are communicating. We have a port in which these two machines are communicating via. And then the application in relation to that port. We have the action of the firewall. Was that communication permitted or no? And the amount of bytes that were communicated. So client bytes we have 6,953 around 6 mgabyte. and this guy 99,000 etc around 99 megabytes. So the server bytes and the client bytes. Now this is obvious. We want to understand the type of IP address that we have. So two types of IP address is within our network. the 1010.10 something and then 92.68.11 something. So these are within our network. However, we also see another IP address which is external and we can see that it resembles nothing like our network 57.203.54 20354 something. And if you are a security administrator or if you have investigated logs before, you're going to understand that external IP addresses are suspicious if they are not from a trusted network, from something that you know. And in our case, this is the IP address that you see all around. So these two guys all the way down these guys you can see they are within the same format and this guy as well 57.203 and either 54 53 55 and it resembles this sort of uh command and control command and control center technically. So going through every single log is going to be too difficult and too lengthy for this video. We've already spent too much time I guess. However, let me point out the things that are important. The very first thing that is happening is here we have the IP address of our source 18 communicating with external IP address 57.203 23 over port 443 with application SSL that does not matter and trying to uh send some stuff in the range of 100 megabytes which is quite large. Now, we do not know anything about this one yet, but as we move forward through the logs, we do see other stuff as well, like the 37 communicating with that, and that's also suspicious, and sending about 200 megabytes of data, which is again a large amount. And then we have a bunch of other stuff like 222 uh communicating with 12 which is usually normal. It's going through RPC and not that uh much amount of uh data has been transferred and usually RPC is for understanding what services are at what end point. So it's a little bit difficult to understand when you try to communicate via RPC. You want to ask the machine as the other host which services are you serving at what port. So some sort of enumeration. Now this can be normal but it can be malicious as well. We do not know from this specific log in front of us. The next one 41.12 SMB version one which again is not a secure port or a secure communication channel the SMB version one maybe if you have other experience in pentesting or um network diagnosis you would see that SMB v1 is usually either disabled or you're going to have to harden it and if not using the other variation V2 or V3 probably V3 is the best one and it's uh trying to send some bytes here and there but then again from this specific log we do not know if something malicious is happening or not and then if you go over and over you see RPC again RPC again and then SMB version two again and then a series of pings understanding that hey uh the 12 says are you alive? Are you alive? Are you alive? It can be malicious or not. It can be a normal communication. We cannot tell just by looking at these logs. Maybe in some cases if this machine is infected it's trying to do an IP sweep understanding that hey what other hosts are available so that I can infiltrate that I can infect but we do not know so from these logs in front of us we cannot with 100% certainty say that these are malicious ious datas and communications that are happening. So we go all the way SMB uh v2 pinging SMB v2 all the way till here http over a port 8080 that's usually not secure and it's not even common. Usually you want to have an SSL or the latest variation um the port 443 for HTTPS and port 80 is used by default for HTTP. So this is too uncommon. And not only that one, the 222 is communicating with the malicious IP address that we are suspecting is our command and control. And this specifically happened at the time 23145. Right? So take a look at this guy 234 3145 and let's try to analyze it with the logs that we had from before. So this specific communication over an unsecure port sending about 75 or 76 mgabytes is going to be at 231 a.m. And we had already in here at 2:31 a.m. On the day 18, exactly same as this guy, the SVC host activated, right? It was cancelling the update, cancelling the scan. So, we're suspecting that maybe this guy. And if not this guy, we have again another similar thing. this one to 3102 communicating again over HTTP via port 443 to that malicious address. Now you might wonder HTTP 44 443 what was that? Most probably just like RPC that can be used for communicating via the remote desktop. So maybe the malicious actor tries to remotely connect to this machine by remote desktop softares and do some stuff and maybe that's the thing that happened in here. Still we do not know if this guy counts as the origin or not. And then if we go further more we can see that around some time all the way in here for our 18 machine uh the SVC host was still there on the day 18 and we can see a communication all the way in here via port 443 over SSL. doesn't matter if it's SSL and it's sending 200 megabytes again. And if we wanted to decide that hey this guy was the origin because this guy was uh activating the SVC host earlier than any other machines. Then we come to the question that what about this specific communication? So if8 communicated with this malicious address initially, it must have been infected already cuz clearly 22 has its first communication to this malicious address at this time or you can even say at this time. this guy and thus this would indicate that the communication happened after 18 meaning that it would give a more strong candidate for8 to be our originator. So going through rest of the log we do see other stuff in relation to 18 as well. For example, if I take a look at this 18 and try to show you some stuff, all the attacks that are happening. So, take a look at these guys all the way in here. Let me highlight them. These two guys, all of them, they happen to find and quarantine the virus after 1437 or let's say after 1436. Now this gives a rise to something. If this machine 37 has communication with this malicious IP address on the day 17 not 18 then again this must have been infected already. The machine 37 must have been infected. The machine 18 must have been infected. So these two guys are are an stronger candidate for the originator of this specific infection or malware. Now which one is it? Is it 18 or is it 37? I think if we take a look at other logs in here, we can see that the by the way I forgot to tell that. Hey, you can see that the 12 is also communicating with this guy and uh thus it must have been infected even though we see that even though we see that 3741.22 22. All of these guys were at some point infected and thus on the day 17 on the day 17 all the way up to this hour 2:30 p.m. they have been infected and controlled via the malicious actor. Yet we cannot decide which one was the originator. So doing further analysis we see that the 18 has a very huge amount of data transferred via port 8080 even though it is over SSL but it does not matter. This is around 9 gabyte. So not 200 megabyte or 100 megabyte 9 gigabyte of data being excfiltrated via this specific machine. And seeing that 18 was the first one who made the connection and seeing that 18 is using RPC seeing that 18 is using SMB v2 all of these gives uh an stronger indication that 18 was the originator. So about the attack, about the timing of the attack, I've mentioned that 230 p.m. on the day 18, right? Every single antivirus or let's say quarantining of this malicious software happened earlier. For example, in here you can see that on the day 18 At 2:37 p.m. the quarantine happened. So the whole attack in here was done already in the firewall logs. So we didn't get to see if this machine had other infections or not had had other communications or not after this hour. So, take a look at uh the 2:30 p.m. which is the last log within our firewall and take a look at the time that we found this malicious software and we quarantined it. So, this log is earlier than this guy. Thus, we do not know what happened afterwards. Is quarantining this specific malware enough or is it any other zero day vulnerabilities within the system, we certainly do not know based on what we have. All in all, you can see that every single thing that happened regarding our scan and regarding whether we quarantined the malware or whether we were not able to quarantine it happened after the hours after the firewall logs. So other communications if uh they happened or not we are not certain of it. If we were probably we could guess better or deduce better with a more certainty that yeah this host this machine was the originator or we're dealing with a zero day vulnerability and so on and so forth. So with all that said, I'm thinking that the originator was8 because this was the very first machine that communicated with the malicious IP address or let's say suspicious IP address. We had a large amount of bytes 9 GB xfiltrated 18 did RPC calls SMB calls and more and there is no other candidate or other stronger candidate that does all of these thus I think my decision would be 18 is the originator so based on the information or let's the limited information that we have in front of ourselves. I would think that these are the answers. At least we are 100% sure that 222 is infected. 37 was infected but then it got cleaned and 41 was infected 12 was infected but then it got cleaned and same goes for 18 infected. We are 100% sure about that. But we are not 100% sure about origin. The data the firewall logs points towards8 strongly but we could be wrong. I do not know what the compia wants but the strong indication is there. So the decision in relation to the origin is upon you. However, I've explained my thoughts and if you have other questions, other things to add, write down in the comments and uh I wish you the best. So, thank you so much for watching. Subscribe to the channel. I have other questions as well. If you want to review them, you can see them in the card or in the uh description section. and subscribe to the channel because I'll be posting much more. And catch you on the next one. Thank you.