DEV Community: Clear Path Security Ltd

Risks of hard-coded secrets in software

Clear Path Security Ltd — Wed, 23 Sep 2026 14:13:59 +0000

Originally published on the ClearPath Security site: https://clearpathsecurity.co.uk/risks-of-hard-coded-secrets-in-software/

Risks of hard-coded secrets in software

For many UK SMEs, software is now part of day-to-day business operations, whether it supports sales, customer service, finance, or operations. That makes the way software is built and maintained a business issue, not just a technical one. One of the most common and avoidable mistakes is putting secrets directly into code or related files.

A secret is any value that should stay private because it gives access to something valuable. That might be a password, an application token, an API key, or a connection string. If that information is written into software and later exposed, the impact can spread well beyond the original mistake. It can affect customers, suppliers, revenue, and reputation.

This article explains the risks of hard-coded secrets in software in plain English, where they usually appear, how they get exposed, and what SMEs can do to reduce the risk without slowing delivery.

Key takeaways

Hard-coded secrets can expose multiple systems at once, turning a small coding mistake into a wider business incident.
The main risks are downtime, fraud, data loss, and reputational damage if a secret is copied or exposed.
Keep secrets out of code, store them in a dedicated secrets manager, and limit who can access them.
Rotate any secret that may have been exposed and remove credentials that are no longer needed.

What hard-coded secrets are and why they matter

Simple definition in plain English

Hard-coded secrets are private values written directly into source code, scripts, or configuration files instead of being stored securely elsewhere. In practice, that means the secret is fixed in the software itself rather than being supplied safely when the software runs.

This is risky because code is often copied, shared, reviewed, backed up, and deployed in many places. Once a secret is embedded in that flow, it becomes much harder to control. Even if the code is later changed, older copies may still exist in repositories, backups, test systems, or developer machines.

Common examples in business software

In an SME environment, hard-coded secrets often include:

Passwords for databases or admin accounts
Application keys used to connect to cloud services
Tokens for payment, messaging, or customer support tools
Certificates or private keys used to prove identity between systems
Test credentials left in scripts or sample files

These values are often added for convenience during development, then forgotten. The problem is not only that they are visible in code. It is that they are easy to copy into other places and difficult to track once they have spread.

Why hard-coded secrets create business risk

How one exposed secret can affect multiple systems

A single exposed secret can open the door to more than one system. For example, one application token might allow access to a cloud platform, a database, and a third-party service. If that token is reused across environments, the same mistake can affect development, testing, and live systems at the same time.

That is why hard-coded secrets are not just a coding issue. They can become a route into core business services. If an attacker or unauthorised user finds one secret, they may be able to use it to reach other connected systems that trust it.

Likely business impacts: downtime, fraud, data loss, and reputation damage

The business impact depends on what the secret protects, but common outcomes include:

Service disruption if systems have to be shut down or rebuilt
Fraud or misuse if a payment or account token is abused
Data loss or unauthorised access if a database credential is exposed
Customer concern if sensitive information is accessed or leaked
Reputational damage if the issue becomes public or affects a client

For an SME, even a short interruption can be costly. Staff may lose time investigating the issue, customers may be unable to use a service, and the business may need urgent support from developers or external specialists. If the secret is tied to a supplier or customer integration, the problem can also affect relationships and contract confidence.

Hard-coded secrets can also create a false sense of security. A team may believe a system is protected because access is limited in one place, while the same secret is sitting in plain text elsewhere. That is why secure development needs to be treated as part of business risk management. If you are building or buying software, it is worth considering the wider secure development approach described in Secure Software Development – Why It Matters.

Where hard-coded secrets usually appear

Source code and configuration files

The most obvious place is source code. Developers may place a password, token, or key directly in a file so the software works quickly during testing. Configuration files are another common location, especially where teams want to keep settings separate from the main code but still store them in the same project.

This is especially common in small teams where people wear multiple hats and deadlines are tight. The issue is understandable, but it should not become normal practice. If secrets are in code or configuration files, they are more likely to be copied, committed to version control, or shared with others who do not need them.

Scripts, build pipelines, and test environments

Secrets also appear in scripts used to deploy software, run tests, or connect systems together. Build pipelines can be another weak point if credentials are added directly into automated steps. Test environments are particularly risky because people often treat them as temporary and less sensitive, even though they may still contain real data or access to real services.

It is also common for teams to use the same secret in more than one place because it is easier to manage in the short term. That convenience can create a bigger problem later, because one exposed value may affect several environments at once.

How secrets get exposed in real-world operations

Shared code repositories and copied files

Secrets are often exposed through everyday working habits rather than a dramatic attack. A file may be copied into a shared folder, checked into a code repository, or sent to a colleague for troubleshooting. Once that happens, the secret may be visible to more people than intended.

