Title: Summary of log analysis within the domain

The logs in the domain generally end with .evtx, so we need to search the logs in the domain to use the dir command

dir/s/b *.evtx

/s: means recursive search, including subdirectories.

/b: means that the results are displayed in concise mode, only the file path is displayed without other information.

Here we can directly use the logparser tool to export log information in the domain. (In the domain control host)

The logparser tool uses SQL query method for filtering.

Use the following directives to filter out the login behavior of users in the domain through the strings column and eventid column.

LogParser.exe -i:evt -o:csv 'SELECT RecordNumber,TimeWritten,EventID,Strings,Message into C:\log5.csv FROM Security where EventID='4624' and Strings LIKE '%|Kerberos|%|%.%.%.%|%' and Strings not LIKE '%|%$|%''

-i: input file type -o: output file type

During normal domain penetration, we directly get the domain control and operate on the domain control host to export the logs. Generally, it is unrealistic to export the domain control logs or the logs of the specified member host for analysis: 1. VPN method; 2. Build a socks tunnel; 3. Use remote Trojan horses;

Query logs through VPN

Generally speaking, connect to the target host through VPN and enter the intranet environment for operation.

Here we assume that the domain management account has been obtained and the export log analysis is performed through the domain management credentials.

1. Query the host's login record

First obtain the log storage location of the domain control

dir /s/b \\10.10.10.10\c$\security.evtx

The domain control log file can be copied locally through the copy instruction.

copy \\10.10.10.10\c$\Windows\System32\winevt\Logs\C:\Users\admins\Desktop\log

Since the log file is a hidden file, we cannot export all .evtx files directly through logparser (cannot be searched)

However, you can use logparser to remotely export partial logs

LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\1.csv FROM \\RemoteServer\Security'

LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\1.csv FROM \\10.10.10.10\Security'

2. Query the traces of logs during connection

When we query log traces, we must first understand the authentication methods used for these logins: Windows uses NTML authentication by default, while Kerberos authentication is used in the domain network. Simply put, ntlm is a direct interactive authentication between the host and the host, and kerberos is authenticated by a third party (domain control).

Domain control will only issue credentials to hosts and domain accounts within the domain. Therefore, when using IP for remote host positioning, ntlm authentication is used, and when using domain name or machine name for positioning, kerberos authentication is used.

The process of connecting to remote sharing using net use is also a login process. Therefore, as long as there is a login, it will be reflected in the log.

The same is true for logging in directly using dir and host.

Log query analysis found that the host logs directly using kerberos authentication. When using dir and net use, if the remote host is ip, then it is ntlm authentication; on the contrary, if the domain name or machine name is used for positioning, then it is kerberos for positioning.

Member host net use connection domain control host

NTLM authentication packet

net use \\10.10.10.10\ipc$

Through the instructions, we can know that the login of this instruction should be ntlm authentication.

After multiple tests, it was found that if a member host uses the above statement to connect to the domain control host, the following records will be left on the domain control host.

The first package is the credentials for verifying the account that connects to the domain control host.

The second package is to assign permissions to the connection

The third package is a data package with successful login

In the third package, you can see the IP address, machine name and other information of the member host.

S-1-0-0|-|-|0x0|S-1-5-21-3315874494-179465980-3412869843-1115|admins|VVVV1|0x889d1b|3|NtLmSsp|NTLM|WEB-2003|{000000000-0000-0000-00000-0000000000}|-|NTLM V1|128|0x0|-|10.10.10.3|1280|%%1833|-|-|%%1843|0x0|%%1842

Therefore, you only need to remotely export the third successfully logged-in data packet and modify the filtering rules to obtain the host information of the domain control in the log through net use.

Use the logParser tool to export log files:

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10.10\Security where strings like '%|NTLM|%|%.%.%.%|%''

Through the strings field, we can see the IP and host name of the host connected to the domain control.

kerberos authentication packet

net use \\ad-2016\ipc$

After multiple tests, it was found that if a member host is connected to the domain control host using the above statement, and using kerberos authentication will leave the following records on the domain control host.

Therefore, you only need to remotely export the fifth successfully logged-in packet and modify the filtering rules to obtain the host information of the domain control in the log through net use.

S-1-0-0|-|-|0x0|S-1-5-21-3315874494-179465980-3412869843-500|Administrator|VVVV1.COM|0x7c3dbeb9|3|Kerberos|Kerberos||{CE15C23A-E7E3-3FC1-4A75-FDF339BEC822}|-|-|0|0x0|-|10.10.10.12|50364|%%1840|-|-|-|%%1843|0x0|%%1842

Use the logParser tool to export log files:

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10\Security where strings like '%|Kerberos|%|%.%.%.%|%' and strings not like '%|%$|%''

Through the strings field, we can see the IP and account of the host connected to the domain control.

Member host dir connects to domain control host

NTLM authentication packet

dir \\10.10.10.10\c$

The principle is the same as net use, just use logparser to export it directly.

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10.10\Security where strings like '%|NTLM|%|%.%.%.%|%''

kerberos authentication packet

dir \\ad-2016\c$

The principle is the same as net use, just use logparser to export it directly.

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10\Security where strings like '%|Kerberos|%|%.%.%.%|%' and strings not like '%|%$|%''

Member Host Connects Member Host

dir \\10.10.10.10\c$

dir \\web-2003\c$

The first method, that is, the ntlm authentication method, is to only leave this log trace in the domain control host's log, which is almost useless, and the main trace is reflected in the log of the connected host.

The second method, which is the kerberos authentication method, will leave two logs on the domain control host: request TGT and request ST log.

The process of searching logs is also similar to the above, so I won't describe it here.

Member host logs in by itself

Only users who log in with the account of users in the domain will have traces left on the domain control host. If you log in with a local account, it will only be reflected in the log of the machine.

If you use a user within the domain to log in, the domain control is to use kerberos for authentication, which is the same as the kerberos authentication packet above.

Use the logParser tool to export log files:

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10\Security where strings like '%|Kerberos|%|%.%.%.%|%' and strings not like '%|%$|%''

Query logs through socks proxy

Generally speaking, when we take down a boundary host, we will build a socks tunnel and bring our local host agent into the intranet for operation.

First, use hash delivery to ensure that the outside domain host has sufficient permissions.

After testing, the hash passed operations will not generate log traces in the domain control and socks tunnel client hosts.

1. Query the host's login record

The instructions and operations are the same as those of VPN.

2. Query the traces of logs during connection

Remote host net use connection domain control host

Because the Proxifier proxy tool cannot modify the dns proxy in the socks environment, resulting in the inability to correctly resolve the domain name and machine name. Therefore, you can only use IP operations, and use NTLM authentication.

NTLM authentication packet

net use \\10.10.10.10\ipc$

Through the instructions, we can know that the login of this instruction should be ntlm authentication.

After multiple tests, it was found that if a member host uses the above statement to connect to the domain control host, the following records will be left on the domain control host.

The first package is the credentials for verifying the account that connects to the domain control host.

The second package is to assign permissions to the connection

The third package is a data package with successful login

In the third package, you can see the IP address, machine name and other information of the member host.

S-1-0-0|-|-|0x0|S-1-5-21-3315874494-179465980-3412869843-1115|admins|VVVV1|0x889d1b|3|NtLmSsp|NTLM|WEB-2003|{000000000-0000-0000-00000-0000000000}|-|NTLM V1|128|0x0|-|10.10.10.3|1280|%%1833|-|-|%%1843|0x0|%%1842

Therefore, you only need to remotely export the third successfully logged-in data packet and modify the filtering rules to obtain the host information of the domain control in the log through net use.

Use the logParser tool to export log files:

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10.10\Security where strings like '%|NTLM|%|%.%.%.%|%''

Through the strings field, we can see the IP and host name of the host connected to the domain control.

Remote dir connection to the domain control host

NTLM authentication packet

Because the Proxifier proxy tool cannot modify the dns proxy in the socks environment, resulting in the inability to correctly resolve the domain name and machine name. Therefore, you can only use IP operations, and use NTLM authentication.

dir \\10.10.10.10\c$

The principle is the same as net use, just use logparser to export it directly.

C:\Users\admins\Desktop\LogParser.exe -i:EVT -o:CSV 'SELECT * INTO C:\Users\admins\Desktop\log\1.csv FROM\10.10.10.10\Security where strings like '%|NTLM|%|%.%.%.%|%''

Remote host connects to member host

dir \\10.10.10.10\c$

Both methods refer to leaving this log trace in the domain control host's log, which is almost useless, and the main trace is reflected in the log of the connected host.

The process of searching logs is also similar to the above, so I won't describe it here.

PowerShell Log

Powershell logs are generally written directly to the system log

However, in normal configuration, powershell does not save the command log of its execution, but only saves the powershell open command (ID:600) and powershell close command (ID:403)

Therefore, during the penetration process, if we obtain an interactive shell, we can open the powershell first and then execute the command, then the log will only record the command to open the powershell, and will not save the record of the commands executed in the powershell terminal.

However, if during the infiltration process, we get a webshell, that is, a semi-interactive command window, then we can only summarize the commands into one statement, and the command will be recorded in the log.

PowerShell script usage

When we use PowerShell script to execute commands, we need to execute a command first

Powershell -ExecutionPolicy Bypass

Used to bypass PowerShell execution policies. PowerShell enables execution policies by default, limiting script execution permissions.

Execution policy is a security mechanism that controls whether script files are allowed to be executed and scripts from untrusted sources. By default, PowerShell's execution policy is set to 'Restricted' , which means that no script file is allowed to be executed.

By using 'Powershell -ExecutionPolicy Bypass' in the PowerShell command line, execution policy restrictions can be bypassed and script files are allowed. This will temporarily change the execution policy to 'Bypass', allowing all scripts to be run.

If the ps1 script we are about to import is SharpHound.ps1

Import-Module ./SharpHound.ps1

At this time, the SharpHound module has been loaded into the current session

View all loaded modules in the current session

Get-Module

Get a list of all commands in the SharpHound module

Get-Command -Module SharpHound

Check out SharpHound usage help

Get-Help SharpHound

get-help Invoke-BloodHound -full

Delete log

If you are in a penetrating environment, deleting all logs will not only not cover up our traces, but will instead make our traces more obvious.

Therefore, we can only use the method of deleting a single log, but Windows does not provide it, or it does not allow the operation of deleting a single log, so we can only use other methods.

Tool usage: https://github.com/3gstudent/Eventlogedit-evtx--Evolution

Principle of deleting single logs: https://3gstudent.github.io/Windows-XML-Event-Log-(EVTX)%E5%8D%95%E6%9D%A1%E6%97%A5%E5%BF%97%E6%B8%85%E9%99%A4-%E4%B8%80-%E5%88%A0%E9%99%A4%E6%80%9D%E8%B7%AF%E4%B8%8E%E5%AE%9E%E4%BE%8B

https://github.com/QAX-A-Team/EventCleaner

Clear RDP login traces

https://blog.csdn.net/m0_37552052/article/details/82894963

https://blog.csdn.net/COCO56/article/details/102671007#:~:text=win10%E7%B3%BB%E7%BB%9F%E6%80%8E%E4%B9%88%E5%88%A0%E9%99%A4%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2%E8%BF%9E%E6%8E%A5%E8%AE%B0%E5%BD%95%201%20%E6%8C%89win%2BR%E9%94%AE%E6%89%93%E5% BC%80%E8%BF%90%E8%A1%8C%EF%BC%8C%E8%BE%93%E5%85%A5%20regedit%201%20%E5%B9%B6%E7%A1%AE%E5%AE%9A%E3%80%82%202,%E5%9C%A8%E5%9C%B0%E5%9D%80%E6%A0%8F%E4%B8%AD%E8%BE%93%E5%85%A5%E4%BB%A5%E4%B8%8B%E5%9C%B0%E5%9D%80%E7%84%B6%E5%90%8E%E5%9B%9E%E8%BD%A6%E 5%8D%B3%E5%8F%AF%E8%BF%9B%E8%A1%8C%E7%9C%8B%E5%88%B0%E6%89%80%E6%9C%89%E7%9A%84%E5%B7%B2%E8%BF%9E%E6%8E%A5%E8%BF%87%E7%9A%84%E7%94%B5%E8%84%91%E3%80%82%20%E8%AE%A1%E7%AE%97%E6%9C%BA%5CHKEY_CURRENT_USER%5CSoftware%5CMicrosoft%5CTerminal%20Server% 20Client%5CDefault%201%203%20%E5%8F%B3%E9%94%AE%E7%82%B9%E5%87%BB%E9%9C%80%E8%A6%81%E7%AE%A1%E7%90%86%E7%9A%84%E8%AE%B0%E5%BD%95%E9%A1%B9%EF%BC%8C%E5%8F%AF%E4%BB%A5%E4%BF%AE%E6%94%B9%E6%88%96%E8%80%85%E5%88%A0%E9%99%A4%E6%AD%A4%E9%A1%B9%E3%80%82

https://blog.csdn.net/travelnight/article/details/122854895

Event ID: 1149: Record which source IPs were successfully logged into the local machine using RDP. Registration :HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\

This path records which servers the current host has logged into. Event ID: 5156 Log: You can see when the machine has accessed port 3389 of other servers. 4624 —— Account logged in successfully

4625 —— Account cannot be logged in

1149 —— User authentication is successful

Reprinted from the original link address: https://forum.butian.net/share/3657