@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

Microsoft-Windows-TerminalServices-RDPClient and NLA

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

"Microsoft-Windows-Terminal Services-RDPClient / Operational" may record information to help you track Lateral Movement.

  • Destination computer name / IP address, and Domain Name
  • Username (encoded, so you need to find a matching username)
  • Reason code that disconnected the session

Let's see what kind of information is recorded in this event log.

-(1)-

Displays the properties of "Microsoft-Windows-TerminalServices-RDPClient/Operational" on Windows 10 1809. In my test environment, logging was enabled by default.

There is no record at the time of OS installation.

f:id:hideakii:20190503084638p:plain

Start mstsc.exe and connect to DC1. There is no option specified. (NLA is enabled on DC1.)

f:id:hideakii:20190503085112p:plain

When Alice successfully logged on to DC1(192.168.100.100), nine events were recorded.

f:id:hideakii:20190503085552p:plain


ID 1024

RDP ClientActiveX is trying to connect to the server (dc1)

In this event, you can check the computer name of the RDP connection destination "DC1". When an IP address is specified for Computer of MSTSC, the IP address is displayed.

ID 1028

Server supports SSL = supported

ID 1029

Base64(SHA256(UserName)) is = 37b1Qe+C6RABWfEqhOY11NzgSzEATQWYD8PK6fWhlzc=-

The username is encoded. The article "Windows Event ID 1029 Hashes" is a good reference for finding a matching username.

If you convert the username "alice" in CyberChef, you can see the same value as the event log.

https://gchq.github.io/CyberChef/#recipe=Decode_text('UTF-8%20(65001)')Encode_text('UTF16LE%20(1200)')SHA2('256')From_Hex('Space')To_Base64('A-Za-z0-9%2B/%3D')&input=YWxpY2U

If "example\alice" is specified for the user name, the domain name and user name are encoded in the event log.

Base64(SHA256(UserName)) is = LZDrhy6nd9yShjFabAXdEq4o+LXDgDsQAAsbbZEr2/0=-37b1Qe+C6RABWfEqhOY11NzgSzEATQWYD8PK6fWhlzc=

 

ID 1102

The client has initiated a multi-transport connection to the server 192.168.100.100.

In this event, you can check the IP address of DC1(192.168.100.100).

ID 1103

The client has established a multi-transport connection to the server.

ID 1025

RDP ClientActiveX has connected to the server

ID 1402

The client is using hardware memory for the frame buffer.

ID 1404

The server is using version 0xA0600 of the RDP graphics protocol (client mode: 0, AVC available: 1).

ID 1027

Connected to domain (EXAMPLE) with session 2.

In this event, you can check the domain name (EXAMPLE.LOCAL).

-(2)-

When Alice signed out of DC1, three events were recorded.

f:id:hideakii:20190503090210p:plain

ID 226

RDPClient_SSL: An error was encountered when transitioning from TsSslStateDisconnected to TsSslStateDisconnected in response to TsSslEventInvalidState (error code 0x8000FFFF).

ID 1105

The multi-transport connection has been disconnected.

By linking this event with ID 1103, can I find out how long Alice has been connected via RDP?

ID 1026

RDP ClientActiveX has been disconnected (Reason= 2)

According to Technet's article, Reason code 2 is "User-initiated client logoff."

-(3)-

Check the event when authentication fails at NLA stage. Several events have been recorded, you can see that there is no ID 1103.

f:id:hideakii:20190503152056p:plain

ID 1026

RDP ClientActiveX has been disconnected (Reason= 7943)

"Reason = 7943" is displayed as the disconnection reason, the corresponding article was not found in the article of TechNet.

-(4)-

Disable NLA in the RDP settings of DC1. Also, add the following to the .RDP file and turn off NLA.

enablecredsspsupport:i:0

Connected to RDP with NLA off. 

f:id:hideakii:20190503155742p:plain

Check the event log with the password input failure several times and the connection disconnected. (Alice has not logged on successfully.)

f:id:hideakii:20190503155954p:plain

Event ID 1103 can confirm that the RDP connection is successful, but you need to confirm in the security log that the logon was successful.

If NLA is disabled, it will appear to be disconnected once. The reason code for disconnection is 263, but this is also a code that is not described in Technet.

f:id:hideakii:20190503160429p:plain

Event ID 1029 displays the user name set in the RDP file.
After successfully connecting the RDP session, ID 1029 was not recorded again when another user name was entered.

 

If NLA is disabled and logon is successful, ID 1027 will be recorded.

If you can not check the security log, event ID 1027 may be a hint of successful logon. (Unfortunately, the successful logon username can not be verified from Event ID 1027.)

f:id:hideakii:20190503161953p:plain

  

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

jpcertcc.github.io

ponderthebits.com

https://social.technet.microsoft.com/wiki/contents/articles/37870.rds-remote-desktop-client-disconnect-codes-and-reasons.aspx

nullsec.us


 

f:id:hideakii:20190503083911j:plain

 

 

Windows Defender Remote Credential Guard and RestrictedAdmin mode.

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Windows Defender Remote Credential Guard is available for Windows 10 and Windows Server 2016.
Is there any way to check if Remote Credential Guard was used with RDP connection?
I checked some event logs but could not identify the use of /remoteGuard.

Remote Credential Guard needs to enable RestrictedAdmin mode. I'm concerned about enabling RestrictedAdmin mode. -> 

Passing the hash with native RDP client (mstsc.exe) - Blog | Michael Eder

f:id:hideakii:20190501212823p:plain

So I continue to look for information to identify.

---

I enabled RDP on Windows Server 2016 and NLA option is checked. The domain user Alice has been added to Remote Desktop Users.

f:id:hideakii:20190501183042p:plain

Set the DisableRestrictedAdmin value in the registry and enable RestrictedAdmin mode. 

f:id:hideakii:20190501183250p:plain

Execute mstsc.exe on Windows 10(PC1) with /remoteGuard option. This verification did not set up a group policy.

mstsc.exe /remoteGuard

If I enter a computer name, the user's item will be grayed out automatically.

f:id:hideakii:20190501193448p:plain

Connect to computer DC1 and view the event log.

DC1

Check the event log records. The following is event logs of DC1 which received RDP connection.

(1) ID 1149 does not record user names, but ID 21 and 22 record Alice.

2019-05-01T10:38:29.350975900Z Microsoft-Windows-TerminalServices-RemoteConnectionManager

ID 1149

Remote Desktop Services: User authentication succeeded:

User:
Domain:
Source Network Address: 192.168.100.10

2019-05-01T10:38:32.690529600Z Microsoft-Windows-TerminalServices-LocalSessionManager

ID 21

Remote Desktop Services: Session logon succeeded:

User: EXAMPLE\alice
Session ID: 2
Source Network Address: 192.168.100.10

ID 22

Remote Desktop Services: Shell start notification received:

User: EXAMPLE\alice
Session ID: 2
Source Network Address: 192.168.100.10

(2) Let's check the security log.
Check NLA event ID 4624 Logon type 3. The item of "Restricted Admin Mode:" is displayed as "-".

f:id:hideakii:20190501195447p:plain

(3) Event ID 4648

f:id:hideakii:20190501195844p:plain

(4) Event ID 4624 Logon Type 10, "Restricted Admin mode" is displayed as "NO".

f:id:hideakii:20190501200537p:plain

I could not determine from the event log whether /remoteGuard was used.


Next, check the log when logged on in RestrictedAdmin mode.

f:id:hideakii:20190501201049p:plain

It can be confirmed by the record of ID 4624 logon Type 10, "Restricted Admin mode" is displayed as "Yes".

f:id:hideakii:20190501201443p:plain

PC1

If /remoteGuard or /restrictedAdmin is specified as an option of mstsc.exe, ID 4648 is not recorded in the security log.
 

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

docs.microsoft.com

 

michael-eder.net

f:id:hideakii:20190501182703j:plain

 

AD ACL and ADTimeline

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Change the ACL of the object on AD and check ADTimline. Use AD ACL Scanner as a tool to check the ACL of AD objects.

AD Timeline-FIRST TC Page 22 has an entry for "AD replication metadata vs security event logs". Check the ACL and compare the security log.

Allow the Alice account the rights needed by DCsync. Below, I set up two permissions related to replication.

f:id:hideakii:20190409184859p:plain

Two event ID 5136 were recorded in the security log.

f:id:hideakii:20190409185153p:plain

Run AD ACL Scanner and check the report. I can view the privileges of Alice account.

Two entries, Critical and Warning, are displayed.

f:id:hideakii:20190409185324p:plain

Execute ADTimeline and check "nTSecurityDescriptor". The time is slightly different from security log ID 5136.

f:id:hideakii:20190409185637p:plain

Remove the access rights of Alice account and view the timeline in ADTimeline.

f:id:hideakii:20190409190154p:plain

f:id:hideakii:20190409190341p:plain

On the timeline, the time stamp where I added Alice disappears, and a record of the time stamp where Alice was deleted is displayed.
Interesting :-)

Next, let's change the GPO ACL. Add an Alice account to Delegation.

Default Domain Policy: {31B2F340-016D-11D2-945F-00C04FB984F9}

f:id:hideakii:20190409202311p:plain

Event ID 4662 is recorded in the security log. Two more ID 5136 records are recorded.

f:id:hideakii:20190409202610p:plain

f:id:hideakii:20190409202905p:plain

Check the ACL of Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}. I can discover the privileges of Alice account.

f:id:hideakii:20190409203209p:plain

Check the timeline. The timestamp is the same as event ID 4662.
f:id:hideakii:20190409203427p:plain

Remove the access rights of Alice account that I added earlier from the GPO.

f:id:hideakii:20190409204033p:plain

In the security log, ID 4662 and ID 5136 are recorded.

f:id:hideakii:20190409204213p:plain

Create a timeline and compare it with the timestamps in the security log.

f:id:hideakii:20190409204553p:plain

 

Next, allow AdminSDHolder full control of Bob's account. (This change is the result of a previous test with DCshadow.)

This setting allows access by Bob account to Domain Admins group etc.

f:id:hideakii:20190408190032p:plain

Let's check the ACL. The report shows that Bob's account has full control.

f:id:hideakii:20190408190726p:plain

Execute ADTimeline and search AdminSDHolder to find out the following events.

ftimeLastOriginatingChange : 2019-04-08T11:28:47Z
Name : AdminSDHolder
pszAttributeName : nTSecurityDescriptor
ObjectClass : container
DN : CN=AdminSDHolder,CN=System,DC=example,DC=local
ObjectCategory : CN=Container,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName :
dwVersion : 4
WhenCreated : 2019-01-20 19:19:55Z
Member :
ftimeCreated :
ftimeDeleted :
SID :
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 114772
usnLocalChange : 114772

 

Next,
Change the security of Bob account. Change Owner to Bob and set Deny to Everyone.

f:id:hideakii:20190408191141p:plain

If try to view Bob's account security information, it will be denied.

f:id:hideakii:20190408191331p:plain

Scan the ACL again and view the report. I can see the permissions granted to Bob account, but the report does not include information about the Bob account itself.

f:id:hideakii:20190408194251p:plain

f:id:hideakii:20190408194334p:plain

 

Reference URL:

github.com

blog.stealthbits.com

An ACE Up the Sleeve:Designing Active Directory DACL Backdoors
https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf

 

f:id:hideakii:20190408185039j:plain

 

RDP NLA and ID 4624 Logon Type3

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

If NLA(Network Level Authentication) is enabled for RDP connection, event ID 4624 logon type 3 will be recorded in the security log.

Is there a way to determine the event ID 4624 logon type 3 recorded by NLA?
----------

Configure RDP in a test environment (Windows 10). Enable NLA in RDP settings.

f:id:hideakii:20190407190929p:plain

Connect to Windows 10 with MSTSC.EXE. Certification is required by NLA.

f:id:hideakii:20190407191713p:plain

Event ID 4624 Logon Type 3 is recorded in the security log when I enter the correct authentication information. 

f:id:hideakii:20190407192424p:plain

Event ID 4624 Logon Type 10 was recorded as the RDP connection was successful.
My question is, can I link this event to the NLA event ID 4624 Logon Type 3 record?

Unfortunately, Logon ID can not connect two events.

f:id:hideakii:20190407193211p:plain

Let's check the event log related to RDP.
ID 1149 is recorded at a very similar time to "ID 4624 logonType 3".

f:id:hideakii:20190407200155p:plain

 Arrange three events in time order. Although the timestamps do not match exactly, I can confirm that they are very close values.

2019-04-07T10:17:12.733209800Z ID 4624 Logon Type 3
2019-04-07T10:17:12.742504600Z ID 1149 Remote Desktop Services: User authentication succeeded:
2019-04-07T10:17:14.815911800Z ID 4624 Logon Type 10

Is there any information that links ID 1149 other than time stamp? I tried to compare the Correlation values, but this is not the same.

ID 4624 Logon Type 3:

