A Cybersecurity Learning Moment

While learning web security assessment techniques, I performed a directory enumeration scan using DIRB, a commonly used tool for discovering hidden web content. At first glance, the scan appeared uneventful—no directories or files were found.

However, the real learning moment came from understanding why.

The Test Scenario

The scan was executed against a fictional domain for learning purposes:

dirb http://example-corp.test

DIRB uses a predefined wordlist to request thousands of common directory and file names from a web server and then analyzes the server’s HTTP responses to determine whether those resources exist.

Scan Output (Visual Representation)

📌 This output can be converted into a graphic for blog or LinkedIn posting.

-----------------
DIRB v2.22
By The Dark Raver
-----------------

START_TIME: Thu Jan 29 13:41:39 2026
URL_BASE: http://example-corp.test/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612

---- Scanning URL: http://example-corp.test/ ----
(!) WARNING: NOT_FOUND[] not stable, unable to determine correct URLs {30X}.
    (Try using FineTunning: '-f')

-----------------
END_TIME: Thu Jan 29 13:41:40 2026
DOWNLOADED: 0 - FOUND: 0

What Does This Actually Mean?

At the core of this output is the warning:

“NOT_FOUND[] not stable, unable to determine correct URLs {30X}”

DIRB expects a consistent “Not Found” response (usually HTTP 404) when it requests a non-existent page. This helps the tool distinguish between real and fake paths.

In this case, the server responded with 30X redirect codes (such as 301 or 302) for both valid and invalid URLs.

As a result:

• DIRB could not reliably identify which paths truly existed

• Any potential findings risked being false positives

• The tool correctly reported zero confirmed results

This is not a failure of the tool—it’s a limitation imposed by server-side behavior.

Why Servers Behave This Way

Redirect-heavy configurations are often used to:

• Force traffic to a single landing page

• Enforce HTTPS or canonical domains

• Reduce information leakage

• Improve security posture against reconnaissance

From a defensive security perspective, this behavior can intentionally or unintentionally hinder automated enumeration tools.

Key Cybersecurity Takeaways

• 🛠️ Security tools rely heavily on predictable system behavior

• 🔍 “No results” does not always mean “no risk”

• 🧠 Interpretation matters more than raw output

• 🛡️ Server configuration plays a major role in exposure and visibility

Final Thought

In cybersecurity, understanding tool limitations is just as important as knowing how to run them. Effective security analysis comes from combining technical results with context, reasoning, and awareness of how systems are designed to respond.

Sometimes, the most valuable insight is hidden in a warning message.

Figure 1: HTTP Headers

HTTP Headers

Statement Problem - Understand the operation of HTTP Headers as they pass information between the client and server. 

Approach: Discussion

Tools - Basic understanding of HTTP communication and cURL

Introduction

HTTP headers pass information between client and server. While some headers are used by both requests and responses, some are only used by either requests or responses. These headers can have one or more values appended after the header name and separated by a colon. There are five types of headers. 

Discussion

General headers are used by both HTTP requests and responses. They are used in specific contexts to describe the message and not its contents. Examples include the date (date: Wed, 16 Feb 2025 10:30:44 GMT) that describes the time zone in which the message originated. Another example of a general header is a connection (Connection: close), that dictates if the current network connection should stay alive after the request finishes. The connection header normally has two values including close and keep-alive.

Entity headers are common to requests and responses. They are used to describe the content transferred by the message. They include content-type (text/html), media-type (application or pdf), a boundary that acts as a marker to separate content, content-length (385), and content-encoding (gzip). 

