The DEKENEAS Threat Observatory: Adaptive Deception and Behavior-First Intelligence for Emerging Exploitation

Abstract

The DEKENEAS Threat Observatory detects emerging exploitation campaigns, including activity with no assigned CVE, at the moment attackers first make contact. It combines two capabilities: an AI-driven deception network that infers the protocol and the product an attacker expects, presents a consistent persona of that product, and sustains the conversation until the attack is delivered, and an intelligence engine that classifies the captured behavior without signatures, indicator lists or malware family databases.

CVE correlation is applied after behavioral detection, with explicit confidence levels. Exploitation-relevant behavior that maps to no known vulnerability is surfaced as a candidate 0-day signal, scored separately from severity. Each weekly edition is generated automatically, with no analyst in the loop, and published as campaign-level intelligence with MITRE ATT&CK mapping and STIX 2.1 indicators.

This paper describes the collection architecture, the analytic method, the structure of the intelligence produced, and the classes of attack activity the module is designed to surface.

1. Introduction

Most threat intelligence sees exploitation late, because it is organized around labels that exist only after an attack is understood. A vulnerability is disclosed, a signature or tag is written for its exploit pattern, and sensors then count matches. Anything without a rule is invisible.

Attackers do not wait for that cycle. They scan, probe, stage infrastructure, test exploits, harvest credentials and deploy malware well before activity appears inside a target organization. By the time a CVE, signature or vendor report exists, the attacker workflow is often mature.

The gap is widest where exploitation outpaces disclosure: routers, embedded devices, edge technologies, management interfaces, modern development tooling and long-tail software. These are also the surfaces least covered by internal monitoring.

The Threat Observatory addresses this by inverting the usual order. It observes attacks directly, from outside, as they are attempted. It classifies what each interaction does before asking which known vulnerability it might correspond to. Whatever remains unexplained after that correlation is the earliest available signal of a new technique or campaign.

Two requirements follow. The collection layer must get attackers to deliver real payloads, even against targets nobody anticipated. The analysis layer must understand those payloads without relying on prior knowledge. Sections 2 to 5 describe how each requirement is met.

2. Collection: AI-driven protocol and application inference

The core of the collection layer is AI-driven inference at two levels: the network determines from the attacker's own traffic which protocol and which product the attacker expects to reach, then responds as that product, consistently, for as long as it takes the attacker to initiate the attack.

2.1 Why the conversation matters

Attackers rarely send an exploit to a target that has not answered convincingly. A scanner connects, sends a probe or handshake, and inspects the reply. Only when the reply matches the service it is hunting does it proceed to the payload.

A conventional honeypot exposes a fixed set of services on fixed ports with scripted replies. If the attacker targets anything outside that set, the exchange ends at connect or banner, and the defender learns only that someone knocked. Coverage is limited to what was anticipated.

2.2 Inference instead of configuration

The DEKENEAS deception network analyzes packet characteristics and interaction patterns to infer the targeted service. It then dynamically activates the matching emulation logic. Protocol is determined per interaction, from what the attacker sends, not assumed from the port number.

Three consequences follow:

• Any port can host any protocol. An HTTP admin login probe on an arbitrary port, a development server request on its default port, or a Log4j payload on a high-numbered port are all engaged.
• Multi-step attacks proceed. Each attacker decision is made on the strength of the previous reply, so a believable conversation carries the attacker from reconnaissance through to weaponized delivery.
• Unanticipated targets are covered. An attack against a service or endpoint nobody planned for still reaches the payload stage, which is the precondition for detecting it.

2.3 Application personas

Inference does not stop at the protocol. From the paths, parameters and fingerprinting sequence an attacker uses, the network identifies the product being hunted and presents a coherent persona of it across that product's entire exposed surface.

A persona is consistent on every axis an attacker's tooling checks:

• Identity. Server headers, security headers, caching and connection behavior are identical on every endpoint, so cross-checking several paths never reveals a seam.
• Path semantics. Each endpoint returns the status code the real product would: login pages render, protected resources redirect unauthenticated sessions, and exploit paths are answered according to the product's state.
• Content types. HTML portals, JSON discovery documents and API endpoints each return the format the product uses.
• Surface coverage. Legacy portals, current login pages, identity-provider endpoints and administrative interfaces of the same product all answer as one device.

The example below shows a persona of an SSL VPN / application delivery appliance responding to a typical fingerprinting and exploitation sequence.

Every response carries the same vendor server header, nosniff, appliance-style cache directives and connection behavior.

The persona also behaves realistically with respect to patch state. A sensor that appears vulnerable to everything is itself a deception tell. By answering an exploit path as a mitigated device would, while the rest of the product remains fully present, the persona stays credible, the attempt is still recorded and classified, and the attacker continues to fingerprint and probe.

2.4 Protocol breadth

Because emulation is selected per interaction, coverage is open-ended rather than limited to a predefined service list. The families below illustrate the range of protocols and products engaged; they are representative, not exhaustive.

Coverage without per-service deployment

Conventional honeypots must be built, deployed and maintained one service at a time. In practice, their coverage concentrates on a small set of popular services, and the threat reports built on them inherit that bias: activity against anything outside the deployed set is never observed, so it is never reported.

The DEKENEAS network removes that constraint. No honeypot has to be deployed for a specific service before that service can be observed, because the service is inferred from the attacker's own traffic. The network therefore catches exploitation against services that other honeypots and reports usually miss: niche and legacy products, vendor-specific management and update planes, newly released frameworks and development tooling, proprietary and appliance services, and services moved to non-default ports.

This is where emerging exploitation tends to appear first. Attackers favor surfaces that defenders and sensor networks do not watch, and an attack against such a surface is precisely what a per-service deployment model cannot see.

2.5 Depth of emulation

Emulation is deliberately low-interaction in one specific sense: it does not simulate a compromised host or hands-on-keyboard activity. It captures reconnaissance, exploitation attempts, protocol misuse and first-stage delivery.

This is the stage that matters for discovery. Internet-scale exploitation (pre-auth RCE, path traversal, command injection, deserialization, JNDI injection) carries its exploit primitive and its delivery command in the requests themselves. Sustaining the conversation until those requests arrive captures the attack whole.

3. Distributed, sector-aware deception

The deception network is distributed across real sector and geographic context, so that what it observes reflects attacks aimed at the kinds of organizations it represents, not undifferentiated internet noise.

3.1 Realism and relevance

Campaigns are typically scoped by industry and region before they are scoped to an individual organization. Deception nodes carrying authentic sector and regional context are therefore reached by the same targeting logic that reaches real organizations in those sectors. This improves realism, makes easy fingerprinting harder, and makes the resulting intelligence materially relevant to the organizations it serves.

Realism also holds within each interaction. Application personas (Section 2.3) stay consistent across a product's whole surface and reflect a plausible patch state, so cross-checking endpoints or testing a known exploit does not expose the sensor.

Unused IP space can be redirected into the network to support this collection. Traffic arriving at address space with no production use has no legitimate destination. Every interaction is, by construction, attacker-initiated.

3.2 Relevance at collection, not after ingestion

Conventional feeds are sold on breadth: hundreds of thousands of indicators, few of which will ever intersect a subscriber's network. The subscriber bears the cost of storing, correlating and ranking the remainder.

Sector-aware collection inverts this model. Relevance is established at the point of collection rather than by scoring applied afterwards. No ranking stage is required, because irrelevant volume is never collected.

3.3 Customer-owned address space

At the Enterprise tier, an organization can route its own unused, routable IP ranges into the deception network. Traffic reaching those ranges is directed at that organization specifically.

The same analysis described in this paper is then scoped to that traffic: customer-specific deception telemetry, attacker behavior intelligence, and IOCs extracted from the customer's own address space. Deployment is a routing change rather than a software installation, and initial observations are typically available within two hours of activation.

4. Intelligence production

The intelligence engine converts captured interactions into campaign-level intelligence by reasoning about what traffic does, not what it matches. The platform maintains no signature set, no indicator lists and no malware family database. Every assessment is computed from telemetry the network collects directly.

4.1 Pipeline

1. Capture. Record reconnaissance, protocol fingerprinting, exploitation attempts, staged file transfer, malware delivery, shell command injection, endpoint abuse and administrative enumeration.
2. Interpret. Separate broad internet background noise from meaningful reconnaissance, active exploitation, malware staging and follow-on behavior.
3. Reconstruct campaigns. Group related events by infrastructure, payload characteristics, request structure, timing and campaign logic.
4. Map infrastructure. Trace scanning nodes, payload staging servers, callback hosts and malware delivery hosts.
5. Enrich across modules. Route suspicious binaries, URLs and newly disclosed vulnerabilities into the specialized analysis modules.
6. Operationalize. Publish the result as a report, STIX 2.1 indicators and machine-consumable feeds.

4.2 Behavioral classification from attack primitives

Detection looks for attack primitives rather than known exploit strings. These include exploitation artifacts, shell metacharacter injection, parameter abuse, protocol misuse, manipulation of configuration templates, misuse of administrative handlers, and command download chains.

Because classification works at this level, the engine handles evasion directly. Obfuscated traversal paths are normalized before classification. Encoded payloads are decoded to the commands they carry. Known obfuscation tactics, such as split keywords, mixed case and nested lookups in Log4j strings, are recognized as obfuscation rather than allowed to defeat matching.

Traffic is classified into reconnaissance, exploitation, malware delivery, credential harvesting and command-and-control-related behavior. Each actor is also placed on an attack-progression scale, for example "moving from enumeration into probing" or "pure enumeration with no observed follow-on exploitation".

4.3 Campaign correlation

Campaigns are formed from shared behavior, not shared addresses. Multiple IPs that sweep the same admin path across the same port sequence are grouped as one coordinated operation, even when they come from different hosts. Activity against different products can be merged at the level of attacker intent, for example as a single effort to inventory administrative interfaces.

4.4 Temporal and statistical analysis

The engine measures properties that only emerge across many events or long windows:

• Port-selection entropy. Measuring how a source distributes connections across thousands of ports distinguishes deliberate randomization by automated survey tooling from targeted probing.
• Cadence. Hosts that connect only once every few days are identified as low-and-slow probers, a pattern built to evade rate-based detection, and clustered by provider range and shared timing.
• Cross-port behavior. Sweeps alternating common and rare ports are identified as attempts to map firewall behavior.

4.5 Analyst-style explanation

Each finding is written up as an assessment: why it matters, what it likely represents, and how to interpret it. Competing explanations are ranked by likelihood when evidence is thin. Recommendations are specific to the observed surface. The aim is to lower cognitive load and the skill barrier for acting on the intelligence, reducing dependence on scarce senior analysts.

5. Behavior first, CVE second: the pre-CVE signal

The Observatory separates detection from vulnerability attribution, and that separation is what produces its emerging-exploitation and 0-day signal.

5.1 Two stages

In the first stage, behavior is detected and classified on its own terms (Section 4). In the second, the classified behavior is correlated against vulnerability intelligence drawn from OSINT. A CVE is attached only where the observed behavior supports it.

A CVE-first system works in the opposite order: it writes a rule for a known CVE and counts matches. It cannot see exploitation for which no rule exists. A behavior-first system sees everything that arrives, and attribution is a second question.

5.2 Calibrated attribution

Every CVE mapping carries an explicit confidence level, chosen according to the evidence.

MITRE ATT&CK techniques are mapped the same way, each with its own confidence. For a file-read exploitation attempt, initial access (T1190) and active scanning (T1595) can be rated high while file and directory discovery (T1083) is rated medium: the read was attempted, but its success cannot be known from the attacker side.

5.3 The residual as signal

Behavior that is exploitation-relevant but maps to no known CVE is the residual of the correlation step. The Observatory surfaces it through two channels:

