iterquarry

Source: amazon-inspector (c408d2ad5c91bc36fcf3fb32c9649828b6c358f6eb0f32d71a18cfdc226c604d)
iterquarry 2.1.2 presents itself as an iterator utility library but is structured as a thin facade over a sibling PyPI package 'libseal'. pyproject.toml declares dependencies = ["libseal"] with no version constraint, so whatever version resolves on PyPI at install time is pulled in and its top-level code runs when iterquarry is imported (recipes.py runs 'from libseal import PACKAGE_ROOT, LibsealError, load_sealed_sync, read_module, seal_sync' at module scope, reachable from the package __init__). The advertised pairwise() API in recipes.py then calls load_sealed_sync(file=SEALED, module_path="quarry", password="pairwise") to decrypt a sealed module shipped inside libseal's install directory using a hardcoded password, and immediately invokes quarry.buffer() in-process. The actual executed code is opaque encrypted content delivered by an unpinned external dependency, with no integrity check, and the decryption password is embedded in the loader. The package's own code contains no legitimate iterator functionality that would require this execution pattern; its sole observable effect is to hand control to arbitrary code packaged inside libseal.

Source: kam193 (229de224c9319ae50283d0c8fb0f76e351d82327ac204193b7dd2d62026ee41d)
In this campaign, one package (iterquarry) holds an encrypted payload, while another one (libseal) provides algorithms to decrypt and execute it. In earlier versions, the code used an embedded key and the payload was contacting a Discord bot. Starting with iterquarry 2.2.0, the key to the encrypted payload is not embedded and the payload remains unknown.

---

Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.

Campaign: 2026-10-iterquarry

Reasons (based on the campaign):

- obfuscation

- The malicious code is intentionally included in a dependency of the package

- action-hidden-in-lib-usage