Jump to content

Welcome to Geeks to Go
Geeks to Go Welcome
Create Account Login to Account
Photo

FRST Tutorial Comment

* * * * * 1 votes
Started by emeraldnzl , Nov 18 2013 06:52 PM
FRST farbar tutorial

  • Please log in to reply
184 replies to this topic

#106
BrianDrab
Posted 11 July 2016 - 07:07 PM

BrianDrab

    Trusted Helper

  • Malware Removal
  • 3,591 posts

I personally think that SetDefaultFilePermissions: should only be used on files or folders that will remain on the OPs system. The reason is that the owner will be set but usually leaves all permissions blank. The OP can then set permissions as desired or if the OP isn't experienced you can set them through a script but this can be more work than it's worth.

 

Unlock: sets the owner as well as giving permissions to Everyone. So it leaves the file or folder wide open as far as permissions go. But if the intent is to remove these files then it makes perfect sense. This one also can work on registry keys.

 

So it gives you a choice.


  • 0

Advertisements

#107
picasso
Posted 11 July 2016 - 07:55 PM

picasso

    Trusted Helper

  • Malware Removal
  • 205 posts
  • MVP

What is the Different between SetDefaultFilePermissions: and Unlock: ?

 
Example of corrupted permissions:
 

*****************
ListPermissions: C:\Windows\regedit.exe
*****************

===================================
permissions of "C:\Windows\regedit.exe":

Owner: some strange account or blank

DACL(PAI):

{EMPTY}

===================================

 
 
SetDefaultFilePermissions: results:
 

===================================
permissions of "C:\Windows\regedit.exe":

Owner: BUILTIN\Administrators

DACL(PAI):

BUILTIN\Administrators    ALLOW    FULL    (NI)
NT AUTHORITY\SYSTEM    ALLOW    FULL    (NI)
BUILTIN\Users    ALLOW    READ/EXECUTE    (NI)
NT AUTHORITY\Authenticated Users    ALLOW    MODIFY    (NI)
NT SERVICE\TrustedInstaller    ALLOW    FULL    (NI)

===================================

 
EDIT: Corrected.
 
 
Unlock: results:
 

===================================
permissions of "C:\Windows\regedit.exe":

Owner: EVERYONE

DACL(PAI):

EVERYONE    ALLOW    FULL    (NI)

===================================

 
 
It looks that this part is incorrect:
 

Unlock:

This directive, in the case of files/directories, sets group "Administrator" as owner, grants access to everyone and works recursively when applied on directories. It should be used for bad files/directories.

 
EDIT: Corrected.


Edited by picasso, 14 July 2016 - 11:36 AM.

  • 0

#108
Herman_Salim
Posted 12 July 2016 - 05:47 AM

Herman_Salim

    Member

  • Member
  • PipPip
  • 36 posts

I am not an expert in the various Microsoft OSs but here are my thoughts.

SetDefaultFilePermissions: in general, sets permissions that might have been changed by malware, back to their default position. FRST sets ownership to Administrator group.
However, system files controlled by TrustedInstaller will not be set back to their default position although the command can still be used for system files.

Unlock: where malware has blocked access this command sets ownership of the item as Administrator and grants access to all groups.
 
Someone with a better understanding may like to add or expand on what I have said. :)

 
 

I personally think that SetDefaultFilePermissions: should only be used on files or folders that will remain on the OPs system. The reason is that the owner will be set but usually leaves all permissions blank. The OP can then set permissions as desired or if the OP isn't experienced you can set them through a script but this can be more work than it's worth.
 
Unlock: sets the owner as well as giving permissions to Everyone. So it leaves the file or folder wide open as far as permissions go. But if the intent is to remove these files then it makes perfect sense. This one also can work on registry keys.
 
So it gives you a choice.

 
 

Example of corrupted permissions:

(...)

 
Thank you very much emeraldnzl, BrianDrab, and picasso. All staff of Geeks to Go are very kind.. :spoton:
 
So, if we want to delete a bad files, better to use Unlock: than SetDefaultFilePermissions:, right?
 
SetDefaultFilePermissions: seems like repair.
 
Please correct me if I am wrong.


  • 0

#109
BrianDrab
Posted 12 July 2016 - 05:56 AM

BrianDrab

    Trusted Helper

  • Malware Removal
  • 3,591 posts

Thank you very much emeraldnzl, BrianDrab, and picasso. All staff of Geeks to Go are very kind..

 

So, if we want to delete a bad files, better to use Unlock: than SetDefaultFilePermissions:, right?

 

SetDefaultFilePermissions: seems like repair.

 

Please correct me if I am wrong.

 

Correct. But you only need to use Unlock: if you can't delete the file normally by simply listing the file path in a fixlist.txt file.


  • 0

#110
Herman_Salim
Posted 12 July 2016 - 09:52 AM

Herman_Salim

    Member

  • Member
  • PipPip
  • 36 posts

 

Thank you very much emeraldnzl, BrianDrab, and picasso. All staff of Geeks to Go are very kind..

 

So, if we want to delete a bad files, better to use Unlock: than SetDefaultFilePermissions:, right?

 

SetDefaultFilePermissions: seems like repair.

 

Please correct me if I am wrong.

 

Correct. But you only need to use Unlock: if you can't delete the file normally by simply listing the file path in a fixlist.txt file.

 

 

Thank you.. Very Clearly explanation from all of you..

 

So, what type of infection (or situasion) that we might use SetDefaultFilePermissions: ?

 

And how can we notice that from Farbar log?


  • 0

#111
picasso
Posted 13 July 2016 - 06:36 AM

picasso

    Trusted Helper

  • Malware Removal
  • 205 posts
  • MVP

So, what type of infection (or situasion) that we might use SetDefaultFilePermissions: ?

 

There is no stright answer. You just have to have some data proving that default file permissions are altered. In case you suspect the modification, just use ListPermissions: command on the file and compare the output with the same file from your system.

 

 

And how can we notice that from Farbar log?

 
In many cases there won't be any indication in the FRST log: a file not covered under Bamital & volsnap, placed in a folder not scanned by FRST, out of One Month scope.

 

In case a file is visible in a log a lack of permissions translates to an inability to get file properties and validate a digital signature:

 

==================== Bamital & volsnap =================

C:\Windows\explorer.exe
[2016-06-12 23:35] - [2015-11-25 07:12] - 4047288 ____A () D41D8CD98F00B204E9800998ECF8427E

C:\Windows\explorer.exe => no Company Name <===== ATTENTION

 

The file has a digital signature and Microsoft as Company, but due to the corrupted permissions FRST is not able to get the data. Note also the hash characteristic for an empty string. The output could be mistaken with a real file corruption, but running ListPermissions: command will tell you that the file is locked by permissions.

 

But there could be a situation that permissions are altered in such way that FRST will get the data, but permissions still need to be corrected.


  • 0

#112
Herman_Salim
Posted 13 July 2016 - 10:23 AM

Herman_Salim

    Member

  • Member
  • PipPip
  • 36 posts

==================== Bamital & volsnap =================

C:\Windows\explorer.exe
[2016-06-12 23:35] - [2015-11-25 07:12] - 4047288 ____A () D41D8CD98F00B204E9800998ECF8427E

C:\Windows\explorer.exe => no Company Name <===== ATTENTION

I had experienced a similar symptom like this.. Here is my case:

 

 

C:\Windows\system32\Drivers\volsnap.sys
[2010-11-21 10:23] - [2010-11-21 10:23] - 0295808 ____A () D41D8CD98F00B204E9800998ECF8427E

C:\Windows\system32\Drivers\volsnap.sys => no Company Name <===== ATTENTION
 

 

I never think about corrupted permission like yours explanation before. I just use this command in fixlist:

cmd: sfc /scanfile=C:\Windows\system32\Drivers\volsnap.sys

Never think about SetDefaultFilePermissions: before.


  • 0

#113
BrianDrab
Posted 13 July 2016 - 10:27 AM

BrianDrab

    Trusted Helper

  • Malware Removal
  • 3,591 posts

cmd: sfc /scanfile=C:\Windows\system32\Drivers\volsnap.sys

 

Works great on System files but if it's not a system file...


  • 0

#114
picasso
Posted 13 July 2016 - 11:04 AM

picasso

    Trusted Helper

  • Malware Removal
  • 205 posts
  • MVP
I had experienced a similar symptom like this.. Here is my case:

C:\Windows\system32\Drivers\volsnap.sys
[2010-11-21 10:23] - [2010-11-21 10:23] - 0295808 ____A () D41D8CD98F00B204E9800998ECF8427E

C:\Windows\system32\Drivers\volsnap.sys => no Company Name <===== ATTENTION

 

That is probably a different case. The output is produced by Necurs rootkit. The rootkit is locking an access to the system driver (and many others) by other method than permissions. Trying to "unlock" or "replace" the volsnap won't work and it is unnecessary. Removing the active Necurs driver will automatically unlock all locked Windows drivers.

 

Example topic

 

Before curing the rootkit (note false "not signed" = the drivers are locked by the rootkit, in fact they are signed, just no access to get the data)

 

Spoiler

 

After curing the rootkit (all drivers got unlocked):

 

Spoiler

  • 0

#115
Dragokas
Posted 13 July 2016 - 11:10 AM

Dragokas

    Malware Expert

  • Expert
  • 67 posts

Herman_Salim,

you are right, sfc is able to recover default permissions on system file.

 

Unfortunately, I do not know the tools that have been able to compare privileges of system files with default and recover them like in a freshly installed OS.

SFC can do some base checking on DACL corruption, but not much.

 

To understand more about importance of privileges:
imagine that some kind of a bad software replaced / updated system file and gave full rights for "Everyone" group.

Now, any program without administrator privileges can freely replace that file.

By default in Windows Vista+, only Trusted Installer service has full write access on system files.