• Campaign level. A campaign whose behavior has no CVE mapping carries a "Possible 0-day" marker. Novelty and severity are independent axes: an unmapped campaign consisting of survey scanning can be marked "Possible 0-day" and still rated Low.
• Within mapped campaigns. Unmapped components of a campaign that otherwise matches known CVEs are raised in the edition's "Emerging activity" section. A typical case is an actor who replays a known exploit against one product and then extends the same technique to adjacent frameworks and endpoints for which no CVE exists.

The Observatory reports these as candidates, not confirmed 0-days. Its editions state explicitly when observed activity is n-day exploitation and when no 0-day weaponization was seen. That calibration is what makes the signal usable: a candidate is a lead to watch, raised at first contact, before any public label exists.

6. Report anatomy

Each weekly edition is generated automatically from the reporting period it covers, with no analyst in the loop, and is available as soon as the period closes. The intelligence is therefore current rather than retrospective.

An edition is layered from overall judgement down to individual indicators:

Every campaign card follows the same structure:

• Narrative of what the actor did, in sequence.
• Targeted technologies and techniques.
• CVEs with confidence level (Section 5.2).
• MITRE ATT&CK tactics and techniques, each with confidence.
• Assessment: interpretation, likely intent, and recommended actions.
• Indicators (IPv4) and an expandable STIX 2.1 bundle.

The STIX output is standard. Each indicator is a STIX 2.1 indicator object, typed malicious-activity, with an ipv4-addr pattern and a valid_from timestamp set at first sighting, ready for ingestion by a TIP or SIEM.

7. Detection patterns

The classes of activity below show how collection and analysis combine. For each, the point is what the deception network must do for the observation to exist, and what the analysis derives from it.

7.1 Toolchain exploitation extending into undocumented endpoints

An actor targets a development server on its default, non-standard port. The network infers HTTP and sustains the conversation through a chained sequence: file-system access through framework-specific prefixes, traversal fragments hidden in module identifiers, and query suffixes that force files to be served in alternative formats.

The analysis decodes crafted payloads, such as encoded import statements wrapped in proxy objects, to establish what the actor is trying to achieve. It maps the core pattern to known CVEs with stated confidence and places the actor on the attack-progression scale.

When the same actor then extends the technique to adjacent frameworks and endpoints with no CVE, those extensions are raised as emerging activity. The actor's search for new primitives is observable only because the emulation stays believable across the whole sequence.

7.2 Weaponized RCE with an encoded download chain

An actor probes a high-numbered port typical of admin or monitoring consoles, requests environment and secret files, then sends a JNDI injection string. The lookups point to an external callback host and carry commands encoded in Base64.

The analysis:

• Decodes the command line, for example a silent download and execution of a cryptominer script from a staging listener.
• Recognizes obfuscation layered into the injection string, such as split keywords, mixed case, nested lookups and loopback hostnames.
• Maps the infrastructure: attacker source, callback host and staging server.
• Maps the full chain across MITRE ATT&CK, from initial access to impact.
• Attributes the CVE as confirmed and states whether the activity is n-day or novel.
• Links secret-file probing to the exploit when the actor pursues several objectives.

The complete weaponized payload, its delivery command and its staging infrastructure are captured and interpreted without executing anything.

7.3 Coordinated sweeps across non-standard ports

A group of hosts probes the same admin login path across an incrementally increasing series of non-standard ports. Because every port answers in the expected protocol, the sweep is visible as one coordinated campaign. On a fixed deployment most of those ports would be closed, and the activity would look like scattered connection attempts.

The analysis identifies the tooling's purpose, such as locating admin frontends moved to non-default ports, and maps any product-specific requests to their known vulnerabilities.

7.4 Reconnaissance as stage one of a known chain

A single request to a product-specific path, for example an error page in a collaboration platform's layouts directory, can be the first stage of a known pre-auth RCE chain. The analysis places it at that stage and records the related CVE as unconfirmed when no exploit body is present. Identifying stage one tells defenders which stage two to expect.

