42 entries

Windows Security

Sign-ins, account changes, and privilege use, recorded in the Windows Security log.

1102 Event 1102: The audit log was cleared Act now Someone wiped the Windows Security log. There is almost no legitimate reason to do this on a production machine, and it is one of the few events that is a finding entirely on its own. Whatever was in the log is gone.
4616 Event 4616: The system clock was changed Worth a look The machine's clock moved. Most of these come from the Windows Time service nudging things by a fraction of a second and are pure noise. A large jump, made by a user account, is a different matter — it is one of the simplest ways to make a timeline unreadable.
4624 Event 4624: An account was successfully logged on Informational Someone or something signed in successfully. This is the most common event in the Windows Security log and almost all of it is routine. What matters is the logon type, the source address, and whether the account should have been signing in there at all.
4625 Event 4625: An account failed to log on Worth a look Something tried to sign in to this machine and was rejected. On a home PC it is almost always a mistyped password or a stale saved credential. In bulk, from one source, against many usernames, it is password guessing.
4634 Event 4634: An account was logged off Informational A sign-in session ended. It is the bookend to Event 4624 and is mostly useful for measuring how long a session lasted. On its own it tells you almost nothing, and it fires constantly.
4647 Event 4647: A user initiated the logoff Informational Someone deliberately signed out, rather than a session simply being torn down. It is the event to use when you actually want to know that a person left, because Event 4634 fires for background sessions too.
4648 Event 4648: A logon was attempted using explicit credentials Worth a look A process signed in as a different account than the one already in use — the runas pattern. It is normal for administrators switching to a privileged account, and it is also exactly what an attacker does after stealing a credential.
4657 Event 4657: A registry value was changed Worth a look Someone or something changed a value in the registry, and Windows recorded the old value alongside the new one. It only fires on keys you have specifically marked for auditing — which is the catch, because by default that is none of them.
4662 Event 4662: An operation was performed on a directory object Worth a look Something acted on an Active Directory object. It is enormously noisy and mostly useless — except for one narrow case, where it is the only practical way to catch an attacker replicating every password hash in your domain.
4663 Event 4663: Something accessed a file, folder, or registry key Worth a look This is the event people reach for when they need to know who deleted a file. It records an access that was actually exercised — but only on objects you marked for auditing beforehand, and the word 'attempt' in Microsoft's title is misleading: a success here means the access happened.
4672 Event 4672: Special privileges assigned to new logon Worth a look A session started with administrative rights. It fires immediately after the matching 4624 and is the cheapest way to answer the question that actually matters: who signed in with privilege, and where.
4688 Event 4688: A new process has been created Informational A program started. This is Windows' own process-creation record, available without installing anything, and it is the backbone of working out what ran on a machine. Whether it includes the command line depends on a Group Policy setting most environments have never turned on.
4697 Event 4697: A service was installed in the system Investigate A new Windows service was registered. Services start automatically and run with high privilege, which is why installing one is a standard way to keep access to a machine. Most are ordinary software; the ones that are not stand out quickly.
4698 Event 4698: A scheduled task was created Investigate A new scheduled task was registered. Tasks run on their own, survive reboots, and can run as SYSTEM — which is why creating one is among the most common ways to keep access to a machine. The event includes the task's full definition.
4699 Event 4699: A scheduled task was deleted Worth a look A scheduled task was removed. Usually software being uninstalled. The pattern worth hunting is a task created and deleted within a short window, which is what an attacker does when the task has served its purpose.
4702 Event 4702: A scheduled task was updated Worth a look An existing scheduled task was modified. It is far noisier than task creation, because Windows updates its own maintenance tasks constantly — and that noise is exactly what makes hijacking an existing task quieter than creating a new one.
4719 Event 4719: The audit policy itself was changed Investigate Someone changed what Windows records. This is the event that tells you your logging has been altered — and because turning auditing off is a standard step before doing anything else, a 4719 that nobody can account for deserves more attention than most events in the Security log.
4720 Event 4720: A user account was created Investigate A new user account was created, either on the local machine or in the domain. In a managed environment every one of these should be traceable to a request. An account you cannot account for is one of the clearest findings available in the Windows log.
4722 Event 4722: A user account was enabled Worth a look A disabled account was switched back on. Routine when someone returns from leave or a new account is finished being set up. Worth a question when the account has been dormant for a long time and nobody asked for it back.
4723 Event 4723: A user changed their own password Informational Someone changed their own password, supplying the old one to do it. That is what separates it from Event 4724, where an administrator resets a password without knowing the current one — and it is why 4723 is the far less interesting of the two.
4724 Event 4724: An attempt was made to reset an account's password Worth a look Someone reset another account's password without knowing the old one — an administrative reset. It is routine at a help desk and it is also how an attacker takes over an existing account, so the pairing of who reset whose password is the thing to read.
4725 Event 4725: A user account was disabled Worth a look An account was switched off without being deleted. It is the correct way to remove access — the account keeps its identifier, so what it owned and what it did remain traceable. Most are ordinary offboarding.
4726 Event 4726: A user account was deleted Investigate A user account was removed. Most are ordinary offboarding. The ones that matter are deletions nobody requested, and deletions of accounts that were created only hours earlier — which is what cleaning up after an intrusion looks like.
4728 Event 4728: A member was added to a global group Act now An account was added to a domain global group. When the group is Domain Admins or Enterprise Admins, the account now controls the entire domain — and there is no more consequential single line in the Windows log.
4729 Event 4729: A member was removed from a global group Worth a look An account lost membership of a domain group. The part that catches people out is that it does not take effect straight away — an existing Kerberos ticket still carries the old membership until it expires, so the account keeps its access for up to ten hours.
4732 Event 4732: A member was added to a local group Investigate An account was added to a local group. When that group is Administrators, this is the moment someone gained full control of the machine — and it is one of the highest-value single events in the entire Windows log.
4733 Event 4733: A member was removed from a local group Worth a look An account lost membership of a group on one machine. Most of these are not people at all — Group Policy and privileged access tooling rewrite local group membership on a schedule, which produces steady, harmless churn that hides the removals that do matter.
4738 Event 4738: A user account was changed Worth a look An attribute on an account was modified. It fires constantly and most of it is meaningless, but a handful of the flags it records are among the clearest attack indicators in Active Directory — particularly the one that disables Kerberos pre-authentication.
4740 Event 4740: A user account was locked out Worth a look An account hit the failed-password threshold and Windows locked it. Nine times out of ten a device is still offering an old password. The field that solves it is the caller computer name, which tells you where the bad attempts came from.
4756 Event 4756: A member was added to a universal group Act now An account joined a universal group, which applies across every domain in the forest. Enterprise Admins and Schema Admins are universal groups — which makes this the widest-reaching of the three group-membership events.
4757 Event 4757: A member was removed from a universal group Worth a look An account lost membership of a forest-wide group. Removal from Enterprise Admins is usually correct housekeeping — unless it happens shortly after an addition nobody requested, which is what covering tracks looks like.
4767 Event 4767: A user account was unlocked Informational A locked account was released, either by an administrator or by the lockout duration expiring. On its own it is administrative housekeeping — its value is as the closing bracket on a lockout, and as a way to spot accounts that lock again minutes later.
4768 Event 4768: A Kerberos ticket (TGT) was requested Worth a look An account asked a domain controller for the ticket that lets it request everything else. It is the moment authentication actually happens in Active Directory — and two of its fields expose encryption downgrade and AS-REP roasting, which little else will show you.
4769 Event 4769: A Kerberos service ticket was requested Worth a look An account asked for a ticket to reach a specific service. It is the single best detection for Kerberoasting — because the ticket is encrypted with the service account's password, and anyone who can request one can attack that password offline, undetected.
4771 Event 4771: Kerberos pre-authentication failed Worth a look A domain controller refused a Kerberos sign-in, almost always because the password was wrong. In an Active Directory domain this is where failed sign-ins actually land, so it is usually more useful than hunting for 4625 on individual machines.
4776 Event 4776: NTLM credential validation on a domain controller Worth a look A domain controller checked a password using NTLM and recorded whether it matched. It is the place NTLM sign-in failures land when the machine the user actually touched is not one you collect logs from, which makes it the widest net you have for failed authentication.
4800 Event 4800: The workstation was locked Informational Someone locked the screen, or Windows locked it after a period of inactivity. It is not a security signal by itself — its value is reconstructing when a person was actually present at a machine.
4801 Event 4801: The workstation was unlocked Informational Someone supplied credentials to return to a locked session. It closes the bracket opened by Event 4800, and together the pair tell you exactly when a person was physically present at a machine.
5140 Event 5140: A network share object was accessed Worth a look Something connected to a shared folder over the network. Ordinary file access produces enormous volumes of this, but connections to the hidden administrative shares are a different matter — they are how remote administration and lateral movement both work.
5145 Event 5145: Detailed file share access Worth a look Someone reached a specific file or pipe over a network share, and Windows recorded exactly which one and what access they asked for. It is enormously noisy — and it is also the clearest view you can get of remote execution tooling and share enumeration.
5156 Event 5156: The firewall allowed a connection Informational Windows recorded a network connection it allowed. Not blocked — allowed. If your Security log has filled up overnight, this is almost certainly why: it fires for every permitted connection in both directions, and on a busy machine that is millions of events a day.
5157 Event 5157: The firewall blocked a connection Informational Windows stopped a connection because no rule allowed it. This is the firewall working, not evidence of an attack — Windows blocks inbound traffic by default, so an internet-connected machine collects these constantly. Its real use is diagnostic: it is the fastest way to find which rule is breaking an application.