Intercept and Analyze Encrypted Traffic of a Suspicious Container
A suspicious container image turned up in the corporate container registry.
It is called node-telemetry-agent:2.1, it ships with no documentation, and it keeps making outbound HTTPS calls to destinations on the internet.
You have been asked to analyze it - find out where it connects and to read what it is sending.
The image is already loaded on your workstation, and a copy is running right now as the agent container.
The trouble is that it never logs where it connects, and its traffic is encrypted.
To read that traffic you have a MITM proxy
standing by on the corporate network at proxy.analysis.lab.
It decrypts whatever is routed through it, forwards it on to the real destination, and shows every decrypted request in its MITM Proxy web console and port 8080:
curl http://proxy.analysis.lab:8080
Route the container's outbound traffic through the MITM proxy and get it to record one decrypted request, without changing the container image or rebuilding it.
Treat the node-telemetry-agent:2.1 image as a black box:
recreate the agent container as many times as you need, but run the image as you found it.
Once a request is recorded, open the MITM Proxy tab
(or curl http://proxy.analysis.lab:8080) to see the intercepted plaintext.
Hint 1
Two steps stand between you and the plaintext:
- First, find the host(s) the container connects to - for that you will have to watch what it does on the network.
- Then redirect that host(s) to the MITM proxy for a fresh container.
Hint 2
Every connection begins with a DNS lookup for the host and a TLS handshake, and both carry the host name in plaintext even though the data that follows is encrypted.
The workstation has tcpdump. A capture limited to DNS (port 53) and TLS (port 443) will show the name(s) the agent
container keeps reaching for.
Hint 3
Once you know the host(s), point it at your MITM proxy for the agent container.
Docker's --add-host flag of docker run overrides a single hostname for one container,
exactly as in the plain-HTTP redirect challenge.
Your proxy is proxy.analysis.lab, and you can look up its address with:
getent hosts proxy.analysis.lab
Hint 4
After the redirect, check the container's logs:
docker logs agent
If the connection fails with x509: certificate signed by unknown authority,
the container reaches the proxy but rejects its certificate.
The proxy signs with its own Lab Interception CA, which the container does not trust,
so you will have to make the container trust the proxy's CA.
A program trusts the CA certificates in its system trust store.
On the node-telemetry-agent image that bundle lives at /etc/ssl/certs/ca-certificates.crt.
The proxy's CA certificate is on your workstation at ~/interceptor-ca.crt,
and you can put it into the container's trust store at run time with a read-only bind mount,
without rebuilding the image.
Recreate the container with both the host override and the mounted CA at once:
docker run -v ~/interceptor-ca.crt:/etc/ssl/certs/ca-certificates.crt:ro ...