Correlation
[ ActivityID] {31290b36-ed74-0000-4d0c-293174edd401}

ID 1149

Correlation
[ ActivityID] {f4208d55-a62e-41d8-a71b-58a083da0000}

Let's include the log of "Microsoft-Windows-TerminalServices-LocalSessionManager".

2019-04-07T10:17:12.733209800Z ID 4624 Logon Type 3
2019-04-07T10:17:12.742504600Z ID 1149 Remote Desktop Services: User authentication succeeded:
2019-04-07T10:17:14.815911800Z ID 4624 Logon Type 10
2019-04-07T10:17:14.859104600Z ID 41 Begin session arbitration:
2019-04-07T10:17:18.317919800Z ID 42 End session arbitration:
2019-04-07T10:17:20.549253300Z ID 21 Remote Desktop Services: Session logon succeeded:

 

When I sign out of RDP, Event ID 4634 logon type 3 is recorded. You can associate the ID 4624 with the Logon ID value(0x1E98FF).

f:id:hideakii:20190407203529p:plain

Let's arrange the log of "Microsoft-Windows-TerminalServices-LocalSessionManager" and ID 4634 in order of time.

2019-04-07T11:29:28.977682900Z ID 4647 User initiated logoff:
2019-04-07T11:29:29.028431800Z ID 23 Remote Desktop Services: Session logoff succeeded:
2019-04-07T11:29:29.396625500Z ID 40 Session 2 has been disconnected, reason code 12
2019-04-07T11:29:29.474687900Z ID 4634 An account was logged off.
2019-04-07T11:29:29.486780000Z ID 24 Remote Desktop Services: Session has been disconnected:

Is it a good idea to link ID 24 and ID 4634 with a timestamp and search for ID 4624 by Logon ID?

 

Reference URL:

docs.microsoft.com

docs.microsoft.com

 

f:id:hideakii:20190407190814j:plain

 

RDP and ID 1149 "Remote Desktop Services: User authentication succeeded:"

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • Windows 10: ID 1149 is recorded when Alice's account is successfully logged on via RDP.
  • Windows 10: If you specify the RestrictedAdmin option, the username and domain will be blank.
  • Windows 10: If you turn off NLA and log on with Rdesktop, ID 1149 will not be recorded.

----------

What kind of user operation is event ID 1149 recorded? Let's check the record in Windows 10 environment.

Enable Remote Desktop on Windows 10 (1809). NLA is ON.

f:id:hideakii:20190323075527p:plain

Start "mstsc.exe" on Windows Server 2019. IP address is specified as the connection destination.

f:id:hideakii:20190323080225p:plain

If the Alice account is successfully logged on, ID 1149 is recorded in "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational".

The ID 1149 is not recorded if the authentication fails, such as the user has made a mistake in the password.

f:id:hideakii:20190323080425p:plain

Disconnect RDP connection and connect again.ID 1149 is recorded.

f:id:hideakii:20190323080752p:plain

Use Remmina as an RDP client. If logon is successful, ID 1149 is recorded.

f:id:hideakii:20190323081731p:plain

f:id:hideakii:20190323081746p:plain

Executed with the /restrictedadmin option specified in mstsc. (I have changed the registry settings and enabled RestrictedAdmin mode.)

f:id:hideakii:20190323082350p:plain

If the logon is successful, the ID 1149 will be recorded but the username and domain will be blank.

f:id:hideakii:20190323083243p:plain

When port forwarding is used at the loopback address.

f:id:hideakii:20190323085455p:plain

Another user is logged on, and session arbitration occurs and select "NO". Also in this case, ID 1149 is recorded. (When this screen is displayed, the Alice account has successfully logged on. ID 4624 is recorded.)

f:id:hideakii:20190323090639p:plain

 

Next, turn off NLA.

f:id:hideakii:20190323084127p:plain

Use rdesktop as an RDP client. In this case, the ID 1149 is not recorded even if the Alice account is successfully logged on.

f:id:hideakii:20190323084406p:plain

<add>

In Windows 7 RDP, you can see the following screen. However, I was not able to reproduce the same situation on Windows 10.

f:id:hideakii:20190323113805p:plain

So I got a comment from @grayfold3d ! Thank you!
For details, please refer to his tweets.

I created an .RDP file and added the following to the end.

 enablecredsspsupport:i:0

The following screen I was expecting was displayed! 

f:id:hideakii:20190323114719p:plain

So I checked the event log. ID 1149 was not recorded.

After the above screen is displayed, even if Alice successfully logs on, ID 1149 is not recorded.

</add> 

 

[Note]
The recording pattern of ID 1149 was different between Windows 7 and Windows 10.

 

PS
By the way, I did not know the mstsc "/public" option. The option suppresses the registry and bitmap cache.

https://yamanxworld.blogspot.com/2015/01/public.html

 

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

ponderthebits.com

cyberforensicator.com

https://www.13cubed.com/downloads/rdp_flowchart.pdf

RDP Event Log DFIR
https://dfironthemountain.wordpress.com/2019/02/15/rdp-event-log-dfir/
dfironthemountain.wordpress.com

 

f:id:hideakii:20190318210122j:plain

 

Windows ID 4648 "A logon was attempted using explicit credentials"

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • Check when the ID 4648 occurs.
  • Runas,Overpass-the-Hash,NET USE,Task Scheduler(schtasks),PsExec,WMIC,PowerShell,Remote Desktop(mstsc)
  • If authentication fails, it differs depending on whether you specify a computer name or IP address.
  • If you specify an IP address instead of a computer name, the contents of "Additional Information" will differ.

f:id:hideakii:20190317093403p:plain

----------

What kind of user operation is event ID 4648 recorded?

The conditions for recording event ID 4648 are described by Microsoft at the following URL.

4648(S) A logon was attempted using explicit credentials. (Windows 10) | Microsoft Docs

Event Description:

This event is generated when a process attempts an account logon by explicitly specifying that account’s credentials.

This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the “RUNAS” command.

I would like to try some of the operations described above.

logged on to PC1 with Example\administrator. Confirm the ID 4648 by switching from the administrator account to the Alice account.

f:id:hideakii:20190313204957p:plain

(1)Runas

First, change the account to Alice with the Runas command. (Alice account is a user of domain. Also, Alice account is included in Domain Admins.)

f:id:hideakii:20190313205554p:plain

Entered Alice's password and RunAs succeeded.

f:id:hideakii:20190313205639p:plain

ID 4648 is recorded in the security log.

f:id:hideakii:20190313205908p:plain

What happens if the authentication fails?

