Apache .htaccess + NGINX Reverse Proxy (O365 phishing attack scenario)

Scenario and context

During a red-team engagement the only initially discovered weakness was a SQL injection vulnerability on a public-facing site of the target, hosted at https://corp.com. This was a classic static website completely separated from the internal corporate network, so even after escalating the SQL injection to remote command execution (RCE) on the Apache host there was:

• No direct access to internal assets
• No in-scope sensitive data in the web application database
• No interesting lateral-movement paths from that server

Instead of discarding this foothold, it was repurposed as infrastructure for an advanced phishing scenario.

The idea was:

1. Use the RCE to edit the Apache .htaccess file of the compromised virtual host.
2. Transparently proxy a controlled path, for example https://corp.com/documents/*, to an attacker domain, http://fake-corp-intranet.com/.
3. On fake-corp-intranet.com run an NGINX reverse proxy that:
   • Terminates TLS for the attacker domain
   • Proxies the Microsoft 365 / Azure AD login flow to Evilginx
   • Carefully rewrites headers, cookies and redirects so that the browser always appears to talk to https://corp.com/documents/...

From the victim point of view the browser:

• Navigates to a seemingly legitimate corp.com URL (for example a “documents portal”).
• Stays under the corp.com origin for the entire authentication flow.
• Never sees the attacker-controlled fake-corp-intranet.com or the phishing host.

This repository contains a cleaned and generalised version of the configuration used during that engagement, intended for similar scenarios where operators have the ability to edit the Apache .htaccess file.

---

High-level architecture

The following diagram summarises the setup:

• corp.com (Apache)

  • Legitimate corporate static site.

  • Already compromised through SQL injection leading to RCE.

  • .htaccess is modified only by adding the following mod_rewrite rule, which proxies https://corp.com/documents/* to http://fake-corp-intranet.com/documents/* using mod_rewrite and mod_proxy:

    RewriteRule ^documents(.*)$ http://fake-corp-intranet.com/documents$1 [P]

  • The URL in the browser remains https://corp.com/....

• fake-corp-intranet.com (NGINX reverse proxy, attacker VPS 1)

  • Public attacker VPS running NGINX with Lua support and Evilginx.
  • Receives traffic from corp.com only for the /documents/ path.
  • Forwards the Office 365 / Azure AD authentication flow to Evilginx running on the same VPS.
  • Evilginx is configured to relay outbound traffic through a second attacker VPS (VPS 2) with an Italian IP, in order to avoid suspicious logins originating from abroad.
  • Rewrites:
    • Location headers that would redirect the victim to Microsoft or the attacker domain,
    • Cookies (domain and path),
    • Absolute URLs in the HTML/JS body, so that the browser always stays on https://corp.com/documents/....

• Attacker VPS 2 (egress / country-local IP)

  • Provides an Italian public IP used by Evilginx on VPS 1 as outbound egress towards login.microsoftonline.com.
  • Only Evilginx/NGINX communicate with it. This helps make the Microsoft 365 login appear as originating from the victim’s country, reducing geo-location anomalies.

In short, the compromised corp.com site is used as a stealth entry point to an otherwise stand‑alone phishing infrastructure.

---

Setup overview

Building on the architecture above, requires configuring only two components: Apache on corp.com and NGINX (plus Evilginx) on fake-corp-intranet.com.

1. Apache (corp.com)

   • Ensure mod_rewrite and mod_proxy are enabled on the compromised Apache host.
   • Add the .htaccess rule shown above so that https://corp.com/documents/* is proxied to http://fake-corp-intranet.com/documents/*.
   • Verify that:
     • https://corp.com/ behaves as usual
     • Visiting https://corp.com/documents/ transparently forwards traffic to fake-corp-intranet.com while the browser still shows corp.com.

2. NGINX + Evilginx (fake-corp-intranet.com)

   • Install NGINX with Lua support:
     • Full step-by-step guide in docs/building-nginx-with-lua.md
   • Use nginx/nginx.conf as the base NGINX configuration
   • Deploy nginx/fake-corp-intranet.conf under your sites-enabled.
     • A detailed, line-by-line explanation of this file is in docs/nginx-reverse-proxy-configuration.md.
   • Configure DNS so fake-corp-intranet.com points to the NGINX VPS, and the Evilginx hostname (for example login.fake-corp-intranet.com) resolves as required by your Evilginx setup.
   • Configure Evilginx to send its outbound traffic through a second attacker VPS with an Italian IP address, so that Microsoft sees the login as originating from the victim’s country and not from abroad.
   • Restart NGINX and validate that requests to https://corp.com/documents/... stay on corp.com while the O365 authentication flow is correctly proxied through Evilginx to Microsoft.