Introduction & Concept
Let’s capture, inspect, and analyse Wireshark data using ChatGPT’s free version. ChatGPT will act as an interpreter of my Wireshark captures, decoding and presenting the data in a readable format, often with tables, summaries and even visual diagrams.
ChatGPT will allow us network administrators to save time not having to process tedious, infinite lines of code. By inputting prompts or queries directly in ChatGPT, we can ask targeted questions about our network data and support troubleshooting.
As you can imagine, I’ve kept the traffic capture as simple as possible to avoid revealing too much about my existing network, so focusing only on Google searches and generating Microsoft 365/Azure traffic.
Let’s get started!
This article is the first instalment in a series examining how AI tools can complement Wireshark to enhance the way network engineers capture, inspect, and analyse network traffic.
Part Two - Microsoft Copilot Network Analysis with Wireshark
Step One
From the Wireshark Interface, Select the NIC you want to capture traffic from.

Step Two
Start Capturing Traffic, by selecting Capture/Start.
Keep the capture file to about 500 packets for best results.

Step Three
Pause the Traffic Capture by selecting Capture/Stop and File/Export traffic and save PCAP file as .CSV file.
This is the format supported by the free version of ChatGPT as the PCAP file version doesn’t work.

Step Four
Login to ChatGPT and upload the .CSV file, or you could simply copy and paste the .CSV contents into ChatGPT.

Step Five
Now that the .CSV file is uploaded we going to use the following tried and tested “prompts” in ChatGPT to query the Wireshark Capture. Again, be creative and use prompts that are applicable to your network context.
A range of example prompts, and their outputs, will be given below.
Example Prompts
- 1) Generate a table of all destination IPs by count
- 2) Extract HTTP/HTTPS URLs and hostnames from this capture
- 3) Produce a table mapping each hostname to the IP addresses
- 4) List the Azure services
- 6) Create simplified diagram showing application traffic flows
Each of these prompts can be used individually to generate a range of responses from the AI interface.
Sample outputs for each of these are shown below.
1) Generate a table of all destination IPs by count
| Destination IP | Packet Count | Notes / Service |
| 104.18.41.41 | ninety (≈90) | Cloudflare edge, mostly UDP/QUIC |
| 172.217.16.238 | 21 | Google services, QUIC/TLS |
| 142.250.179.227 | 20 | Google services, QUIC |
| 40.99.202.98 | 4 | UDP/HTTPS |
| 142.250.129.132 | 4 | Google services, TCP/QUIC |
| 142.250.187.206 | 4 | Google services, TCP/QUIC |
| 13.107.138.10 | 2 | Microsoft / Azure |
| 20.190.169.25 | 2 | Microsoft / Azure |
| 20.223.35.26 | 1 | Microsoft / Azure |
| 216.239.38.120 | 2 | Google service / DNS? |
| 142.251.29.119 | 2 | Google service |
| 142.250.140.94 | 2 | Google services, TCP/HTTP |
| 185.25.182.20 | 2 | TLS traffic, unknown service |
| 52.108.52.22 | 2 | TLS traffic, unknown service |
| 52.98.224.162 | 2 | TLS traffic, unknown service |
| 40.100.174.2 | 2 | TLS traffic, unknown service |
| 170.72.245.140 | 3 | TLS traffic, unknown service |
| 52.109.32.11 | 3 | TLS traffic, unknown service |
| 192.168.1.254 | 4 | Local DNS server |
| Arcadyan_3e:7f:cb | 1 | Local ARP request |
| Intel_49:ee:a9 | 1 | Local ARP reply |
ChatGPT Observations:
- The dominant traffic is to 104.18.41.41, clearly the main external service.
- Most traffic is to Google and Cloudflare servers.
- Microsoft/Azure IPs appear sporadically.
- Local network traffic (192.168.1.*) is mostly DNS and ARP request.
2) Extract HTTP/HTTPS URLs and hostnames from this capture
- com – standard DNS queries, TLS connections.
- gcp.gvt2.com – Google telemetry/analytics.
- beacons-handoff.gcp.gvt2.com – CNAME for telemetry.
- Multiple Google/YouTube IPs (resolved via DNS):
- 217.16.238
- 250.179.227
- 250.129.132
- 250.187.206
- Cloudflare IP 104.18.41.41 – likely HTTPS/QUIC connection to a Cloudflare-protected site.
- Microsoft/Azure endpoints (from RST/TLS packets):
-
- 99.202.98
- 107.138.10
- 190.169.25
- 223.35.26
- Additional TLS endpoints / CDNs:
- 108.52.22
- 98.224.162
- 25.182.20
- 72.245.140
Notes:
- Full URLs are not visible because QUIC/TLS encrypts HTTP headers and paths. Only hostnames are exposed in:
- DNS queries
- TLS SNI (Server Name Indication)
- The majority of traffic is QUIC over UDP (port 443) or TLS over TCP (port 443), so the sites are encrypted.
3) Produce a table, mapping each hostname to the IP addresses
| Hostname / Domain | IP Addresses Observed in Capture |
| google.com | 172.217.16.238 |
| beacons.gcp.gvt2.com | 142.250.179.227 |
| beacons-handoff.gcp.gvt2.com | 142.250.179.227 |
| Cloudflare-protected site | 104.18.41.41 |
| Microsoft/Azure | 40.99.202.98, 13.107.138.10, 20.190.169.25, 20.223.35.26 |
| Google CDN / Services | 142.250.129.132, 142.250.187.206 |
| Other TLS endpoints | 185.25.182.20, 170.72.245.140 |
Notes:
- Multiple IPs may belong to the same hostname due to load balancing/CDNs (Content Delivery Network)
- Full URLs are not visible because QUIC/TLS encrypts HTTP paths. Only hostnames and DNS queries are observable.
4) Group IPs by service type
| Service Type | Hostnames / Domains | IP Addresses Observed |
| Google / YouTube | google.com | 172.217.16.238 |
| Google / YouTube | beacons.gcp.gvt2.com | 142.250.179.227 |
| Google / YouTube | beacons-handoff.gcp.gvt2.com | 142.250.179.227 |
| Google / YouTube | Google CDN / Services | 142.250.129.132, 142.250.187.206 |
| Cloudflare | Cloudflare-protected site | 104.18.41.41 |
| Microsoft / Azure | Microsoft endpoints | 40.99.202.98, 13.107.138.10, 20.190.169.25, 20.223.35.26 |
| Other / Unknown | Other TLS endpoints | 185.25.182.20, 170.72.245.140 |
Observations:
- Most of your traffic is to Google services, with both QUIC and TLS connections.
- Cloudflare traffic likely indicates visiting a site behind their CDN (Content Delivery Network)
- Microsoft/Azure IPs appear via TCP resets and TLS traffic - likely Microsoft services or telemetry.
5) List the Azure services
| IP Address | Observed Protocol / Traffic Type | Likely Azure Service / Function |
| 40.99.202.98 | UDP 443 (QUIC / HTTPS), TCP RST | Possibly Azure Front Door or CDN endpoint |
| 13.107.138.10 | TCP 443 RST | Likely Microsoft 365 / Office 365 endpoint |
| 20.190.169.25 | TCP 443 RST | Azure App Services or Azure Front Door |
| 20.223.35.26 | TCP 443 RST | Azure App Services or Azure CDN |
Notes / Observations:
- The repeated RST packets suggest connection resets, which are common with cloud service endpoints when probing, health checks, or load-balancing.
- These IPs are consistent with Microsoft Azure and Microsoft 365 front-end services, including CDN and web apps.
- Exact service mapping is not always possible from raw IPs alone, as Azure uses large ranges for multiple tenants.
6) Create simplified diagram showing application traffic flows

