Reply to thread

Message

<blockquote data-quote="Andy Ful" data-source="post: 729784" data-attributes="member: 32260">.In fact, you have a decent prevention against malicious DLLs. In the default-deny setup and recommended by me configuration related to the web browser, malicious documents etc., there is (close to) nothing that could load malicious DLLs. That is the idea of default-deny. That is true for updated Windows 10 which is hard to exploited (especially on SUA).Controlling DLLs is important in default-allow setup or when you are using vulnerable (not patched and not protected) applications like MS Office 2007. A malicious document can easily cause execution of DLLs and also the shellcode.There is a way to control DLLs via SRP, but like most other monitoring DLL solutions, it is inefficient:<ol>
<li data-xf-list-type="ol">reflective DLL injections are not covered,</li>
<li data-xf-list-type="ol">.NET DLLs are not covered,</li>
<li data-xf-list-type="ol">it can have a negative impact on Windows performance.</li>
</ol>There is also a method to log DLLs using &lt;Tools&gt; &lt;Turn On Advanced SRP Logging&gt; in Hard_Configurator. The entries in the log are related only to processes running with Administrative rights. So, if you are interested to see what DLLs are loaded by the concrete application, then you have to run it via &#039;Run As SmartScreen&#039;.</blockquote>

[QUOTE="Andy Ful, post: 729784, member: 32260"] . In fact, you have a decent prevention against malicious DLLs. In the default-deny setup and recommended by me configuration related to the web browser, malicious documents etc., there is (close to) nothing that could load malicious DLLs. That is the idea of default-deny. That is true for updated Windows 10 which is hard to exploited (especially on SUA). Controlling DLLs is important in default-allow setup or when you are using vulnerable (not patched and not protected) applications like MS Office 2007. A malicious document can easily cause execution of DLLs and also the shellcode. There is a way to control DLLs via SRP, but like most other monitoring DLL solutions, it is inefficient: [LIST=1] [*]reflective DLL injections are not covered, [*].NET DLLs are not covered, [*]it can have a negative impact on Windows performance. [/LIST] There is also a method to log DLLs using <Tools> <Turn On Advanced SRP Logging> in Hard_Configurator. The entries in the log are related only to processes running with Administrative rights. So, if you are interested to see what DLLs are loaded by the concrete application, then you have to run it via 'Run As SmartScreen'. [/QUOTE]

Verification