Version control systems can make this worse because they keep a history of changes. Even if a secret is removed from the latest version, it may still exist in earlier commits or branches. That means the problem can remain long after the team thinks it has been fixed.

Backups, logs, and developer workstations

Backups can preserve secrets that were supposed to be temporary. Logs may also capture values that were never meant to be recorded, especially if an application prints configuration details during startup or error handling. Developer workstations are another common exposure point because they often contain local copies of code, test files, and credentials.

For SMEs, this matters because the same small set of people often manage development, deployment, and support. That makes it easier for secrets to spread across laptops, shared drives, and cloud tools without anyone noticing. Good control is less about blame and more about reducing the number of places where a secret can live.

What attackers or unauthorised users can do with exposed secrets

Access cloud services, databases, or third-party tools

If a secret is exposed, it may allow access to cloud services, databases, messaging platforms, payment systems, or customer support tools. The exact impact depends on the permissions attached to the secret. Even a limited account can still be useful if it provides a starting point into a wider environment.

Unauthorised access is not always obvious at first. A stolen token may be used quietly, or a password may be tested later. That delay can make the issue harder to spot and investigate.

Move through connected systems or misuse trusted integrations

Many business systems are connected through trusted integrations. That is useful for efficiency, but it also means one exposed secret can be used to move between systems that trust each other. An attacker may not need to break in through the front door if a trusted connection is already available.

This is one reason why hard-coded secrets are so important to address early. They can turn a small mistake into a wider incident because they sit at the point where systems, suppliers, and business processes meet. If your organisation relies heavily on third-party tools, it is also worth reviewing the broader supply chain angle in How third-party software introduces cyber risk for UK SMEs.

How to reduce the risk without slowing delivery

Use a dedicated secrets manager instead of storing values in code

The safest approach is to keep secrets out of code and store them in a dedicated secrets manager. This is a secure place designed to hold private values and provide them to applications when needed. The software then reads the secret at run time rather than carrying it around in the codebase.

For SMEs, the important point is not the brand of tool. It is the principle. Keep secrets in one controlled place, limit who can view them, and make sure applications only receive the access they need. If you are building this capability, our guide to secrets management using key vaults and HSMs explains the practical options in more detail.

Limit access, rotate secrets, and remove unused credentials

Access should be restricted to the smallest practical group of people and systems. Not every developer, tester, or contractor needs access to every secret. If a secret is no longer needed, remove it. If it may have been exposed, change it quickly. This is often called rotation, which simply means replacing the old value with a new one.

It is also sensible to review whether some secrets are still in use at all. SMEs often keep old credentials around because nobody wants to break a live integration. A regular review helps remove forgotten accounts and reduces the number of places an attacker could try.

Practical checks for SMEs

Review code, repositories, and deployment scripts

A practical first step is to look for secrets in the places where they are most likely to hide. Check source code, configuration files, deployment scripts, and any shared repository used by the team. Pay attention to old branches, sample files, and test data as well as the main application code.

It is worth making this a routine check rather than a one-off clean-up. Secrets can slip back in when teams are under pressure, especially during urgent fixes or new releases.

Check who can access secrets and how often they are changed

Ask three simple questions:

Who can see each secret?
Where is it stored?
When was it last changed?

If the answer is unclear, that is a sign the process needs tightening. You do not need a large security programme to improve this. Many SMEs can make meaningful progress by tightening access, documenting where secrets live, and setting a regular review cycle.

If your team is still building secure development habits, it may help to revisit the basics in Secure coding principles explained for product teams and then add simple checks into everyday delivery.

A simple action plan for teams

Find and replace hard-coded secrets

Start by identifying where secrets are currently stored. Replace hard-coded values with secure references to a secrets manager or another controlled storage method. Remove old copies from code, scripts, and test files where possible.

Then rotate any secret that may already have been exposed. If a value has been in code, in a shared file, or in a public repository, assume it should be treated as compromised until proven otherwise. That is a cautious but sensible position for business protection.

Set rules for secure storage and handling going forward

Once the immediate clean-up is done, set a simple rule: secrets must not be stored in code. Back that up with a practical process for storing, approving, and changing them. Make sure developers, contractors, and anyone who deploys software understands the rule and knows where to put secrets instead.

It also helps to add a basic check before release, so secrets are spotted before software goes live. For growing teams, that kind of control is often more effective than relying on memory or good intentions.

When to get outside help

If secrets are spread across multiple systems

If you suspect secrets are already spread across code, repositories, backups, and cloud tools, it may be difficult to clean up safely without help. The main challenge is not just finding the secrets. It is understanding which ones are still active, which systems depend on them, and what needs to be changed first.

