NoVirusThanks OSArmor

[NoVirusThanks]

@Telos @BryanB @ForgottenSeer 58943

If OSA didn't block anything then it should not be related to OSA.

You can switch OSA protection to Passive Logging (it will be still enabled on reboot).

It logs blocked events without blocking the processes (they are allowed to run).

If you get\find any more details please let me know.

@shmu26

Will update the color of the icon.

But I am still having issues that OSA starts up disabled, and I can't enable it. This happens in the following situation:
1 I log into user account 1. Then I "lock", i.e., I don't actually sign out, I just go to lock screen
2 I log into user account 2. Then I "lock" that user, and return to user account 1
3 at this point, I am logged into two user accounts simultaneously.
4 user account 1 shows OSA as disabled. Protection is not active.

Interesting, much thanks for including steps to reproduce it (will try this scenario asap).

Question: account 1 and 2 are both Admin accounts?

Another minor point: If cmd.exe is blocked (advanced settings), and OneDrive has an issue with signing in, it runs a process that gets blocked by OSA.
log says:

Will fix that FP in next build.

 

[shmu26]

Question: account 1 and 2 are both Admin accounts?

account 1 is admin
account 2 is Standard User account (win10)

 

[128BPM]

Hi, anyone know what this means? (BlockFakeSystemProcesses)

Date/Time: 11/03/2018 05:24:38 p.m.
Process: [4660]C:\Windows\System32\dllhost.exe
Parent: [724]C:\Windows\System32\svchost.exe
Rule: BlockFakeSystemProcesses
Rule Name: Block fake system processes
Command Line: C:\Windows\system32\DllHost.exe /Processid:{E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E}
Signer:
Parent Signer:

Thanks

 

[Deleted member 65228]

Hi, anyone know what this means? (BlockFakeSystemProcesses)

Infringing on a system process.

For example, if I compiled a program and re-named it to "explorer.exe" then that would be infringing a system process because it wouldn't really be explorer.exe. Infringement of system processes is a common technique and it's been around since Win2k.

However, dllhost.exe and svchost.exe should be digitally signed by Microsoft and those details are not on the log you posted.

What's the SHA-256 of your dllhost.exe and svchost.exe?

 

[ForgottenSeer 58943]

Hi, anyone know what this means? (BlockFakeSystemProcesses)

Date/Time: 11/03/2018 05:24:38 p.m.
Process: [4660]C:\Windows\System32\dllhost.exe
Parent: [724]C:\Windows\System32\svchost.exe
Rule: BlockFakeSystemProcesses
Rule Name: Block fake system processes
Command Line: C:\Windows\system32\DllHost.exe /Processid:{E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E}
Signer:
Parent Signer:

Thanks

It means I would be scared to death if I saw this and probably just format my machine.

 

[128BPM]

Hi Opcode,

svchost.exe = 40a73317ac3adc9236338920ff106ceb9844af15295f02d6f85a9427d1dac01d

dllhost.exe = 61b8955ce0a2aa9d0719920b30216717b349b6fbe11c697c31cfa84f859cc1ae

 

[Deleted member 65228]

@128BPM

It appears to be fine, I am quite confident this is nothing but a false positive flag. The version of dllhost.exe you have has been around since 2009, therefore I assume you're running Windows 7.

@NoVirusThanks might be verifying via digital signature although it appears that this isn't the first case of dllhost.exe not being digitally signed whilst being clean and not patched by malicious software, food for thought.

I'd treat this as a false positive for the time being. I can do further forensics this week if you provide me the binaries on your system for dllhost.exe for svchost.exe but it's entirely up to you - feel free to drop me a PM with them attached if you'd like me to take a look.

 

[shmu26]

These command lines parented by svchost are to me the most puzzling of events.
Most systems have several instances of svchost running simultaneously, so which one did it, and which process was the granddaddy?

In process hollowing, it is common for malware to spawn an instance of svchost as a child, and then fill it with malicious code. So you want to rule out the possibility that malware was the granddaddy of the command line.

I would check the PID of that particular instance of svchost, and look at the logs to see what else it has done in this system session. Most of the time, you will find that it ran a couple scheduled tasks. If so, this is just another one of those Windows scheduled tasks.

That's my take on it, anyways...

 

[Deleted member 65228]

@128BPM

It could also be possible that dllhost.exe and svchost.exe itself is perfectly fine however they are being affected in-memory, potentially being started up as suspended and being resumed after code injection as @shmu26 noted although I think it is rather unlikely because dynamic forking is more prevalent on 32-bit processes and malware authors for the home user market are lazy and often stupid (instability on their samples, well-known anti-reversing techniques, copy-pasted code, etc.) nowadays, it would be easier for one to just inject code into explorer.exe via DLL injection for example... and there are just more interesting targets like csrss.exe on Windows 7. However, probably a good idea not to rule it out.

ProcDump - Windows Sysinternals

Next time a flag shows up you can take a memory dump of the flagged processes and send it to me for inspection as well. However bear in mind that it could potentially expose sensitive/personal content in the memory (never say never) so only do so if you feel comfortable with ne helping this way.

