Introduction to Incident Response Simulation

Welcome to Chapter 15! In our journey so far, we’ve explored the intricate worlds of firewalls, DNS, subnetting, packet analysis, network monitoring, and the foundational principles of cybersecurity. Now, it’s time to put all that knowledge into action with a practical, hands-on project: an Incident Response (IR) Simulation.

This chapter is designed to be the ultimate test and application of your cumulative learning. You’ll step into the shoes of a cybersecurity analyst, tasked with detecting, analyzing, and containing a simulated cyber incident within a controlled network environment. By actively engaging in this simulation, you won’t just memorize concepts; you’ll gain practical experience and confidence in real-world cybersecurity scenarios. Get ready to think critically, troubleshoot effectively, and become a true digital detective!

Before we dive in, make sure you’re comfortable with:

  • Configuring basic network devices (routers, switches, hosts) and IP addressing.
  • Understanding firewall rules (allow/deny, ports, protocols, IP addresses).
  • The basics of packet analysis and what to look for in network traffic.
  • Interpreting network logs and events.

Core Concepts: Incident Response & Simulation

Incident Response (IR) is the organized approach an organization uses to address and manage the aftermath of a security breach or cyber attack. Its primary goal is to limit damage, reduce recovery time and costs, and prevent future incidents.

The NIST Incident Response Lifecycle

The National Institute of Standards and Technology (NIST) provides a widely adopted framework for incident response, breaking it down into several key phases. Understanding these phases is crucial for any IR professional:

  1. Preparation: This phase involves establishing policies, procedures, and tools before an incident occurs. It includes training staff, implementing security controls (like firewalls!), and having communication plans ready.
  2. Identification: This is where you detect an incident. It involves monitoring systems, analyzing logs, and confirming that an actual security event has taken place. This is where your network monitoring and packet analysis skills truly shine!
  3. Containment: Once an incident is identified, the goal is to stop its spread. This might involve isolating compromised systems, blocking malicious traffic at the firewall, or disabling user accounts.
  4. Eradication: After containment, you eliminate the root cause of the incident. This could mean removing malware, patching vulnerabilities, or reconfiguring systems.
  5. Recovery: Bringing affected systems back online in a secure manner. This often involves restoring from backups, verifying system integrity, and monitoring for any recurrence.
  6. Post-Incident Activity (Lessons Learned): Analyzing what happened, how it was handled, and what improvements can be made to prevent similar incidents in the future. This is a vital step for continuous improvement.

Why Simulate Incidents?

Simulating cyber incidents offers invaluable benefits:

  • Skill Development: It provides a safe environment to practice your technical skills without risking actual production systems.
  • Process Refinement: Helps identify gaps in IR plans and procedures, allowing organizations to refine them before a real crisis.
  • Team Cohesion: Fosters teamwork and communication among IR team members.
  • Stress Testing: Allows individuals and teams to experience the pressure of an incident, improving their ability to perform under stress.

For our project, we’ll focus heavily on the Identification and Containment phases within a simulated network environment.

Step-by-Step Implementation: Our Incident Response Scenario

We’ll use Cisco Packet Tracer (version 8.2.2 or later, as of 2025-12-23) to build a simple network and simulate an attack. While Packet Tracer has limitations compared to real-world tools like Wireshark on live systems, it’s excellent for visualizing network flow and applying basic firewall concepts.

Scenario Briefing: The “Suspicious Outbound Connection”

Imagine you’re the junior network security analyst for “TechCo.” Your network monitoring system (which we’ll simulate conceptually) has alerted you to highly unusual outbound TCP connections originating from one of your internal web servers, WebSrv01. The connections are attempting to reach an external IP address on an uncommon port, suggesting potential command-and-control (C2) communication or data exfiltration. Your task: Investigate, identify the threat, and contain it.

Step 1: Setting Up Our Lab Environment in Packet Tracer

Let’s build a basic network that represents a simplified version of TechCo’s infrastructure.

1.1 Build the Network Topology

