Failure to replace phishing domain in certain edge cases

[ziggoon]

Summary:
Evilginx is not replacing the phishing domain in certain GET requests and Location headers in responses.

While preparing a phishlet for an upcoming engagement I noticed that an ADFS authentication service was complaining about bad requests coming from evilginx, thus failing to initiate the authentication process. After sending the traffic through Burp I saw a request from the evilginx server to the auth service with the phishing domain in one of the URL parameters.

Bad request: GET /api/Account/Login?returnUrl=https%3A%2F%2Fsubdomain.ziggoon.local%2F

I was able to "patch" this with Burp by using an HTTP match and replace rule which replaced "ziggoon.local" in request headers with the target domain. This allowed me to reach the ADFS login page and enter creds, but I was not receiving an MFA prompt. I added my browser to the proxy and checked the Burp logs again and noticed a response from evilginx the had the legitimate domain in the Location header, which was causing the auth flow to break. Again, was able to "patch" this with Burp and I successfully captured creds and tokens in evilginx.

[iliwasel]

How did you manage to get evilginx and burp suite working together?
When configuring the burp suite proxy inside evilginx, whenever a request comes by I get the following error:
Cannot read TLS response from mitm'd server proxyconnect tcp: EOF