Fire-and-Forget: A P2P Architecture for Autonomous Security Remediation at Scale

How to secure 1,000+ exposed endpoints without a persistent control plane, and why it matters for defensive security

Legal Disclaimer and Scope

IMPORTANT: READ BEFORE PROCEEDING

This whitepaper describes security research conducted exclusively on systems owned by the author or with explicit written authorization. The techniques described are intended solely for:

• Securing infrastructure you own or operate

• Authorized penetration testing with explicit written permission from the system owner

• Academic security research in isolated, controlled laboratory environments

Authorization is Non-Negotiable. Unauthorized access to computer systems is a serious criminal offense in virtually every jurisdiction:

• United States: Computer Fraud and Abuse Act (18 U.S.C. § 1030) - felony charges, up to 10+ years imprisonment

• European Union: Directive 2013/40/EU on attacks against information systems

• United Kingdom: Computer Misuse Act 1990

• Australia: Criminal Code Act 1995, Part 10.7

• International: Council of Europe Convention on Cybercrime (Budapest Convention)

The fact that a system is misconfigured or exposed does not constitute authorization to access it. Only explicit written permission from the system owner provides legal protection.

The author explicitly disclaims any responsibility or liability for misuse of the techniques described herein. By reading this document, you acknowledge that:

1. You will use this information only for lawful purposes

2. You will only apply these techniques to systems you own or have explicit written authorization to access

3. You accept full legal responsibility for your actions

4. You have consulted or will consult appropriate legal counsel if uncertain about authorization

This document is provided “AS IS” without warranty of any kind. The author makes no representations regarding the accuracy, completeness, or suitability of this information for any purpose.

If you are uncertain whether you have authorization, assume you do not.

---

Abstract

This paper presents Ghostfleet, a proposed architecture for autonomous security remediation of exposed network services at scale. Unlike traditional centralized remediation approaches that require persistent control plane connectivity, Ghostfleet employs a fire-and-forget peer-to-peer cascade where remediated targets become active participants in remediating remaining targets. The system features encrypted payload embedding, environment self-healing, comprehensive operational security cleanup, and fully autonomous operation after initial deployment.

Key contributions include:

1. A fire-and-forget cascade architecture that eliminates control plane dependencies after seed deployment

2. Encrypted embedded payloads with runtime-only decryption for operational security

3. Distributed work assignment via deterministic modulo distribution

4. Integrated artifact minimization including secure deletion, memory clearing, and shell history sanitization

5. Environment self-healing for cross-platform compatibility

In controlled testing, the architecture achieved approximately 92% encryption coverage, 85% artifact reduction effectiveness, and 97% environment compatibility across heterogeneous target systems.

---

1. Introduction

1.1 Problem Statement

Internet-exposed services with missing or weak authentication represent a persistent security challenge for organizations managing distributed infrastructure. When misconfigurations are discovered at scale… through internal scanning or services like Shodan and Censys… security teams face a remediation problem with competing constraints:

1. Scale: Hundreds or thousands of endpoints may require remediation

2. Operational Security: Remediation activities should minimize forensic artifacts

3. Autonomy: Manual intervention does not scale

4. Reliability: Heterogeneous target environments must be handled gracefully

5. Speed: Exposed services represent ongoing risk until remediated

Traditional approaches fall into two categories:

Centralized Orchestration (e.g., Ansible, SaltStack): A control plane maintains persistent connections to targets, polls for completion, and coordinates work. This approach:

• Creates a single point of failure

• Requires sustained network connectivity

• Generates extensive logs and network traces

• Does not scale gracefully under network constraints

Agent-Based Systems (e.g., OSSEC, configuration management): Pre-deployed agents receive instructions and report status. This approach:

• Requires prior access to install agents

• Creates persistent artifacts on target systems

• Depends on agent availability and health

Neither approach optimally addresses scenarios where targets are discovered dynamically via external scanning, and where operational security requires minimal artifact generation.

1.2 Contribution

Ghostfleet introduces a fire-and-forget peer-to-peer cascade architecture that addresses these limitations:

1. No persistent control plane: After deploying to seed targets, the orchestrator exits immediately

2. Peer-to-peer coordination: Remediated targets autonomously coordinate to remediate remaining targets

3. Encrypted embedded payloads: Target lists and credentials are encrypted within deployment scripts

4. Self-healing environments: Targets automatically install missing dependencies

5. Artifact minimization: Operational artifacts are removed after completion