Outside support can help you reduce the risk in a structured way and avoid accidental disruption to live services. That is often useful when the business depends on a small number of people who already have full workloads.

If you need help improving secure development practices

If hard-coded secrets are only one part of a wider development issue, it may be time to improve the overall secure development process. That can include clearer rules for code review, safer release steps, better access control, and more consistent handling of sensitive information.

For SMEs that want a practical, risk-based approach, external advice can help turn a one-off fix into a repeatable way of working. If that would be useful, you can speak to a consultant for support tailored to your environment.

Conclusion

Hard-coded secrets are easy to overlook because they often start as a convenience. The business risk appears later, when those secrets are copied, exposed, or reused in more places than intended. At that point, a small coding shortcut can become a wider incident involving downtime, fraud, data loss, or reputational harm.

For UK SMEs, the most practical response is straightforward. Keep secrets out of code, store them in a dedicated secrets manager, limit access, rotate them when needed, and build simple checks into everyday development and release work. Those steps do not need to be complicated to be effective.

If you want help reviewing your current approach or improving secure development practices across your team, a short conversation with an experienced adviser can be a sensible place to start.

Frequently asked questions

What is the meaning of risk?

Risk is the chance that something bad will happen and the impact it would have if it does. In software, that usually means asking how likely a problem is and how much it could cost the business.

What are examples of risk in software?

Examples include exposed passwords, insecure data handling, service outages, unauthorised access, and software defects that affect customers or operations. Hard-coded secrets are a good example because they can create several of these problems at once.

Detecting OAuth consent phishing in Microsoft 365 audit logs

Clear Path Security Ltd — Wed, 23 Sep 2026 14:13:56 +0000

Originally published on the ClearPath Security site: https://clearpathsecurity.co.uk/detecting-oauth-consent-phishing-in-microsoft-365-audit-logs/

OAuth consent phishing is a practical identity attack that abuses the trust users place in application consent prompts. Instead of stealing a password directly, the attacker persuades a user to grant a malicious app access to mailbox data, profile information, files, or other Microsoft 365 resources. Once consent is granted, the app can keep operating until the grant is removed, which makes this a persistence mechanism as well as an initial access technique.

For UK SMEs, the risk is less about a headline-grabbing breach and more about quiet abuse of normal business workflows. A compromised mailbox can be used for invoice fraud, internal phishing, data theft, or follow-on access to other cloud services. The good news is that Microsoft 365 and Entra ID provide enough telemetry to detect many of these cases if you know which events and fields matter, and if you treat consent activity as a first-class detection problem rather than a one-off admin task.

Key takeaways

Detect OAuth consent phishing by correlating consent grants, service principal changes, and sign-in activity, not by relying on one log source.
Treat first-seen applications, unusual permission scopes, and consent from unexpected users or locations as high-value hunting signals.
Revoke malicious grants quickly, disable the application or service principal, and review mailbox access and token use for follow-on abuse.
Reduce future risk by restricting user consent, using admin consent workflows, and alerting on new or high-risk grants.

What OAuth consent phishing is and why it matters

In a typical consent phishing scenario, the attacker registers or uses an application that requests permissions such as Mail.Read, offline_access, Files.Read.All, or User.Read. The victim is then directed to a legitimate Microsoft consent screen, often via a convincing email, Teams message, or external website. If the user approves the request, the app receives an access token and, in some cases, a refresh token that can be used repeatedly without re-prompting the user.

This differs from password theft in two important ways. First, the attacker may not need the user’s credentials at all, which means password resets alone may not remove the access path. Second, the activity can look like normal application usage unless you inspect consent events, service principal creation, and subsequent token use together. That is why detection needs to span identity logs, audit logs, and sign-in telemetry rather than relying on a single signal.

Microsoft’s audit trail is especially useful because it can show when an application was created, when permissions were granted, and which actor approved the request. If you already have a central logging approach in place, as discussed in our guide to what security logs you actually need and why, consent events are one of the identity sources worth prioritising.

Which Microsoft 365 and Entra ID logs to review

The main sources are Microsoft 365 audit logs, Entra ID sign-in logs, and service principal activity. In practice, you want all three because each answers a different question. Audit logs tell you what changed, sign-in logs tell you who authenticated and from where, and service principal records tell you what the application can now do.

Start with the Unified Audit Log in Microsoft Purview if it is available in your tenant. This is where you are most likely to see consent-related operations, application registrations, and permission changes. In Entra ID, sign-in logs help you validate whether the consented app was followed by unusual authentication patterns, such as token use from a new country, a new device, or a non-interactive sign-in that does not match the user’s normal behaviour.

