How to register a windows service but avoid it being listed in the services console?

Question

I know a legitimate Windows Application, a parental control software, that install as a service, but the service is not listed in the service list, the list you see in services.

Answer 1

Provided that serviceName (std::wstring) holds the name of the Service and hService (HANDLE) is a handle to a Service, the following code will hide the service:

    PSECURITY_DESCRIPTOR secDescPtr;
    ULONG secDescSize = 0;
    if (ConvertStringSecurityDescriptorToSecurityDescriptor(L"D:(D;;DCWPDTSD;;;IU)(D;;DCWPDTSD;;;SU)(D;;DCWPDTSD;;;BA)(A;;CCSWLOCRRC;;;IU)(A;;CCSWLOCRRC;;;SU)(A;;CCSWRPWPDTLOCRRC;;;SY)(A;;CCDCSWRPWPDTLOCRSDRCWDWO;;;BA)",
        SDDL_REVISION_1,
        &secDescPtr,
        &secDescSize) == TRUE)
    {

        wprintf(L"Security Descriptor conversion ok");
        if (SetServiceObjectSecurity(hService, DACL_SECURITY_INFORMATION, secDescPtr) == TRUE)
        {
            wprintf(L"Service %s hidden",serviceName);
            ret = true;
        }
        else
        {
            switch (GetLastError())
            {
            case ERROR_ACCESS_DENIED:
                wprintf(_T("Service Security setup failed - Access Denied"));
                break;
            case ERROR_INVALID_HANDLE:
                wprintf(_T("Service Security setup failed - Invalid Handle"));
                break;
            case ERROR_INVALID_PARAMETER:
                wprintf(_T("Service Security setup failed - Invalid Parameter"));
                break;
            case ERROR_SERVICE_MARKED_FOR_DELETE:
                wprintf(_T("Service Security setup failed - Service Marked For Delete"));
                break;
            }
        }
    }
    else
    {
        wprintf(_T("Security Descriptor conversion failed"));
    }

Answer 2

OK, I can reproduce this behaviour: by giving a service the same permissions as those of the mystery service, I can make it disappear from the list in services.msc.

sc sdset myservice D:(D;;DCLCWPDTSD;;;IU)(D;;DCLCWPDTSD;;;SU)(D;;DCLCWPDTSD;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

So it's all down to the permissions.

OK, let's expand out that security descriptor string. This is a bit tricky because the mapping between the SDDL permissions and equivalent security manager permissions does not appear to be well documented in MSDN or in the SDK headers; luckily, Wayne Martin has already done the heavy lifting for us and posted the results in the blog entry Service Control Manager Security for non-admins.

D: - this part is the DACL, the permissions on the service.

Deny entries always come first, which also means they take precedence over the allow entries:

(D;;DCLCWPDTSD;;;IU) - deny (D) interactive users (IU) the following rights:
  DC - SERVICE_CHANGE_CONFIG (the right to change the service configuration)
  LC - SERVICE_QUERY_STATUS (the right to query the service status)
  WP - SERVICE_STOP (the right to stop the service)
  DT - SERVICE_PAUSE_CONTINUE (the right to pause and continue the service)
  SD - DELETE (the right to delete the service)
(D;;DCLCWPDTSD;;;SU) - deny services (SU) the same set of rights as above
(D;;DCLCWPDTSD;;;BA) - deny the Administrators group (BA) the same as above

The allow entries are just the same as the default permissions. (They are in a different order, but the order of allow entries is not significant.)

(A;;CCLCSWLOCRRC;;;IU) - allow the interactive user the following rights:
  CC - SERVICE_QUERY_CONFIG (the right to query the service configuration)
  LC - overridden by the deny entry
  SW - SERVICE_ENUMERATE_DEPENDENTS (the right to see service dependencies)
  LO - SERVICE_INTERROGATE (the right to send SERVICE_CONTROL_INTERROGATE)
  CR - SERVICE_USER_DEFINED_CONTROL (the right to send a user defined control)
  RC - READ_CONTROL (the right to see the permissions)
(A;;CCLCSWLOCRRC;;;SU) - allow services the following rights:
   same as for the interactive user
(A;;CCLCSWRPWPDTLOCRRC;;;SY) - allow local system the following rights:
   same as for the interactive user, plus:       
   RP - SERVICE_START (the right to start the service)
   WP - overridden by the deny entry for BA
   DT - overridden by the deny entry for BA
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) - allow the Administrators group:
   same as for local system, plus:
   DC - overridden by the deny entry
   LC - overridden by the deny entry
   SW - overridden by the deny entry
   SD - overridden by the deny entry
   WD - WRITE_DAC (permission to change the permissions)
   WO - WRITE_OWNER (permission to take ownership)

Finally, we have the SACL. This is also unchanged from the default for a service.

S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
  S: - indicates that this is a SACL
  AU - indicates that this is an audit entry
  FA - indicates that failed attempts to access the object should be audited
  WD - controls whose failed attempts should be audited; the Everyone SID
  CCDCLCSWRPWPDTLOCRSDRCWDWO - the kinds of access attempts to audit
    - appears to include every right that applies to services

So basically that just says "audit all failed attempts to access this service".

It should be possible to significantly simplify those permissions, e.g., by removing all the allow permissions that are overridden by the deny permissions. In fact, it seems likely the only access permission you would really need is SERVICE_START and perhaps SERVICE_QUERY permission for local system, and maybe not even those. :-)

On the other hand, the complexity of the permissions doesn't really matter, so it probably isn't worth the effort involved in testing the changes.

---

PS: to restore the default permissions you can say:

sc sdset myservice D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)