Grant Application - Offensive Security #340

Application Name:

DevOps Infrastructure Security & Darknet Information Monitoring for MVPs

GitHub Application:

https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/340

Project: Offensive Security
Requested amount: $88,000
Category: Infrastructure

Project Summary

External offensive-security assessment of the Zcash ecosystem’s deployed infrastructure - organisation websites and email, light client and indexer servers, payment tools and CI/CS pipelines - emulating how a real adversary would compromise it. In parallel, and with each person’s consent, we monitor the darknet exposure of Zcash MVPs and employees against a 94B record dataset to surface the leaked credentials, addresses, PII, infostealer and live adversarial infrastructure & operations (long before it reaches the average breach check database). The same starting points an attacker would use, giving each participant a private report.

Project Description

The security of Zcash’s software code is well-supported by Least Authority’s role as the ecosystem security lead and Taylor Hornby’s efforts for Shielded Labs. This grant proposal supports those efforts by evaluating and improving the security of deployed infrastructure, and the exposure of the people who operate it. These are the two things a real external adversary actually attacks, and they are equally important: an attacker probes the deployed systems, and uses information leaked about individuals as the starting point to target them directly.

On the infrastructure side, we evaluate:

  • Websites, email infrastructure, etc. of Zcash-related organisations,
  • Light client and indexer servers that wallets connect to (lightwalletd, Zaino),
  • CI/CD and software release infrastructure,
  • Any other DevOps deployments that are important to the community.

Additionally, Zcash MVPs (leaders, developers, etc.) and employees would benefit from understanding their risk profile as a result of information exposures in leaks/hacks circulating on the darknet. With these individuals’ permission, we also propose to perform darknet searches for personal information including:

  • Home addresses, Number Plates, PII
  • Apps used, accounts registered (regardless of compromise), music preferences, diets, enough intimate details for social engineering
  • Compromised accounts,
  • History of malware infecting their systems.

These searches draw on a darknet dataset we have accumulated of over 94 billion records (breach data, credential combolists, and infostealer logs). By providing a private report to these individuals on which information is available about themselves on the darknet, these individuals can better understand their risk profile for physical attacks, phishing and social engineering, and system compromises.

Proposed Problem

The code auditing performed by Least Authority and Taylor Hornby is valuable for ensuring Zcash-related software is security-bug-free. In addition to the code being secure, it is also important that the code is deployed securely, and that the people responsible for it understand what an attacker already knows about them.

Even with perfect code, an insecure server deployment can put users at risk, for example from attacks such as:

  • Replacing a wallet binary download with a malicious copy,
  • Drive-by downloads and other browser-based attacks against visiting users,
  • Extracting sender/recipient information from light client servers,
  • Stealing deployment keys from CI/CD systems, to release malware.

An attacker targeting a specific person usually begins with information that has already been leaked about them. A home address enables a physical or coercion attack against someone holding funds. A reused password, or a session token captured in an infostealer log, can lead to a compromised account, a signing key, or a malicious code release. Leaked personal information is the adversary’s starting point, which is why monitoring it is as important as testing the infrastructure.

Services like Have I Been Pwned already offer Zcash MVPs information about what has been leaked about them on the darknet. However, Have I Been Pwned does not disclose the actual leaked data such as passwords and addresses. Having access to this information would help MVPs better understand the source of the breach, whether their system had been compromised, and which home addresses have been leaked. TechSlayers’ darknet search reports include full copies of such information, drawn from the dataset described above.

Proposed Solution

With permission, TechSlayers will perform black-box penetration testing against Zcash’s public infrastructure to identify weaknesses such as:

  • Out of date server software and operating systems,
  • Out of date and vulnerable WordPress plugins,
  • APIs lacking access control, leaked credentials, etc.,
  • Other vulnerabilities (XSS, CSRF, etc.),
  • Email server misconfigurations creating phishing risks (DMARC, DKIM, SPF),
  • Light client and indexer servers leaking sender/recipient metadata,
  • And much more.

These penetration tests will be performed manually with the assistance of the latest AI models. If given access to server source code and deployment scripts (e.g. WordPress plugins, Kubernetes configurations, etc.), we will also perform white-box security review for similar problems.

To direct this testing to where it matters most, we have surveyed the deployed surface of the current Zcash ecosystem. It includes:

  • Organization websites and email, such as ZODL (zodl.com), Electric Coin Company (z.cash, electriccoin.co), the Zcash Foundation (zfnd.org) and its community forum, Shielded Labs, and the Zcash Community Grants portals,
  • Light client and indexer infrastructure, including the zec.rocks light-server network (a Kubernetes deployment behind HAProxy on Fly.io), the Zaino indexer that is replacing the deprecated zcashd RPC, and legacy lightwalletd instances,
  • Wallets with deployed components, such as the Zodl wallet
  • Payment and point-of-sale tools, such as ZGo (a WordPress plugin) and Free2Z,
  • Block explorers and chain-analytics services,
  • CI/CD and release pipelines across the ecosystem’s GitHub organizations,
  • Community and social platforms, such as ZecHub and the community forum.

We will also make available our darknet search capabilities to any MVP, employee, or community member, to look up their personal information.

6 Likes

(Disclosure: I’m friends with Phill and I think I have some shares in TechSlayers)

I encouraged Phill to apply here since an effort like this would close off some important gaps in the community’s security posture, especially now that identifying vulnerable software and exploiting vulnerabilities can be automated with AI.

We have amazing code security practices for the software we ship, but there’s also vast amounts of infrastructure operating around that software like these forums, wallet download sites, public lightwalletd instances, zcash nodes themselves, etc. Most of this infrastructure doesn’t get independent security testing, but it’s still important to Zcash users’ security.

Black-box pentests should give a low-noise signal of what’s vulnerable without needing to bother infrastructure operators with the effort and risks of granting a third party auditor access to their systems. Phill’s darknet information reports are eye opening; when you realize some C-tier social media app leaked the exact GPS coordinates to your old apartment you’ll definitely think twice about enabling location services.

4 Likes

Of the surfaces listed, which worries you most today, the public lightwalletd and indexer servers or the release and CI pipelines?

PII exposure of key ZCG/ecosystem members is what worries me most today. An attacker doesn’t need to defeat the crypto or breach a server if a maintainer’s or key-holder’s leaked credentials, hand them the account directly. Highest likelihood, lowest attacker effort, highest impact.

Second is the light-client/indexer layer.

The logic connecting them: people are the weakest link and the cheapest to exploit, so I’d start there; the indexer layer is the highest-value system an attacker reaches once they’re moving. Both are why I propose continuous monitoring on both layers, not a one-time sweep.

3 Likes

Been thinking a lot about this and am curious what the benefit is if folks can’t change the fact the info is already out there. Rn its confined to small subset of darkness, wouldn’t this type of report bring more light to senstive info? I guess I dont see a clear end game if its immutable. Also, it seems to increase fear. Is that a goal?

Thank you

2 Likes

@phill at the most recent meeting, ZCG voted to approve this proposal. Congratulations!

To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread.

Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests.

3 Likes

@dismad Once such information reaches the large public databases it’s effectively immutable but that process can be slowed, and sometimes prevented, while the data is still in private trade. It’s also useful to know what’s already out there, so you can adjust your privacy strategy and OpSec accordingly, both as an individual and as an organisation.

@ZCG I am absolutely ecstatic thank you so much for the opportunity!!!

1 Like

Month: 1 · Period: mid-July to mid-August

Summary

  • First iteration of ecosystem mapping (pre-reconnaissance) completed
  • Monitored the Ironwood (NU6.3) mainnet activation end-to-end
  • First darknet-monitoring engagement live

Ecosystem mapping & scoping (Pre-reconnaissance)

Built an inventory of the zcash ecosystem

  • Assets catalogued: 139
  • Coverage dimensions: 15

Reconnaissance

In-progress

Active infrastructure assessments

  • Initial findings under investigation: 25
  • Defensive positives: reviewed signing / spend-authority components — soundly built; prior third-party audit of a server-side component verified fixed.

Dark PII Reconnaissance

  • Organizations opted in: 1
  • Individuals assessed: 13
  • Identifier touch points: 80+

Projects

Ironwood (NU6.3) activation monitoring

Ironwood network upgrade activated on mainnet on 28 July 2026 at ~14:08 UTC (block 3,428,143). A network upgrade is a moment of elevated risk so this event was treated it as a live resilience test.

Captured a clean pre-activation baseline and a post-cutover rebaseline (including a mid-window client version roll) to distinguish upgrade effects from normal variance. This was done by setting set up probes in 5 regions measuring availability, consistency and performance before, during and after. All monitored endpoints stayed online at 100% availability with only minor, expected slowdown.

Attack vectors threat-modeled for the activation window (and watched for live):

Vector Outcome
Consensus split / chain fork / partition Not observed — fleet fully converged
Infrastructure overload / availability failure under surge Not observed — 100% availability
Light-client server-selection manipulation (eclipse-style) Monitored — no evidence
Exchange/pool cut-over reorg / double-migration races Monitored (third-party) — no incident
Supply-integrity / turnstile verification failure Turnstile held — no anomaly
Privacy / metadata correlation in the high-volume window Priority hardening area — handled privately

This also initiated building an eclipse-scenario PoC, as such an attack is cheaper to perform during an upgrade in terms of resources required.

Eclipse-scenario PoC

Isolated lab — own CA + own instances: built a working proof-of-concept of the transport-trust decision a light-client eclipse relies on — taken up to, but deliberately not through, the point of live impact. Certificate pinning is the effective mitigation; specifics held for private disclosure to the affected wallet team.

2 Likes