f:id:hideakii:20190316070202p:plain

If the Runas command was not successful, I could not find ID 4648 in the security log. 

(2)Overpass-the-Hash

Execute Overpass-the-Hash using Alice's NTLM hash value. ID 4648 has not occurred in this operation.

f:id:hideakii:20190313210415p:plain

Execute the DIR command on the PtH CMD. By this operation, ID 4648 is recorded in the security log of PC1.

f:id:hideakii:20190313210945p:plain

f:id:hideakii:20190313211224p:plain

Connect to DC1 using the wrong hash value.

f:id:hideakii:20190316073433p:plain

DIR command failed, but the ID 4648 was recorded.

f:id:hideakii:20190316073634p:plain

(3)NET USE

I started Administrator's CMD newly and executed the NET USE command. Specify Alice account with /user option. (The command line specifies the computer name. Kerberos authentication is used.)

ID 4648 is recorded in the security log of PC1.

f:id:hideakii:20190313211757p:plain

f:id:hideakii:20190313212234p:plain

If the command was not successful, I could not find ID 4648 in the security log.

However, if you specify an IP address other than computer name, ID 4648 will be recorded.

f:id:hideakii:20190316072607p:plain

(4)Task Scheduler(schtasks)

Use the schtasks command to register a job on the remote system.
(I got an error a little ;-)

f:id:hideakii:20190313213922p:plain

ID 4648 is recorded in the security log of PC1. The contents of "Additional Information" is "host/DC1".

f:id:hideakii:20190313214031p:plain

If the command was not successful, I could not find ID 4648 in the security log.

f:id:hideakii:20190316070814p:plain

If you specify an IP address and authentication fails, ID 4648 will be recorded.

f:id:hideakii:20190316075426p:plain

f:id:hideakii:20190316075437p:plain

(5)PsExec

Execute ipconfig command on DC1 using PsExec command.  Specify Alice account with -u option.

f:id:hideakii:20190314205845p:plain

ID 4648 is recorded in the security log of PC1. The contents of "Additional Information" is "cifs/DC1". 

f:id:hideakii:20190314205730p:plain

If the command was not successful, I could not find ID 4648 in the security log.

f:id:hideakii:20190316071029p:plain

If you specify an IP address and authentication fails, ID 4648 will be recorded.

f:id:hideakii:20190316074146p:plain

(6)WMIC

Execute ipconfig command on DC1 using WMIC command.  Specify Alice account with /user option. 

f:id:hideakii:20190314211013p:plain

ID 4648 is recorded in the security log of PC1. The contents of "Additional Information" is "RestrictedKrbHost/DC1". 

f:id:hideakii:20190314211117p:plain

f:id:hideakii:20190318213847p:plain

If the command was not successful, I could not find ID 4648 in the security log.

f:id:hideakii:20190316071401p:plain

If you specify an IP address and authentication fails, ID 4648 was not recorded.

f:id:hideakii:20190316075016p:plain

(7)PowerShell

Execute Powershell and Enter-PSSession.  Specify Alice account with -Credential option. 

f:id:hideakii:20190314211628p:plain

ID 4648 is recorded in the security log of PC1. The contents of "Additional Information" is "HTTP/DC1". 

f:id:hideakii:20190314211717p:plain

If the command was not successful, I could not find ID 4648 in the security log.

f:id:hideakii:20190316071545p:plain

If you specify an IP address and authentication fails, ID 4648 was not recorded.

f:id:hideakii:20190316074559p:plain

(8)Remote Desktop(mstsc)

Execute mstsc command. Specify Alice account.
(NLA is enabled on DC1.)

f:id:hideakii:20190314212551p:plain

ID 4648 is recorded in the security log of PC1. The contents of "Additional Information" is "TERMSRV/dc1". 

f:id:hideakii:20190314212649p:plain

If the connection was not successful, I could not find ID 4648 in the security log.

f:id:hideakii:20190316071928p:plain

If you specified an IP address as the computer name, ID 4648 was recorded in the security log even if authentication failed.

f:id:hideakii:20190316072310p:plain

f:id:hideakii:20190316072236p:plain

The details of RDP and ID 4648 are described in "Event Log Analysis" of IIJ-SECT.

It also explains the case where ID 4648 is not recorded when using "Restricted Admin mode". Please refer to the following URL.

https://sect.iij.ad.jp/d/2018/05/044132/training_material_sample_for_eventlog_analysis.pdf

 

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

docs.microsoft.com

blog.menasec.net

 

https://sect.iij.ad.jp/d/2018/05/044132/training_material_sample_for_eventlog_analysis.pdf

f:id:hideakii:20190313203256j:plain

 

Active Directory and ADTimeline(5)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • Grant the access right of "AdminSDHolder" to Bob account, using DCshadow.
    The nTSecurityDescriptor of "AdminSDHolder" is recorded in the ADTimeline.
  • The process of SDProp updates the access rights such as "Domain Admins" etc...These ACLs will now include Bob accounts.

----------
[Note]Please be aware that the verification method not be sufficient.

I will Check the ADTimeline of the case where changed the ACL of AdminSDHolder with DCshadow. DCshadow was executed with reference to the following URL.

blog.stealthbits.com

Check the ACL before running DCshadow. Bob account does not have permissions for this folder. (Bob account does not have high privilege.)

f:id:hideakii:20190311161950p:plain

Run DCshadow and grant access to Bob account. You can confirm that the access right of the Bob account has been added.

f:id:hideakii:20190311162943p:plain

f:id:hideakii:20190311163059j:plain

Check the ADTimeline.  NT-Security-Descriptor attribute changes and "dwVersion" value is "2".

ftimeLastOriginatingChange : 2019-03-11T07:27:01Z
Name : AdminSDHolder
pszAttributeName : nTSecurityDescriptor
ObjectClass : container
DN : CN=AdminSDHolder,CN=System,DC=example,DC=local
ObjectCategory : CN=Container,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName :
dwVersion : 2
WhenCreated : 2019-01-20 19:19:55Z
Member :
ftimeCreated :
ftimeDeleted :
SID :
pszLastOriginatingDsaDN :
uuidLastOriginatingDsaInvocationID : d5bc3667-ea75-4e13-a074-70f751b5e55c
usnOriginatingChange : 41052
usnLocalChange : 65687

"ADobjects.xml" file contains detailed information of AdminSDHolder. I can check the ACL added to Bob account.

f:id:hideakii:20190311171540j:plain

Wait for execution of SDProp processing.
I can check the records related to ACL change of AdminSDHolder on the ADTimeline.
f:id:hideakii:20190311182033j:plain