Service principal and enterprise application data are equally important. A malicious app may be created in the tenant, or a third-party app may be granted permissions that are broader than the business intended. If you are already hunting for identity abuse patterns, the techniques in KQL queries for detecting risky Entra ID sign-ins in Sentinel can be adapted to correlate consent events with suspicious sign-in behaviour.

Retention and licensing matter. If your audit retention window is short, you may miss the original consent event and only see downstream activity. That creates a blind spot, especially where the attacker waits before using the grant. Make sure your detection design accounts for the fact that some tenants will have richer audit history than others, and that older events may need to be exported into a SIEM for longer retention.

High-signal audit events and fields to look for

The most useful events are those that show consent being granted, applications being registered, or permissions being assigned. Depending on your tenant configuration and log source, the exact operation names vary, but the pattern is consistent: look for app creation, service principal creation, consent grant, permission assignment, and admin consent approval.

Useful fields include the actor, target application name, application or client ID, service principal ID, granted scopes, IP address, user agent, and timestamp. If the event includes the resource being requested, that is particularly valuable because it lets you distinguish a low-risk app from one asking for broad mailbox or directory access. Also capture whether the action was performed by a standard user or an administrator, because that changes both the likely abuse path and the response.

For example, a newly created application with a generic name, a recently seen publisher, and high-privilege scopes such as Mail.ReadWrite, offline_access, or Directory.Read.All deserves more attention than a known line-of-business app with a stable client ID and a long history of use. The same applies if the consent comes from an account that normally never approves applications. That is where baselining becomes useful, not as a perfect detector, but as a way to separate expected business behaviour from unusual events.

Detection logic for suspicious consent activity

A strong detection strategy starts with rarity. If an application has never been seen in your tenant before, or if it is first seen by a user who does not usually approve apps, that is worth investigating. You can also flag unusual permission scopes, especially when the requested access is broader than the app’s stated purpose. A calendar add-in asking for mail access, for example, is a classic mismatch.

Location and device context also help. Consent granted from an unmanaged device, a new country, or an IP address that does not match the user’s usual working pattern increases suspicion. This is particularly relevant for UK SMEs with hybrid workforces, where a user may normally sign in from the office or home network and suddenly approve an app from a different region.

Separate user-consent abuse from admin-consent abuse. User-consent abuse often relies on convincing an ordinary user to approve delegated permissions. Admin-consent abuse is more serious because it can grant tenant-wide access or permissions that bypass normal user boundaries. If your tenant allows user consent at all, you should treat consent to high-risk scopes as a detection event, not just a configuration issue. If only admins can approve apps, then any admin consent event should be monitored closely and correlated with change records or ticket references.

One practical rule is to alert when a new or rarely seen application receives permissions that include mail, files, directory, or offline access, especially if the consent is followed by immediate token use. Another is to alert when the consenting user is outside a known approver group or when the app name resembles a common productivity tool but the publisher is unverified. These are not proof of compromise, but they are good triage candidates.

Example hunting approach in Microsoft Sentinel or KQL

In Microsoft Sentinel, a sensible starting point is to build a baseline of consent activity over 30 to 90 days. You want to know which applications are normally approved, by whom, from where, and at what frequency. That baseline can then be used to identify outliers such as first-seen app IDs, unusual scopes, or consent events outside business hours.

A simple hunting pattern is to query audit logs for app consent or application registration events, then summarise by app ID, actor, and scope. From there, join to sign-in logs to see whether the same user or service principal generated unusual authentication events shortly afterwards. If you are using Sentinel, a KQL pattern might look like this in concept: filter the audit table for consent-related operations, extract the app identifier and scopes, then join on sign-in records for the same identity within a short time window. The exact table names and operation strings depend on your connector and tenant, so validate them in your environment before turning the logic into an analytic rule.

For teams already using detection engineering practices, this is a good candidate for a Sigma-style rule translated into your SIEM, with a correlation layer that ties consent, sign-in, and mailbox access together. If you need a broader refresher on query structure and hunting workflow, our article on KQL threat hunting with Microsoft Sentinel covers the mechanics of building and tuning hunts.

Correlating consent with mailbox access is especially useful. A malicious app may not trigger obvious interactive sign-ins, but it may still access mail via Graph API shortly after consent. If you see a new app consent followed by a burst of mailbox reads, attachment downloads, or directory enumeration, that is a stronger signal than consent alone.

How to triage a suspected illicit consent grant

When a suspicious grant appears, start by confirming the application identity. Check the display name, app ID, publisher, redirect URI, and the permissions granted. A legitimate business app should usually have a recognisable owner, a documented purpose, and a stable history. A suspicious app often has a generic name, a recently created service principal, or a publisher that does not match the business context.

Next, determine the blast radius. Did the app receive delegated permissions for one user only, or application permissions that apply tenant-wide? Was the consent granted by a standard user, an admin, or a privileged role holder? Did the app request offline access, which can allow long-lived access without repeated user interaction? These questions help you decide whether the issue is limited to one mailbox or whether it may affect multiple accounts and data sets.

Then look for persistence and downstream abuse. Review sign-in logs for the consenting account and the service principal. Check for mailbox access, file downloads, directory reads, or unusual API activity after the grant. If the app is part of a broader campaign, you may also see follow-on phishing from the compromised mailbox, changes to inbox rules, or attempts to add additional OAuth grants. This is where it helps to think in terms of attack chains rather than isolated alerts.

Containment and remediation actions

If you confirm the grant is malicious or likely malicious, revoke the consent promptly and disable the application or service principal. In many tenants, that means removing the enterprise application, deleting the app registration if it was created in your tenant, and revoking active sessions for the affected account. If the app was granted admin consent, review whether any other users or groups were exposed through the same app.

Reset credentials for affected accounts where appropriate, but do not assume a password reset alone is enough. Review refresh tokens, active sessions, and mailbox rules. If the account had access to sensitive data or privileged roles, consider a broader review of recent activity and any other consented applications. You may also need to check whether the app has been used to access SharePoint, OneDrive, or other Microsoft 365 services.

Conditional Access should be reviewed as part of containment, but it is not a complete answer on its own. It can reduce the chance of risky sign-ins, yet it does not automatically stop a user from approving a malicious app if your consent settings are permissive. That is why consent governance and identity controls need to work together.

Hardening to reduce future consent phishing risk

The most effective hardening step is to reduce who can grant what. If your business can operate with user consent restricted, do that. Where user consent is allowed, limit it to low-risk permissions and consider requiring verified publishers. For higher-risk permissions, use an admin consent workflow so that requests are reviewed rather than approved ad hoc.

Review your app governance settings regularly. Remove stale enterprise applications, disable unused app registrations, and keep an inventory of approved business apps with owners and purposes. This makes it much easier to spot a new or unexpected consent event. Least privilege still applies here: if an app only needs read-only access to a single mailbox or site, do not approve tenant-wide permissions.

Alerting on new grants is also worthwhile. A lightweight rule that flags first-seen app IDs, high-risk scopes, or consent by non-approvers can give a small team enough time to investigate before the app is used at scale. If you already have a broader identity hardening programme, our guide to secure baseline configurations for Microsoft 365 is a useful companion piece for tightening the surrounding controls.

Operationalising the detection in a small security team

For a small team, the main challenge is not writing a single query. It is keeping the detection useful over time. Start by documenting the business-approved applications, the people allowed to approve them, and the normal permission patterns. Then tune your analytic rule so that it suppresses known-good apps but still alerts on new client IDs, unusual scopes, and suspicious consent locations.

Map the detection to MITRE ATT&CK so that it is easier to explain in incident reviews and control mapping exercises. OAuth consent phishing aligns well with adversary-in-the-middle style initial access and persistence through valid accounts and tokens, although the exact technique mapping depends on the behaviour you observe. The value of the mapping is not the label itself, but the consistency it brings to detection coverage and reporting.

Finally, tie the alert into your incident response playbook. The playbook should say who checks the app, who revokes access, who resets accounts, and who decides whether wider notification or recovery steps are needed. If you already maintain evidence and logs for investigations, keep the relevant audit records and sign-in data long enough to support that process. Our article on retaining evidence and logs for investigations is a useful reference point for that operational discipline.

Handled well, OAuth consent detection becomes a manageable part of identity monitoring rather than a specialist project. The key is to combine audit log visibility, sensible baselines, and a clear response path so that a suspicious grant is investigated quickly and consistently.

If you want help reviewing your Microsoft 365 detection coverage, consent settings, or incident response workflow, speak to a consultant.

Frequently asked questions

How do I detect OAuth consent phishing in Microsoft 365 audit logs?

Look for consent grant events, application registrations, and permission assignments in the audit logs, then correlate them with Entra ID sign-in activity and service principal use. The strongest signals are first-seen apps, unusual scopes such as mail or directory access, and consent from unexpected users, locations, or devices.

What Microsoft 365 log sources are most useful for finding illicit consent grants?

The most useful sources are Microsoft 365 audit logs, Entra ID sign-in logs, and service principal or enterprise application records. Audit logs show the change, sign-in logs show the authentication context, and service principal data shows what the app can access after consent.

Baselining and detecting anomalous PowerShell with script block logging

Clear Path Security Ltd — Fri, 18 Sep 2026 16:50:27 +0000