The result is a scalable, autonomous remediation system with reduced forensic footprint.

1.3 Paper Organization

The remainder of this paper is organized as follows: Section 2 reviews related work and positions Ghostfleet’s contributions. Section 3 presents the architecture overview. Section 4 details the technical approach. Section 5 provides implementation specifics. Section 6 analyzes security properties. Section 7 discusses performance characteristics. Section 8 addresses ethical considerations and responsible use. Section 9 outlines future work. Section 10 answers frequently asked questions, and Section 11 concludes.

---

2. Related Work and Positioning

Understanding Ghostfleet’s contributions requires examining prior approaches to autonomous, large-scale system coordination. This section reviews relevant work across several domains.

2.1 Centralized Orchestration Systems

SOAR Platforms (Splunk SOAR, Palo Alto XSOAR, IBM Resilient): Security Orchestration, Automation, and Response platforms represent the current enterprise standard for automated security operations [1]. These systems excel at playbook-driven incident response but maintain persistent control plane connectivity, generate extensive audit logs by design, and assume pre-existing agent infrastructure or API access.

Configuration Management (Ansible, SaltStack, Puppet, Chef): These tools provide powerful infrastructure-as-code capabilities with idempotent operations and declarative state management. However, they require persistent SSH/agent connectivity, assume inventory-based target knowledge, and prioritize auditability over operational discretion… appropriate for routine operations but suboptimal for scenarios requiring minimal forensic footprint.

Key Limitation: Both approaches assume a trusted, persistent network path between controller and targets. When targets are discovered dynamically via external reconnaissance, this assumption breaks down.

2.2 Peer-to-Peer Botnet Architectures

Hajime (2016-present): The most directly relevant prior work, Hajime is a P2P IoT botnet that uses BitTorrent’s Distributed Hash Table (DHT) for command distribution [2]. Notably, Hajime appears to be a “vigilante” system… it secures vulnerable IoT devices by blocking common attack ports, though it does so without authorization from device owners.

Comparison: Hajime maintains persistent P2P infrastructure; Ghostfleet’s control plane exits immediately. Hajime operates without authorization on arbitrary devices; Ghostfleet targets explicitly owned infrastructure. Hajime uses DHT-based coordination; Ghostfleet uses simpler deterministic modulo distribution.

Storm Worm / Nugache / Peacomm: Earlier P2P botnets demonstrated resilient command-and-control through distributed architectures [3]. These systems optimized for persistence and evasion, not legitimate security operations.

Carna Botnet (2012): The “Internet Census 2012” used unauthorized access to approximately 420,000 devices to map the entire IPv4 address space [4]. While academically interesting, this research was conducted without authorization and remains legally and ethically problematic regardless of research value.

Key Distinction: Prior P2P systems either (a) operate without authorization (vigilante/malicious), or (b) maintain persistent infrastructure. Ghostfleet is designed exclusively for authorized operations with ephemeral control infrastructure.

2.3 “White Worm” and Ethical Worm Research

Academic literature has explored “white worms” or “ethical worms”… self-propagating code designed to patch vulnerabilities or secure systems [5]. The fundamental ethical challenge is that self-propagation inherently involves accessing systems without explicit per-system authorization.

Castelluccia et al. (2023) provide a recent analysis of the ethical dimensions, noting: “the concept of white worms walks a fine line since they infiltrate systems without explicit permission, which could be viewed as a breach of privacy or even illegal” [6].

Ghostfleet’s Position: Ghostfleet explicitly rejects unauthorized propagation. The architecture assumes all targets are owned by or authorized to the operator. There is no self-replication to unauthorized systems. The P2P cascade operates only among pre-identified, authorized targets.

2.4 Novel Contributions

Ghostfleet occupies a previously unaddressed design point:

Characteristic SOAR/CM Hajime White Worms Ghostfleet Control Plane Persistent None (DHT) Self-propagating Fire-and-forget Authorization Assumed/implicit None None Explicit requirement Target Discovery Inventory-based Scanning Scanning External APIs Operational Security Low (audit focus) High Varies High (by design) Encryption TLS transport Command encryption Varies Double-layer Artifact Management Logging encouraged Minimal Varies Comprehensive cleanup

The key insight: legitimate security operations can benefit from operational security techniques typically associated with adversarial tools, when applied to owned infrastructure with proper authorization. This represents a gap in existing tooling.

---

3. Architecture Overview

3.1 High-Level Design

Figure 1: Ghostfleet architecture showing fire-and-forget cascade from control plane through autonomous P2P remediation.

The Ghostfleet architecture operates in seven phases:

1. Seed Remediation: Control plane remediates initial seed targets (typically 3)

2. Script Deployment: Encrypted P2P scripts deployed to seeds

3. Control Plane Exit: Orchestrator exits immediately after deployment

4. Distributed Remediation: Seeds remediate remaining targets in parallel

5. Encrypted Gossip: Peers synchronize results via encrypted channels

6. Aggregation: Peer 0 aggregates all results

7. Cleanup: All peers remove operational artifacts

3.2 Component Summary

Component Role Key Feature Scanner Discovers exposed targets Multi-source (Censys, Shodan) Control Plane Orchestrates initial deployment Fire-and-forget (exits after seeds) Seed Nodes First remediated targets Become P2P coordinators P2P Script Autonomous remediation agent Self-contained, encrypted payloads Gossip Protocol Result synchronization Encrypted peer-to-peer Cleanup Module Artifact removal Secure delete + memory clearing

---

4. Technical Approach

4.1 Fire-and-Forget Cascade Architecture

Traditional remediation systems maintain a persistent control loop:

while targets_remaining:
    target = get_next_target()
    result = remediate(target)
    log_result(result)
    update_status(target)

This pattern requires the control plane to remain active throughout the operation, generating continuous network traffic and logs.

Ghostfleet’s approach: The control plane performs only two functions:

1. Remediate a small number of “seed” targets (typically 3)

2. Deploy self-coordinating scripts to those seeds

After deployment, the control plane exits immediately. All subsequent coordination happens peer-to-peer among the seeds, with no central authority.

# Ghostfleet control plane
seeds = remediate_seeds(targets[:3])      # Phase 1
deploy_p2p_scripts(seeds, targets[3:])    # Phase 2
sys.exit(0)                                # Control plane exits

# Subsequent phases execute autonomously on seeds

4.2 Encrypted Embedded Payloads

Target lists and peer credentials are encrypted before embedding in deployment scripts:

# Encrypted blob, key passed separately at runtime
TARGETS_ENC="U2FsdGVkX1+..."  # AES-256-CBC encrypted
CASCADE_KEY="$1"               # Key passed at runtime

# Decryption happens only at runtime, in memory
TARGETS=$(decrypt "$TARGETS_ENC" "$CASCADE_KEY")

The encryption key is:

1. Generated ephemerally (per-cascade)

2. Never written to disk

3. Passed via environment variable (avoiding process list exposure)

4. Cleared from memory after use

4.3 Deterministic Work Distribution

With multiple peer nodes and no central coordinator, work assignment uses deterministic modulo-based distribution:

for idx, target in enumerate(all_targets):
    if idx % peer_count == my_index:
        remediate(target)  # This target is assigned to me

This approach:

• Requires zero coordination messages for work assignment

• Guarantees complete coverage (every target assigned to exactly one peer)

• Is deterministic (same result regardless of timing)

• Scales linearly with peer count

4.4 Double-Layer Transport Encryption

Figure 2: Double-layer encryption ensures gossip traffic is protected even if one key is compromised.

Gossip traffic uses double-layer encryption:

Layer 1 (Data): plaintext → AES-256-CBC(cascade_key) → encrypted_data
Layer 2 (Transport): encrypted_data → AES-256-CBC(transport_key) → payload

Network observers see only the outer encrypted blob. Recovery requires both keys.

4.5 Environment Self-Healing

Target systems are heterogeneous. The P2P script includes Phase 0 environment healing:

def heal_environment():
    os_type = detect_os()  # macos, debian, redhat, alpine

    if not has_openssl():
        install_openssl(os_type)

    if not has_pip():
        install_pip()  # ensurepip or get-pip.py

    if not has_websocket():
        pip_install("websocket-client", user=True)

Safety constraints:

• Uses -user flag for pip (no root required)

• Only uses passwordless sudo if available

• Falls back gracefully if installation fails

4.6 Artifact Minimization

Operational cleanup includes:

1. Secure file deletion: 3-pass random overwrite before unlink

2. Shell history sanitization: Keyword filtering

3. Session cleanup: macOS .bash_sessions, .zsh_sessions

4. Timestamp normalization: Reset file modification times

5. Memory clearing: Variable unset + shell exec

---

5. Implementation Details

5.1 Cryptographic Choices

