@port139 Blog

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

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



Active Directory and ADTimeline(1)

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

 Summary:

  • I added PC 1 to the example domain, but I could not find it on ADTimeline timeline.
  • I created an Alice account and added it to the Domain Admins group. Creating an Alice account and updating adminCount was confirmed on the timeline.
  • Removed Alice account from Domain Admins. In the timeline, records related to Domain Admin were recorded.
  • I created a Bob account in the Example domain, and then deleted the Bob account.

 ----------

[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.

In the test environment there are two computers DC1(Windows Sever 2019) and PC1(Windows 10 1809). Please note that there is only one DC, I have not tested the case where there are multiple DCs. ADTimeline is running on DC1.

 

Add PC1 to domain Example. 

f:id:hideakii:20190210102413p:plain

In the output of ADTimeline, the corresponding record could not be found. Whether changes to computer accounts will be recorded will be tested separately in the future.

 

Next, create an Alice account on the Example domain.

f:id:hideakii:20190210102719p:plain

The record when Alice was created could be confirmed on ADTimeline.

ftimeLastOriginatingChange : 2019-02-10T10:26:12Z
Name : Alice
pszAttributeName : primaryGroupID
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-10 10:26:12Z
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 : 24624
usnLocalChange : 24624


Add the Alice account to the "Domain Admins" group.

f:id:hideakii:20190210103031p:plain

In the output of ADTimeline, I could not find a record that added Alice to the "Domain admins" group.

When you add the Alice account to the Domain Admins group, Alice's "adminCount" is updated. You can check that record with the output of ADTimeline.

ftimeLastOriginatingChange : 2019-02-10T10:34:41Z
Name : Alice
pszAttributeName : adminCount
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-10 10:26:12Z
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 : 24647
usnLocalChange : 24647

<2019/02/11 add>

Traces of adding Alice to the Domain Admins group. I missed that timestamp, thank you for the comment!

ftimeLastOriginatingChange : 2019-02-10T10:38:49Z
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=Alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-10T10:28:38Z
ftimeDeleted : 2019-02-10T10:38:49Z
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 : 24648
usnLocalChange : 24648

Metadata #2 – The ephemeral admin, or how to track the group membership – Once upon a case…

ftimeCreated the time when the member has been added for the first time.

<2019/02/11 /add>

 

Log on to PC1 with "example\Alice" account.

f:id:hideakii:20190210103545p:plain

In the output of ADTimeline, related records could not be found.

 

Remove the Alice account from the "Domain Admins" group.

f:id:hideakii:20190210104001p:plain

In the output of ADTimeline you can see the records related to Domain Admins.

ftimeLastOriginatingChange : 2019-02-10T10:38:49Z
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=Alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-10T10:28:38Z
ftimeDeleted : 2019-02-10T10:38:49Z
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 : 24648
usnLocalChange : 24648

 

Log on to PC again with "example\Alice" account. For this logon, Alice is not a member of the Domain Admins group.

f:id:hideakii:20190210104340p:plain

I could not find related records in ADTimeline. 

 

Several items I tested were confirmed with ADTimeline. However, I have not tried other tests, such as deleting users.

I created a Bob account in the Example domain. Then delete the Bob account.

f:id:hideakii:20190210114340p:plain

ftimeLastOriginatingChange : 2019-02-10T02:42:20Z
Name : bob
DEL:36e610eb-61ef-4fb8-9f15-4612be60d2ae
pszAttributeName : accountExpires
ObjectClass : user
DN : CN=bob\0ADEL:36e610eb-61ef-4fb8-9f15-4612be60d2ae,CN=Deleted
Objects,DC=example,DC=local
ObjectCategory :
SamAccountName : bob
dwVersion : 2
WhenCreated : 2019-02-10 02:39:14Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1105
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 : 28709
usnLocalChange : 28709

While testing the Bob account I noticed that the time in the test environment was incorrect. The Bob account will be tested again. 

I will continue testing.

 

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

Reference URL:

github.com

Metadata #0 – Metadata, what is it and why do we care?

blogs.technet.microsoft.com

 

f:id:hideakii:20190210083637j:plain

 

Active Directory and When-Changed (2)

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

Summary:

  • I got some comments on Twitter about the previous contents. So I did a simple test using DCshadow.
  • Updates of SIDHistory etc. are explained in detail on the DCshadow web.
    I have not tried anything new in this blog. 
  • I tried creating a timeline using ADTimeline.

 ----------

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

Check the properties of "Alice", "SIDhistory" is not set.

f:id:hideakii:20190203195541j:plain

Using DCshadow, set "SIDhistory" to Alice.

f:id:hideakii:20190203201003j:plain

A value has been set for Alice's SIDHistory and "whenChanged" has been updated. The attribute of Alice has changed, but event ID 4738 is not recorded.

f:id:hideakii:20190203201225j:plain

Using PowerShell, delete Alice's SIDhistory.

Set-ADUser -Identity alice -Remove @{SIDHistory='S-1-5-21-1490397982-2793378994-64436834-500'}

f:id:hideakii:20190203202228j:plain

This operation which does not use DCshadow can be confirmed by event ID 4738.

f:id:hideakii:20190203202627j:plain

Use DCshadow to set the time stamp for whenChanged.

f:id:hideakii:20190203204451j:plain

You can confirm that the time stamp specified in "whenChanged" is set.

f:id:hideakii:20190203204533j:plain

If an attacker did not change the timestamp of whenChanged, can I track updates that are not recorded in the event log?


I tried ANSSI-FR/ADTimeline. I just ran the script and I am not used to this timeline format yet.

f:id:hideakii:20190203211938j:plain

I was able to check the timestamp of the record that deleted sIDHistory on the timeline.(This operation is recorded in the event log)
However, I could not find an update of sIDHistory by DCshadow.

f:id:hideakii:20190203212207j:plain

The sample ADtimeline that I created can be downloaded from here.

I will continue testing.

 

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

Reference URL:

docs.microsoft.com

www.dcshadow.com

github.com

https://www.ssi.gouv.fr/uploads/2019/01/anssi-coriin_2019-ad_timeline.pdf

 

f:id:hideakii:20190203194853j:plain

 

 

Active Directory When-Created and When-Changed (1)

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

Summary:

  • Active Directory accounts have "When-Created" and "When-Changed" attributes.
  • I am checking when those attributes are updated. However, I just started to verify.
  • When user Alice logon, the "lastLogon" attribute is updated, but "whenCahged" is not updated.
  • The following information is in the Microsoft article. Please refer to the reference URL for details.
    ・The Update Frequency of the "When-Created" attribute is "When the object is created."
    ・The Update Frequency of "When-Changed" attribute is "Each time the object is changed."
  • 2019/02/02 ADD
    ・Some attributes are not replicated between DCs. For example, "lastLogon" is not replicated.
    ・The System Flags item has the NR*1 flag bit. [MS-ADTS]: System Flags
  •  

 ----------

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

Create test account Alice on AD. Compare the date and time of the event log with the date and time of "When-Created", and confirm that they match.

f:id:hideakii:20190127085057p:plain

f:id:hideakii:20190127085208p:plain

f:id:hideakii:20190127092635p:plain

Log on to the domain with the Alice account and check the timestamp. Several logon date properties were added to the display.

When Alice first logged on to the domain, "When-Changed" was updated.

Is this update affected by updating attributes such as "lastLogon"? Or, it is "<not set>" at the time of account creation Is it the result of setting "lastLogonTimestamp"?

f:id:hideakii:20190127093358p:plain

When Alice logon, the "lastLogon" attribute is updated but "whenCahged" is not updated. (I have not confirmed the update of Last-Logon-Timestamp. LastLogonDate is the result of decoding lastLogonTimestamp?)

I repeated logon and logoff several times, but "when-Changed" was not updated.

 

Next test,
I added the Alice account to the Domain Admins group. This operation did not update "When-Changed" of Alice account.(It was not updated by this operation, but it will be updated with related events.) 

After adding Alice to the Domain Admins group, I did Logon and LogOff, but "when-Changed" was not updated.

f:id:hideakii:20190127094943p:plain

f:id:hideakii:20190127095151p:plain

While I was trying other tests, I noticed that "When-Changed" was being updated. So I confirmed the time when "When-Changed" was updated in the event log.

f:id:hideakii:20190127103639p:plain

Perhaps, I think that it is an ACL update event of "AdminSDHolder". I was forgotten to confirm the attributes of "adminCount" beforehand.

EID 4780

f:id:hideakii:20190127103927p:plain

EID 4738 is also recorded in the event log, but I could not identify which attribute was changed.

f:id:hideakii:20190127162603p:plain

 

I will continue testing.

 

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

Reference URL:

docs.microsoft.com

docs.microsoft.com

blogs.technet.microsoft.com

blogs.technet.microsoft.com

https://adsecurity.org/?p=1906

 

f:id:hideakii:20190127083722j:plain

 

*1:FLAG_ATTR_NOT_REPLICATED or FLAG_CR_NTDS_NC, 0x00000001

RDP and UserAssist (Win 10)

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


Summary:

----------

I used two Windows 10 to test RDP. The destination of RDP connection is Windows 10 ver 1809.(192.168.1.16).

In the MSTSC setting, assign F: drive.

f:id:hideakii:20190120100800p:plain

Connect to the remote system with RDP and browse F drive. There is an Autoruns tool on the F drive. Run Autoruns64.exe and Autorunsc64.exe.

f:id:hideakii:20190120102407p:plain

Load NTUSER.DAT into the Registry Explorer. (I'm very happy to be able to load the registry with Live!! :-)

You can check that Run Counter and Last Executed are recorded. 

f:id:hideakii:20190120104658p:plain

I read the article of "No run counts in UserAssist" and tested the execution of Task Scheduler.

f:id:hideakii:20190120110021p:plain

As Matthew Seyer wrote in the article, Run Counter and Last Executed were not recorded.

f:id:hideakii:20190120110220p:plain
Also, we tried executing the GUI program from CMD described on Twitter of Maxim Suhanov. Run Counter and Last Executed were not recorded.

f:id:hideakii:20190120111111p:plain

f:id:hideakii:20190120111517p:plain

 

There was nothing new in my test. ;-)
Thanks to everyone who has published validation results about UserAssist.

  

Verification environment: Windows 10 1809, Time zone UTC

Reference URL:

www.hecfblog.com

www.hecfblog.com

medium.com

 

binaryforay.blogspot.com

 

f:id:hideakii:20190120094750j:plain