Honestly, I recon his system is actually perfectly fine. Unless he has been downloading and running near the time of the detections, it was probably a false positive. After all, if he has been using NVT OSArmor for some time now and hasn't been downloading and running close to the time of the detection, then it is likely just a false positive. Otherwise it would be extremely likely in my opinion that: a). the detections can be triggered again; b). the activity would be triggered on startup timing.

Also, affecting both svchost.exe and dllhost.exe would be noisier and the goal would be stealth... Another reason why I think it is unlikely. Always a possibility though.

There are scanners you can run for things like process hollowing... RunPE detector is one of them. It wouldn't do any harm to give it a go.

 

[Andy Ful]

That event is probably related to userenv.dll:
CLSIDs Windows 7 Ultimate SP1 x64 Office 2010
userenv.dll - What is userenv.dll?
Some people reported also the issues with Microsoft-Windows-DistributedCOM - Event ID: 10010, see for example:
How to fix error shown in EventViewer: The server {E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E} did not register with DCOM within the required timeout.
How to fix error shown in Event Viewer: The server {E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E} did not register with DCOM within the required timeout.
Windows Explorer Is Not Responding - Windows Vista

 

[Prorootect]

Opcode wrote:
"There are scanners you can run for things like process hollowing... RunPE detector is one of them. It wouldn't do any harm to give it a go."

- sure, I have it for a long time, it's portable.
"RunPE detector" download on phrozen.io: RunPE Detector - Phrozen

Nice 3D icon of RunPE detector

--------------------------------------------

phrozen.io Home page: Home - Phrozen

... and nice MT topic: Update - RunPE Detector v2.0

 

[Deleted member 65228]

@Prorootect It works by checking if the image pointed to on-disk by the process matches the image in-memory.

PEB -> ProcessParameters -> ImageName (UNICODE_STRING) Buffer field in PRTL_PROCESS_PARAMETERS

PEB accessible from EPROCESS in Windows Kernel. NtQueryInformationProcess -> get that image-name, requires process handle with minimum query desired access

Will catch 99.9% of process hollowing by malware in the wild.

 

[Deleted member 65228]

Okay I did some reverse engineering and have identified how NtQueryInformationProcess really gets the file path image name...

1. User-mode process calls NtQueryInformationProcess (NTDLL) with the ProcessImageFileName class (27)
2. System call transition to invoke NtQueryInformationProcess (NTOSKRNL)
3. NtQueryInformationProcess checks if the ProcessInformationClass (PROCESSINFOCLASS) parameter is 27
4. If it is 27 (which represents the ProcessImageFileName class in the PROCESSINFOCLASS enum) then it will:
- Invoke ObpReferenceObjectByHandleWithTag to get a pointer to the _EPROCESS structure for the targeted process using the process handle given to the routine
- If the NTSTATUS result is STATUS_SUCCESS then PsQueryFullProcessImageName is invoked

PsQueryFullProcessImageName works by accessing the fields of the _EPROCESS structure for the process.

1. Base address of the _EPROCESS structure for the target process + an offset (offset = different on different OS versions/updates)
2. The address of the calculation will be the field in the _EPROCESS structure for that process for SeAuditProcessCreationInfo (_SE_AUDIT_PROCESS_CREATION_INFO)
3. Access the _SE_AUDIT_PROCESS_CREATION_INFO structure field ImageFileName
4. The ImageFileName field = _OBJECT_NAME_INFORMATION structure
5. Access the _OBJECT_NAME_INFORMATION structure using the ImageFileName field which has only one field to it which is named "Name" (UNICODE_STRING)
6. Provides back the Buffer contents of that UNICODE_STRING

The same value in that Buffer is also given to the PRTL_PROCESS_PARAMETERS ImageFileName entry in the PEB but patching the PEB locally won't stop others from locating the image file name with NtQueryInformationProcess because the Windows Kernel doesn't rely on the PEB data, it has its own storage in kernel-structures. The PEB does use communication with the Windows Kernel for some things because the point of it is so user-mode processes can access data without actually touching kernel memory so that info is given back down, and some software might rely on data in the PEB (you can also read PEB of other processes), like how people used to patch the Ldr linked list to hide non-manually mapped modules until Microsoft blocked it off with memory protection techniques.

So that is how the ImageFileName is retrieved...