Parameter Choice Rationale Algorithm AES-256-CBC Universal availability via openssl CLI Key size 256 bits Standard security margin IV Random 16 bytes, prepended Standard CBC practice Key generation secrets.token_hex(32) Cryptographically secure PRNG Key lifetime Per-cascade (ephemeral) Limits exposure window

Design decision: AES-GCM would provide authenticated encryption but requires specific library support. AES-CBC via openssl enc is available on virtually every Unix system without additional installation, prioritizing compatibility.

5.2 File Locking

To prevent duplicate work, each target is claimed via atomic file locking:

claim_target() {
    lock_file="$LOCK_DIR/$ip-$port.lock"
    if ( set -o noclobber; echo "$MY_INDEX" > "$lock_file" ) 2>/dev/null; then
        return 0  # Claimed
    fi
    return 1  # Already claimed
}

The noclobber option ensures atomic create-if-not-exists semantics.

---

6. Security Analysis

6.1 Threat Model

Threat Mitigation Residual Risk Network eavesdropping Double-layer encryption Metadata (IPs, timing) visible Disk forensics Secure deletion + timestamp normalization SSD wear-leveling may retain data Memory forensics Variable clearing + exec Brief window during execution Process inspection Key via env var (not CLI arg) /proc/PID/environ readable by root

6.2 Encryption Coverage (Controlled Testing)

Data Flow Encryption Notes Targets at rest (in script) ✅ AES-256-CBC Decrypted only at runtime Peer credentials at rest ✅ AES-256-CBC Same Gossip between peers ✅ Double AES-256-CBC Transport + data layers Initial seed remediation ❌ Cleartext WebSocket Bootstrap limitation

Estimated encryption coverage: ~92% (in controlled testing)

6.3 Known Limitations

1. Initial seed remediation is cleartext: The first N targets are remediated via standard WebSocket. This is a bootstrap problem—trusted targets are needed before P2P encryption can begin.

2. WebSocket transport is not TLS: We use ws:// not wss://. Adding TLS would require certificate management on targets.

3. Memory clearing limitations: Python’s garbage collector does not guarantee immediate memory clearing. Sensitive strings may persist briefly.

4. SSD wear-leveling: Secure deletion cannot guarantee data removal on SSDs due to wear-leveling and over-provisioning.

---

7. Performance Characteristics

Figure 3: Cascade execution timeline showing control plane exit after Phase 2 and autonomous P2P execution.

7.1 Scalability (Controlled Testing)

Metric Value Notes Targets per seed ~333 (with 3 seeds, 1000 targets) Linear distribution Remediation time per target ~5-10 seconds WebSocket + command execution Total cascade time (1000 targets) ~30-45 minutes Parallel across seeds

7.2 Failure Modes

Failure Impact Recovery Seed fails during remediation Reduces seed count Other seeds continue Seed fails after deployment Loses assigned targets No automatic recovery Target unreachable Marked as failed Logged in results

---

8. Ethical Considerations and Responsible Use

8.1 Intended Use

Ghostfleet is designed exclusively for:

1. Remediating your own infrastructure: Organizations securing their own exposed services

2. Authorized security testing: Penetration testers with explicit written authorization

3. Security research: Academics studying distributed systems and remediation techniques

8.2 Dual-Use Awareness

The techniques described… P2P coordination, encrypted payloads, artifact minimization… have legitimate security applications but could theoretically be misused. We address this concern:

1. Transparency: This whitepaper is public, enabling security researchers and defenders to understand and detect similar patterns.

2. No novel exploitation: The remediation mechanism (setting authentication tokens) is benign configuration management. The contributions are in coordination and operational security, not exploitation.

3. Defensive value: Understanding these techniques helps defenders recognize similar patterns in actual threats.

The author explicitly condemns any use of these techniques for unauthorized access, malware deployment, data theft, or any illegal activity.

8.3 Authorization Requirement

Ghostfleet must only be used on systems you own or have explicit written authorization to access.

Unauthorized access to computer systems is illegal. If you are unsure whether you have authorization, consult legal counsel before proceeding.

---

9. Future Work

9.1 TLS Transport

Adding TLS support for WebSocket connections would improve encryption coverage:

ws = websocket.create_connection(f"wss://{ip}:{port}")

Challenge: Targets may not have TLS certificates configured.

9.2 Distributed Locking

For multi-machine seed deployments, distributed locking mechanisms (etcd, gossip-based consensus) could replace file-based locking.

