Logs are the heartbeat of any Azure investigation. But Azure's logging architecture is not a single flat file you download and read — it is a multi-layered system where different types of activity are captured in different log sources, stored in different places, and queried in different ways. Miss a layer and you miss evidence. The Five Log Sources You Need to Know Azure organizes its logs into five categories. Understanding these upfront prevents the confusion of wondering why an action does not appear in the log you are searching: Tenant Logs — Identity events: sign-ins, user management, policy changes. ON by default. This is where you catch credential abuse, password spray attacks, and unauthorized access. Subscription Logs — Resource management events: creation, deletion, and modification of Azure resources. Also ON by default. Critical for crypto mining investigations, sabotage cases, and tracking attacker infrastructure setup. Resource Logs — Logs generated by specific Azure resources. OFF by default. This is where data exfiltration evidence lives — and where many investigators find the cupboard bare. Operating System Logs — Windows event logs or Linux syslog from inside the VMs. OFF by default. Requires an agent installed on the VM. Application Logs — Custom logs generated by applications running in Azure. OFF by default. The uncomfortable reality: when you arrive at an incident, there is a real chance only the first two categories are being collected. If your client did not set up a Log Analytics workspace and configure the optional log sources, you are working with maybe 20% of the potential evidence. Part of your job is to turn those on immediately so you do not lose any more data going forward. 💡 Investigator Note: Educating clients on log configuration is incident response step zero. The best time to set up logging is before anything happens. The second-best time is the moment you get the call. The Log Analytics Workspace: Your Central Investigation Hub Microsoft stores some logs by default and makes them accessible in the Azure Portal. But for any serious investigation, you need logs aggregated in one place where you can query them properly. That place is the Log Analytics Workspace. The Log Analytics Workspace collects and aggregates logs from Azure resources, on-premises systems, and other sources. It organizes everything into tables — each log source gets its own table — and exposes them for querying using the Kusto Query Language (KQL). The default workspace can handle up to 6GB of data per minute with a daily cap of 4TB, which is sufficient for all but the largest enterprise environments. Setting Up a Log Analytics Workspace If you are called to an environment that does not have one configured, here is how to create it: Step 1 — In the Azure Portal, search for 'Log Analytics workspaces' in the search bar Step 2 — Select 'New' to create a workspace Step 3 — Fill in the Subscription, Resource Group, Name, and Region Step 4 — Select 'Review + Create' Once the workspace exists, configure log sources to send their data there. The workspace becomes your single pane of glass for the investigation. Tenant Logs: Where Identity Events Live Tenant logs cover everything related to identity and authentication. This is where Microsoft Entra ID (formerly Azure Active Directory) writes its records — who logged in, when, from where, whether they succeeded or failed, and what administrative changes were made to the directory. 📌 Old: Throughout Azure documentation you will see 'Azure Active Directory' and 'AAD' used frequently. ➜ Updated: Microsoft renamed Azure Active Directory to Microsoft Entra ID in October 2023. Functionally identical. In the Azure Portal, search for 'Microsoft Entra ID'. In KQL queries, some table names still use 'AAD' prefixes. What the Tenant Log Contains Audit Logs — Changes to the directory: adding or removing users, modifying groups, changing roles, updating policies. If someone added an attacker-controlled account or escalated privileges, this is where you find it. Sign-in Logs — Authentication events for every user sign-in. Includes timestamp, user, IP address, location, application, success/failure status, and whether MFA was satisfied. Non-interactive User Sign-ins — Sign-ins that happen without user input such as refresh tokens and legacy auth. Service Principal Sign-ins — Authentication events for applications and service accounts. Managed Identity Sign-ins — Authentication events for Azure-managed identities. Provisioning Logs — Activity related to user and group provisioning. Identity Protection Logs — Risk events flagged by Microsoft's detection engine: RiskyUsers, UserRiskEvents, RiskyServicePrincipals. Reading Sign-In Log Status Values Every sign-in event has a Status field with one of three values: Success — Authentication completed successfully. Failure — Authentication was rejected: wrong password, blocked account, MFA failure, etc. Interrupted — The sign-in flow was paused mid-process, most commonly because the 'Stay signed in?' prompt appeared and the user closed the browser or selected No. Do not confuse Interrupted with a suspicious event — it is usually benign. When investigating credential abuse, focus on patterns: repeated failures from a single IP (password spray), failures from unusual geographies, or a success event immediately after a failure burst. The MFA column tells you whether multi-factor authentication was enforced for each sign-in. 💡 Investigator Note: The portal only shows the last 30 days of sign-in logs. For anything older, you need logs exported to a Log Analytics workspace or storage account. If those were not configured before the incident, you have a hard 30-day limit on visibility. Sending Tenant Logs to Log Analytics To send Entra ID logs to your Log Analytics Workspace: Step 1 — Search for and open 'Microsoft Entra ID' in the portal Step 2 — In the left menu, select 'Diagnostic settings' Step 3 — Select 'Add diagnostic setting' Step 4 — Select the log categories you want (SigninLogs, AuditLogs, etc.) and choose your Log Analytics Workspace as the destination Querying Tenant Logs with KQL Once your logs are in the workspace, query them using KQL — similar to SQL but optimized for log data. Here are practical examples: All successful sign-ins in the last 24 hours: SigninLogs | where TimeGenerated > ago(1d) | where ResultType == 0 Sign-ins from a specific country: SigninLogs | where TimeGenerated > ago(7d) | where Location == "RU" | project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultType Accounts with multiple failures — potential password spray: SigninLogs | where TimeGenerated > ago(1d) | where ResultType != 0 | summarize FailureCount = count() by UserPrincipalName, IPAddress | where FailureCount > 10 | order by FailureCount desc Exporting Tenant Logs for SIEM or Long-Term Storage Two scenarios where you will want logs outside the workspace: Storage Account (Archival) — For retention beyond the workspace limit, export logs to an Azure Storage Account. Once there, specify a retention period. Useful for compliance and for having a separate copy an attacker cannot delete by compromising your management plane. Event Hub (SIEM Integration) — If your client has a SIEM, the Event Hub streams logs in real time. Splunk, QRadar, Microsoft Sentinel, and most other SIEMs have native connectors for Azure Event Hub. 💡 Investigator Note: When investigating, always check whether an event hub is configured. If it is, there may be a SIEM your client forgot to mention that holds historical log data going back much further than what is visible in Azure. Subscription Logs (Activity Logs): Tracking What Was Built, Changed, or Destroyed Subscription logs — officially called the Activity Log — record every operation performed through the Azure Resource Manager. Any time a resource was created, modified, or deleted, there is a record here. Activity logs are enabled by default and require no additional configuration. This log source is particularly valuable for two types of investigations: Crypto mining incidents — Attackers spin up high-compute VMs to mine cryptocurrency. Activity logs show when those VMs were created, what size they were, and which account created them. Sabotage and destructive attacks — Activity logs show mass deletion events, including which resources were deleted, by whom, and when. Key Fields in the Activity Log ResourceId — The full resource identifier of what was acted on. Tells you exactly what was touched. OperationName — What action was taken. Format: Provider/ResourceType/Action. For example: MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE for creating or modifying a VM. ResultType / ResultSignature — Whether the operation succeeded or failed. CallerIpAddress — The IP address of the entity that made the request. Critical for attribution. CorrelationId — A GUID that links related sub-operations together. When creating a VM triggers multiple sub-operations (disk, NIC, IP address), they all share the same CorrelationId. Claims — The sub-field under Identity that contains information about the principal who made the request. Send Activity Logs to your workspace using 'Export Activity Logs' in the portal. Once configured, data populates the AzureActivity table. Find all delete operations — attacker covering tracks or ransomware: AzureActivity | where OperationNameValue contains "DELETE" | project TimeGenerated, OperationNameValue, ResourceId, CallerIpAddress, Caller | order by TimeGenerated desc This query is particularly telling when you see a resource group deletion. Deleting a resource group removes everything inside it — VMs, disks, NICs, IP addresses — in a single action. Enumerate all unique compute operations to understand attacker activity on VMs: AzureActivity | where OperationNameValue contains "COMPUTE" | distinct OperationNameValue Count operations by type for a scope-of-impact overview: AzureActivity | where OperationNameValue contains "COMPUTE" | summarize count() by OperationNameValue This gives you a pivot-table-style summary: how many VMs were created, started, stopped, deleted. The volume and pattern of operations often tells a story without needing to look at individual entries. In the next article, we cover the log sources that are off by default but critical for deep investigations: NSG flow logs, storage account access logs, and operating system and application logs from inside the VMs themselves. ----------------------------------------------------------------------------------------------------------Special Thanks I would like to extend my heartfelt gratitude to one of my dearest friends, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication! https://www.linkedin.com/in/iqrabintishafi/ ------------------------------------------------------------------------------------------------------------- Next Article: https://www.cyberengage.org/post/azure-logging-part-2-storage-accounts-nsg-flow-logs-and-the-data-exfiltration-trail

