here we go this is the second part of the wire shark Series in the first video we covered the complete tutorial on how to use wire shark we covered the basics and we covered the uh packet navigation and dissection today we're going to uh analyze traffic with wiar so let's discuss what do we have today on the agenda first thing we're going to see how we can analiz traffic and detect in map scans so there we go we have a typo here we're going to correct this so n map scans and we're going to take a look at how to analyze ARP packets meaning we want to take a look at how attackers can um perform art poisoning and man in the middle attack how can we detect this using wire shark so art poisoning Plus mitm they are closely connected actually are poisoning ANM you need to in order to conduct man the M attack you need as a precursor you need to perform R poisoning so they are like R poisoning and then you have mitm and third on the agenda we're going to analyze the hcp net bios and we're going to analyze cus we're going to take a at the examples of these packets how do they look at a in a packet capture file additionally we're going to take a look at DNS and icmp packets and of course we going to learn how to extract clear text credentials from FTP and HTTP and lastly we're going to take a look at how to decrypt http s packets I have never found something better than this room to demonstrate the concepts we have discussed earlier so we're going to go over the tasks we're going to answer the questions and hopefully guys we'll be able to explain the idea so first thing let's jump over to D shark and from here we need to start answering the questions so the first thing we're going to take a look at the questions in task two where it is around in map scans let's scroll down okay so while we answer the questions I'm going to explain the concepts of every single filter we use in wire shark so the first thing is what open the capture file exercise at the in map directory so we're going to go to file open uh go to computer so from here we should highlight where it is it is the desktop so you want to desktop exercise okay in map and exercise okay so that's what we have now this is a packet capture file that represents in map or captured in map traffic meaning there was a machine at point in time where someone was scanning this machine with n map so uh they captured the uh traffic and and G gave it to you so that you analyze the packet capture and find out the nature of the in map scans performed Against the Machine the first question is what is the total number of the TCB connect scans so as you know guys nmap has Vari types of scans we can perform connect scan steal scan udb scan TCP scan right in this question we need to find out the total number of TCB connected scans meaning we want to find out if the Zer has performed in map uh TCP connect scans so to find out we need to rely on what is called the TCP flags as you know guys in inmap we have TCP 3-way handshake where the client sends a synchronization packet as seen here in the examples from packet 1 to five we have synchronization uh packets and then we have reset acknowledgement right so the combination of synchronized acknowledgement reset these flags can be used to filter or extract uh packets that would show in map or inmap attempts so first let's see we have to find out TCP connect scan so to do that we're going to use this filter TCP do Flags Okay we're going to use the ctcp flags filter and synchronize equal to one so when the synchronized flags flag equals to one meaning we have a TCP connect scan combined with another condition the other condition is that the server would need to send an acknowledgement scan okay at TP connect scan the client sends hello with the synchronized flag set okay and the server replies with acknowledgement so the other condition for TB connect scan to be successful is TCB flags. acknowledgement needs to be zero okay and the last condition the window size TCB do window size needs to be less than or more than 1,24 so this window size we have a problem in this so here it is not Windows it is window so here we have three conditions we use them in one filter the sync flag needs to be one the acknowledgement flag needs to be zero and the window size needs to be more than more than 1,24 so we execute this filter and here as you can see guys warar has extracted all of the packets that indicate there was a TCP connect scan as you can see we we see here a same ize packets sent from this client with the IP address of 101067 to the destination IP address represented by 101 47123 so all these are synchronization packets indicating that there is indeed an N map scan number of packets displayed here is 1,000 at the bottom here as you can see guys where I hovering over with the mouse the number of packets is 6,544 out of which we have displayed packets that represent the filter we have just executed is 1,000 okay next question which is scan type is used to scan the TCP Port 80 so if we filter the TCP traffic now where the port equal to 80 we use the filter TCP Port equal to 80 take a look at the nature of the uh packets okay as you can see here guys to find out the type of inmap scan that's used to reveal to Port at we're going to take a look at the flow of the packets the first packet as you can see we have a synchronization flag set and then the host or the destination address ends with 123 replies with another packet where the acknowledgement flag is sent and then the client send an acknowledgement acknowledgement flag and lastly the uh server sends reset acknowledgement indicating that indicating the uh uh that the three-way handshake is finished successfully so this is typical of a TCB connect scan regular TCB connect scan as opposed to TCB steth scan in a TCP C scan the client only sends a synchronization a packet and then would never send an acknowledgement that's the difference between TCP connect and TCP still scan so we answer with TCB connect scan how many UDP close Port messages are there okay so here udb close ports so basically here we need to find out the udb scans on a Clos Port that indicate that the P Port was closed to be able to do that we're going to need to get the help or or use icmp filters because udb scans use icmp packets so we're going to use icmp do type equal 3 that's the up code and icmp do code equal 3 so this indicates that we looking for udb scans where the port was closed and we have 1,83 packets the last question is which udb port in the 570 Port range is open which udb port in the 5 5570 Port range is open so basically here to be able to find out the answer for this question remember that we need to exclude the closed ports to execute the close ports it's going to be very easy all we have to do is to use this filter that is not equal so this is the not equal filter meaning we're going to execute all the udb scans that you that resulted in Clos ports so we're going to type here UDP first UDP and so this is the filter we're we're going to look for UDP packets and packets that satisfy both conditions where the port uh where the protocol is UTP and U the port is open going to enter and we see we have 1,445 buckets so which should you be Port okay we have to find out the port now which should be port in the 55570 range let's take a look here so as you can see here guys if you take a closer look at the pack Mar ETS at the info section we want to see a port that is between this range 55 and 70 so far these ports are out of range as you can see here guys bucket number 6,294 the port here is 68 in the info section this is the correct answer this port Falls in the right range between 55 and 70 all right in the next task we're going to answer or we're going to take a look at the examples of how to how to analyze the ARP or ARP protocol address resolution protocol okay going need to take a look at another paa file so we're going to file this stop exercise or the file is exercise okay so we have the file open now the first question is what is the number of ARP requests crafted by the attacker so we're not only looking to extract the AR packets but we want to extract the AR request crafted by the attacker meaning here there is a possibility of our poisoning attack to extract our poisoning or the packets that contain our poisoning attack we're going to use this filter as you can see we have 138 packets now to take a look at the source machine that is conducting the attack we're going to have to take a look at an example braacket take a look at this one for example and we scroll down to the address resolution protocol expand this and from here we can we can highlight the cender MAC address it starts with 0 0 and ends with P4 this indicates or this shows the MAC address of the attacker that has crafted these are poisoning packets okay what's next next we need to find out how many requests the attacker has sent so we're not only looking at the total number of our poisoning packets we want we want only to take a look at the requests to do that we're going to have to use a filter that uses the attacker Mac address to do that we're going to have to use ethernet do destination no Source sorry so Source since it is the machine making the request it's going to be the source 00 0 c29 E2 B4 so that is the source Mac address of the attacker and we're going to use another filter since we want to take a look at the ARP requests we're going to use ARP and then the option will be op code there are many op codes that would indicate different uh meanings so an OP code of one meaning an AR request an OP code of maybe two would mean an R response so here as you can see this is the final filter we click enter and we can see we have 284 packets next thing what is the number of HTTP packets received by the attacker now this is easy because here we have the address or the MAC address of the attacker uh now the attacker is on the recipient side so this will be the destination and we're going to use on the other side of the the uh condition here we're going to use HTTP because you want to filter for HTP traffic this will list all the HTP packets where the re recipient is the attacker so we enter and we see these packets so we have 90 packets next thing what is the number of sniff username and password entries so since we are taking a look at the h2b packets there there is a high chance since we're taking a look at the HTP packets in here uh they could be chances or they could be packets that contain username and password entries so you're going to take a look at one example packet so this one represents a get request to a page or to a login page login as you can see here and there is a response from the server so if we follow the stream of this packet we're going to be able to take take a look at the row data so following the TCP stream this is the request and this is the response scrolling down you can take a look at the body of the request from the body of the request we should be able to uh extract plain text credentials so this is the TCP stream I'm going to have to uh go back exactly that's what I need and take look at the um HTP stream so here follow HTTP stream and from here we see the response of the server now from here if we search for a combination of username and password okay so if we search for maybe usern name as you can see we have the US and password submitted in the form but we cannot see the actual values to be able to see the actual values we're going to have to uh you know make the filter more narrowed so going to to modify the filter so here as you can see the request is made to this host and this is the what page and it is a get request usually the credentials are revealed or are sent to the server using a post request so we're going to have to filter the HTP traffic for a post request and we're going to use this host as another filter so we're going to copy this go back and from here HTTP do host equal to this host okay and HTTP request dot method equal to post so in this filter we are using the HTTP traffic HTP filter as part of the HTTP options or the attributes that can be used with the filter we have the host we can filter by the request method so we're filtering for the packets that are sent or that have the host in the packet equals to this host and the request method equals to post now of course you can change this to get to delete to put depending on the kind of request you're looking for going hit enter and this would reveal all of the post requests so I have a post request here to user info and the following packets are all rep representing post request to the web page let's take a look at an example follow the stream and we SC scroll down here we want to see patterns usern with password let's use a filter username or maybe pass okay so we have one username equal test and password equal to test we can see more examples okay this is another one that's another request where the username was UN name equal to testore thmor test and the password was insecure PW so these are tests I don't think they uh they are counted as the answer and then we have these These are also tests okay let's take a look at this one so that's a username um M that's also a test okay this one testore thore test insecure password admin super secret client and we have client 354 nice work so total we have around six usernames and six passwords so we have six what is the password of the client 986 so we are in the same pan here we're going to take a look at this so that's the client 986 and the password is a client not there what is the comment provided by client 354 we're going to go back to the last packet you can see the client 354 and the the the comment was nice work right next identifying dhtp bios and cus traffic so going right to the questions going to open this P file so from file menu open and we go to DHCP Kos highlight the there used to be an AOSP cap so that's the capture file okay all right so what is the MAC address of the host Galaxy a30 so we are given a host we want to find out the MAC address of this host remember that when we analyze DHCP NE bios or kpros most likely the information that we will extract are information that identify the uh end points such as the host name the source and destination Mac address the IP address so when we analyze the HTP n cuos information we aim to extract host name information IP Mac address or even username information when we analyze cuos so you're asking what is the Mac address of this host Galaxy a30 so the host name of every single machine is transferred uh through the packets when declined or when there is DHCP NE bios or cus protocol in the traffic so most probably if we're going to search with this host name we're going to be able to find it in these packets okay because they are dfcp or uh you know NE biopic so so we're going to use uh the search feature so edit and find packet we explained this previously in the last or in the previous video so for the packet details we're going to keep this as is we're going to use string search and type Galaxy a30 we search with this click on find no packet contain that string in it is dissected display oh that is strange let's make sure we open the right file go to statistics capture file properties you can see we open the right file that represent the net bios and the hcp traffic yet we seem to get only the art packets all right okay let's do this DHCP okay we have thep traffic but still we cannot find the Galaxy a30 let's search for net bios NBN s and we have NBN traffic or packets okay so but we cannot find details about this host let's me try the next question how many netb registration requests uh does the Lea ljm workstation have so here we're looking to filter for net bios packets usually if you want to conduct net bios search you use NBN this would show all of the net bios packets that have been captured now I want to extract the registration net bios registration packets do that we're going to use the flags npns flags op code needs to equal to five again guys as with all protocols there are up codes that indicate the the request and response for every single stage for the net bios we have as you can see guys five for the registration same with DHCP different up codes for different stages during the life cycle of the uh request so for request we use upcore three option three and for response we use five for denied request we use six and these can be found here if you take a look at an example n bi packet going to the protocol breakdown we can see here in the queries uh the flags we have the up code as you can see here okay so up code needs to equal to five and we're going to search with another thing with the host name Leva lgm so if you go to the queries here we can see there is an attribute name this indicate the host name of the machine that initiated the net bios request so we're going to use this attribute in the filter so and NBN s. name it's not going to be equal we're going to use contains okay contains uh filter and this is the name of we're looking after okay good we have hits so how many net bios registration requests and we have 16 so no idea why I cannot find this host try it out guys and tell me your feedback in the comments which host requested the IP address so here we need to analyze the DHCP packets because we're looking for information that belonged to a machine initiated an IP an IP assignment so there was machine that requested to have this IP address so to find out this machine we're going to need to take a look at the DHCP packets usually can contact Global search to extract the hcp packet using DHCP filter this would show all the DHCP packets again guys to be able to use the filters and the attributes of this uh filter take a look at an example packet and go back or uh sorry go to the protocol breakdown highlight Dynamic host configuration protocol and from here we can take a look at the options so these options can be used in the filter up here we have the length Hardware type CL Cent Mac address all of these can be used in the filter so we want to find out the requested IP address let's see if we have this option here an option that we can use to filter by the requested IP address because in a dhp packet a host will send a DHCP request for an IP assignment right client Mac address message type parameter list so this is DHCP inform form we going to need to take a look at the DHCP request packet let's see here so DHCP request packets can be found using this up code three so these are the HTTP requests let's take a look now at the options at and we can see here that option 50 we have this requested IP address now we're going to use this in the filter so here option underscore requested underscore IP underscore address equal to to this let's see who's the host that requested this IP address DCP the option underscore requested underscore IP underscore address I still the query tells me there is a problem let's see here hm H do requested not underscore and now it is correct okay we have one packet take a look down here want to extract the host name scroll down the host name usually is an identifier that can be found from here so option 12 the host name is galaxy-2 which is the answer now next question what is the IP address of the user u5 we need now to analyze the curos packet capture so we click on file and we go to uh curos so these are cus packets in order to conduct Global sech with kpros we can use um let's scroll down we can use this keyword this would list all of the curos packets okay now the same thing with protocol in order to figure out how to extract attributes from these packets we're going to have to take a look at an example packet we go to curos and we can see here the tickets these are the um options or the attributes we can use in the filter so we have C name this would indicate the host name of the machine and maybe the username of the machine C name String and we have ticket if you want to filter by tickets so the question is here telling us to find out the IP address of the user u5 so usually you want to filter for the uh packets or the cus packets where the username contains the u5 therefore we're going to use the C name String so Cur bros. C name String contains your five and we have hits so what is the IP address of the user let's take a look at an example packet again going to the protocol of breakdown you can see here let's make sure the data is correct the username is or or contains u5 okay so C name String u5 meaning that this is the correct machine we need to find out the IP address the IP address is 10122 what is the host name of the available host in the kpros packets what is the host name of the available host so we need to Circle back here and use this filter why because we just we need to list all of the C name strings from the cus packets so take a look at the first one for example or this one so the C name String here is Dees what is the host name of the available host the question is vague I may admit because there are many host names here now this one contains the correct answer okay so as you can see guys we analyze the HTP net bios skos packets to extract host name information and other identifying information such as the username of the machines now next we're going to take a look at the task five where we going to analyze DNS and icmp traffic usually DNS and icmp traffic are used to perform U tunneling meaning uh used under the context of that in the context of that ex filteration after the machine is compromised usually the attackers try to um smuggle the sensitive data through these protocols DNS and icmp to hide the uh what they what they are doing okay so now let's expand here and see the questions investigate the anomalous packets first we're going to take a look at this paa file so file open go to this one and going to analyze this okay so investigate anomalous packets which protocol is used in icmp channeling all right so to conduct Global search to reveal the icmp packets we can use icmp again as with every protocol we take look at an example packet and we scroll down to the packet details we see what kind of attributes we can use in the search data the sequence numbers all of these are valid options that can be used in the filter so here we want to find out the anomalous packets so usually an icmb packet is anomalous when the length of the packet is more than certain size which happens to be a standard size for packets it is 64 when the length of the packet is more than 64 the icmp packet is considered to be suspicious it means it might contain data more data than it's supposed to be because ismp is a protocol used to network trouble shooting and probing as well so the data length of an i packet is not supposed to be more than 64 so to find the packets we're going to filter for icmp and we're going to have to use another filter the data length here as you can see an example packet here data length is 84 bytes so the filter for packets with the data length is more than um uh 64 we're going to have to this filter and more than 64 this will give me all of the packets where the length is more than 64 as you can see an example packet is here you can see the data is 84 bytes and this one is the same 84 byes a total of 759 packets so which protocol is used in icmp tunneling we want to find out the actual reason why packet is more than 64 meaning there is there might be some tunneling happening going on here so to find out this to find this out take a look at an example here it's not clear what kind of payload data is this so we're going to need to take a look at more packets and keep an eye on the payload data on the right okay stop there take a look at this one so here there is open SSH packet number 42 as you can see guys the payload data shows an open SSH Banner which means that the protocol icmp is smuggling data using the open SSH so the protocol used here is open or the old SSH protocol now we're going to open the other P file DNS analyze the DNS traffic okay same with other protocols we use DNS and we can find out all of the DNS packets all right so DNS is a very common and popular Network protocol attackers use this protocol to conduct queries or to send queries to a C2 server as we learned from the pre previous videos so there's a high chance that packets contain queries sent to C2 server in order to you know request commands to be executed on the compromise machine so we're going to going need to reveal the malicious DNS packets or the packets that probably were sent to a C2 server to find this out we're going to need to rely on the data length so a malicious DNS query that's sent to CTO server usually will look longer than the regular DNS query that's sent to a regular domain to find this out we're going to need to use Query attribute and name do length can need to be more than 15 and we need to Al satisfy this condition so take a look at these packets we have a total of 30,000 364 packets the question is investigate the anomalous packets what is the suspicious main domain address that receives anomalous DNS queries okay here we're going to again need to take a look at the payload data data we have a lot of queries here so there is a malicious domain you might probably need to uh take a look at many packets to find the correct answer take a look at the payload data here we need to find out a unique domain name that's not so common so keeping an eye on the payload data here scrolling down we can see this one packet number 2,621 and on the payload data section we see a domain name that equals to xfl.com so that's the malicious domain data xfill data xfl.com next we're going to analyze clear text Data transferred through FTP and H HTP so here we go now we have FTP packets again we can filter the FTP packets using the FTP filter we can see all of the FTP packets same with other protocols there are options attributes that can be used as you can see guys to filter for FTP requests FTP response failed login attempts successful login attempts now here to uh find out the Brute Force attempts as depicted in the question we need to look for the correct code sent by the server usually Brute Force attempts have many failed login attempts to filter failed login attempts we're going to have to use the Response Code Center by the server every packet has a response code you going you can find it from here from the protocol breakdown we can see the Response Code attribute it can be used in the query as we have demonstrated with every other protocol okay so fb. response and then code has to be 530 indicating a fail login attempts how many of them 737 what is the size of the file X accessed by the FTP account okay here we're looking to extract the files accessed so again this is another FTP code so the FTP code for file status or file probing is 2113 so we going back here and say instead of 530 it's going to be 213 and we have one so we have two packets we need to find out the size of the file okay to find out the size of the file we can see here in the info section it is 213 bytes file status 23 oh no I made a mistake it's not that it is this one 3, 39,900 424 that's the file of the size accessed adversary uploaded a document to the FTP server what's the F name we are in the same pen we're looking to find status information about the files so here we have this we can choose to follow the stream and we can follow along with the packets we can see a login successful login scrolling down we see a list of the current directory to list the contents and we can see a command sent to the server to upload this file resume so the file name is resume or this document file adversary try to assign special Flags to change the executing permissions of the uploaded file again we we are back here with the file status response code 213 so back here follow TCP stream so we're going to need to follow along with the commands that the attacker executed on files now we see this one CH mode 37s so that's the command used to change the permissions on the resume uploaded okay now we can analyze clear Text data on the HTTP protocol okay close open a new file that's quite long room uh and the user agent pick up okay so this is the pain or this is the packet list of HTTP packets again we can use HTTP to conduct Global search of the HTTP packets now usually guys if you want to analyze malicious packets or malicious traffic s over HTTP one of the common signs is the user agent so a malous user agent is usually found uh through a packets sent from the attackers so the question here is asking investigate the user agents what is the number of anomalous user agent types so there are many ways to answer this question usually you want to look for the most common malicious user agents okay to be able to do that we're going to need to know what are these user agents so we can take a look at an example here this is an example packet we go to the protocol breakdown and from here we can analyze the user agent the user agent here is Milla that's not a malicious user agent usually it can be malicious you cannot rule it out unless you analyze it more in depth take a look at another one so take a look at this one the user agent here is SQ map most definitely this is an indicator that an attacker is using SQL map to analyze the application for SQL injection vulnerabilities so upon analyzing or when you analyze most of the packets you'll be able to come up with the list of the user agents used and to attack used to attack the host so basically let's see here in HTTP we can extract them or we can use this filter so this filter here analyze it okay so here we're looking for the user agent attribute so this filter will list all of the packets where the user agent equals to SQL map or n map or W fuz or ncto so we have 24 packets we want to find out how many what is the number of anomalous user agent to facilitate this we're going to have to add this as a column so add apply as a column and now we have the user agent here another filter for the user agent can be this so here would indicate that there is a lock forj attack caring this user agent and we can see another one this is the user agent used this would now make them three user agents and again guys we can use uh another query let's go back look at this one we have a pce 64 here if you take a look at this going to copy that copy the value and go to cyber chef from Bas 64 and this Bas 64 command is used to retrieve a file from the server LH it's a bash script and it downloads the script gives it execution permissions and execute on the machine look at this one so that's the US that's the uh that's an indicator of another attack was taking place and this would answer this question by the way the last one now this one is interesting there is a slight typo here instead of Milla it is Mosa now usually attackers use typos to um deceive analysts so in so if you if you take a closer look or if you take a quick look at the user agent here you would realize oh this is mosella nothing abnormal here but upon a closer inspection we see a typo here it looks very similar to the original lay open okay so where is this file come on don't make it hard httv okay now we're going to use the same filter here and take a look at the packet number the start is 444 this is the packet number all right next task eight analyzing https traffic we can conduct a global search for htps uh data using https nope uh ssdb well it works part partially maybe you can try with http2 okay so why this doesn't work why we cannot filter all the https traffic because usually traffic sent over htps is encrypted which means we cannot have full visibility on the details including the payload section or the payload data other uh data such as the information transferred over the uh protocol so we don't have full visibility over what data is being transferred when we analyze https so that's why in order to correctly analyze or to be able to have as much information as possible from the encrypto traffic we're going to rely on the What's called the TLs handshake the TLs handshake is the same as TCP handshake but encrypted with the TLs uh protocol as you can see here guys there are many states for the tless handshake so as you can see a handshake tless handshake type one okay and tless handshake type two so type one when a client says hello to the server and type two when the server says hello to the client we can use these as well to extract the communication between the client and the server over the TLs or over htps protocol we can see these are requests from the client to the server and if we use this filter actually we only change one with two we can see the server answers to the client right so this way we can filter https traffic relying on the DLS handshake the question here is what is the frame number of the client Hello message sent to accounts Google so going to have to filter with the packets sent from the client okay so look here for example this one as you can see in the payload data section we can see this accounts google.com now to be able to find the frame number we're going to have to look at the packet details so this is Packet number 16 decrypt the traffic with the keys log file what is the number of http2 packets so what's going on here all right so as you know guys this is an encrypted traffic to be able to decrypt it the only way is to have the correct uh public and private key we have to make sure that we have the keys used to encrypt the session as you know guys when you browse a website using htps as you can see in the browser here there is a session open between you as the client and and the other website or this or the server as the server site this session okay uses pair of keys if we cannot capture these keys we're not going to be able to decrypt the traffic okay so to answer this question the author of this room has provided us with a key log file this log file was created after they captured or they sniffed the traffic over an https session when they did that they were able to extract the keys so with the keys ready for us we can decrypt the traffic okay so to decrypt the traffic we're going to X on this go to file edit preferences and then go to protocols going to supply wire shark with the correct keys so let's see here looking for the correct protocol it's going to be long no so TLS is ready here okay and here the pre-shared key is what we need the file it contains the encrypted or the encryption Keys okay so we browse to the key log file already have it here going to open and then click on okay so now I provide War Shack with the correct keys to the red traffic next is to type HTTP 2 not one man two okay and now we have the traffic decrypted now we can take a look at the packets in clear text and they are 115 packets go to frame 332 okay we're going to go to packet 322 that's right okay what is is the authority header of the http2 packet okay taking a look at the http2 which is a decrypted form at of HPS scrolling down to the authority header so that's the authority header safe browsing googleapis.com investigate the decrypted packets and find the flag what is the flag okay so to find the flag you're going to have to export the objects so go to file export objects okay as you can see we have two so we're going to save the first one desktop and now as you can see guys we have the file we open the file and we can see the flag here okay last two tasks are very easy guys but I'm going to go over them nevertheless so here we learn how to extract clear text credentials automatically without the need to go over you know filters and uh decrypt traffic so we're going to Lo the relevant packet capture file it is under bonus okay so go to tools credentials and wiar automatically extracts all clear text credentials transferred over nonseq protocol such as FTP and HTP you can see them in here the username and additional information okay so what's the packet number of the credentials using HTP basic o we have only one that uses h2p o and it is 237 which the packet number where empty password was submitted so as you can see we cannot find what what password can be what what password has been used but if you click on an example packet let's take a look at this one see we are um brought to the packet number 170 and we can see that there is no password provided empty password okay last one here going to open the relevant pickup we are in the same peup file this task is about creating firewall rules so how is that possible so basically guys W shark based on the given pea file it can give you defensive insights so if you are using for example um one of these firewalls net filter Cisco iOS IP filter warar can create uh firew rules automatically for you all you have to do is to go to tools fir rules and you can find all of the possible rules that can be created based on different attributes from here we can select what kind of f we want to create the rule for can select IP firewall and from here we can see all of the rules that can be applied so here we want to create a rule for denying Source ipv4 address so source ipv4 and we can use this one to deny the source IP address select packet number 231 okay packet number 2 31 this is the packet highlight the packet go to tools create firew reset and here we're going to select again IP firewall what is the rule for allowing destination Mac address so here all of these are for ipv4 scrolling down we can see Mac address we want this the destination Mac address so we want to allow this station Mac address so we're can use this one but instead of deny we're going to use allow so that was it guys
