Defending against the “Pay2key” cyber campaign

Ben Brauner

December 16, 2020

Cyber Incident Response

Pay2key – December 2020

Over the last 10 days, OP Innovate has handled a number of cyber incidents resulting from the Iranian ‘Pay2key’ campaign. This intelligence gathering and ransomware campaign has targeted over 80 Israeli organizations thus far, and if successful, would have paralyzed significant sectors of the Israeli industry.

Incident Response Methodology

An incident response methodology coalesces is a number of procedures which aim to identify, investigate, handle and then learn from security incidents. The methodology seeks to minimize impact and downtime, bring about rapid recovery, and feed into an iterative feedback loop which strives to decrease future recurrence.

The commonly accepted incident response phases are:

This document focuses on the detection, containment and eradication of the “Pay2key” cyber campaign.

Go to the Windows Task Scheduler and identify the newly created task named “VerifiedPublisherCertStoreVerify”. It appears in the \Microsoft\Windows\AppID directory and replaces the existing legitimate Windows task of the similar name (VerifiedPublisherCertStoreCheck) (figure 1).

Figure 1: Task Scheduler showing the disabled legitimate task and its persistent malicious replacement

Investigation of the malicious task shows that it runs an application masquerading as a Windows application each day at 9am. The name of this application is sccm.exe, and mimics the Windows System Center Configuration Manager (SCCM). Use of a legitimate Windows application name may help the malware file to evade some antivirus software which looks for unknown file names.

This malware file is located in the c:\windows\speech folder. Its location is a further effort to evade the AV software (figure 2).

Figure 2: Malware location

Eradication action items:

The malicious scheduled task must be deleted.
The malware file found in c:\windows\speech\sccm.exe must be deleted.

A further artifact found was the creation of a local administrative user on the server, the account named “DefaultAccounts$” (figures 3 and 4). This seeks to mimic the “DefaultAccount”, also known as the Default System Managed Account (DSMA), a built-in account introduced in Windows 10 version 1607 and Windows Server 2016. It remains present in Windows 10, Windows Server 2016 and Windows Server 2019. The legitimate DefaultAccount user is absent since the server predates Windows Server 2016.

Figure 3: The newly created DefaultAccounts$ account

Eradication action items:

The DefaultAccounts$ user must be deleted

Further recommendations to mitigate the attack:

Block all traffic to and from the following IPs: 63.32.140.129 , 13.81.213.207 , 162.223.91.13
Reset passwords for all domain admin users, VPN users. Enable and enforce 2FA.
Make sure your VPN software and firewall firmware are up to date