HTTP

Overview

In this lab, I explored the intricacies of the HTTP protocol while gaining practical experience with network traffic analysis and intrusion detection systems (IDS), specifically Snort. The goal was to extract and analyze HTTP traffic captured from a live network segment, then prepare the data for further inspection using IDS tools.

Objectives

The lab focused on:

• Deepening understanding of the HTTP protocol and how it manifests in raw packet data.
• Practicing the use of IDS rule sets related to HTTP activity.
• Preparing packet captures for detection and analysis using Snort.

1) Using the analyze tool on the course VM, extract all HTTP traffic observed by the dmz sensor on TCP port 80 during the time range from 05/02/19 09:00:00 to 05/02/19 11:00:00. Save the extracted data to a file named http_extract.pcap.

Place this file in the directory /sec503/Exercises/Day3
This will ensure it is accessible for use with Snort or Suricata in the upcoming exercises.

2) Review the extracted packets using Wireshark and answer the following questions about the capture:

– Reassemble the session between host 192.168.61.20 and host 134.170.104.154. What version of HTTP is in use? What kind of request is sent? How does the server respond? What kind of server does it appear to be?

We see that HTTP version 1.1 is in use. The client is sending an HTTP POST request to the server meaning it is sending data to the server, likely for uploading. The body of the request contains 1324 bytes of data. The target host for this request is ssw.live.com.

The server HTTP response is a successful 200 ok response. The server acknowledged and successfully processed the request but did not return any content. This is typical for many upload or form submission responses that only need to confirm success without sending data back. The webserver is a Microsoft-IIS/7.5.

3) Create a Snort Rule that can detect a possible indicator of data exfiltration using one or more Snort Http rule options.

– What in the URL might indicate a potential exfiltration attempt ?

The URL in question is /UploadData.aspx. Even though it’s not definitive proof, seeing the word “Upload” in the URL is a strong clue that the client may be sending data to the server—something often associated with exfiltration.

-why is it better to scan for this term in the url instead of the full request or response body?

Urls are generally short and follow predictable patterns, making them much easier and faster to scan for keywords like “upload”. searching the full session payload for this term could be very inefficient, especially since we wouldn’t know where to start looking.

– create a snort or rule in your local.rules file under /sec503/exercises/day3 that looks for the word “upload” in a url. confirm that your rule successfully detects the activity.

Let’s verify if this alert works properly:

Bingo