Display the ACL of the Domain Admins group, Bob has full control. (also in "ADobjects.xml" file.)

f:id:hideakii:20190311182237j:plain

 

PS

I checked the status of adminCount in Bob account. the "adminCount" value of the Bob account is not set. 

f:id:hideakii:20190311163636j:plain

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

blog.stealthbits.com

www.labofapenetrationtester.com

docs.microsoft.com

f:id:hideakii:20190311161906j:plain

 

Active Directory and ADTimeline(4)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • Delete the Bob account. I can check the change of isDeleted on the ADTimeline.
  • Activate the AD recycle bin and delete the Bob account. The changing attributes are different. "isRecycled" is not set.

 ----------
[Note]Please be aware that the verification method not be sufficient.

Last week I confirmed the traces of DCShadow on the timeline. PC1 was temporarily registered as DC by DCshadow and deleted immediately after that.
Today, I would like to delete the user account Bob. (AD Recycle Bin is disabled in the test environment.)

The Bob account has the SIDHsitory value set. 

f:id:hideakii:20190303200458p:plain

Delete the Bob account from the administration tool. (Unfortunately, I do not know if I can use DCshdow to delete user accounts.)

f:id:hideakii:20190303201008p:plain

The Bob account has been deleted.  3/3/2019 11:10:29 AM

f:id:hideakii:20190303201147p:plain

Check the ADTimeline. Multiple records are recorded at the time when the Bob account was deleted.

f:id:hideakii:20190303202020p:plain

You can check the change of "isDeleted" attribute on the timeline.

ftimeLastOriginatingChange : 2019-03-03T11:10:29Z
Name : bob
DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76
pszAttributeName : isDeleted
ObjectClass : user
DN : CN=bob\0ADEL:c3027aff-3453-4894-bf89-f69a4fbb5e76,CN=Deleted
Objects,DC=example,DC=local
ObjectCategory :
SamAccountName : bob
dwVersion : 1
WhenCreated : 2019-02-11 07:06:37Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1601
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 61506
usnLocalChange : 61506

In the "ADobjects.xml" file, check the Bob account information. It is interesting that "isRecycled" attribute is set to True. (this object has been marked for permanent deletion)

 <Obj RefId="165">

<TNRef RefId="0" />
<ToString>CN=bob\0ADEL:c3027aff-3453-4894-bf89-f69a4fbb5e76,CN=Deleted Objects,DC=example,DC=local</ToString>
<Props>
<S N="CanonicalName">example.local/Deleted Objects/bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<S N="CN">bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<B N="Deleted">true</B>
<Nil N="Description" />
<Nil N="DisplayName" />
<S N="DistinguishedName">CN=bob\0ADEL:c3027aff-3453-4894-bf89-f69a4fbb5e76,CN=Deleted Objects,DC=example,DC=local</S>
<I32 N="instanceType">4</I32>
<B N="isDeleted">true</B>
<B N="isRecycled">true</B>
<S N="LastKnownParent">CN=Users,DC=example,DC=local</S>
<DT N="Modified">2019-03-03T11:10:29+00:00</DT>
<DT N="modifyTimeStamp">2019-03-03T11:10:29+00:00</DT>
<S N="Name">bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<Nil N="ObjectCategory" />
<S N="ObjectClass">user</S>
<G N="ObjectGUID">c3027aff-3453-4894-bf89-f69a4fbb5e76</G>
<Obj N="objectSid" RefId="166">
<TNRef RefId="4" />
<ToString>S-1-5-21-1490397982-2793378994-64436834-1601</ToString>
<Props>
<I32 N="BinaryLength">28</I32>
<S N="AccountDomainSid">S-1-5-21-1490397982-2793378994-64436834</S>
<S N="Value">S-1-5-21-1490397982-2793378994-64436834-1601</S>
</Props>
</Obj>
<B N="ProtectedFromAccidentalDeletion">false</B>
<S N="sAMAccountName">bob</S>
<I32 N="sDRightsEffective">15</I32>
<I32 N="userAccountControl">66048</I32>
<I64 N="uSNChanged">61506</I64>
<I64 N="uSNCreated">36953</I64>
<DT N="whenChanged">2019-03-03T11:10:29+00:00</DT>
<DT N="whenCreated">2019-02-11T07:06:37+00:00</DT>
</Props>
</Obj>

Check the "SIDHsitory" item in "log-adexport.log".

2019-03-03 11:13:25 Number of accounts with SIDHistory in the forest: 0

The Bob account has been deleted, but if go back in the timeline I can track changes in SIDHistory etc.

 

I tried to Enable AD Recycle Bin, and encountered an error. I need time to investigate this error. :-(
I restored the snapshot of the test environment.

f:id:hideakii:20190303205108p:plain

f:id:hideakii:20190303212831p:plain

Delete the Bob account again and check the timeline. 3/3/2019 12:29:41 PM

f:id:hideakii:20190303213453p:plain

The number of records differs from when deleting Bob account earlier.

f:id:hideakii:20190303213740p:plain

Interestingly, I can not find the attribute "isRecycled". For the isRecycled attribute when the Recycle Bin is enabled, the description is written at Microsoft's URL.

<Obj RefId="165">
<TNRef RefId="0" />
<ToString>CN=bob\0ADEL:c3027aff-3453-4894-bf89-f69a4fbb5e76,CN=Deleted Objects,DC=example,DC=local</ToString>
<Props>
<S N="CanonicalName">example.local/Deleted Objects/bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<S N="CN">bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<B N="Deleted">true</B>
<Nil N="Description" />
<S N="DisplayName">bob</S>
<S N="DistinguishedName">CN=bob\0ADEL:c3027aff-3453-4894-bf89-f69a4fbb5e76,CN=Deleted Objects,DC=example,DC=local</S>
<I32 N="instanceType">4</I32>
<B N="isDeleted">true</B>
<S N="LastKnownParent">CN=Users,DC=example,DC=local</S>
<DT N="Modified">2019-03-03T12:29:41+00:00</DT>
<DT N="modifyTimeStamp">2019-03-03T12:29:41+00:00</DT>
<S N="Name">bob_x000A_DEL:c3027aff-3453-4894-bf89-f69a4fbb5e76</S>
<Nil N="ObjectCategory" />
<S N="ObjectClass">user</S>
<G N="ObjectGUID">c3027aff-3453-4894-bf89-f69a4fbb5e76</G>
<Obj N="objectSid" RefId="166">
<TNRef RefId="4" />
<ToString>S-1-5-21-1490397982-2793378994-64436834-1601</ToString>
<Props>
<I32 N="BinaryLength">28</I32>
<S N="AccountDomainSid">S-1-5-21-1490397982-2793378994-64436834</S>
<S N="Value">S-1-5-21-1490397982-2793378994-64436834-1601</S>
</Props>
</Obj>
<B N="ProtectedFromAccidentalDeletion">false</B>
<S N="sAMAccountName">bob</S>
<I32 N="sDRightsEffective">15</I32>
<I32 N="userAccountControl">66048</I32>
<I64 N="uSNChanged">61509</I64>
<I64 N="uSNCreated">36953</I64>
<DT N="whenChanged">2019-03-03T12:29:41+00:00</DT>
<DT N="whenCreated">2019-02-11T07:06:37+00:00</DT>
</Props>
</Obj>

<ADD 2019/3/6>

Restore the Bob account from the Recycle Bin.

f:id:hideakii:20190306203424p:plain

The SIDHistory value of the Bob account has also been restored.

f:id:hideakii:20190306203939p:plain

Check the ADTimeline. You can find several records related to Bob account restore.

f:id:hideakii:20190306205537p:plain

Check the Bob account information in the ADobjects.xml file. A lot of interesting information was displayed.

<Obj RefId="165">
<TNRef RefId="0" />
<ToString>CN=bob,CN=Users,DC=example,DC=local</ToString>
<Props>
<I64 N="accountExpires">9223372036854775807</I64>
<S N="CanonicalName">example.local/Users/bob</S>
<S N="CN">bob</S>
<I32 N="codePage">0</I32>
<I32 N="countryCode">0</I32>
<DT N="Created">2019-02-11T07:06:37+00:00</DT>
<DT N="createTimeStamp">2019-02-11T07:06:37+00:00</DT>
<Nil N="Deleted" />
<Nil N="Description" />
<S N="DisplayName">bob</S>
<S N="DistinguishedName">CN=bob,CN=Users,DC=example,DC=local</S>
<Obj N="dSCorePropagationData" RefId="166">
<TNRef RefId="1" />
<LST>
<DT>2019-03-06T11:36:40+00:00</DT>
<DT>1601-01-01T00:00:00+00:00</DT>
</LST>
</Obj>
<S N="givenName">bob</S>
<I32 N="instanceType">4</I32>
<Nil N="isDeleted" />
<S N="LastKnownParent">CN=Users,DC=example,DC=local</S>
<I64 N="lastLogonTimestamp">131953593229547103</I64>
<DT N="Modified">2019-03-06T11:36:40+00:00</DT>
<DT N="modifyTimeStamp">2019-03-06T11:36:40+00:00</DT>
<S N="msDS-LastKnownRDN">bob</S>
<S N="Name">bob</S>
<Obj N="nTSecurityDescriptor" RefId="167">
<TNRef RefId="2" />
<ToString>System.DirectoryServices.ActiveDirectorySecurity</ToString>
<Props>
<S N="AccessRightType">System.DirectoryServices.ActiveDirectoryRights</S>
<S N="AccessRuleType">System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S N="AuditRuleType">System.DirectoryServices.ActiveDirectoryAuditRule</S>
<B N="AreAccessRulesProtected">false</B>
<B N="AreAuditRulesProtected">false</B>
<B N="AreAccessRulesCanonical">true</B>
<B N="AreAuditRulesCanonical">true</B>
</Props>
<MS>
<S N="Owner">EXAMPLE\Domain Admins</S>
<S N="Group">EXAMPLE\Domain Admins</S>
<Obj N="Access" RefId="168">
<TNRef RefId="3" />
<IE>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
<S>System.DirectoryServices.ActiveDirectoryAccessRule</S>
</IE>
</Obj>
<S N="Sddl">O:DAG:DAD:AI(A;;LCRPLORC;;;PS)(A;;RC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RPWP;e45795b2-9455-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;e45795b3-9455-11d1-aebd-0000f80367c1;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;;AU)(OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;AU)(OA;;RP;77b5b886-944a-11d1-aebd-0000f80367c1;;AU)(OA;;RP;e45795b3-9455-11d1-aebd-0000f80367c1;;AU)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;;RS)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-1490397982-2793378994-64436834-526)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-1490397982-2793378994-64436834-527)(OA;CIIOID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;CIIOID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;bf967a86-0de6-11d0-a285-00aa003049e2;PS)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;WP;ea1b7b93-5e48-46d5-bc6c-4df4fda78a35;bf967a86-0de6-11d0-a285-00aa003049e2;PS)(OA;CIIOID;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;LCRPLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;OICIID;RPWP;3f78c3e5-f79a-46bd-a0b8-9d18116ddc79;;PS)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(A;CIID;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1490397982-2793378994-64436834-519)(A;CIID;LC;;;RU)(A;CIID;CCLCSWRPWPLOCRSDRCWDWO;;;BA)</S>
<S N="AccessToString">NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\Authenticated Users Allow _x000A_NT AUTHORITY\SYSTEM Allow _x000A_BUILTIN\Account Operators Allow _x000A_EXAMPLE\Domain Admins Allow _x000A_Everyone Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\Authenticated Users Allow _x000A_NT AUTHORITY\Authenticated Users Allow _x000A_NT AUTHORITY\Authenticated Users Allow _x000A_NT AUTHORITY\Authenticated Users Allow _x000A_BUILTIN\Windows Authorization Access Group Allow _x000A_BUILTIN\Terminal Server License Servers Allow _x000A_BUILTIN\Terminal Server License Servers Allow _x000A_EXAMPLE\Cert Publishers Allow _x000A_EXAMPLE\RAS and IAS Servers Allow _x000A_EXAMPLE\RAS and IAS Servers Allow _x000A_EXAMPLE\RAS and IAS Servers Allow _x000A_EXAMPLE\RAS and IAS Servers Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_EXAMPLE\Key Admins Allow _x000A_EXAMPLE\Enterprise Key Admins Allow _x000A_CREATOR OWNER Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow _x000A_NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow _x000A_NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow _x000A_NT AUTHORITY\SELF Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_NT AUTHORITY\SELF Allow _x000A_NT AUTHORITY\SELF Allow _x000A_EXAMPLE\Enterprise Admins Allow _x000A_BUILTIN\Pre-Windows 2000 Compatible Access Allow _x000A_BUILTIN\Administrators Allow </S>
<S N="AuditToString"></S>
</MS>
</Obj>
<S N="ObjectCategory">CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local</S>
<S N="ObjectClass">user</S>
<G N="ObjectGUID">c3027aff-3453-4894-bf89-f69a4fbb5e76</G>
<Obj N="objectSid" RefId="169">
<TNRef RefId="4" />
<ToString>S-1-5-21-1490397982-2793378994-64436834-1601</ToString>
<Props>
<I32 N="BinaryLength">28</I32>
<S N="AccountDomainSid">S-1-5-21-1490397982-2793378994-64436834</S>
<S N="Value">S-1-5-21-1490397982-2793378994-64436834-1601</S>
</Props>
</Obj>
<I32 N="primaryGroupID">513</I32>
<B N="ProtectedFromAccidentalDeletion">false</B>
<I64 N="pwdLastSet">131943423975962354</I64>
<S N="sAMAccountName">bob</S>
<I32 N="sAMAccountType">805306368</I32>
<I32 N="sDRightsEffective">15</I32>
<Obj N="sIDHistory" RefId="170">
<TNRef RefId="1" />
<LST>
<Obj RefId="171">
<TNRef RefId="4" />
<ToString>S-1-5-21-1490397982-2793378994-64436834-500</ToString>
<Props>
<I32 N="BinaryLength">28</I32>
<S N="AccountDomainSid">S-1-5-21-1490397982-2793378994-64436834</S>
<S N="Value">S-1-5-21-1490397982-2793378994-64436834-500</S>
</Props>
</Obj>
</LST>
</Obj>
<I32 N="userAccountControl">66048</I32>
<S N="userPrincipalName">bob@example.local</S>
<I64 N="uSNChanged">65610</I64>
<I64 N="uSNCreated">36953</I64>
<DT N="whenChanged">2019-03-06T11:36:40+00:00</DT>
<DT N="whenCreated">2019-02-11T07:06:37+00:00</DT>
</Props>
</Obj>

