Search Results

Everyone who does digital forensics has seen wipers. Funny part is attackers and careless admins both sometimes want files gone . Tools that overwrite/delete files — “wipers” — are common and can hide evidence. SDelete (a Sysinternals tool signed by Microsoft) is famous because it can slip past some whitelisting and looks “legit” on a system. But SDelete is only the tip of the iceberg — there are other tools and each leaves its own marks. Knowing those marks helps you figure out what happened  even when the file contents are gone. ------------------------------------------------------------------------------------------------------------ The main players Here are the common tools investigators run into: SDelete (Sysinternals)  — overwrites file clusters and free space. Popular because admins use Sysinternals and signatures make it look benign. BCWipe (commercial)  — very thorough, has features to wipe MFT records, slack space, and other NTFS artifacts . Commercial product; trial exists. Eraser (open source)  — long-lived tool. Renames files many times (seven by default), overwrites clusters , etc. cipher.exe (built-in Windows)  — intended for EFS tasks but /w:  can wipe free space. Very stealthy because it’s a system binary. ------------------------------------------------------------------------------------------------------------ What these tools try  to hide — and what they often fail to hide Wipers attempt to remove traces of a file. But Windows and NTFS create lots of metadata, logs, and side-files that are harder to fully erase. From an investigator’s point of view, the goal  is often just to prove the file existed  and that wiping happened  — not necessarily to recover the original content. Commonly left-behind evidence includes: USN Journal ($UsnJrnl) entries  — rename, delete, data-overwrite, stream changes. Wipers produce many USN events if they rename/overwrite repeatedly. NTFS LogFile ($LogFile)  — sometimes contains original file names or operations even when MFT entries are gone. MFT records ($MFT)  — deleted or overwritten MFT entries, reused MFT entry numbers (tools may create new files using same MFT index). Prefetch / evidence-of-execution  — prefetch files and other execution traces often show the wiper ran. ADS (Zone.Identifier)  — some tools (e.g., Eraser) leave alternate data streams like Zone.Identifier intact, which can reveal source URLs or original filenames. Temporary directories / filenames  — e.g., EFSTMPWP left behind by cipher.exe, or ~BCWipe.tmp created by BCWipe. Odd timestamps  — some wipers zero timestamps (e.g., set to Windows epoch Jan 1, 1601) which looks suspicious. Large flurries of rename / DataOverwrite / DataExtend events  — pattern of many sequential operations in a short time window. ------------------------------------------------------------------------------------------------------------ Short tool profiles + investigator takeaways SDelete What it does:  Overwrites clusters and free space. Why it’s sneaky:  Signed Sysinternals binary → looks legitimate. Look for:  USN and MFT evidence of overwrites and prefetch/execution traces for sdelete.exe. BCWipe What it does:  Commercial, deep-wiping features (MFT, slack, NTFS $LogFile features advertised). Real behavior:  Very noisy in NTFS journals — lots of renames, data-overwrite events, and creative file/directory creation to overwrite metadata (e.g., ~BCWipe.tmp, ... filenames). Look for:  ~BCWipe.tmp directories, massive $UsnJrnl activity in a short time, entries that show rename → overwrite → delete sequences, prefetched BCWipe executables. Eraser What it does:  Open-source, renames files repeatedly (7 passes by default), overwrites clusters. Quirks:  Leaves Zone.Identifier ADS sometimes; renames and timestamp zeroing (Jan 1, 1601) are common. Look for:  Repeated rename patterns in USN, C (change ) time updated but other times zeroed, leftover ADS pointing to original download URL. cipher.exe What it does:  Windows built-in — /w: wipes free space by creating temporary files to overwrite free clusters. Quirks:  Leaves a directory named EFSTMPWP at the root (observed persisting across reboots in many tests), creates many fil.tmp files while running. Look for:  EFSTMPWP directory, temporary fil*.tmp files, prefetch entries showing cipher run (and Windows event traces of disk activity). ------------------------------------------------------------------------------------------------------------ Example artifact patterns to search for: You can use these heuristics in your triage/scripting/search: Search USN journal for many sequence-like events (rename → data overwrite → delete) within seconds — suspicious. Look for directory names and temporary filenames: ~BCWipe.tmp, BCW, filXXXX.tmp. Check prefetch for unexpected executables: sdelete.exe, bcwipe*.pf, eraser*.pf, cipher*.pf. Scan for Zone.Identifier ADS on recently deleted files (may include original download URL or filename). Find files with timestamps set to zeroed timestamps — a potential sign of Eraser or timestamp wiping. Look for an MFT entry number reused by a later file or directory — indicates the original MFT record was targeted and may have been overwritten. Parse $LogFile (transaction log) for strange entries that mention original file names even when $MFT shows deletion. ------------------------------------------------------------------------------------------------------------ Investigator workflow Snapshot everything  (image the volume) — you need a forensically sound copy. Parse the MFT and USN  — timeline representation is crucial. Many wipers create big bursts in the USN journal that are easy to see in a timeline. Check $LogFile and shadow copies  — sometimes these hold remnants of filenames or older versions. Search ADS  — Zone.Identifier can unexpectedly reveal original source/location. Look for prefetch and execution evidence  — often the wiper executable will leave a prefetch or service entry. Remember SSD caveats  — wear-leveling and TRIM can make complete overwrites unreliable on SSDs; artifacts can be missing or inconsistent. Correlate with logs  — application logs, Windows event logs, and backup logs can confirm when delete/wipe activity occurred. ------------------------------------------------------------------------------------------------------------ Caveats and testing notes (be honest about limits) Tests often assume the active file clusters were overwritten — but you can’t always prove every  copy was overwritten (especially on SSDs). Some wipers advertise wiping certain structures (like $LogFile), but testing showed mixed results — so always verify with artifacts rather than relying on vendor claims. ------------------------------------------------------------------------------------------------------------ Short example: cipher.exe /w:C: — what to expect If someone runs cipher.exe /w:C: after deleting files: You may see EFSTMPWP at C:\ root. Temporary fil####.tmp files created and deleted during the run. No direct evidence of which files were wiped (cipher writes free space), but you can correlate deletion times from USN/MFT earlier in the timeline to guess what got targeted. Prefetch and process execution traces will show cipher.exe ran. ------------------------------------------------------------------------------------------------------------ Wrap-up — final thought Wipers try to erase content , but they often leave stories . The job of a forensic examiner is to read those stories in metadata, journals, and side-files. Look for patterns — rapid renames, heaps of USN events, leftover temp folders, strange timestamps, MFT reuse, and ADS — and you’ll often reconstruct what happened even when the file is gone. -------------------------------------Dean---------------------------------------------------------------

If you’ve been following me for a while, you already know how much I love Sublime . It’s one of those tools that just keeps getting better — feature after feature, update after update — all with one goal: making email security effortless . And today, they’ve released something that’s honestly a game changer . The Hidden Threat: Malicious Calendar Invites We’ve all seen those sketchy calendar invites — you know, the ones that magically appear on your calendar even though you never accepted them. Sometimes they’re phishing attempts. Sometimes they’re just spam. Either way, they’re becoming a growing problem across both Google Workspace  and Microsoft 365 . Attackers have learned that not every threat has to come through your inbox. Many organizations still allow automatic calendar event additions, and that’s where trouble starts . A single malicious invite can trick users into clicking phishing links or even expose them to malware. That’s why this new Sublime feature is such a big deal. ------------------------------------------------------------------------------------------------------------- What’s New: Automatic Calendar Event Deletion Sublime’s new Automatic Calendar Event Deletion  feature can now automatically delete malicious or unwanted calendar events  whenever you: Quarantine a message, Move it to spam, or Send it to the trash. In short, if a bad email comes in with a sneaky calendar invite attached — Sublime wipes that calendar entry for you. That’s brilliant. One less attack vector to worry about. ------------------------------------------------------------------------------------------------------------- Why It’s So Useful Think about this: You receive a spam or phishing email that includes a calendar invite. Even if you delete the email, that event might still sit  on your calendar, waiting for someone to click it later. Now, Sublime closes that gap completely. When you remove or quarantine the email, the related calendar event goes with it. This is exactly the kind of intelligent automation that saves time and  improves security posture at the same time. ------------------------------------------------------------------------------------------------------------- How to Join the Public Beta This feature is currently in public beta , and getting it enabled is pretty simple. You just need to update the Sublime app permissions to include Calendar access , then notify the Sublime team. (I’ll update this once it goes live — currently, it’s in beta mode.) Here’s a quick breakdown based on your setup: For Google Workspace (Cloud-Managed) Log in to your admin console: https://admin.google.com Go to Security → Access and Data Control → API Controls Scroll down to Domain-wide delegation  and click Manage domain-wide delegation Click Add new Enter the Client ID: 112905660299333414135 Add this scope: https://www.googleapis.com/auth/calendar.events Wait up to 24 hours for the changes to apply For Google Workspace (Self-Managed) Add the Calendar API scope to your existing domain-wide delegation client Enable the Google Calendar API in your project Wait up to 24 hours for propagation For Microsoft 365 (Cloud-Managed) Visit your organization-specific authorization link Approve the consent request that includes “ Read and write calendars ” You’ll be redirected back to Sublime’s homepage Wait up to 24 hours for it to take effect For Microsoft 365 (Self-Managed) Add the Calendars.ReadWrite permission to your Azure AD app Grant admin consent Allow up to 24 hours for changes Once you’re done, just let the Sublime team know so they can enable the feature in your environment. That’s it — no further configuration needed. (Note: Restoring deleted calendar events isn’t supported yet, but they’ve confirmed it’s coming soon. For now, users can re-RSVP to a restored message to re-add the event.) ------------------------------------------------------------------------------------------------------------- Bonus Tips: Strengthen Your Calendar Security While Sublime’s update adds a huge layer of protection, there are still a few best practices every organization should follow. For Google Workspace: Go to Apps → Google Workspace → Calendar → Advanced Settings Under “Add invitations to my calendar” , choose one of: “Invitations from known senders,” or “Invitations users have responded to via email.” This prevents random senders from silently placing meetings on your calendar. For Microsoft 365: Use PowerShell to stop your system from auto-accepting events. Run: Set-CalendarProcessing -Identity -AutomateProcessing None This disables the “Calendar Attendant” that automatically processes invites — giving you more control. ------------------------------------------------------------------------------------------------------------- My Take: Honestly, this update just shows how Sublime really listens to real-world threats . Attackers keep finding new ways to sneak in — even through calendars — and Sublime is always one step ahead. Automatic Calendar Event Deletion might sound like a small addition, but in practice, it can save analysts hours of investigation time and prevent users from walking right into phishing traps. I’ve said it before and I’ll say it again — this is why I love Sublime. If you’re managing email security, you should definitely check this feature out. ------------------------------------------------------------------------------------------------------------- Final Thought Cybersecurity isn’t just about blocking emails anymore. It’s about protecting every single touchpoint  — even your calendar. And with this new feature, Sublime just made that a whole lot easier. -------------------------------------------------Dean---------------------------------------------------

