{ "id": "0230f717-f07f-46e8-b86f-80d657d626a7", "created_at": "2026-04-06T00:22:33.27251Z", "updated_at": "2026-04-10T03:24:29.076838Z", "deleted_at": null, "sha1_hash": "3863af9b3a1ad53e5d23225f79b400974c90a9d7", "title": "Dismantling Smart App Control", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1332776, "plain_text": "Dismantling Smart App Control\r\nBy Joe Desimone\r\nPublished: 2024-08-06 · Archived: 2026-04-05 19:53:58 UTC\r\nIntroduction\r\nReputation-based protections like Elastic’s reputation service can significantly improve detection capabilities\r\nwhile maintaining low false positive rates. However, like any protection capability, weaknesses exist and bypasses\r\nare possible. Understanding these weaknesses allows defenders to focus their detection engineering on key\r\ncoverage gaps. This article will explore Windows Smart App Control and SmartScreen as a case study for\r\nresearching bypasses to reputation-based systems, then demonstrate detections to cover those weaknesses.\r\nKey Takeaways:\r\nWindows Smart App Control and SmartScreen have several design weaknesses that allow attackers to gain\r\ninitial access with no security warnings or popups.\r\nA bug in the handling of LNK files can also bypass these security controls\r\nDefenders should understand the limitations of these OS features and implement detections in their security\r\nstack to compensate\r\nSmartScreen/SAC Background\r\nMicrosoft SmartScreen has been a built-in OS feature since Windows 8. It operates on files that have the “Mark of\r\nthe Web” (MotW) and are clicked on by users. Microsoft introduced Smart App Control (SAC) with the release of\r\nWindows 11. SAC is, in some ways, an evolution of SmartScreen. Microsoft says it “adds significant protection\r\nfrom new and emerging threats by blocking apps that are malicious or untrusted.” It works by querying a\r\nMicrosoft cloud service when applications are executed. If they are known to be safe, they are allowed to execute;\r\nhowever, if they are unknown, they will only be executed if they have a valid code signing signature. When SAC\r\nis enabled, it replaces and disables Defender SmartScreen.\r\nMicrosoft exposes undocumented APIs for querying the trust level of files for SmartScreen and Smart App\r\nControl. To help with this research, we developed a utility that will display the trust of a file. The source code for\r\nthis utility is available here.\r\nSigned Malware\r\nOne way to bypass Smart App Control is to simply sign malware with a code-signing certificate. Even before\r\nSAC, there has been a trend towards attackers signing their malware to evade detection. More recently, attackers\r\nhave routinely obtained Extend Validation (EV) signing certificates. EV certs require proof of identity to gain\r\naccess and can only exist on specially designed hardware tokens, making them difficult to steal. However,\r\nattackers have found ways to impersonate businesses and purchase these certificates. The threat group behind\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 1 of 8\n\nSolarMarker has leveraged over 100 unique signing certificates across their campaigns. Certificate Authorities\r\n(CAs) should do more to crack down on abuse and minimize fraudulently-acquired certificates. More public\r\nresearch may be necessary to apply pressure on the CAs who are most often selling fraudulent certificates.\r\nReputation Hijacking\r\nReputation hijacking is a generic attack paradigm on reputation-based malware protection systems. It is analogous\r\nto the misplaced trust research by Casey Smith and others against application control systems, as well as the\r\nvulnerable driver research from Gabriel Landau and I. Unfortunately, the attack surface in this case is even larger.\r\nReputation hijacking involves finding and repurposing apps with a good reputation to bypass the system. To work\r\nas an initial access vector, one constraint is that the application must be controlled without any command line\r\nparameters—for example, a script host that loads and executes a script at a predictable file path.\r\nScript hosts are an ideal target for a reputation hijacking attack. This is especially true if they include a foreign\r\nfunction interface (FFI) capability. With FFI, attackers can easily load and execute arbitrary code and malware in\r\nmemory. Through searches in VirusTotal and GitHub, we identified many script hosts that have a known good\r\nreputation and can be co-opted for full code execution. This includes Lua, Node.js, and AutoHotkey interpreters. A\r\nsample to demonstrate this technique is available here.\r\nThe following video demonstrates hijacking with the JamPlus build utility to bypass Smart App Control with no\r\nsecurity warnings:\r\nIn another example, SmartScreen security warnings were bypassed by using a known AutoHotkey interpreter:\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 2 of 8\n\nAnother avenue to hijack the reputation of a known application is to exploit it. This could be simple, like a classic\r\nbuffer overflow from reading an INI file in a predictable path. It could be something more complex that chains off\r\nother primitives (like command execution/registry write/etc). Also, multiple known apps can be chained together\r\nto achieve full code execution. For example, one application that reads a configuration file and executes a\r\ncommand line parameter can then be used to launch another known application that requires a set of parameters to\r\ngain arbitrary code execution.\r\nReputation Seeding\r\nAnother attack on reputation protections is to seed attacker-controlled binaries into the system. If crafted carefully,\r\nthese binaries can appear benign and achieve a good reputation while still being useful to attackers later. It could\r\nsimply be a new script host binary, an application with a known vulnerability, or an application that has a useful\r\nprimitive. On the other hand, it could be a binary that contains embedded malicious code but only activates after a\r\ncertain date or environmental trigger.\r\nSmart App Control appears vulnerable to seeding. After executing a sample on one machine, it received a good\r\nlabel after approximately 2 hours. We noted that basic anti-emulation techniques seemed to be a factor in\r\nreceiving a benign verdict or reputation. Fortunately, SmartScreen appears to have a higher global prevalence bar\r\nbefore trusting an application. A sample that demonstrates this technique is available here and is demonstrated\r\nbelow:\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 3 of 8\n\nReputation Tampering\r\nA third attack class against reputation systems is reputation tampering. Normally, reputation systems use\r\ncryptographically secure hashing systems to make tampering infeasible. However, we noticed that certain\r\nmodifications to a file did not seem to change the reputation for SAC. SAC may use fuzzy hashing or feature-based similarity comparisons in lieu of or in addition to standard file hashing. It may also leverage an ML model\r\nin the cloud to allow files that have a highly benign score (such as being very similar to known good).\r\nSurprisingly, some code sections could be modified without losing their associated reputation. Through trial and\r\nerror, we could identify segments that could be safely tampered with and keep the same reputation. We crafted one\r\ntampered binary with a unique hash that had never been seen by Microsoft or SAC. This embedded an “execute\r\ncalc” shellcode and could be executed with SAC in enforcement mode:\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 4 of 8\n\nLNK Stomping\r\nWhen a user downloads a file, the browser will create an associated “Zone.Identifier” file in an alternate data\r\nstream known as the Mark of the Web (MotW). This lets other software (including AV and EDR) on the system\r\nknow that the file is more risky. SmartScreen only scans files with the Mark of the Web. SAC completely blocks\r\ncertain file types if they have it. This makes MotW bypasses an interesting research target, as it can usually lead to\r\nbypassing these security systems. Financially motivated threat groups have discovered and leveraged multiple\r\nvulnerabilities to bypass MotW checks. These techniques involved appending crafted and invalid code signing\r\nsignatures to javascript or MSI files.\r\nDuring our research, we stumbled upon another MotW bypass that is trivial to exploit. It involves crafting LNK\r\nfiles that have non-standard target paths or internal structures. When clicked, these LNK files are modified by\r\nexplorer.exe with the canonical formatting. This modification leads to removal of the MotW label before security\r\nchecks are performed. The function that overwrites the LNK files is _SaveAsLink() as shown in the following\r\ncall stack:\r\nThe function that performs the security check is CheckSmartScreen() as shown in the following call stack:\r\nThe easiest demonstration of this issue is to append a dot or space to the target executable path (e.g.,\r\npowershell.exe. ). Alternatively, one can create an LNK file that contains a relative path such as\r\n.\\target.exe . After clicking the link, explorer.exe will search for and find the matching .exe name,\r\nautomatically correct the full path, update the file on disk (removing MotW), and finally launch the target. Yet\r\nanother variant involves crafting a multi-level path in a single entry of the LNK’s target path array. The target path\r\narray should normally have 1 entry per directory. The pylnk3 utility shows the structure of an exploit LNK (non-canonical format) before and after execution (canonical format):\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 5 of 8\n\nA Python script that demonstrates these techniques is available here.\r\nThe following shows an LNK file bypassing MotW restrictions under Smart App Control to launch Powershell\r\nand pop calc:\r\nIn another example, we show this technique chained with the Microsoft cdb command line debugger to achieve\r\narbitrary code execution and execute shellcode to pop calc:\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 6 of 8\n\nWe identified multiple samples in VirusTotal that exhibit the bug, demonstrating existing in the wild usage. The\r\noldest sample identified was submitted over 6 years ago. We also disclosed details of the bug to the MSRC. It may\r\nbe fixed in a future Windows update. We are releasing this information, along with detection logic and\r\ncountermeasures, to help defenders identify this activity until a patch is available.\r\nDetections\r\nReputation hijacking, by its nature, can be difficult to detect. Countless applications can be co-opted to carry out\r\nthe technique. Cataloging and blocking applications known to be abused is an initial (and continual) step.\r\nprocess where process.parent.name == \"explorer.exe\" and process.hash.sha256 in (\r\n\"ba35b8b4346b79b8bb4f97360025cb6befaf501b03149a3b5fef8f07bdf265c7\", // AutoHotKey\r\n\"4e213bd0a127f1bb24c4c0d971c2727097b04eed9c6e62a57110d168ccc3ba10\" // JamPlus\r\n)\r\nHowever, this approach will always lag behind attackers. A slightly more robust approach is to develop behavioral\r\nsignatures to identify general categories of abused software. For example, we can look for common Lua or\r\nNode.js function names or modules in suspicious call stacks:\r\nsequence by process.entity_id with maxspan=1m\r\n[library where\r\n (dll.Ext.relative_file_creation_time \u003c= 3600 or\r\n dll.Ext.relative_file_name_modify_time \u003c= 3600 or\r\n (dll.Ext.device.product_id : (\"Virtual DVD-ROM\", \"Virtual Disk\",\"USB *\") and not dll.path : \"C:\\\\*\")) and\r\n _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: \"*!luaopen_*\")] by dll.hash.sha256\r\n[api where\r\n process.Ext.api.behaviors : (\"shellcode\", \"allocate_shellcode\", \"execute_shellcode\", \"unbacked_rwx\", \"rwx\", \"ho\r\n process.thread.Ext.call_stack_final_user_module.hash.sha256 : \"?*\"] by process.thread.Ext.call_stack_final_user\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 7 of 8\n\napi where process.Ext.api.name : (\"VirtualProtect*\", \"WriteProcessMemory\", \"VirtualAlloc*\", \"MapViewOfFile*\") a\r\n process.Ext.api.behaviors : (\"shellcode\", \"allocate_shellcode\", \"execute_shellcode\", \"unbacked_rwx\", \"rwx\", \"ho\r\n process.thread.Ext.call_stack_final_user_module.name : \"ffi_bindings.node\"\r\nSecurity teams should pay particular attention to downloaded files. They can use local reputation to identify\r\noutliers in their environment for closer inspection.\r\nfrom logs-* |\r\nwhere host.os.type == \"windows\"\r\nand event.category == \"process\" and event.action == \"start\"\r\nand process.parent.name == \"explorer.exe\"\r\nand (process.executable like \"*Downloads*\" or process.executable like \"*Temp*\")\r\nand process.hash.sha256 is not null\r\n| eval process.name = replace(process.name, \" \\\\(1\\\\).\", \".\")\r\n| stats hosts = count_distinct(agent.id) by process.name, process.hash.sha256\r\n| where hosts == 1\r\nLNK stomping may have many variants, making signature-based detection on LNK files difficult. However, they\r\nshould all trigger a similar behavioral signal- explorer.exe overwriting an LNK file. This is especially\r\nanomalous in the downloads folder or when the LNK has the Mark of the Web.\r\nfile where event.action == \"overwrite\" and file.extension : \"lnk\" and\r\n process.name : \"explorer.exe\" and process.thread.Ext.call_stack_summary : \"ntdll.dll|*|windows.storage.dll|shel\r\n (\r\n file.path : (\"?:\\\\Users\\\\*\\\\Downloads\\\\*.lnk\", \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\*.lnk\") or\r\n file.Ext.windows.zone_identifier == 3\r\n )\r\nFinally, robust behavioral coverage around common attacker techniques such as in-memory evasion, persistence,\r\ncredential access, enumeration, and lateral movement helps detect realistic intrusions, including from reputation\r\nhijacking.\r\nConclusion\r\nReputation-based protection systems are a powerful layer for blocking commodity malware. However, like any\r\nprotection technique, they have weaknesses that can be bypassed with some care. Smart App Control and\r\nSmartScreen have a number of fundamental design weaknesses that can allow for initial access with no security\r\nwarnings and minimal user interaction. Security teams should scrutinize downloads carefully in their detection\r\nstack and not rely solely on OS-native security features for protection in this area.\r\nSource: https://www.elastic.co/security-labs/dismantling-smart-app-control\r\nhttps://www.elastic.co/security-labs/dismantling-smart-app-control\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.elastic.co/security-labs/dismantling-smart-app-control" ], "report_names": [ "dismantling-smart-app-control" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434953, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3863af9b3a1ad53e5d23225f79b400974c90a9d7.pdf", "text": "https://archive.orkl.eu/3863af9b3a1ad53e5d23225f79b400974c90a9d7.txt", "img": "https://archive.orkl.eu/3863af9b3a1ad53e5d23225f79b400974c90a9d7.jpg" } }