</ADD>

I will continue testing.

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

w/ww.dell.com

github.com

docs.microsoft.com

blog.stealthbits.com

f:id:hideakii:20190303193143j:plain


 

Active Directory and ADTimeline(3)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • I added the Bob account to the "Domain Admins" group and deleted it from the group. You can check this operation with ADTimeline.
  • Run DCsync with Alice account. This operation could not be confirmed on the timeline.
  • Using DCshadw, set the SIDHsitory of the Bob account. The operation by DCshadow can be confirmed with ADtimeline.

----------

[Note]Please be aware that the verification method not be sufficient.

I checked the ADTimeline about Bob account last week.(Last week, I was not reading "README.md" carefully.)

Bob account is a regular user, today's test I would like to set Bob high privilege. Add the Bob account to the Domain Admins group and then delete it from the group.

f:id:hideakii:20190223102741p:plain

DC1: 2/23/2019 1:29:15 AM EID 4728 A member was added to a security-enabled global group.(Bob)

f:id:hideakii:20190223103236p:plain

DC2: 2/23/2019 1:35:23 AM Log on to PC1 with Bob account
DC2: 2/23/2019 1:40:50 AM Bob account log off.

Since Bob was a Domain Admins group, it appears on the timeline. I can check the following records on ADtimeline.(I have not set up a custom group.)

ftimeLastOriginatingChange : 2019-02-23T01:35:22Z
Name : bob
pszAttributeName : lastLogonTimestamp
ObjectClass : user
DN : CN=bob,CN=Users,DC=example,DC=local
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : bob
dwVersion : 2
WhenCreated : 2019-02-11 07:06:37Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1601
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : 97c9ab0f-143e-4218-96fb-a6bdc442af7e
usnOriginatingChange : 24760
usnLocalChange : 45216

Delete the Bob account from the Domain Admins group.

DC1: 2/23/2019 1:44:06 AM EID 4729 A member was removed from a security-enabled global group.(Bob)

f:id:hideakii:20190223104657p:plain

On ADTimeline, I can check the date and time Bob was added and deleted to Domain Adminsin the following record.

ftimeLastOriginatingChange : 2019-02-23T01:44:06Z
Name : Domain Admins
pszAttributeName : member
ObjectClass : group
DN : CN=Domain Admins,CN=Users,DC=example,DC=local
ObjectCategory : CN=Group,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : Domain Admins
dwVersion : 2
WhenCreated : 2019-01-20 19:20:35Z
Member : CN=bob,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-23T01:29:15Z
ftimeDeleted : 2019-02-23T01:44:06Z
SID : S-1-5-21-1490397982-2793378994-64436834-512
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 45230
usnLocalChange : 45230

 

Next test, I would like to grant high privilege by using Bob's SIDHistory.

Log on to PC1 with Alice account.Run Mimikatz on Alice account and check administrator's information using DCsync.

f:id:hideakii:20190223110023p:plain

DC2: 2/23/2019 1:53:36 AM EID 4662 An operation was performed on an object.

f:id:hideakii:20190223105926p:plain

On ADtimeline, I can confirm Alice 's logon, but I could not find a record related to DCSync. (I guess that metadata replication does not occur.)

 

Run DCshadow with the Alice account and set the Administrator's SID in the sidHistory of the Bob account.

f:id:hideakii:20190223111405p:plain

DC2: 2/23/2019 2:12:15 AM EID 4662 An operation was performed on an object.

f:id:hideakii:20190223111931p:plain

On the ADTimeline, I can confirm this operation with several records. "PC1" that operated DCshadow is displayed.

ftimeLastOriginatingChange : 2019-02-23T02:12:15Z
Name : PC1
DEL:de838231-3f87-47d4-b77f-8e3a546f2f31
pszAttributeName : dNSHostName
ObjectClass : server
DN : CN=PC1\0ADEL:de838231-3f87-47d4-b77f-8e3a546f2f31,CN=Servers,CN=Default-First-Site
-Name,CN=Sites,CN=Configuration,DC=example,DC=local
ObjectCategory :
SamAccountName :
dwVersion : 1
WhenCreated : 2019-02-23 02:12:15Z
Member :
ftimeCreated :
ftimeDeleted :
SID :
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : 97c9ab0f-143e-4218-96fb-a6bdc442af7e
usnOriginatingChange : 24859
usnLocalChange : 45319 

<add>

I got a comment in DM. The following time stamps show the same value. Promotion and deletion of DC occurred at the same time.

ftimeLastOriginatingChange = WhenCreated

</add>

 

The "log-adexport.log" file contains the output related to DCshadow.I have failed to run DCshadow once, so it is recorded twice. ;-)

2019-02-23 02:31:30 Domain Controller demotion or use of DCShadow: 2 deleted server objects and 2 deleted nTDSDSA objects located in the tombstone

You can also check records related to Bob's SIDHistory with ADTimeline.

ftimeLastOriginatingChange : 2019-02-23T02:12:15Z
Name : bob
pszAttributeName : sIDHistory
ObjectClass : user
DN : CN=bob,CN=Users,DC=example,DC=local
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : bob
dwVersion : 1
WhenCreated : 2019-02-11 07:06:37Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1601
pszLastOriginatingDsaDN :
uuidLastOriginatingDsaInvocationID : d5bc3667-ea75-4e13-a074-70f751b5e55c
usnOriginatingChange : 24822
usnLocalChange : 45335

The number of SIDHistory is output in the "log-adexport.log" file.

2019-02-23 02:31:30 Number of accounts with SIDHistory in the forest: 1
2019-02-23 02:31:30 Number of accounts with a suspicious SIDHistory in the current domain: 1

Let's check the properties of Bob account.

The SID of Administrator is set in SIDHistory of Bob account. On DC 2, the time stamp of whenChanged is "2/23/2019 2:12:15 AM".

f:id:hideakii:20190223112453p:plain

On DC1, the time stamp of whenChanged is "2/23/2019 2:12:30 AM".(Whenchanged is not replicated.)

f:id:hideakii:20190223112843p:plain

What is the change at 2:12:30? , I confirmed the event log but could not identify it.

You can download timeline and event log from here.

 

I will continue testing.

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

When-Changed attribute - Windows applications | Microsoft Docs

 

f:id:hideakii:20190223101501j:plain

 

Active Directory and ADTimeline(2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • I created an Alice account, added it to the Domain admins group, and confirmed it on the timeline.
  • Next, I created a Bob account and logged on to the domain, but I could not confirm it in the timeline (Note:Since Bob does not have high privilege, it is not displayed in ADTimeline. You can display Bob in the timeline using $groupscustom definition.)

----------

[Note]Please be aware that the verification method not be sufficient.

Continuing from last week, I would like to check what can be investigated by using ADTimeline.

I have newly constructed an Active Directory environment with two DCs. (DC1, DC2 and PC1)

First, I created users Alice and Bob.

DC1: 2/11/2019 7:05:45 AM EID 4720 A user account was created.(Alice)
DC2: 2/11/2019 7:05:45 AM EID 4720 A user account was created.(Bob)

I checked the DC1 and DC2 timelines, I found a record related to Alice account, but I could not find record related to Bob account. Interesting.

f:id:hideakii:20190217090609p:plain

Next, I added the Alice account to the Domain Admins group.

DC1: 2/11/2019 7:08:50 AM EID 4728 A member was added to a security-enabled global group.(Alice⇒Domain Admins)

In the timeline, there is a record related to the Domain Admins group and the "adminCount" of the Alice account.

f:id:hideakii:20190217091452p:plain

ftimeLastOriginatingChange : 2019-02-11T07:08:50Z
Name : Domain Admins
pszAttributeName : member
ObjectClass : group
DN : CN=Domain Admins,CN=Users,DC=example,DC=local
ObjectCategory : CN=Group,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : Domain Admins
dwVersion : 1
WhenCreated : 2019-01-20 19:20:35Z
Member : CN=alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-11T07:08:50Z
ftimeDeleted : 1601-01-01T00:00:00Z
SID : S-1-5-21-1490397982-2793378994-64436834-512
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 36964
usnLocalChange : 36964

In Microsoft Blog, ftimeDeleted and ftimeCreated are described.

ftimeDeleted the time the member has been removed (equal 0 if the object is currently still a member).
ftimeCreated the time when the member has been added for the first time.

 

Next, log on to PC1 with Alice account.

DC2: 2/11/2019 10:57:19 AM EID 4624 An account was successfully logged on.(Alice)

On the timeline, there is a record related to the "lastLogonTimestamp" of the Alice account.

f:id:hideakii:20190217094449p:plain

ftimeLastOriginatingChange : 2019-02-11T10:57:19Z
Name : alice
pszAttributeName : lastLogonTimestamp
ObjectClass : user
DN : CN=alice,CN=Users,DC=example,DC=local
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : alice
dwVersion : 1
WhenCreated : 2019-02-11 07:05:45Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1104
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 37098
usnLocalChange : 37098

On DC1 and DC2, check the properties of the Alice account. (Get-ADUser -identity alice -property *)

Since lastLogon is not replicated, there are differences in values.

DC1

lastLogon : 131943562397419196
LastLogonDate : 2/11/2019 10:57:19 AM
lastLogonTimestamp : 131943562397419196

DC2

lastLogon : 131943562396367072
LastLogonDate : 2/11/2019 10:57:19 AM
lastLogonTimestamp : 131943562397419196

The values output to ADobjects.xml created by ADTimeline are as follows.

lastLogon : 131943562397419196
lastLogonTimestamp : 131943562397419196

 

Next, I will also check the Bob account.(Bob account does not have high privilege.)

The Bob account logs on to the domain. You can check Bob's logon with DC1

 and DC2 security log.

DC1

f:id:hideakii:20190217103220p:plain

DC2

f:id:hideakii:20190217101315p:plain

However, I could not find a record related to Bob account. I searched Bob in ADobjects.xml, but it did not exist.

(ADD: I was testing it without understanding that ADTimeline was targeting high privilege. Bob does not have high privilege, so it is not displayed on the timeline.)

f:id:hideakii:20190217101534p:plain

Just to be sure, I will check the properties of Bob with DC1 and DC2. 
lastLogonTimestamp indicates the time Bob logged on. (2/11/2019 10:59:19 AM)

DC1

LastLogonDate : 2/11/2019 10:59:19 AM
lastLogonTimestamp : 131943563590742494

DC2

lastLogon : 131943563590742494
LastLogonDate : 2/11/2019 10:59:19 AM
lastLogonTimestamp : 131943563590742494

It is interesting that Bob's logon does not appear on the timeline.

f:id:hideakii:20190217144557p:plain

The timeline and event log created this time can be downloaded from here.

<add>

I could display Bob in the timeline by defining the "Domain Users" group in "$groupscustom".

$groupscustom = "Domain Users"

f:id:hideakii:20190217180549p:plain

(I have not read all of README.md. I was taught it by DM. Thank you! ;-)

</add>

 

PS

LastLogonTimeStamp seems to have delays of up to 14 days, not updates in real time.

blogs.technet.microsoft.com

 

I will continue testing.

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

blogs.technet.microsoft.com

blogs.technet.microsoft.com

 

f:id:hideakii:20190217085520j:plain