Open Cisco Packet Tracer and create the following topology:

  • 1x Router: Generic Router (e.g., 4331)
  • 1x Switch: Generic Switch (e.g., 2960)
  • 1x Server: Generic Server (rename to WebSrv01)
  • 1x PC: Generic PC (rename to AnalystPC)
  • 1x Cloud: Generic Cloud (representing the Internet)

Connect them as follows:

  • Router’s GigabitEthernet0/0/0 to Cloud’s Ethernet port.
  • Router’s GigabitEthernet0/0/1 to Switch’s FastEthernet0/1.
  • Switch’s FastEthernet0/2 to WebSrv01.
  • Switch’s FastEthernet0/3 to AnalystPC.

Your topology should look something like this:

graph TD Cloud[Internet] -- GigabitEthernet0/0/0 --> Router Router -- GigabitEthernet0/0/1 --> Switch Switch -- FastEthernet0/2 --> WebSrv01[Web Server 01] Switch -- FastEthernet0/3 --> AnalystPC[Analyst PC]

1.2 Configure IP Addresses

Now, let’s assign IP addresses. We’ll use a simple subnet for our internal network.

  • Internal Network: 192.168.1.0/24
  • External (Internet) IP: We’ll use a placeholder, 203.0.113.1 for the router’s WAN interface, and assume the cloud handles routing beyond that.

Configure Router:

  1. Click on the Router, go to the “CLI” tab.
  2. Enter enable, then configure terminal.
  3. Configure the internal interface:
    Router>enable
Router#configure terminal
Router(config)#interface GigabitEthernet0/0/1
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#exit
  4. Configure the external (WAN) interface. We’ll just give it an IP and assume the cloud is configured.
    Router(config)#interface GigabitEthernet0/0/0
Router(config-if)#ip address 203.0.113.1 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#exit
  5. Add a default route to simulate Internet access (pointing to the Cloud’s “next hop,” which Packet Tracer handles implicitly via the Cloud object):
    Router(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2
Router(config)#exit
Router#copy running-config startup-config
    (Note: 203.0.113.2 is a common placeholder for the “ISP” side of the connection to the cloud.)

Configure WebSrv01:

  1. Click on WebSrv01, go to “Desktop” tab, then “IP Configuration”.
  2. Set Static IP:
    • IP Address: 192.168.1.10
    • Subnet Mask: 255.255.255.0
    • Default Gateway: 192.168.1.1
    • DNS Server: (Leave blank for now, or set to 192.168.1.1 if you want to simulate internal DNS later).

Configure AnalystPC:

  1. Click on AnalystPC, go to “Desktop” tab, then “IP Configuration”.
  2. Set Static IP:
    • IP Address: 192.168.1.50
    • Subnet Mask: 255.255.255.0
    • Default Gateway: 192.168.1.1
    • DNS Server: (Leave blank)

1.3 Test Connectivity

From AnalystPC’s Command Prompt, try to ping WebSrv01:

ping 192.168.1.10

You should see successful replies. Also, try to ping the Router’s internal IP (192.168.1.1).

Step 2: Simulating the Incident - Malicious Outbound Connection

Now, let’s make WebSrv01 behave suspiciously. We’ll simulate a compromised server trying to connect to an attacker’s C2 server on the Internet. We’ll use a specific external IP and port for this.

Simulated Attacker C2 IP: 172.16.10.100 (a public IP, for example) Simulated C2 Port: 4444 (an uncommon, non-standard port)

From WebSrv01’s Command Prompt:

We’ll use the telnet command to simulate an outbound connection attempt. Even if the telnet connection fails (because there’s no actual server listening at 172.16.10.100:4444), the network traffic will be generated and observable.

telnet 172.16.10.100 4444

Let this run for a few seconds. You’ll likely see “Connecting…” and then “Connection refused” or “Request timed out” – which is perfectly fine for our simulation, as we’re interested in the attempt to connect.

Step 3: Identification - Detecting the Malicious Activity

This is where your network monitoring and analysis skills come into play.

3.1 Conceptual Network Monitoring & Alerts

In a real environment, your Security Information and Event Management (SIEM) system or Network Intrusion Detection System (NIDS) would trigger an alert for “unusual outbound connection from WebSrv01 to 172.16.10.100:4444.” For our simulation, we’ve just generated that traffic, so we know it’s there.

3.2 Packet Analysis (Packet Tracer Simulation Mode)

Packet Tracer has a “Simulation Mode” that allows you to observe packet flow.

  1. Switch to Simulation Mode (the “Play” icon next to “Realtime” at the bottom right).
  2. Click “Edit Filters” and ensure only “TCP” is selected, or “All” for a broader view.
  3. Click “Auto Capture / Play” or “Capture/Forward” repeatedly.
  4. Observe the packets originating from WebSrv01 and heading towards the Router and Cloud.
  5. Click on individual packets and inspect their details. You should see:
    • Source IP: 192.168.1.10 (WebSrv01)
    • Destination IP: 172.16.10.100 (Simulated C2)
    • Source Port: A high ephemeral port (randomly assigned by WebSrv01)
    • Destination Port: 4444 (Our simulated C2 port)
    • Protocol: TCP

This visual confirmation of the suspicious traffic is your “smoking gun” for identification!

3.3 Firewall Log Analysis (Conceptual)

While Packet Tracer’s router CLI doesn’t provide a full-fledged show firewall logs command like real Cisco IOS or Linux firewalls, we can conceptually understand what we’d look for.

In a real scenario, you’d check your router or firewall logs (show logging on Cisco, journalctl -u nftables or dmesg on Linux with nftables/iptables logging enabled, or Windows Event Viewer for Windows Firewall). You’d filter for:

  • Denied connections (if a default deny rule is in place).
  • Allowed connections (if logging of allowed traffic is enabled), specifically looking for the 192.168.1.10 to 172.16.10.100:4444 pattern.
  • Unusual port numbers and external IPs.

The presence of these log entries would confirm the malicious activity.

Step 4: Containment - Blocking the Malicious Traffic

Now that we’ve identified the threat, our next step is to contain it by blocking the suspicious outbound connection from WebSrv01 at the router’s firewall.

4.1 Create an Access Control List (ACL)

We’ll use a standard Cisco ACL to deny the specific traffic. We need to create an ACL that matches traffic from WebSrv01 to 172.16.10.100 on port 4444.

From Router’s CLI:

Router>enable
Router#configure terminal
Router(config)#access-list 101 deny tcp host 192.168.1.10 host 172.16.10.100 eq 4444
Router(config)#access-list 101 permit ip any any
Router(config)#exit

Explanation:

  • access-list 101 deny tcp host 192.168.1.10 host 172.16.10.100 eq 4444: This is the crucial rule. It says: “For ACL 101, deny (block) tcp traffic from the specific host 192.168.1.10 (our WebSrv01) to the specific host 172.16.10.100 (the C2 server) on destination port 4444.”
  • access-list 101 permit ip any any: This is the implicit “allow all other traffic” rule. Remember: ACLs have an implicit deny any any at the end. Without this permit statement, all other legitimate traffic would be blocked!

4.2 Apply the ACL to an Interface

We need to apply this ACL to the router interface where the traffic leaves our internal network towards the Internet. This is the GigabitEthernet0/0/1 interface, but we apply it as an outbound filter, meaning it checks traffic leaving this interface.

From Router’s CLI:

Router(config)#interface GigabitEthernet0/0/1
Router(config-if)#ip access-group 101 out
Router(config-if)#exit
Router(config)#exit
Router#copy running-config startup-config

Explanation:

  • ip access-group 101 out: This applies ACL 101 to the GigabitEthernet0/0/1 interface, specifically for traffic going out of the interface. This ensures that WebSrv01’s malicious traffic is checked before it leaves our network towards the Internet.

4.3 Verify Containment

Now, let’s re-run the malicious activity and observe.

From WebSrv01’s Command Prompt:

telnet 172.16.10.100 4444

This time, you should notice that the connection attempt fails much faster, or you might see a “Connection timed out” without the initial “Connecting…” delay, indicating the router blocked it.

Switch to Packet Tracer’s Simulation Mode:

  • Clear any previous events.
  • Run the telnet command from WebSrv01 again.
  • Observe the packets. You should see them generated by WebSrv01, reach the Switch, then the Router. When they hit the Router, they should be dropped by the ACL. You might see a small ‘X’ icon over the packet when it reaches the router, indicating it was discarded.

This confirms that your containment measure (the firewall rule) is working!

Step 5: Eradication & Recovery (Conceptual)

In a real incident, after containment, you would:

  • Eradicate: Determine how WebSrv01 was compromised (e.g., outdated software, weak credentials, phishing). Clean the system, remove malware, patch vulnerabilities.
  • Recovery: Restore WebSrv01 to a clean state, possibly from a known good backup, and bring it back online.

These steps are complex and beyond the scope of a basic Packet Tracer simulation, but they are critical phases of IR.

Step 6: Post-Incident Activity (Lessons Learned)

Finally, you would document everything:

  • What happened?
  • How was it detected?
  • What actions were taken?
  • What worked well?
  • What could be improved?
  • Are there any new firewall rules or monitoring alerts needed?

This feedback loop strengthens your organization’s overall security posture.

Mini-Challenge: Refine Your Containment

Great job containing the initial threat! Now, let’s refine your skills.

Challenge: Instead of blocking all TCP traffic from WebSrv01 to 172.16.10.100 on port 4444, modify the ACL to block only the specific port 4444 for TCP. Then, imagine the attacker switches to using port 8080. How would you adapt your firewall rule to block the new threat without affecting legitimate web traffic on standard HTTP/HTTPS ports (80/443)?

Hint: Think about how you defined the deny rule in the ACL. Can you create multiple deny rules for different ports, while still allowing everything else? Remember the order of ACL rules matters!

What to Observe/Learn:

  • How specific can you make your firewall rules?
  • The importance of adapting quickly to changing threat tactics.
  • The sequential processing of ACL rules.

Common Pitfalls & Troubleshooting

  1. ACL Order Matters!

    • Pitfall: Placing a broad permit ip any any rule before your specific deny rule. If you do this, the permit rule will match all traffic, and your deny rule will never be hit.
    • Troubleshooting: Always place specific deny rules before broader permit rules. Use show access-lists 101 (or your ACL number) to inspect the order.

  2. Incorrect Interface/Direction:

    • Pitfall: Applying the ACL to the wrong interface or in the wrong direction (in instead of out, or vice-versa).
    • Troubleshooting: Carefully consider where the traffic you want to block originates and where it’s headed. ip access-group [ACL_NUMBER] out is typically used on the interface leaving your internal network to filter outbound traffic. ip access-group [ACL_NUMBER] in would filter traffic entering the interface.

  3. Forgetting the permit any any:

    • Pitfall: Creating a deny rule and forgetting to add a permit ip any any at the end of the ACL. This will result in all other traffic being implicitly denied, effectively shutting down your network!
    • Troubleshooting: If your network suddenly stops working after applying an ACL, check if you’ve included a permit statement for legitimate traffic.

Summary

Congratulations! You’ve successfully completed an incident response simulation, applying a wealth of knowledge from previous chapters. Here are the key takeaways:

  • Incident Response Lifecycle: You’re now familiar with the NIST phases: Preparation, Identification, Containment, Eradication, Recovery, and Post-Incident Activity.
  • Practical Application: You’ve seen how concepts like IP addressing, subnets, and firewalls come together in a real-world cybersecurity scenario.
  • Identification Skills: You practiced identifying suspicious network traffic using Packet Tracer’s simulation mode and learned what to look for in conceptual firewall logs.
  • Containment Expertise: You successfully implemented a firewall rule on a router to block malicious outbound connections, demonstrating effective containment.
  • Troubleshooting: You’ve gained insight into common firewall configuration pitfalls and how to debug them.

This project-based chapter empowers you with a foundational understanding of how to approach and handle cyber incidents, a critical skill for any aspiring cybersecurity professional.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.