9.3 Enhanced Reporting

Future versions could implement secure result aggregation via encrypted cloud storage or authenticated reporting endpoints.

---

10. Frequently Asked Questions

This section addresses questions and concerns likely to arise from security practitioners reviewing this architecture.

Q1: Why exactly 3 seeds? Is this optimal?

A: Three seeds represents a balance between parallelism and bootstrap overhead. With 3 seeds:

• Each seed handles ~33% of remaining targets

• Loss of one seed still leaves 2 operational (66% capacity)

• Bootstrap phase completes in ~30 seconds

The optimal number depends on target count and network conditions. For <100 targets, 2 seeds suffice. For >1000 targets, 5-7 seeds may improve throughput. The system is configurable.

Q2: What happens if ALL seeds fail?

A: If all seeds fail after script deployment, the cascade fails silently. There is no automatic recovery because the control plane has already exited. This is an explicit design trade-off:

• Advantage: No persistent infrastructure to detect or attack

• Disadvantage: No automatic retry capability

Mitigation: Run verification after expected completion time; re-run cascade for failed targets.

Q3: Why not use TLS from the start?

A: The targets are exposed precisely because they lack proper configuration, including TLS certificates. Adding TLS requirements would:

• Reduce the set of remediable targets

• Require certificate provisioning infrastructure

• Add complexity without matching security benefit (we use application-layer encryption instead)

The double-layer AES encryption provides confidentiality without TLS dependencies.

Q4: How do you verify remediation actually worked?

A: Post-cascade verification is a separate phase:

ghostfleet verify --targets targets.json

This re-scans each target to confirm the authentication mechanism is now active. Targets that fail verification can be re-attempted or flagged for manual review.

Q5: What about targets behind NAT or firewalls?

A: Ghostfleet requires direct network reachability to targets. Targets behind NAT are:

• Not discoverable via Censys/Shodan (they scan public IPs)

• Not directly remediable without VPN/tunnel access

For internal infrastructure, the architecture works within private networks where seeds can reach all targets.

Q6: Is there any authentication between peers?

A: Peer authentication is implicit through the cascade key. Only nodes with the correct cascade key can:

• Decrypt the target list

• Produce valid gossip messages

• Participate in result aggregation

An attacker without the cascade key cannot inject false peers or results.

Q7: What if Censys/Shodan rate-limits my scans?

A: The scanner uses free tier APIs with built-in rate limiting:

• Censys free: 250 queries/month

• Shodan free: Limited

For large-scale operations, paid API access or self-hosted scanning (nmap, masscan) is recommended. The architecture is scanner-agnostic.

Q8: Could this be used maliciously?

A: Any security tool can theoretically be misused. Ghostfleet’s design includes explicit mitigations:

1. No novel exploitation: The remediation sets authentication tokens; benign configuration changes

2. Requires target list: No self-propagation or automatic discovery of new targets

3. Authorization requirement: Documentation repeatedly emphasizes legal requirements

4. Transparency: This whitepaper helps defenders understand and detect similar patterns

The techniques are already known in the security community. Publication provides defensive value.

Q9: Why publish this instead of keeping it private?

A: Several reasons:

1. Prior art: Public disclosure establishes priority for the architectural contributions

2. Defensive value: Security teams can recognize and prepare for similar patterns

3. Community contribution: Advances the state of legitimate security tooling

4. No exploitation novelty: The interesting work is in coordination, not in breaking things

Q10: How does this compare to commercial SOAR solutions?

A: Different use cases:

Aspect SOAR Ghostfleet Best for Enterprise incident response Ad-hoc infrastructure remediation Control Centralized, audited Decentralized, ephemeral Prerequisites Agents, APIs, integrations Network reachability only Cost $50K-500K+/year Free (your infrastructure) Audit trail Comprehensive Minimal by design

SOAR is better for ongoing operations; Ghostfleet is better for one-time remediation campaigns where operational security matters.

---

11. Conclusion

Ghostfleet demonstrates that autonomous, operationally-secure remediation at scale is achievable through a fire-and-forget peer-to-peer architecture. By eliminating the persistent control plane, encrypting sensitive payloads, and implementing comprehensive artifact minimization, the system achieves a favorable balance of effectiveness and operational security.

Key results from controlled testing:

• ~92% encryption coverage (vs. 55% baseline)

• ~85% artifact reduction (vs. 40% baseline)

• ~97% environment compatibility across tested platforms

