Detect it by watching for abnormal growth in files that should change slowly, especially logs, archives, and documents in sensitive locations. Compare file size changes with recent writes, process ownership, and hash history. Large padding, repeated appends, or size jumps without corresponding content changes can indicate evasion, storage abuse, or attempts to break quotas, scans, or transfer limits.
How to spot suspicious file-size inflation patterns
File-size inflation is most useful to detect when you treat it as a mismatch problem, not just a growth problem. The key question is whether a file is getting larger in a way that fits its normal edit pattern. Security teams should baseline expected churn by file type, location, ownership, and business process, then flag sudden jumps, repeated padding, or steady growth that is not explained by normal application output.
That context matters because inflated files often look harmless if you only watch total size. A log file that should append modestly, an archive that rarely changes, or a document in a sensitive share that suddenly expands are all different from a healthy working file. The strongest signal is a size change that is not accompanied by a plausible content delta, recent legitimate writer activity, or a normal revision history.
File attributes help separate ordinary growth from manipulation. Compare size changes with recent writes, process ownership, hash history, and the file’s role in the system. If a file grows while its content hash stays stable for long periods, or the same process repeatedly appends blocks of similar-looking data, that pattern is more suspicious than a one-time increase tied to a known job or user action.
What file behaviour usually gives the game away?
Suspicious inflation often shows up as repeated appends, large padding blocks, or size jumps that do not line up with user editing patterns. Logs are a common place to look because their structure is predictable and their growth rate is usually easier to model than free-form content. Archives and exported documents are also worth attention because their size can be manipulated to interfere with scanning, transfer limits, retention rules, or storage quotas.
Look for combinations of signals rather than one isolated indicator. A file that becomes much larger, is owned or touched by an unexpected process, and changes outside normal business hours is more interesting than a single size spike by itself. In practice, the best detections correlate file telemetry with process lineage and write timing so that a benign batch job does not look identical to tampering.
When a file is deliberately padded, the content often remains low-value while the file becomes operationally expensive. That can create false pressure on backup systems, slow triage, or hide malicious material inside a larger container. Watching for growth that is disproportionate to the file’s function is often more useful than applying a fixed size threshold.
How should defenders investigate and confirm it?
Start by asking whether the file should be mutable at all, then whether the observed growth is consistent with that file’s normal use. If the answer is no, review the writer process, parent process, account context, and the sequence of recent modifications. A clean investigation usually shows either a legitimate bulk update with expected provenance or a growth pattern that has no matching business process.
Comparing current state with prior hashes or known-good versions is especially useful when the file grows but the meaningful content does not. If the growth is driven by filler data, repeated blocks, or container padding, the file may still appear intact to a casual reviewer. That is why defenders should validate both metadata and content structure before concluding the change is routine.
For files that affect security tooling or transfer workflows, the practical concern is not only whether the file is bigger, but whether the inflation was meant to distort downstream handling. A sudden change in an archive, log bundle, or export package can be a clue that someone is trying to evade inspection, exhaust resources, or force an exception in a pipeline that expects smaller objects.
Risk and Threat Considerations
Artificial file inflation matters because it can be used to hide malicious content, stress storage and transfer systems, or interfere with inspection logic. The risk is highest where size thresholds, quota enforcement, or content scanning are used as control points, since padding can change how a system prioritises, classifies, or processes the file.
Failure mechanism: An attacker or insider can append filler, repeated blocks, or low-signal content to create a file that appears abnormal only after it has already moved into backup, transfer, or review workflows. That can delay detection, increase operational load, or create blind spots in downstream tooling.
Impact: Teams may miss malicious payloads, waste storage and analyst time, or see processing failures in systems that were never designed for unusually inflated objects. In sensitive environments, size abuse can also become a persistence or evasion tactic if the inflated file blends into routine logs or exports.
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 CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Inflated log files can indicate tampering or abuse of log workflows. |
| Recommendation — Monitor log growth and alert on abnormal append patterns or unexpected file expansion. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Suspicious file-size jumps are an anomaly detection problem. |
| Recommendation — Baseline file growth and investigate deviations from expected change patterns. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Reviewing anomalous file activity supports detection of padding and manipulation. |
| Recommendation — Correlate file growth with process and write evidence during audit review. | ||
| MITRE ATT&CK | T1565 — Data Manipulation | File inflation is a form of altering data to affect integrity or handling. |
| Recommendation — Hunt for deliberate content alteration that changes file handling or trust. | ||
Practitioner Guidance
What to prioritise: Build detections around deviation from normal file behaviour, not just absolute file size. The most useful alerts combine size delta, write activity, process identity, and file type so that reviewers can tell padding from legitimate growth.
What to verify: Confirm that the file’s owner, writer process, and recent hash history all make sense together. If the file is in a location where changes should be rare, treat unexplained growth as a triage event even when no malware is immediately visible.
Practitioner takeaway: Size inflation is best treated as an integrity and workflow anomaly, so the strongest detections are the ones that explain why the file changed, not just how much it changed.
Related resources from NHI Mgmt Group
- Guide: EDR Evasion and Defence Guide
- How do security teams detect spear-phishing campaigns that hide behind seemingly legitimate file-sharing workflows?
- How should security teams detect exfiltration when every file transfer is individually allowed?
- How should cloud security teams detect and contain attempts to modify compute infrastructure for defense evasion?
- How should security teams detect ransomware activity from file creation and shadow copy deletion on Windows endpoints?