Technical specialists who, while investigating security incidents or troubleshooting problems with troubleshooting, have tried to find information that is really important for them in the Microsoft Windows operating system logs, they know that not all that is needed is included in the event audit logs. Is it possible to remedy this situation without additional financial investments using tools that are guaranteed to be compatible with the Windows environment? Of course you can!
Note: we continue the series of publications of the full versions of articles from the magazine Hacker. Spelling and punctuation of the author saved.
Immediately make a reservation that the scope of this article will remain the issues of deliberate cleansing of the logs or the “curve” of setting up audit policies in the domain (Audit Policy). Here we will talk only about how to increase the information content and expand the capabilities of the event audit function using the System Monitor (Sysmon) utility in the Windows environment (from Windows 7 for client nodes and from Windows Server 2008 R2 for servers).
The utility can be downloaded from the Microsoft Docs website, from the Windows Sysinternals download section. As part of Windows Sysinternals from Mark Russinovich and So there are still many useful utilities, so find the time and “feel” them. Plus look into the selection of materials on GitHub materials .
But for this article we will take a special ready-made assembly from the GitHub download , which includes the Sysmon Threat Intelligence Configuration configuration file from ION-STORM . It is focused on identifying security incidents and can provide a quality basis for creating your own configuration files.
The utility can be installed pointwise at each workplace or using Group Policy in the domain.
This configuration file contains mostly full standard paths for a number of software:
<Image condition="is">C:\Program Files\OpenVPN\bin\openvpn-gui.exe</Image> <ImageLoaded condition="contains">C:\Program Files (x86)\Notepad++</ImageLoaded>
Thus, in a specific IT infrastructure, this may require some tuning, since, for example, according to the corporate policy, programs can be installed on the D: \ disk, and not on C :.
The toolkit is so flexible that you can set up any constructs aimed at tracking certain actions or excluding them from your field of vision.
After installation, you will receive a new Microsoft-Windows-Sysmon / Operational log (Channel), in which Sysmon allocates 18 task categories (Task Category), among them: Process Create, Network Connect, Driver Load, ProcessAccess, File Create.
Let us turn to the practical application of Sysmon.
Imagine the network interaction between two network nodes: node A refers to node B, and this appeal is not legal, that is, a security incident is suspected. Look for traces of this network interaction in the operating system will be at the very last moment, and it will start with the active network equipment.
What does 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 see only who IP_1 and where IP_2.
By and large, additional efforts will be needed: it will be necessary to analyze node A (IP_1) in semi-automatic or manual mode in order to find the real source of network activity.
It must be remembered that if the network activity does not extend 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 apply a sniffer at this moment or to send traffic in advance through the SPAN port and generate a PCAP file. What will it give?
We see who, where and if very lucky, then with what, that is, in this case PuTTY.
But there is neither the place where the application is installed, nor the name of the executable file, nor when it was created. In the case of PuTTY, this may seem frivolous, but if you are looking for traces of unauthorized actions and / or malware, then these are already important things. Plus, the malware can “introduce itself” as a legal application and push you to close this security incident as a false positive, making a decision only on the basis of the application name obtained from the network traffic dump.
Now let's 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, as well as additional parameters of network interaction (protocol, port). Now, in the same channel, by the value of the ProcessGuid field, we will find an event of the Process Create category in order 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 a process has been created, including the hash value of the file - the progenitor of this process.
Now you can check this file using the hash:
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.), hashes analysis - including automated, by comparing data from Threat Intelligence services, for example, in the Security Information class system and Event Management (SIEM), - can act as quite an effective compensating measure to combat 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 in the operating system of files that can be a potential source of information security incidents, such as digital certificates, executable files, library files, PowerShell files, RDP files, MS Office files with macro support, as well as files created in certain file system directories:
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 logged. 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 MS Word:
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 safeguard, this may be of interest when a malicious file performs a reassociation of legally assigned corporate applications for certain types of files and thereby “enforces” the use of a vulnerable application. Another example: changing the registry keys of the operating system that affect the operating system boot settings in order to reduce the level of security after a regular reboot (disabling anti-virus protection or other information protection tools).
In order to ensure the centralized collection and storage of events from the logs of all network nodes, including reducing the possibility for an attacker to clear the logs on the attacked node, it is practiced to consolidate data on a dedicated node. The Windows Event Collector service must be running on this node. As a result, the events will be displayed in the Forwarded Events log.
You need to do the following steps at each workplace or using group policies in the domain:
wevtutil set-log Microsoft-Windows-Sysmon / Operational / ca: DATA (A ;; 0x1 ;;; UID_COLLECTOR)
Get extended Microsoft-Windows-Sysmon / Operational channel access rights for the COLLECTOR account.
Our practice has shown that a full-fledged analysis of suspicious events on the network often lacks regular logging tools, especially if we are talking about targeted attacks against organizations. In this case, Sysmon can be a highly promising solution, the use of which, in our opinion, will be limited only by the imagination of the ultimate information security specialist.
We remind you that this is the full version of an article from Hacker magazine . Its authors are Alexander Kuznetsov and Alexey Fedorov.
Source: https://habr.com/ru/post/352692/
All Articles