Security teams detect infected software by comparing files and packages against trusted hashes, scanning for known malicious indicators, and watching for unusual process, network, or persistence behaviour after execution. Validate software from source to deployment, and isolate suspected systems quickly. Unexpected modifications to signed or approved software often indicate compromise or trojanisation.
How infected software shows up in practice
Security teams usually spot infected software by looking for evidence that the file or package no longer matches what was trusted, approved, or signed. That means checking hashes, signatures, package metadata, and build provenance, then comparing them to a known-good baseline. If the software behaves differently after execution, those runtime changes matter just as much as the binary itself.
Detection works best when static and behavioural signals are combined. A clean hash alone does not prove safety if the software was replaced before deployment, and a suspicious process alone does not prove infection if the behaviour is normal for that application. The practical job is to correlate file integrity, origin, execution context, and downstream effects.
Software Supply Chain Security Guide is the right starting point when you need to connect source, build, signing, and deployment checks to detection of tampering or trojanisation.
What to look for after execution begins
Once software runs, infected samples often reveal themselves through abnormal process trees, unexpected child processes, unusual network destinations, or new persistence mechanisms. The most useful indicators are the ones that break the software’s normal profile, not just generic malware alerts. For example, a signed updater that launches scripting tools, writes to autostart locations, or reaches out to unfamiliar infrastructure deserves immediate scrutiny.
Teams should also treat unexpected modifications to approved software as a high-value signal. If a package was trusted in source control, then altered in transit, altered during build, or altered before installation, the problem may be compromise rather than a simple endpoint infection. The earlier that discrepancy appears in the chain, the broader the potential blast radius.
MITRE ATT&CK Enterprise Matrix helps map those runtime clues to persistence, defense evasion, and credential access behaviours that commonly follow software compromise.
How to reduce false negatives and contain suspected compromise
Detection gets weaker when teams only inspect the endpoint after installation. A stronger approach is to validate software from source to deployment, keep trusted baselines for hashes and signatures, and compare newly observed artifacts against what was expected at each stage. That makes it easier to catch tampering before the software is allowed to spread.
Containment should be fast and reversible. If a workstation, server, or build host shows signs of infected software, isolate it quickly, preserve evidence, and avoid blind cleanup until the team understands whether the issue is a single host infection, a compromised package, or a broader supply chain event. If credentials, tokens, or update channels may have been exposed, rotate them as part of the response.
Risk and Threat Considerations
Infected software is dangerous because it can look legitimate while carrying attacker-controlled behaviour. Signed or approved software that changes after trust has been established can bypass normal approval paths, spread quietly, and create persistence or lateral movement opportunities before defenders notice.
Failure mechanism: Attackers alter a trusted package, replace a dependency, or inject code into an otherwise approved binary, then rely on normal distribution and execution to deliver the payload.
Impact: The compromise can expose hosts, credentials, update channels, and downstream systems while delaying detection because the software appears valid at first glance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Infected software often hides malicious code or changes from static inspection. |
| T1547 — Boot or Logon Autostart Execution | Infected software may persist by creating startup or logon execution paths. | |
| T1204 — User Execution | Trojanised software depends on execution of a trusted-looking file or installer. | |
| Recommendation — Hunt for obfuscation and concealment when trusted software behaves inconsistently. Check for new persistence entries after suspicious software execution. Correlate user-initiated execution with later abnormal process and network activity. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of Information and Systems Is Protected | Detecting infected software depends on verifying artifact integrity and unauthorized change. |
| DE.CM-09 — Network Monitoring | Unexpected outbound connections are a key behavioural sign of infected software. | |
| Recommendation — Verify hashes, signatures, and provenance before allowing software into production. Monitor egress and flag software that contacts unfamiliar destinations. | ||
Practitioner Guidance
What to verify: Compare the deployed artifact against the original source, build output, signature, and hash before you trust any security verdict. If those controls disagree, treat the software as suspect even if the endpoint is not yet showing obvious malware activity.
Decision rule: If the software can still authenticate to services, reach production systems, or update other hosts, prioritise isolation and credential review before deeper triage of the binary itself. If the compromise may extend into the build or release path, broaden the investigation beyond a single endpoint.
Practitioner takeaway: The most reliable detection strategy is chain-of-custody plus behaviour, because infected software is often discovered not by one indicator, but by a mismatch between what was trusted and what the software actually does.
Related resources from NHI Mgmt Group
- How do security teams detect malicious software delivery when the code looks legitimate?
- How should security teams detect and contain repo confusion attacks in software supply chains?
- How should security teams detect unauthorized software releases in CI/CD pipelines before users are affected?
- How should security teams detect malware that disguises itself as legitimate software and uses cloud services as dead drop resolvers?