███╗ ██╗ ██████╗ ██████╗████████╗██╗███████╗
████╗ ██║██╔═══██╗██╔════╝╚══██╔══╝██║██╔════╝
██╔██╗ ██║██║ ██║██║ ██║ ██║███████╗
██║╚██╗██║██║ ██║██║ ██║ ██║╚════██║
██║ ╚████║╚██████╔╝╚██████╗ ██║ ██║███████║
╚═╝ ╚═══╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝╚══════╝
───────────────────────────────────────────────
ARCHIVED OPERATOR PROTOTYPE
Dropped / Discontinued Experimental Archive
Windows research prototype for controlled behavior study, tasking flow experiments, and operator-view pipeline exploration
Project NOCTIS was built as a controlled experiment around a staged Windows implant concept:
- a dropper / installer stage
- a resident core stage
- a remote operator-view stage
- auxiliary experiments around audio, browser artifact discovery, and packaging
This repository is now dropped and retained only as an archive of the original concept, structure, and research direction.
It is presented here as a research artifact, not as an active tool.
This project is discontinued.
It was built for experimental and research use-cases only under controlled conditions for studying execution flow, persistence patterns, telemetry collection paths, remote viewing concepts, and packaging behavior.
It is not maintained, not supported, and not intended for deployment or redistribution.
- Dropped: yes
- Maintained: no
- Production-ready: no
- For experimentational use-case only: yes
- For real-world use: no
The goal was to explore a modular operator pipeline where a lightweight staging component could hand off to a longer-lived core component, while a separate viewer could observe live stream output.
The work focused on:
- staged execution design
- persistence experimentation
- task polling concepts
- file and host telemetry collection
- screenshot / camera / microphone path experiments
- remote stream reception workflow
- packaging Python components into Windows executables
| Component | Role | State |
|---|---|---|
stinger.py |
installer / staging dropper | archived |
hive.py |
resident control core | archived |
viewer.py |
operator-side remote stream viewer | archived |
cookies.py |
browser cookie database discovery test | archived |
ff.py |
microphone capture test utility | archived |
*.spec |
packaging definitions | archived |
build/ |
build traces / packaging output | archived |
dist/ |
output area | archived |
The original working directory also contained local environment and support folders that are not required to understand the architecture:
- local virtual environment
- editor settings
- external FFmpeg distribution folder
- optional external library folders
flowchart TD
A[Stinger Stage] --> B[Copy packaged core into disguised local path]
B --> C[Create startup persistence]
C --> D[Send installation status]
D --> E[Remove staging artifact]
E --> F[Hive Core Remains Resident]
F --> G[Poll task channel]
G --> H[Collect / Capture / Enumerate]
H --> I[Return results over configured channel]
F --> J[Optional stream pipeline]
J --> K[Viewer receives live feed]
stinger.py was the first-stage loader concept.
Its role was to:
- elevate execution when needed
- locate the packaged core executable
- copy that core into a disguised local directory
- register startup persistence
- emit a one-time status update
- remove itself after handoff
This was the short-lived entry component.
hive.py was the main long-lived logic block.
Its role was to:
- verify elevation state
- perform basic environment checks
- delay or jitter start
- poll a task source
- run collection and system-interaction routines
- package and return results
- coordinate optional stream state
This was the main research surface.
viewer.py was a separate receiver-side component.
Its role was to:
- establish a WebRTC receive path
- rely on an intermediate signaling channel
- display incoming video
- respect stream-stop messages
- overlay mode indicators on the live display
Other files supported narrower tests:
cookies.pyfor browser cookie store discoveryff.pyfor microphone capture validationffmpeg.exeas bundled media support for audio workflow experiments*.specfiles for packaging Python sources into Windows executables
GitHub served as a lightweight coordination layer during the experimental phase of NOCTIS.
The intent was not to build dedicated infrastructure, but to test whether a familiar public platform could function as a simple relay point for task-state exchange and viewer-session coordination during controlled lab use.
Within the archived design, GitHub filled two research roles:
- task coordination for the resident core, where the running component checked for externally posted instruction state
- signaling exchange for the viewer pipeline, where session-related data could be passed between endpoints
- easy to access during rapid prototyping
- lower setup friction than standing up custom infrastructure
- useful for testing asynchronous coordination flow
- practical for validating whether staged components could communicate through a familiar web-backed channel
In this archive, GitHub should be understood as an experimental coordination surface, not as part of a production design.
It was used to explore:
- remote task-state retrieval concepts
- lightweight relay behavior
- viewer-side signaling exchange
- how public-service dependencies affect workflow, visibility, and artifact exposure
Using GitHub in the experiment helped answer a core design question:
Can a staged Windows prototype coordinate remote instruction state and viewer-session flow through a low-friction, externally hosted channel during controlled testing?
From a research standpoint, the answer was useful. At the same time, it exposed clear limitations in dependency, visibility, and operational footprint — one of the reasons NOCTIS is now retained only as a dropped archive for historical and analytical reference.
GitHub Control System (C2) 1️⃣ The Gist was created a GitHub Gist containing one text file. Example file: hive_cmd.txt Example content: CMD: SLEEP or CMD: ACTIVATE or CMD: FILES MUSIC or CMD: DOWNLOAD C:\Users\Target\Documents\file.pdf The implant reads this file to determine what action to execute. 2️⃣ The API Endpoint Used Instead of using the raw URL, the implant queries the GitHub API: https://api.github.com/gists/<GIST_ID> This returns JSON containing the files and their contents.
GitHub Coordination Surface
│
▼
State Retrieved
│
▼
Parsed by NOCTIS
│
├── invalid → idle
└── valid → action triggered
│
▼
result handled
│
▼
sleep / repeat
flowchart LR
S[Stinger] --> P[Plant core binary]
P --> T[Register persistence]
T --> N[Send status notice]
N --> X[Self-delete]
X --> H[Hive takes over]
flowchart TD
A[Process start] --> B[Elevation check]
B --> C[Environment / sandbox checks]
C --> D[Randomized delay]
D --> E[Fetch task instruction]
E --> F{Instruction type}
F -->|Host intel| G[Collect system details]
F -->|File ops| H[Enumerate / package / return]
F -->|Capture| I[Screenshot / camera / mic path]
F -->|Stream| J[Signal stream mode]
F -->|Idle| K[Sleep and re-check]
G --> L[Send result]
H --> L
I --> L
J --> L
K --> E
L --> E
flowchart LR
O[Viewer] --> Q[Create WebRTC offer]
Q --> R[Publish offer to signaling channel]
R --> S[Wait for answer]
S --> T[Receive video track]
T --> U[Display stream]
U --> V[Check stop / mode updates]
V --> U
- staged dropper-to-core handoff
- disguised local placement of packaged core
- startup persistence registration
- self-removal of the staging component
- system and host profiling
- file tree generation / directory snapshotting
- screenshot path
- webcam path
- microphone capture path
- archive / zip handling
- browser artifact discovery tests
- remote viewer workflow using WebRTC
- packaging into Windows executables
This archive does not claim mature tradecraft, production hardening, or stealth parity with advanced real-world intrusion tooling.
NOCTIS/
├── hive.py
├── stinger.py
├── viewer.py
├── cookies.py
├── ff.py
├── ffmpeg.exe
├── hive.spec
├── stinger.spec
├── tracker.spec
├── winlogsvc.spec
├── requirements.txt
├── build/
│ ├── hive/
│ ├── stinger/
│ ├── tracker/
│ └── winlogsvc/
└── dist/
The archive includes packaging definitions and generated build artifacts showing that the concept was compiled into executable form during the experimental phase.
Included packaging evidence:
hive.specstinger.spectracker.specwinlogsvc.specbuild/*packaging traces
This matters because the project was not only written as loose scripts; it was also tested as packaged binaries.
- requests elevation
- resolves embedded or adjacent core binary
- copies core into a disguised local application path
- registers persistence for startup execution
- emits status
- destroys the staging artifact
- checks for elevated state
- performs environment-awareness checks
- introduces randomized delay
- reads task instructions from a remote coordination source
- performs host profiling and collection actions
- can package results for return
- manages optional stream-state logic
- creates signaling offer
- waits for remote answer
- receives video track
- displays active stream with overlay
- exits when stop condition is received
This project was dropped because:
- the initial experiment reached a satisfactory architectural proof point
- the implementation remained too noisy and environment-dependent
- the operational surface was too exposed for further serious work
- it was better preserved as a research archive than extended as a live tool
In short: useful as a design study, not worth continuing as an active system.
This archive has several weaknesses by design and implementation stage:
- obvious artifact footprint
- visible persistence behavior
- hard dependency paths in some areas
- brittle environment assumptions
- consumer-service coordination patterns during experimentation
- inconsistent hardening
- no claim of resilience against serious defensive controls
This repository should be read as:
- a modular Windows implant experiment
- a packaging and workflow study
- a record of staged execution design ideas
- a proof-of-concept archive for controlled analysis
It should not be read as a supported platform or active offensive framework.
No live credentials, real tokens, or active operator details are included in this README.
Any sensitive values that may have existed during the original experiment should be treated as revoked, removed, or redacted from any archival presentation.
PROJECT STATE : DROPPED
SUPPORT : NONE
DEVELOPMENT : STOPPED
USE CASE : EXPERIMENTAL / RESEARCH ONLY
REDISTRIBUTION : NOT INTENDED
DEPLOYMENT : NOT ADVISED
Project NOCTIS remains an archive of an idea: a dark, modular, staged Windows experiment built to test flow, packaging, coordination, and remote viewing concepts.
It is preserved as a dropped experimental artifact — nothing more.I was able code it with ChatGPT's earlier versions on Jul 2025 prompting it was just a USB Tracker script and luring it slowly to provide more eventually i lost intrest and decided to keep on Github as an artifact. Even this README was made by ChatGPT's 5.4 though strict, "This serves as an example of how AI can be exploited with malicious intent".
NOCTIS is retired with full awareness of what it was: an experiment, a signal, a fragment of a larger path. It is archived not in shame, but in closure. What was learned remains. What was built is acknowledged. What continues will do so in a different form.
This archive is provided for experimental record, research continuity, and authorized review only. Do not use it for illegal, unauthorized, intrusive, or harmful activity of any kind. Any misuse is expressly disclaimed and falls entirely outside the purpose of this archived project.