RunPE detector tool -> gets the image file name and reads the PE on-disk and compares if it matches or not. The reason this is done is because process hollowing works by starting a process with a suspended state so you can un-map the image from the process (it won't have executed any of its own code yet either) -> replace it with the malicious image -> now the process still points to the genuine file path but the contents are malicious because the image in memory was replaced.

Due to how it works and due to how most malware deploys process hollowing, it'll catch 99.9% of malware in the wild using process hollowing.

--

Sorry for hijacking the thread, I'll shut up and stop talking about this now.

 

[NoVirusThanks]

Here is a new v1.4 (pre-release) test41:
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test41.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Improved OSArmor self defense (basic)
+ Improved detection of suspicious processes
+ Improved detection of fake system processes
+ Added Event Log Service on "Prevent important Windows Services from being disabled"
+ Improved Block processes named like *keygen* or *crack*
+ Block execution of sc.exe
+ Block execution of net\net1.exe
+ Block execution of wmic.exe
+ Block execution of netsh.exe
+ Block execution of bitsadmin.exe
+ Block execution of reg.exe
+ Fixed some false positives

To install it, first uninstall the previous build, then reboot (not really needed but may help), and install the new build.

All reported FPs are fixed.

@Opcode

Interesting analysis

We've built a tool some time ago that could detect RunPE behaviors, we'll see if we can integrate it into OSArmor.

@128BPM

It seems to be an FP, should be fixed in test 41.

 

[Kuttz]

Here is a new v1.4 (pre-release) test41:
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test41.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Improved OSArmor self defense (basic)
+ Improved detection of suspicious processes
+ Improved detection of fake system processes
+ Added Event Log Service on "Prevent important Windows Services from being disabled"
+ Improved Block processes named like *keygen* or *crack*
+ Block execution of sc.exe
+ Block execution of net\net1.exe
+ Block execution of wmic.exe
+ Block execution of netsh.exe
+ Block execution of bitsadmin.exe
+ Block execution of reg.exe
+ Fixed some false positives

To install it, first uninstall the previous build, then reboot (not really needed but may help), and install the new build.

All reported FPs are fixed.

@Opcode

Interesting analysis

We've built a tool some time ago that could detect RunPE behaviors, we'll see if we can integrate it into OSArmor.

@128BPM

It seems to be an FP, should be fixed in test 41.

Kaspersky Free + OSArmor running great so far Just loving the overall system responsiveness,ease of use at no compromise on security

 

[codswollip]

@Telos @BryanB @ForgottenSeer 58943

If OSA didn't block anything then it should not be related to OSA.

You can switch OSA protection to Passive Logging (it will be still enabled on reboot).

It logs blocked events without blocking the processes (they are allowed to run).

If you get\find any more details please let me know.

I re-entered my task scheduler details for daily imaging via Macrium Reflect. After assuring myself that was working as expected, I clean installed test41 (w/default settings) yesterday. Today the scheduled imaging ran with OSA active, so I have ruled out OSA as a contributor to earlier imaging problems I experienced.

 

[codswollip]

FP During installation?

Date/Time: 3/14/2018 10:17:28 PM
Process: [5024]C:\WINDOWS\SysWOW64\taskkill.exe
Parent: [3716]C:\Users\Telos\AppData\Local\Temp\is-L4G3I.tmp\InstallVoodooShield422.tmp
Rule: BlockTaskkillExecution
Rule Name: Block execution of taskkill.exe
Command Line: "C:\WINDOWS\System32\taskkill.exe" /f /im VoodooShield.exe
Signer:
Parent Signer:

 

[NoVirusThanks]

Sorry guys, a little in late here:

Here is a new v1.4 (pre-release) test42:
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test42.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Improved detection of PowerShell malformed commands
+ Change Registry value ServicesPipeTimeout to 180000 via setup file
+ Modified the service to fix a rare crash on session change
+ Improved detection of fake system processes
+ Improved Block command-lines that match *\Start Menu\Programs\Startup\*
+ Added BitLocker Service on "Prevent important Windows Services from being disabled"
+ Improved Block unknown processes on Windows folder
+ Improved Block execution of .reg scripts
+ Block execution of xcopy\robocopy.exe
+ Block execution of diskpart.exe
+ Block execution of format.com
+ Block execution of tasklist.exe
+ Block execution of systeminfo.exe
+ Block execution of whoami.exe
+ Fixed some false positives

To install it, first uninstall the previous build, then reboot (not really needed but may help), and install the new build.

@Telos

Yes it is an FP related to VS, but I think I may not fix it internally (will discuss it soon).

You may need to exclude it via the Exclusions Helper.

Thanks for sharing it anyway.

 

[Av Gurus]

Sorry guys, a little in late here:

Here is a new v1.4 (pre-release) test42:
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test42.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Improved detection of PowerShell malformed commands
+ Change Registry value ServicesPipeTimeout to 180000 via setup file
+ Modified the service to fix a rare crash on session change
+ Improved detection of fake system processes
+ Improved Block command-lines that match *\Start Menu\Programs\Startup\*
+ Added BitLocker Service on "Prevent important Windows Services from being disabled"
+ Improved Block unknown processes on Windows folder
+ Improved Block execution of .reg scripts
+ Block execution of xcopy\robocopy.exe
+ Block execution of diskpart.exe
+ Block execution of format.com
+ Block execution of tasklist.exe
+ Block execution of systeminfo.exe
+ Block execution of whoami.exe
+ Fixed some false positives

To install it, first uninstall the previous build, then reboot (not really needed but may help), and install the new build.

WD don't like it....

 

[Carphedon]

WD don't like it....

View attachment 182558

Installs fine and without wd warning over here.

@NoVirusThanks
Can you add checksum hashes when you release a new build?