[dredd]

Design Philosophy

Periscope aims to be a dependency-injected, unit-tested, N-tier architected, resilient, rich data, ORM backed, multi-platform, expert-guided, cradle-to-grave, automated build/deployment, C2 system for breach operations with a permanent back-end and ephemeral target-facing infrastructure.\

Eyes, Ears, and OODA Loops.
Our project aims to be different than every other C2 tool we have seen or used. If it's not different, why would we build this?
[/url]
Distinguishing Features:

• Many Callback Endpoints, One Control Center. Rather than spinning up multiple disjointed C2 servers, we deploy a network of redirectors across a variety of protocols and domains, but all of them route back to a single central back-end server, where all of our adversary intent logic and data reside. Our redirectors are designed with zero knowledge encryption so they can be deployed on untrusted hosting infrastructure without an admin at the provider being able to steal our access to victim networks.
  
• Prioritize automated situational awareness data collection, hence the reference to OODA loops. Operators should not spend their time collecting information to figure out where they are in a target network (Observe, Orient). They should spend their time moving towards campaign objectives (Decide, Act). So this data should be collected in an OPSEC safe, yet automated way. See docs on the Rules Engine.
  
• RICH DATA. All data that is collected by the agent should be collected and persisted in the Control Center's structured database. No flat log files or grepping standard out to find something. Rich data leads towards better situational awareness and more automation capabilities. It also prevents operator friction where it is easier to run a collection task a second time on an infected machine, risking detection.
  
• GLOBALIZATION. Complete support for wide char unicode on non-English language Windows hosts, including file system support for alternative character set based filenames. At the time when we first built this, no open source or commercial C2 tooling supported this. Every string in metadata about a host is collected with Unicode support, so even a hostname containing an emoji character will be rendered correctly. (At the time of development, this would crash some C2s.)
  
• Orchestration. Our mantra is that
  Algorithms > Shells
  . The long term goal is for the operator to orchestrate shells into performing tasks based on rich data and conditional logic, not run yet-another-interactive-shell. An operator interacting with a shell is an indication that the task algorithms assigned to an agent were not rich enough for the campaign objectives. There will always be some manual steps, but they should be as minimal as possible, and should be reviewed post-mortem to build better rules.
  
• Liveness. Leveraging rules to collect as much as possible, including the file system of the target host, allows the Operator to feel as though the interaction is with a live interactive host, but in reality, it's short round trips between the Operator's terminal and the Control Center's API, not high latency round trips to the victim endpoint which could be on multi-hour callback intervals. File Systems that have been traversed through Dir Tasks will be cached locally and can be perused long after even the shell is down, even for post-mortem. The Operator experience in the CLI is just like what they're used to on a live terminal endpoint.
  
• State of the Art Comms. We want agents that have multiple ways to phone home, rich criteria for choosing which method, resilience if one or more method is blocked by defenders, and as much sneakiness and camouflage as we can dream up, ready to go in a configurable product. Think: agents with more than 10 ways to call home over the Internet, from shared services, to domain fronting, to our categorized domains, to self-organizing local chains (picking another agent in the target network as the designated egress point until it can no longer be reached). We want to be unstoppable with comms.
  
• Operator Decision Support. We want the UI to guide the operator towards making OPSEC-safe task decisions for agents all the time based on automatically collected situational awareness data. If we lose a shell, we want to use our rich data collected during the campaign to feed into future campaigns OPSEC safe rules to prevent that particular lost shell situation from ever occurring. The UI should guide the operator towards these smart decisions in a way that is educational, in case the tool captures OPSEC knowledge that operator has not yet earned through the misfortune of a lost shell and blown campaign. Inspiration for many of the defensive control detections came from the Danderspritz Project Leak.
  
• Minimal Knowledge in all Agents and Stagers. Agent and Stager binaries can be collected and analyzed by defenders. We want them to know as little as possible about what is happening in our campaign. They should contain a set of primitive features they can implement and the logic for
  If {x} then {y}
  should be stored on the
  Control Center
  and not the
  agent
  for this very reason. The Control Center is the brains of our operation.
  
• Hardened Poly-Morphic Stagers. We have our own Stager solution, which borrows TTPs from malware families in the past decade, and is presumed to be inspected by both automation (sandboxes) and smart defenders. As a result, there are layers of obfuscation and trickery built-in, with the option to feature toggle different detection and evasion techniques at build time, in addition to complete dynamic XOR encryption of all strings with just-in-time (JIT) XOR decryption at runtime, only when a string literal constant is actually needed based on the environment in which it lands. Additionally, leveraging Canaries to notify Operators when a stager is being inspected, as well as calling for fake next-stages when it can be determined it is unsafe to connect to live next stage hosting infrastructure.
  
• Host Based Tasking. Unlike other C2 frameworks, we want our tasks to be assigned to hosts, not agents. An agent is an implementation of a session, not the access itself. An agent may be fired off an ephemeral persistence mechanism (e.g.
  normal.dot
  only firing when MS Word is open), so we may have agents that only last for a few minutes to a couple hours. We don't want to start over with each agent. We want to pick up where we left off. As a result, all tasks involving things like File I/O will use fully qualified paths, because future agents may run in a variety of local directories. If a new agent phones home and is available for a task assigned the host, and the security context matches the task, then that agent will pick up the work where the queue was left off, unlike other C2 frameworks where the new agent starts all over again at step 0. This matters even more when the Rules Engine is considered.
  
• Minimal Command Line Execution on the Agent. Or put bluntly:
  APIs > Terminals
  . We believe defensive telemetry around Operating System and Application APIs will always be more difficult than simply capturing terminal commands and applying regular expressions or yara rules against them. Operators should not trust terminal commands and consider them as potential ways to get caught. As a result, the use of
  shell
  tasks in our agents should be used only as a crutch until the similar functionality is built as an agent primitive wrapper for the host's native APIs.
  
• Extensible Canaries. Support HTTP/DNS trackers and reverse indicators that are useful in a variety of ways, from learning when a defender discovers a payload, to indicating distress, to serving a staged payload or maybe a pixel tracker, etc., firing off a WebHook operator push notification upon event execution. These are our subtle and super flexible way of putting telemetry into places that were previously quiet and unmonitored.
  
• Safety Checks on Everything. Modern defenses involve public and private cloud hosted sandboxes and interrogation services. We include safety checks in our comms that identify likely unsafe clients talking to our services, by a combination of timing,
  Canaries
  , IP addresses, Network ASNs/Ownership, etc. This can result in a
  Canary
  delivering a malicious payload to an expected victim or a 404 to a security vendor who snagged a copy of our stager out of a malicious email attachment.
  
• Email Phishing Engine. We are discontent with publicly available tools for handling phishing campaigns at scale, so we built a better one that uses a single persistent
  Control Center
  and ephemeral throw-away
  Task Runner
  workloads to do the heavy lifting of delivering email via a variety of mechanisms without risking the banning of our permanent Control Center infrastructure. Also with a web UI for simple management by an phishing initial access team, a necessary division of labor of offensive teams at scale.
  
• Multi-Player. We built this fully intending on multiple operators simultaneously working together-- also this supports LDAP, because we don't like keeping passwords in sync.
  
• Full Auditing. With multiple operators and tons of complexity, it is imperative that we capture key events and can articulate what happened and when. Our auditing is captured with UTC timestamps only and preserved in a way that a play-by-play post-mortem with a defender is easily supportable.
  
• MITRE ATT&CK. We integrate with our industry's default taxonomy for describing adversary activity. It's not perfect (nothing is), but this gets us closer to mapping back to detection gaps and conversing in a common language with incident responders.
  
• Proper Software Engineering. Unlike other options, there is no combat coding here. We bring proper engineering patterns and practices to this project. CI/CD automation, generics, Object Orientation, code first databases, etc. This is built to last and be extended.
  

Goals:

• Stability. Our goal is reliable execution, not flaky execution. We want this to work every single time and if it doesn't, we want to capture why so we can learn from it. Exception handling is an art.
  
