Outlook phishlet missing correct domain? (goproxy related "Cannot write TLS response body from mitm'd client")

[HachimanSec]

Hi,

I just tried out the latest version (2.3.0) of evilginx2 and played with outlook and o365 phishlets.

Strangely both fail, I assume because a domain is missing in the yaml (I am not really sure about this yet, as I just have to work my head around the config files).

When I open a browser, I see the login and password screens just as expected. However when I click on the submit of the password, I receive an error from Microsoft:

request-id 7d3deb1f-d842-4d91-b45e-833d6510c12e
X-Auth-Error Microsoft.Exchange.Clients.Security.MSSPErrorException
X-OWA-Version 15.20.1709.16
X-FEServer AM0PR05CA0071
X-BEServer AM0P195MB0276
Date:20/03/2019 21:40:05

Any ideas if the yaml needs to be adjusted?

At the same time the console gives continuous TLS errors
2019/03/20 21:39:55 [121] WARN: Cannot handshake client outlook.live.com remote error: tls: unknown certificate
2019/03/20 21:39:55 [124] WARN: Cannot handshake client login.live.com remote error: tls: unknown certificate

[kgretzky]

Please try to use the latest 2.3.1 version from master branch and see if it fails the same way.

[HachimanSec]

Thanks Kuba. Will do so later today!

[HachimanSec]

PS: Maybe something to add. I am working on a Docker environment for training of some NGOs and journalists, combining Evilginx with GoPhish etc.

Can this problem be somewhat related to a Dockerized environment?

[HachimanSec]

I got the latest version 2.3.1

The config is the following for O365 (TLS handshake errors still appear)

: lures edit redirect_url 0 https://www.office.com
[15:36:48] [inf] redirect_url = 'https://www.office.com'

: lures get-url 0

https://login.o365.my.<domain>.rocks/VAmKAUBZ

: lures 0

     phishlet : o365
         path : /VAmKAUBZ
 redirect_url : https://www.office.com
         info :
     og_title :
      og_desc :
     og_image :
       og_url :

: 2019/03/21 15:36:57 [057] WARN: Cannot handshake client login.microsoftonline.com remote error: tls: unknown certificate
2019/03/21 15:36:58 [060] WARN: Cannot handshake client www.office.com remote error: tls: unknown certificate
2019/03/21 15:37:02 [063] WARN: Cannot handshake client login.microsoftonline.com remote error: tls: unknown certificate

I receive the following error by MS (this also happens when I change the redirect_url to www.office365.com)

[HachimanSec]

I setup the outlook Phishlet with similar problems:

2019/03/21 15:48:31 [004] WARN: Cannot handshake client outlook.live.com remote error: tls: unknown certificate
2019/03/21 15:48:32 [006] WARN: Cannot write TLS response body from mitm'd client: write tcp 172.17.0.0:443-><MyIP>:53317: write: connection reset by peer

What I just noticed, by using different accounts, entering username and password works (even getting logged by Evilginx2). However after clicking on submit for the password, the error appears right away and I dont see the screen for the second factor OTP.

Is it possible that this is related to docker?
What I see in Evilginx is that I receive a broken pipe and the source IP is the docker IP of my DigitalOcean host:
2019/03/21 16:02:35 [041] WARN: Cannot write TLS response body from mitm'd client: write tcp 172.17.0.2:443-><MyIP>:53584: write: broken pipe

However I explicitly expose the ports to my public IP
docker run -it --privileged --entrypoint /bin/sh -p 165.227.x.x:80:80 -p 165.227.x.x:443:443 -p 165.227.x.x:53:53/udp evilginx2:0.1

The config is:

phishlets hostname outlook outlook.my.<domain>.rocks
[15:44:39] [inf] phishlet 'outlook' hostname set to: outlook.my.<domain>.rocks
[15:44:39] [inf] disabled phishlet 'outlook'
: phishlets enable outlook
[15:44:39] [inf] enabled phishlet 'outlook'
[15:44:39] [inf] developer mode is on - will use self-signed SSL/TLS certificates for phishlet 'outlook'
:
: lures create outlook
[15:44:53] [inf] created lure with ID: 1
: lures 1

     phishlet : outlook
         path : /FuXQdMXb
 redirect_url :
         info :
     og_title :
      og_desc :
     og_image :
       og_url :

: lures get-url 1
https://outlook.outlook.my.<domain>.rocks/FuXQdMXb

[HachimanSec]

Hi Kuba,

I just tried it on a local Kali box and there it works.
Strangely I see similar issues related to broken pipes:

