Technical experts who, while investigating information security incidents or troubleshooting troubleshootings, at least once tried to find information that is really important for them in the logs of Microsoft Windows operating systems, know that not everything that is needed is included in the event audit logs. Is it possible to fix this situation without additional financial investments using tools guaranteed to be compatible with the Windows environment? Of course you can!

Note: we continue the series of publications of full versions of articles from the Hacker magazine. Spelling and punctuation of the author saved.

Immediately we make a reservation that outside the scope of this article there will remain questions of deliberate cleaning of logs or the “curve” of setting audit policies in the domain (Audit Policy). Here we will only talk about how to increase the information content and expand the capabilities of the event audit function using the System Monitor (Sysmon) utility in a Windows environment (from Windows 7 for client nodes and from Windows Server 2008 R2 for servers).

Sysmon

The utility can be downloaded from the Microsoft Docs website, from the Windows Sysinternals download section . There are many more useful utilities in Windows Sysinternals from Mark Russinovich and Co, so take the time and “touch” them. Plus take a look at the selection of materials on GitHub materials .
But for this article we will take a special ready-made assembly with GitHub download , which includes the Sysmon Threat Intelligence Configuration configuration file from ION-STORM . It is focused specifically on identifying information security incidents and can provide a quality basis for creating your own configuration files.

The utility can be installed pointwise to each workstation or using Group Policies in the domain.

In this configuration file, for the most part, the full standard paths for a number of software are indicated:

C:\Program Files\OpenVPN\bin\openvpn-gui.exe
    C:\Program Files (x86)\Notepad++

Thus, in a specific IT infrastructure, this may require some tuning, since, for example, according to corporate policy, programs can be installed on the D: \ drive, and not on C :.

The toolkit is so flexible that you can set any constructions aimed at tracking certain actions or excluding them from your field of vision.
After installation, you will receive a new Microsoft-Windows-Sysmon / Operational (Channel) log, in which Sysmon identifies 18 Task Categories, among them: Process Create, Network Connect, Driver Load, ProcessAccess, File Create.

Network Audit

Let's move on to the practical application of Sysmon.

Imagine the network interaction between two network nodes: node A accesses node B, and this appeal is not legal, that is, there is a suspicion of an information security incident. They will search for traces of this network interaction in the operating system at the very last moment, and they will begin with the active network equipment.
What will a firewall or router tell us if it controls this network interaction?

    <190>%ASA-6-302014: Teardown TCP connection 2047052539 for outside:IP_1/60307 (DOMAIN\USER_NAME) to dmz-0:IP_2/22 duration 0:00:16 bytes 5675 TCP FINs (USER_NAME)

We only see who is IP_1 and where is IP_2.
By and large, additional efforts will be required here: it will be necessary to analyze node A (IP_1) in semi-automatic or manual mode to find a real source of network activity.

It must be remembered that if the network activity does not go beyond the network segment controlled by the firewall, or the corresponding events are recorded on this firewall, which often happens, then nothing will be found in the logs.
Suppose you managed to use a sniffer at that moment or to fork traffic in advance through the SPAN port and form a PCAP file. What will it give?

We see who, where and, if very lucky, then with the help of what, that is, in this case PuTTY.
But there is no place to install the application, nor the name of the executable file, nor when it was created. In the case of PuTTY, this may seem like far-fetched attributes, but if you are looking for traces of unauthorized actions and / or malware, these are already important things. Plus, a malware can “appear” to be a legitimate application and push you to close this information security incident as a false positive, deciding only on the basis of the application name received from the network traffic dump.

Now look at the Microsoft-Windows-Sysmon / Operational channel. It has the following event:

    Network connection detected:
    UtcTime: 2018-02-08 11:33:49.672
    ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}
    ProcessId: 4636
    Image: C:\Users\USER_NAME\Desktop\putty.exe
    User: DOMAIN\USER_NAME
    Protocol: tcp
    Initiated: true
    SourceIsIpv6: false
    SourceIp: IP_1
    SourceHostname: COMP_NAME.DOMAIN
    SourcePort: 60307
    SourcePortName: 
    DestinationIsIpv6: false
    DestinationIp: IP_2
    DestinationHostname: 
    DestinationPort: 22
    DestinationPortName: ssh