Originally published on the ClearPath Security site: https://clearpathsecurity.co.uk/baselining-and-detecting-anomalous-powershell-with-script-block-logging/

PowerShell is one of the most useful administrative tools in Windows environments, which is exactly why it deserves dedicated detection coverage. It is used for software deployment, identity and endpoint administration, cloud management, and routine automation. It is also frequently abused because it can run in memory, invoke native Windows components, and blend into normal administrator activity.

For UK SMEs, the goal is not to treat every PowerShell invocation as suspicious. The aim is to understand what normal looks like in your environment, collect enough telemetry to spot meaningful deviations, and turn that into detections that are useful to a small security team. If you already have basic logging in place, logging and monitoring basics for small teams is a sensible companion topic. This article focuses on the next step: building a baseline for PowerShell and using script block logging to identify anomalous behaviour.

Key takeaways

Script block logging is most useful when combined with process, identity, and network telemetry rather than used in isolation.
Build a baseline around trusted hosts, users, parent processes, and script locations so that detections focus on meaningful deviations.
Prioritise high-signal patterns such as encoded commands, unusual execution paths, and suspicious parent-child relationships.
Tune detections using frequency, rarity, and context to reduce noise without suppressing genuine abuse.
Review and validate PowerShell detections regularly because legitimate automation and administration patterns change over time.

Why PowerShell deserves dedicated detection coverage

PowerShell is not just another command shell. It exposes access to Windows Management Instrumentation, the registry, Active Directory, scheduled tasks, services, and network functions. In legitimate use, that makes it efficient for administrators. In malicious use, it gives an operator a flexible way to enumerate systems, stage payloads, disable controls, or move laterally.

That dual use matters because many defensive tools see only fragments of the activity. Process creation logs may show powershell.exe, but not the full script. Network logs may show a connection, but not the command that initiated it. Script block logging fills part of that gap by recording the content PowerShell interprets after de-obfuscation.

In practice, PowerShell detections work best when they are part of a wider Windows telemetry strategy. Process telemetry, Windows Security logs, Sysmon, and network data all add context. If you are already using endpoint controls to reduce attack surface, reducing attack surface using system hardening techniques can help you decide which PowerShell features should be restricted or monitored more closely.

What script block logging captures and what it does not

Script block logging records the content of PowerShell script blocks, typically through Event ID 4104 in the Microsoft-Windows-PowerShell operational log. The value is that it captures the script after PowerShell has parsed it, which can expose decoded or expanded content that would otherwise be hidden by simple command-line obfuscation.

That makes it useful for detecting suspicious strings, unusual function calls, encoded content, and common tradecraft such as download cradles or reflective loading patterns. It is especially helpful when an attacker uses short, heavily obfuscated commands that would be hard to triage from process creation alone.

However, script block logging is not complete visibility. It does not guarantee that every malicious action will be logged, and it does not tell you intent. It also depends on the relevant logging being enabled, the event reaching your collection point, and the script being executed through PowerShell in a way that produces useful content. Some activity may occur through other interpreters, native binaries, WMI, scheduled tasks, or remote management channels. For that reason, detections should correlate PowerShell events with broader telemetry rather than relying on a single log source.

There is also a practical distinction between content and context. A script block may look unusual in isolation, but be perfectly normal for a deployment tool or a management script. That is why baselining is essential.

Building a useful baseline for normal PowerShell activity

A baseline is not a static allowlist. It is a working understanding of what normal PowerShell activity looks like across your estate, so that you can identify outliers. Start by identifying the systems, users, and tools that legitimately generate PowerShell at scale.

For most SMEs, those will include endpoint management platforms, patching tools, software deployment agents, backup agents, and a small set of privileged administrators. Record which hosts generate PowerShell, which accounts run it, which parent processes launch it, and which command patterns recur. This gives you a practical view of expected behaviour.

Separate routine automation from interactive use. A scheduled task that runs a signed script from a known path every night is very different from an administrator opening an interactive shell on a finance workstation at 11pm. The first may be normal. The second may still be legitimate, but it deserves context.

When building the baseline, focus on a few dimensions:

Trusted hosts, such as jump servers, management servers, and endpoint management consoles.
Trusted users and groups, especially privileged accounts and service accounts.
Trusted parent processes, such as management agents or approved automation runners.
Trusted script locations, for example signed scripts in controlled repositories.
Expected frequency, such as daily patching windows or weekly maintenance jobs.

It is also useful to compare PowerShell usage by device class. A domain controller, a management server, and a user laptop should not look the same. If they do, that may indicate over-permissive administration or a lack of role separation. For a broader view of how PowerShell abuse fits into attacker behaviour, detecting fileless malware and living-off-the-land attacks provides useful context.

