Iranian Campaign, Twitter Conspiracy, Bangladesh Hacked – SWN #9 | SC Media
Third-party risk, IOT, Mobile, Bug bounties

Iranian Campaign, Twitter Conspiracy, Bangladesh Hacked – SWN #9

February 4, 2020



This week, a Everyone wins in Iowa, Twitter has conspiracy theories?, Hackers steal billions and don't get caught, Iowa Election Apps secured by "obscurity", and the top 24 passwords found on the Dark Web. Jason Wood talks about a New Iranian Campaign Tailored to US Companies Utilizes an Updated Toolset.

Visit for all the latest episodes!

Full Episode Show Notes

To learn more about our sponsors visit: The Security Weekly Sponsor's Page

Iranian Campaign, Twitter Conspiracy, Bangladesh Hacked

Security Weekly News -- Week of 4 -- February -- 2020

  1. Security through obscurity? Iowa Caucus uses the tried and failed secrecy method on voting apps.
  2. ...and failed, but it wasn't due to security issues supposedly.
  3. Shadow, Inc. develops failed Iowa App,
  4. Everyone wins in Iowa.
  5. Iowa app described as "hastily conceived" and "a mess".
  6. Russian criminals funding Russian Cyber challenges.
  7. AppSec Concerns Drove 61% of businesses in study to move away from commercial apps.
  8. Twitter bans Zero Hedge Account after it doxxed a Chinese Scientist.
  9. Facebook pays a half a billion settlement over biometric privacy.
  10. Hackers stole a billion dollars in 2016, Mandiant Probe released.
  11. Yes. Virginia, your Macbook is vulnerable to malware.
  12. Device Aware 2FA can defeat social engineering?
  13. The most popular categories and passwords found in over a billion dark web breaches.
  14. Anonymized Data is Meaningless Bullshit.
  15. Enterprise hardware still vulnerable to DMA attacks and Live Memory Captures.
  16. A Performance Artist creates traffic jams on google maps using 99 luftballons.
  17. 99 LuftBallons

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>valsClient 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 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.


[caption id="attachment_210" align="alignleft" width="120"]Doug White Doug White - Professor[/caption] [caption id="attachment_210" align="alignleft" width="120"]Jason Wood Jason Wood - Founder; Primary Consultant[/caption]


[audio src=""]

prestitial ad