This is the place you can post if you have a question or comment about the FRST Tutorial.
Feedback is also important so if you have a comment please make it.
#1
Posted 18 November 2013 - 06:52 PM

#2
Posted 22 November 2013 - 06:12 PM

I will report that the links to the individual sub-topics in the table of contents do not work (screenshot)

#3
Posted 22 November 2013 - 06:32 PM

I works for me now.
Please check it and tell me if it works for you.

#4
Posted 23 November 2013 - 11:44 AM

Of a great simplicity, in addition to an excellent explanation.
My compliments to Farbar and geekstogo for publication.
Hello from italy.
#5
Posted 23 November 2013 - 01:05 PM

Hmm... Don't know what happened there.
I works for me now.
Please check it and tell me if it works for you.
Works for me now, thanks again!

#6
Posted 23 November 2013 - 01:06 PM

#7
Posted 13 December 2013 - 04:16 AM

However I have limited knowledge at this level of Windows.
My computer won't boot so I ran FRST from USB and got this report.
I really need some expert help as what to do next. I am not sure exactly what to remove or change.
Log removed.
See next post.
#8
Posted 13 December 2013 - 11:41 AM


This is a forum for questions about the Farbar Recovery Scan tool. It is not the place to post logs and request help.
It appears that you have a zero access infection. Please start a new topic in the Virus, Spyware, Malware Removal forum and post the FRST log there.
#9
Posted 11 January 2014 - 10:31 PM

#10
Posted 12 January 2014 - 12:03 AM

If you read the tutorial you will find an example under the Fixing section.
Check out under Bamital & volsnap Check.
This one:
Bamital & volsnap Check
Bamital and volsnap malware check.
Modified system files alert you to possible malware infection. Where infection is identified care needs to be taken with remedial action. Expert help should be sought as removal of a system file could render a machine unbootable.
When a malware made custom entry in BCD is found you will see the following line in the Bamital section:TDL4: custom:26000022 <===== ATTENTION!
#12
Posted 14 December 2014 - 11:41 PM

Is there any open database where we can check if MD5 for drivers is correct?
#13
Posted 15 December 2014 - 12:04 AM

There are some tools with data bases out there but I find that the ones I have used are not fully reliable.
If you are worried about a file why not try Virscan.
Go to VirSCAN.org FREE on-line scan service
#14
Posted 22 December 2014 - 11:20 PM

Hi there
While looking over a user's log, I found this warning:
testsigning: ==> Check for possible unsigned rootkit driver <===== ATTENTION!
According to the portion of the tutorial that covers the testsigning directive:
testsigning on:
Applys to Windows Vista and later.
Malware will sometimes add an item to the BCD (Boot Configuration Data) to escape integrity checks at startup. The malware needs to be cleaned from the machine and then the default BCD restored. Care manipulating the BCD is delicate work that if done wrongly will render a machine unbootable.
When FRST locates evidence of this sort of tampering it will report like this:
testsigning: ==> Check for possible unsigned rootkit driver <===== ATTENTION!
Where the malware is still present on the machine there will also be a (hidden) unsigned driver showing in the log like this:
Also the user might say that he has seen this on his desktop:0 442564429e863a90; C:\Windows\System32\Drivers\442564429e863a90.sys [75208 2012-06-26] ()
"I've just noticed something, in the bottom right of my desktop it says Test Mode, Windows 7, Build 7601. I've never noticed that before"
The full removal script will be:
0 442564429e863a90; C:\Windows\System32\Drivers\442564429e863a90.sys [75208 2012-06-26] ()
C:\Windows\System32\Drivers\442564429e863a90.sys
testsigning: ==> Check for possible unsigned rootkit driver <===== ATTENTION!
Beside removing the malware driver, FRST will remove the value that is added to BCD. No further action is necessary.
Sometimes however other tools will have partially cleaned the machine but not repaired the BCD. In those cases the following may be used:
testsigning: ==> Check for possible unsigned rootkit driver <===== ATTENTION!
In a situation where; after setting testsigning to its default (turning it off); something goes wrong, then to enable the testsigning for further
troubleshooting use the following command:
testsigning on:
I can't figure out the connection between the testsigning directive and the presence of the warning in the log:
testsigning: ==> Check for possible unsigned rootkit driver <=====ATTENTION!
Is the only connection between the two is that the word testsigning appears in both? In other words, I think using the testsigning directive has nothing to do with the warning. Is that correct?
mrfixiter
#15
Posted 23 December 2014 - 03:39 AM

Hi mrfixiter,
testsigning: ==> Check for possible unsigned rootkit driver <=====ATTENTION!
For 64-bit versions of Windows Vista and above, all kernel-mode drivers should have a digital signature otherwise they will not be loaded. Testsigning is not set to on by default. Some legit programs might set the option in the testing phase in order to get their driver loaded. Necurs is known to set the option on in order to load its driver. The above warning tells you the testsigning is on.
On an infected 64-bit machine with Necurs, if you (before removing the rootkit driver) turn off the testsigning, the rootkit driver will not load any more but the system becomes unbootable.
When you include the above line in the Fixlist the testsigning will be set to off. The "testsigning on:" does the opposite. It sets the testsigning to on again.
Also tagged with one or more of these keywords: FRST, farbar, tutorial
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
As Featured On:
