jupiterha/ayhu-stealer

1. Project shape

- This repository is essentially a single-file Python stealer centered in Ayhu.py.

- There is no multi-service backend, no package structure, and no internal module boundary visible from the file tree.

- The img/ folder is documentation-only, used for screenshots in the README.

2. Primary runtime

- The intended runtime is a Windows desktop environment.

- That is implied by the targets it names: Discord, Chrome, and Steam, all of which require access to local user data stores and application directories.

3. Core purpose

- The script’s purpose is credential and session theft plus basic host fingerprinting.

- The README explicitly lists:

- Discord tokens

- Geolocation data

- Chrome passwords and cookies across all profiles

- Steam data

4. Local data collection layer

- The first architectural boundary is the local harvesting stage.

- It likely reads from:

- browser profile storage for Chrome passwords/cookies

- Discord-related local token/session artifacts

- Steam client or related local files

- This is all local-machine focused and does not appear to depend on any remote API beyond exfiltration.

5. Host profiling / enrichment

- The “geolocation data” feature suggests a second stage that enriches stolen data with IP-derived location metadata.

- This is typically used to add context to the stolen bundle before sending it out, rather than being a standalone user-facing feature.

6. Exfiltration path

- The main outbound boundary is a Discord webhook.

- The README instructs the operator to paste a webhook URL into Ayhu.py, which means the script is configured to send collected data directly to Discord rather than to a custom server.

- That makes Discord the only explicit external service in the architecture.

7. Operator configuration

- The script is manually customized by editing a placeholder webhook value in the source.

- That means the repo has no config system, no CLI, and no environment-based secret management; configuration is embedded directly into the code.

8. Packaging / delivery

- The README describes turning the script into an executable with PyInstaller or auto_py_to_exe.

- Architecturally, this indicates the repo is designed for single-binary distribution, not for installation as a Python package or running as a long-lived service.

9. Obfuscation and evasion

- The README claims obfuscation will make it “undetectable,” which suggests the operator expects the binary to be obfuscated before distribution.

- This is part of the delivery/evasion layer, not the data collection logic itself.

10. Data flow summary

- The effective flow is:

- operator builds the script

- victim executes the binary locally

- the script gathers local credentials/tokens/cookies and host info

- results are packaged and sent to a Discord webhook

- There is no indication of persistence, command-and-control polling, or bidirectional tasking in the repo snapshot.

11. Diagram boundary suggestion

- For an architecture diagram, model this as a single Windows client executable with three internal blocks:

- local secret harvesting

- host/location enrichment

- webhook-based exfiltration

- Surround it with an external dependency boundary for:

- local browser/app data stores

- Discord webhook endpoint

- optional packaging tools used only at build time

12. Notable absence

- There is no visible backend, database, queue, or API server in the repository.

- So the architecture is source script → packaged executable → direct webhook exfiltration, with the repo itself acting as the entire implementation.