• Be Gray. We believe that the future of malware will be to look like legitimate applications as much as possible, which means using the same development languages, frameworks, tools, APIs, and packaging/distribution methods that legitimate applications use. The more "good" and "commonality" we can introduce into our payloads and agents, the more difficult they will be to identify by Machine Learning models and human analysis.
  
• Less AV Signatures. Since this is our private tool (at least for now), it should be free of the burden of commercial security product signatures (at least for now). See
  Be Gray
  above.
  
• Flexible Design. We are building Periscope with a multi-tiered approach to support extensibility in a flexible way without causing problems down the road. For instance, all
  redirectors
  are either direct or indirect, which simplifies the design but allows for a variety of redirector types (e.g. SMB daisy chaining, DNS, Twitter as a third party service, whatever we can imagine!). Also, the tiers are flexible and resilient so that redirectors can live in different places (e.g. as a redirector without escrowed access to encryption keys, or as an internal relay host within a target environment). Want a new module? No problem, modules are built to tie back to primitives. If the
  agent
  doesn't support it (e.g. *nix agent can't read the Registry since it isn't windows, or maybe a browser plugin can't perform an ldap query) then it will gracefully handle the situation both in the Control Center and within the agent.
  
• Must have agents that can run on all platforms: Windows, Mac, *nix, even potentially non-standard or limited functionality agents (e.g. browser plugins and VBA/macro only agents).
  

OODA Loops

• Orient (Hostname, Domain, Network Config, UserID, Privileges, Environment)
  
• Observe (Other users, admins, processes, services, tasks, etc.)
  
• Decide (Resilient multi-home, multi-protocol callback so a human operator can make decisions)
  
• Act (Directory Listings, Read Files, Write Files, Query databases)
  

All primitive functions on the agent are simple and commonly used by many legitimate enterprise apps, which makes an unsignatured binary very "gray" (i.e. heuristics will be difficult).
[url=https://github.com/malcomvetter/Periscope/blob/main/wiki/design-philosophy.md#repo]
Repo

• Agents (C++ and GoLang) - The C++ agent is the flagship agent, but the GoLang agent runs in more target environmetns with a subset of the primitives available for tasking
  
• CLI - Dotnet core project for the operator's command line interface into the system.
  
• Common - Libraries shared hierarchically among the project components
  
• ControlCenter - Dotnet core project for the centralized back-end command node for the system.
  
• DnsServer - A DNS library dependency for DNS based redirectors and canaries
  
• HAProxy - an implementation of high availability for the components in our infrastructure, subject to variance based on your deployment requirements
  
• Redirectors/Core - Library of commong components among all redirector types
  
• Redirectors/DnsRedirector - A redirector over DNS, currently for DNS Canaries only, but one day for C2 comms over DNS as well
  
• Redirectors/HttpRedirector - Our workhorse redirector, ready for HTTP, HTTPS, Domain Fronting, etc.
  
• Redirectors/SlackRedirector - An example indirect redirector set to communicate over Slack's enterprise communication service API
  
• Redis - our in memory cache for common items necessary for scaling our infrastructure
  
• Runner/DnsRunner - a Task Runner workload that can manage DNS domains and create/manage DNS records to automate the deployment and utilization of complex campaign infrastructure, leveraing dozens of domains at once.
  
• Runner/Services - Task Runner workloads that can build our agents and stagers dynamically with minimal configuration defined by an Operator, so Operators don't have to be developers
  
• Runner/SmtpRunner - Task Runner that does the heavy lifting of sending SMTP phish campaign emails where they need to go, complete with email message templates, attachments, and dynamically generated stagers and agent payloads.
  
• Stager - Our very own stage zero stager, with our tradeoff choices for OPSEC safety, and our execution methods. The "Spaghetti" stager is designed look like a giant monolith of code with minimal branching after it is compiled, to frustrate defenders tasked with reverse engineering and signaturing our binaries.
  
• WebUI - Our web UI project that implements the View of the MVC design pattern, leveraging the same Control Center API that everything else uses.
  
• Wiki - the overall project documentation