Incident Response: Scam Attack Against Retail Stores

Yesterday our stores experienced a scam attack via phone call claiming to be from the IT department and wanting to test refunds on high value items in order to get free money. Later in the campaign, they change story to claim they were from a VoIP provider. Unfortunately, one or two stores fell victim, but many others remained vigilant.

As a response, our security team deployed the following: – Created a war room for the few members involved. – Sent out communications to all employees involved (we have internal tools for this) – Used OSINT to investigate the phone number being used (the threat actor was dumb enough to use the same number for all attempts). – Blocked the number through our provider (though changing number is obviously very easy. This was done because it was the only number being used at the time.) – Did EDR scans on all store PCs from people that called in. Side Note – This is where communication with non tech savvy people can be difficult. During the social engineering process, the person at the register is instructed to reach a point in the process where you have to enter a credit card number. Reports from one end user claimed the that cc number was entered in automatically by the threat actor on the phone. They claimed no other assistance was given to access the PC, no mouse movement was performed, just the number entry. This does not make any sense to me. I did the following to investigate, but found zero IoCs: – full EDR scan on the endpoint – PCAP review for any malicious connections – RMM software installations – ELK log review – folder review – confirmed scheduled tasks Nothing substantial was found to show that a threat actor had accessed the PC and entered in the cc number. Personally, I think the end user reporting this claimed it happened this way to protect themselves. Regardless, nothing was found.

Through good communication and best security practices we were able to get this incident under control relatively fast. A big take away from this is going to be ACL build out for the feature that allows for the access of refunds through manual entry. Too many people seem to have access to this feature by default.

There is an obvious pattern that must be brought up so we as analysts and blue teamers can remain vigilant. Threat actors are starting to realize how easy social engineering truly is and the power that comes with it. We must keep our end users aware of these threats and train them to question the true intentions of people when something doesn't feel right. Typically when your gut questions something, you're usually right. For our team, we are going to be working closely with our help desk team over the next few weeks to improve their verification process and social skills to learn when something malicious is happening. Happy Hacking!