7.5 Multiple protocols on one port

An actor sends an HTTP traversal request to an HTTPS port, then non-HTTP payloads to the same port. Because protocol is inferred per connection, both are engaged and correlated to the same actor.

The analysis distinguishes misconfiguration abuse, such as reading an exposed repository configuration file, from exploitation of a software flaw. It records no CVE where none applies and rates initial-access techniques accordingly.

7.6 Unknown services and management planes

• Unknown service probes. A request to an unusual port carrying a parameter that matches no known product is engaged and logged. The analysis ranks plausible explanations, such as backdoor discovery or research into a niche service, and places the source on a watch list.
• Management and update planes. An attacker addresses an emulated endpoint as an agent update server, sending structured metadata about architecture, OS and versions. The analysis identifies reconnaissance against remote-management infrastructure even when no CVE applies.

These findings exist only because an unanticipated service was engaged in the protocol the attacker chose.

8. Operational integration

The Observatory is the starting point for the platform's intelligence, not a standalone report. Its output is built to move directly into defensive workflows.

• Indicators. Every campaign exports STIX 2.1, ready for threat intelligence platforms and SIEMs.
• Feeds and API. At the Enterprise tier, the platform's API-first backend exposes machine-consumable feeds: malicious IPs, C2 infrastructure, malware files, phishing URLs and domains, and darknet observations. Entries carry assessed risk level, geographic metadata and recommended actions, for SIEM, SOAR, TIP and detection-engineering pipelines.
• Cross-module enrichment. Suspicious binaries, URLs, leak references, access-sale indicators and newly disclosed vulnerabilities observed in campaigns are routed into the Malware Analysis, Phishing Analysis, Investigations, Leaks and Initial Access Broker, and Recent Vulnerabilities modules.
• Actionable guidance. Each assessment names the exposed surface and the defensive response. For Log4j exploitation, for example, the assessment recommends updating or mitigating all Log4j instances, monitoring for outbound LDAP, RMI and DNS callbacks to untrusted hosts, and protecting environment-file locations with strict access controls and non-default paths.

The Threat Observatory is included in the Pro and Enterprise tiers, together with first-party attacker telemetry, current attacker behavior intelligence, behavioral campaign correlation, emerging exploitation detection, and unmapped / pre-CVE behavior detection.

9. Design scope

The Observatory is designed for the external, early stages of the attack lifecycle: reconnaissance, exploitation attempts, protocol misuse and first-stage delivery. These are the stages where campaigns are developed, tested and staged, before they reach a victim's network.

It deliberately does not emulate a compromised host or post-exploitation activity. Intelligence about delivery comes from the captured commands and their infrastructure: a decoded download command identifies the payload, its staging host and the actor's objective.

Each edition reports what was observed in its window. The mix of activity varies week to week with attacker behavior: some weeks are dominated by reconnaissance and n-day exploitation, others include fully weaponized payload delivery or unmapped techniques. The same pipeline captures and analyzes all of them.

10. Conclusion

The Threat Observatory sees exploitation at first contact, including exploitation nobody has labeled yet, because it removes the two dependencies that make conventional intelligence late.

AI-driven protocol and application inference removes the dependency on anticipating targets, so services that other honeypots never deploy and other reports never cover are observed too. Attackers are engaged in whatever protocol they choose, on whatever port, by a consistent persona of the product they are hunting, for as long as it takes them to deliver the attack. Behavior-first analysis removes the dependency on prior labels. Payloads are understood by what they do, and CVE attribution follows with stated confidence, leaving unmapped behavior visible as an early signal.

Together, these make visible what conventional intelligence sees late or not at all: actors hunting for new primitives in modern software stacks, weaponized payloads decoded to their objective and infrastructure, coordinated sweeps across hundreds of ports, and unknown services engaged in unexpected protocols. The result is published weekly, automatically, as campaign intelligence ready for action.

Sources

• DEKENEAS Cyber Threat Intelligence product description