SitRep – Extensible, Configurable Host Triage

Checks are separated into categories. This enables them to be shown in proper groups. The adhering to checks are currently out there:

Natural environment

• CurrentUser.cs – the latest person
• DomainName.cs – the area name
• HostName.cs – the hostname
• LoggedOnUsers.cs – Record all logged on users
• OSVersion.cs – OS edition details
• VirtualEnvironment.cs – Checks if we are working in a virtualised setting
• userEnvironmentVariables.cs – Grabs the ecosystem variables applied to the recent procedure
• SystemEnvironmentVariables.cs – Grabs process setting variables from the registry (HKLM)
• NameServers.cs – Receives the DNS servers for each individual community interface

Defences

• AVProcesses.cs – Checks if any known AV procedures are working

Permissions

• Integrity.cs – Get the integrity amount of the present-day process
• LocalAdmin.cs – Check out if we are a community admin
• Privileges.cs – Listing our present-day privileges.
• UACLevel.cs – Get the UAC level
• UserDomainGroups.cs – Will get the users domain group memberships
• ComputerDomainGroups.cs – Receives the area groups the computer system is a member of

Computer software

• InstalledBrowsers.cs – Lists the browsers mounted on the endpoint

Qualifications

• CredentialManager.cs – Retrieve qualifications stored in Home windows Credential Supervisor for the recent consumer

The following checks are now marked as becoming not OpSec protected:

• CredentialManager.cs
• ComputerDomainGroups.cs
• UserDomainGroups.cs

You really should overview this configuration and update the OpSec tags as expected.

Disabling Checks

All checks are enabled by default. Even so, as checks are loaded dynamically, it is feasible to disable them.

Disabling a look at

CheckBase features a boolean “Enabled” assets, which defaults to correct. This can be established in the derived course by introducing a constructor. The example under disables the CurrentUser check (CurrentUser.cs):

general public CurrentUser()

    foundation.Enabled = phony

Excluding checks from the construct

As checks are loaded dynamically, it is probable to exclude a check from the build with out other modifications. The least difficult way to do this is to right-click on the verify course in Visual Studio and choose “exclude from undertaking”. The check out can be re-added by picking “incorporate in task” from the very same context menu.

This approach has the gain of eradicating the code from the compiled artifact.

Illustration Usage

Operate all checks

SitRep.exe /AllowUnsafe

Operate only OpSec risk-free checks (default)

SitRep.exe

SitRep is created to be executed via execute-assembly (or equal)

Incorporating Checks

Checks inherit from CheckBase and put into practice the ICheck interface. This enforces the patterns desired for the dynamic test loading. Other approaches and lessons can be additional as expected.

The ICheck interface exposes the following homes and strategies:

• IsOpsecSafe (bool) – Indicates if the check out is regarded as OpSec secure or not
• DisplayOrder (int) – The order in which to show the result of this check out inside of its exhibit group
• Examine() – The method known as to operate the precise look at

Derived lessons should override the “ToString()” system defined in CheckBase. This method is named when displaying the output of each individual verify.

Entry to indigenous techniques is presented by means of lessons in the “NativeMethods” folder. Each and every course is named right after the dll it interacts with.

Checks are accountable for giving their have mistake managing. Recent checks wrap the complete “examine” method in a try-capture block, the use of this sample is encouraged.

An example, empty test is shown underneath

working with SitRep.Interfaces
utilizing Process

namespace SitRep.Checks.Software package
{
    course ExampleCheck : CheckBase, ICheck
    
        community bool IsOpsecSafe => true

        community int DisplayOrder => 1

        community Enums.Enums.CheckType CheckType => Enums.Enums.CheckType.Credential

        public void Check()
        
            try out
            
                throw new NotImplementedException()
            
            catch
            
                Information = "Check unsuccessful [*]"
            
        

        general public override string ToString()
        
            toss new NotImplementedException()
        
    
}

Contributing

PRs welcome. Be sure to be certain checks are stand-alone (i.e. not dependent on the output of other checks). As significantly as probable, checks really should be self-contained, with all solitary-use code present in just the look at class.

Why no unit exams?

Have you ever tried out mocking a area-joined Windows endpoint? Which is why.

Thanks

SitRep will make use of code from Seatbelt, SharpUp and random StackOverflow posts. Credits have been extra where by correct.