It can be instructive to closely examine even completely usual-looking phishing messages from time to time, since they may lead one to unusual phishing sites[1] or may perhaps use some novel technique that might not be obvious at first glance[2].

One such “uninteresting at first, yet interesting in the end” message was forwarded to me by a colleague of mine over the weekend. 

Besides the e-mail headers showing that the sender address was spoofed and that the message actually originated from a server in the AWS, there was nothing noteworthy about the e-mail itself.

...
Received: from [redacted].ddfree.live ([46.[redacted].25])
  by [redacted] with ESMTP; 20 Nov 2021 10:03:23 +0100
Received: from ec2-3-[redacted]-71.us-east-2.compute.amazonaws.com ([3.[redacted].71] helo=EC2AMAZ-PSCS0RU) 
	by server.ddfree.live with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.93)
	(envelope-from <[redacted]@hotmail.com>)
	id 1mnAfp-0007D6-GT
	for [redacted]@alef.com; Tue, 16 Nov 2021 21:27:45 -0500
...

It contained only a single personalized link…

hxxps://connect[.]vantrodx[.]com/?gcx=recipient@domain.tld

…which, when accessed, would result in the browser being redirected to a dynamically generated URL on the domain connectztc[.]webredirect[.]org, where the actual phishing page resided.

At first glance, the phishing site appeared to be just as uninteresting and run-of-the-mill as the phishing message. It contained a low-quality attempt at an Outlook login page that displayed the e-mail address, which was contained in the initial link, as part of its body.

Since it is generally not advisable to use real e-mail addresses when one interacts with phishing sites, I usually use something generic that satisfies any potential regex checks of e-mail address structure that a phishing site might perform, but can nevertheless be interpreted as a simple message should the operators of the phishing site check the database of login attempts manually at some later time...

If a victim filled in a password and clicked the Sign In button, credentials would be sent to the server using a HTTP POST request and verified.

POST /ftAoH25E9I92bORGAISC619b5e68a0bc1/o3vrvy5ml15ed5a394876a1?s=def502004d6[truncated] HTTP/1.1
Host: connectztc.webredirect.org
...

user=goto%40hell.tld&u2=goto%40hell.tld&pass=123456

Should the credentials be incorrect, the website would display an error message and give the user another chance to input the right password. So far, there was nothing out of the ordinary...

The site turned out to be interesting, however, when I attempted to access it again using the same initial link sometime later from a different public IP address. Instead of the Outlook login screen, only a 404-error page was displayed.

One might have reasonably expected at that point that the phishing site has been taken down. However, this did not turn out to be the case, since when I changed the e-mail address in the initial link, the login page was displayed correctly once again.

Based on this and further testing, it seems that there was some mechanism on the server, which logged the public IP address from which any link with specific e-mail address was first opened, and which would check whether the IP was the same before allowing any subsequent access using the same link.

If one were to access the site from the same public IP twice using the same link (independent of cookies, browser used, or any other factors), the login page would load correctly both times. But if the same link was opened from two different public IPs, the server would serve a 404 page to the second request instead of the login page.

My assumption is that this dynamically adjusted allow-listing was an attempt at a very simple protection mechanism for the phishing page. In cases when someone would click on a phishing link and afterwards reported it to their IT or security team, it is not unimaginable that a member of such team might try to open the same initial link without changing the e-mail address and that their internet traffic might originate from a different public IP than did the traffic of the person who reported the phishing. Since the investigator would be greeted with a 404, they could then easily come to the conclusion that the website has already been taken down and would therefore not pursue any further actions in connection with it.

Although this approach could hardly hide a phishing site from any more in-depth investigation, it might be effective in some cases. And since I’ve never come across it before and it seemed quite novel, I thought it might warrant at least this short mention. If nothing else, it provides a good illustration of why it is unwise to use unmodified phishing links that contain e-mail addresses during analysis and it goes to show that when one finds a 404 page where a phishing site used to be, it might not necessarily be the end of the story.

If you’d like to take a closer look at the phishing site described above yourself, you may, since at the time of writing it is still up...perhaps in part thanks to its protection mechanism.

[1] https://isc.sans.edu/forums/diary/Slightly+broken+overlay+phishing/26586/
[2] https://isc.sans.edu/forums/diary/Broken+phishing+accidentally+exploiting+Outlook+zeroday/26254/

-----------
Jan Kopriva
@jk0pr
Alef Nula