You just got Azure access mid-incident. The clock is running, the client is watching, and you need to move fast without missing anything. This is not the time to figure out what to look at — that thinking should already be done. Fifteen commands, organized in the exact sequence you should run them, with a clear explanation of what each one tells you and what red flags to look for. Bookmark it. Run it on every Azure engagement. All commands work in Azure Cloud Shell (Bash or PowerShell) and in any local terminal with the Azure CLI installed. No special permissions beyond read access are required for most of these — though Owner-level access is recommended for a complete picture. Phase 1: Environmental Baseline — Know What You Are Walking Into These first four commands take under two minutes and give you a complete picture of the environment before you touch anything else. Never skip this phase. Command 1 — Confirm Your Access Scope The very first thing to verify is which subscriptions you can actually see. Clients often say 'you have full access' when they mean full access to one subscription. This shows you exactly what your credentials can reach: az account list --output table What to look for: how many subscriptions exist, which one is currently selected (marked as IsDefault), and whether any subscriptions are missing that your client said would be in scope. If subscriptions are missing, stop and get access before proceeding. Command 2 — Switch to the Right Subscription If there are multiple subscriptions, select the one relevant to your investigation before running any further commands: az account set --subscription "Subscription Name Here" Repeat the remaining commands for each subscription in scope. Role assignments, resources, and logs do not automatically span subscriptions — you have to check each one individually. Command 3 — Map the Resource Groups Resource groups are the logical folders that contain everything in a subscription. This command gives you an instant map of the environment: az group list --output table What to look for: resource group names that do not match what your client described, groups in unexpected regions, or groups with generic names like 'rg-temp' or 'test-rg' that nobody can explain. Attackers who deploy their own infrastructure always create a resource group to hold it. Command 4 — Full Resource Inventory Every virtual machine, storage account, database, network interface, and resource in the subscription — listed in one command: az resource list --query "[].{Name:name, RG:resourceGroup, Type:type, Location:location, State:provisioningState}" --output table This command shows you Name, Resource Group, Type, Location, and Provisioning State. What to look for: VMs with names you do not recognize — use Command 12 further below to get their sizes and running status in full detail Storage accounts with generic or random-looking names — potential attacker staging areas for data exfiltration Resources in regions your client does not normally operate in — the Location column makes this easy to spot Resources in resource groups that were not on your client's environment map — cross-reference with Command 3 output 💡 Investigator Note: az resource list does not show creation time by default. To find when a specific resource was created, query the Activity Log — covered in detail in the Azure Logging articles in this series. az monitor activity-log list --start-time 2026-04-01T00:00:00Z --query "[?contains(operationName.value,'write')].{Time:eventTimestamp, Name:name, Resource:resourceId, Caller:caller, Operation:operationName.value}" --output table Phase 2: Identity and Access — Who Can Do What Once you know what exists in the environment, you need to know who has access to it. This phase maps the full access picture and is where you will most commonly find attacker persistence. Command 5 — Find All Owner-Level Access Owner is the most dangerous role in Azure. An Owner can do anything — create resources, delete resources, grant access to others, and remove logs. Finding every Owner across the subscription is non-negotiable: az role assignment list --all --query "[?roleDefinitionName=='Owner']" --output table What to look for: any account your client cannot immediately identify. Service principals with Owner access. Guest accounts with Owner access. Accounts that were granted Owner access around the incident timeframe. 💡 Investigator Note: Every Owner in this list is a potential persistence mechanism if the attacker gained one of these accounts. Cross-reference each one against your known user list. Command 6 — Find All Contributor Access Contributor is the second most powerful role — full create and delete access without the ability to grant access to others. Still critical to enumerate: az role assignment list --all --query "[?roleDefinitionName=='Contributor']" --output table What to look for: same as above. Any unrecognized account or service principal with Contributor access can create and destroy resources — enough capability for most attacker objectives. Command 7 — Full Role Assignment List Get every role assignment across all resource groups and resources in the subscription — not just subscription-level assignments: az role assignment list --all --output table The --all flag is what makes this comprehensive. Without it you only see top-level assignments and miss any access granted at the resource group or individual resource level. This is the complete picture. Command 8 — Enumerate a Specific User's Access When you have identified a compromised account, enumerate exactly what it has access to across the entire subscription: az role assignment list --all --assignee user@yourtenant.onmicrosoft.com --output table Replace the email with the actual compromised account UPN. Repeat this for every subscription in scope — access granted in one subscription does not appear when querying another. Phase 3: Threat Hunting — Looking for What the Attacker Left Behind Beyond investigating the original compromised account, experienced attackers always leave something behind. These commands hunt for the most common persistence mechanisms used in Azure environments. Command 9 — List All Guest Accounts Guest accounts are the most overlooked persistence mechanism in Azure. They can be added using any external email address — a personal Gmail, Outlook, or any other external identity. They do not appear in normal HR user lists and survive password resets on internal accounts: az ad user list --query "[?userType=='Guest'].{Name:displayName, Email:userPrincipalName, Created:createdDateTime}" --output table What to look for: any guest account added around the incident timeframe. Any guest account your client cannot explain. Guest accounts with Owner or Contributor role assignments from Command 5 or 6. Command 10 — List All Service Principals Service principals are application identities. Attackers register rogue applications and grant them permissions because service principals are invisible to most user audits, are not affected by password resets, and persist independently of any user account: az ad sp list --all --query "[].{Name:displayName, AppId:appId, Type:servicePrincipalType}" --output table What to look for: service principals with generic or suspicious names, any service principal created around the incident timeframe, and cross-reference against your role assignment results to see which ones have elevated permissions. 💡 Investigator Note: A service principal with Owner or Contributor access that your client cannot explain is a critical finding. It means an attacker has persistent access that survives any user account remediation. Command 11 — Find Recently Created User Accounts If the attacker created a new internal user account as a backdoor, it will appear in the directory sorted by creation date. This command surfaces it: az ad user list --query "sort_by([?createdDateTime!=null].{Name:displayName, Email:userPrincipalName, Created:createdDateTime}, &Created)" --output table Scroll to the most recently created accounts. Any account created during or just before the incident window that your client cannot explain should be treated as an attacker-created backdoor until proven otherwise. Phase 4: Network and Infrastructure — Understand the Attack Surface These commands map the network and compute infrastructure, helping you understand what was exposed to the internet and what paths an attacker could have used. Command 12 — List All Virtual Machines with Full Detail Get a focused list of every VM with its current power state, size, and location. This is where you check for high-compute sizes used for crypto mining: az vm list --show-details --query "[].{Name:name, Status:powerState, Size:hardwareProfile.vmSize, RG:resourceGroup, Location:location}" --output table What to look for: VMs in a stopped/deallocated state that should be running, high-compute sizes like Standard_NC, Standard_F, or Standard_H series that are expensive and commonly used for crypto mining, VMs in unexpected resource groups or regions, and any VM your client did not provision. Command 13 — List All Public IP Addresses Every public IP address in the subscription represents a potential entry point. This command lists all of them: az network public-ip list --query "[].{Name:name, IP:ipAddress, Associated:ipConfiguration.id, RG:resourceGroup}" --output table What to look for: public IPs not associated with any resource (could be leftover from a deleted VM), IPs in resource groups you do not recognize, and any IP associated with a resource the client did not provision. Command 14 — List All Storage Accounts Storage accounts are the most common data exfiltration destination in Azure. This command lists all of them with their public access configuration: az storage account list --query "[].{Name:name, RG:resourceGroup, PublicAccess:allowBlobPublicAccess, Location:location}" --output table What to look for: any storage account where PublicAccess is true — this means blobs in that account may be publicly accessible without credentials. Any storage account your client did not create. Storage accounts in unexpected resource groups. 💡 Investigator Note: A storage account with public blob access enabled is a high-priority finding in any investigation. It could be the exfiltration destination or an accidentally exposed data store. Check it immediately. Phase 5: Management Groups — The Top of the Hierarchy Command 15 — Check for Management Groups The final command checks whether management groups exist and, if they do, what structure they create. Policies and permissions at this level cascade down to every subscription beneath them: az account management-group list --output table What to look for: the existence of management groups at all, the hierarchy they create, and whether any unexpected policies or permissions may have been applied at this level. If management groups exist, investigate what policies are assigned to them — these policies control logging, security settings, and access across the entire tenant. Quick Reference: All 15 Commands in One Place Copy and paste this block into your notes at the start of every Azure engagement: # PHASE 1: ENVIRONMENTAL BASELINE az account list --output table az account set --subscription "Subscription Name" az group list --output table az resource list --query "[].{Name:name, RG:resourceGroup, Type:type, Location:location, State:provisioningState}" --output table # PHASE 2: IDENTITY AND ACCESS az role assignment list --all --query "[?roleDefinitionName=='Owner']" --output table az role assignment list --all --query "[?roleDefinitionName=='Contributor']" --output table az role assignment list --all --output table az role assignment list --all --assignee user@tenant.onmicrosoft.com --output table # PHASE 3: THREAT HUNTING az ad user list --query "[?userType=='Guest'].{Name:displayName, Email:userPrincipalName, Created:createdDateTime}" --output table az ad sp list --all --query "[].{Name:displayName, AppId:appId, Type:servicePrincipalType}" --output table az ad user list --query "sort_by([].{Name:displayName, Email:userPrincipalName, Created:createdDateTime}, &Created)" --output table # PHASE 4: NETWORK AND INFRASTRUCTURE az vm list --show-details --query "[].{Name:name, Status:powerState, Size:hardwareProfile.vmSize, RG:resourceGroup, Location:location}" --output table az network public-ip list --query "[].{Name:name, IP:ipAddress, Associated:ipConfiguration.id, RG:resourceGroup}" --output table az storage account list --query "[].{Name:name, RG:resourceGroup, PublicAccess:allowBlobPublicAccess, Location:location}" --output table # PHASE 5: MANAGEMENT GROUPS az account management-group list --output table These 15 commands are your Azure IR starting point — not your ending point. What you find here drives where you go next. Unexpected VMs lead you to activity logs. Suspicious storage accounts lead you to StorageRead logs. Guest accounts lead you to sign-in logs. Let the findings from this playbook direct your deeper investigation. All five log source types, how to enable them, and how to query them are covered in the Azure Logging articles in this series. --------------------------------------------------------Dean------------------------------------------------ Special Thanks I would like to extend my heartfelt gratitude to one of my dearest friend, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication! https://www.linkedin.com/in/iqrabintishafi/ Next Article https://www.cyberengage.org/post/part-3-getting-into-azure-four-access-methods-and-the-forensic-artifacts-each-one-leaves-behind

