RawPOS is point-of-sale malware designed to steal payment card data from memory or transaction paths on compromised systems. Attackers deploy it in retail environments to capture cardholder data before encryption or transmission. Monitor POS endpoints for suspicious processes, memory scraping behaviour, and unauthorised software changes.
How RawPOS Works in a Retail Environment
RawPOS is designed to live on or near a point-of-sale endpoint long enough to observe card-present transactions. It focuses on the moments when payment data exists in memory, buffers, or transaction flow, because those are the points where cardholder data may be exposed before normal protections fully apply.
This makes the malware less dependent on stealing data from databases or payment gateways. Instead, it targets the operational path where the card is processed, which is why point-of-sale compromise can translate quickly into large-scale payment card theft if the endpoint is not tightly controlled.
What RawPOS Tries to Capture
RawPOS families are associated with memory scraping and transaction interception. In practice, that means the malware is looking for payment card track data, account numbers, and other card-present artefacts while they are temporarily resident on the system or passing through the checkout workflow.
The key security issue is timing. Even when card data is encrypted later in the flow, a compromised endpoint may still expose useful data earlier in processing. That is why defenders treat card data exposure on POS systems as a host integrity problem, not only a network encryption problem.
Why RawPOS Is Dangerous
POS malware is dangerous because retail endpoints are often numerous, business-critical, and expected to keep running during busy trading periods. Once an attacker has foothold on a checkout system, they can quietly harvest payment data from many transactions before the compromise is noticed.
NIST Cybersecurity Framework 2.0 fits this threat pattern well because RawPOS primarily disrupts protect and detect outcomes: organisations need asset visibility, endpoint hardening, anomaly monitoring, and rapid response around systems that process payment data.
Retail environments also tend to rely on consistent software images and predictable transaction software, so unauthorised process injection or unexpected binaries can become an early sign of compromise.
How Organisations Reduce RawPOS Exposure
Exposure control starts with knowing exactly which endpoints handle card-present transactions, where they sit on the network, and which software is authorised to run on them. POS systems should be treated as high-trust assets with tightly limited administrative access and aggressive application control.
NIST Cybersecurity Framework 2.0 supports that approach at a program level, while NIST AI Risk Management Framework is not directly relevant here; the better technical fit for this subject is stronger endpoint and configuration discipline, especially around software allowlisting and least privilege.
Where payment environments are segmented, a compromise of one register or back-office machine should not automatically open access to adjacent systems, management tools, or payment-adjacent services. Logging, integrity monitoring, and alerting on unexpected process execution matter because RawPOS often tries to blend into normal checkout activity.
Detection, Response, and Recovery After Suspected Infection
Detection should focus on suspicious processes, memory scraping behaviour, unusual child processes spawned by payment software, and unauthorised changes to binaries or startup locations. Because this malware is built to be quiet, defenders often need host telemetry, file integrity monitoring, and endpoint containment to see it.
If compromise is suspected, isolate the endpoint, preserve volatile evidence where feasible, and review whether card data could have been exposed during the compromise window. Post-incident review should also examine adjacent systems, because retail malware often appears in clusters when attackers reuse the same access path or deployment method.
Recovery is not complete when the malware is removed. The organisation must also validate that no persistence mechanism, remote access tool, or tampered management account remains in place that could reintroduce the threat.
Risk and Threat Considerations
RawPOS creates direct card-data theft risk because it is built to capture payment information at the point where it is most valuable to attackers and hardest to contain operationally. The danger increases when point-of-sale systems are widely deployed, weakly segmented, or slow to reveal unauthorised software changes.
Failure mechanism: An attacker gains execution on a checkout system, then uses memory scraping or transaction interception to collect card data before later-stage protections can stop it.
Impact: Stolen card data can drive fraud, chargebacks, breach notification obligations, forensic cost, and loss of trust in the merchant environment.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | RawPOS risk is reduced by limiting POS access paths and execution rights. |
| DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | RawPOS is detected through endpoint monitoring and software-change visibility. | |
| PR.DS-10 — Integrity Protection | RawPOS targets payment data handling integrity on the host during transaction flow. | |
| Recommendation — Apply least-privilege access to POS endpoints and transaction software. Monitor POS endpoints for unauthorized software and suspicious process activity. Protect transaction software integrity and verify trusted binaries on POS systems. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | POS malware thrives where endpoint configuration and software baselines drift. |
| Recommendation — Harden POS builds and enforce approved software configurations. | ||
| MITRE ATT&CK | T1056 — Input Capture | RawPOS-like malware intercepts payment data entering or passing through the endpoint. |
| T1055 — Process Injection | POS malware often persists by blending into legitimate payment processes. | |
| Recommendation — Map card-data capture behaviours to input-capture techniques and hunt for them. Investigate injected or unexpected processes inside payment application contexts. | ||
Practitioner Guidance
What to watch for: Treat any unexplained process running on a POS endpoint, especially one that accesses memory, hooks payment software, or appears outside the approved application set, as an immediate investigation trigger. In retail environments, speed matters because the malware’s value comes from silent collection over time.
Governance implication: Ownership of POS hardening, software control, and monitoring should be explicit, with clear responsibility for approving changes to checkout systems and validating that installed software matches the intended build. The practical test is whether the organisation can prove that only authorised code handles card transactions.