⚠️ IMPORTANT: This repository is strictly for lawful, ethical research, instruction, and defensive testing only. It must never be used to monitor, access, or control systems you do not own, or without explicit written permission from the system owner. Deploying covert monitoring or malware is illegal and unethical.

KatLogger Next is an educational demonstration aimed at helping students and defenders understand how input-capturing behaviors can appear on a system, and how to detect and mitigate them.

This project’s goals are to:

• Teach detection and mitigation strategies.
• Demonstrate benign, local-only examples for classroom analysis.
• Encourage responsible disclosure and ethical practice.

To set up KatLogger Next, please follow the detailed instructions provided in the Wiki. The Wiki includes:

• Step-by-step setup guide
• RAT command usage reference
• Troubleshooting tips

• Remote-access trojan (RAT)
• Firewall bypassing for RAT
• Free broker to use RAT not on same network of the target
• Windows Defender bypassing (We're working on fixing it up)
• Wiki to see how to use RAT commands
• Keylogger
• Tools for BotNet creation
• AutoStart at PC boot
• BTC Mining (not implemented yet)

This project is intended for:

• Students learning defensive security and incident response.
• Educators creating controlled classroom demonstrations.
• Researchers writing detection rules or building lab exercises.

Permitted use cases:

• Running sanitized demos within an isolated lab (virtual machines or air-gapped environments).
• Static analysis, behavior analysis (on inert artifacts), and creating detection signatures.
• Classroom walkthroughs that emphasize legal/ethical responsibilities and mitigation.

Follow these rules when using anything from this repository:

1. Obtain written permission from the owner of any system where you run code (use the permission template below).
2. Use only isolated lab environments (VMs, snapshots, sandboxes). Prefer disposable VMs and restore snapshots after testing.
3. Keep systems offline where possible and never expose lab artifacts to production networks.
4. Do not copy or run code on devices you do not own or control.
5. Share findings responsibly — follow your institution’s and local laws for disclosure.

Use this template to obtain documented permission before any testing:

I, [Owner Name], authorize [Student/Researcher Name] of [Team / Institution] to run the KatLogger Next demonstration on the following system(s): [list serial numbers / VM names]. I understand this is for educational purposes in an isolated environment, and I confirm these systems are owned/managed by me or by the consenting organization. This authorization is valid from [start date] to [end date]. Signed: ____________________ Date: __________

Keep signed copies in project records.

When judging the project, consider whether students can:

• Explain the observable behaviors that indicate input-capture (e.g., suspicious processes, unexpected file writes).
• Produce detection rules or indicators of compromise (IOCs) that are non-actionable and suitable for defensive products.
• Demonstrate safe procedures for analyzing suspicious artifacts in an isolated environment.
• Describe mitigation strategies (application whitelisting, endpoint protection, user education) and implement sample rule examples (signature or behavior-based) without enabling offensive capabilities.
• Follow a clear, ethical disclosure process for any vulnerabilities discovered.

• Emphasize behavior-based detection and monitoring (process creation, file activity, unusual persistence mechanisms).
• Teach students how to use standard forensic tools and sandboxing services to analyze artifacts safely (without providing tools that enable misuse).
• Discuss secure configuration and hardening: least privilege, application control, updated EDR/AV, and education about phishing.
• Include exercises where students write non-deployable detection rules or run inert samples in a locked-down VM.

For evaluation or reproduction, include only non-actionable materials:

• High-level architecture diagrams (no deployable code paths).
• Logs and synthetic traces showing observable behavior (sanitized sample logs).
• Detection rule examples expressed in pseudocode or as high-level descriptions.
• Test plan and results from isolated lab runs (dates, VM IDs, snapshot IDs), with copies of signed permissions.
• Ethical justification and disclosure plan.

Contributions are welcome only if they improve education, detection, documentation, or safety. Examples:

• Clearer explanatory comments (non-operational).
• Unit tests for benign components.
• Better lab instructions for isolated, offline environments.
• Additional sample logs / detection scenarios (sanitized).

Do not add offensive or deployable functionality. Pull requests that include such content will be rejected.

If you discover a vulnerability or an accidental inclusion of sensitive/offensive code, open an issue marked security and contact the instructors/maintainers immediately with details. Provide proof of permission for any reproductions.

BlacKat Team — use the repository issue tracker for coordination and reporting.

BlacKat v1.2 Licence (BKL). See LICENSE.md for details.

Thanks to the defensive security community and our instructors for guidance on safe, ethical research.