- Keystroke loggers grabbing the track 1 and/or track 2 from the credit/debit cards
- Keystroke logger installed via USB
- Keystroke logger installed from an attacker’s laptop on the POS VLAN. Unplugging a terminal, jacking in, exploit the other non-protected terminals in the POS VLAN.
- Keystroke logger installed via the internet because we failed to stop the terminal from reaching it.
- Memory scrappers to collect the clear text track1/2 data in memory
- Installed in the same ways as above.
- Card Holder Data (CHD) extracted at rest and/or in transit while operating in Store & Forward (S&F) mode.
- Card Holder Data (CHD) extracted at rest and/or in transit while creating a Timeout Reversal.
- Card Holder Data (CHD) extracted at rest and/or in transit while performing for batch settlements.
- CHD sniffed and collected in transit, ANYWHERE along the path.
Questions for Oracle/Micros
- Is CHD kept on the terminal during S&F operations? In other words, if the terminal loses communication with the server, do the terminal itself store the CHD?
- If the server(s) goes down or is otherwise unreachable, do ALL terminals stop functioning or can they function independently using offline authorization mode of some sort?
- If the terminals and servers are online, but the network path upstream to the payment gateway/processor drops, does the S&F operation happen on the server?
- Do the Micros terminals emulate a keyboard from the Mag Stripe Reader (MSR)? If so, a simple keystroke logger is in play here.
- Are there application logs on the terminals themselves that can be exploited? If so, this opens up another data at rest attack surface.
- Are the records in the SQL DB hashed and salted?
- Tokenization and/or point-to-point encryption start and end where? (e.g. Server to payment processor only, MSR to server, all the way MSR to Issuer, etc.)