: 2019/03/21 17:23:06 [048] WARN: Cannot write TLS response header from mitm'd client: write tcp 192.168.1.6:443->192.168.1.6:60688: write: broken pipe
2019/03/21 17:23:07 [050] WARN: Cannot write TLS response header from mitm'd client: write tcp 192.168.1.6:443->192.168.1.6:60690: write: broken pipe
2019/03/21 17:23:08 [058] WARN: Cannot write TLS response header from mitm'd client: write tcp 192.168.1.6:443->192.168.1.6:60704: write: broken pipe

However I dont see the
2019/03/21 16:02:34 [029] WARN: Cannot handshake client outlook.live.com remote error: tls: unknown certificate warnings.

Could it be that the alpine docker image is causing that problem?
And can the broken pipe errors be ignored?

EDIT:
I also checked the default Dockerfile you provide which is not Alpine based. I receive the same errors about TLS handshake and broken pipes

2019/03/21 16:36:30 [034] WARN: Cannot write TLS response body from mitm'd client: write tcp 172.17.x.x:443-><MyIP>:54182: write: broken pipe
2019/03/21 16:36:31 [041] WARN: Cannot handshake client outlook.live.com remote error: tls: unknown certificate

It displays the username and password screen but break on the OTP one

EDIT2:
The error seems to originate from the go proxy package, I am just not sure where and why exactly 😄

chunked := newChunkedWriter(rawClientTls)
				if _, err := io.Copy(chunked, resp.Body); err != nil {
					ctx.Warnf("Cannot write TLS response body from mitm'd client: %v", err)
					return
				}

GitHub goproxy

EDIT3:
Found a similar issue here:
Mitm'ed HTTPS responses are not automatically deflated #9

A test from inside the container via curl seems to work:

/app # curl -Ikv https://outlook.live.com
* Expire in 0 ms for 6 (transfer 0x55e1e3c90620)
* Expire in 1 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 2 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 2 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 2 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 2 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 0 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 2 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 1 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 1 ms for 1 (transfer 0x55e1e3c90620)
* Expire in 1 ms for 1 (transfer 0x55e1e3c90620)
*   Trying 13.107.42.11...
* TCP_NODELAY set
* Expire in 149998 ms for 3 (transfer 0x55e1e3c90620)
* Expire in 200 ms for 4 (transfer 0x55e1e3c90620)
* Connected to outlook.live.com (13.107.42.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; CN=Outlook.live.com
*  start date: Oct  2 00:00:00 2018 GMT
*  expire date: Oct  2 12:00:00 2020 GMT
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Cloud Services CA-1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e1e3c90620)
> HEAD / HTTP/2
> Host: outlook.live.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 302
HTTP/2 302
< cache-control: no-cache
cache-control: no-cache
< pragma: no-cache
pragma: no-cache
< content-length: 0
content-length: 0
< location: https://outlook.live.com/owa/
location: https://outlook.live.com/owa/
< request-id: 7714953d-8b83-4f4f-bc1e-103c8d5139fd
request-id: 7714953d-8b83-4f4f-bc1e-103c8d5139fd
< x-feserver: AM4PR0902CA0008
x-feserver: AM4PR0902CA0008
< x-requestid: 8b216cd8-f1fe-47e4-b265-50ef089fb99b
x-requestid: 8b216cd8-f1fe-47e4-b265-50ef089fb99b
< strict-transport-security: max-age=31536000
strict-transport-security: max-age=31536000
< x-powered-by: ASP.NET
x-powered-by: ASP.NET
< x-feserver: AM4PR0902CA0008
x-feserver: AM4PR0902CA0008
< x-msedge-ref: Ref A: FD15C6BF4AE24CD290DECD199A953050 Ref B: FRAEDGE0714 Ref C: 2019-03-21T16:27:58Z
x-msedge-ref: Ref A: FD15C6BF4AE24CD290DECD199A953050 Ref B: FRAEDGE0714 Ref C: 2019-03-21T16:27:58Z
< date: Thu, 21 Mar 2019 16:27:58 GMT
date: Thu, 21 Mar 2019 16:27:58 GMT

<
* Connection #0 to host outlook.live.com left intact

Best
Tom

[kgretzky]

Wow. Thanks for all this information. I will try to look into it as it is indeed strange.
I've never experienced this behavior before.

[HachimanSec]

Sure, I try to learn something from this and make it, hopefully, a bit easier for you ;)
Let me know if there is something I can test.

I also attach my modified Dockerfile FYI

FROM golang:alpine AS build

MAINTAINER HachimanSec

ENV SRC_DIR $GOPATH/src/github.com/kgretzky