Every Azure investigation starts with access. Before you can query a single log or examine one VM, you need to authenticate to the environment and navigate to what you need. But access goes both ways — the same methods you use to investigate are the same ones threat actors use to carry out attacks. Understanding all four access methods is not just procedural. It directly informs what evidence you should be looking for and where. The Four Ways Into Azure Microsoft offers four primary interfaces for interacting with Azure resources: The Azure Portal — a graphical web interface Azure CLI — a command-line interface using 'az' commands Azure PowerShell — a scripting interface using the Az module The Microsoft Graph API — a RESTful API for programmatic access An important point: all four methods route through the Azure Resource Manager. No matter which interface an action comes from, it gets logged in the same place. A GUI click in the portal and a CLI command produce the same underlying log entry. There is no hidden channel. That is actually a significant advantage for investigators. Method 1: The Azure Portal The Azure Portal is the web-based GUI that most users interact with daily. It requires authentication — username and password, with MFA if configured (and it should be). For incident responders, the portal is the fastest way to get an initial lay of the land. Three views are particularly useful right from the start: All Resources — a complete list of every provisioned resource across the subscription. Usually the first thing to review when understanding what is running in the environment. Activity Log — a timeline of resource-level changes. Critical for tracing what was created, modified, or deleted. Microsoft Entra ID — the identity hub for reviewing user accounts, sign-in logs, and audit events. The portal is excellent for quick lookups and initial assessment, but it has real limitations for deep investigations. Most log views in the portal are capped at 30 days of retention and filtering options are basic. For anything beyond a surface-level review, move to the Log Analytics workspace or export logs to a more capable tool. 📌 Old: The portal still references 'Azure Active Directory' in many places. | Updated: Since the October 2023 rebrand to Microsoft Entra ID, the portal now shows 'Microsoft Entra ID' in the left navigation. Functionally identical — logs, sign-in records, and audit data are all in the same place. Method 2: Azure CLI The Azure CLI gives you a set of 'az' commands that can manage virtually every resource in Azure. It runs on Windows, macOS, and Linux, and can also be run directly from the Azure Portal's built-in Cloud Shell. The CLI is preferred by many investigators because it is scriptable, reproducible, and does not require navigating through menus. Here is the basic authentication and navigation workflow: az login This opens a browser for authentication. Once done, list available subscriptions: az account list Select the relevant subscription: az account set --subscription "Production Environment" From here, virtually anything you can do in the portal can be done via CLI. The practical advantage during an investigation is speed and repeatability — you can build a set of commands that quickly pulls the artifacts you need and can be re-run to refresh data. You can use Bash as well 💡 Investigator Note: If you are working from a client-managed machine where you would rather not install the CLI, Cloud Shell gives you CLI access directly from the browser without any installation required. Method 3: Azure PowerShell Azure PowerShell is the Microsoft-native scripting approach. It uses the Az PowerShell module — not the older AzureRM module, which is now deprecated and should not be in use in any modern environment. 📌 Old: Older environments may still have the AzureRM module installed. | Updated: Microsoft deprecated AzureRM in February 2024 and removed it from the PowerShell Gallery. Any environment still using AzureRM-based scripts is running on an unsupported module. Flag it — it suggests outdated tooling and a potentially less-maintained environment. Setting up Azure PowerShell on a fresh Windows machine: # Step 1: Open PowerShell as Administrator # Step 2: Install the Az module Install-Module -Name Az -AllowClobber # Step 3: Verify installation Import-Module Az; Get-Module Az # Step 4: Authenticate Connect-AzAccount Once connected, PowerShell equivalents of common investigation tasks are available. For example, to retrieve activity logs: Get-AzLog -ResourceProvider "Microsoft.Compute" -DetailedOutput PowerShell also lets you extract VM configuration data from logs — useful when you need to understand what a VM looked like at a specific point in time: $results = Get-AzLog -ResourceProvider "Microsoft.Compute" -DetailedOutput $results.Properties | foreach {$_} | foreach { $contents = $_.Content if ($contents -and $contents.ContainsKey("responseBody")) { $fromjson = ($contents.responseBody | ConvertFrom-Json) [PSCustomObject]@{ VmId = $fromjson.properties.vmId VmSize = $fromjson.properties.hardwareprofile.vmsize } } } Method 4: The Microsoft Graph API The Graph API is a RESTful API that allows programmatic access to Azure and Microsoft 365 data. It predates the event hub as an integration mechanism, which means you will frequently encounter it in SIEM configurations — many organizations have their SIEM pulling data from Azure via the Graph API. From an investigative standpoint, the Graph API matters for two reasons: some data is only accessible through it and not through the portal or CLI; and threat actors frequently abuse application tokens obtained through the Graph API to maintain persistent access without needing a user's password. When reviewing an environment's logging configuration, always check whether a SIEM is connected via Graph API or event hub — this may reveal a log repository your client forgot to mention. 💡 Investigator Note: Graph API supports multiple languages: Python, Node.js, PHP, C#, and others. If your client's development team has built internal tools, check whether they use the Graph API — those tools could be useful data sources or, if compromised, vectors for data exfiltration. Cloud Shell: The Built-In Terminal — and a Forensic Goldmine Cloud Shell is one of Azure's most convenient features and one of its most overlooked forensic artifacts. It is a fully functional command-line terminal available directly inside the Azure Portal — no installation required. When a user clicks the terminal icon, they choose between Bash (using Azure CLI) or PowerShell. For administrators it is a huge convenience. For investigators it raises an important question: if a threat actor obtained Azure credentials and used Cloud Shell, would you be able to tell — and would you be able to see what they did? The answer depends on two things: which shell they chose, and whether Cloud Shell was running in persistent or ephemeral mode.. First Step: Determine Which Mode Was Used Before looking for any Cloud Shell artifacts, you need to establish whether Cloud Shell was even configured with persistent storage. Azure Cloud Shell now runs in two distinct modes: Persistent Mode — When a user first launches Cloud Shell and chooses to mount a storage account, Azure creates a dedicated storage account and file share to preserve the home directory and command history across sessions. This is the mode that leaves forensic artifacts. Ephemeral Mode — When a user launches Cloud Shell without mounting any storage (they click 'proceed without storage' or Azure prompts them with an ephemeral session), no storage account is created. The session is wiped clean when it ends. No .bash_history survives. No artifacts remain. You will know ephemeral mode is active when you see this message at the top of the Cloud Shell session: "Your Cloud Shell session will be ephemeral so no files or system changes will persist beyond your current session." To check whether persistent Cloud Shell storage exists in the environment, run these two commands: az group list --query "[?contains(name, 'cloud-shell')]" --output table az storage account list --query "[?contains(resourceGroup, 'cloud-shell')]" --output table If both commands return empty output, no persistent Cloud Shell storage exists in that subscription. Either the environment uses ephemeral mode, or Cloud Shell has never been used. Either way — no file-based artifacts to collect. 💡 Investigator Note: Empty output from both commands does not mean Cloud Shell was never used. It means no persistent artifacts were stored. The sign-in logs and activity logs will still show if Cloud Shell was accessed — check those regardless. Cloud Shell Bash — Persistent Mode: The Forensic Trail When a user has configured persistent Cloud Shell storage and selected the Bash environment, Azure creates a storage account and file share to store the home directory. This is where the forensic artifacts live. To find the storage account, look for a resource group named cloud-shell-storage- for example, cloud-shell-storage-eastus. The storage account inside will have an auto-generated name. Once you locate it, navigate to File Shares inside the storage account. ⚠️ Updated: Older documentation states the storage account name consistently starts with the letters 'cs'. This may no longer be reliable in newer Azure environments. Use the resource group name 'cloud-shell-storage-' as the more dependable way to locate it. Inside the file share you will find the user's home directory. The artifacts that matter most: .bash_history — every command run in the Bash Cloud Shell session is recorded here. This is your primary evidence source. Even if a threat actor was careful, there is always a chance they did not bother clearing history in a shell they expected to be temporary. .wget-hsts — if the threat actor used wget to download files such as tools, scripts, or malware, entries appear here. The HSTS file records each HTTPS host that wget contacted, including timestamps. Other Linux artifacts — depending on what the attacker did, additional traces may be present such as downloaded scripts, shell configuration files, and temporary files. To find and collect these artifacts during an investigation: Run the two resource group and storage account commands above to locate the persistent Cloud Shell storage. Open Azure Storage Explorer and connect to the identified storage account. Navigate to File Shares → .cloudconsole → download acc_.img. Mount the disk image on a Linux machine: sudo mount -o loop acc_username.img /mnt/cloudshell Navigate to the history files: cat /mnt/cloudshell/.bash_history cat /mnt/cloudshell/.wget-hsts Check for any other files the attacker may have downloaded or created Cloud Shell PowerShell — Persistent Mode: Not a Complete Blind Spot In persistent mode, both Bash and PowerShell use the exact same home directory persistence mechanism. Azure stores the entire $HOME directory as a disk image (acc_.img) in the same storage account and file share used by Bash. PowerShell writes its command history using PSReadLine to: ~/.local/share/powershell/PSReadLine/ConsoleHost_history.txt This file lives inside $HOME, which means it is inside the disk image, which means it is recoverable from the storage account — using the exact same steps as for Bash. How to Recover PowerShell History Locate the storage account using the same steps as Bash (cloud-shell-storage- resource group). Download acc_.img from File Shares → .cloudconsole. Mount the disk image: sudo mount -o loop acc_username.img /mnt/cloudshell 4. Read the PowerShell history: cat /mnt/cloudshell/.local/share/powershell/PSReadLine/ConsoleHost_history.txt 💡 Important Caveat: PSReadLine writes its history file at session end, not in real time. If the attacker's session ended abnormally (browser closed, timeout, force-kill), the most recent commands may not have flushed to disk. .bash_history has a similar but less severe gap. Always check both files if both shells were used When PowerShell IS a Blind Spot PowerShell Cloud Shell only has no file artifacts in one scenario: ephemeral mode. If the attacker used ephemeral mode with PowerShell, no storage account is created and no history file is written. In this case, fall back to the Azure Activity Log and sign-in logs for evidence of what actions were taken. 💡 Investigator Note: Even without command history, the Activity Log records every resource-level action (creating VMs, modifying configs, querying key vaults). You will not see raw commands typed, but you will see the effects of those commands. This is a strong argument for ensuring Activity Logs and resource-specific logs are flowing to a Log Analytics workspace or SIEM before an incident happens. Quick Reference: What to Expect by Mode and Shell Mode Shell Storage Account Created Forensic Value Persistent Bash Yes — cloud-shell-storage- High — .bash_history, .wget-hsts available Persistent PowerShell Yes — same storage account as Bash Medium-High — ConsoleHost_history.txt via PSReadLine (inside acc_user.img) Ephemeral Bash or PowerShell No None — session wiped. Check sign-in logs and Activity Log only. Investigator Tip: When You Cannot Find the Storage Account If the cloud-shell-storage- resource group does not appear, try these steps in order: Check all subscriptions — Cloud Shell storage is created in whichever subscription was active when Cloud Shell was first launched. Switch subscriptions and re-run the search commands. Search by tag across all subscriptions: az resource list --tag ms-resource-usage=azure-cloud-shell -o table If the storage account was deleted, check the Activity Log for: Microsoft.Storage/storageAccounts/delete If nothing is found at all, the session was likely ephemeral — fall back to sign-in logs and Activity Log. 💡 To confirm Cloud Shell was used at all: check Entra ID Sign-in logs and filter by application ID c44b4083-3bb0-49c1-b47d-974e53cbdf3c. This is the Azure Cloud Shell app ID. Sessions appear here regardless of whether persistent or ephemeral mode was used. Choosing Your Access Method as an Investigator In practice you will use all four methods at different points in an investigation. Here is a rough guide: Portal — Start here for initial orientation. Get an overview of resources, check sign-in logs for recent activity, and verify your access level. CLI (az commands) — Use for bulk enumeration: listing resources, querying role assignments, pulling activity logs across subscriptions. PowerShell — Use when you need to process log output programmatically or when your client's existing scripts are PowerShell-based. Graph API — Use when you need identity-related data not readily available through the other interfaces, or when building automated collection scripts. In the next article, we move from access methods into the infrastructure itself — specifically virtual machines and networking — which are typically at the center of any Azure incident. Special Thanks I would like to extend my heartfelt gratitude to one of my dearest Friend, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication! https://www.linkedin.com/in/iqrabintishafi/ ------------------------------------------Dean-------------------------------------------------------- Next Article : https://www.cyberengage.org/post/azure-compute-and-networking-what-incident-responders-actually-need-to-know

Azure incident response is not the same as endpoint IR. The telemetry is different, the artifacts are different, and if you approach it the same way, you will miss everything that matters. Lets start with this series Before you can investigate anything in Microsoft Azure, you need to speak the language. Not the marketing language — the actual structural language that determines who can see what, where logs live, and why you might be staring at a completely blind spot without even knowing it. Azure is not just a place where virtual machines run. It is a layered ecosystem with a very specific hierarchy, and if you do not understand that hierarchy, you will waste hours chasing down logs that do not exist yet, or requesting permissions that will not actually give you what you need. This article breaks down the Azure architecture the way an investigator needs to understand it — not as a cloud architect, but as someone who shows up mid-incident and needs to know what they are looking at, fast. The Five-Layer Architecture: How Azure Is Structured Azure organizes everything into five main components, stacked on top of each other. Think of it like a set of Russian nesting dolls — each layer lives inside the one above it, and permissions at the top flow downward to everything beneath them. 1. The Tenant The tenant is the outermost container. It represents the organization itself — your client's company. Every tenant is tied to a dedicated identity service that controls who can log in and what they can do. When a company signs up for Azure, they get one tenant. Larger enterprises may have multiple tenants for different subsidiaries or regional entities. From an investigation standpoint, the tenant boundary matters because logs, permissions, and identities are all scoped to it. If you are dealing with a multi-tenant environment, confirm which tenant holds the resources you are investigating — and make sure you have access to it before you start. 2. Management Groups Management groups are optional containers that sit above subscriptions. Large enterprises use them to organize subscriptions into logical groupings — separating production environments from development, or grouping subscriptions by business unit. What makes management groups significant for investigators: policies and permissions can be applied at this level and cascade downward to every subscription within the group. If someone set a logging policy at the management group level, it affects everything below it. If someone was granted access at the management group level, they have access to everywhere beneath it. Not every company uses management groups. Smaller organizations often skip them entirely. Do not assume they exist — verify. 3. Subscriptions A subscription is essentially a billing boundary and an agreement between the organization and Microsoft to use Azure services. Most organizations end up with multiple subscriptions to separate costs by department, project, or environment. Here is why this matters to investigators: your permissions do not automatically span all subscriptions. If you are granted access to one subscription and the resources you need are in another, you are going to hit a wall. Before starting any investigation, enumerate all subscriptions in the tenant and confirm your access level to each one. It sounds obvious but it is easy to overlook, especially when a client says 'you have admin access' without specifying that means admin access to only one of their twelve subscriptions. 4. Resource Groups Resource groups are containers for related resources. Think of them as project folders — a web application might have its own resource group containing the virtual machine, storage account, database, and networking components all in one place. Resource groups matter to investigators because access control can be scoped at this level. A user might have read-only access at the entire subscription level but Owner permissions on a specific resource group. Conversely, you might be granted access only to one resource group — which severely limits your visibility. If this happens, push back and request subscription-level access. Investigating with resource group-level permissions only is like trying to find a needle in a haystack while only being allowed to look at one bale at a time. 5. Resources Resources are the actual things — virtual machines, storage accounts, databases, network interfaces, IP addresses, and hundreds more. Each resource lives inside a resource group, which lives inside a subscription, which lives inside a tenant. Everything traces back up the chain. Resource IDs: Azure's Internal Naming Convention Every single resource in Azure — from a VM to a network interface to a snapshot — has a unique identifier called a Resource ID. It follows this predictable format: /subscriptions//resourceGroups//providers/// Take a virtual machine as an example. It has one Resource ID for the VM itself, another for its OS disk, another for its network interface, and another for any public IP address assigned to it. Each component is individually addressable. In practice, Resource IDs show up constantly in logs. When you see a long string starting with '/subscriptions/' in a log entry, that is your signpost telling you exactly which resource was touched — at which subscription, resource group, and service level. Learning to read them quickly saves real time during an investigation. Azure Resource Manager: The Traffic Cop Behind Everything Every action you take in Azure — whether through the web portal, a CLI command, a PowerShell script, or an API call — goes through one central layer called the Azure Resource Manager (ARM). ARM is the management plane that handles creation, modification, and deletion of resources. It validates your permissions, applies your request, and logs what happened. The key insight for investigators: regardless of how an action was taken, ARM processed it and ARM logged it. Whether an attacker used the Azure portal GUI or quietly ran scripts via the CLI at 3am, the record goes through the same place. There is no hidden channel that bypasses the audit trail. ARM also supports JSON-based templates called ARM templates, which let organizations deploy consistent environments repeatably — often called infrastructure as code. If you encounter these templates during an investigation, they can reveal a lot about the intended architecture of an environment. 💡 Investigator Note: ARM is conceptually similar to AWS CloudFormation. If you have AWS investigation experience, the mental model transfers well. Azure Role-Based Access Control (RBAC): Who Can Do What Azure uses Role-Based Access Control (RBAC) to govern who can access resources and what they are allowed to do. Every time a request goes through ARM, RBAC is checked to determine if the requester has the necessary permissions. Understanding RBAC matters for two reasons: it shapes what you as an investigator can actually see and do during your engagement, and it helps you identify how a threat actor may have obtained or escalated their access. The Three Elements of a Role Assignment Every access grant in Azure is built from three components: Security Principal — The entity being given access. This could be a user account, a group, a service principal (think: an application's identity), or a managed identity. Role Definition — The set of permissions being granted. The most common built-in roles are: Reader (read-only), Contributor (read and write, but cannot grant access to others), and Owner (full control, including the ability to grant access to others). Scope — Where the permission applies. This can be set at the management group, subscription, resource group, or individual resource level. When investigating an incident, you ideally want Owner-level access at the subscription level. This gives you the widest view and the most flexibility. In practice, you will sometimes be handed Contributor or Reader access to a single resource group. Know what you have — and know what you are missing. Enumerating What a User Can Access One of the first things to do in an investigation is understand what a specific user or compromised account actually had access to. This is harder than it sounds because access can be granted at any level of the hierarchy, and a user might have no access at the subscription level yet have Owner permission on a critical resource group. The most efficient way to enumerate this is via CLI. First, select the relevant subscription: az account set --subscription "Production Environment" Then enumerate role assignments for the account under investigation: az role assignment list --all --assignee compromised-user@company.com The --all flag is essential. Without it, you only see top-level assignments and miss anything granted at the resource group or individual resource level. Repeat this process for every subscription in the tenant. The PowerShell equivalent if you prefer that route: Get-AzRoleAssignment -SignInName compromised-user@company.com MITRE ATT&CK and Azure: Where Threat Actor Behavior Maps to the Cloud MITRE ATT&CK includes specific matrices for cloud environments with dedicated coverage for Azure across multiple matrices: Office 365, Azure AD, SaaS, and IaaS. These give you a structured way to categorize attacker behavior during an investigation. In practice, threat actors operating in Azure environments consistently focus on a predictable set of activities: Credential theft and verification — Attackers frequently test stolen credentials using legacy authentication protocols such as IMAP, which can bypass MFA. Mitigations: disable legacy auth protocols and enforce multi-factor authentication. Token theft — Rather than stealing user passwords, sophisticated attackers steal OAuth tokens that applications use to authenticate. These tokens can grant long-term access without triggering password-based alerts. Data collection — OneDrive, SharePoint, and Exchange are common targets for bulk data collection before exfiltration. Data exfiltration — Storage accounts are frequently used as staging grounds for data theft. The Graph API is another common exfiltration channel. Resource abuse — Cryptocurrency mining using compromised Azure subscriptions is extremely common. If you see unexpected VM deployments, especially high-compute instances, check for this immediately. 💡 Investigator Note: Microsoft has published a mapping of its built-in Azure security controls against MITRE ATT&CK techniques covering 48 controls. It is a useful reference when scoping the defensive posture of a client environment. Quick Reference: Azure Investigation Checklist Before diving into any Azure investigation, run through this mental checklist: Identify the tenant(s) involved — get the tenant ID and the associated domain Enumerate all subscriptions — do not assume you have been granted access to all of them Confirm your own permission level at each subscription — Owner is ideal Check for management groups — if present, policies applied there affect everything below Map out the resource groups — know which ones are relevant to the incident For key accounts (compromised users, service principals), enumerate role assignments across all subscriptions Old vs. New Terminology: What You Need to Know Throughout Microsoft documentation you will still see the term Azure Active Directory (AAD) used extensively. In October 2023, Microsoft renamed Azure Active Directory to Microsoft Entra ID. The functionality is completely identical — only the name changed. In the Azure Portal, the service now appears as 'Microsoft Entra ID'. When searching for it or referencing it in KQL queries, be aware that log table names and field names may still use 'AAD' in some places depending on when they were created. Understanding this architecture is not just background knowledge — it directly shapes where you look, what you ask for, and how you interpret what you find. In the next article, we will look at the four ways you can access Azure and, more importantly, what traces each access method leaves behind. We will Continue in next article --------------------------------------------------Dean---------------------------------------------------- Special Thanks I would like to extend my heartfelt gratitude to one of my dearest friend, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication! https://www.linkedin.com/in/iqrabintishafi/ ------------------------------------------------------------------------------------------------------------- Next Article: https://www.cyberengage.org/post/azure-architecture-first-15-commands-to-run-the-moment-you-get-access#

Hey everyone, First things first — I owe you an apology for going quiet. Life got a little hectic on the personal side and I had to step away for a bit, but I'm back now and planning to write and post a lot more frequently going forward. Good to be back. Before we get into today's topic, I want to mention something quickly — www.cyberengage.org/ started as just sharing knowledge, and honestly it's grown into something bigger than I expected. Because of that, I'm actually looking for writers who can contribute articles. If you're in writing for the blog, send me an email (apatel19800@gmail.com)— I'm happy to pay per article. --------------------------------------------------------------------------------------------------------- Now, let's get into it. If you've already read the complete cloud forensics guide — covering what artifacts to collect and how to investigate Box, Google Drive, and OneDrive — you know the foundation. If you haven't, go check that out first because today's article builds on it. https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques Today we're going a step further and talking specifically about collection — how you actually go about acquiring this data, what tools to use, what trips people up, and why cloud drive forensics is genuinely different from regular Windows acquisition. --------------------------------------------------------------------------------------------------------- First, Understand What You're Actually Dealing With Back in the early days, cloud drive apps were simple. They synced a local folder to the cloud. You wanted the files? Go to the folder, grab them, done. That's not how it works anymore. The new generation of cloud apps lets you see every file in your cloud drive — even ones that aren't actually downloaded to your machine. You browse them, interact with them, but they're not sitting on the local disk. They're ghosts. And that creates a real headache when it comes to collection. Here's how each of the big three handles it, because they all do it differently: OneDrive is the most straightforward. When a file is cached locally it's physically in the OneDrive folder and a forensic image will capture it. Files that are cloud-only won't be there, but OneDrive at least shows you a Status column — blue cloud icon for cloud-only, green checkmark for locally available. Box Drive is trickier. It uses something called a callback filesystem — essentially a reparse point that redirects all filesystem activity in the Box folder to a virtualized volume. If you image the C drive, the Box folder looks completely empty. If the user is logged out or the app isn't running, the Box folder won't even exist. Google Drive for Desktop takes it even further. It creates a virtual mount point but only when the app is running and the user is authenticated. And here's a fun wrinkle — the mounted filesystem is FAT32, which breaks some acquisition tools including KAPE in certain configurations. --------------------------------------------------------------------------------------------------------- So How Do You Actually Collect This Data? If you have access to a live system with the user logged in, tools like FTK Imager (use "Contents of a Folder") or KAPE can logically acquire whatever's in that virtualized filesystem. Requesting those files may also trigger the app to automatically download cloud-only files and cache them locally — which sounds helpful but comes with two serious caveats. First, automatically pulling files from the cloud could push you outside your legal scope of authority. Get legal guidance before you let that happen. Second, those newly downloaded files get written to the disk, potentially overwriting unallocated space that might hold deleted evidence. You gain files and lose evidence at the same time. Going straight to the cloud and acquiring directly from the cloud instance is often cleaner — but that needs credentials and the right tooling. And it's not always the better option. If the user was running encryption that keeps data encrypted in the cloud, the local copy — even if incomplete — might be the only readable version you'll ever get. Plan your acquisition strategy before you start. This is new territory and winging it will cost you. --------------------------------------------------------------------------------------------------------- KAPE for Cloud Storage Collection KAPE, written by Eric Zimmerman, handles cloud storage collection well when used correctly. Box, Dropbox, Google Drive, and OneDrive all have dedicated target files in the default KAPE installation. They're split into Metadata targets and UserFiles targets so you can grab just the database metadata without accidentally pulling gigabytes of user documents. The compound targets — CloudStorage_Metadata.tkape and CloudStorage_All.tkape — reference all the individual app targets at once. --------------------------------------------------------------------------------------------------------- API-Based Collection: Going Direct to the Cloud Every major cloud provider exposes an API and there are forensic tools built around them. Google Takeout lets the user (or investigator with credentials) download everything — Drive, Gmail, contacts, calendar, Chrome history. Data comes out zipped with the original folder hierarchy intact. Google Workspace adds Admin Data Export, which lets admins export everything for every user in the organization — though it's all or nothing, no filtering. F-Response is a commercial tool that supports all the major platforms. Add credentials and it writes the cloud content to a VHD or local share. Magnet AXIOM has extensive cloud support built in — OneDrive, Google, Dropbox, Box, iCloud and more. With Google Workspace admin credentials it can collect across an entire organization. When the API allows it, AXIOM also pulls usage logs. One thing that gets overlooked constantly — file version history. Many providers keep multiple versions and expose them via API. Google Drive is a good example. If you only need to dig into a few files, manually browsing the web interface while recording your screen is honestly sometimes the quickest option. --------------------------------------------------------------------------------------------------------- The Windows Artifacts You Still Shouldn't Skip Here's what's easy to forget when you're deep in cloud collection mode — the machine itself is still full of evidence. Browser history is often the first clue a cloud app was even in use. Cloud storage URLs are surprisingly rich. They can show file sharing activity, access to deleted items, version history browsing, specific files opened, searches conducted, and even the user's email embedded in URL parameters. LNK files can show you files that used to be in a cloud folder even if they're long gone. A LNK referencing a OneDrive path is evidence that file existed there. The Recycle Bin is worth checking specifically for cloud storage paths. Deleted items often end up here before being permanently removed. Registry searches for terms like "OneDrive", "Google Drive", "My Drive", "Dropbox", and "Box" across user hives can surface files and folders that were once accessed — including the drive letter Google Drive mounted its virtual filesystem on. Alternate Data Streams — Dropbox tags files with ADS markers. Copy that file anywhere within NTFS and the Dropbox fingerprint follows it. --------------------------------------------------------------------------------------------------------- Bottom Line Cloud drive forensics is complex because the apps themselves are designed to blur the line between local and cloud. The strategy that works for OneDrive won't work for Box. Legal scope gets murky the moment files start auto-downloading. Plan before you acquire, cross-reference the local artifacts with your cloud collection, and don't walk past the browser history and LNK files — they'll often tell you things the cloud API won't. --------------------------------------------Dean----------------------------------------------------------- As mentioned at the top — if you're a writer want to contribute to the blog, I'm paying per article. Send me an email and let's talk. And if you want to see the full cloud forensics guide covering what artifacts exist across Box, Google Drive, and OneDrive — that's linked below. https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques

So let's talk about something that doesn't get nearly enough attention in the digital forensics world — the FeatureUsage registry key. If you're investigating Windows systems and you're not checking this, you're genuinely leaving evidence on the table. ------------------------------------------------------------------------------------------------------------ Okay, But What Even Is FeatureUsage? FeatureUsage showed up in Windows 10 build 1903 and was first publicly reported by researcher Jai Minton. At its core, it's Windows quietly keeping tabs on how users interact with the taskbar and GUI applications — things like which apps were launched, how often they were in focus, how many notifications popped up, and even how many times someone right-clicked an icon. Now here's the part that makes investigators happy: this data doesn't disappear when an app gets uninstalled. That means if someone ran a VPN client, a privacy cleaner, or some sketchy chat app and then deleted it trying to cover their tracks? FeatureUsage still has the receipts. You'll find it sitting in the user's NTUSER.DAT file at: Since it's tied to individual user profiles, every user on the machine has their own copy of this data. ------------------------------------------------------------------------------------------------------------ The Subkeys You Actually Care About AppLaunch — "What Was Pinned and How Often Was It Clicked?" This one only tracks apps that were pinned to the taskbar — which is already telling you something useful. If an app is pinned, the user knew about it, used it enough to want it front and center, and actively kept it there. That's not an accident. Each pinned application shows up as a value, and the data field tells you exactly how many times that pinned shortcut was clicked to launch the app. Even if the user later unpinned it, the record stays. And because , you typically get the full file path — which is great for spotting apps running out of weird locations like temp folders or random AppData subdirectories. Malware loves hiding in unusual spots, and this key can expose that. AppSwitched — "Which Apps Were Actually Being Used?" While AppLaunch only covers pinned apps, AppSwitched casts a much wider net. This one tracks how many times any application became the active window — meaning keyboard input, mouse focus, the whole thing was directed at it. It even catches the original installer apps (think setup wizards), since those are GUI-based and require user focus to get through. In practice, you'll often see something like a browser absolutely dominating the count, which makes sense. AppBadgeUpdated — "How Many Notifications Did They Get?" This one tracks the notification badges that appear on taskbar icons — you know, like when your Slack icon shows "11 new messages." AppBadgeUpdated counts how many of those accumulated for each app. ShowJumpView — "Did They Right-Click and Dig Deeper?" When a user right-clicks a taskbar icon, they get a Jump List — quick access to recent files, saved sessions, frequent actions, etc. ShowJumpView counts how many times that happened per application. Here's a practical example: if Remote Desktop Connection shows 4 right-clicks in ShowJumpView, that strongly suggests the user was accessing saved RDP connections from the Jump List. Combine that with Jump List forensics and you've got a much richer picture of where they were connecting. TrayButtonClicked — The One People Always Forget This is the subkey that covers everything else on the taskbar — the clock, the Start button, the search box, Cortana, system tray widgets, all of it. And it's surprisingly powerful. Think about what the search box alone can tell you. If someone was running searches on a system, TrayButtonClicked will reflect that activity. Now imagine you're looking at a profile created during an attacker's RDP session — and you can see they were hammering the search functionality. That's a huge behavioral clue about what they were looking for on the machine. ------------------------------------------------------------------------------------------------------------ Why This Changes the Investigation? The thing that makes FeatureUsage genuinely powerful isn't any one subkey in isolation — it's the combination. You've got execution evidence even for uninstalled apps, focus and interaction evidence for everything GUI, passive engagement evidence even when apps weren't actively opened, deep interaction evidence through Jump List usage, and taskbar behavior evidence covering searches, clock use, and more. None of this gets wiped when someone uninstalls software and tries to clean up. That's a big deal. ------------------------------------------------------------------------------------------------------------ How to Use It Properly Cross-reference everything :- AppSwitched data hits different when you line it up against UserAssist and Prefetch. If all three are pointing at the same application, that's a strong execution timeline. Pay attention to deleted apps :- If AppLaunch shows a high execution count for a path that no longer exists on the system, something was there and it was used regularly before being removed. Sort by count :- High focus counts in AppSwitched = high user interaction. Start with the outliers. Watch for behavioral anomalies. A user who "never touches Jump Lists" but has 50+ right-clicks on a VPN shortcut? That tells a story. ------------------------------------------------------------------------------------------------------------ Bottom Line FeatureUsage tracks application usage at a granular level and survives uninstallations Use AppSwitched to counter "I never used that program" claims with hard numbers Use AppLaunch to find evidence of deleted or hidden applications Don't sleep on TrayButtonClicked — especially on attacker RDP profiles Always pair with Prefetch, BAM/DAM, and UserAssist for a full timeline ---------------------------------------------Dean-----------------------------------------------------------

Every craftsman will tell you the same thing — knowing your tools is half the battle. You could understand the Windows Registry inside and out, but if you're staring at raw hex dumps with no way to decode them, you're going to have a bad time. The good news? The forensic community has spent years building some genuinely excellent registry analysis tools. Some are free. Some cost money. Some have been around for a decade. One was practically rebuilt from scratch in a modern programming language. And one of them is, without much debate, the current gold standard. Let's walk through the lineup. ------------------------------------------------------------------------------------------------------------ The Main Players You don't need to use all of these. But you absolutely need to know  all of them — because the right tool depends on the job, the environment, and sometimes just what your employer's IT policy allows. ------------------------------------------------------------------------------------------------------------ The Concept Is King Before we go any deeper into Registry Explorer specifically, here's something worth burning into your brain: the tool is not what matters — the understanding is . This sounds like a motivational poster, but it's genuinely practical advice. Forensic tools change. Vendors stop updating. Better options emerge. If your entire skill set is muscle memory for one specific GUI, you're in trouble the moment that GUI isn't available. But if you deeply understand what  the registry contains and why  certain keys matter, you can pick up any tool — or even a raw hex editor in a pinch — and still do the job. That said, if you're going to master one tool, Registry Explorer is one of my favorite tool ------------------------------------------------------------------------------------------------------------ Registry Explorer — A Guided Tour Registry Explorer isn't just a registry viewer. It's closer to a full forensic workstation for registry analysis. Let's break down what you're actually looking at when you open it. ------------------------------------------------------------------------------------------------------------ Plugins: The Feature That Changes Everything Here's what separates Registry Explorer from a basic registry browser: plugins . Raw registry data is often encoded, compressed, or stored in binary formats that are completely unreadable to human eyes. A value might contain a list of recently opened files, but the raw bytes look like absolute gibberish. Plugins handle all of that decoding automatically. The moment you click on a key that Registry Explorer recognises — say, the Recent Documents key — a plugin silently fires in the background, decodes every value, and presents the results in a clean, sortable grid. No manual decoding. No looking up data formats. It just works. The best part? You didn't have to ask for it. The plugin system runs passively as you navigate. It's like having an expert sitting next to you who taps your shoulder every time something interesting appears. ------------------------------------------------------------------------------------------------------------ Searching Like a Pro The search functionality in Registry Explorer is where things get genuinely powerful for investigations. It isn't just a "Ctrl+F and hope for the best" situation. The Best way to use this find I have showed in USB Forensics Link below https://www.cyberengage.org/post/drive-letter-identification-and-volume-guid-and-user-mapping Complete USB Forensics: https://www.cyberengage.org/courses-1/usb-forensics ------------------------------------------------------------------------------------------------------------ Timeline Analysis — The Hidden Superpower One feature that doesn't get enough attention: the timestamp range search. It sounds mundane. It isn't. When you're responding to a compromise and you know roughly  when something bad happened, you can punch in a time window and ask Registry Explorer to show you every single key that was modified during that period — across all loaded hives simultaneously. Sort by timestamp, and suddenly you have a chronological trail of registry activity. You can watch a piece of malware establish persistence in real time, just from the registry's own timestamps. For root cause analysis — figuring out exactly what happened and in what order — this is genuinely one of the most powerful techniques available. And it's not a fancy add-on feature. It's just the search box with a date range. ------------------------------------------------------------------------------------------------------------ The Bookmarks Tab: Forensics on Rails For analysts who don't want to manually navigate to known-important registry locations every time, the Available Bookmarks  tab is a shortcut to every forensically relevant key across all loaded hives. Think of it as Registry Explorer's built-in list of "here's where the interesting stuff lives." Click a bookmark, land directly on the key, and the adjacent information panel updates with context. For newer analysts learning the ropes, this is an incredible guide to what the registry actually contains that matters. For experienced analysts, it's a time saver. ------------------------------------------------------------------------------------------------------------ The Honest Bottom Line If you only have time to learn one registry tool deeply, Registry Explorer is the right choice — not because the others aren't excellent, but because it covers the most ground, costs nothing, and is actively maintained by someone (Eric Zimmerman) who genuinely cares about the forensics community. But keep RegRipper in your back pocket. It's been running on real cases since before many current analysts were in the field, and its plugin library is a goldmine of institutional knowledge about what the registry contains and why it matters. Use the right tool. Understand the data. Never confuse the two. ------------------------------------------Dean-------------------------------------------------------------- Full series below: https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

For More detailed one check out below article: https://www.cyberengage.org/post/tracking-usb-activity-through-event-logs-every-plug-tells-a-story Windows Event Logs are an excellent resource for investigating USB-related activities. These logs provide insights into when devices are connected or disconnected, driver installations, user actions, and more. Let’s break this down in simple terms. ----------------------------------------------------------------------------------------------------- Key Logs to Monitor for USB Activity System Log (Plug and Play Events) When a new USB or Plug and Play device is connected, Windows installs a driver, logging Event ID 20001  (start of installation) and 20003  (completion of installation). These events include details like: Timestamp  (when the installation occurred) Device Information  (Vendor ID, Product ID, iSerialNumber) Installation Status  (e.g., 0x0 means no errors). Limitation : Modern W indows versions (10/11) often log only Event ID 20003 by default. Example Use : Correlate timestamps with user logins to identify who connected the device. Security Log (Audit Removable Storage) Event ID 4663  is logged when files or folders on a removable device are accessed, created, or modified. Tracks: User Account  performing the action. Action Type  (e.g., file creation, deletion, or read). Object Name  (the specific file or folder). Challenge : The log does not directly tie file operations to a specific device. Investigators must cross-reference with other logs or artifacts. Security Log (Audit Plug and Play Activity) Event ID 6416  records every time a Plug and Play device is added. Provides: Detailed device information (VID, PID, iSerialNumber, volume name). Benefit : Unlike System Logs, these events are recorded each time a device is connected. How to Enable : Configure the “Audit PNP Activity” option in Advanced Audit Policy Configuration. Microsoft-Windows-Partition/Diagnostic Log Tracks detailed removable device activity, including when a device is connected or disconnected. Often used alongside Event ID 6416 and 4663 for a complete timeline. ----------------------------------------------------------------------------------------------------- Additional Logs for Device Activity Microsoft-Windows-DriverFrameworks-UserMode/Operational Log Available by default in Windows 7, but must be enabled in later versions. Logs connection and removal of devices, allowing you to determine how long a device was connected. MBAM/Operational Log (Microsoft BitLocker Administration and Monitoring) Tracks the mounting and dismounting of removable devices. Includes the volume GUID , which can help correlate device activity with registry data ----------------------------------------------------------------------------------------------------- Setting Up Auditing for USB Devices To make the most of these logs, you need to configure Windows to track the necessary events: Enable Removable Storage Auditing : Go to Advanced Audit Policy Configuration > Object Access > Audit Removable Storage . Enable both Success  and Failure  auditing. Enable Plug and Play Activity Auditing : Under Advanced Audit Policy Configuration > Detailed Tracking , enable Audit PNP Activity . ----------------------------------------------------------------------------------------------------- Key Takeaways Use System Logs  for identifying the first-time connection of devices. Rely on Security Logs  for tracking file and folder operations. Combine Event IDs 4663, 6416, and 20003  to get a complete picture of device activity. Cross-reference logs with the Registry  or other artifacts like Prefetch data  to match devices with user actions. Enable auditing policies to ensure detailed logs are captured. By strategically leveraging these logs, investigators can gain valuable insights into USB usage, even in environments with limited historical data retention. --------------------------------------------------Dean--------------------------------------------------

So, I had previously created a quick summary about USB activity, but I got a lot of requests asking for a more detailed version. That’s exactly why I’m here with this updated article! I’ve tried to keep things simple while adding a bit more depth so it’s easier to understand and actually useful. If you’re curious to learn even more, don’t forget to check out the full USB forensics series as well — it covers everything in much greater detail.. USB activity summary Windows Event Logs for USB Activity https://www.cyberengage.org/post/windows-event-logs-for-usb-activity USB Forensic Series https://www.cyberengage.org/courses-1/usb-forensics ------------------------------------------------------------------------------------------------------ There's a moment in almost every data theft investigation where the question becomes: did they use a USB drive?  Not whether they could  have — whether they actually did , when, and what they put on it. Windows Event Logs answer that question in remarkable detail. Not from one log, and not from one event ID — but from a layered set of logging mechanisms that, used together, can reconstruct every removable device interaction down to the individual file that was copied. The challenge is knowing which logs to pull, which event IDs matter, and how to connect the dots between them. ------------------------------------------------------------------------------------------------------ Let's walk through the whole picture. The Logging Ecosystem Before diving into specific events, it's worth understanding that USB forensics in Windows isn't a single artifact — it's a collaboration between three different log sources, each with different strengths and coverage ------------------------------------------------------------------------------------------------------------ The System Log: First Impressions Only The simplest entry point into USB forensics is the System log. When any new Plug and Play device connects and Windows tries to install a driver for it, Event IDs 20001 and 20003 fire — and they carry the device's identifying information including its serial number. The critical caveat: These events only fire for the first  connection of a specific device. Once the driver is installed, subsequent connections don't trigger new Plug and Play install events. So the System log tells you the device was ever  connected, and gives you the exact timestamp of that first introduction — but goes silent for every repeat visit. One important gap: The user account logged in at the time of device insertion isn't included in the Plug and Play events themselves. To connect a device to a user, you need to correlate the event timestamp with logon events in the Security log — or with USB registry artifacts that do tie connections to user sessions. Modern Windows (recent Win10 and Win11 builds) has shifted toward logging only EID 20003 by default, skipping 20001 entirely. ***Check both when analyzing a system, and don't assume absence of 20001 means no device was connected.**** ------------------------------------------------------------------------------------------------------------ The Security Log: Where Files Get Named If the System log tells you that  a device was connected , the Security log — when properly configured — tells you what happened on it . This is the capability that transforms USB forensics from "a device was plugged in" to "this user copied this specific file to this device at this exact time." Two audit settings unlock this capability: Audit Removable Storage  (EID 4663) — records every interaction with a removable device: files read, files written, files deleted, even attribute changes. Each event names the user account, the process responsible, and the operation type. The limitation is significant: The device is identified by a volume path like \Device\HardDiskVolume9\  rather than by serial number. You have to cross-reference with other artifacts to know which  device that volume path corresponds to. Audit PNP Activity  (EID 6416, Win10+) — records every device connection with full hardware identifiers: Vendor ID, Product ID, and iSerialNumber. Unlike the System log, this fires on every  connection, not just the first. And because it lives in the Security log, it's far more likely to have been captured by enterprise SIEM infrastructure than System log events. Neither is on by default. Finding them populated on a system you're investigating means someone proactively configured auditing — which itself tells you something about the environment's security posture. ------------------------------------------------------------------------------------------------------------ Connecting the Dots: A Real Scenario Here's how these events work together in practice. Two events, same device, four minutes apart — and between them, a complete picture of what happened. The Volume Path Problem Here's the gap in the middle of this whole system that you need to know about: EID 4663 doesn't include a device serial number . It identifies the device by its assigned volume path — something like \Device\HardDiskVolume9\ — which is a runtime assignment that changes every time the device is plugged in. This means if you only have EID 4663 events and no 6416 events, you can see file operations on a removable device but you can't definitively identify which  physical device it was without external help. The solution is correlation: Match the EID 4663 timestamp with a contemporaneous EID 6416 event showing the same volume path — that gives you the serial number Cross-reference with USB registry artifacts like USBSTOR and MountedDevices to confirm the device identity Once the volume path is tied to a physical device, every other EID 4663 event using that same path and Logon ID during that session can be attributed to the same device connection Once that link is established for a session, the Logon ID in EID 4663 events lets you track every single file operation that user performed on that device for the duration of their session ------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------ The Access Type Dictionary When EID 4663 fires, the Accesses field tells you what operation the user performed on the device. This field uses Windows access right terminology that can seem cryptic at first: AppendData  — a new file was written to the device. This is the exfiltration indicator. Data was copied to  the drive. ReadData  — a file on the device was read. Data was accessed from  the drive. Delete  — a file on the device was deleted. WriteData  — an existing file was modified. SYNCHRONIZE  — a standard access right that accompanies most operations; not meaningful on its own. The Process Name field is equally useful. explorer.exe means a human dragged and dropped or copy-pasted through the GUI. cmd.exe means command-line operation. robocopy.exe or xcopy.exe means a scripted or bulk copy. The process name tells you how  the transfer happened — and sometimes, whether it looks deliberate and scripted or like normal user behavior. ------------------------------------------------------------------------------------------------------------ The Big Picture USB forensics from event logs is a layered discipline. No single event ID gives you everything. But stack them correctly — 6416 to identify the device, 4663 to track the files, correlation with logon events to tie it to a user — and you can build a minute-by-minute record of every removable device interaction on a machine. That's not circumstantial. That's a chain of evidence built entirely from logs the operating system generated for its own purposes, long before anyone suspected they'd need to be reviewed.# ------------------------------------------------------------Dean--------------------

Part 1: https://www.cyberengage.org/post/meet-the-ce-sentinelone-assistant-i-built-it-for-myself-but-you-can-try-it-too 1. DFIR Investigation Tab The DFIR Investigation tab is the biggest addition to the CE S1 Assistant since launch. It takes a completely different approach to the problem — instead of helping you write queries to find things, it analyses logs you already have. Here is the workflow it was built around. You get an alert. You open SentinelOne Deep Visibility and run a query across the affected endpoint. You export the results as a JSON file. You upload that file to the DFIR tab. The tool processes it, anonymises all sensitive data, validates the result. You get a full incident report back — verdict, confidence, attack chain, indicators, immediate actions. The analysis that used to take an analyst an hour or two of manually correlating events gets done in seconds. And because the data is anonymized before it leaves your browser session, you can run it against real incident data without exposing confidential information. What the Upload Does? When you upload a Deep Visibility JSON export, the tool runs through four stages . These stages happen automatically — you do not configure them. Stage What Happens 1. Load & Parse Reads your JSON file. Handles both raw array exports and wrapped exports. Detects multi-endpoint files early. 2. Anonymise Replaces real usernames, hostnames, internal IPs, and client names with numbered labels (USER-001, ENDPOINT-001, etc.). Catches names anywhere they appear — in file paths, command lines, process names. 3. Validate Scans every field of every event for any real value that survived anonymisation. If anything is found, the submission is blocked and you are told exactly what needs fixing. 4. Build Brief Constructs a structured incident brief from the cleaned data — process timeline, DNS activity, network connections, file operations, and SentinelOne behavioural indicators — then sends it for analysis. The Anonymisation System — Why It Matters? This is the part I want to explain in detail because it is the part most people do not expect. When you are dealing with a real incident, the logs contain real data. Real names in file paths. Real hostnames. Confidential things in process arguments or script variables. If you paste that directly I, you have just sent potentially sensitive personal and business data. The anonymisation system I built specifically to prevent that. What Gets Replaced? Usernames — replaced with USER-001, USER-002, etc. (consistent across the entire file) Endpoint hostnames — replaced with ENDPOINT-001, ENDPOINT-002, etc. Internal IP addresses — replaced with INTERNAL-IP-001, INTERNAL-IP-002, etc. Company names — replaced with COMPANY-001 fragments (you specify these if needed) Credentials found in command lines — Bearer tokens, passwords, API keys — replaced with [REDACTED-CRED] Cloud keys — AWS AKIA keys, Azure AccountKey, api_key= values — replaced with [REDACTED-CLOUD-KEY] The replacement is case-insensitive and not path-based. If a username appears anywhere — in a fie path, in a process name, in a command line argument, in a script parameter — it gets caught and replaced. This works on macOS paths, Windows paths, and Linux paths without any configuration. The Validation Block? After anonymization, the tool runs a separate validation pass before it will allow the data to be analyzed . It scans every field of every event for any real value that survived — case-insensitively. Hard Block:  If any real username, hostname, or company name fragment is found anywhere in the cleaned data, the submission is blocked entirely. You see a list of exactly which values were found and in which events. This is not a warning — it is a hard block. The data does not move until the validation passes. This is deliberate. What You See in the UI? After upload and anonymisation, the tool shows you a summary panel before it runs the investigation: How many events were in the file What was replaced — a map of real name → anonymised label (visible in your browser only, never stored, gone on refresh) Event type breakdown — how many Process Creation, DNS, Network, File events Any behavioural indicators SentinelOne flagged in the raw data Any warnings (e.g. a hostname that looks like it might be a client machine) The real values shown in the mapping panel exist only in your browser session. They are never sent anywhere, never logged, and disappear when you refresh the page. What the Investigation Report Contains? Once the brief is built and validated, investigation starts. The report that comes back is structured into specific sections: Attack Chain — chronological reconstruction of what happened, from first event to last observed Indicators of Compromise — hashes, IPs, domains, file paths, process names extracted directly from the logs MITRE ATT&CK Techniques — technique IDs and names mapped to observed behaviours Additional Logs Needed — if the log window was too short or missing event types, the report flags what you should pull next Verdict — MALICIOUS / SUSPICIOUS / FALSE POSITIVE / INCONCLUSIVE Confidence — percentage confidence in the verdict with reasoning Key Findings — the three to five most important things the analysis found ------------------------------------------------------------------------------------------------------------- 2. Three Investigation Modes The DFIR tab does not do one thing. It has three distinct investigation modes because different situations call for different approaches. You select the mode before submitting. Mode 1 — Full Investigation Use this when you want the complete picture. You do not know yet what happened, or you want confirmation of what you suspect. You upload the JSON and let the tool do the full sweep. What it does: Builds a complete incident brief from all events in the file Perform full DFIR investigation. Returns the structured report covering attack chain, IOCs, techniques, verdict, and actions Best for: ·         New alerts where you do not yet know the scope ·         Confirming or ruling out a suspected compromise ·         Generating a report you can share with the team or document in a ticket Mode 2 — Targeted (Ask a Question) Use this when you have a specific question about the incident and you do not need the full report. You upload the same JSON, type your question, and the tool pulls out only the events relevant to that question. Examples of targeted questions: "Was there any lateral movement in this data?" "What persistence mechanisms were set up on this endpoint?" "Did the suspicious process make any outbound connections?" "Was there any credential access activity?" "Did anything run from a temp directory?" Instead of analysing the full event timeline, the tool uses a separate extraction function that filters and summarises only the events that are relevant to your specific question. This makes the response faster, more focused. The answer format is always: ·         YES / NO / CANNOT DETERMINE — a direct answer to your question ·         Evidence — the specific events that support the answer ·         Context — what those events actually mean in terms of attacker behaviour Mode 3 — IOC Hunt Use this when you have a list of IOCs — from a threat report, from a feed, from another analyst — and you want to know if any of them appear in your log data. You do not need a question. You just give it the IOCs and it tells you what matched. Input format — one IOC per line, any mix of: SHA256 / SHA1 / MD5 hashes IP addresses Domains and URLs (defanging is handled automatically — hxxp becomes http, [.] becomes ) File paths Process names Keywords What you get back for each IOC: ·         FOUND or NOT FOUND ·         How many times it appeared in the log data ·         First seen and last seen timestamps ·         Which processes were associated with it ·         Classification — TRUE POSITIVE / FALSE POSITIVE / SUSPICIOUS This mode direct pattern scan against the event data. ------------------------------------------------------------------------------------------------------------- 3. Follow-up Chat After an investigation runs — in any mode — there is a chat panel directly below the results. You can keep asking questions about the same incident without re-uploading anything. The way this works is important. The context from the investigation — the anonymised brief, the original report, the IOC list if you ran an IOC hunt — is carried forward into the conversation. What You Can Ask The follow-up chat is not a general assistant. It is grounded in the incident data from your upload. Things it handles well: Expanding on something in the report — "tell me more about that bypass" Asking about specific techniques — "what does xattr -c actually do and why does it matter?" Asking for a query based on findings — "give me an S1QL query to hunt for this on other endpoints" Asking about a specific IOC — "what is the typical behaviour associated with this process name?" Asking about next steps — "what else should I pull to confirm lateral movement?" Asking for a summary in a specific format — "summarise this for a non-technical stakeholder" Session Behaviour The conversation context resets if you upload a new file or refresh the page There is no history saved from the chat — if you need to keep something, copy it before navigating away ------------------------------------------------------------------------------------------------------------- 4. Sigma Rule Library Sigma is the universal detection rule format for the security community. Rules written in Sigma describe attacker behaviour in a way that can theoretically be converted to any SIEM or EDR query language. There are thousands of community-contributed Sigma rules covering almost every known attack technique. The problem for SentinelOne users is that Sigma rules need to be converted to S1QL before you can use them in Deep Visibility. The field names are different. The operators are different. Sigma uses logsource categories that need to be mapped to SentinelOne event types. Getting it right manually takes time and good knowledge of both formats. The Sigma Rule Library solves this in two ways. Part 1 — Pre-Converted Community Rules The library contains Sigma rules from the upstream community repository that have already been converted to S1QL and verified to work. You browse, filter, find what you need, and copy the query directly. Filter options: Platform — Windows, Linux, macOS, or all Severity — Critical, High, Medium, Low Status — Verified, Unverified, Failed (so you know which ones have been tested) MITRE ATT&CK tactic and technique Free text search across rule titles and descriptions Each rule card shows the Sigma rule title, the mapped MITRE technique, the severity level, the platform, and the converted S1QL query. You can expand the card to see the full query and copy it with one click. The library syncs from the upstream Sigma repository automatically, so it stays current as new community rules are released. Part 2 — Custom Sigma Converter This is the part I find most useful day to day. You paste any Sigma YAML — a rule from GitHub, a rule from a threat report, a rule a colleague sent you, or one you wrote yourself — and the tool converts it to S1QL immediately. What the converter handles: Field name mapping — Sigma's Image Logsource translation — mapped to S1 event types Operator conversion — contains, startswith, endswith, re translated to S1QL equivalents Detection logic — all, any, not conditions preserved in the S1QL output Validation — tells you if any part of the rule cannot be translated and why Why this matters:  Every time a new threat report drops with a Sigma detection rule attached, you no longer need to manually work out the S1QL translation. Paste it in, get the query, start hunting. The field mapping knowledge that used to live in your head is now handled automatically. ------------------------------------------------------------------------------------------------------------- 5. Query Feedback System In the original launch article I mentioned a feedback system was coming. It is live now. The problem it solves is straightforward. The natural language query generator is good, but it is not perfect. Sometimes a query comes back with a wrong field name. Sometimes the operator is right but the filter logic is off. Sometimes the query works technically but misses what the analyst actually needed. Before the feedback system, those issues would disappear. I would edit the query manually and move on. Nobody would know the generator got it wrong, and the same mistake would happen again for the next person who asked a similar question. How It Works — Analyst Side Every generated query now has a flag button next to it. If the query does not work — or does not do what you expected — you click it. You are asked two things: ·         What was wrong with the query? ·         What did you actually need? That feedback, along with the original input and the generated query, gets submitted and shows up in the admin review panel. You do not need to do anything else. How It Works — Admin Side The admin panel has a dedicated Feedback section that shows every submission. For each one you can see: The original natural language input the analyst typed The query the tool generated The feedback text explaining what was wrong Status — Pending, Reviewed, or Dismissed Submission timestamp Why This Matters Long-Term The quality of the query generator improves over time because the failure signals are visible. Without feedback, you are flying blind — you know the tool is not perfect but you do not know where or why. With the feedback system, you see exactly which inputs produce bad outputs and you can fix the prompt or the field schema specifically for those cases. ----------------------------------------------------Dean---------------------------------------------------- I'm still working on a fully offline, self-hosted version — something you can spin up yourself on your own machine. No cloud, no dependencies. It's not ready yet but I'm heads down on it — watch this space.

