{
    "id": "46776acb-56e4-4632-abfe-4bbbf7d49987",
    "name": "Investigating Network Attacks",
    "slug": "investigating-network-attacks",
    "status": "published",
    "lab_type": "pta",
    "is_sample": false,
    "duration_in_seconds": 1800,
    "metadata": {
        "courses": [
            "cd60ce4a-1b83-48c4-8d38-7e6bfeab4a1e"
        ],
        "pta_sdn": "58",
        "pta_namespace": "my.ine",
        "learning_paths": [],
        "has_published_parent": true
    },
    "session": null,
    "company": "a491bc32-c056-4946-9169-cc053387bada",
    "created": "2022-03-30T03:10:27.818625Z",
    "modified": "2024-04-30T14:38:18.324811Z",
    "is_beta": false,
    "lab_objectives": [],
    "main_learning_area": "3e1aa06f-2e9f-4789-b50d-aa027ad8dcfa",
    "learning_areas": [
        {
            "id": "3e1aa06f-2e9f-4789-b50d-aa027ad8dcfa",
            "name": "Cyber Security",
            "slug": "cyber-security"
        }
    ],
    "categories": [],
    "tags": [],
    "difficulty": null,
    "is_web_access": false,
    "is_lab_experience": false,
    "is_featured": false,
    "cve": null,
    "severity": null,
    "year": null,
    "classification": null,
    "external_url": "",
    "solution_video": null,
    "explanation_video": null,
    "description": "# Scenario\n\nA company's internal network is under serious attacks. The IDS at every Department are throwing various alerts of unknown network attacks. You are called to find out what's going on, explain what type of attacks are being conducted and how it may be possible to mitigate them.\n\nThe network engineers at each department installed a packet capturing device and presented you with the captured files.\n\n# Goals\n\n- Examine the traffic generated by the various network attacks\n- Determine the attack and its potential impact\n- Find the machine where the attack originated from\n\n# What you will learn\n\n- Analyze traffic looking for attacks\n\n# Recommended tools\n\n- **Wireshark**",
    "description_html": "<h1>Scenario</h1>\n<p>A company's internal network is under serious attacks. The IDS at every Department are throwing various alerts of unknown network attacks. You are called to find out what's going on, explain what type of attacks are being conducted and how it may be possible to mitigate them.</p>\n<p>The network engineers at each department installed a packet capturing device and presented you with the captured files.</p>\n<h1>Goals</h1>\n<ul>\n<li>Examine the traffic generated by the various network attacks</li>\n<li>Determine the attack and its potential impact</li>\n<li>Find the machine where the attack originated from</li>\n</ul>\n<h1>What you will learn</h1>\n<ul>\n<li>Analyze traffic looking for attacks</li>\n</ul>\n<h1>Recommended tools</h1>\n<ul>\n<li><strong>Wireshark</strong></li>\n</ul>",
    "tasks": "# Tasks\n\n## Task 1: Examine the Captured Traffic of the HR Department\n\nExamine the PCAP file containing traffic from the HR Department [located at **Desktop/Module7/Lab22/1.HR_Dept.pcapng**]\n\nThe users are complaining about the slow network performance.\n\nWhat type of attack is being carried? What is the impact of this attack?\n\n## Task 2: Examine the Captured Traffic of the IT Department\n\nExamine the PCAP file containing traffic from the IT Department [located at **Desktop/Module7/Lab22/2.IT_Dept.pcapng**]\n\nUsers are complaining about not being able to access the internet at all, even though the router (192.168.153.2) is pingable. What type of attack is being conducted? How can such an attack be stopped?\n\n## Task 3: You Get a Call from a Client Complaining About Not Being Able to Access the Web Server (192.168.153.154). Try to Figure Out What Is the Case.\n\nExamine the PCAP file containing traffic from the Web Server [located at **Desktop/Module7/Lab22/3.WebServer.pcapng**]\n\nYou try to access the site, and you find out that it takes ages to load. Examine the traffic that was captured and try to determine what is happening and the attacker's IP address, if possible.\n\n## Task 4: Employees At the Legal Department Cannot Connect to the Network At All. Try to Figure Out What Is the Case.\n\nExamine the PCAP file containing traffic from the Legal Department [located at **Desktop/Module7/Lab22/4.Legal_Dept.pcapng**]\n\nWhat sort of attack is being conducted here? Can you determine the source? How can it be stopped?\n\n## Task 5: The Management Department Was the Only Department Which You Didn't Get Any Complaints From. Try to Figure Out If They Have Also Been Attacked.\n\nExamine the PCAP file containing traffic from the Management Department [located at **Desktop/Module7/Lab22/5.MGT_Dept.pcapng**]\n\nThis sounds suspicious since it doesn't make sense for a group of attackers to attack the whole network and leave that department untouched. Examine the captured traffic you have and see if you can spot anything unusual.",
    "tasks_html": "<h1>Tasks</h1>\n<h2>Task 1: Examine the Captured Traffic of the HR Department</h2>\n<p>Examine the PCAP file containing traffic from the HR Department [located at <strong>Desktop/Module7/Lab22/1.HR_Dept.pcapng</strong>]</p>\n<p>The users are complaining about the slow network performance.</p>\n<p>What type of attack is being carried? What is the impact of this attack?</p>\n<h2>Task 2: Examine the Captured Traffic of the IT Department</h2>\n<p>Examine the PCAP file containing traffic from the IT Department [located at <strong>Desktop/Module7/Lab22/2.IT_Dept.pcapng</strong>]</p>\n<p>Users are complaining about not being able to access the internet at all, even though the router (192.168.153.2) is pingable. What type of attack is being conducted? How can such an attack be stopped?</p>\n<h2>Task 3: You Get a Call from a Client Complaining About Not Being Able to Access the Web Server (192.168.153.154). Try to Figure Out What Is the Case.</h2>\n<p>Examine the PCAP file containing traffic from the Web Server [located at <strong>Desktop/Module7/Lab22/3.WebServer.pcapng</strong>]</p>\n<p>You try to access the site, and you find out that it takes ages to load. Examine the traffic that was captured and try to determine what is happening and the attacker's IP address, if possible.</p>\n<h2>Task 4: Employees At the Legal Department Cannot Connect to the Network At All. Try to Figure Out What Is the Case.</h2>\n<p>Examine the PCAP file containing traffic from the Legal Department [located at <strong>Desktop/Module7/Lab22/4.Legal_Dept.pcapng</strong>]</p>\n<p>What sort of attack is being conducted here? Can you determine the source? How can it be stopped?</p>\n<h2>Task 5: The Management Department Was the Only Department Which You Didn't Get Any Complaints From. Try to Figure Out If They Have Also Been Attacked.</h2>\n<p>Examine the PCAP file containing traffic from the Management Department [located at <strong>Desktop/Module7/Lab22/5.MGT_Dept.pcapng</strong>]</p>\n<p>This sounds suspicious since it doesn't make sense for a group of attackers to attack the whole network and leave that department untouched. Examine the captured traffic you have and see if you can spot anything unusual.</p>",
    "published_date": "2020-10-20T15:32:26Z",
    "solutions": "# Solutions\n\n## Task 1: Examine the Captured Traffic of the HR Department\n\nWe can tell from the first look at the peak of the file, without any in-depth analysis, that something is not right. We have many IP packets that are not carrying any content, and most of them don't belong to the network segment we sniffed the data from.\n\n![0](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/0.png)\n\nThis suggests that someone is crafting those packets and sending them on the network to cause the switch to throw its cam table and work as a hub.\n\nWe can safely assume we are dealing with Mac flooding here.\n\n## Task 2: Examine the Captured Traffic of the IT Department\n\nLet's examine the protocol hierarchy in this PCAP file.\n\nEverything may seem normal at first glance; however, we know from our study that internet disconnection on a network can be caused by an attacker conducting ARP poisoning attacks.\n\nLet's filter out the traffic, display only the ARP packets and scroll down to view the ARP replies to verify that hypotheses.\n\n![1](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/1.png)\n\nHere is the first ARP reply which has the router's IP address.\n\n![2](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/2.png)\n\nThe reply claims that the router's physical address is **00:50:56:eb:f7:91.** Let's look at more replies.\n\nDown there, something defiantly doesn't look right.\n\nThere is one device that keeps sending gracious ARP replies, telling that the default gateway MAC address is **00:0c:29:20:bc:14** (which is different from the one we saw earlier) even though no one sent a request about it.\n\n![3](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/3.png)\n\nThis looks very much like poisoning attacks where the attacker keeps sending spoofed ARP replies, telling everyone that he or she is the default gateway.\n\nThe good thing about this is that the MAC address that is being populated by those ARP frames is supposed to be the MAC address of the attacker.\n\nLet's filter the traffic looking for frames that holds that MAC address.\n\n![4](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/4.png)\n\nThis is interesting; we can see the ARP answers we saw earlier in addition to an ACK segment coming from **192.168.153.154** which contains the suspect's MAC address we got earlier.\n\nThis attack may be stopped by implementing dynamic ARP inspection feature in the network.\n\n## Task 3: You Get a Call from a Client Complaining About Not Being Able to Access the Web Server (192.168.153.154). Try to Figure Out What Is the Case.\n\nThe client's description mentioned that the web server is not functioning well. Most of the attacks that cause web servers to slow down or denial of service rely on sending too many requests.\n\nTo get an overview of the packets going to our web server let's use Wireshark filters to display packets that are destined to our web server on port 80.\n\n```\nip.addr==192.168.153.154 and tcp.dstport==80\n```\n\n![5](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/5.png)\n\nWe can see that our server is receiving many (maybe too many) SYN segments on port 80. This may suggest that this is a SYN flooding attack.\n\nOne way to tell if those SYN request are coming from real users or not is to view the rest of the communication.\n\nWe can see that the supposed clients are terminating the connection right after sending the SYN.\n\nAnother way is to perform reverse DNS on those IP addresses. We can also ping those IP addresses and compare the TTL and the TCP window size values from their reply with the values we have on the request we received.\n\nHowever, since this seems to be a blind DOS attack, it may be hard to determine the attacker's IP address based on the traffic alone.\n\n## Task 4: Employees At the Legal Department Cannot Connect to the Network At All. Try to Figure Out What Is the Case.\n\nThis is an APIPA IP address which a client assigns to itself when it is unable to reach the DHCP within the network.\n\nIt seems that there is no need to filter out DHCP packets to verify whether the DHCP is active on that Network or not because the number of DHCP discover packets is enormous. See *Statistics > DHCP (BOOTP) Statistics*\n\n![7](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/7.png)\n\nWe can see that DHCP offer messages are going on that Network.\n\n![8](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/8.png)\n\nThis rules out the possibility of a problem in the connection between the clients and the DHCP and makes us believe that someone is performing a DHCP starvation attack.\n\nUnfortunately, we may not be able to determine the source of the attack by analyzing the PCAP file alone. However, we can stop it by enabling DHCP messages rate limiting on the switch's port.\n\n## Task 5: The Management Department Was the Only Department Which You Didn't Get Any Complaints From. Try to Figure Out If They Have Also Been Attacked.\n\nSince we have doubts, let's start with examining the protocol hierarchy of the file capture. See *Statistics > Protocol Hierarchy*\n\n![9](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/9.png)\n\nWe can see that there are many seemingly normal protocols running. However, down on the bottom of the TCP application, alongside HTTP and HTTPS we notice that there is an unknown protocol running under the name _Data_.\n\nThe name or tag data suggests that Wireshark couldn't recognize the protocol used for the connection.\n\nLet's filter the traffic looking for those packets by typing the word _data_ in the filter box.\n\n![10](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/10.png)\n\nWe are now left with a few ICMP messages and unknown TCP messages carrying data. The data section of the ICMP packet doesn't seem to be carrying anything interesting.\n\n![11](https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/11.png)\n\nSo, let's follow the stream of the other connection we found (the unknown protocol in the TCP)\n\nFrom the output, we can see that someone has connected to the **192.168.153.154** machine on port 6666 to a remote shell, created a new user named **Manager** and added it to the **Administrators** group.",
    "solutions_html": "<h1>Solutions</h1>\n<h2>Task 1: Examine the Captured Traffic of the HR Department</h2>\n<p>We can tell from the first look at the peak of the file, without any in-depth analysis, that something is not right. We have many IP packets that are not carrying any content, and most of them don't belong to the network segment we sniffed the data from.</p>\n<p><img alt=\"0\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/0.png\" /></p>\n<p>This suggests that someone is crafting those packets and sending them on the network to cause the switch to throw its cam table and work as a hub.</p>\n<p>We can safely assume we are dealing with Mac flooding here.</p>\n<h2>Task 2: Examine the Captured Traffic of the IT Department</h2>\n<p>Let's examine the protocol hierarchy in this PCAP file.</p>\n<p>Everything may seem normal at first glance; however, we know from our study that internet disconnection on a network can be caused by an attacker conducting ARP poisoning attacks.</p>\n<p>Let's filter out the traffic, display only the ARP packets and scroll down to view the ARP replies to verify that hypotheses.</p>\n<p><img alt=\"1\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/1.png\" /></p>\n<p>Here is the first ARP reply which has the router's IP address.</p>\n<p><img alt=\"2\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/2.png\" /></p>\n<p>The reply claims that the router's physical address is <strong>00:50:56:eb:f7:91.</strong> Let's look at more replies.</p>\n<p>Down there, something defiantly doesn't look right.</p>\n<p>There is one device that keeps sending gracious ARP replies, telling that the default gateway MAC address is <strong>00:0c:29:20:bc:14</strong> (which is different from the one we saw earlier) even though no one sent a request about it.</p>\n<p><img alt=\"3\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/3.png\" /></p>\n<p>This looks very much like poisoning attacks where the attacker keeps sending spoofed ARP replies, telling everyone that he or she is the default gateway.</p>\n<p>The good thing about this is that the MAC address that is being populated by those ARP frames is supposed to be the MAC address of the attacker.</p>\n<p>Let's filter the traffic looking for frames that holds that MAC address.</p>\n<p><img alt=\"4\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/4.png\" /></p>\n<p>This is interesting; we can see the ARP answers we saw earlier in addition to an ACK segment coming from <strong>192.168.153.154</strong> which contains the suspect's MAC address we got earlier.</p>\n<p>This attack may be stopped by implementing dynamic ARP inspection feature in the network.</p>\n<h2>Task 3: You Get a Call from a Client Complaining About Not Being Able to Access the Web Server (192.168.153.154). Try to Figure Out What Is the Case.</h2>\n<p>The client's description mentioned that the web server is not functioning well. Most of the attacks that cause web servers to slow down or denial of service rely on sending too many requests.</p>\n<p>To get an overview of the packets going to our web server let's use Wireshark filters to display packets that are destined to our web server on port 80.</p>\n<pre class=\"codehilite\"><code>ip.addr==192.168.153.154 and tcp.dstport==80</code></pre>\n\n<p><img alt=\"5\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/5.png\" /></p>\n<p>We can see that our server is receiving many (maybe too many) SYN segments on port 80. This may suggest that this is a SYN flooding attack.</p>\n<p>One way to tell if those SYN request are coming from real users or not is to view the rest of the communication.</p>\n<p>We can see that the supposed clients are terminating the connection right after sending the SYN.</p>\n<p>Another way is to perform reverse DNS on those IP addresses. We can also ping those IP addresses and compare the TTL and the TCP window size values from their reply with the values we have on the request we received.</p>\n<p>However, since this seems to be a blind DOS attack, it may be hard to determine the attacker's IP address based on the traffic alone.</p>\n<h2>Task 4: Employees At the Legal Department Cannot Connect to the Network At All. Try to Figure Out What Is the Case.</h2>\n<p>This is an APIPA IP address which a client assigns to itself when it is unable to reach the DHCP within the network.</p>\n<p>It seems that there is no need to filter out DHCP packets to verify whether the DHCP is active on that Network or not because the number of DHCP discover packets is enormous. See <em>Statistics &gt; DHCP (BOOTP) Statistics</em></p>\n<p><img alt=\"7\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/7.png\" /></p>\n<p>We can see that DHCP offer messages are going on that Network.</p>\n<p><img alt=\"8\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/8.png\" /></p>\n<p>This rules out the possibility of a problem in the connection between the clients and the DHCP and makes us believe that someone is performing a DHCP starvation attack.</p>\n<p>Unfortunately, we may not be able to determine the source of the attack by analyzing the PCAP file alone. However, we can stop it by enabling DHCP messages rate limiting on the switch's port.</p>\n<h2>Task 5: The Management Department Was the Only Department Which You Didn't Get Any Complaints From. Try to Figure Out If They Have Also Been Attacked.</h2>\n<p>Since we have doubts, let's start with examining the protocol hierarchy of the file capture. See <em>Statistics &gt; Protocol Hierarchy</em></p>\n<p><img alt=\"9\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/9.png\" /></p>\n<p>We can see that there are many seemingly normal protocols running. However, down on the bottom of the TCP application, alongside HTTP and HTTPS we notice that there is an unknown protocol running under the name <em>Data</em>.</p>\n<p>The name or tag data suggests that Wireshark couldn't recognize the protocol used for the connection.</p>\n<p>Let's filter the traffic looking for those packets by typing the word <em>data</em> in the filter box.</p>\n<p><img alt=\"10\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/10.png\" /></p>\n<p>We are now left with a few ICMP messages and unknown TCP messages carrying data. The data section of the ICMP packet doesn't seem to be carrying anything interesting.</p>\n<p><img alt=\"11\" src=\"https://assets.ine.com/content/ptp/lab_22_investigating_network_attacks/11.png\" /></p>\n<p>So, let's follow the stream of the other connection we found (the unknown protocol in the TCP)</p>\n<p>From the output, we can see that someone has connected to the <strong>192.168.153.154</strong> machine on port 6666 to a remote shell, created a new user named <strong>Manager</strong> and added it to the <strong>Administrators</strong> group.</p>",
    "flags": [],
    "min_points_to_pass": null,
    "access_type": "default",
    "user_status": "unstarted",
    "user_lab_status": null,
    "user_status_modified": null,
    "user_flags": [],
    "global_running_session": null
}