Hacker News new | past | comments | ask | show | jobs | submit login
Nazar: Analyzing malware that was uncovered in leaked NSA files (checkpoint.com)
198 points by Megabeets on May 5, 2020 | hide | past | favorite | 28 comments



I believe the use of open source tools to accomplish their tasks is interesting. Using "living off the land" open source tools also hinders researchers when trying to attribute an attack to a certain country.

I found malware that was installed remotely on to millions of Android users under the government "Life Line" program that also used readily available open-source code found on GitHub.

The malware used an open sourced virtualization shared object library (.so) named "VirtulApp" and also an open source software development kit called "TalkingData"

Both code sources were found on GitHub.

The malware in question hides its icon from the users screen but can be found under Settings/Apps but shows an icon for a well-known "Antivirus/Cleaner" app that has been removed from the Google Play store many times. The malware also shares much of the cleaner app's SDK's and excessive permissions.

The malicious app also contains several encrypted files in its assests directory that are decrypted into executable java .jar files to expand it's functionality.

Kaspersky Labs names this particular malware variant "Necro"

5a5ab39960d3b96be2b8bbea99477e6f


> I believe the use of open source tools to accomplish their tasks is interesting. Using "living off the land" open source tools also hinders researchers when trying to attribute an attack to a certain country.

That is one conclusion. But, given that there seems to be a significant amount of code that's custom (the filesystem module), I'm not sure what that would accomplish. If that too was opensource and there was a tiny amount of glue code, then it would make some sense. Leave the most suspicious hooks(like all input device monitoring) to well known tools.

Based on the report, it is more likely that whoever group created it didn't have much knowledge. Using the Shutdown Alarm and pissing all over the system just to accomplish such a tiny task is difficult to justify, and that's what drew undue attention.


The cultural significance of the name is pretty ironic: https://en.wikipedia.org/wiki/Nazar_(amulet)


Researchers usually pick a name when they have started looking at a collection of samples, and don't really have knowledge of what is going on or who the threat actor is yet.

The authors call it خضر, a guardian angel type from the Quran that shares secret knowledge.


It is also the Arabic for the adjective green (plural) and the name comes from Arabic as well, and a prophet some i even heard some suggest is Buddha, in addition to other more obvious Wikipedia suggestions.

That aside, this is what drives me nuts about threat Intel: we use enough googlable Persian words and give enough hints we know Persian in our code and opsec and people have a full dossier that confirms we're Iranians? I assume there is more depth to their claims but you have to work for the reporting company to know it which makes the whole subset of the industry dubious if you ask me (but we know no one is, lol).


Did you forget the whole "there was some Russian in the metadata so it must have come from Russia" conclusion of CrowdStrike?


I think you're thinking of khidr(?)


you forgot the most common meaning : vegetables :) you know hackers can be silly sometimes


That explains why it's being used for the root directory.


> Territorial Dispute

  def path_normalize(path):
      try:
          path = re.sub('%(.+)%', (lambda m: ('%{0}%'.format(m.group(1)) if (m.group(1) not in datastore.ENV_VARS) else datastore.ENV_VARS[m.group(1)])), path)
      except:
          tedilog.error(...)
      return path
What a terrible way to write

  return re.sub(r'%(.+)%', lambda m: datastore.ENV_VARS.get(m.group(1), m.group(0)), path)


Does yours catch the exception?


Apparently I didn’t include the parts that don’t need to be changed. (Actually, with the correct input type, this piece of code shouldn’t raise any exception period other than BaseExcept like KeyboardInterrupt, which usually shouldn’t be caught like this either. So I would omit the try...except myself.)


Also:

  if result:
    return True
  return False


I’m not a python programmer, but isn’t this a good way of turning truthy or falsey answers into actual Boolean values?


If you want to do that just use bool().


So if I want the USA out of my system, all I have to do is create some dummy exes, dlls and regkeys on my system?


No. Depending on the signature you trigger one of two things will likely happen:

If it is an allied partners tool, they will reach out to the other intelligence agency and deconflict. The other agency will confirm access and share with the US.

If it is a foreign toolkit (Iranian in this example), they have likely reverse engineered the tools and will piggy-back on them to access your system. Another option is 4th party collection where they use access to Iranian networks to siphon off the data the Iranians have collected on you.

If either of these turn out to be bogus, it will be treated as a false positive and they will reinfect your machine ignoring the warning.


Kinda hard to get them out of your system if you run Windows which is made by a company located in the USA and that sends data constantly to their servers, some of which are based in the states.


I wonder what kind of system you can create without having any specific country dependency at all.

Certainly the breakdown in influence for say your standard PC will be hard to avoid any USA input, no matter the OS due to code submissions/contributions and then that's presuming honest location actors. Let alone binary blobs for drivers.

So hardware and OS, you will be pushed to avoid any USA influence.

After all USB, Intel did that, clearly USA influence, as are many standards, so I dare say that unless you build your own CPU and everything, you will be having some USA influence upon your system, one way or another. Let alone many other countries.

Heck even all those 6502/Z80 systems - USA companies invented those, so not even the humble Sinclair ZX81 would still have USA in there.

Though I'm sure that Russia and China do have computers without any USA in them. But then, you start to see how that works.

Gets down to trust, which for some can be a choice of sandwiches they don't like but they need to eat. Most like the sandwiches, some like all three flavours and some make their own flavours, but using ingredients from all three. Some will bake their own bread and use the standard ingredients. Very few will make their own flour, bread, ingredients all by themselve. Coz they still use an over and knife made by somebody else. See, the efforts to exclude any potential influence is so deep that to completely remove them all is beyond the scope of many. So gets down to a balance, a trade off of trust.


It's all about the hardware now, building out your own components isn't going to be easy, get a microprocessor that was build pre-1998 or try an open source hardware solution but who wants to do that..


Seems like it. In other viruses (and I'm sure the NSA does this too), your system might actually be scanned for other known viruses and removed. In the NSA's case, these could be enemy threat actors.


It used to be standard operating practice as an attacker to close the holes through which you yourself gained access to prevent others from taking your prize.

Ironically the most secure and cheapest thing a company could do was get compromised by a competent attacker who only wanted to launder small amounts of data or CPU cycles through your network, and in exchange keeps your servers all patched and up to date for you to keep out other attackers.


So be an e-aphid and let the kindly e-ants farm you?


e-symbiosis! e-harmony!


W-what if you use Linux? :B


use Wine.


I'm sure the Linux kernel would never be compromised by state actors, even if a retired US Army general was on the board of directors[1] of the most popular Linux distro, or that the US' most infosec oriented intel agency didn't come up with the main method for RBAC with it[2]. Or that hardware and the numerous bits of firmware that control it would ever get back-doored by any state actor!

"OpenBSD co-founder Theo de Raadt, cited as a top el8 target, angrily refused to discuss the compromise in late July of a file server maintained by the open-source, Unix-based operating-system project. On Aug. 1, a dangerous Trojan horse program was discovered amid the code for OpenBSD, which is used by thousands of organizations and renowned for its security.

While de Raadt wouldn't comment on whether there were any suspects in the case, the lead article in the latest el8 newsletter, published in early July, contains an obvious smoking gun. The article begins with several lines of screen-display from what appears to be an OpenBSD.org system. The "w-command" output suggests that attackers had access to one of de Raadt's accounts."[3]

[1]https://www.redhat.com/en/about/press-releases/shelton

[2]https://www.nsa.gov/what-we-do/research/selinux/documentatio...

[3]https://www.cc.gatech.edu/computing/acmnews/msg00221.html


And there's the time someone did try to sneak something into an open source kernel [1].

The cool thing is, anyone can audit the kernels any time, and even if Theo's or Linus's accounts get compromised, the backdoor will be observable by everyone.

Try that with Windows: we have no idea what's in there, we never will, and MS has zero incentive to tell us.

1. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: