Hard_Configurator - Windows Hardening Configurator

[Glynn]

That is the problem for some users when using advanced PDF features. The partial solution is installing the latest Adobe Reader DC and tick the option 'Run in App Container'.

Yes i figured as much, tried all of the pdf readers - nada, installed DC and it worked, thanks for the tip about app container. I think i'll just restore my clean system backup, after i printed the stupid document(all this without internet access ofc).

 

[shmu26]

Like Andy said, you can use a simple PDF reader like Sumatra as the default reader, or use Edge in Windows 10 as the default reader.
Then you can use Adobe manually, and only when you really need it.

 

[Glynn]

Like Andy said, you can use a simple PDF reader like Sumatra as the default reader, or use Edge in Windows 10 as the default reader.
Then you can use Adobe manually, and only when you really need it.

Thank you shmu, unfortunately im paranoid as hell, and i do not want Adobe DC attack surface anywhere near my pc. Fortunately i made an image backup before plunging into installing DC, also no need for 3rd party pdf readers. I just use the built-in reader in chrome, also gmail is using it's own document reader.

 

[shmu26]

@Andy Ful there is no practical way to control rundll32, correct?

EDIT: Okay, I see that you can enable monitoring of dlls, it will block dlls in user space that are not whitelisted.

Log does not display blocked dlls, as far as I can tell. Any good way to know which dlls are being blocked?

 

[shmu26]

I see that there are lots of Microsoft dlls in temp folders in appdata.
And I don't see any safe way to whitelist them.
What to do?

 

[Andy Ful]

@Andy Ful there is no practical way to control rundll32, correct?

EDIT: Okay, I see that you can enable monitoring of dlls, it will block dlls in user space that are not whitelisted.

Log does not display blocked dlls, as far as I can tell. Any good way to know which dlls are being blocked?

.
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:

1. reflective DLL injections are not covered,
2. .NET DLLs are not covered,
3. it can have a negative impact on Windows performance.

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'.

 

[Andy Ful]

I see that there are lots of Microsoft dlls in temp folders in appdata.
And I don't see any safe way to whitelist them.
What to do?

I cannot see this in my system - the only DLLs are related to AppLocker (not supported in Windows Home and Pro) and OneDrive.
.
Anyway, is not easy to stop thinking that you are not using default-allow setup. Indeed in default-allow setup, the applications are usually allowed to run and then the security program has to decide if the application is going to do something malicious. Controlling DLLs can be important to recognize the danger.
In the default-deny setup, all new applications are simply blocked, and controlling DLLs is not so helpful anymore. One should only remember to close the infection vectors related to the potential exploits via: web pages, useful files which can have embedded active content (like MS Office documents, PDF documents, etc.), unpatched Windows, and unpatched applications. When using the ideal default-deny setup, there should be nothing in the system that could load/inject malicious DLLs. In the real world scenario, the probability of such events, while using default-deny setup, should be very low.
It would be nice to have the ability to control only some special DLLs to block PowerShell etc., but there is no such possibility on Windows Home (and Pro).

 

[shmu26]

It is not easy to stop thinking that you are not using default-allow setup. Indeed in default-allow setup, the applications are usually allowed to run and then the security program has to decide if the application is going to do something malicious. Controlling DLLs can be important to recognize the danger.
In the default-deny setup, all new applications are simply blocked, and controlling DLLs is not so helpful. One should only remember to close the infection vectors related to web pages, useful files which can have embedded active content (MS Office documents, PDF documents, etc.), unpatched Windows, and unpatched applications. When using the ideal default-deny setup, there should be nothing in the system that could load malicious DLLs. In the real system probability of such event should be very low.
It would be nice to have the ability to control only some special DLLs to block PowerShell etc., but there is no such possibility on Windows Home (and Pro).

Thanks. I do have my exploitable apps locked down pretty tight. So my concerns are more theoretical than real.

Regarding the many Microsoft dlls in the appdata temp folders: I realized that aside from OneDrive, these dlls will be loaded by processes running with system privileges, so it is not an issue. They won't be blocked.

 

[Andy Ful]

Thanks. I do have my exploitable apps locked down pretty tight. So my concerns are more theoretical than real.

Regarding the many Microsoft dlls in the appdata temp folders: I realized that aside from OneDrive, these dlls will be loaded by processes running with system privileges, so it is not an issue. They won't be blocked.

That is strange. I have only ApplockerAuditDll.dll (not used in Windows Home and Pro) and OneDrive DLLs in my UserProfile.
All other DLLs used by the system and Windows apps should be located in Windows and Program Files folders.

 

[shmu26]

That is strange. I have only ApplockerAuditDll.dll (not used in Windows Home and Pro) and OneDrive DLLs in my UserProfile.
All other DLLs used by the system and Windows apps should be located in Windows and Program Files folders.

Attached is a screenshot of a few of these files.

But besides the appdata ones, there are also many Microsoft dlls in Programdata. I see that you already have Defender whitelisted, so no prob there.

It is not so hard to do a quick search in appdata and programdata, and find out which program folders (including OneDrive) have dlls, and whitelist the path with *.dll.
It doesn't look like anything in the temp folders needs whitelisting, so should be okay.

 

[shmu26]

Is there a way to add additional sponsors?
What about processes like
sc.exe
schtasks.exe
at.exe

and others such as those on ERP 4 VulnerableProcesses.xml ?

 

[Andy Ful]

Attached is a screenshot of a few of these files.

But besides the appdata ones, there are also many Microsoft dlls in Programdata. I see that you already have the Defender dlls whitelisted.
View attachment 187211

.
I see. The DLLs in the Temp folder are installation leftovers. But, system installations are executed with higher rights, so SRP will ignore them.
The folder:
'C:\ProgramData\Microsoft\Windows Defender'
is whitelisted by Hard_Configurator - it is not writable as standard user.
I have also the ppcrlconfig600.dll in ProgramData - it is possibly related to Microsoft Account.

 

[Andy Ful]

Is there a way to add additional sponsors?
What about processes like
sc.exe
schtasks.exe
at.exe

and others such as those on ERP 4 VulnerableProcesses.xml ?

The sponsors will be probably updated in one of the next versions, but I think that they are not very helpful in default-deny setup for the home users. Blocking the sponsors can be useful when you have the setup with unpatched vulnerabilities or unprotected vulnerable applications, or temporarily when the computer is used in the unsafe environment. Actual sponsors included in Hard_Configurator, are well tested and generally do not break Windows Updates. Adding more sponsors sooner or later will cause the problems and probably no one will use this feature.
This topic requires the further discussion.

 

[shmu26]

The sponsors will be probably updated in one of the next versions, but I think that they are not very helpful in default-deny setup for the home users. Blocking the sponsors can be useful when you have the setup with unpatched vulnerabilities or unprotected vulnerable applications, or temporarily when the computer is used in the unsafe environment. Actual sponsors included in Hard_Configurator, are well tested and generally do not break Windows Updates. Adding more sponsors sooner or later will cause the problems and probably no one will use this feature.
This topic requires the further discussion.

Thanks.
I understand your position on the sponsors. And you are right.
Nevertheless, I would be happy if you could add a few more -- whichever ones you think are the most important.
It is hard to convince home users to give up their beloved but highly exploitable apps. They will hold on to M$ Office and Adobe Reader, for various reasons, no matter what alternatives you offer them.
You could mark some sponsors as "high risk", and some as "experimental", and then if the user still insists on borking his system, it is not your fault.

 

[Andy Ful]

Thanks.
I understand your position on the sponsors. And you are right.
Nevertheless, I would be happy if you could add a few more -- whichever ones you think are the most important.
It is hard to convince home users to give up their beloved but highly exploitable apps. They will hold on to M$ Office and Adobe Reader, for various reasons, no matter what alternatives you offer them.
You could mark some sponsors as "high risk", and some as "experimental", and then if the user still insists on borking his system, it is not your fault.

I know that MS Office is unbeatable, because there are some reasons for that. The most important reason is document compatibility, when sharing documents with other people. Most companies use MS Office and it is practical for people who work for them to have MS Office installed on their own computers. The same can be true for the students. So for example, about 2/3 MalwareTips members probably use MS Office (yes, I read the thread about it).
That is why I am not trying to convince anybody to drop his/her favorite Office suite. I am trying to convince some users, that on Windows 10, it is worth to install the second Office suite, that works fully in App Container to view/print documents from unsafe sources. They will be much safer with this, losing only a little convenience. And, this will work also for the average users.
This is the same philosophy, as avoiding to use the car for shopping, when one can get the same by going 200 m on foot (it is much healthier).
Of course, the car is still very useful when the shop is 5 miles away.

 

[shmu26]

I know that MS Office is unbeatable, because there are some reasons for that. The most important reason is document compatibility, when sharing documents with other people. Most companies use MS Office and it is practical for people who work for them to have MS Office installed on their own computers. The same can be true for the students. So for example, about 2/3 MalwareTips members probably use MS Office (yes, I read the thread about it).
That is why I am not trying to convince anybody to drop his/her favorite Office suite. I am trying to convince some users, that on Windows 10, it is worth to install the second Office suite, that works fully in App Container to view/print documents from unsafe sources. They will be much safer with this, losing only a little convenience. And, this will work also for the average users.
This is the same philosophy, as avoiding to use the car for shopping, when one can get the same by going 200 m on foot (it is much healthier).
Of course, the car is still very useful when the shop is 5 miles away.

I checked out the Office mobile apps. Yeah, that's a good idea.
I set the supported file types to open by default in Mobile.
This solution will work well, until malcoders figure out how to attach malware to a doc composed by a person you know, so you will be tricked into opening it in the full application, to edit it.
Then, we will have to edit our docs online.

 

[Av Gurus]

Can you please tell what are this "sponsors "?
TNX

 

[shmu26]

Can you please tell what are this "sponsors "?
TNX

It is what most of us call vulnerable processes. Here is a partial list:

 

[Andy Ful]

I checked out the Office mobile apps. Yeah, that's a good idea.
I set the supported file types to open by default in Mobile.
This solution will work well, until malcoders figure out how to attach malware to a doc composed by a person you know, so you will be tricked into opening it in the full application, to edit it.
Then, we will have to edit our docs online.

There is no need to edit files from known persons, so you still can view them via secure Office viewers.

 

[shmu26]

There is no need to edit files from known persons, so you still can view them via secure Office viewers.

There is no need, unless your job is editor...