« Newly Observed ScreenConnect Host Server Port Forwarding Rule Addition »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.20

Outlook Home Page Registry Modification

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Outlook Home Page Registry Modification

edit

Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.registry-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Tactic: Persistence
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender for Endpoint
  • Data Source: SentinelOne
  • Resources: Investigation Guide
  • Data Source: Crowdstrike

Version: 208

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Outlook Home Page Registry Modification

Possible investigation steps

  • What does the written registry value tell you about the configured Outlook content target?
  • Focus: registry.path, registry.value, registry.data.type, and registry.data.strings, plus which Outlook folder or Today page the key controls.
  • Hint: check for a deletion on the same registry.path after the alert time — if removed, urgency shifts to post-exploitation cleanup or transient testing. If a loopback or localhost URL is present, check for COM object registrations (CLSID entries) serving content on that port.
  • Implication: a loopback or localhost URL with a non-standard port is a strong indicator of Specula-style COM server abuse — do not treat it as benign internal traffic. External URLs, local HTML files, and UNC paths also support concern. The investigation path is narrower only when the target uses a non-loopback internal hostname or a path consistent with enterprise branding.
  • Which process wrote the setting, and does the writer context fit expected Outlook administration?
  • Focus: process.executable, process.code_signature.subject_name, process.code_signature.trusted, and user.id.
  • Hint: if the direct writer is a broker or service process, check Effective_process.executable for the true initiator. If signer fields are absent on the registry event, recover the writer from surrounding process telemetry.
  • Implication: the writer context is harder to justify when a script host, LOLBin, unsigned, or user-writable binary writes the key, or when the user context does not match known Outlook administration tooling; it is more explainable when the writer is a signed deployment or profile-management tool with a recognized signer.
  • What does the target URL or path resolve to, and does it fit a known abuse pattern?
  • Focus: the written target in registry.data.strings; for URL targets, review same-host DNS "lookup_result" and connection events with dns.question.name, dns.resolved_ip, and destination.ip; for path targets, pivot to file.path on the same host.id.
  • Hint: if the target is a UNC path, confirm whether the same host reached the backing server in surrounding connection activity and whether a local file.path copy was staged before Outlook could render it.
  • Implication: external URLs to rare domains or public IPs, user-writable HTML files, and unrecognized network shares support concern. The target is less concerning when it resolves to a recognized enterprise portal or branding content path. Missing corroborating network or file telemetry is unresolved, not benign.
  • Do file events or Outlook process events show the target being staged or activated?
  • Focus: same-host file activity tied to the writer or target path (file.path, file.origin_url, file.Ext.windows.zone_identifier), and Outlook or Office process events (process.executable, process.parent.executable) that access the configured target.
  • Hint: for URL targets, correlate Outlook activity to the same resolved IPs or domains; for local or UNC paths, look for the same path being opened after the write.
  • Implication: concern rises when the writer stages HTML or script content in user-writable locations and Outlook reaches the same target, or when the modified profile triggers suspicious child or network activity. Absence of staging or activation does not clear the registry write but reduces immediate execution risk.
  • If the local evidence stays suspicious, how did the account authenticate to this host before the registry write?
  • Why: writing the Outlook Home Page key requires HKCU hive access, so the session origin can reveal compromised credentials, lateral movement, or unexpected remote access.
  • Focus: if Windows Security logs are ingested, query authentication events for user.id and host.id around the alert time, checking winlog.logon.type, source.ip, and winlog.event_data.AuthenticationPackageName. If authentication data is unavailable, fall back to process.Ext.session_info.logon_type from the writer’s process event.
  • Implication: supports concern when the session originated from an unexpected source IP, used an unusual logon type or authentication package, or cannot be tied to the user’s normal access pattern for this host.
  • If the local evidence stays suspicious, does this host show related alerts or adjacent Outlook Home Page variants?
  • Focus: related alerts for the same host.id and user.id in the last 48 hours to identify precursor delivery, suspicious Office execution, network command-and-control, or additional persistence activity on the same asset or user.
  • !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broader compromise when the asset also shows delivery, suspicious Office execution, or follow-on persistence alerts; stays locally bounded when surrounding host alerts are limited to routine administration or unrelated benign activity.
  • Escalate when the registry change, writer context, target resolution, execution evidence, and alert scope align on unauthorized Outlook customization or persistence; close only when all evidence fits a recognized Outlook customization or profile-management workflow; if mixed or incomplete, preserve and escalate.

False positive analysis

  • Enterprise branding, profile migration, or configuration-management tooling can legitimately write these keys. Confirm when the registry.path family, registry.data.strings target, and writer identity all match the same customization or deployment workflow, with no staged external content or divergent infrastructure.
  • Before creating an exception, build on the specific registry.data.strings value, process.code_signature.subject_name or Effective_process.executable, and the specific registry.path family. Avoid exceptions on registry.value alone, user.name alone, or the entire Outlook registry subtree.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the confirmed registry.path family, registry.data.strings target, and writer identity that proved the Outlook customization workflow. Create an exception using the same registry.data.strings value, writer signer, and registry.path family.
  • If suspicious but unconfirmed, preserve the modified registry.path, written value data, recovered process.entity_id, writer identity, any staged file.path content, and any related destination or alert context. Apply reversible containment first, such as blocking the page target or limiting Outlook use on the affected host, and avoid destructive cleanup until scope is clearer.
  • If confirmed malicious, document the recovered process.entity_id, process.command_line, process.code_signature.subject_name, registry.data.strings target, and the modified registry.path values before initiating response actions. Use available endpoint response integrations to contain the affected host or account when the writer, target, staging, or activation evidence indicates unauthorized Outlook Home Page abuse. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act.
  • Restore the affected Outlook Webview or Today values to a known-good state, remove any malicious local HTML or script content identified during the investigation, and block confirmed malicious domains, IPs, or network shares referenced by the page target.
  • If the target points to external infrastructure or a shared path, review proxy, DNS, firewall, and related-alert data for additional hosts or users that reached the same content, then scope any follow-on delivery or persistence activity found on those assets.
  • After containment, review whether Outlook Home Page functionality is still needed in the environment and restrict who can manage those settings.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
registry where host.os.type == "windows" and event.action != "deletion" and registry.value : "URL" and
    registry.path : (
        "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\*",
        "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Today\\*"
    ) and registry.data.strings : ("*://*", "*:\\*", "\\\\*\\*")

Framework: MITRE ATT&CKTM

« Newly Observed ScreenConnect Host Server Port Forwarding Rule Addition »