A PAC file is JavaScript that every browser on the network fetches and runs to decide where each request goes. It is configuration, not an executable, so it leaves no binary for an endpoint agent to flag — and it can route a handful of named hosts through an attacker while everything else goes direct. Each exercise hands you a captured file to read.
A finance user reports that online banking 'looks normal but asks me to log in twice sometimes'. Everything else on the machine is fast and behaves. Nothing is flagged by the endpoint agent. You retrieve the PAC file the browser is actually using.
Nothing is being proxied — every request in this file returns DIRECT, and the proxy logs are empty. Yet the security team can see a steady trickle of DNS queries from this laptop to a nameserver that is not theirs, each one a long random-looking label. Work out how a PAC file with no proxy in it is leaking anything at all.
This PAC was written to be tedious to read. Ignore the noise and work out which requests actually reach the attacker's proxy, and which parts of the file exist purely to waste your time.
The malicious PAC is gone from the affected workstation. Now decide which of the proposed changes actually remove the class of attack, and which only address the single instance you happened to find.
Alderbrook Financial routes essentially all outbound traffic through a DLP/TLS-inspecting proxy, with one carved-out exception for a certificate-pinned banking API that breaks when inspected. A phishing page impersonating that same bank's SSO portal was reported by a user, and it was never flagged by the inspection gateway's threat-intel feed. Work out why a phishing domain that should have hit the inspecting proxy never did.
Every weekday spot-check of this laptop's PAC file, run during business hours, showed nothing but DIRECT. The PAC only routes traffic through a proxy outside business hours and on weekends, precisely when the executive is most likely to be checking personal banking and webmail from the same machine, and precisely when the SOC's daytime monitoring has no eyes on it.
Windows Update succeeds, internal apps work, and static assets from the CDN load quickly, nothing about the estate looks broken. Yet a threat-intel feed flagged an IP address that dozens of hosts have quietly been talking to for weeks. The PAC everyone fetches looks almost entirely benign at a glance; work out what it is actually doing to nearly everything else.
The PAC file recovered from the user's laptop is suspected in a credential-theft report, but every attempt to reproduce the malicious behavior in the analysis sandbox has returned DIRECT for every request. Work out what the file is checking for before it decides how to behave, and why the sandbox never sees the real version of it.
Whoever built this PAC did not rely on a single proxy. If the primary listed proxy ever goes down, the browser moves on to a second address before finally giving up and going DIRECT, and neither the user nor an uptime check watching only the primary address would ever see an interruption. Explain what that ordering actually buys the operator.
The security team carved out a single-host exception years ago so one legacy build server, whose TLS client cannot tolerate re-terminated certificates, would not have its traffic inspected. Threat intel has now reported a command-and-control address that has never appeared in a single inspection-proxy log, despite dozens of internal hosts reaching it. Work out how a one-host exception ended up covering a command-and-control server it was never meant to touch.