In the last blog, we examined how combolists are built from the raw sources (breach dumps, infostealer logs, and SQLi mass exploitation), the curation process, and how they fuel credential stuffing through tools like OpenBullet and SilverBullet.
That phase ends with a “hit”, a validated email:password pair confirmed against a target login.
But the credential stuffing hit is not the end of the story. It is the beginning of a much larger underground supply chain.
In this blog, we follow what happens after validation. Specifically, we examine the highest-value tier of the entire ecosystem, mail access, and then map how every major sector of cybercrime draws from the combolist economy.
What Is Mail Access and Why It Sits at the Top of the Market
Among all categories of validated credentials traded on the underground market, none carries the same depth of compromise as Mail Access.
In dark web forums, Telegram broker channels, and private Tox/Discord rooms, “mail access,” sometimes written as “webmail access,” “inbox access,” or simply “mail,” refers to validated email:password pairs where the seller has confirmed that IMAP/POP3/SMTP or webmail login works.
It is not just a credential. It is a confirmed live mailbox, and inside the underground economy, that distinction is everything.
Why Mail Access Is the Most Valuable Credential Type
Mail access is the most valuable credential category in the entire underground economy, not because of any single piece of data it exposes, but because of the depth, variety, and intelligence density packed into a single mailbox.
Where a streaming or gaming credential grants access to one service, a single validated mailbox typically enables an attacker to
- Read all existing and incoming emails.
- Steal sensitive data, invoices, password reset links, personal information, and more.
- Create forwarding rules or inbox filters to maintain persistent, hidden access.
- Reset passwords on linked accounts, including banking platforms and social media.
- Launch targeted phishing campaigns from a trusted, legitimate email address.
There is a more practical reason why mail access has become the most valuable type of credential attackers go after one that defensive security literature rarely mentions but that becomes immediately clear to anyone who has watched a credential-stuffing operation in real time:
A growing number of platforms now require email-link verification or OTP, and without mail access, a valid email:password pair is operationally useless against them.
The pattern is everywhere now. When an attacker attempts to log in with stolen credentials from an unfamiliar IP, device, or geography, the platform does not simply allow the login or block it. Instead, it issues a challenge:
- “We noticed a new sign-in. Click the link in your email to confirm it’s you.”
- “Verify your login by using the OTP we just sent.”
- “For your security, we’ve sent a magic link to your email. Click it to continue.”
This is now standard behavior on a wide range of services banking portals, crypto exchanges, e-commerce platforms, streaming services, gaming accounts, and cloud SaaS. Some platforms use it as a one-time challenge for new devices; others treat it as a passwordless authentication primitive (the “magic link” pattern) and require it on every login.
For the legitimate user, this is a low-friction security improvement.
For an attacker working from a stolen email:password pair, it is a hard wall unless they also have access to the mailbox.
This is the structural reason mail access sits at the top of the credential market. Mail access is not just a higher-value target on its own. It is the master key that unlocks every other credential the attacker has already collected.
A combolist of 100,000 banking credentials is functionally inert if the corresponding email accounts cannot be opened to retrieve the verification links. Pair the same combolist with mail access for those same victims, and the entire stock becomes weaponizable overnight.
How Mail Access Is Graded and Sorted
Mail access markets are tiered. Sellers grade their stock with consistent vocabulary:
- “Hits” login confirmed, nothing more verified.
- “Fresh / Private” recently harvested, not yet circulated, often less than 7 days old.
- “Sorted” filtered by domain, country, or keyword presence inside the mailbox.
- “Provider” high friction to crack but extremely high value. Sellers offer three types: multi-provider lots (Hotmail, AOL, Yahoo bundled together); corporate mail access (sold separately at a premium); and individual accounts from high-value targets as standalone listings.
Hacker Tools: How Mail Access Is Actually Compromised
Knowing that mail access is a traded commodity is the easy part.
The harder question and the one defenders need to answer is how attackers actually get in and what tools they use, and how they pull it off at scale.
This section covers the main attack methods the same way Part 1 covered SilverBullet config logic: enough detail to support defense.
After acquiring raw email:password combolists (from infostealer logs, breaches, or SQLi dumps), attackers feed them into specialized mail access checkers. These tools are purpose-built for high-volume IMAP validation and post-login intelligence gathering unlike general credential stuffers (OpenBullet, SilverBullet), they are optimized for email protocols and almost always include built-in inbox scanning.
Many email access checking tools exist in both older and newer versions.
While some checkers have continued to evolve and become more advanced, others have become outdated over time, as is natural with any technology
In this example, the attacker is checking a huge list of email and password combinations against TikTok. You can see in Figure 6 on the left that it says 16,000 out of 55,000 accounts have already been tested, and 4,872 of them were successful (real working accounts).
The middle table shows the email addresses, passwords, and the website being checked (tiktok.com).
On the right side, the attacker can easily choose which websites to target.
This kind of tool makes the whole process very easy and fast. The attacker loads a big list of emails and passwords, presses start, and the program automatically finds working accounts and lets them open the inbox right away all in one window.
In Figure 7, there is a built-in email viewer that lets the attacker open and read the inbox of any successful account immediately.
Many modern mail access checkers include a built-in keyword scanning feature.
After successfully logging into an account, the tool can automatically search the victim’s inbox for specific keywords or domains. For instance, if an attacker is targeting individuals who play Grand Theft Auto V, they can add @rockstargames.com (or rockstargames.com) to their keyword list.
The checker will then scan the inbox for any emails containing these terms and save the matching accounts into a separate results file. This feature also supports the use of multiple keywords at once. Below is an example of a real keyword list commonly used by operators:
The current tool landscape
Several tool families are in active circulation in cracking communities.
The list rotates as builds get cracked, leaked, or replaced but the capability set across them is converging:
- SNIPR : A long-standing name in cracking communities. Built-in configs, keyword scanning, clean interface. Still actively used, though the community has fragmented as newer tools have arrived.
- All-In-One Checker : Popular for its simplicity and reliability for basic IMAP validation. Frequently distributed as cracked or free builds; common entry-level choice.
- HMC and its successor builds : A long-running family known for excellent domain-routing logic and a very large pre-resolved IMAP-server database that ships with each build. Widely re-distributed.
- OpenBullet 2 + ULP / mail-tier configs : Not a dedicated mail-checker but increasingly used as one, since community-maintained configs cover most major providers. Lower polish than the dedicated tools, but more flexible.
Older tools (Mail Stalker, etc.) are still mentioned in tutorials but are considered outdated against modern providers they predate today’s captcha and rate-limit landscape.
For the rest of this blog, we’ll use HMC as the case study because we have a real reverse-engineered build to walk through. Although the developers attempted to protect it with obfuscation to conceal its internal logic, we were able to bypass these protections and expose the underlying code. Figures 8 and 9 illustrate this process: Figure 8 shows the original obfuscated code, while Figure 9 presents the same code after deobfuscation.
How These Tools Work
When attackers get hold of a leaked list of email addresses and passwords (combo lists), they don’t try each one by hand. They run automated tools that do it at scale thousands of checks per minute, across hundreds of email providers at once. The process is straightforward: the tool takes one email:password pair, figures out which mail server that email belongs to, quietly tries to log in, and records whether it worked. Then it moves on to the next one. Forever. Think of it like someone with a massive ring of copied keys, methodically trying each key on every door in a building except the building has thousands of doors and the keys are being tried simultaneously by dozens of hands. The diagram below maps out exactly how that process flows, from the moment the operator hits “Run” to the moment a valid credential lands in a results file.
Technical Workflow
Once the operator clicks Run, ThreadsManager.Run() brings every supporting service online and spawns the worker pool.
In one sweep it resets caches (HostFinder.Refresh), arms the background timers (stopwatch, speed meter, rest saver, proxy loader), loads the combo list, then runs Task.Run to spawn N background threads each one calling Worker.Run through a SafeExecute shim that prevents one thread’s crash from killing the pool.
Stop() is a hard kill Thread.Abort() on every worker:
Thread.Abort() injects an exception asynchronously, so a force-stopped run often leaves a truncated final entry in Results\\<session>\\Good.txt
Per-mailbox dispatch
Each worker runs an infinite loop in Net/Worker.cs. It pulls one mailbox at a time off the queue and routes it.
If WebSettings.CheckWeb is on, the domain is matched against eleven hardcoded provider lists (Rambler, Mail.ru, Yandex, Onet, GMX, Proton, Yahoo, AOL, iCloud, Interia, Seznam) and routed to the dedicated web client for that provider:
Three matching styles are visible: array contains for most providers, ContainsIgnoreCase("yahoo") substring match for Yahoo (catches yahoo.fr, yahoo.co.jp, but not ymail.com), and exact EqualsIgnoreCase for AOL and iCloud. Six of the eleven targets are CIS or Eastern European providers.
Domains that don’t match any provider fall through to the generic IMAP/POP3 path cache lookup → host discovery → MailHandler.
Domain-aware IMAP routing
For unknown domains, the checker runs a five-stage discovery pipeline (Net/HostFinder.cs, Net/HostFinderContext.cs) to figure out which IMAP/POP3 server to connect to.
The pipeline sits behind a per-domain cache in HostFinder.GetServer() each unique domain pays the discovery cost exactly once, no matter how many workers encounter it:
The cache has three states.
InProgress (set on the first thread to see a domain) makes other threads hitting the same domain sleep and re-queue.
Found returns the cached Server. NotFound increments a counter and writes the credential to HostNotFound.txt. HostFinder.Refresh() (the second method on screen) is what ThreadsManager.Run() calls at the start of every session to wipe this cache.
The actual discovery work happens inside FindServer(), which runs the five stages below in order:
Stage 1 : Local cache. A hardcoded _domainCoincidences dictionary (~14 entries) maps known provider fragments to canonical IMAP hosts. Substring match anything containing gmail.com resolves immediately to imap.gmail.com:993/SSL.
Stage 2 : MX lookup + MX-pattern shortcut. If the cache misses, the checker fetches the domain’s MX record. Two paths: FindMXRecordByLookup (direct DNS) or FindMxRecordByGoogle (DNS-over-HTTPS via dns.google.com/resolve, routed through a proxy). The MX result is matched against _recordCoincidences (~37 entries) which recognises substrings like outlook, google, yahoo, mx-aol, secureserver, zoho, and a long tail of shared-hosting MX patterns.
Stage 3 : Subdomain brute-force on the original domain. Try imap.<domain>, mail.<domain>, etc. on 993/143; same for pop.<domain>, pop3.<domain> on 995/110. About 20 TCP probes per domain.
Stage 4 : Subdomain brute-force on the MX parent. Same probes, but applied to the registered domain of the MX host (catches vanity domains hosted on a shared mail backbone).
Stage 5 : Autoconfig and Autodiscover fallback. Fetch autoconfig.<domain>/mail/config-v1.1.xml (Mozilla) and autodiscover.<domain>/autodiscover/autodiscover.xml (Microsoft). Parse the IMAP server out of the returned XML. The User-Agent is set to a hardcoded value designed to slip past basic bot protection.
The strongest detection signal in this stage is the order a real mail client would try autoconfig first and brute-force essentially never. Inverted ordering is a checker fingerprint.
Login + harvest loop
MailHandler.Handle() picks the right protocol-specific handler and delegates to Check():
The AllowedProtocols filter lets the operator restrict the run to IMAP-only or POP3-only. The RebruteImapWithPop3 block at the bottom is the more interesting part if an IMAP login errors out, the same credentials are re-attempted over POP3 on the same domain. From the target’s perspective this looks like an IMAP attempt followed within a minute by a POP3 attempt with the same username, often from the same proxy IP. High-fidelity behavioural signature.
WebHandle is the slim variant used by web clients when they need an IMAP/POP3 fallback:
The writeGood parameter lets the caller suppress writes to Bad.txt when a web client invokes the IMAP fallback, only successful logins get recorded.
Check() is the retry loop:
A few details worth flagging:
- Multi password guard Same address is checked before and after the login call if another worker has already proved a known-good password for this address mid-run, the current attempt aborts. Stops the checker from burning multiple proxies on the same email when the combo list contains several passwords for it.
- Comcast special case If the handler is IMAP, the result is
Blocked, and the domain is exactlycomcast.net, the retry counter is decremented (this attempt doesn’t burn a slot). The developers special-cased this domain, suggesting they hit repeatable behaviour from Comcast’s IMAP service they didn’t want to treat as a hard fail. - Result reclassification .
ServerDisabled → BlockedandHostNotFound → Bad. MeansBad.txtin the operator’s results folder isn’t pure “wrong password” it’s a mix of credential failures and infrastructure errors. - Dual retry budgets
IOException/SocketExceptionandTimeoutExceptioncount against separate counters. A single credential can produce 8–10 actual login attempts on the target server before being recorded asError.
The success branch does the harvest registers the credential as known-good, optionally runs SELECT INBOX, and if SearchSettings.Search is on, walks the inbox against operator queries and writes matches to disk.
Weaponization
Once a mailbox is validated, attackers frequently move beyond simple access. Many checkers include built-in tools to extract SMTP credentials and webmail panel sessions.
These compromised business-grade SMTP accounts are then sold or used directly in large-scale operations. Figures 11 &12 below shows a typical underground marketplace selling hacked webmail and SMTP infrastructure from hosting providers and large companies:
Conclusion
Mail access is not merely another credential in the underground market, it is the master key that transforms raw combolists into a fully weaponized supply chain. A validated email:password pair that can open the inbox turns every downstream credential (banking, crypto, e-commerce, gaming) from inert data into an operational asset. Without mailbox control, modern email-based challenges, magic links, OTPs, and device-verification flows, render even “good” hits useless. With it, attackers gain persistent read access, password-reset capabilities, forwarding rules, and the ability to phish from a trusted address.This blog has traced the full downstream pipeline: from breach dumps and infostealer logs through curation and credential stuffing, to the specialized mail-access checkers (HMC and its relatives) that operate at massive scale. We have seen how these tools combine intelligent domain routing, MX discovery, protocol fallbacks, inbox harvesting, and keyword scanning to deliver exactly what the broader cybercrime economy demands, fresh, private, sorted mailboxes graded by value.
The economic reality is stark. Every major sector of cybercrime, account takeover fraud, business email compromise, targeted phishing, SIM-swapping support, and ransomware reconnaissance, ultimately draws from this combolist-to-mail-access pipeline. The tools are mature, the market is liquid, and the incentives are perfectly aligned: one high-quality mailbox can unlock dozens of high-value accounts.For defenders, the implications are clear. Visibility into mail-checker infrastructure (proxy patterns, IMAP/POP3 retry signatures, autoconfig-first ordering, and inbox-search behavior) is now as important as monitoring credential-stuffing endpoints. Until authentication models shift decisively away from email as a recovery and verification channel, toward passkeys, hardware-bound credentials, or phishing-resistant MFA, mail access will remain the highest-ROI target in the entire credential ecosystem.The combolist economy does not end with the “hit.” It only begins there. Understanding the mail-access layer is therefore essential to understanding how modern cybercrime actually operates at scale.
