Investigating Network Stress in a Virtual Lab: A Blue Team Analysis

Introduction

Understanding how systems behave under increased network activity is an important skill for IT professionals and cybersecurity analysts. While large-scale Denial-of-Service (DoS) attacks require significant resources and infrastructure, even small-scale network stress can provide valuable insights into how operating systems process traffic and how analysts investigate unusual behaviour.

In this lab, I built a controlled Windows-based virtual environment using VirtualBox to observe how a system responds to sustained network traffic. The goal was not to disrupt services, but to investigate how increased traffic appears within monitoring tools and to develop a structured approach to network analysis.

Lab Objectives

The objectives of this investigation were:

• Build an isolated virtual network

• Establish a baseline of normal system behaviour

• Generate controlled network traffic

• Monitor system performance during activity

• Investigate changes in resource utilisation

• Identify the root cause of observed behaviour

• Document findings using a blue-team methodology
  

Lab Environment

The environment consisted of two Windows virtual machines running inside VirtualBox.

Client System

Purpose: Generate network traffic

IP Address: 192.168.10.11

Target System

Purpose: System under investigation

IP Address: 192.168.10.10

Both virtual machines were connected to an isolated internal network named "labnet" to ensure testing remained completely contained.

Configuring Network Connectivity

Static IP addresses were assigned to both systems to simplify communication and troubleshooting.

The client system was configured with the address 192.168.10.11 while the target system was configured with 192.168.10.10.

Connectivity was verified using standard ICMP ping requests.

Establishing a Baseline

Before generating any traffic, I recorded the normal operating state of the target machine.

Task Manager and Resource Monitor were used to establish baseline measurements including:

• CPU utilisation

• Memory usage

• Network activity

• Active network connections
  

At this stage, resource utilisation remained low and there were no signs of abnormal activity.

Simulating Network Stress

To generate a sustained stream of traffic, the client system was configured to continuously send ICMP echo requests to the target system.

This created a predictable flow of network traffic that could be analysed without introducing risk to production systems.

The traffic was allowed to run for approximately ten minutes while monitoring tools remained active on the target machine.

Investigation and Analysis

With traffic generation underway, monitoring tools immediately showed an increase in network activity.

Task Manager Observations

Task Manager displayed increased network utilisation compared to the baseline state. CPU utilisation also showed minor fluctuations as the operating system processed incoming requests.

Resource Monitor Observations

Resource Monitor provided a clearer view of network behaviour.

The increase in traffic corresponded directly with the incoming ICMP requests generated from the client machine. Network throughput increased and activity became visible within the monitoring interface.

Network Statistics

Using the netstat command, I reviewed protocol statistics before and during testing.

The results showed increased ICMP packet counts, confirming that the observed network activity was directly linked to the traffic generated during the simulation.

Root Cause Analysis

What Changed?

Compared to the baseline:

• Network utilisation increased

• ICMP packet counters increased

• Resource Monitor showed sustained network activity

• CPU usage rose slightly as requests were processed

What Caused the Activity?

The root cause was continuous ICMP traffic originating from the client machine.

Each incoming request required processing by the Windows networking stack before a response could be generated.

Why Was There No Service Disruption?

Although traffic levels increased, modern operating systems are designed to handle significant volumes of routine network traffic.

Several factors contributed to system stability:

• The traffic originated from a single source

• Available bandwidth was not exhausted

• System resources remained within normal operating limits

• Windows efficiently processed and responded to requests

Recovery and Validation

After stopping the traffic generation process, network utilisation returned to normal levels.

Monitoring tools confirmed that the system returned to its baseline operating state without requiring any intervention.

This demonstrated that the observed activity was directly linked to the generated traffic rather than an underlying system issue.

Lessons Learned

This investigation demonstrated the importance of establishing a baseline before analysing suspicious activity.

Key takeaways included:

• Network monitoring tools can quickly identify unusual traffic patterns.

• Resource Monitor provides valuable visibility into active network activity.

• Baseline measurements are critical for effective troubleshooting.

• Root cause analysis should focus on evidence gathered throughout the investigation.

• Controlled lab environments provide a safe way to develop investigative skills.
  

Conclusion

This lab provided a practical introduction to network investigation techniques within a controlled environment. By generating and analysing sustained ICMP traffic, I was able to observe how Windows handles increased network activity, collect evidence using built-in monitoring tools, and perform a structured root cause analysis.

While the simulation did not generate enough traffic to impact system availability, it successfully demonstrated how analysts can investigate unusual network behaviour and correlate observations with system metrics. The skills developed during this exercise directly relate to real-world troubleshooting, monitoring, and security analysis scenarios.