Finding the PAC file – with WireShark

I’ve been a diehard netmon user for many many years. Windows 10 has been telling me it is not supported for a year. I’m comfortable and spoiled with netmon because I know how to do the things that have meaning to me.I’ve been trying to Message Analyzer, and Wireshark; weaning off of netmon. What ever format customers send me a capture in is the tool I use to read them lately.

One of the slam dunk eash tasks in netmon is finding and reading a customers proxy.pac file. I say Spoiled, because netmon has a precanned standard filter called “isolate proxy traffic” –  Wireshark has a page of filters 3 miles long and searching for pac, wpad, proxy, ETC turned up zero results making me swoon.

Queue Pink FunHouse and away we go on a mission to build the proxy isolation thing in netmon in wireshark.


Netmon Built in “Standard Filter” called “Isolate Proxy Traffic”- Spoiled

Searching the webs

Why build a wheel when you can “borrow” it from someone else. My quest started on the internets searching the tubes for things like:

  • “isolate proxy traffic WireShark filter”
  • “filter pac proxy wpad wireshark”
  • “isolate proxy.pac file wireshark filter”

I used both bing and google and came back with nothing close to what I wanted. I checked out the wireshark forums, Wireshark wiki and support pages and still nothing – Mutter, Kev will not be beaten.

Building the filter

Search failed me. Guess I’ll have to actually do some work and figure this out on my own. Luckily I have two things to work from. One – The filter in Netmon provides the basic bits, Two – A folder on my machine called captures filled with 100’s of packet captures I know have proxy.pac files in them. Yes I am a digital pack rat. Armed with hints and test subjects I set off to write some filters.

Looking at DNS

Netmon looked for DNS queries with WPAD in the query string. Makes sense, clients need to be able to find proxy servers, and wpad is a good common FQDN for a proxy server. It was also the top of query list netmon used. Yes, I started at the top. – DNS query for WPAD in Wireshark comes back with results, but they are not going quickly yield a proxy file. The filter  looks like – contains “wpad”

Looking at the Content-Type

My next move was to find a proxy.pac file packet in netmon, open it and look for something simple to search for. The first three captures with proxy.pac files in them appeared to all have an HTTP content-type with x-ns-proxy in them. The Netmon capture has  x-ns-proxy as a search in; Timy, we might be onto something.  Copied both of the content type filters from netmon into Wireshark and a wrote contains filter with an OR, and BAM – proxy.pac file. Even better, only one packet in the results for the query.

http.response.line contains “x-ns-proxy” or http.response.line contains  “x-ws-proxy”


PII redacted single packet response to x-ns-proxy filter

WireShark Follow Stream

A few weeks ago a customer dropped a netmon capture on us with an insane proxy.pac file. I’m talking a 4,000+ line pac file filled with If, then, else blocks that took market board time to workout. Most companies pac file is ~30 lines and fits in a single packet. Wireshark has a feature I consider the cat’s meow. Follow TCP stream. With this customer I found the pac file in netmon, then opened the capture in wireshark. Located the first packet based on packet number in netmon. Right clicked the packet and picked follow TCP stream – Wireshark opens up all of the packets in the steam then assembles the contents in a text box, it’s so sexy. – in netmon building that huge proxy file one packet at a time by hand would have taken me an hour.


PII redacted screen shot of the proxy.pac file I found

Note – I spelled wireshark wireshare 96% of the time while drafting this post. I might not be able to spell at all, but at least I don’t spell consistently?


Leave a Reply