Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1294: Analytic 1294

Untrusted processes creating outbound TLS/HTTPS connections with malformed certificates or header fields, often mismatched with target service behavior. Detects protocol impersonation attempts via traffic metadata analysis and host process lineage.

EnterpriseAN1294AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because it focuses on Windows processes that appear to be making outbound HTTPS/TLS connections in ways that do not look like normal service behavior, such as malformed certificates or suspicious header fields. For leaders, the decision value is whether the organization can distinguish legitimate encrypted business traffic from protocol impersonation attempts without relying only on payload inspection.

Executive priority

Prioritize this as a visibility and resilience question: do SOC and IR teams have enough endpoint process lineage and network metadata to explain which Windows process opened an outbound encrypted connection, where it went, and whether the TLS/HTTPS characteristics matched expected behavior? This supports incident triage, managed detection validation, and audit evidence for monitoring of outbound communications, but it requires local baselining because ATT&CK supplies no specific tactic, relationship context, or formal detection logic for this analytic.

Technical view

Validate whether Windows endpoint telemetry can be joined with outbound TLS/HTTPS metadata. The analytic’s core is correlation: an untrusted or unexpected process creates an outbound encrypted connection, and the traffic shows malformed certificate or header characteristics or behavior mismatched to the target service. Detection engineering should test process lineage, destination context, TLS certificate fields, HTTP header metadata, and expected application-to-service patterns. Because no official detection query is provided, teams should build environment-specific baselines and tune for legitimate software that uses custom TLS stacks, proxies, inspection tools, or unusual update mechanisms.

Likely telemetry

  • Windows process creation and parent/child process lineage
  • Outbound network connection records tied to host process identity
  • TLS handshake metadata, including certificate attributes and validation anomalies
  • HTTPS/HTTP header metadata where available
  • Destination service, domain, IP, port, and reputation/context metadata

Detection direction

  • Confirm that network events can be attributed back to the originating Windows process, not only to the host or user.
  • Baseline normal TLS/HTTPS behavior for common browsers, updaters, agents, and business applications before alerting on malformed or mismatched fields.
  • Look for combinations of weak signals rather than a single malformed field: unusual process lineage, unexpected destination, certificate/header irregularities, and service-behavior mismatch.
  • Tune carefully for false positives from security inspection infrastructure, enterprise proxies, legacy applications, development tools, and software using nonstandard TLS libraries.
  • Document blind spots where encrypted traffic metadata, certificate details, or endpoint-to-network correlation is not retained.

Mitigation priorities

  • Improve collection first: ensure Windows endpoint process lineage and outbound connection telemetry are retained and searchable.
  • Standardize network metadata capture for TLS/HTTPS sessions, including certificate and header-relevant fields where policy and tooling allow.
  • Define trusted process and destination baselines for business-critical applications and approved update channels.
  • Use allowlisting, egress controls, and proxy policy to reduce unexpected outbound encrypted connections where operationally feasible.
  • Prepare IR playbooks to quickly answer: which process connected, who launched it, what certificate/header anomalies were observed, and whether the destination behavior was expected.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic, not a technique. It is scoped to Windows and describes traffic metadata analysis combined with host process lineage. There are no supplied relationships, tactics, mitigations, data components, or official detection query, so this take emphasizes validation questions and telemetry requirements rather than a prescribed rule.

No active exploitation, attribution, impact, tactic mapping, or guaranteed detection coverage is supported by the supplied fields. Local environment baselines are required to determine what is untrusted, malformed, or mismatched for a given organization.

Official MITRE ATT&CK definition

Analytic 1294

Untrusted processes creating outbound TLS/HTTPS connections with malformed certificates or header fields, often mismatched with target service behavior. Detects protocol impersonation attempts via traffic metadata analysis and host process lineage.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
cfc1b0ed33864b94...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle cfc1b0ed3386…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1294
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.