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

T1216.002: SyncAppvPublishingServer

Adversaries may abuse SyncAppvPublishingServer.vbs to proxy execution of malicious PowerShell commands. SyncAppvPublishingServer.vbs is a Visual Basic script associated with how Windows virtualizes applications (Microsoft Application Virtualization, or App-V).[1] For example, Windows may render Win32 applications to users as virtual applications, allowing users to launch and interact with them as if they were installed locally.[2][3] The SyncAppvPublishingServer.vbs script is legitimate, may be signed by Microsoft, and is commonly executed from `\System32` through the command line via `wscript.exe`.[4][5]

Adversaries may abuse SyncAppvPublishingServer.vbs to bypass PowerShell execution restrictions and evade defensive counter measures by "living off the land."[6][4] Proxying execution may function as a trusted/signed alternative to directly invoking `powershell.exe`.[7]

For example, PowerShell commands may be invoked using:[5]

`SyncAppvPublishingServer.vbs "n; {PowerShell}"`

EnterpriseT1216.002Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

SyncAppvPublishingServer.vbs matters because it is a legitimate Windows App-V script that can be used as a trusted proxy for PowerShell execution. For leaders, the risk is not the script itself, but whether endpoint controls and SOC monitoring can distinguish normal Windows/App-V activity from attempts to hide PowerShell behind signed system components.

Executive priority

Prioritize this as a Windows defense-evasion validation item. It is relevant to operational resilience and audit evidence because it tests whether execution prevention, script controls, and detection engineering cover “living off the land” abuse rather than only obvious use of powershell.exe. Security leaders should ask whether App-V is actually used in the environment, whether this script is expected to run, and whether exceptions in application control create blind spots.

Technical view

This is a Windows sub-technique under System Script Proxy Execution. The supplied ATT&CK context describes abuse of SyncAppvPublishingServer.vbs, commonly launched from System32 through wscript.exe, to proxy PowerShell commands and potentially bypass direct PowerShell execution restrictions. SOC and IR teams should validate DET0440-aligned logic for PowerShell execution via SyncAppvPublishingServer.vbs proxy abuse, correlate parent-child process behavior involving wscript.exe and the script, and review command-line content where collected. Because official detection text is not provided in the object, local detection design should be tested against expected App-V administrative activity and endpoint logging reality.

Likely telemetry

  • Windows process creation events with command-line arguments
  • Parent-child process relationships involving wscript.exe and SyncAppvPublishingServer.vbs
  • Script execution telemetry for Visual Basic Script activity
  • PowerShell-related telemetry when commands are proxied rather than launched directly
  • Application control or script-blocking allow/deny events

Detection direction

  • Validate whether DET0440 or equivalent analytics identify PowerShell execution proxied through SyncAppvPublishingServer.vbs, not just direct powershell.exe execution.
  • Baseline legitimate App-V usage before alerting aggressively; environments not using App-V may treat execution of this script as higher signal.
  • Tune for command-line patterns, script path, parent process, user context, host role, and proximity to other suspicious PowerShell activity.
  • Check blind spots where command-line logging, script telemetry, or parent-child process data are missing or filtered.
  • Account for false positives from legitimate App-V publishing or administrative workflows where this script is expected.

Mitigation priorities

  • Use M1038 Execution Prevention as the primary control direction: implement application control and script blocking appropriate to Windows endpoints.
  • Review whether SyncAppvPublishingServer.vbs is needed in the environment, especially where App-V is not used.
  • Constrain script execution paths and interpreters where business operations allow, while avoiding broad exceptions for signed Microsoft scripts without behavioral monitoring.
  • Ensure PowerShell restrictions are not the only control; monitor and control trusted script proxies that can invoke PowerShell indirectly.
  • Document approved App-V and script execution behavior for compliance evidence and incident response triage.
Analyst notes and limits

This object is a Windows sub-technique for stealth/defense-evasion style behavior involving a legitimate Microsoft-associated App-V script. Relationship context provides one detection strategy, DET0440, and one mitigation, M1038 Execution Prevention. The most useful local question is whether the organization can observe and control indirect PowerShell execution through signed system scripts.

The official ATT&CK object does not provide a detection section, and the supplied relationship context does not include detailed DET0440 logic. This take therefore avoids claiming detection coverage or exploitation prevalence. Local App-V use, logging configuration, application control policy, and normal administrative workflows are required to determine severity and alerting thresholds.

Official MITRE ATT&CK definition

SyncAppvPublishingServer

Adversaries may abuse SyncAppvPublishingServer.vbs to proxy execution of malicious PowerShell commands. SyncAppvPublishingServer.vbs is a Visual Basic script associated with how Windows virtualizes applications (Microsoft Application Virtualization, or App-V).[1] For example, Windows may render Win32 applications to users as virtual applications, allowing users to launch and interact with them as if they were installed locally.[2][3] The SyncAppvPublishingServer.vbs script is legitimate, may be signed by Microsoft, and is commonly executed from `\System32` through the command line via `wscript.exe`.[4][5]

Adversaries may abuse SyncAppvPublishingServer.vbs to bypass PowerShell execution restrictions and evade defensive counter measures by "living off the land."[6][4] Proxying execution may function as a trusted/signed alternative to directly invoking `powershell.exe`.[7]

For example, PowerShell commands may be invoked using:[5]

`SyncAppvPublishingServer.vbs "n; {PowerShell}"`

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1216 System Script Proxy Execution This object subtechnique of System Script Proxy Execution.
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1038: Execution Prevention Enterprise detects · Detection Strategy DET0440: Detecting PowerShell Execution via SyncAppvPublishingServer.vbs Proxy Abuse Enterprise subtechnique of · Technique T1216: System Script Proxy Execution Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

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
2.0
Created
Modified
Raw hash
c0b67570e9ee9b8f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle c0b67570e9ee…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    1 - appv

    SEONGSU PARK. (2022, December 27). BlueNoroff introduces new methods bypassing MoTW. Retrieved February 6, 2024.

    Open source URL
  2. [2]
    2 - appv

    Microsoft. (2022, November 3). Getting started with App-V for Windows client. Retrieved February 6, 2024.

    Open source URL
  3. [3]
    3 - appv

    Raj Chandel. (2022, March 17). Indirect Command Execution: Defense Evasion (T1202). Retrieved February 6, 2024.

    Open source URL
  4. [4]
    4 - appv

    John Fokker. (2022, March 17). Suspected DarkHotel APT activity update. Retrieved February 6, 2024.

    Open source URL
  5. [5]
    5 - appv

    Nick Landers, Casey Smith. (n.d.). /Syncappvpublishingserver.vbs. Retrieved February 6, 2024.

    Open source URL
  6. [6]
    6 - appv

    Strontic. (n.d.). SyncAppvPublishingServer.exe. Retrieved February 6, 2024.

    Open source URL
  7. [7]
    7 - appv

    Nick Landers. (2017, August 8). Need a signed alternative to Powershell.exe? SyncAppvPublishingServer in Win10 has got you covered.. Retrieved September 12, 2024.

    Open source URL
  8. [8]
    mitre-attack T1216.002
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use