[Request for explaination] why does it look like only the user that install the tool get restricted ?

[nobur]

Hi,

There is something that look a little weird in the implementation. When Raccine is call viaimage file execution options, I guess that is it looking for a temporary folder to process yara files. (RaccineUserContext if I'm correct). If this folder doens't exist, it seems that yara file are not processed and the program is run whatever it's safe or not.

The problem is that this folder is created by RaccineSettings.exe which is launched via a registry value placed in HKCU ( the profile of the user who did the installation =>surely an IT admin). Any other user or remote execution that don't load a user profile will fall in the case explainned just above.

Are my guessings correct ? how can we solve that issue ? Can't we just create the folder in the Raccine.exe itself if it doesn't exist instead of in the RaccineSettings.exe?

thanks for your answer.

[nobur]

It look like I was pointing to the right direction. I did some more tests that confirmed my thoughts.

I made the following adjustment in the RaccineLib/Raccine.h to move temp folder to a common one : #define RACCINE_USER_CONTEXT_DIRECTORY L"%ALLUSERSPROFILE%\\RaccineUserContext\\%USERNAME%" then added few lines in the correponding Raccine.cpp :

ExpandEnvironmentStringsW(RACCINE_USER_CONTEXT_DIRECTORY, wTestFilename, ARRAYSIZE(wTestFilename) - 1);

>    if (std::filesystem::create_directories(wTestFilename) == false) {
>        if (raccine_config.is_debug_mode()) {
>            wprintf(L"Unable to create temporary user folder: %s\n", wTestFilename);
>        }
>    }

and the problem seems to be solved ( for now... ). Under W2008, this creates a folder in c:\programdata named RaccineUserContext and a subfolder per user to avoid collisions (I wasn't sure it could not happen...). The parent folder will always exist even if the user doesn't have any profile folder. This is a quick and dirty modification that should be reviewed and tested by some more skilled persons but that does rougthly the job.

[Neo23x0]

Shouldn't we just put the RaccineSettings.exe RUN key entry into HKLM? In this case, RaccineSettings.exe should load in any user session and create the folder within %TEMP% itself.

[nobur]

I see 2 reasons : 1- this will still rely on the user profile loading. Any program that doesn't load a user profile will not be restricted (like psexec.exe -e) 2- RaccineSettings is more (in my opinion) an optional feature. AFAIK, the folder creation is the only technical requirement that make it launch mandatory to make Raccine.exe to work properly.

In conclusion: moving RaccineSettings.exe to HKLM Run key can be a good option to ensure every interactive user will get alert popups and configuration capabilities but we should also be sure that Raccine will work properly even if RaccineSettings had never been launch.

Adding the folder existence test/creation directly in the Raccine.exe protect us from users that simply delete the temp folder to bypass the protection as it will be recreated every time if needed (I'm not a professional programmer, if I could find this weakness, more skilled people surely can also).

This is only "My" point of view. It could be nice to have someone else's remarks and suggestions....

[Neo23x0]

Any program that doesn't load a user profile will not be restricted (like psexec.exe -e)

Has anyone seen Ransomware loaders that don't execute in a user context or loaded user profile. Raccine's main purpose is Ransomware protection. It protects systems on which a user opens a weaponized document from an infection.

If there is Ransomware that doesn't load a user profile, there is more need to handle this problem.

[Neo23x0]

You may ask, "why not?" I'd also like to add the security problem that is caused by making the RACCINE_USER_CONTEXT_DIRECTORY folder a publicly accessible folder. Process command lines, which get stored within that folder, may contain sensitive information, like an API key, a session token or a password. We are somehow reluctant to expose all process command line parameters of everyone working on that system to everyone else working on the same system.

That's why I'd like to make this small assessment regarding the necessity of the change.

[nobur]

An "in between" solution can be to change folder permission to something more restrictive upon creation (need a little more research...).

"Has anyone seen Ransomware loaders that don't execute in a user context or loaded user profile." I not really up-to-date about that but i guess a huge amount of those used to ransom companies do.

You said Raccine main purpose is Ransomware protection. Weaponized document is one of the possible intrusion medium. Once on a network, it mostly propagate itself using other methods ( i.e. scheduled tasks run as system, remote shell/powershell scripts, ...) . If device A got compromised (unprotected device), if it can get domain permissions, it can spread to device B. As it more probably be run with another account that the one that is connected on device B (system ?) it then can run without any restriction.

Whatever the solution, the goal should be to ensure that Raccine is always executed properly regardless the account used and if this account has a profile loaded or not.

I'm not a security nor active directory expert. I've just been recently asked by our company security team to deploy your solution widely on all our domain controller to avoid an attack as a quick fix solution. Domain controllers are priority targets for hackers that want to ransom an organization and is precisely a case were multiple users can logon on a single server.

[nobur]

A short question, what kind of file are stored in the temporary folder ? I didn't point the privacy issue because every time I've looked in those directories, they were empty. I dumbly thought they were only use to compile and process rules and that command lines details remains in memory. if command line details are stored on the disk, this always represents a privacy risk. Every one that can get elevated to local admin rights can retrieve user's sensitive information he should not aware of.

If you're on a personal device, you're probably the only known user meaning no one else that you can logon then the risk of someone else come retrieve sensitive information is quite low were ever you place files. It starts to be a concern when several users can logon then every possible users should be restricted.

Another possible solution could be to simply delete the created file right after they have been used.

[Neo23x0]

A short question, what kind of file are stored in the temporary folder?

The process command line information of the respective process.

Another possible solution could be to simply delete the created file right after they have been used.

That's why you see that folder as empty. They exist for some milliseconds and then get deleted.

but i guess a huge amount of those used to ransom companies do

If the entry vector is email / attachments than most likely "no, they're not". In case of spreading by remote exploitation of services then probably "yes, possible".

So, to get back to the actual problem. You say, that the current RACCINE_USER_CONTEXT_DIRECTORY set to %TEMP%\\RaccineUserContext causes problems, because in sessions that don't load a user profile the folder set in %TEMP% doesn't exist, right. This folder would be C:\Users\username\AppData\Local\Temp in cases a user named username logs in. E.g. in case of a LOCAL_SYSTEM context, this should be C:\WINDOWS\system32\config\systemprofile\AppData\Local\Temp.

I'll add your fix that creates the folder but won't change it to a subfolder of %ProgramData%. If a process environment doesn't have a %TEMP% var than it most likely also lacks the %ProgramData% or %AllUserProfile% env varibles.

[nobur]

Sounds good to me. regarding TEMP var: in our case if you don't load any profile you fall back to the SYSTEM one. TEMP is then set to c:\windows\temp not C:\WINDOWS\system32\config\systemprofile\AppData\Local\Temp