<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>TeamViewer Germany GmbH — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/teamviewer-germany-gmbh/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 12 May 2026 19:11:31 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/teamviewer-germany-gmbh/feed.xml" rel="self" type="application/rss+xml"/><item><title>Process Created with an Elevated Token via Token Theft</title><link>https://feed.craftedsignal.io/briefs/2026-05-process-created-with-elevated-token/</link><pubDate>Tue, 12 May 2026 19:11:31 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-process-created-with-elevated-token/</guid><description>This rule detects the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary, which adversaries may leverage to escalate privileges and bypass access controls through token theft.</description><content:encoded><![CDATA[<p>This detection rule identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. The technique, often referred to as token theft, allows adversaries to escalate privileges and bypass access controls by creating a new process with a different token. The rule focuses on detecting instances where a process is initiated with the SYSTEM user ID (S-1-5-18) and its effective parent process is a privileged Microsoft native binary located in a standard Windows directory. This activity is indicative of an attempt to hijack a legitimate system process&rsquo;s token for malicious purposes. This can lead to full system compromise.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to the system, potentially through phishing or exploiting a vulnerability.</li>
<li>The attacker identifies a privileged Windows process, such as a service running as SYSTEM, as a target for token theft.</li>
<li>The attacker uses the <code>CreateProcessWithTokenW</code> API (or similar) to create a new process.</li>
<li>The new process is configured to run under the security context (token) of the targeted privileged process.</li>
<li>The attacker then executes malicious code within the context of the newly created process.</li>
<li>This malicious code now operates with SYSTEM-level privileges, bypassing normal access controls.</li>
<li>The attacker can then use these elevated privileges to install malware, modify system settings, or steal sensitive data.</li>
<li>Finally, the adversary achieves persistence and control of the system.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows attackers to perform any action on the system with the highest privileges. This includes installing malware, accessing sensitive data, creating new user accounts with administrative rights, and disabling security controls. The impact is a complete compromise of the affected system. The Elastic rule has a risk score of 73 and is classified as high severity.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable Elastic Defend to collect the necessary process creation events, as specified in the <a href="https://ela.st/install-elastic-defend">setup instructions</a>.</li>
<li>Deploy the provided Sigma rule to your SIEM to detect processes created with elevated tokens. Tune the rule based on observed false positives in your environment.</li>
<li>Investigate any alerts generated by the Sigma rule by examining the process tree, focusing on the <code>user.id</code>, <code>process.executable</code>, <code>process.parent.executable</code>, and <code>process.Ext.effective_parent.executable</code> fields as outlined in the rule&rsquo;s <code>note</code> section.</li>
<li>Review and validate any exceptions before implementing them, ensuring that the exact child/parent/effective-parent pattern is stable for the same host or managed host group, and avoid broad exceptions.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>privilege-escalation</category><category>token-theft</category><category>windows</category></item><item><title>Privilege Elevation via Parent Process PID Spoofing</title><link>https://feed.craftedsignal.io/briefs/2026-05-privilege-elevation-via-ppid-spoofing/</link><pubDate>Tue, 12 May 2026 19:10:58 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-privilege-elevation-via-ppid-spoofing/</guid><description>This rule detects parent process spoofing used to create an elevated child process, specifically targeting privilege escalation to SYSTEM, where adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges on Windows systems.</description><content:encoded><![CDATA[<p>This detection identifies a technique known as parent process ID (PPID) spoofing used to elevate privileges on Windows systems. PPID spoofing involves creating a new process with a spoofed parent process ID to evade process monitoring defenses or gain higher privileges. This is achieved by manipulating the <code>UpdateProcThreadAttribute</code> API. The detection specifically looks for processes running as SYSTEM (<code>user.id : &quot;S-1-5-18&quot;</code>) where the real parent PID (<code>process.parent.Ext.real.pid</code>) differs from the reported parent PID, which could indicate spoofing. The rule aims to identify privilege escalation attempts while excluding common false positives like Windows Error Reporting, update processes, and certain third-party software. This behavior matters for defenders because successful PPID spoofing can allow attackers to execute malicious code with elevated privileges, potentially leading to complete system compromise.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to the system, potentially through exploitation of a vulnerability or social engineering.</li>
<li>The attacker executes a malicious program or script designed to perform PPID spoofing.</li>
<li>The malicious program uses the <code>UpdateProcThreadAttribute</code> API to set a custom parent process ID (PPID) for a new process.</li>
<li>The attacker attempts to create a new process with SYSTEM privileges, often through the <code>seclogon</code> service. The new process inherits the spoofed PPID.</li>
<li>The system creates the new process with the specified (spoofed) parent PID, while the <code>Ext.real.pid</code> reflects the true creator process.</li>
<li>The spoofed process executes malicious commands, leveraging SYSTEM privileges. This could involve installing backdoors, modifying system configurations, or stealing sensitive data.</li>
<li>The attacker attempts to move laterally within the network, utilizing the compromised system as a launchpad.</li>
<li>The final objective could be data exfiltration, ransomware deployment, or long-term persistence within the environment.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful PPID spoofing can grant attackers SYSTEM-level privileges, allowing them to perform virtually any action on the compromised system. This can lead to data theft, system corruption, or the installation of persistent backdoors. A single compromised system can serve as a beachhead for further attacks within the network. The potential damage includes significant financial losses, reputational damage, and disruption of business operations. The rule is designed to detect this activity before significant damage occurs by identifying the initial elevation of privileges via PPID spoofing.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the provided Sigma rules to your SIEM to detect potential PPID spoofing attempts, focusing on the processes running as SYSTEM with mismatched parent PIDs (<code>process.parent.Ext.real.pid</code> vs <code>process.parent.pid</code>).</li>
<li>Enable process creation logging with full command-line auditing to capture the necessary data for the Sigma rules to function effectively.</li>
<li>Investigate any alerts generated by the Sigma rules by examining the parent and child processes, as well as the user context and command-line arguments.</li>
<li>Implement application control policies to restrict the execution of unauthorized or untrusted executables, mitigating the risk of malicious code execution via PPID spoofing.</li>
<li>Review and harden the configuration of systems with elevated privileges to minimize the potential impact of successful privilege escalation attacks.</li>
<li>Tune the Sigma rules based on your environment to reduce false positives by excluding known-benign processes and applications.</li>
<li>Consult the references for more context on PPID spoofing and mitigation strategies.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>privilege-escalation</category><category>windows</category><category>ppid-spoofing</category></item></channel></rss>