Conclusion
The initial ChatGPT draft I started with seemed to generate way too much superfluous data, however the more I refined my prompts with further instructions, the more precise and accurate the data e.g. never include the word “all” in your prompts.
Saying that, I was interested in how ChatGPT provided clear instructions on parsing different network data at different stages in the analysis, including when a diagram or table suited the query.
ChatGPT also allowed me to share content throughout the analysis, which reduced manual formatting in Word, Excel and similar tools.
Final thought, ChatGPT can support existing network analysis by parsing and presenting data in a more accessible format for review. I can’t wait when network tools start developing Generative APIs that can integrate directly into ChatGPT so there’s no need to upload the content, but rather just query the network tool directly from ChatGPT.
Bonus Content
- Content Delivery
-
- Purpose: Serve static content (images, scripts, CSS, HTML) from a location close to the user.
- Benefit: Reduces latency, speeds up web page load times.
- DDoS Protection
-
- Purpose: Absorb and filter large-scale attacks at the network edge.
- Benefit: Keeps websites online even under attack by stopping malicious traffic before it reaches the origin server.
- Web Application Firewall (WAF)
-
- Purpose: Inspect traffic for malicious patterns, like SQL injection or cross-site scripting.
- Benefit: Protects the application from common web attacks.
Feedback & Further Discussion
This article is part of a three part series on WireShark Analysis with AI Tools, Part Two (Copilot) and Part Three (Gemini) are also available. This article was written by our Senior Collaboration Architect, Dylan James. If you'd like to reach out to Dylan to discuss the article or any similar concepts, he'd be happy to hear from you. Please reach out to us via our contact page and we'll get you in touch with him.