Request headers are used exclusively for requests alone and do not relate in any way to the content of the message. The request headers include host (www.nnnn.co.ke) which specifies the host being queried, user-agent (curl/7.77.0) describes the client requesting resources, referrer (https://www.nnnn.co.ke) points to where the current request is coming from, accept (*/*) that describes the media types that the client can understand and a cookie that contain cookie value pairs in name=value. It also has authorization (basic….) that the server uses to identify the client.

Response headers are used in HTTP responses and do not relate to the content of the message in any way. Common response headers include location, age, server, set cookie (Cookies needed for client identification), and www-authenticate which notifies the client about the type of authentication required to access the required resource. 

Security headers are a type of response headers used to specify the rules and policies to be followed by the browser while accessing the website. They include content-security-policy, strict-transport security and referrer-policy.

HTTP Requests and Responses

Problem Statement - Explore HTTP Communication to decipher the structure and the meaning of HTTP communication.

Approach - Explanation of HTTP 

Tools used - cURL, Basic understanding of web communication

Introduction

HTTP request is made by the client such as cURL or browser, is processed by the server that then sends an http response containing the response code, and likely, the requested resource. An HTTP request contains three main paths including the HTTP method e.g. GET which specifies the type of action to perform, the path to the resource being accessed, and the version of the HTTP in use. See Figure 1.

Figure 2: HTTP Response

To preview full HTTP request and full HTTP response, use cURL. This is useful for writing exploits and penetration tests. To do this, issue curl www.naconek.ke -v where the -v flag prints both the request and the response. the output details can be enhanced by using -vvv to verbose further. See Figure 3 below. 

Figure 3: Full HTTP Request and Response in cURL

Using DevTools to Monitor HTTP Communication

Figure 4: DevTool and HTTP Commnucication

This activity demosnstrate the usefulness of DevTools in monitoring HTTP communications. Using the network tab, DevTools can give more insights into the processes happening behind the scenes when a client requests for a resource from the server. 

Problem Statement - Understand the underlying mechanism of web communication

Approach - Explanation of URL components, HTTP vs. HTTPS, client-server model, and DNS resolution flow.

Tools Used - Web browser, cURL and conceptual understanding of DNS servers.

Introduction

Understanding web requests is critical for any cybersecurity enthusiast to be successful. It focuses on how web applications work. The first focus is on HyperText Transfer Protocol (HTTP). HTTP is an application layer protocol that is used to access the World Wide Web resources. Hypertext stands for texts that contain links to other resources and texts that can reader can understand. Since HTTP communication is client and server, the client requests resources from the server that processes the request and returns the requested resources. The default port for HTTP communication is port 80 and that of HTTPS is port 443. To fully access the web, the user must enter a fully qualified domain name as a Uniform Resource Locator (URL) to reach the desired website. A URL has different specifications including the scheme that describes the protocol being accessed, user information that contains the credentials of the client, a host that contains the resources being requested, a port that defines the way to access the server, a path that points to the location of the requested resource, query string that consists of parameters and value and the fragment (See Figure 1).  It is worth noting that not all of these components are required to access web resources. However, scheme and host are essential to access the resource. 

Figure 2: HTTP Flow

Client URL (cURL)

Client URL is a command-line tool used to send various types of web requests from the command line. When returning responses, cURL does not render and presents it in raw format. Client URL uses various flags for various purposes as seen in Figure 3. 

Figure 3: cURL Flags

To demonstrate that cURL can be used to send requests to the server and recieve responses, I used command-line by issuing the command - $curl 94.237.54.54:42524/download.php on cURL. The server responded with the resource i.e the requested flag. See Figure 4.

Figure 4: Requested Flag

Note: In HTTP, data is transferred in clear-text, giving room for Man-in-the-middle (MiTM) Attacks.

HyperText Transfer Protocol Secure (HTTPs)

HTTPs are a more secure protocol and are used to counter the risks associated with transferring data in clear text seen in HTTP. In this protocol, all communication/data are transmitted in encrypted format, making it difficult for the third party to extract and retrieve the data. When HTTP is transferring data, the data is in plain text and anyone can easily read it. But with HTTPs, the data is encrypted and transferred as Application data, which is transferred as a single encrypted stream, making it difficult for any malicious actor to capture information such as credentials (See Figure 5). HTTPS websites are identified through the https:// scheme. 

Figure 7: cURL for HTTPs

This activity is a comprehensive exploration of web requests, fundamental for cybersecurity. It elucidates the client-server communication model of HTTP and HTTPS, detailing URL components and the crucial DNS resolution process. The security implications of clear-text HTTP versus encrypted HTTPS are highlighted, along with the functionality of cURL for command-line interactions.

In today’s digital age, computer networks are the backbone of businesses, governments, and personal communications. However, with increased connectivity comes the risk of cyber threats and vulnerabilities that can compromise sensitive data, disrupt operations, and lead to financial losses. In this section, we’ll explore common network threats, the vulnerabilities that attackers exploit, and best practices to protect your systems.

Common Computer Network Threats

1. Malware Attacks

Malicious software, or malware, includes viruses, worms, ransomware, and spyware designed to infiltrate systems, steal data, or cause damage.

• Example: Ransomware like WannaCry encrypts files and demands payment for decryption.

2. Phishing & Social Engineering

Cybercriminals trick users into revealing sensitive information (passwords, credit card details) through fake emails or websites.

• Example: An email pretending to be from a bank asking for login credentials.

3. Denial-of-Service (DoS/DDoS) Attacks

Attackers flood a network with excessive traffic, making services unavailable to legitimate users.

• Example: A DDoS attack on a company’s website causing downtime.

4. Man-in-the-Middle (MitM) Attacks

Hackers intercept communication between two parties to steal or alter data.

• Example: Attackers eavesdropping on unsecured Wi-Fi connections.

5. Insider Threats

Employees or contractors with access to sensitive data may intentionally or accidentally cause security breaches.

• Example: A disgruntled employee leaking confidential company files.

Common Network Vulnerabilities

A vulnerability is a weakness in a system that can be exploited by attackers. Some major vulnerabilities include:

1. Unpatched Software

Failing to install security updates leaves systems open to known exploits.

• Solution: Regularly update operating systems and applications.

2. Weak Passwords & Poor Authentication

Simple or reused passwords make it easy for hackers to gain access.

• Solution: Enforce strong passwords and multi-factor authentication (MFA).

3. Misconfigured Firewalls & Security Settings

Improperly set up firewalls or open ports can allow unauthorized access.

• Solution: Regularly audit and tighten security configurations.

4. Lack of Encryption

Unencrypted data (emails, files, network traffic) can be intercepted.

• Solution: Use SSL/TLS for websites and VPNs for secure remote access.

5. Outdated Hardware & Software

Older systems may no longer receive security patches, making them high-risk.

• Solution: Replace outdated hardware and upgrade unsupported software.

How to Protect Your Network

1. Use Firewalls & Intrusion Detection Systems (IDS) – Monitor and block suspicious traffic.

2. Regularly Update & Patch Systems – Fix known security flaws.

3. Train Employees on Cybersecurity – Educate staff on phishing and safe browsing.

4. Implement Strong Access Controls – Use role-based access and MFA.

5. Backup Critical Data – Ensure recovery options in case of ransomware or data loss.

Final Thoughts

Cyber threats are constantly evolving, but understanding common network vulnerabilities and adopting proactive security measures can significantly reduce risks. By staying informed and implementing best practices, businesses and individuals can safeguard their digital assets.

🔹 Have you experienced a network security breach? Share your thoughts in the comments!

📌 Follow my page for more cybersecurity tips and tech insights!

#CyberSecurity #NetworkSecurity #TechBlog #CyberThreats #DataProtection

 Ever wondered how your emails fly across continents or how you stream videos seamlessly? It all boils down to two fundamental networking frameworks: the OSI Model and the TCP/IP Model! Let's break them down. 

The OSI (Open Systems Interconnection) Model is a conceptual framework that standardizes communication functions of a telecommunication or computing system. Think of it as a detailed blueprint with 7 distinct layers, from the physical hardware all the way up to the application software. It's fantastic for understanding the theoretical flow of data!