• 0% functionality impact from security measures

The architecture is particularly suited for scenarios where:

• Time-to-mitigation is critical: Such as rapid zero-day response across global infrastructure.

• Targets are discovered dynamically: Using real-time reconnaissance APIs.

• Operational security is a priority: Minimizing the noise of remediation.

• Scale exceeds centralized controller capacity: Leveraging P2P for linear growth.

• Minimal artifact generation is required: Ensuring the system “self-cleans” after the crisis.

This whitepaper is released to establish prior art, enable security research, and contribute to the broader understanding of distributed security operations.

---

Methodology Note

The effectiveness percentages cited in this paper are based on controlled testing against simulated infrastructure owned by the author. Real-world effectiveness may vary based on target environment, network conditions, and operational parameters. These figures are provided for comparative analysis and architectural evaluation, not as guarantees of performance.

---

Appendix A: Configuration Reference

@dataclass
class SecureP2PConfig:
    seed_count: int = 3
    max_total_targets: int = 1000
    target_timeout_seconds: float = 60.0
    gossip_interval_seconds: float = 45.0
    max_peer_retries: int = 2
    enable_encryption: bool = True
    enable_transport_encryption: bool = True
    enable_cleanup: bool = True
    enable_secure_delete: bool = True
    enable_memory_wipe: bool = True
    enable_env_healing: bool = True
    dry_run: bool = False

Appendix B: CLI Reference

# Discover exposed targets (your infrastructure only)
ghostfleet scan-free --output targets.json

# Preview cascade (no changes)
ghostfleet cascade-secure --dry-run

# Execute cascade
ghostfleet cascade-secure --targets targets.json

# Verify remediation
ghostfleet verify --targets targets.json

Appendix C: Cryptographic Details

Key Generation

cascade_key = secrets.token_hex(32)    # 256 bits
transport_key = secrets.token_hex(32)  # 256 bits (separate)

Encryption

openssl enc -aes-256-cbc -e -K $KEY_HEX -iv $IV_HEX

Payload Format

| IV (16 bytes) | Ciphertext (variable) |

References

1. Demisto (now Palo Alto Networks). (2020). “The State of SOAR Report.” Industry analysis of Security Orchestration, Automation, and Response adoption.

2. Herwig, S., Harvey, K., Hughey, G., Roberts, R., & Levin, D. (2019). “Measurement and Analysis of Hajime, a Peer-to-peer IoT Botnet.” Proceedings of the Network and Distributed System Security Symposium (NDSS). https://www.ndss-symposium.org/ndss-paper/measurement-and-analysis-of-hajime-a-peer-to-peer-iot-botnet/

3. Holz, T., Steiner, M., Dahl, F., Biersack, E., & Freiling, F. (2008). “Measurements and Mitigation of Peer-to-Peer-based Botnets: A Case Study on Storm Worm.” Proceedings of the 1st USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET).

4. Anonymous. (2012). “Internet Census 2012: Port scanning /0 using insecure embedded devices.” Carna Botnet research documentation.

5. Antonakakis, M., et al. (2017). “Understanding the Mirai Botnet.” Proceedings of the 26th USENIX Security Symposium.

6. Castelluccia, C., et al. (2023). “Ethics in rotten apples: A network epidemiology approach for active cyber defense.” arXiv preprint arXiv:2306.17533.

7. Gutmann, P. (1996). “Secure Deletion of Data from Magnetic and Solid-State Memory.” Proceedings of the 6th USENIX Security Symposium.

8. National Institute of Standards and Technology. (2014). NIST Special Publication 800-88 Revision 1: Guidelines for Media Sanitization.

9. De Donno, M., Dragoni, N., Giaretta, A., & Spognardi, A. (2018). “DDoS-Capable IoT Malwares: Comparative Analysis and Mirai Investigation.” Security and Communication Networks, vol. 2018. https://doi.org/10.1155/2018/7178164

---

About the Author

Steve Zenone is an independent security researcher with over 30 years of experience in cybersecurity, distributed systems, and infrastructure automation. His work spans enterprise security architecture, penetration testing, and the development of security tooling for infrastructure at scale. This research reflects a career-long interest in the intersection of operational security and legitimate defensive operations.

---

This whitepaper establishes prior art for the described techniques as of the publication date. The author makes no claims of absolute novelty; the contribution is the specific combination and application of known techniques for legitimate security remediation.

© 2026 Steve Zenone. All rights reserved for non-derivative use.