Press Windows + R. Type something. Hit Enter. That's it — that's the entire user interaction. What happens in the registry afterward is far more interesting. The Run dialog  has existed since Windows XP and hasn't changed much since. It's the power user's shortcut — a quick way to launch applications, open specific paths, fire up system tools, or connect to network resources without touching a mouse. Most casual users have never opened it. The ones who have tend to use it constantly . And that habit leaves a very clean trail. ------------------------------------------------------------------------------------------------------------ Why This Key Matters The Run dialog skews heavily toward technically proficient users — administrators, power users, developers, and, notably, attackers operating on a compromised machine. Someone who knows to press Win+R and type \\192.168.1.1\c$ to map a network share, or regedit to open the registry editor, or cmd /k whoami to check their privilege level — that's not an accidental user. That's someone who knows exactly what they're doing. Every command typed into that dialog gets preserved at: NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU The key maintains a full MRU list — most recent entry at position 0, with the Last Write Time of the key anchoring precisely when that most recent command was typed. Everything else in the list is ordered by recency, giving you a sequenced history of every Run dialog command this user ever typed on this machine. ------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------ Reading the List Like an Analyst The MRU ordering is your friend here. Position 0 is the most recent command — timestamped. Everything below it is ordered from most to least recent, giving you a behavioral sequence even without individual timestamps. That sequence is often more revealing than any single entry. A list that shows notepad → calc → explorer is a normal user having a normal day. A list that shows powershell -ep bypass -w hidden → cmd /k whoami /priv → \\192.168.1.50\c$ → regedit is someone working through a deliberate playbook. Commands worth flagging immediately: UNC paths (\\hostname\share or \\IP\share) — direct navigation to network resources PowerShell with execution policy bypass flags or hidden window arguments whoami, net user, net localgroup — reconnaissance commands runas — privilege escalation attempts Registry paths typed directly — someone who knows exactly where they're going in the registry Remote management tools — mstsc, psexec, wmic The Run dialog is a power user feature. When you find it populated with sophisticated commands, you're not dealing with someone who stumbled onto the machine. You're dealing with someone who knew exactly what to type — and left every keystroke in the registry for you to find. ---------------------------------------------Dean-------------------------------------------------------- Full Registry forensic Series: https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

Windows has a dirty little secret. Every time you double-click an application, launch something from your taskbar, or open a file through the Start Menu, a registry key quietly takes notes. It records what you ran, how many times you ran it, when you last ran it, and — most fascinatingly — how long that application actually had your attention. That key is UserAssist . And it was never designed for forensics. It was designed to make your Start Menu smarter. The fact that it became one of the most powerful execution-tracking artifacts in Windows forensics is a beautiful accident. ------------------------------------------------------------------------------------------------------------- What UserAssist Actually Is UserAssist exists to populate the "most frequently used applications" list in the Windows Start Menu. To do that job, it needs to track GUI-based application launches — and it does so with remarkable granularity. The critical word there is GUI . UserAssist has no interest in: Background processes running silently Anything executed from a command terminal Scheduled tasks firing without user interaction If a human clicked something on screen and a window appeared, UserAssist probably knows about it. If a script ran in the dark, UserAssist missed it entirely. This scope limitation is important — it means UserAssist tells you specifically about human interaction , which is exactly what makes it so valuable. The key lives per-user in NTUSER.DAT : NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\ ------------------------------------------------------------------------------------------------------------- The Focus Time and Focus Count fields deserve special attention. Every other execution artifact tells you an application ran . UserAssist also tells you whether someone actually used it . An application that launched and immediately crashed will have a run count but near-zero focus time. An application that someone spent three hours inside will have substantial focus time. That distinction matters enormously in both insider threat and malware investigations. ------------------------------------------------------------------------------------------------------------- The GUID Problem — and Why It Actually Helps Here's where UserAssist gets architecturally interesting. The data isn't stored in one flat list. It's organized under subkeys named with GUIDs — each representing a different method  of launching the application. Most of these GUIDs are ghost towns. Users don't launch software through exotic methods, so those subkeys stay empty. Two GUIDs do almost all the heavy lifting: CEBFF5CD-ACE2-4F4F-9178-9926F41749EA   → Tracks applications executed   directly via .exe files  (e.g., double-clicking a program). F4E57C4B-2036-45F0-A9AB-443BCFE33D9F   → Tracks applications executed   via shortcuts  (e.g., Start Menu, taskbar, desktop shortcuts). ------------------------------------------------------------------------------------------------------------- Why It's So Hard to Read Raw The developers of UserAssist went out of their way to make it painful to analyze manually — and nobody quite knows why. The obstacles stack up: Application names are ROT-13 encoded  — a simple substitution cipher where each letter shifts 13 places. Paths use KNOWNFOLDERID aliases  instead of real folder paths — {6D809377-6AF0-444B-8957-A3773F02200E} instead of C:\Program Files\. These are documented but add a decoding step. All the actual execution data  — run count, focus time, last run time — lives in binary blobs at specific byte offsets within each value. In practice, nobody reads UserAssist raw. Registry Explorer's UserAssist plugin handles all decoding automatically — ROT-13, KNOWNFOLDERID mapping, and binary blob parsing — and presents clean, sortable, filterable output. But understanding what's happening under the hood means you can validate findings when it matters. ------------------------------------------------------------------------------------------------------------- The Accuracy Problem Nobody Talks About Enough Here's the uncomfortable truth about UserAssist: it's unreliable enough that you should never use it as a sole source of truth. The degradation in data quality from Windows XP through modern Windows 10/11 has been consistently documented, and specific quirks make overconfident claims dangerous: ------------------------------------------------------------------------------------------------------------- What to Actually Look For When you load UserAssist into Registry Explorer and the plugin decodes everything, you're looking at a sortable table of every GUI application this user ever launched. Here's how experienced analysts work through it: Sort by Last Run Time  to find what was running around your investigation window — this is almost always the first sort you do Filter by Program Name  when you have a specific application in mind — encryption tools, remote access software, data exfiltration utilities Sort by Run Count  to understand the user's baseline habits — legitimate heavy users show high counts for office apps and browsers; anything with a high count that shouldn't be there is a flag Sort by Focus Time  to find what the user was actually doing  rather than just what was open — the application with the most accumulated focus time is where this person spent their day Watch for remote access tools  — AnyDesk, TeamViewer, ngrok, Cobalt Strike — appearing in either GUID tells you a human ran a remote access capability on this machine Watch for admin tools  appearing on a non-admin user's machine — registry editors, process monitors, privilege escalation utilities ------------------------------------------------------------------------------------------------------------- The Bottom Line UserAssist is complicated, imperfect, and worth every minute you spend learning it. No other single registry artifact gives you focus time. No other artifact can tell you not just that an application ran, but that a person sat there using it  for a specific accumulated duration. The quirks and limitations aren't reasons to avoid it — they're reasons to understand it deeply. An analyst who knows UserAssist's failure modes can use it confidently. One who doesn't might stake a case on a run count that Windows quietly reset during the last Patch Tuesday. Use it as a compass. Let the other execution artifacts be your map. ------------------------------------Dean--------------------------------------------------------- Complete Series Below https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A