RUN apk add --update ca-certificates && \
  apk add --no-cache --update git bash build-base && \
  rm -rf /var/cache/apk/*

WORKDIR $SRC_DIR

RUN git clone https://github.com/kgretzky/evilginx2 evilginx2

WORKDIR $SRC_DIR/evilginx2

RUN make

#final stage
FROM alpine AS prod

WORKDIR /app

COPY --from=build /go/src/github.com/kgretzky/evilginx2/phishlets ./phishlets/
COPY --from=build /go/src/github.com/kgretzky/evilginx2/bin .

RUN apk add ca-certificates

VOLUME ["/app/phishlets/"]

VOLUME ["/root/.evilginx/crt/"]

EXPOSE 443 80 53/udp

ENTRYPOINT ["/app/evilginx"]

[kgretzky]

I noticed this line:

[15:44:39] [inf] developer mode is on - will use self-signed SSL/TLS certificates for phishlet 'outlook'

Are you running Evilginx with developer flag? This will only use self-signed certificates which will result in TLS errors.

[HachimanSec]

Actually both. I tried it with developer and with the LetsEncrypt certs.

What I noticed is the difference in the missing line:
2019/03/21 16:36:31 [041] WARN: Cannot handshake client outlook.live.com remote error: tls: unknown certificate
This one appears on the Docker version with --developer but not on my Kali box, also with --developer.

I assume the TLS errors originate exactly because of what you mentioned, the self signed certs. To verify this I will run it with LetsEncrypt again.

Any idea why there is the handshake error with unknown tls certificate?
I dont get why this fails. The docker container is capable of reaching the host outlook.live.com, as tested with curl.
In kali the same compiled version of Evilginx2 works

[HachimanSec]

Hey @kgretzky
I just tried it again with the "official" Letsencrypt certs.
Just as you said, the TLS error is gone.

However the redirect error still exists. Interestingly enough, the login page for the username and the second page for the password works. Username and password is captured too.

The third page is then broken.

I tried it with two different users, one with OTP enable and one without.
In both cases the behaviour is the same, the first two pages work and third one breaks. Whether the third page is supposed to be the OTP page or the final inbox page.

[HachimanSec]

Hi @kgretzky
a quick update. I rebuild the whole docker image with the default settings from GitHub. Unfortunately no change.

Something I noticed during testing, and maybe that's helpful.
Before the error page, I see a the username a second time. Seems kinda strange to me. Could this be a rerouting issue or something?

21:19:52] [imp] [0] [outlook] new visitor has arrived: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15 (217.22.143.24)
[21:19:52] [inf] [0] [outlook] landing URL: https://outlook.ms.my.phishing.rocks/verify
[21:20:08] [+++] [0] Username: [victim@outlook.com]
[21:20:08] [+++] [0] Password: [PASSWORD]
[21:20:08] [+++] [0] Username: [victim@outlook.com]

[kgretzky]

I haven't updated the outlook phishlet for several months now and it is very possible that they did some additional security checks.
It looks that they have finally added the detection of malicious window.location value, which is currently the only way to secure the website against mitm proxying.

You'd need to reverse engineer the javascript they use and replace the security checks with sub_filters.

If you see the error message printed from the web server, it means the certificate works.

[HachimanSec]

I just checked it on my local Kali Linux box. It totally works fine there.
This is truly strange.

Local evilginx2 (2.3.1) - works
Docker evilginx (2.3.1) - OTP screen breaks

This is super strange. What would make evilginx break running inside a container.
Any idea where I could start debugging?

[HachimanSec]

@kgretzky I think I found the problem (even though I am not able to explain it).

I used a DigitalOcean droplet for my tests. To analyse further, I installed evilginx 2.3.1 directly onto the droplet (no docker).
There it displays the very same error page. Hence I conclude that the error is neither related to evilginx nor to docker, but to the way DO droplets work. Even though I totally have no idea what issue that could be...

[StratoMusic]

So were you able to fix this and how? I have only tested with setup in server from onecloud, experiencing the same issue...

[StratoMusic]

@HachimanSec any help with this man? i am still facing this issue, in my local kali and hosting in one cloud.

Please let me know how you fixed

[ghost]

Hi @HachimanSec,

Can you please share your email address?, badly need a little help with outlook yaml.

Thanks

[wilsonfisk77]

Hello,

Any update on this outlook issue ?
i have been facing the same issue for a long time as described by @HachimanSec

Thanks

[TeddyBlue]

anybody made headway on this?

[JaredStemper]

@kgretzky has the issue been resolved?

I am still facing this error when for my tests when installing evilginx 2.4.2 directly onto a DigitalOcean droplet without docker.