Reply to thread

Message

<blockquote data-quote="Andy Ful" data-source="post: 1054186" data-attributes="member: 32260">The example posted by <a href="https://malwaretips.com/goto/post?id=1054148" target="_blank">Gandalf_The_Grey</a> is interesting. The .NET executables can read the data from external resources and create the DLLs filelessly (in memory). Many malware can do it too. If the external resource is modified by the attacker, then the legal .NET executable will create the DLL with malicious code.This method is similar to DLL hijacking, but instead of using malicious DLL, the attacker replaces the original resource with a malicious one. This method can be a challenge for many AVs.I can predict such attacks, but I do not know how popular they can be.The dynamic code trust verification can be skipped in WDAC by skipping in the policy the option:&nbsp;&lt;Option&gt; Enabled: Dynamic Code Security &lt;/Option&gt;It is skipped in Smart App Control. I may consider skipping it in WHH.</blockquote>

[QUOTE="Andy Ful, post: 1054186, member: 32260"] The example posted by [URL='https://malwaretips.com/goto/post?id=1054148']Gandalf_The_Grey[/URL] is interesting. The .NET executables can read the data from external resources and create the DLLs filelessly (in memory). Many malware can do it too. If the external resource is modified by the attacker, then the legal .NET executable will create the DLL with malicious code. This method is similar to DLL hijacking, but instead of using malicious DLL, the attacker replaces the original resource with a malicious one. This method can be a challenge for many AVs. I can predict such attacks, but I do not know how popular they can be. The dynamic code trust verification can be skipped in WDAC by skipping in the policy the option: <Option> Enabled: Dynamic Code Security </Option> It is skipped in Smart App Control. I may consider skipping it in WHH. [/QUOTE]

Verification