SWNEpisode9

From Security Weekly Wiki
Jump to navigationJump to search

Recorded February 4, 2020 at G-Unit Studios in Rhode Island!

Episode Audio

Hosts

  •  
    Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  •  
    Jason Wood
    Threat hunter at CrowdStrike, penetration tester, sysadmin, and Founder of Paladin Security.
  • Security News

    Expert Commentary: Jason Wood

    New Iranian Campaign Tailored to US Companies Utilizes an Updated Toolset

    I was reading about some phishing campaigns when I ran across this analysis by Intezer of a new campaign by Helix Kitten (aka APT34, aka OilRig) that was really interesting to read. The interesting part was the evolution of tools used by the threat actor in the campaign. The main company that is the target of this campaign is Westat, which provides services to US federal agencies, state and local governments, and other businesses. One of those services is an employee satisfaction survey that Westat can tailor to a client and then send out to their employees. The threat group decided to use what appears to be a Westat employee survey as the lure and started sending it out to various companies.

    The phish contains a spreadsheet named something like “survey.xls”, but it appears as a blank document until macros are enabled. Once macros are enabled, the survey is displayed. The survey itself looks pretty good. In the screenshot that I saw of the document, the branding appears legit, the grammar looks good, and none of the phrases used raises an immediate alarm. In fact, Westat sounded a little annoyed in a released statement that said this was the result of “a bad actor stealing the Westat brand name and logo.” So it was a good phish.

    All that sounds normal, so let’s get to the interesting part. Here’s how the compromise works. The user enables macros and starts to fill in their survey. The VBA code used in the macro extracts a zip file and writes a file named “client update.exe” to C:\Users\<username>\vals\Client Update.exe”. It then creates a scheduled task to execute the payload 5 minutes after installation. It also creates scheduled tasks to execute the payload every time the user logs into the host. To prevent execution, defenders have 5 minutes to detect the extract (if it wasn’t prevented) and remove the executable. That’s a tough one to pull off.

    The malware itself is a modified version of the TONEDEAF malware and Intezer has labeled this iteration TONEDEAF 2.0. They go into some comparisons of the code in the new version and the previous version. TONEDEAF 2.0 is a backdoor that allows the operators to execute arbitrary shell commands on the infected host. It also doesn’t include predefined commands to be run. The C2 appears to be a mix of HTTP and HTTPS requests and responses. So perhaps they are in the process of moving to an HTTPS only implementation. The C2 requests use an HTTP parameter named “set” and set it to a 3 digit server ID and 3 digit client ID.

    There appears to be a fair bit of code reuse in the malware as well. Intezer shows the original code next to the updated code side by side. Even if you aren’t a developer, you can see the same variables names being used, the structure looks very similar, and in other places the code is identical. One change is the move from 32-bit to a 64-bit payload.

    One thing that I thought was kinda funny was when Intezer connected to the C2 infrastructure in a browser, the page didn’t load correctly. The operators have some mistakes in mime-types set to the CSS and this results in a very broken looking copy of docs.microsoft.com. Another sign that all is not as it should be is in the actual Excel document sent in the phish. The metadata still lists the original language of the document as Arabic. Both of these issues would only be seen by someone doing some analysis though since a normal user wouldn’t be connecting to the C2 server or be looking at metadata.

    So what are the lessons to take away from this? First, if you are receiving emails from Westat with a spreadsheet claiming to be an employee satisfaction survey, you might not want to open it. Second, I think it’s worth reading through the write up by Intezer and becoming acquainted with how this works. Yes, there are some IOCs for the current infrastructure that you can monitor for. That will change over time. I think it is also good to see how Intezer went through their analysis and tied it back to the information previously documented by Fireeye on this actor. Of course, it is possible that another group took the code initially attributed to Helix Kitten and modified it for their own use. It might not be them at all. But it does show the evolution of the tools used over time. There definite similarities that appear to tie these all together. To be honest, it looks like any other software development team that I’ve worked with. The code changes over time, but a lot of original stuff gets brought along with it.

    As we work in this time where the industry is now tying activity back to threat actors, I think it’s worth getting familiar with how some of this analysis is done. Even if you aren’t doing threat analysis yourself, it’s good to understand the workflow that others are using to perform it. It provides you with a bit more confidence when you look at a report and can make your own decision on how well the reporting group has done at doing their homework.