How CDW Tackled the Anatomy of a Phishing Attack and Key Takeaways

Phishing attacks are becoming more sophisticated. Many organizations with diligent IT departments are familiar with the occasional phishing training, which alerts us to: be mindful of the sender’s email address, not click on suspicious links from individuals purporting to be someone they’re not and, above all, not send them sensitive information.

When these types of incidents do occur, what most employees will never see or know is the detailed investigation and triage IT teams must endure. The need for thorough investigations and problem-solving is also why organizations turn to CDW Managed Security Services.

Before we begin, bear in mind that a phishing attack on one organization is an attack on all because, chances are, if it works on one company, it’s only a matter of time before the same tactic is used on another. Every security team is a part of the collective effort to combat online attacks. Solution sharing is the surest way to combat attackers. Now, imagine this real-world scenario.

The Incident

In this incident, adversarial behaviors such as initial access via phishing, persistence via dynamic link library (DLL) side-loading, command and control (C&C) and discovery via remote procedure call (RPC) were observed. Upon thorough investigation, it was revealed that a user clicked a link in an email from a personal email account accessed via a work-issued device, leading to a successful phishing attack.

The attacker was living off the land (LotL) by employing Windows-native processes. In its article “NCSC Warns CNI Operators Over ‘Living-Off-the-Land’ Attacks,” Computer Weekly defines LotL as “the exploitation of existing, legitimate tools on users’ IT systems in order to blend in naturally occurring traffic that would not ordinarily raise any eyebrows. By exploiting these tools or binaries — also known as LOLbins — malicious actors can slip past security defenses and teams with relative ease and operate discretely in the service of their paymasters.”

This incident was a clear case of behavioral threat detection, as no threat intel site flagged the initial executable and the command-and-control IP as malicious. This underscores the point that attackers are constantly updating their infrastructure and relying more on LOL binaries to evade signature threat detection.

The Attack Chain at a Glance

Key Takeaways From This Incident

• The role of defense in depth cannot be overemphasized in prevention mechanisms.
• With remote work, the network perimeter boundaries have been eroded, so it is crucial for organizations to have the proper controls in place, such as a proxy, always-on VPN and host firewalls to mitigate threats to remote endpoints and users.
• User awareness and remote user policies are key controls.
• Beyond signature-based detection and investigation, examining behavioral traits during incident investigation is far more important.
• Best practices should be employed in implementing firewall policies.
• Application control continues to be a key preventive control for installation or execution.

CDW’s Security Operations Center (SOC) received a Cortex XDR alert through XDR Analytics BIOC for the following reason(s):

• The process dfsvc.exe connected to kuka1.top.

Command line: "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\dfsvc.exe"

• The address kuka1.top was connected by 0 different endpoints across 0 unique days in the last 30 days.

Initial Access via Phishing

Upon CDW escalating the incident to the customer, the customer found an internal phishing ticket by the user, which stated that the user had clicked on a link received on a personal email account. In this case, the user was able to access the personal email which bypassed the corporate email anti-phishing solution and made this phishing attempt successful.

Application Execution

Upon investigation by CDW’s Managed XDR team, it was discovered that the host downloaded an unapproved software, ScreenConnectClient.exe via Chrome. Once run, ScreenConnectClient.exe facilitates the installation of a parent process — dfsvc.exe — with two further executables initiated from the level above:

> dfsvc.exe

> ScreenConnect.WindowsClient.exe

> screenconnect.clientservice.exe

In its legitimate guise, ScreenConnect™ is a software that provides remote support and remote access software solutions that enable users to connect to and control remote computers and devices over the internet. Based on threat intel lookup, the hash of the initial download of ScreenConnect after the phishing link was clicked came back as unknown (Refer to the IOC section for the hash). Our thought was that the executable was probably not ScreenConnect or that a malicious executable was injected into it, which modified it.

Dfsvc.exe is a Windows native process used for ClickOnce application installation. In this incident, the process was spawned by the unknown ScreenConnect and was used to establish a Command-and-Control connection. There have been a few cases where attackers employed this process for malicious purposes.

The causality tree for the alert was as follows:

The causality tree shows that ScreenConnect.Client.exe was downloaded via Chrome, and the executable was found in the user’s download folder. The investigation also showed that the user was referred to https[:]//kuka1[.]top after the phishing link was clicked, and ScreenConnect.Client.exe was automatically downloaded and installed from https[:]//kuka1[.]top/bin/ScreenConnect[.]exe.

This maps to the execution phase of the MITRE Attack after initial access. Since the execution of the executable was successful, this could be indicative of the absence of application control or a poorly implemented application control in the environment since the user was able to install unauthorized software.

After installation of the ScreenConnect.Client.exe, it spawned dfsvc.exe which is a ClickOnce service that allows users to execute software from a web browser. Our belief is that ScreenConnect.Client.exe injected a possible malicious code into dfsvc.exe, and it was used to install the application. It is also worth noting that the hash of ScreenConnect.Client.exe is unknown based on threat intel, which could be indicative of a threat since ScreenConnect is a well-known software.