Administrator (with UAC elevation passed) has only read/execute rights for security reasons.

 


Works great on System files but if it's not a system file...

It's a system file.

SfcIsFileProtected("C:\\Windows\\system32\\Drivers\\volsnap.sys") == true

HiJackThis log:


FileName - Is legitimate - (Microsoft, WFP)
-------------------------------------------
[OK] [MS] C:\Windows\system32\Drivers\volsnap.sys - legit. (Microsoft) (protected)


  • 0

Advertisements

#116
emeraldnzl
Posted 13 July 2016 - 05:41 PM

emeraldnzl

    GeekU Instructor

  • GeekU Moderator
  • 20,051 posts

This topic is only for questions specifically about the FRST tutorial.

 

This is not the place to discuss actual malware situations.

 

@ Herman_Salim,

 

Questions about malware infections should be asked in the Malware forum here.

 

Alternatively you should join a school to learn more about fighting malware, see post number 85. :)

 

 


  • 0

#117
Herman_Salim
Posted 14 July 2016 - 05:09 AM

Herman_Salim

    Member

  • Member
  • PipPip
  • 36 posts

 

I had experienced a similar symptom like this.. Here is my case:

C:\Windows\system32\Drivers\volsnap.sys
[2010-11-21 10:23] - [2010-11-21 10:23] - 0295808 ____A () D41D8CD98F00B204E9800998ECF8427E

C:\Windows\system32\Drivers\volsnap.sys => no Company Name <===== ATTENTION

 

That is probably a different case. The output is produced by Necurs rootkit. The rootkit is locking an access to the system driver (and many others) by other method than permissions. Trying to "unlock" or "replace" the volsnap won't work and it is unnecessary. Removing the active Necurs driver will automatically unlock all locked Windows drivers.

 

Example topic

 

Before curing the rootkit (note false "not signed" = the drivers are locked by the rootkit, in fact they are signed, just no access to get the data)

 

Spoiler

 

After curing the rootkit (all drivers got unlocked):

 

Spoiler

 

 

Yeah.. You're Right.. This is Necurs Rootkit. Thank you.. I can't Remove it even with Combofix.. Eventually, I use Malwarebyte to completely remove it.

 

 

 

Herman_Salim,

you are right, sfc is able to recover default permissions on system file.

 

Unfortunately, I do not know the tools that have been able to compare privileges of system files with default and recover them like in a freshly installed OS.

SFC can do some base checking on DACL corruption, but not much.

 

To understand more about importance of privileges:
imagine that some kind of a bad software replaced / updated system file and gave full rights for "Everyone" group.

Now, any program without administrator privileges can freely replace that file.

By default in Windows Vista+, only Trusted Installer service has full write access on system files.

Administrator (with UAC elevation passed) has only read/execute rights for security reasons.

 

 


Works great on System files but if it's not a system file...

It's a system file.

SfcIsFileProtected("C:\\Windows\\system32\\Drivers\\volsnap.sys") == true

HiJackThis log:

 


FileName - Is legitimate - (Microsoft, WFP)
-------------------------------------------
[OK] [MS] C:\Windows\system32\Drivers\volsnap.sys - legit. (Microsoft) (protected)

 

 

Yeah.. Thank you.. :yes:

 

This topic is only for questions specifically about the FRST tutorial.

 

This is not the place to discuss actual malware situations.

 

@ Herman_Salim,

 

Questions about malware infections should be asked in the Malware forum here.

 

Alternatively you should join a school to learn more about fighting malware, see post number 85. :)

 

 

 

This is not my system, my friend does. I've already solved it, i just flashback with Picasso's explanation.

 

Sorry if I ask too deep about Malware Situasions. :upset:

 

I've already apply to GeekU :D


  • 0

#118
emeraldnzl
Posted 14 July 2016 - 02:42 PM

emeraldnzl

    GeekU Instructor

  • GeekU Moderator
  • 20,051 posts

 

I've already apply to GeekU

 

Good luck with your application.


  • 0

#119
Herman_Salim
Posted 17 July 2016 - 03:19 AM

Herman_Salim

    Member

  • Member
  • PipPip
  • 36 posts

Hello..
 

CMD: bootrec /FixMbr

 

RestoreMbr:

 

What is the Difference between the two Commands above?

 

Thank you..


Edited by Herman_Salim, 17 July 2016 - 03:19 AM.

  • 0

#120
picasso
Posted 17 July 2016 - 05:06 AM

picasso

    Trusted Helper

  • Malware Removal
  • 205 posts
  • MVP

The difference is already stated in the tutorial description. The second command requires an external third-party tool and MBR dump made earlier by the tool.


  • 0
Back to Malware Removal Guides and Tutorials



Also tagged with one or more of these keywords: FRST, farbar, tutorial

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

  1. Geeks to Go Community
  2. → Security
  3. → Malware Removal Guides and Tutorials

As Featured On:

featured
Malware Removal How to Guides Windows 7 System Building Download Files Register welcome

Never used a forum? Learn how.