Welcome back, folks! If you’ve been following this series, I’ve already covered how attackers move laterally using things like named pipes, scheduled tasks, services, and registry modifications and more .Now it’s time to unpack some classic but still dangerous  remote execution tricks — and how to actually hunt them down using Windows logs. ------------------------------------------------------------------------------------------------------------- PowerShell Remoting & WMIC — Attackers’ Favorite “Admin Tools” Here’s the deal : not every network logon (Event ID 4624 , Type 3 ) means RDP or SMB. Sometimes, those logons come from administrative tools  being misused for remote execution — particularly PowerShell Remoting , WMIC , or WinRS . Attackers love these tools because: They’re already installed  on almost every Windows machine. They blend in perfectly with normal IT activity. And they use legitimate protocols  (WinRM or RPC), which defenders often ignore. WMIC (Windows Management Instrumentation Command-Line) The WMIC /node:  command lets you run commands remotely using RPC. When someone runs this: wmic /node:cyberengage.svr process call create "cmd.exe /c C:\Public\HackBloodHound.exe" Windows creates a WmiPrvSE.exe  process on cyberengage.svr to execute that command. Detection tip: If you see WmiPrvSE.exe  spawned unexpectedly — especially running a strange command or launching tools like PowerShell, cmd.exe, or unknown binaries — that’s a huge red flag. Log relationships to remember: Event ID 4624  (Type 3) → Remote network logon Parent process:  WmiPrvSE.exe Child process:  The command being executed (cmd.exe, powershell.exe, etc.) Use Sysmon Event ID 1 (Process Creation)  or 4688 (Security Log)  to tie it all together. PowerShell Remoting (WinRM) PowerShell remoting uses the WinRM  service to execute PowerShell commands on remote systems. When an attacker runs: Enter-PSSession -ComputerName cyberengage.svr -Credential Administrator or Invoke-Command -ComputerName cyberengage.svr -ScriptBlock { Start-Process C:\Public\HackBloodHound.exe } On the target endpoint , you’ll see WSMProvHost.exe  kick in. That’s the host process responsible for remote PowerShell sessions. Detection tip: In your EDR or Sysmon data, look for WSMProvHost.exe  as a parent of suspicious child processes (like cmd.exe, powershell.exe, rundll32.exe, etc.). Log indicators: Event ID 4624 , Logon Type 3 (network logon) Parent process:  WSMProvHost.exe Sysmon Event ID 1  → shows the actual command line executed remotely. WinRS (Windows Remote Shell) This one’s often overlooked but used heavily by adversaries. winrs.exe works over the same WinRM  protocol as PowerShell remoting — but it directly runs programs instead of PowerShell commands. Example: winrs -r:cyberengage.svr "C:\Public\HackBloodHound.exe" This will launch WinrsHost.exe  on cyberengage.svr, which spawns cmd.exe → executes the malicious payload. Detection stack: Event ID 4624 , Logon Type 3 Process chain:  svchost.exe → WinrsHost.exe → cmd.exe → HackBloodHound.exe Sysmon Event ID 1  to capture command-line parameters. ------------------------------------------------------------------------------------------------------------- Explicit Credentials — Watching Attackers Switch Keys The most underrated event types : Event ID 4648  — “A logon was attempted using explicit credentials.” Here’s what that means: Someone (or something) explicitly provided a username/password to run a command — instead of using cached credentials from their current logon session. So when attackers use tools like: runas /user:Administrator cmd.exe psexec -u cyberengage.org\user -p Welcome123 \\cyberengage.svr cmd.exe or use Cobalt Strike modules that specify credentials — you’ll get a 4648 event . What makes this event gold  for defenders is that it’s logged on the source system  — the machine the attacker is coming from , not just the one they’re moving to . That means you can finally track the attack chain backwards  — see where lateral movement originated . How to Investigate 4648s 4624 Logon Type 9  = Successful logon with explicit credentials 4648  = “Tool used explicit credentials” (even if it’s the same user account) If you see a 4648 → look at: “Target Server” field — if it shows localhost, it’s inbound; if it shows another host, it’s outbound. The username and process that initiated it. The timestamp — match it against process creation or PowerShell logs. Pro tip: Filter out the noise (computer accounts, M365 services, etc.) — what remains is almost always either: Admins doing maintenance, or Attackers moving laterally ------------------------------------------------------------------------------------------------------------- NTLM Relay Attacks — Spotting the Subtle Network Trick Now, for the fun part. NTLM relay attacks don’t “crack” passwords — they just reuse  authentication requests to trick another system into accepting them. So what happens in the logs? Event ID 4624  on Server  will show: Workstation Name:  Client Source Network Address:  IP of Server That mismatch is your giveaway. This “split identity” is a strong sign of NTLM relay in action. To confirm: Correlate the IPs — is the workstation name and source IP inconsistent? If DHCP is used, grab DHCP lease logs to confirm which IP belongs to which device. NTLM relay attacks often accompany SMB traffic anomalies (e.g., access to ADMIN$, IPC$ shares. ------------------------------------------------------------------------------------------------------------- Combined Up Recap: Technique Key Parent Process Log/Event IDs Detection Clue WMIC WmiPrvSE.exe 4624 (Type 3), Sysmon 1 Suspicious child processes PowerShell Remoting WSMProvHost.exe 4624, Sysmon 1 PowerShell remote commands WinRS WinrsHost.exe 4624 Command execution via WinRM Explicit Credentials varies 4648, 4624 Type 9 Source-based credential use NTLM Relay N/A 4624 Workstation name ≠ IP address ------------------------------------------------------------------------------------------------------------- Credential Theft and Reuse Credential theft and reuse attacks often exploit weaker encryption types  and legacy authentication protocols (NTLM)  to move laterally through a Windows domain. Key detection points lie in Kerberos event IDs (4768, 4769)  and NTLM authentication logs (4624, 4776) . 1. Abuse of Weak Kerberos Encryption (RC4-HMAC-MD5) Attackers often force the use of weaker encryption types  to speed up offline password cracking or perform “Overpass-the-Hash” (pass-the-key) attacks. Common Scenarios: Attack Type Description Key Event ID(s) Detection Indicator Kerberoasting Attackers request service tickets encrypted with weak RC4-HMAC-MD5 to brute-force service account passwords offline. 4769 Encryption Type: 0x17 or 0x18 Overpass-the-Hash Attackers use a stolen NT hash to request a TGT using RC4 encryption. 4768 Encryption Type or (post-Jan 2025) Session Type: 0x17 / 0x18 Key Log Artifacts: Event ID 4769 – Service Ticket Request Ticket Encryption Type: 0x17 (RC4-HMAC-MD5) Event ID 4768 – TGT Request Ticket Encryption Type: 0x17 Session Encryption Type: 0x17 (Post-Jan 2025 patch introduces more fields for encryption visibility.) Why RC4 Matters RC4-HMAC-MD5 (0x17) is a legacy encryption type . AES128 (0x11) or AES256 (0x12) are default for modern environments. Seeing frequent 0x17 or 0x18 tickets → highly suspicious , unless legacy systems exist. Defender Tip: Hunt for Event IDs 4768/4769  where Encryption Type = 0x17 or 0x18.Filter out legacy systems, then review recent TGS/TGT requests by privileged or service accounts. 2. NTLM and Pass-the-Hash Detection Even with Kerberos as the default protocol, NTLMv2 authentication  still appears — especially in legacy or IP-based connections. Attackers exploit NTLM through pass-the-hash , relay , or forced authentication  attacks. Detection via Logs: Log Type Event ID Description Account Logon 4776 NTLMv2 authentication attempt Logon Success (Network) 4624 Check for Authentication Package: NTLM and Package Name (NTLM only): NTLM V2 Normal vs Suspicious: Normal:  Kerberos authentication seen (Package Name: -) Suspicious:  NTLMv2 used on systems that normally use Kerberos(e.g., sudden NTLMv2 activity on domain controllers or file servers) Sample 4624 Log (NTLMv2) Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Package Name (NTLM only): NTLM V2 Key Length: 128 Hunt Strategy: Look for unusual NTLMv2 authentications  in Event IDs 4624 / 4776. Correlate with 4648 (Explicit Credentials)  or 4624 Logon Type 9  to trace the origin. Watch for sudden NTLMv2 spikes  or logons to unfamiliar hosts . 3. Post-Jan 2025 Microsoft Patch — What Changed? Microsoft’s January 2025 update enhanced Event ID 4768 and 4769  logs: Added new fields: Session Encryption Type Pre-Authentication Encryption Type Long-Term Key Type visibility Enables defenders to differentiate client-supported encryption vs DC-issued encryption . Greatly improves detection of RC4 downgrade or forced-weak encryption  scenarios. 4. Other Lateral Movement Indicators Technique Event ID What to Look For Credential switching (RunAs) 4648 Logs explicit use of credentials; indicates lateral move origin Logon Type 9 (NewCredentials) 4624 Indicates session initiated with explicit credentials Delegation abuse 4624 + abnormal access patterns Delegated service accounts connecting to new/unexpected systems Coercion/NTLM Relay 4624 Mismatch between Workstation Name and Source Network Address Quick Hunt Queries (SIEM Examples) Kerberoasting SecurityEvent | where EventID == 4769 | where TicketEncryptionType in ("0x17", "0x18") | project TimeGenerated, TargetUserName, ServiceName, TicketEncryptionType Overpass-the-Hash SecurityEvent | where EventID == 4768 | where SessionEncryptionType in ("0x17", "0x18") or TicketEncryptionType in ("0x17", "0x18") | project TimeGenerated, TargetUserName, IpAddress, Computer NTLMv2 Usage SecurityEvent | where EventID == 4624 and AuthenticationPackageName == "NTLM" | project TimeGenerated, TargetUserName, IpAddress, WorkstationName ------------------------------------------------------------------------------------------------------------- Summary Attack Type Key Event IDs Indicator What It Means Kerberoasting 4769 RC4-HMAC-MD5 (0x17) Weak encryption used for service tickets Overpass-the-Hash 4768 RC4-HMAC-MD5 (0x17) TGT requested using NT hash Pass-the-Hash 4624, 4776 NTLMv2 logons Reuse of stolen NTLM hash Credential Switching 4648, 4624 (Type 9) Explicit credentials Lateral movement initiation NTLM Relay 4624 Hostname-IP mismatch Relayed authentication ------------------------------------------------------------------------------------------------------------- Bonus: Abuse of Administrative Credentials & Tools Once attackers compromise high-privileged accounts like Domain Admins or service accounts , they effectively inherit legitimate administrative rights  — becoming "unpaid administrators." They can now: Control much of the environment (domain, servers, endpoints). Use legitimate tools for remote management and execution such as: RDP , VNC , PowerShell , PsExec , WMIC , and Group Policy . Patch management and software deployment tools  to push malicious payloads. Detection & Defense Restrict and monitor accounts used for deployment . Use unique accounts  (not Domain Admins) for patching. Limit deployment windows  (detect off-hour use). Maintain decoy/test systems  to log and analyze deployment activities. Watch for unexpected GPO changes  or new deployment tasks. Lateral Movement via Vulnerability Exploitation When credentials aren’t available or remote access is blocked, attackers turn to exploiting vulnerabilities  to move laterally. Trends Vulnerability exploitation  is on the rise — both for initial access  and lateral movement . Zero-days  increasingly used by state-sponsored actors. Detection Methods Crash / Exploit Detection: Event logs showing crashes or memory corruption. Microsoft Exploit Guard / antivirus telemetry. Process Creation Monitoring (Event ID 4688): Detect abnormal parent-child process chains (e.g., IIS worker spawning cmd.exe). Watch for code injection , new handles , and unusual command shells . Application control / EDR logs . Threat intelligence  to track newly exploited vulnerabilities. Memory forensics  for hidden or injected processes. ------------------------------------------------------------------------------------------------------------- Wrapping up: Effective lateral movement detection hinges on visibility, context, and restraint of privilege. Attackers exploit legitimate pathways; defenders must therefore combine behavioral monitoring, account segregation, and timely patching to break the chain before impact. -------------------------------------------Dean----------------------------------------------------------

Hey — today we’re unpacking lateral movement. Think of it like this : an attacker already got a foothold in your network and now wants to move sideways to more valuable systems. In this article I’ll try tp show you the common ways they do that, what Windows logs to watch for, and practical detective steps you can take right now. ------------------------------------------------------------------------------------------------------------- Why this matters Once an attacker can move laterally, they can reach domain controllers, file servers, backup systems, or any asset you care about. Detecting lateral movement early can stop a breach from becoming a full-blown incident. Start point: the logon event that often tells the story — Event ID 4624 (Logon Type 3) When someone authenticates remotely to a Windows host (SMB, named pipes, remote service calls, PsExec, scheduled tasks, etc.) , Windows commonly records Event ID 4624  with Logon Type = 3  (Network). That single event is often the first hint something happened on the target system. What to watch for: A strange source computer or IP doing a network logon to a host that normally doesn’t see it. An account authenticating from an unexpected system (service accounts from a workstation, users from servers). Unusual time-of-day for an account or a burst of network logons from the same source. Quick detective mindset: Find 4624 / LogonType 3 on the target machine. Note the Account Name, Logon ID and Caller Computer / Source IP. Correlate with surrounding events: process creation, PowerShell logs, Sysmon network events, scheduled task events. Don’t assume a 4624 = malicious. Many normal operations use this type of logon. Context is everything. ------------------------------------------------------------------------------------------------------------- Common techniques that produce 4624 Type 3 (and what extra artifacts they leave) Here are typical ways attackers use network logons and what you can look for around them. Network share access (SMB, port 445) Look for Event IDs related to file share access (if auditing enabled). Attackers often mount shares to copy tools or exfiltrate files. Named pipes / RPC (port 135, 445) Correlate network logs showing RPC or SMB with suspicious services/processes. Remote scheduled tasks / Task Scheduler Scheduled task creation events, task run events, or suspicious schtasks command lines in process creation logs. Remote service execution (PsExec, sc.exe) Process creation for psexec.exe, sc.exe remote service installs, or any service creation events. Check for Service Control Manager logs. PowerShell remoting, WinRM (port 5985/5986) PowerShell logs, WinRM session events, or Event ID 4648 (explicit credentials) near a 4624. WMI remote execution (wmic /node) WMI operation events, suspicious wmic command lines in process creation logs. Analyze network connections and system activity — where to get signal Successful TCP/UDP connections by themselves are usually not logged — they’re too noisy — but these sources can give you the visibility you need: Sysmon (Event ID 3)  — if you run Sysmon and enable network connection logging, you get process-to-remote-host mapping (gold). Host-based firewall logs  — Windows Filtering Platform and firewall logs can show successful connections (if enabled). Security log: Event ID 5156  — Windows Filtering Platform allowed a connection. EDR/XDR  — many EDRs provide both process telemetry and network context; use process launch + network data together. How to use them together: Start from the 4624 Type 3 event. Look at Sysmon or firewall logs to see which remote port and process were involved. Check process creation logs, PowerShell logs, and the Security log around the same timestamp for suspicious activity (scripts, encoded commands, task creation). ------------------------------------------------------------------------------------------------------------- File shares — a favorite lateral movement highway Mounting and using network shares is one of the easiest ways to move laterally or stage data. Windows events for share auditing: 5140  — network share was accessed (gives share name, server path, source IP, account). This event is created when the session is established — not for every file access. 5145  — detailed file share auditing (records access to specific files/folders) — very informative but noisy. Use this only for very sensitive shares or short bursts of investigation. 5142–5144  — share created/modified/deleted. Important note about 5140: The Accesses  field will often say ReadData (or ListDirectory) even if later the user wrote or deleted files. 5140 records the initial access granted when the share session started. Practical steps: If you can, enable strategic share auditing on sensitive file servers (5140 + selective 5145). When you see 5140 for a suspicious source, follow the account’s Logon ID across the security log to find what else it touched. Look for sudden creation of new shares (5142) or the use of admin shares (like C$) from non-admin hosts. ------------------------------------------------------------------------------------------------------------- Detection tips you can use today Baseline normal: map which systems normally connect to your servers and from what accounts. Anything outside that baseline is suspicious. Flag 4624 Type 3  where the Caller Computer is not in your baseline or the account is unexpected for that host. Look for 4624 Type 3  followed quickly by process creation events launching admin tools (PsExec, wmiprvse making child processes, schtasks, sc.exe, net.exe). Monitor for Service creation , scheduled task creation , or new remote services started from non-admin systems. If you have Sysmon: monitor Image that opens network connections (Event 3) — e.g., cmd.exe, powershell.exe, wmic.exe, psexec.exe. On file servers: enable Object Access > Audit File Share  (ID 5140) for strategic monitoring; enable detailed file share  (ID 5145) only for critical folders. Common pitfalls — what to avoid when investigating Assuming every 4624 Type 3 is bad  — many business processes use network logons. Use context (account role, time, source host). Relying on a single log source  — attackers leave breadcrumbs in many places; correlate across logs. Enabling noisy auditing wide-open  — 5145 and verbose Sysmon network logging can generate mountains of data. Apply selectively or with filters. ------------------------------------------------------------------------------------------------------------- Named pipes — what they are and why attackers love them Think of a named pipe like a little memory-backed mailbox processes use to chat with each other . Pipes can be local (two processes on the same machine) or remote (a process on another machine reads/writes the pipe over SMB). Windows exposes remote pipes through the special IPC$ share — so when you see IPC$ traffic, named pipes might be involved. Why this matters to defenders: Attackers use named pipes to hide communications inside normal SMB traffic (TCP 445). Instead of opening a weird port, they piggyback on SMB — which often looks rote in network telemetry. Windows telemetry you can use Named pipes are noisy in normal operation, so context is key. Useful events and sources: Sysmon Event ID 17  — a named pipe was created by a process (gives you the process that created it). Sysmon Event ID 18  — a named pipe connection occurred (shows which pipe was accessed and when). Security / System logs  — IPC$ access will show up as a network share access (similar to file share events). How to use them together: Start with suspicious IPC$/SMB activity (or a 4624 network logon tied to a workstation). Look at Sysmon Event 18 around the same time to get the pipe name. Use Sysmon Event 17 to find which process created that pipe on the target host. Correlate with process creation, command lines, or network activity to decide whether it’s malicious. ------------------------------------------------------------------------------------------------------------- Scheduled tasks — silent persistence and remote execution Scheduled tasks are a favorite for attackers because they: Can be created remotely — which often generates a network logon on the target (so still shows up as that 4624 type 3 behavior we talked about). But Windows gives you great signals about tasks — if you enable the logging. Key logs to turn on: Task Scheduler / Operational  (Microsoft-Windows-TaskScheduler/Operational) — excellent for creation and execution entries. Events here persist longer and are easier to hunt through than Security log entries. Security log scheduled task events  (when object auditing is enabled) — these include: 4698  — scheduled task created 4699  — scheduled task deleted 4700 / 4701  — task enabled/disabled 4702  — task updated Task Scheduler operational events you’ll see: 106  — task created (shows registering user and task name) 200 / 201  — task executed / completed (these often contain the actual command path that ran) Why remote task creation is important: Tasks created remotely will usually be accompanied by a 4624 Type 3  logon on the host around the same timestamp. That pairing is a very useful signal to automate hunting on. ------------------------------------------------------------------------------------------------------------- When analysts think about lateral movement, scheduled tasks and malicious services often go hand-in-hand. Attackers use them to execute commands remotely , maintain persistence , and bypass login-based detection . Luckily, Windows leaves behind rich forensic artifacts — if you know where to look. Task Scheduler v1.2 — Modern Task Artifacts (Vista and Later) Starting with Windows Vista and Server 2008 , Microsoft introduced a new scheduled task format (v1.2) , the new tasks are XML-based , human-readable, and stored without any file extension. Where to Find Them Folder Description C:\Windows\System32\Tasks Standard location for 64-bit task files C:\Windows\SysWOW64\Tasks Rare — tasks created by 32-bit code (worth checking for anomalies) Each file’s name matches the task name , and its contents describe who created it, what it runs, and under which account. What Information You Get (from the XML) Inside each XML file, key elements reveal attacker actions and context: Tag Description Shows the date/time  and account  that registered the task Includes hostname and username  that created the task — crucial for spotting remote scheduling Defines when and how often the task runs (e.g., once, hourly, at logon) Contains the command path or script  executed Identifies the user account used to run the command Why This Matters in Lateral Movement Remote scheduled tasks are a common tactic . While event logs (like 4698 or 106) don’t clearly state whether a task was scheduled remotely, the Author tag  in the XML file does. If you see a hostname or domain account in , it’s almost certainly remote. Even if the attacker deletes the task, the XML file may remain or be recovered forensically  from disk or Volume Shadow Copies. Better yet — if the same malicious task name appears across several systems, it can map attacker propagation  across your network. Task Scheduler v1.0 — Legacy Artifacts (XP / 2003) Older systems use .job files stored under C:\Windows\Tasks.These binary-format jobs contain: Registration date/time User account Command path Execution timestamp They’re created by at.exe  and schtasks.exe  on XP/2003 systems. Even on newer OS .job files may appear for backward compatibility , giving you a second artifact to pivot from if attackers forget to delete both versions. ------------------------------------------------------------------------------------------------------------- Windows Services — Another Common Lateral Movement Vector Just like scheduled tasks, services  are used for persistence and remote execution — often seen when attackers deploy PsExec , SCShell , or custom service installers. Key System Log Event IDs (Service Control Manager) Event ID Description Why it matters 7034 Service crashed unexpectedly May reveal instability caused by injected malware 7035 Service sent a Start/Stop control Traces the start/stop command 7036 Service started or stopped Confirms the actual operation 7040 Service start type changed Detects persistence via Boot/Auto-start configuration 7045 New service installed (Windows 2008 R2+) Excellent signal for new service-based malware EID 7045  is particularly powerful — each new service installation generates one. Even transient services (like PsExec) produce 7045 entries, making them easy to track across hosts. Security Log — Event ID 4697 If “Audit Security System Extension”  is enabled, Event ID 4697  will appear in the Security log  for new service installations. While it may list SYSTEM as the account, it provides start type and correlates nicely with 7045 events. Pro tip: Use both 4697 (Security) and 7045 (System) to get the who + when + what  of any new service creation. ------------------------------------------------------------------------------------------------------------- Abusing Windows Services Services in Windows are like small background workers — they run quietly without user interaction, handling updates, drivers, or system tasks. But attackers love them because services can start code with high privileges  and even survive reboots . So when you see a “new service installed” event on a host you didn’t expect, your alarm bells should go off. What to Hunt For The two golden event IDs for service creation are: EID 4697 (Security log)  — “A service was installed in the system.” EID 7045 (System log)  — “A service was installed.” Before Windows 10, these were clean, high-signal events. If one popped up, something new was created — and you’d investigate. But then Microsoft introduced Per-User Services  in Windows 10.These are like lightweight user-specific instances that start when a user logs in — and unfortunately, they flood your logs with hundreds of “new” service events. So now your logs might look like: OneSyncSvc_52a78dec WpnUserService_4g4y BluetoothUserService_0a3c Looks legit, right? That’s the problem. Attackers can easily hide behind that chaos. For example, naming their malicious service something like: OneSyncSvc_52a78dec and blending right in. Smarter Filtering Don’t just filter out every service with an underscore — that’s dangerous. Instead: Filter by ServiceFileName , not by service name. Create an ignore list  for known legitimate binaries, like: C:\Windows\System32\svchost.exe -k ASUSSystemAnalysis Focus on EID 7045  (System log) instead of 4697 — it’s less noisy and usually doesn’t log those per-user services. Bottom line: If you see an unexpected service installed and the binary path points to Temp, AppData, or a random directory — that’s your sign. ------------------------------------------------------------------------------------------------------------- Remote Registry — The Sneaky Lateral Move Here’s something you’ll see often in real intrusions: attackers using the reg command  to make changes on another system’s  registry. Yup, the same reg add command you use locally can modify a remote machine if they have credentials and the Remote Registry service  running. 🔍 What You’ll See in Logs When this command runs, several artifacts light up: Event Log Event ID Description Security 4624 (Logon Type 3) Network logon from the attacker system Security 5140 IPC$ access (named pipe communication) System 7036 Remote Registry service start/stop If you’re auditing file shares, 5140 is pure gold — it confirms the named pipe connection (like \PIPE\winreg).If not, 4624 + 7036 can still tell the story. Registry Timestamp The modified registry key also updates its LastWrite timestamp . Example workflow: Spot suspicious remote logons (4624 Type 3). Check the timeframe in Registry Explorer. Sort by Last Write Time  to see what changed. If a new value appears under Run with a weird executable path — that’s your persistence clue. Analyst Tip Attackers often choose “subtle misspellings”  for filenames . So when you see something like: C:\Windows\System32\svchos1.exe Ask yourself — since when did Windows start naming files like that? ------------------------------------------------------------------------------------------------------------- DCOM Abuse — Old Tech, New Tricks This is one of those “been around forever but still dangerous” technologies. DCOM lets one system create or control a code component on another system over the network. Attackers use this for lateral movement — without dropping any new binaries. What to Look For When a COM object is instantiated remotely: The DcomLauncher  service spins up the associated process (e.g., mmc.exe). That process becomes a child of the svchost.exe  process that hosts the DcomLaunch service. So if you’re threat hunting: Look for processes like mmc.exe, excel.exe, or outlook.exe being launched by svchost.exe -k DcomLaunch . Check the logs for EID 4624 (Type 3)  — remote network logons. Correlate with EID 4672  — “Special privileges assigned” (this usually means admin rights). Then review process creation logs (Sysmon Event 1 or Security EID 4688) for binaries spawned right after. Common Noise (and How to Filter It) Two DCOM-related system events are worth noting: EID 10036  — DCOM error (can reveal attacker testing or failure). EID 10016  — frequent in normal operations; only useful if you filter by user, SID, or time . Pro tip: most malware devs test DCOM methods by trial and error. Those errors generate 10036s — if you see a cluster of them before a suspicious logon, you’ve probably caught them mid-experiment. ------------------------------------------------------------------------------------------------------------- 🧭 Quick Recap — Detection Summary Technique Key Events Hunt Focus Service Abuse 4697, 7045 Unexpected service install, odd binary path Remote Registry 4624, 5140, 7036 Remote logon + Run key changes DCOM Abuse 4624, 4672, 4688, 10036 DcomLauncher spawning child process, privileged remote logon ------------------------------------------------------------------------------------------------------------- Why This Matters These techniques aren’t theoretical — they’re used daily by ransomware operators, red teams, and even internal IT tools. But the difference between legit  and malicious  is all about context . If you tune your detections around these three — services, registry, and DCOM — you’ll catch the kind of lateral movement that slips past surface-level monitoring. ----------------------------------------------------Dean------------------------------------------------ We will continue this in next article

If you’ve worked in cybersecurity for a while, you know one truth: PowerShell is both a friend and a foe . Administrators love it because it makes automation simple. Attackers love it because it makes exploitation simple. From credential theft to data exfiltration, lateral movement, and even memory-only malware — PowerShell can do it all. So, the real question is not whether  PowerShell is being used, but how  and by whom . That’s where PowerShell logging  comes into play — your digital microscope into what’s really happening behind that blue window. ---------------------------------------------------------------------------------------------------------- The Problem — Power Without Visibility Older versions of PowerShell were like stealth bombers — powerful and almost invisible. Before version 5, investigators had very little to work with; attackers could run entire malicious frameworks without leaving much of a trace. Then came PowerShell v5 , and finally, we got some serious logging features. Now we can see what’s being executed, which modules are being loaded, and even the contents of the script itself. But here’s the catch: most of this logging is not enabled by default , and attackers know it. That’s why it’s your job to understand it, enable it, and use it wisely. The Key Event IDs You Must Know Think of these as your “eyes and ears” inside PowerShell: Event ID Log Type What It Shows Why It Matters 4103 Module Logging Captures module and pipeline output Great for spotting command sequences and variables 4104 Script Block Logging Captures the full script content Lets you see exactly what was executed (with deobfuscation!) 400 & 800 Legacy PowerShell Logs Session start and stop events Still useful for older systems or downgrade attacks WinRM/Operational Remoting Logs Tracks inbound/outbound PS remoting Crucial for identifying remote PowerShell abuse Logs to remember: Microsoft-Windows-PowerShell/Operational.evtx → for PowerShell v5 Microsoft-Windows-PowerShellCore/Operational.evtx → for PowerShell Core (v6, v7) ---------------------------------------------------------------------------------------------------------- The Power of Script Block Logging (EID 4104) Event ID 4104  is where the magic happens. It records the entire script block  that was executed — whether typed in manually, run from a file, or even built dynamically in memory. What’s even better? Windows automatically flags potentially malicious script blocks as “Warning” events  under EID 4104 — even if script block logging isn’t fully enabled. That’s right — Microsoft built in a safety net. If a suspicious command like Invoke-Expression , DownloadString , or FromBase64String  runs, it gets logged automatically. So, even in unprepared environments, you might still get lucky. ---------------------------------------------------------------------------------------------------------- Why Attackers Still Get Away — The Downgrade Trick Attackers know PowerShell v5+ logs everything, so they often downgrade  their sessions to PowerShell v2  — which has no useful logging at all. You can spot this behavior in the legacy logs: Look in Windows PowerShell.evtx  for Event ID 400  with EngineVersion=2.0  or HostVersion=2.0 Also, watch for command-line indicators like: powershell -Version 2 Best defense? Disable or uninstall PowerShell v2 entirely. It’s outdated, insecure, and only helps attackers stay invisible. ---------------------------------------------------------------------------------------------------------- Decoding the Attacker’s Syntax Attackers rarely use PowerShell the normal way. They love stealthy parameters  that hide windows, bypass policies, and run scripts directly from memory. Common flags and their purpose: Parameter What It Does Why It’s Dangerous -WindowStyle hidden Hides PowerShell window Runs silently in background -NoProfile Skips user profile scripts Avoids detection via profile hooks -NonInteractive Disables prompts Prevents blocking -ExecutionPolicy Bypass Disables script execution restrictions Runs unsigned or malicious scripts -EncodedCommand Runs Base64-encoded script Obfuscates real command Invoke-Expression (IEX) Executes arbitrary code Common in download cradles ---------------------------------------------------------------------------------------------------------- Quick Wins for Analysts When triaging PowerShell activity, start with these “low-hanging fruit” checks: Search for suspicious keywords :download, Invoke-Expression, FromBase64String, WebClient, rundll32, Start-BitsTransfer, Invoke-WmiMethod Filter by Event ID : 4103 → See what modules and variables were used 4104 → See the full script, including deobfuscated code Look for “Warning” in 4104  — these are Microsoft’s auto-flagged malicious patterns. Check for Remoting (WinRM) : Event ID 6  — Destination host, IP, and logged-on user Event ID 91  — Session creation Event ID 168  — Authenticating user Remember — even legitimate scripts can look suspicious. Don’t just hunt for what  was executed — understand why  it was executed. ---------------------------------------------------------------------------------------------------------- PowerShell Core (v6 & v7) — The Next Chapter PowerShell Core is cross-platform now (Windows, Linux, macOS) — built on .NET Core. It doesn’t replace PowerShell v5, it coexists  with it. That means: Separate installation Separate Group Policies Separate logs If both versions exist on a system, you must enable logging on both . Attackers already know this — they may run scripts through PowerShell 7 to bypass your v5 monitoring. ---------------------------------------------------------------------------------------------------------- Practical Tip: Centralize, Don’t Silo The biggest mistake I see? Logs stay on endpoints until it’s too late. Forward PowerShell logs , Security logs (4688) , and Defender logs (1116–1119)  to a central SIEM or log collector. Once an attacker wipes or disables logging locally, your central copy will be the only evidence left. ---------------------------------------------------------------------------------------------------------- The Art of Obfuscation Attackers now rely heavily on obfuscation  — the practice of making a script unreadable to humans and confusing to machines. If you’ve ever seen something like ${#/~) or $a+$b+$c forming into a download cradle, that’s obfuscation at work. One of the most famous tools behind this is Invoke-Obfuscation , created by Daniel Bohannon. It showed the world just how easily PowerShell scripts could be twisted into unrecognizable forms while still running perfectly. Since then, threat actors and cybercrime groups have taken this concept to a new level, turning PowerShell into a weapon that can blend right into legitimate system activity. The scary part? A heavily obfuscated script can look like complete gibberish but still download malware or run a tool like Mimikatz in the background. The good news is that defenders have caught up. Windows 10 introduced AMSI (Antimalware Scanning Interface) , which allows security tools to inspect scripts as they’re executed  — even if they’re obfuscated. This means we can now catch malicious activity closer to the source. ---------------------------------------------------------------------------------------------------------- Understanding PowerShell Logging PowerShell isn’t just powerful for attackers — it’s also a goldmine for forensic analysts. The tool leaves behind several kinds of logs, and each tells a different part of the story. PowerShell Transcript Logs Transcript logs are like a screen recorder for the PowerShell terminal. They capture exactly what was typed  and what the system replied with . That includes both the commands (inputs) and their results (outputs). These logs are incredibly useful because they give you the complete picture  — especially in scenarios where an attacker runs tools like Mimikatz  to dump credentials. Script Block Logging might tell you what script was executed , but Transcript Logging shows what actually happened , including whether the attack succeeded. Transcript logs are saved as text files, usually under: C:\Users\\Documents\ But storing logs in user folders is risky — attackers can easily delete or modify them. That’s why redirect them to a write-only network share  or a secure folder with limited permissions. You can enable transcription via Group Policy  under: Computer Configuration >Administrative Templates >Windows Components > Windows PowerShell >Turn on PowerShell Transcription It’s lightweight, easy to enable, and provides incredible visibility with minimal storage cost. Script Block Logging Script Block Logging focuses on the code itself  — the PowerShell commands and functions that get executed, even if they’re hidden or dynamically generated. In combination with transcript logs, Script Block Logging helps you catch both the “what” and the “how” of PowerShell activity. PSReadLine History Starting with PowerShell v5, Microsoft introduced something even simpler — a local history file called ConsoleHost_history.txt. If you’ve used Linux before, this is similar to .bash_history. It records the last 4,096 commands typed into the PowerShell console (but not the output). The file is stored here: %UserProfile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ This is often the first artifact investigators check when trying to reconstruct what an attacker was doing manually. However, there are two caveats: Attackers can easily delete or modify it. It only records interactive console sessions, not background or remote executions. Even so, it’s incredibly handy — especially because it’s enabled by default. ---------------------------------------------------------------------------------------------------------- Why This Matters for Defenders Every PowerShell log type provides a different piece of the puzzle: Log Type Captures Typical Use Case Script Block Logging Code that was executed Detect obfuscated or malicious scripts Transcript Logging Commands + Output Reconstruct what happened in a session PSReadLine History Last 4,096 typed commands Identify manual actions or testing When combined, they can help analysts piece together how an attacker moved through a system, what tools they executed, and what data they may have accessed. ---------------------------------------------------------------------------------------------------------- Wrapping Up PowerShell is not the enemy — blindness is and PowerShell logging isn’t just a feature — it’s a window into the attacker’s mind/ When properly logged, PowerShell becomes one of your most valuable forensic resources. You can see who ran what, when they ran it, and what exactly executed in memory. ----------------------------------------------Dean---------------------------------------------------

If you’ve worked in cybersecurity or digital forensics for even a short while, you’ve probably realized that Windows event logs are like the system’s memory  — they remember almost everything that happens. From user logins and process creations to application crashes and errors, these logs quietly record the life story of a system. But what happens when someone — say, an attacker — tries to erase those memories ? Or when malware crashes in the middle of doing something shady and leaves traces behind?That’s where event log analysis becomes one of the most powerful skills in our toolkit. ------------------------------------------------------------------------------------------------------------- Event Log Clearing — When Someone Tries to Erase Their Footprints When investigating an intrusion, one of the first things I check for is log clearing activity . Why?Because whenever someone tries to cover their tracks, they often attempt to clear the event logs — especially the Security  log. How You Detect It Event ID 1102  — Appears in the Security  log when it’s cleared. Event ID 104  — Appears in the System  log when any  other log (like Application or Setup) is cleared. So even if the attacker wipes out the previous entries, these two events show that someone did it  — and often, who did it . Who Can Clear Logs? Only users with Administrator or SYSTEM privileges  can clear event logs. That includes: Local Administrators Domain Administrators The Local SYSTEM account If your logs show one of these users clearing logs outside of your normal maintenance schedule — especially during an incident — it’s a red flag . Why It Matters Attackers clear logs to hide privilege escalation, lateral movement, or malware execution traces. It’s a common tactic in ransomware attacks , where adversaries want to erase evidence before encrypting systems. And remember, you can’t partially clear logs in Windows  — it’s all or nothing. However, advanced attackers have found ways around this. ------------------------------------------------------------------------------------------------------------- Modern Log Manipulation Tricks (and Why You Should Care) Old-school tools like WinZapper  tried to delete individual events but usually ended up corrupting the logs. Modern attackers are more sophisticated. For instance: DanderSpritz (from the Shadow Brokers leak)  includes a module called eventlogedit  that can hide  specific events by altering log headers. ( https://danderspritz.com/ ) Invoke-PhantOm , a PowerShell-based tool, kills all threads of the Event Log Service. It looks like the service is still running, but nothing is being logged — a classic stealth move. ( https://github.com/olafhartong/Invoke-Phant0m ) Even more advanced attackers might: Suspend the Event Log Service, modify logs, then resume it. Directly manipulate logs in memory  (RAM) instead of on disk. Or flood the logs with noise  — harmless events that bury the real ones. All these attacks require administrative privileges, but the takeaway is simple: Never assume logs are complete or untouched. Always analyze them critically. How to Defend Against Log Clearing Attacks Set up alerts  for Event IDs 1102  and 104  in your SIEM or monitoring solution. If these occur outside known maintenance windows, investigate immediately. Forward logs  to a centralized log server  or cloud SIEM. Even if local logs are cleared, your remote copies remain safe. Baseline your environment. Know which admins perform legitimate log maintenance. Any deviation is worth a look. Correlate gaps. If no logs are forwarded for hours or days, that system deserves attention — it might be under manipulation. ------------------------------------------------------------------------------------------------------------- Evidence of Malware Execution — When the Bad Stuff Crashes Let’s flip to the other side of the story. Even when attackers don’t clear logs, their malware often leaves evidence behind. In fact, many pieces of malware crash  — and those crashes are pure gold for forensic analysts. Where to Look Most of the time, you’ll find useful traces in: System Event Logs  — check for Critical , Warning , and Error  events. Application Event Logs  — especially: Event ID 1000  → Application error Event ID 1001  → Windows Error Reporting (WER) Event ID 1002  → Application hang Even though the Security log can track process execution (if process auditing is enabled), many organizations keep that feature off due to log volume. That’s why System  and Application  logs often give you the first real hints of malware activity. ------------------------------------------------------------------------------------------------------------- Windows Error Reporting (WER): The Hidden Gem Windows Error Reporting (WER) doesn’t just pop up that annoying “ This program has stopped working” message — it actually creates detailed reports when programs crash. These reports are stored as simple text files, often named Report.wer . You’ll find them in: C:\ProgramData\Microsoft\Windows\WER %UserProfile%\AppData\Local\Microsoft\Windows\WER And here’s what makes them valuable: Timestamp of execution Full executable path SHA1 hash of the file Loaded DLLs or modules Sometimes, analyzing a WER file can even reveal malware helper files , injection modules , or failed payloads . ------------------------------------------------------------------------------------------------------------- Microsoft Defender logs — your first alarm bell Even the slickest adversary sometimes trips an anti-malware rule. Defender is not perfect, but it’s a very useful source of early indicators. Treat Defender alerts as starting points, not the whole story. What to check Primary log: Microsoft-Windows-Windows Defender/Operational.evtx  — look here first. Important event IDs (quick list): 1116  — Malware detected 1117  — Malware action taken (quarantine, remove, etc.) 1118  — Malware action failed 1119  — Malware action critical failure Extra sources Defender writes MPLog-*.log  (Diagnostics): C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-YYYYMMDD-HHMMSS Contains process lists, possible code injection flags (“tainted”), file hashes, paths Defender scanned, and SDN queries. DetectionHistory  (user-facing record): C:\ProgramData\Microsoft\Windows Defender\Scans\HistoryService\DetectionHistory Shows what the user saw and what action was taken. Quarantine : C:\ProgramData\Microsoft\Windows Defender\Quarantine Holds quarantined files (usually stored in vendor format). Tools like maldump  can extract original file contents. How to use these logs Start with event IDs 1116–1119 to find detections and timestamps. Use MPLogs to find process context, hashes, and “tainted” notes — sometimes MPLogs include the SHA1/SHA2 which helps pivoting. If you find a quarantined item, extract it—hash it, submit to VT/intel, and search your environment for other instances. Quick hunting keywords for MPLog detection, tainted, SDN Query, sha1, sha2, file paths like \Temp\ or AppData\. Tip: Defender telemetry often outlives other logs on a host (it can go back months). Don’t skip it during incident triage. ------------------------------------------------------------------------------------------------------------- Process tracking & command-line capture — make attackers visible If you can capture full command lines for process creation, you go from blind to powerful. Many attacks are just clever command lines; 4688 events tell the story when enabled. Key Events 4688  — New process created (includes executable path, and — if enabled — full command line) 4689  — Process exited Why this matters Attackers rely on command shells, PowerShell, WMIC, and weird command arguments. Full command lines let you see attacker tooling, scripts, and flags — all of which are high-value IOCs. How to enable Group Policy path: Computer Configuration → Policies → Administrative Templates → System → Audit Process Creation Enable and turn on Include command line in process creation events  (works on Windows 7+ backported). If you have EDR, enable process command-line capture there—it’s usually cheaper on storage and easier to query. Practical hunts Find suspicious parent → child chains: powershell.exe launching rundll32, or wmic creating cscript from a weird folder. Filter for cmd.exe /c or powershell -EncodedCommand or long -Command lines. Those are often malicious. Tip: If your environment is noisy, enable detailed command lines on servers (domain controllers, jump boxes) first — highest ROI. ------------------------------------------------------------------------------------------------------------- WMI Activity logs — catching stealthy persistence WMI event consumers (filters + consumers + bindings) are a neat persistence trick for attackers. Lucky for us, modern Windows logs a lot of this activity. Where to look Microsoft-Windows-WMI-Activity/Operational.evtx  (WMI-Activity/Operational) Event IDs of interest: 5857–5861 , with 5861  being the most useful. 5861  — A permanent event consumer was created (this often means a lasting persistence mechanism). 5858  — Query errors (useful to see which host/user caused WMI query failures). 5857  — Provider DLL loads (can show dropped/proprietary WMI DLLs). Why 5861 matters It records permanent consumers added to WMI. If an attacker installs a consumer that runs a VBScript or PowerShell on a trigger, 5861 will often reveal the script path or the exact command that will run. What to hunt for New consumers executing scripts from user profiles or Temp folders. Filters that trigger frequently (every 20 seconds) — often used to create polling beacons. Provider DLLs that look unusual (not standard Microsoft DLLs). The command-line angle again WMI attacks are much easier to find when you have command-line logs. Without them you may only see wmic process call create which is fine, but not as clear as the full command. Tip: If you can only enable one capability, enable process command-line collection. It makes WMI attacks transparent. ------------------------------------------------------------------------------------------------------------- Putting it together — how a triage should flow When you spin up an investigation, do this in order: Defender first  — check 1116–1119 and MPLogs for immediate detections and SHA1s. Quarantine may contain the payload. Process timeline  — pull 4688/4689 events for the host/time window. Look for parent→child anomalies and suspicious command-lines. WMI-Activity  — check for 5861 (new consumers) and 5858/5857 for query errors or odd provider loads. Correlate  — match Defender timestamps to process creation and WMI consumer creation. That gives you a timeline: detection → execution → persistence. Extract artifacts  — recover quarantined files, collect MPLogs, and capture relevant files (scripts, DLLs, Report.wer if present). Remember: defenders win by stitching together multiple weak signals into a strong story. ------------------------------------------------------------------------------------------------------------- Tools and small commands that help right away KAPE  — Use it to collect Defender logs, MPLogs, DetectionHistory, Quarantine, WER files, and relevant registry hives quickly during triage. EvtxECmd  — Great for parsing and mapping evtx entries into normalized CSVs for easy filtering. maldump  — Use to extract original files from Defender quarantine. (Vendor quarantine formats vary — tools help.) Timeline tools  — Load your parsed CSVs into Timeline Explorer or your SIEM for grouping and pivoting. Quick PowerShell tip to search MPLog for a hash or keyword: Get-ChildItem 'C:\ProgramData\Microsoft\Windows Defender\Support\*.log' -Recurse | Select-String -Pattern "< Enter IP File name >" -List ------------------------------------------------------------------------------------------------------------- Wrapping Up logs tell stories — even when someone tries to silence them. From attackers to malware tripping over its own code, there’s always a trace if you know where to look. In forensics, success isn’t about having perfect data. It’s about knowing how to read the clues that survive. ---------------------------------------------------Dean-----------------------------------------------------

When investigating intrusion attempts or suspicious login activity in Windows environments, one of the most overlooked sources of truth lies in the authentication failure logs  — specifically, Kerberos Event ID 4771  and NTLM Event ID 4776 . These tiny events, often lost in the noise of massive log volumes, can tell a deep story: Was someone trying to guess passwords? Was an attacker using a stolen hash? Or was it just a misconfigured system clock? Kerberos Pre-Authentication Failures (Event ID 4771) Kerberos is the default authentication protocol in modern Windows domains, but when things go wrong, it leaves behind a clear trail. Whenever Kerberos “pre-authentication” fails, Windows logs Event ID 4771  on the authentication server   — usually the domain controller. This event contains the date, time, username, client IP address, and most importantly, an error code  that tells you why authentication failed. There are more than 40 possible Kerberos failure codes, but a few valuable for incident responders. Let’s translate the most common ones into plain language: Error Code Meaning What It Often Means in Real Life 0x6 Invalid or non-existent account Someone tried logging in with an account that doesn’t exist — could be enumeration or stale credentials 0x7 Requested server not found Usually a replication issue, but sometimes points to attempts to reach decommissioned hosts 0xC Policy restriction Account tried to log in outside allowed hours or from a restricted device 0x12 Account locked, disabled, or expired May indicate brute-force or password-guessing attacks 0x17 Password expired User simply needs a reset — or an attacker tried with an old credential dump 0x18 Invalid password The classic — could be typos or password spraying 0x25 Clock skew too large Indicates a mismatch in system time; Kerberos rejects tickets when clocks differ too much If you see a cluster of 0x18 errors  across multiple accounts from a single source IP, it’s not a coincidence — it’s likely someone is testing passwords or performing a brute-force  or password spray  attack. NTLM Authentication Failures (Event ID 4776) Although Kerberos is dominant, NTLM  hasn’t disappeared — it still pops up in remote logins, local account authentications, and pass-the-hash attacks . When NTLM authentication fails, you’ll find Event ID 4776  logged on the system where the authentication was attempted. This event is a goldmine because it records both the username  and the reason  why authentication was denied, using NTSTATUS-style error codes . Here are some of the most useful ones for IR: Error Code Meaning IR Insight 0xC0000064 Account doesn’t exist Enumeration attempt — attacker probing usernames 0xC000006A Wrong password, username valid Password guessing — if repeated from one host, suspect brute-force 0xC000006F Account not allowed to log in now Account policy restriction triggered 0xC0000070 Not allowed from this computer Attempt to access restricted host — possible lateral movement 0xC0000071 Password expired Legit user or old credential reuse 0xC0000072 Account disabled Attackers sometimes test disabled accounts from old dumps 0xC0000193 Account expired Expired service or user account reused 0xC0000234 Account locked Brute-force or repeated login attempts triggered lockout policy Pro Tip:  The same error codes also appear in Event ID 4625 (Failed Logon) . So cross-referencing 4625 with 4776 helps you see where  the login happened and why  it failed. A pattern of multiple 0xC000006A and 0xC0000234 events coming from a single workstation is a clear red flag — it usually means someone (or something) is trying stolen passwords or hashes in bulk. Tracking Account & Group Enumeration (Event IDs 4798 & 4799) Once attackers gain a foothold, they rarely move blind. The next step is reconnaissance  — mapping out what accounts and groups exist, and more importantly, who the Domain Admins are . Windows 10 and Server 2016 introduced new logging capabilities to make this easier to detect: Event ID 4798:  A user’s local group membership  was enumerated. Event ID 4799:  A security-enabled local group membership  was enumerated. Why These Events Matter for Defenders Enumeration happens early  in the attack lifecycle. That means if you spot 4798 or 4799 events tied to suspicious processes, you’ve caught the attacker before  they’ve escalated privileges or exfiltrated data. --------------------------------------------------------------------------------------------------------- When You Log In with a Local Account (NTLMv2 in Action) So imagine this — you’re on your workstation and try to access a shared folder on a remote server using a local account  (not a domain one). Maybe you run: net use S: \\198.30.0.0\Share Boom — that’s a remote access attempt using NTLMv2. Here’s what happens behind the scenes: The client  says to the server: “Hey, I want to log in with this username.” The server  replies: “Cool, prove it. Here’s a random challenge.” The client  encrypts that challenge using the hash of your password and sends it back — this is the NTLM Response . At this point, the server  checks if that encrypted response matches what it expects. If it does — you’re in. Now, from a forensic point of view — here’s what we care about 👇 Event ID Location Meaning 4776 On the server NTLM authentication attempt 4624 On the server Authorization success — user logged in (Type 3 or 10) Type 3 = network login, Type 10 = RDP So if you’re investigating a lateral movement, and you see 4 624 (Type 3)  on a file server using a local account, that’s a huge red flag — someone might be using local creds to hop around. 2. When You Log In with a Domain Account (NTLMv2) Now, let’s change the scene — you’re using a domain account  to connect to that same file share. Here’s where the Domain Controller (DC)  jumps in — because that’s where your account actually lives. The client still sends an authentication request to the server . The server says, “Wait, I don’t store your password hash — let me ask the DC.” The server  forwards that challenge/response to the domain controller . The DC  checks if your response is correct (using the NT hash in the NTDS.dit ). The DC  says “All good,” and the server  logs you in. From a log perspective: Event ID Where it appears What it means 4776 Domain Controller Authentication check (NTLMv2 validation) 4624 (Type 3) Server Authorization success — you got in via SMB 4624 (Type 10) Server Authorization success — you got in via RDP Tip: If you ever see net use \IPaddress\share  — that’s likely NTLMv2 , not Kerberos. Kerberos needs proper Service Principal Names (SPNs) , and those don’t work well with raw IPs unless someone configured it manually (which 99% of orgs don’t). 3. Kerberos — The Smart Guy in the Room Kerberos is the default in modern domains, and it’s way more efficient (and secure) than NTLM. But it’s also a bit more talkative in logs. Let’s picture when someone logs in locally with a domain account. Step 1: The Ticket-Granting Ticket (TGT) — “Let me in the club!” The client  asks the Domain Controller (DC)  for a TGT . The DC logs: 4768 — AS Request / Reply (If it fails, you might see 4771 — Pre-authentication failed) Step 2: The Service Ticket — “Now let me access this service.” Once you have your TGT, the client says to the DC: “Hey, I want to access this specific machine/service.” The DC responds with a TGS (Ticket Granting Service) Ticket  — and logs: 4769 — TGS Request / Reply Now the client can use that service ticket to log in locally or remotely. Step 3: Local Authorization The client  logs: 4624 (Type 2)  → interactive logon (user at keyboard) The DC  also logs: 4624 (Type 3)  → network logon when the ticket is presented back to it. By the end of this process, you’ll see a flurry of 4768, 4769, and 4624 events  across both client and DC. Bonus tip: If you’re ever analyzing logs and see multiple 4769  tied to krbtgt or service accounts, it usually means the client is requesting tickets for various services — like LDAP, CIFS, or even group policy updates. 4. Kerberos in Remote Logons If the logon happens remotely (like accessing a file share or RDP server): The client requests a service ticket  from the DC — 4769  on the DC. The client presents that ticket to the server  — and the server logs 4624 (Type 3)  if it’s successful, or 4625  if it’s denied. So when investigating: 4769 on the DC  tells you who asked  for access. 4624 on the server  tells you who actually got in . That’s gold for tracking lateral movement. ------------------------------------------------------------------------------------------------------------- Putting It All Together Here’s how you can think of it: Scenario Who Logs What Key Events Local Account Logon Target system 4776, 4624 Domain Account (NTLMv2) DC (auth), Server (access) 4776 (DC), 4624 (Server) Domain Account (Kerberos) DC + Client + Server 4768, 4769, 4624 Think of it like this: Authentication  (Who are you?) → DC Authorization  (Can you come in?) → Server or Client ------------------------------------------------------------------------------------------------------------- 5. Why This Matters in Investigations During lateral movement or credential abuse: You’ll often see 4624 (Type 3)  events lighting up on multiple systems. Pair them with 4768/4769  from the DC to map out exactly how the attacker moved. Combine IPs, usernames, and timestamps to build your attack path timeline . And when the logs aren’t centralized — you’ll have to collect from multiple endpoints . Quick DFIR Tip If you’re working offline and can’t access a SIEM, start with: Get-WinEvent -LogName Security | ? {$_.Id -eq 4624 -or $_.Id -eq 4769 -or $_.Id -eq 4776} | Select TimeCreated, Id, Message And then pivot by username and IP address — you’ll quickly map authentication relationships. ------------------------------------------------------------------------------------------------------------- Final Thought Once you understand where each event lives — DC, server, or client — the logs start to tell a story. You can see who authenticated, how, from where, and what access they gained. The fun part? Attackers leave breadcrumbs  across all three — and now you know exactly where to look. -----------------------------------------------Dean---------------------------------------------- Third Part of this series: https://www.cyberengage.org/post/understanding-where-windows-authentication-logs-actually-live-from-ad-to-entra-id

I know, I know — Log Analysis  doesn’t sound like the most exciting topic these days . Everyone in cybersecurity has gone through it at some point, and if you’ve sat in an interview, you’ve probably been asked about it too. There are already tons of articles and videos on this topic out there. But here’s the thing — log analysis isn’t about knowing event IDs by heart . It’s about correlating different events together to tell a story . That’s the part most people miss. And that’s what I’m going to focus on today. ------------------------------------------------------------------------------------------------------------ Why This Topic Still Matters Even with so many amazing tools available now — like Hayabusa : https://www.cyberengage.org/post/hayabusa-a-powerful-log-analysis-tool-for-forensics-and-threat-hunting EvtxECmd : https://www.cyberengage.org/post/unleashing-the-power-of-evtxecmd-a-deep-dive-into-windows-event-log-analysis Chainsaw understanding how  to correlate logs is still essential. These tools automate the process, but they don’t think for you . They can highlight suspicious events, but they can’t explain why something happened , or how one event connects to another . That’s where your analysis skills come in. To help with this, I’ve created a personal Intrusion Detection Cheat Sheet  — it’s available under the Resume page on my website, under Quick Guides . It contains core correlations and scripts I’ve built for my own investigations — things that are hard to remember when you’re in the middle of an IR case. ------------------------------------------------------------------------------------------------------------ Tracking Account Usage: Logon Events One of the most common and powerful ways to start log analysis is by tracking account activity  — basically, who logged in, from where, and when. Relevant Event IDs 4624  → Successful Logon 4625  → Failed Logon 4634 / 4647  → Successful Logoff 4648  → Logon using explicit credentials (like RunAs ) 4672  → Special privileges assigned to a new logon These five are the bread and butter of account tracking. How to Read These Events Every log entry is more than just a timestamp. When you expand an event in the Event Viewer (or parse it with a tool), focus on the following fields: Timestamp:  When the event occurred. Computer:  The hostname — helps correlate across multiple systems. Account Name:  Who logged in or attempted to. Logon Type:   How  they logged in — locally, over the network, via RDP, etc. Event ID:  What kind of logon or logoff this was. Understanding Logon Types Here’s a quick reference to some of the most useful logon types: Logon Type Description 2 Interactive logon via console or KVM 3 Network logon (SMB, PowerShell remoting, etc.) 4 Batch logon (used by Scheduled Tasks) 5 Service logon (Windows service accounts) 7 Session reconnect (unlock, RDP reconnect, etc.) 8 Network logon sending credentials in cleartext 9 Logon using different credentials (RunAs /netonly) 10 Remote interactive logon (RDP) 11-13 Cached or reconnected logons This is where correlation starts to get interesting. If you see Logon Type 10  on a workstation, for example, that means Remote Desktop was used — which might be normal on a jump server, but very suspicious on a regular user laptop. If you see 4625 (failed logons)  with Type 3  repeatedly from different IPs — that’s often a password spray or brute-force attempt. Correlating Logons and Logoffs Let’s say you find this: A 4624 (successful logon)  event at 12:00 PM A 4647 (user-initiated logoff)  event at 12:00 AM the next day Using the Logon ID  (a unique value assigned to each session), you can tie these together and calculate how long the user was active. That’s useful in profiling behavior: Was this an abnormally long session? Was it active during non-business hours? Did any privileged actions happen in between (like a 4672  event)? That’s what log correlation really means — finding connections between time, behavior, and privilege. ------------------------------------------------------------------------------------------------------------ When Logs Don’t Tell the Whole Story It’s important to remember that not every access attempt creates a logon event. If a system is exploited via a backdoor or remote code execution vulnerability, you might not see a normal 4624  event. That’s why correlation must extend beyond Security.evtx — you need to look at: Sysmon events (especially Event ID 1, 3, and 7 ) Prefetch files and ShimCache USN Journal and Amcache PowerShell and WMI logs When combined, these help fill the gaps where the Event Viewer stays silent. ------------------------------------------------------------------------------------------------------------ Pro Tip: Don’t Memorize — Build Your Correlations You don’t have to remember every event ID.Instead, build a mental (or written)  correlation map like this: Scenario Event IDs to Link Description Brute-force attack 4625 + Source IP pattern Repeated failed logons from same IP Lateral movement 4624 + 4672 + Type 3/10 Successful logon with admin privileges Privilege escalation 4672 + 4688 Elevated rights + new process creation RunAs misuse 4648 + 4624 Explicit credential use detected RDP session 4624 (Type 10) + 4634 Remote login session tracking This is exactly what I’ve built in my Intrusion Detection Cheat Sheet , and I can tell you — it makes a huge difference during investigations. ------------------------------------------------------------------------------------------------------------ Understanding Built-In Accounts in Windows Logs When you’re digging through event logs, you’ll often stumble upon strange account names like SYSTEM, LOCAL SERVICE, NETWORK SERVICE, or even things like UMFD-0 and DWM-1. At first glance, these can look suspicious — especially if you’re new to Windows log analysis.But here’s the truth: not every “unknown” account is an attacker. Many of these are built-in service accounts  that Windows uses to run background processes and manage system functions — often before a real user even logs in. Common Built-In Accounts You’ll See Account Description Typical Logon Type Privilege Level SYSTEM The most powerful local account. Has unlimited privileges on the machine. 5 Highest (root-equivalent) LOCAL SERVICE Runs processes that don’t need network access. Uses null sessions for network calls. 5 Low NETWORK SERVICE Similar to LOCAL SERVICE, but can authenticate over the network. 5 Medium $ The computer account for a domain-joined machine. Used for machine-to-domain authentication. 3 System DWM / UMFD Internal Windows components (Desktop Window Manager and Font Driver Host). 2 Low ANONYMOUS LOGON Represents unauthenticated connections (e.g., null sessions, some network access). 3 None 💡 Tip:  Built-in accounts are noisy . Don’t panic if you see multiple 4624 (Logon) events with these accounts — they appear frequently as part of normal Windows operation. Why These Accounts Exist Each service or process in Windows must run under an identity — something that defines its permissions. When Windows boots, dozens of processes start before any user logs in , and these rely on internal accounts like SYSTEM or LOCAL SERVICE. For example: The SYSTEM  account might handle core OS-level operations. LOCAL SERVICE  might manage background maintenance tasks. NETWORK SERVICE  might handle updates or telemetry that require outbound connectivity. The Microsoft Trustworthy Computing Initiative  (post-Windows 2003) actually reduced the power of SYSTEM by introducing these limited accounts, following the principle of least privilege . Filtering Out the Noise When you’re hunting for intrusions, seeing dozens of system account logons can clutter your view. To focus on real user activity , it’s smart to filter out built-in accounts like these: SYSTEM LOCAL SERVICE NETWORK SERVICE DWM-* UMFD-* $ ANONYMOUS LOGON This will leave you with cleaner visibility on human actions — the kind attackers try to mimic. ------------------------------------------------------------------------------------------------------------ Tracking Privileged Account Activity (Event ID 4672) Now let’s talk about one of the most powerful log events  for defenders: Event ID 4672 — “Special privileges assigned to new logon.” Whenever a user logs in and is assigned admin-level privileges (like SeDebugPrivilege or SeTakeOwnershipPrivilege), Windows records Event ID 4672. This event appears immediately after a 4624 (Successful Logon)  event and indicates that the account logging in has administrative capabilities — either local admin, domain admin, or system-equivalent rights. Why 4672 Is a Goldmine Every attacker, at some stage, needs admin-level access  to move laterally, dump credentials, or persist. That means tracking Event ID 4672  can help you: Detect unexpected privilege elevation. Spot service accounts behaving unusually. Identify high-value targets for auditing. Here’s what a typical 4672 looks like: Field Example Meaning Account Name Dean The account that logged in Privileges Assigned SeDebugPrivilege, SeTakeOwnershipPrivilege Indicates admin-level capabilities Correlating Event 4624 (Logon) Shows when and how they logged in If you see a 4624 + 4672  pair on a system where admin logons are rare, your threat-hunting instincts should kick in immediately. Correlation Example Let’s say you see this sequence: 4624 — Successful logon (User: Dean) 4672 — Special privileges assigned 4688 — New process created (possibly with elevated rights) This combination can signal an attacker using stolen credentials or a scheduled task executing under admin privileges. To confirm, look at: Logon Type  (e.g., Type 10 for RDP or Type 3 for network) Source IP  (was it remote?) Timestamp proximity  (did 4672 appear right after 4624?) If yes — that’s a strong indicator of admin-level access. ------------------------------------------------------------------------------------------------------------ Event ID 4648 — Explicit Credential Use Another powerful event in correlation chains is 4648 , which records when a user explicitly provides credentials . This happens when someone: Uses Run As  to launch a program with another account. Connects via PsExec , Enter-PSSession , or net use /user: . Initiates RDP or SMB connections  that prompt for alternate credentials. In short: 4624 = Logon occurred4648 = Credentials explicitly entered 4648 in Action Here are two examples: Example 1 — RDP Connection Source:  dean.cyberengage.org Target:  Server10 Credential Used:  dean@cyberengage.org SPN:  TERMSRV/server10 This means the user on  used admin credentials to open an RDP session to Server10. Example 2 — SMB Share Mapping Command: net use S: \\server10\share /user:cyberengage.og\administrator Network Address:  192.168.0.0 Port:  445 (SMB) SPN:  CIFS/server10 Here, 4648 records that the user explicitly entered alternate credentials to access a network share. Why This Matters When combined, 4624 , 4672 , and 4648  tell a powerful story: 4624:  The account logged in. 4648:  They used a different credential (e.g., administrator). 4672:  That credential had admin-level privileges. This pattern — especially across multiple machines — often signals credential misuse , lateral movement , or privilege escalation . Defensive Takeaway You don’t need fancy tools to spot privilege abuse — just solid log correlation. Start with this simple approach: Search for Event ID 4672  across endpoints. Correlate each one with 4624  and 4648 . Flag logons from: Unusual hosts Non-working hours Service accounts acting interactively These insights often expose attacker behavior long before malware is detected . ------------------------------------------------------------------------------------------------------------ RDP (Remote Desktop Protocol) Why RDP Matters in IR Attackers love RDP : It’s one of the most abused remote access mechanisms. Sophos (2023):  90% of investigated intrusions involved RDP. RDP abuse examples: Lateral movement within internal networks. Persistence via hijacked sessions. Rogue outbound RDP (social engineering or misconfigurations). Credential theft or privilege escalation via RDP sessions. Core Windows Event IDs Event ID Description Notes 4624 Successful Logon Logon Type 3 (network), 7 (unlock/reconnect), 10 (RDP) 4647 Logoff User-initiated logoff 4778 Session Reconnected Captures hostname + IP of client 4779 Session Disconnected Captures client that disconnected 4801 Workstation Unlocked Often seen before Type 7 reconnects Key Forensic Insights 1. Event 4778 (Session Reconnected) Indicates a user reconnected  to an existing session. Contains both Client Name  and Client IP Address  (often the attacker’s system). Often paired with: 4624 (Type 7)  → Unlock / RDP reconnect 4801  → Workstation unlock Important: Not every RDP session logs 4778—only reconnects. 2. Event 4779 (Session Disconnected) Marks when a session was closed or disconnected. Use it with 4778 to “bookend” RDP session activity. 3. Event 4624 (Logon Type) Reference Logon Type Meaning 3 Network (NLA) — pre-authenticated connection 7 Unlock / Reconnect 10 Classic RDP Interactive Logon Many analysts mistakenly only track Logon Type 10 → this can miss modern NLA-based (Type 3) or reconnect-based (Type 7) RDP events. Supporting Logs (Auxiliary Sources) Log Source Event IDs Use RDPCoreTS 131 Outbound RDP connections TerminalServices-RDPClient 1024, 1102 Destination hostname & IP for outbound RDP Prefetch tscon.exe Evidence of RDP hijacking (session switching) Sometimes Mismatched Logon IDs — What It Means You may notice sometimes that the Logon ID  in Event ID 4778 doesn’t match the one in 4624.That’s normal. Here’s why: Event IDs 4778 and 4779 track session reconnect/disconnect  activity. These events inherit the Logon ID of the earliest still-active session  by that user. If there was a prior session (and it was never fully logged off), the reconnect event uses that old session ID — leading to a mismatch. Practical Takeaways for DFIR Analysts Correlate Events Together Combine 4778, 4779, 4624, and 4647 to reconstruct RDP timelines. Look Beyond Logon Type 10 Type 7 and Type 3 can hide RDP reconnects or NLA-based connections. Pay Attention to Client Name & IP These are often your best clues about attacker infrastructure. Check for Persistence via Unclosed Sessions Attackers can hijack old sessions left open by admins to avoid detection. Pivot to Auxiliary Logs Inspect RDPCoreTS  (Event 131) and RDPClient  logs (Events 1024/1102) for outbound connections. Check Prefetch  for tscon.exe (used in RDP hijacking). Additional RDP Logging and Account Logon Events Why This Matters Attackers abuse RDP (Remote Desktop Protocol)  both for initial access  and lateral movement . Unfortunately, traditional Security logs roll over quickly , so responders can lose critical evidence unless they correlate data across custom RDP logs  and authentication logs (Account Logon Events) . 1. Primary RDP Log Sources Target Log Key EIDs Relevant Data Captured Description Security 4624, 4778 Source IP / Hostname / Username Standard logon + RDP reconnects TerminalServices-RDPClient 1024, 1102, 1029 Destination Hostname / Destination IP / Hashed Username Logs outbound RDP connections (source-side) Remote Desktop Services-RDPCoreTS 98, 131 Successful connections / attempts / Source IP / Username Helps identify RDP sessions and connection attempts TerminalServices-RemoteConnectionManager 1149 Source IP / Username Tracks successful RDP authentications TerminalServices-LocalSessionManager 21, 22, 25, 41 Source IP / Username Tracks session creation, connection, and disconnection Tip:  Combine these logs for complete RDP session reconstruction. The Security log  gives general logon evidence, while the custom RDP logs  persist longer and provide IPs, hostnames, and session context that may be missing from Security. 2. Key Log: Microsoft-Windows-TerminalServices-RDPClient/Operational This is the most valuable log  for tracking lateral movement  because: It’s recorded on the source system  (unlike most Windows logs that log activity on the destination). It shows where the attacker moved from the compromised machine. Event IDs Event ID Meaning Example Use in IR 1024 Records the name  of each system accessed Identify lateral movement destination hostnames 1102 Records the IP address  of each system accessed Validate connections or pivot points 1029 Contains a Base64-encoded SHA256 hash of the username  used Useful for detecting reused or suspicious usernames Event ID 1029 – Username Hashing Details Hash = SHA256(username) (case-sensitive, domain ignored). Example: dean@cyberengage.org  → hash based only on administrator. Case matters: Admin ≠ ADMIN ≠ administrator. Helps detect unusual capitalization patterns (e.g., ADMINistrator) used by attackers to bypass detection. Pro Tip:  Always correlate 1029 events with Event ID 4648 (Explicit Credential Use)  in the Security log to see the account actually used for RDP. 3. Account Logon vs Logon Events Event Category Recorded On Purpose Logon Events System where authorization  happens (workstation/server being accessed) Local or remote login tracking Account Logon Events System where authentication  happens (local SAM or Domain Controller) Credential validation tracking Account Logon Events Protocol Event IDs Meaning NTLM 4776 Account authentication success/failure Kerberos 4768 Ticket Granting Ticket (TGT) requested 4769 Service Ticket requested 4771 Pre-authentication failed How They Work Local Accounts:  Authentication logged on the same workstation  (Local SAM). Domain Accounts:  Authentication logged on the Domain Controller  (Kerberos/NTLM handshake). A single logon  can generate: 4624 (Logon Event) on the workstation, and 4768/4769 (Account Logon Events) on the DC. If you see Account Logon events  on a workstation , it often signals a rogue local account  — a potential attacker-created persistence mechanism. We will continue more in next article! ------------------------------------------------------------------------------------------------------------ Closing Thoughts Log analysis might not sound exciting compared to hunting with EDR or sandboxing malware samples — but it’s still the foundation of incident response . The automation tools will help you find the “what,” but your understanding of correlation  helps you find the “why” and “how.” So the next time someone asks you about Event ID 4624 in an interview — don’t just define it. Explain how you’d correlate  it with other events to tell the story of an intrusion. That’s where the real skill lies. -------------------------------------------------Dean---------------------------------------------------- Second Part of this Series: https://www.cyberengage.org/post/tracking-kerberos-ntlm-authentication-failures-and-investigation

Okay, let’s get one thing straight — Windows logging is not centralized by default. Each system—your laptop, your DC, your file server—logs its own stuff. That means if you’re doing forensics or threat hunting, you’ve got to know exactly which system has what evidence . If you pull the wrong logs, you might completely miss the attacker’s authentication trail. ------------------------------------------------------------------------------------------------------------- 1. Clients, Domain Controllers, and Member Servers — Who Logs What? Think of these three as different witnesses  in your investigation. Each one saw a different part of the crime. System Type What It Logs Example Event IDs Client Systems Logon events when someone accesses the client, and Account Logon events if local accounts are used. 4624, 4625 (logon), 4776 (local account auth) Domain Controllers (DCs) Account Logon events for all domain accounts  (Kerberos & NTLM). Logon events for when they themselves are accessed. 4768, 4769, 4776, 4624 Member Servers Logon events for access to the server, and Account Logon events if local accounts exist. 4624, 4625, 4776 Now, here’s the simple rule  you should always remember: Authentication happens where the account lives. Authorization happens where the access happens. Let’s decode that in plain language 👇 Authentication = Account Logon Events These tell you who tried to prove their identity  (i.e., “is this password/ticket valid?”).So if it’s: A local account  → it’s stored on that machine → you’ll find 4776  on that system. A domain account  → stored on the Domain Controller → you’ll find 4768/4769/4776  on the DC. Authorization = Logon Events These tell you who actually got access  to the system. So: If someone connects to a file server  using SMB, you’ll see 4624 (Type 3)  on the file server. If someone RDPs into a system, it’s 4624 (Type 10) . If someone logs in locally (keyboard/console), it’s 4624 (Type 2) . Every system generates its own logon events  for whoever touches it. 2. Domain Controllers — The Authentication Powerhouse Every Domain Controller (DC) in the domain is an equal partner . So when a domain account authenticates, the event could appear on any DC  that handled the request. That’s why, during incident response, you often need logs from all DCs , not just one. DCs will be buzzing with: 4768  → Kerberos AS Request (TGT issued) 4769  → TGS Request (Service ticket) 4776  → NTLM authentication 4624 (Type 3)  → Network logon to the DC If you ever wonder “where did this user authenticate?”, start your hunt on the DCs. 3. Member Servers — Your Quiet Evidence Keepers Member servers behave just like clients. If someone accesses them (say, via SMB or RDP), the Logon events (4624/4625)  appear right there. If they have local accounts (which attackers love  creating as backdoors), then you’ll also see: 4776  — Local NTLM authentication 4720 / 4732  — Local account creation or group modification Attackers often create local “shadow” admin accounts, so these logs are pure gold during lateral movement investigations. 4. The Cloud Era — Welcome Entra ID (formerly Azure AD) Now things get interesting.Microsoft’s Modern Authentication  changed the game. We’re no longer bound to traditional AD — you can join your machines directly to Entra ID  (Azure AD). Here’s how it shifts things: What changes: Authentication  moves to the cloud (Entra ID). Logs  for that authentication now live in Entra ID’s portal , not in your local Security event logs. Passwordless login  (Windows Hello / Hello for Business) becomes standard — it uses certificates and key pairs , not NT hashes. What stays the same: Logon events (4624, 4625)  still happen on the local system being accessed. Network logon (Type 3)  → for SMB or remote shares RDP (Type 10)  → for Remote Desktop Local logon (Type 2, 7, or 11)  → for local or interactive access Even in a pure Entra ID world, your endpoints are still the final witnesses. 5. Passwordless Authentication (Windows Hello / Hello for Business) Instead of using passwords or timestamps, Windows Hello uses certificates and keys . But here’s the key takeaway: Even though the authentication method changes, the same event IDs are generated . So: 4768  → Still logged on the DC when a TGT is requested. 4624  → Still recorded on the system granting access. The difference? You’ll see extra certificate details in the log, showing which cert/key pair was used during authentication. 6. Hybrid Entra ID + Active Directory — The Real-World Mix This is where most companies are today — hybrid mode . On-prem AD for internal stuff. Entra ID for cloud apps like Office 365 , SharePoint , or Teams . Here’s how that works under the hood: Authentication may happen in the cloud , but your DCs still issue TGTs  for on-prem access. Service tickets (4769)  still exist. Logon events (4624)  still show up locally. So from an incident response perspective, the log locations don’t change much  — you just add one more layer (Entra ID logs in the cloud). 7. Watching for Account Management Activity Alright, authentication is one thing — but what about account creation or privilege escalation ? Here’s where attackers love to play. Action Event ID Description User account created 4720 New account made (local or domain) User account deleted 4726 Account removed Account enabled/disabled 4722 / 4725 Account activation changes Password reset 4724 Admin reset user password Added to global group 4728 Domain Admins, etc. Added to local group 4732 Local Administrators, etc. Added to universal group 4756 Forest-wide access group Account changed 4738 Username, password, or attribute updated If you ever see 4720 followed by 4732  close together — that’s a dead giveaway. It often means: An attacker created a new user and immediately added it to the Administrators group. Quick Recap for DFIR Analysts 4776 / 4768 / 4769  → Authentication (Account Logon events) 4624 / 4625  → Authorization (Logon events) 4720–4756  → Account and group management DCs = domain accounts , Clients/Servers = local accounts Entra ID  shifts authentication to the cloud but not logon visibility And most importantly — logs are decentralized . Unless you have log forwarding or a SIEM, you’ll need to collect from each endpoint manually. ------------------------------------------------------------------------------------------------------------- Final Word If you’re doing threat hunting or forensics, think of authentication events like breadcrumbs . Each one tells a small part of the story — but together, they paint the attacker’s entire movement. Once you know where each event lives , you’ll never look at “just another 4624” the same way again. ---------------------------------------------Dean--------------------------------------------------

If you’ve ever tried digging through Windows event logs, you already know the pain — thousands of entries, confusing structures, and XML data that can make your head spin. Now imagine doing that for dozens or hundreds of systems during an investigation. That’s where EvtxECmd , created by Eric Zimmerman , becomes a real lifesaver. At first glance, EvtxECmd looks like another command-line tool that converts .evtx files into CSV, XML, or JSON formats. But once you start using it, you realize it’s much more than that. It’s a smart, flexible event log parser that helps you extract the right information instead of drowning in all the noise. Why Windows Event Logs Are Tricky Windows event logs are incredibly detailed — sometimes too  detailed. Each event type (like a logon or a process creation) stores information differently. There’s no single consistent structure, which makes it difficult to normalize or compare data across systems. Let’s take Event ID 4624 (a successful logon) as an example. One event might store the username in a particular XML field, another event might bury it in a nested tag. Multiply that inconsistency across hundreds of event IDs, and you quickly see why filtering event logs manually is a nightmare. How EvtxECmd Solves This Problem EvtxECmd fixes this inconsistency by using something called Map files . Think of Map files as small “blueprints” that tell the tool exactly what to extract from each event type. These Maps are crowd-sourced , meaning the community contributes templates for different event types, and each map uses XPath filters  to pull out only the relevant details — usernames, IP addresses, domains, process names, etc. For example: For Event ID 4624, it might extract the TargetUserName  and TargetDomainName . For Event ID 4688, it might extract the command line , parent process , or executable path . Once extracted, EvtxECmd organizes all this information into clean columns in a CSV file. You can now easily filter, search, or group the data without wrestling with XML. It’s like turning chaos into a spreadsheet of clarity. Working Smarter with PayloadData Columns You’ll notice that the tool uses columns named PayloadData1–6 . These are general-purpose slots that can hold different kinds of data depending on the event type. Why not just have separate columns for everything? Because that would result in hundreds  of columns — way too messy. So instead, EvtxECmd lets every event type reuse these six slots for its most important details. That means in one row, PayloadData1 might be a username, and in another, it might be a process name. To know what each means, you can simply refer back to the event’s ID and the corresponding Map file. Once you understand this logic, analyzing large sets of logs becomes surprisingly straightforward. Bringing It All Together with Timeline Explorer Parsing logs is just half the battle — the real magic happens when you start analyzing .Eric Zimmerman’s Timeline Explorer  pairs perfectly with EvtxECmd output. You can open the CSV file in Timeline Explorer and use features like: Filtering by keyword or event ID Grouping by columns  (for example, EventID, Username, LogonType) Counting event occurrences Quick sorting and drilling down Here’s a simple example: If you group by EventID, UserName, and LogonType, you can instantly see how many times each user logged example via RDP (LogonType 10) . You might discover that a user who normally logs in locally suddenly had two RDP sessions from an unknown IP — a quick red flag for possible lateral movement. Scaling It for Real Investigations EvtxECmd isn’t limited to just one system. You can run it on: Live systems  to extract and filter logs on the fly Mounted disk images  or triage collections  during incident response Even older versions of logs through the Volume Shadow Service (VSS) It can also de-duplicate events  across multiple sources, which is super helpful when you’re merging logs from dozens of endpoints. This scalability is what makes it a go-to tool for forensic analysts and threat hunters. Whether you’re investigating a ransomware infection or tracking a suspicious user account, EvtxECmd helps you see patterns that would otherwise stay hidden. unning EvtxEcmd on live system to extract artifacts: COMMAND LINE:  -     EvtxECmd.exe -d C:\windows\system32\winevt\logs --csv C:\Users\user\desktop --csvf eventlogs.csv –vss Breaking Up: -d (directory)  (Path of (directory)logs where it present) --csv \Users\user\desktop (CSV Format where you want store) --csvf eventlogs.csv File name to save CSV formatted results   –vss  Process all Volume Shadow Copies that exist on drive Running EvtxEcmd on collected logs from system: COMMAND LINE:  -     EvtxECmd.exe -d C:\users\user\downloads\logs\ --csv C:\Users\user\desktop --csvf eventlogs.csv -d (Provide path where all logs present)               Running EvtxEcmd on Single log for example security.evtx: COMMAND LINE:  -     EvtxECmd.exe -f C:\users\user\download\security.evtx --csv C:\Users\user\desktop --csvf eventlogs.csv -f (For single evtx file) ------------------------------------------------------------------------------------------------------------- Final Thoughts EvtxECmd takes something notoriously messy — Windows event logs — and turns it into structured, searchable data. It bridges the gap between raw XML chaos and actionable insight. If you’re new to log analysis, this tool will help you focus on what matters: the story the events are trying to tell. And if you’re an experienced investigator, EvtxECmd’s flexibility and map-based approach can dramatically speed up your workflow. -------------------------------------------------------Dean-------------------------------------

Hey everyone Let’s talk about one of the most underrated but dangerous  parts of automation and DevOps: secrets management . You might not realize it, but every single system you build — whether it’s an app, CI/CD pipeline, or cloud deployment — has secrets . These are things like API tokens, SSH keys, database passwords, and service credentials that your automation tools, containers, and scripts need to function. ------------------------------------------------------------------------------------------------------------- Why Secrets Management Matters In modern DevOps and cloud environments, everything is automated — provisioning, configuration, deployment, and release pipelines. But automation often requires privileged access to services. That means your infrastructure and code are constantly touching credentials and tokens. So if secrets are hardcoded, exposed in version control, or shared in plain text… well, you’re basically leaving your passwords under the doormat. 🫣 ------------------------------------------------------------------------------------------------------------- How Not  to Keep Secrets Let’s start with what not to do  — because this is where many developers slip up. Keeping Secrets in Code A lot of people hardcode secrets right into their code because it’s quick and easy. But that’s a huge security risk. Why? Anyone with access to your repository can read those secrets. Even if you delete the secret later, it still lives in your version history . In Git, everyone  has a full copy of the repo — including that secret. Rotating secrets means you have to redeploy the code every time. Bottom line: never hardcode credentials . Ever. ------------------------------------------------------------------------------------------------------------- Be Especially Careful with GitHub GitHub is an amazing place for collaboration — but it’s also a goldmine for attackers searching for exposed secrets. Tools to Scan for Secrets in Git Repos Here are some great open-source tools that can help you detect secrets in your repositories: Gitrob 👉 https://github.com/michenriksen/gitrob Scan GitHub repos for sensitive files, credentials, and even things like IPs, domains, and tokens. It maps out all repos under your organization and flags risky content. truffleHog 👉 https://github.com/dxa4481/truffleHog Performs deep searches through the entire commit history  of a repo, looking for high-entropy strings (which often indicate secrets). Git-all-secrets 👉 https://github.com/anshumanbh/git-all-secrets Clones and scans repos using multiple tools (including truffleHog). A great “all-in-one” option. These tools help you catch exposed secrets before they catch you . ------------------------------------------------------------------------------------------------------------- Preventing Secrets from Getting Into Code Detecting secrets is one thing — but wouldn’t it be better if they never made it  into your codebase in the first place? That’s where pre-commit tools come in. They stop you from accidentally committing secrets to your repo. Here are some popular ones: git-secrets  (by AWS Labs) 👉 https://github.com/awslabs/git-secrets Blocks commits that contain secrets. It can be installed locally and even customized with regex patterns. Talisman (ThoughtWorks) 👉 https://github.com/thoughtworks/talisman Hooks into Git’s pre-push process and scans for suspicious content — like private keys or tokens — before allowing a push. SEDATED (OWASP) 👉 https://github.com/OWASP/SEDATED Prevents sensitive data from being pushed to remote Git servers. Git Hound 👉 https://github.com/ezekg/git-hound Uses regular expressions to detect sensitive data in commits and blocks the push if something looks fishy. You can also check out the Pre-commit framework , which has a plugin called detect-secrets  — easy to integrate with your workflow. ------------------------------------------------------------------------------------------------------------- Hands-on with Git-Secrets Let’s look at how to actually use git-secrets , since it’s one of the most popular tools out there. Step 1: Install git-secrets Inside your Git repo, run: git secrets --install This sets up pre-commit hooks automatically. You should see: ✓ Installed commit-msg hook ✓ Installed pre-commit hook ✓ Installed prepare-commit-msg hook Step 2: Register AWS patterns (optional) If you’re using AWS credentials: git secrets --register-aws Step 3: Check what patterns are active git secrets --list This lists all the regex patterns it’s scanning for — like AWS access keys or secret keys. Step 4: Scan your repo git secrets --scan If nothing shows up — awesome! It means your repo is clean. 🎉 ------------------------------------------------------------------------------------------------------------- Ansible — Keep It Simple, Keep It Safe Ansible Vault  ( official docs ) is built right into Ansible (since version 1.5). It allows you to encrypt sensitive data (like passwords, private keys, and tokens) inside special files called vault files . These can be safely stored in your Git repo or shared between teams — no more plain-text secrets! To use it: ansible-vault create secrets.yml You can then edit, view, or decrypt files with: ansible-vault edit secrets.yml ansible-vault view secrets.yml ------------------------------------------------------------------------------------------------------------- Secret Keepers — Centralized Secrets Management At some point, you’ll realize: instead of juggling secrets across multiple tools, you need a central place  to store, rotate, and control access. That’s where Secret Keepers  or Secrets Servers  come in. These are dedicated platforms that: Store and encrypt secrets centrally Allow secure API or CLI access Support rotation, revocation, and auditing Manage authentication and access policies Provide high availability and logging Open-Source Secret Keepers Tool Description Vault OSS (HashiCorp) The most widely used open-source secrets manager. Supports dynamic secrets, key rotation, encryption as a service, and integrates with multiple backends (AWS, databases, etc.). Conjur OSS (CyberArk) Open-source enterprise-grade secrets and identity manager. Handles access control and secret retrieval. Keywhiz (Square) Provides secure access to secrets via REST API or FUSE filesystem. Uses mTLS for authentication. Confidant (Lyft) AWS-native secrets manager that stores encrypted data in DynamoDB. Knox (Pinterest) Lightweight, developer-friendly secrets tool written in Go for key creation and rotation. Commercial Secrets Management Tools Tool Description Amazon KMS Manages encryption keys using dedicated hardware security modules (HSMs). Fully integrated with AWS services. Amazon Secrets Manager Manages secrets like API keys and DB credentials with APIs for rotation and retrieval. CyberArk Secrets Manager Enterprise-grade vaulting solution with AD/LDAP integration and strong auditing. Google KMS / Secret Manager Scalable key and secret management for Google Cloud Platform. Integrated with IAM and audit logging. Microsoft Azure Key Vault Protects keys and secrets using FIPS 140-2 certified HSMs. Integrates with Azure logging and identity services. Vault Enterprise (HashiCorp) Commercial version of Vault with advanced identity management, MFA, replication, and enterprise support. ------------------------------------------------------------------------------------------------------------- Wrapping It Up Secrets management is one of those things that’s boring until it’s not . One small mistake — a single exposed API key — can lead to massive data breaches or unauthorized access. So, remember: Never hardcode secrets. Scan your repos regularly. Use pre-commit hooks  to stop leaks before they happen. Automate responsibly. Your code should be powerful — but your secrets should stay silent . -------------------------------------------------Dean-------------------------------------------------------

When we talk about secure coding , we usually think about the code we  write — avoiding insecure functions, preventing injections, or following secure design patterns. But here’s the truth: most of the code running in production today wasn’t even written by us. That’s not necessarily bad — open source drives innovation and saves time. But it also means that we’re inheriting someone else’s vulnerabilities , and in many cases… we don’t even realize it. ------------------------------------------------------------------------------------------------------------- The Open-Source Dependency Problem Here’s the scary part: A single outdated dependency can silently introduce critical security vulnerabilities into your entire application stack. Let’s say you build a web app that depends on 10 libraries. Those libraries might depend on 50 others. And if even one of them has a known vulnerability your system might be at risk without you even touching a line of insecure code. The problem grows when: Developers download old or vulnerable packages  from package managers. Teams don’t update  to newer, patched versions. And sometimes, no one even knows what dependencies  are in the system. That’s why organizations now use dependency analysis tools  — also known as Software Composition Analysis (SCA)  — to automatically detect and monitor these risks. ------------------------------------------------------------------------------------------------------------- How Dependency Scanning Works Dependency analysis tools scan your project’s: Source code Manifest files  (like package.json, requirements.txt, or pom.xml) Or even compiled build artifacts They then identify every open-source component and compare them against known vulnerability databases  — such as the National Vulnerability Database (NVD)  or other proprietary sources. If a component version matches a known vulnerable one, you’ll get an alert — often with details about the CVE ID , severity , and recommended fix . Modern CI/CD pipelines can even fail a build automatically  if a critical vulnerability is detected, preventing risky code from being deployed. ------------------------------------------------------------------------------------------------------------- Popular Open-Source Tools for Managing Vulnerable Dependencies Several open-source tools can help detect and manage vulnerable libraries across different programming ecosystems. Here are some of the most widely used: Tool Language / Features OWASP Dependency-Check Scans Java, .NET, Ruby, Node.js, Python, and limited C/C++ (autoconf/cmake). Compares against CVE databases. Bundler-Audit Checks Ruby Gem dependencies for known vulnerabilities. Retire.js Scans JavaScript libraries (including browser JS) for known security issues. PHP Dependency Checker Detects insecure PHP Composer dependencies. GitHub Dependabot Alerts Automatically detects and reports vulnerable dependencies in Java, JavaScript, .NET, PHP, Python, and Ruby projects. Safety Checks Python dependencies against the Safety DB. Microsoft Application Inspector CLI tool that analyzes dependencies, highlights risks, and flags potential backdoors. Open-source tools include: Ruby:   Bundler-Audit Node.js:   Node Security Project (NSP) JavaScript:   Retire.js PHP:   PHP Dependency Checker Python:   Safety ------------------------------------------------------------------------------------------------------------- Commercial Tools for Dependency Management If you’re working in an enterprise environment, there are several commercial SCA tools  that go beyond open-source scanners. These tools typically: Offer deep integration  into CI/CD pipelines Include license compliance checking Maintain proprietary vulnerability databases  for faster detection Provide governance controls  for managing third-party risk Here are some leading solutions: Tool Features Black Duck (Synopsys) Inventories open-source code for both security and license vulnerabilities. FOSSA Multi-language component analysis with license governance. Sonatype Nexus Lifecycle Integrates into CI/CD pipelines; checks for vulnerable or non-compliant components. Snyk Finds and patches vulnerabilities in Node.js, Ruby, Python, Java, Scala, and more. Free for open-source projects. FlexNet Code Insight Manages and controls downloads of open-source components. SourceClear (CA/Veracode) Detects vulnerabilities not yet public using proprietary analysis. WhiteSource (now Mend) Plugin-based solution that checks both security and licensing issues. JFrog Xray Works with Artifactory; performs deep dependency and license scanning. WhiteHat Security (Sentinel SCA) Adds software composition analysis into the Sentinel Source platform. ------------------------------------------------------------------------------------------------------------- Why This Matters Modern development depends heavily on open-source software — and that’s perfectly fine as long as we manage it responsibly . A single vulnerable dependency can compromise your entire product. That’s why integrating SCA tools (like OWASP Dependency-Check or Snyk) into your CI/CD pipeline  is now considered a best practice. When configured properly, these tools will: Identify outdated or risky components Provide clear remediation paths Automate version updates Help enforce open-source license compliance In short, they give you visibility and control — two things that are often missing when dealing with complex dependency chains. ------------------------------------------------------------------------------------------------------------- Final Thoughts Insecure dependencies are one of the biggest blind spots in modern software development. You might be following every secure coding guideline out there, but if your application uses a vulnerable third-party library, you’re still exposed. By combining SAST tools like Semgrep  with SCA tools like Dependency-Check or Snyk , you get a complete view of your codebase — both your own code and what you’ve inherited. This layered approach is key to building truly secure applications. -------------------------------------------------Dean-------------------------------------------------