Telemetry sources to combine with script block logging

Script block logging is strongest when combined with other Windows telemetry. At minimum, pair it with PowerShell operational logs, Windows Security logs, and Sysmon if you can support it operationally.

PowerShell operational logs help you see engine lifecycle events and script block content. Windows Security logs provide logon events, privilege use, and process creation if configured appropriately. Sysmon adds richer process creation, network connections, image loads, and command-line detail. Together, they let you answer not just what script ran, but who ran it, from where, and what it touched next.

Useful correlations include:

Event ID 4104 with process creation events to identify the parent process and command line.
PowerShell activity followed by outbound network connections to unfamiliar destinations.
PowerShell launched from office applications, archive utilities, or script hosts that are unusual for the user.
PowerShell activity on servers that should rarely need interactive administration.

Sysmon is particularly valuable where you need process ancestry and network context. If you are tuning that layer as well, detecting living-off-the-land binaries with Sysmon process events is a good reference point for building process-based detections that complement PowerShell telemetry.

Patterns that often indicate suspicious PowerShell behaviour

There is no single malicious PowerShell signature that works everywhere, but there are recurring patterns that deserve attention. The most common include encoded commands, heavy obfuscation, unusual execution switches, and scripts that retrieve or execute content from remote sources.

Encoded commands are often used to hide the real content from casual inspection. Obfuscation may involve string concatenation, variable indirection, alias abuse, or deliberate formatting changes. Suspicious command-line switches include -EncodedCommand, -ExecutionPolicy Bypass, and combinations that suppress profile loading or hide the window. None of these are proof of malicious intent on their own, but they are strong indicators when they appear on endpoints that should not need them.

Download cradles are another common pattern. These are commands that fetch content from the network and execute it immediately, often using native web request functions. In-memory execution, reflective loading, and script injection techniques may leave little on disk, which is why script block content and process context matter. Attackers also frequently use PowerShell as a staging mechanism before moving to other tools, so the PowerShell event may be only the first observable step.

Look for unusual combinations rather than isolated strings. For example, a script block that uses web requests, base64 decoding, and process injection APIs is far more concerning than a simple administrative query. Similarly, PowerShell running from a user profile path, temporary directory, or email attachment location is more suspicious than a signed script from a controlled deployment share.

Practical detection logic for small security teams

Small teams need detections that are high signal and maintainable. Start with a small number of rules that are easy to explain and triage. Good candidates include rare parameter usage, suspicious parent-child relationships, unusual execution paths, and scripts that contain known risky behaviours.

A practical rule set might include:

PowerShell with -EncodedCommand or equivalent encoded content.
PowerShell launched by office applications, browser processes, archive tools, or scripting hosts that are not normally used for administration.
PowerShell executed from user-writable directories such as %AppData%, %Temp%, or downloads folders.
PowerShell script blocks containing web download functions, reflection, AMSI tampering indicators, or suspicious process creation.
PowerShell activity on servers or workstations outside approved maintenance windows.

Use allowlists carefully. They are useful for reducing noise from known deployment tools, but they can also hide abuse if they are too broad. Prefer scoped allowlists based on signed binaries, known service accounts, specific management servers, and controlled script paths. Avoid blanket exclusions for entire command patterns unless you have strong evidence that they are safe in your environment.

When possible, score detections by context rather than treating them as binary. A rare command on a privileged account, from an unusual host, outside business hours, should rank higher than the same command from a known management server during a patch window. That approach is often easier to operationalise than trying to write one perfect rule.

How to tune detections without losing coverage

Tuning is where many PowerShell detections either become useful or get switched off. The main challenge is reducing false positives from legitimate administration, software deployment, and automation frameworks without creating blind spots.

Start by measuring frequency and rarity. Which commands appear every day, and which appear only once a month? Which hosts generate the most script block events, and do those hosts align with your expected management architecture? Which accounts are responsible for the majority of activity? These questions help you identify the normal operating envelope.

Then add context. A script block that looks suspicious on a user laptop may be routine on a patching server. A command that is normal for a service account may be unusual for an interactive administrator. Time of day, source host, parent process, and user group membership all matter.

Be careful not to over-tune around a single tool. If you suppress every event from one deployment platform, you may miss abuse through that platform, especially if an attacker compromises the management plane. A better approach is to validate the platform’s normal command patterns and then alert on deviations from those patterns.

For teams that want to improve detection quality systematically, the same principles used in broader detection engineering apply here: define the behaviour, measure the noise, tune by context, and review regularly. If you are already working on credential misuse detection, detecting credential theft and misuse patterns is a useful adjacent reference because PowerShell abuse often overlaps with account compromise.