We see who, where, with what help, and also additional parameters of network interaction (protocol, port). Now in the same channel, by the value of the ProcessGuid field, we find an event of the Process Create category to get more information directly about the source of this network activity:

    Process Create:
    UtcTime: 2018-02-08 11:33:30.583
    ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}
    ProcessId: 4636
    Image: C:\Users\USER_NAME\Desktop\putty.exe
    CommandLine: "C:\Users\USER_NAME\Desktop\putty.exe" 
    CurrentDirectory: C:\Users\USER_NAME\Desktop\
    User: DOMAIN\USER_NAME
    LogonGuid: {4e1a728b-268c-5a7c-0000-0020d3a20600}
    LogonId: 0x6A2D3
    TerminalSessionId: 1
    IntegrityLevel: Medium
    Hashes:     SHA256=7AFB56DD48565C3C9804F683C80EF47E5333F847F2D3211EC11ED13AD36061E1,IMPHASH=EFE162FD3D51DED9DD66FA4AC219BF53
    ParentProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}
    ParentProcessId: 3632
    ParentImage: C:\Windows\explorer.exe
    ParentCommandLine: C:\Windows\Explorer.EXE

We see that the process has been created, including the hash value of the file - the progenitor of this process.

Now you can hash check this file:

• according to corporate "white lists" of authorized software;
• for compliance with the standard on the website of the manufacturer of this software;
• in Threat Intelligence service ratings;
• on resources like VirusTotal.

It is worth noting that on those network nodes where there are restrictions on the installation of anti-virus protection tools (dispatcher terminals, technological workstations, etc.), hash analysis - including automated analysis by matching data from Threat Intelligence services, for example, in a system of the Security Information class and Event Management (SIEM), - can be a very effective compensatory measure for combating malicious software.

Developing the theme of tracking actions related to files, it should be noted that by default the specified configuration file allows you to track the creation of files in the operating system that can be a potential source of information security incidents, for example, digital certificates, executable files, library files, PowerShell files, RDP -files, MS Office files with macro support, as well as files created in certain directories of the file system:

    File created:
    UtcTime: 2018-02-08 11:50:39.893
    ProcessGuid: {4e1a728b-283b-5a7c-0000-00107b384a00}
    ProcessId: 2780
    Image: C:\Program Files\Microsoft Office\Office15\WINWORD.EXE
    TargetFilename: C:\Users\USER_NAME\Desktop\Doc1.docm
    CreationUtcTime: 2018-02-08 11:50:39.893

Files or actions that lead to changes in registry settings are also subject to logging. For example, the association of the DOCM file type, which was first used in the operating system when creating the Doc1.docm file (see the example above), with the MS Word application:

    Registry value set:
    EventType: SetValue
    UtcTime: 2018-02-08 11:50:40.550
    ProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}
    ProcessId: 3632
    Image: C:\Windows\Explorer.EXE
    TargetObject: \REGISTRY\USER\S-1-5-21-1626002472-1445367128-3583509536-1113\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.docm\OpenWithList\a
    Details: WINWORD.EXE

For a security guard, this may be of interest when a malicious file reassociates legally attached corporate applications for certain types of files and thereby “imposes” the use of a vulnerable application. Another example: changing the registry keys of the operating system that affect the boot parameters of the operating system in order to reduce its level of security after the next reboot (disabling anti-virus protection or other information protection tools).

Centralizing event collection and storage

In order to ensure centralized collection and storage of events from the logs of all network nodes, including reducing the ability of an attacker to clear the logs on the attacked node, data consolidation on a dedicated node is practiced. The Windows Event Collector service must be running on this node. Eventually, the events will be displayed in the Forwarded Events journal.
You need to do the following steps at each workplace or using group policies in the domain:

1. Add the user on behalf of whom the “COLLECTOR” events will be collected to the local group “Event log reader”.
2. Run on behalf of the administrator (Run as) the command
   winrm quickconfig -quiet
3. Run on behalf of the administrator (Run as) the command
   wevtutil get-log Microsoft-Windows-Sysmon / Operational,
   Get the line "channelAccess" DATA

1. Run as admin the Run command
   wmic useraccount where name = 'COLLECTOR' get sid
   Get UID_COLLECTOR
2. Run as administrator the command (Run as)
   

wevtutil set-log Microsoft-Windows-Sysmon / Operational / ca: DATA (A ;; 0x1 ;;; UID_COLLECTOR)

Obtain extended Microsoft-Windows-Sysmon / Operational channel permissions for the COLLECTOR account.

1. Add this node to a specially created subscription (Subscription) for centralized collection and storage of events on a dedicated node running the Windows Event Collector service.

Conclusion

Our practice has shown that for a full analysis of suspicious events on the network, often regular logging tools are not enough, especially if we are talking about targeted attacks on organizations. In this case, Sysmon can be a highly promising solution, the possibilities of which, in our opinion, will be limited only by the imagination of the ultimate specialist in information protection.

We remind you that this is the full version of an article from the Hacker magazine . Its authors are Alexander Kuznetsov and Alexey Fedorov.