Refer to VMRAY’s dynamic analysis report of a malicious executable that was seen to spawn dfsvc.exe. Like this case, dfsvc.exe was found to be clean and signed by Microsoft.

Persistence via DLL Side Loading:
The Screenconnect.Client.exe located at C:\Users\UserName\AppData\Local\Apps\2.0\B9K6HBD2.89G\VERYPJND.8KQ\scre..tion_25b0fbb6ef7eb094_0017.0009_7d4412487
2762e6a\ScreenConnect.ClientService.exe loaded the ScreenConnect.ClientService.dll for persistence which modified some registry values to enable ProxyBypass, IntranetName and UNCAsIntranet.

Intranet Auto Detect was disabled to avoid detection. Threat actors commonly use a DLL side-loading technique for persistence, where a DLL search order mechanism, which takes different factors into consideration on where to load a DLL in Windows, is used to plant and then invoke a legitimate application that execute a malicious payload. Also, upon lookup of the hash for the DLL, it was found that it was not signed.

C&C Connection
The dfsvc.exe was seen to establish a C&C connection to an external IP 159[.]253[.]120[.]139, which resolves to kuka1[.]top.

Discovery via RPC Calls
Based on the established connection, several commands were initiated through RPC calls to enumerate the host machine using SmartScreen since it uses a client-server model to request a service from a program located on another computer.

We were able to ascertain that data was being uploaded through the RPC calls that were made, which had arguments of collecting system information such as operating system (OS), BIOS, processor and time zone. The dfsvc.exe started ScreenConnect.WindowsClient.exe, which further spawned another ScreenConnect.Client.exe.

Possible Data Exfiltration
There was a possible data exfiltration since we saw a network connection established between the local host and the remote IP for a duration of 17 minutes 55 seconds. We also saw 6.80 MB of data being uploaded.

The domain has a Welcome message and asks for a code to join. That suggests that the site expected the user to enter a code they received in the phishing email, which would initiate the download.

Because of the security implications seen so far, the endpoint was isolated to prevent lateral movement by stopping it from moving deeper into the network in search of sensitive data and other high-value assets.

Through our threat intel, we were also aware of a vulnerability related to ScreenConnect for versions below 23.9.8 being exploited, so we tied those IOCs and did some proactive searches in the environment. This vulnerability lets the user create a new administrator account to take control of the ScreenConnect instance. We leveraged the live terminal session to check for the same behavior. Luckily, no admin account was created in this case.

Out of the three instances seen for ScreenConnect, the first one, which was downloaded, had the hash(44cc31ab875172fe40bdc27a5278122e0725d4bb664bc6a8a541b6bd7c9a7f22) which was not available on any security tool and could be a part of the exploited version. The hash for ScreenConnect.WindowsClient.exe(71602f6b0b27c8b7d8ad624248e6126970939effde785ec913ace19052e9960e) is flagged by three security vendors, and one sandbox and has version 23.9.10.

The hash for screenconnect.clientservice.exe(E9ab064ed381c29a3930f75ca3e05605c6ee07f30a69c043f576a5461de3bafc) came back clean and had version 23.9.10 as well.

It’s safe to assume that the hash of ScreenConnect.Client.exe that was downloaded and the malicious hash for ScreenConnect.WindowsClient.exe are integral parts of this phishing scam.

CDW blocked the hashes related to the incident. We terminated all the processes related to the ScreenConnect, and initiated a malware scan on the host. We deleted all the malicious files as we continued to notice outbound network activities.

We then performed a search for all the hashes in the environment to ensure no other host was running this application. Since a recent vulnerability exploit is seen for ScreenConnect, we also ran a threat hunt based on “ScreenConnect critical vulnerability bug” in the environment.

Recovery Step

As a recovery measure, disable the user account and re-image the host.

Mitigation Steps

CDW advised the customer to route all their traffic through a Web security gateway with a good anti-phishing profile to avoid such scenarios where users can access web resources that contain malware.

Application control should be in the environment, ensuring best security practices. This will block unauthorized applications from executing in ways that put data at risk.

Also, use a NGFW to block threats on Application-Layer.

IOCs Observed

• Hashes
  44cc31ab875172fe40bdc27a5278122e0725d4bb664bc6a8a541b6bd7c9a7f2271602f6b0b27c8b7d8ad624248e6126970939effd
  e785ec913ace19052e9960e7c5442121dba2a30ab9579ec08e111ded372cf9cf90fb3256f273980b975afa9

• IPs
  159[.]253[.]120[.]139
• FilePath
  C:\Users\UserName\Local\Apps\2.0\B9K6HBD2.89G\VERYPJND.8KQ\scre..tion_25b0fbb6ef7eb094_0017.0009_7d4412487276
  2e6a\
  
• Domain
  kuka1[.]top

No security vendors flagged the hashes, IP, or domain malicious. It’s advised that you run the above IOCs in the environment and do some additional checks if there are hits to make sure they are not related to a phishing attack.

As you can see, fighting phishing attacks is no easy feat, but with a managed security services provider like CDW on your side, we can assist you in navigating and resolving them with ease.

For more information about how CDW Managed Security Services can help keep your organization secure from phishing attacks and more, visit our webpage or call 800-800-4239.