Threat hunting questions to ask in PowerShell logs

Hunting is where script block logging becomes especially valuable. Rather than waiting for a rule to fire, use the logs to ask structured questions about behaviour.

Useful hunting questions include:

Which hosts generate the most PowerShell script blocks, and do those hosts match their intended role?
Which users run PowerShell interactively, and is that consistent with their job function?
Which script blocks contain web requests, encoded content, or suspicious string manipulation?
Which parent processes launch PowerShell most often, and are any unexpected?
Which scripts run outside normal maintenance windows or from unusual paths?

Hunting is also a good way to validate your baseline. If a host suddenly starts producing far more PowerShell activity than usual, that may indicate a new automation job, but it may also indicate an attacker using the host as an execution point. The key is to compare current behaviour with the established pattern, not with an abstract idea of what is normal.

Operationalising detections in Microsoft Sentinel or a SIEM

In a SIEM, the main task is to make PowerShell events searchable, normalised, and easy to correlate. In Microsoft Sentinel, that usually means ensuring the relevant Windows logs are ingested into a workspace, then building analytics rules and hunting queries around Event ID 4104 and related process telemetry.

Normalisation matters because PowerShell content is often messy. Script blocks can be multiline, contain escaped characters, or be split across events. If your SIEM supports parsing or custom fields, extract the command content, host, account, parent process, and execution time into searchable fields. That makes it much easier to write detections and triage alerts.

A practical workflow is:

Ingest PowerShell operational logs and process telemetry from your endpoints and servers.
Build one or two high-signal analytics rules for obvious suspicious patterns.
Create hunting queries for rare commands, unusual hosts, and off-hours activity.
Review alerts weekly to identify recurring false positives and new legitimate use cases.
Promote validated hunts into scheduled detections where they add value.

If you are designing the broader pipeline rather than just the rule content, centralised security visibility explained for SMEs can help frame how PowerShell telemetry fits into a wider visibility model.

Validation, tuning, and continuous improvement

Detections should be tested against known-good administrative activity and safe simulations. You do not need to recreate real attacker behaviour to validate whether your logging and rules are working. Instead, use benign scripts that exercise the same telemetry paths, such as encoded commands in a lab, remote administration from approved hosts, or scheduled automation from service accounts.

Check three things during validation. First, does the event arrive in your SIEM with the fields you need? Second, does the rule trigger on the behaviour you expect? Third, can an analyst triage the alert quickly using the available context? If the answer to any of those is no, the detection is not yet operationally ready.

Measure alert quality over time. Track false positives, time to triage, and the proportion of alerts that lead to useful investigation. If a rule is noisy but occasionally valuable, tune it rather than removing it immediately. If it is consistently noisy and low value, retire it and replace it with a more contextual rule.

Continuous improvement is especially important in PowerShell monitoring because legitimate usage changes. New management tools, new automation scripts, and new cloud integrations can all alter the baseline. Review your detections after major changes to endpoint management, identity administration, or software deployment.

Implementation checklist for UK SMEs

If you are starting from scratch, a phased approach is usually the most practical.

Phase one is logging enablement. Turn on PowerShell script block logging on the systems that matter most, especially privileged workstations, servers, and management hosts. Make sure logs are forwarded centrally and retained long enough for investigation. If storage is limited, prioritise high-value assets rather than trying to capture everything at once.

Phase two is baseline creation. Identify trusted hosts, users, and tools. Document the common parent processes, command patterns, and maintenance windows. Use that baseline to define what should be normal, and where exceptions need review.

Phase three is detection. Start with a handful of high-signal rules for encoded commands, suspicious parent processes, unusual paths, and risky script content. Keep the rules understandable so that they can be maintained by a small team.

Phase four is review and improvement. Revisit the baseline monthly, tune alerts based on real activity, and add new detections when you see repeatable patterns. If you want support designing that operating model, the service most aligned to this work is our Speak to a consultant option, which can help you shape practical logging and detection improvements without overengineering the solution.

For UK SMEs, the most effective PowerShell monitoring programmes are usually the ones that are focused, well-instrumented, and reviewed regularly. You do not need perfect coverage on day one. You need enough visibility to spot meaningful deviations, enough context to triage them, and enough discipline to keep improving the baseline as your environment changes.

Frequently asked questions

Is script block logging enough on its own to detect malicious PowerShell?

No. It is a strong source of content visibility, but it works best when combined with process creation, logon, and network telemetry so you can see who ran the script, from where, and what happened next.

What is the difference between script block logging and PowerShell transcription?

Script block logging records the script content that PowerShell interprets, which is useful for seeing decoded or expanded commands. Transcription records the interactive session output and input as a text transcript, which can be useful for context but does not replace script block logging.