Tag: malware

Brushaloader gaining new layers like a pro

Date of publication: 19/11/2019, Michał Praszmo

Yo dawg, I heard you like droppers so I put a dropper in your dropper

On 2019-11-18 we received a report that some of Polish users have began receiving malspam imitating DHL:

In this short article, we’ll take a look at the xls document that has been used as a (1st stage) dropper distributing another well-known (2nd stage) dropper – brushaloader.

Read more

Detricking TrickBot Loader

Date of publication: 05/02/2019, Michał Praszmo


    TrickBot (TrickLoader) is a modular financial malware that first surfaced in October in 20161. Almost immediately researchers have noticed similarities with a credential-stealer called Dyre. It is still believed that those two families might’ve been developed by the same actor.

    But in this article we will not focus on the core itself but rather the loader whose job is to decrypt the payload and execute it.
    Read more

    MWDB – our way to share information about malicious software

    Date of publication: 16/01/2019, CERT Polska

    Analysis of current threats is one of the most common challenges facing almost any organization dealing with cybersecurity. From year to year, it also becomes a harder nut to crack, being undoubtedly influenced by the growing scale of activities undertaken by criminals and the degree of their advancement. In the face of this situation, efficient exchange of information between researchers is a key issue.
    Read more

    Dissecting Smoke Loader

    Date of publication: 18/07/2018, Michał Praszmo

    Smoke Loader (also known as Dofoil) is a relatively small, modular bot that is mainly used to drop various malware families.

    Even though it’s designed to drop other malware, it has some pretty hefty malware-like capabilities on its own.

    Despite being quite old, it’s still going strong, recently being dropped from RigEK and MalSpam campaigns.

    In this article we’ll see how Smoke Loader unpacks itself and interacts with the C2 server.

     

    Read more

    Backswap malware analysis

    Date of publication: 19/06/2018, Hubert Barc

      Backswap is a banker, which we first observed around March 2018. It’s a variant of old, well-known malware TinBa (which stands for “tiny banker”). As the name suggests, it’s main characteristic is small size (very often in the 10-50kB range). In the summary, we present reasoning for assuming it’s the same malware.
      Read more

      Ostap malware analysis (Backswap dropper)

      Date of publication: 01/06/2018, Paweł Srokosz

        Malicious scripts, distributed via spam e-mails, have been getting more complex for some time. Usually, if you got an e-mail with .js attachment, you could safely assume it’s just a simple dropper, which is limited to downloading and executing malware. Unfortunately, there is a growing number of campaigns these days, where script doesn’t exit after downloading sample. Instead of ending its life – it remains active, waiting for additional commands or more samples to fetch. Some of the examples are: vjw0rm used in Vortex ransomware campaigns and Ostap – the main protagonist of our story.

        This article is an introduction to Backswap malware analysis, which is a second-stage malware downloaded by Ostap. Our analysis of Backswap malware will be published soon!

        Read more

        Analysis of a Polish BankBot

        Date of publication: 16/01/2018, Agnieszka Bielec


          Analysis of a Polish BankBot

          Recently we have observed campaigns of a banking malware for Android system, which targets Polish users. The malware is a variant of the popular BankBot family, but differs from the main BankBot samples. Its victims were infected by installing a malicious application from Google Play Store. We are aware of at least 3 applications that were smuggled to Google Play Store and bypassed its antivirus protection:

          • Crypto Monitor
          • StorySaver
          • Cryptocurrencies Market Prices

          The last one is an older version which was uploaded to VirusTotal on 13.10.2017.

          According to the ESET’s analysis “Crypto Monitor” and “StorySaver” reached between 1000 and 5000 downloads. In each case, the malware pretended to be a benign, useful application.

          Read more

          Analysis of Emotet v4

          Date of publication: 24/05/2017, Paweł Srokosz

          Introduction

          Emotet is a modular Trojan horse, which was firstly noticed in June 2014 by Trend Micro. This malware is related to other types like Geodo, Bugat or Dridex, which are attributed by researches to the same family.

          Emotet was discovered as an advanced banker – it’s first campaign targeted clients of German and Austrian banks. Victims’ bank accounts were infiltrated by a web browser infection which intercept communication between webpage and bank servers. In such scenario, malware hooks specific routines to sniff network activity and steal information. This technique is typical for modern banking malware and is widely known as Man-in-the-Browser attack.

          Next, modified release of Emotet banker (v2) has taken advantage of another technique – automation of stealing money from hijacked bank accounts using ATSs (Automated Transfer Systems, more informations on page 20 of CERT Polska Report 2013). This technology is also used in other bankers. Good examples are ISFB (Gozi) or Tinba.

          At the beginning of April 2017, we observed wide malspam campaign in Poland, distributing fraudulent mails. E-mails were imitating delivery notifications from DHL logistics company and contained malicious link, which referred to brand-new, unknown variant of Emotet.

          Malware distributed in this campaign differed from previously known versions. Behavior and communication methods were similar, but malware used different encryption and we noticed significant changes in its code. Thus we called this modification version 4.

          Read more

          Sage 2.0 analysis

          Date of publication: 14/02/2017, Jarosław Jedynak

          logo

          Introduction

          Sage is a new ransomware family, a variant of CryLocker. Currently it’s distributed by the same actors that are usually distributing Cerber, Locky and Spora.

          In this case malspam is the infection vector. Emails from the campaign contain only malicious zip file without any text. Inside zip attachment there is malicious Word document with macro that downloads and installs ransomware.

          After starting the ransomware, Windows UAC window is shown repeatedly until the user clicks yes.

          At the end the encryption process is started and all files are encrypted:

          Ransom message directs us to panel in the Tor network, but before we can log in we have to solve a captcha:

          And finally we are greeted with “user-friendly” panel:

          We can even chat with malware creators:

          Interestingly, this ransomware doesn’t remove itself after encryption, but copies itself to %APPDATA%\Roaming directory and re-encrypts all files after every reboot (until the ransom is paid).

          Technical analysis

          After this short introduction, We’ll focus on the technical side (because Sage 2.0 is not completely a generic ransomware, few things are rather novel).

          Main function of binary looks like this:

          As we see, there is a lot of fingerprinting and checks, though most of them are quite standard. More interesting features include:

          Debug switch

          Probably something didn’t work on the first try, so there is a debug command line parameter to test that configuration data is set correctly:

          And surely enough, this debug parameter does what it should:

          Someone probably forgot to remove this from the final version, because this is clearly a debugging feature.

          Locale Check

          Sage 2.0 creators like some nations more than others:

          This checks user keyboard layouts:

            • next == 0x23 -> Belarussian
            • next == 0x3F -> Kazakh
            • next == 0x19 -> Russian
            • next == 0x22 -> Ukrainian
            • next == 0x43 -> Uzbek
            • next == 0x85 -> Sakha

          We’re a bit disappointed that Polish didn’t make it on the exception list (If Sage creators are reading this: our locale is 0x15).

          Location fingerprinting

          Sage is trying to get it’s host location by querying maps.googleapis.com with current SSID and MAC:

          Canary file

          Before encryption Sage checks for existence of a special debug file:

          Thanks to this, malware creators don’t have to worry about accidentally running the executable and encrypting their own files.

          Finally, if the file is not found, encryption is initiated.

          Extension whitelist

          Of course, not every file is encrypted – only files with whitelisted extension are touched:

          Encryption

          As usual, this is the most interesting thing in ransomware code. Sage 2.0 is especially unusual because it encrypts files with elliptic curve cryptography.

          The curve used for encryption is y^2 = x^3 + 486662x^x + x over the prime field defined by 2^255 – 19, with base point x=9. These values are not arbitrary – this curve is also called Curve25519 and is the state of the art in modern cryptography. Not only it’s one of the fastest ECC curves, it’s also less vulnerable to weak RNG, designed with side-channel attacks in mind, avoids many potential implementation pitfalls, and (probably) not backdoored by any three-letter agency.

          Curve25519 is used with hardcoded public key for shared secret generation. The exact code looks like this (with structures and function names by us):

          This looks like properly implemented Elliptic Curve Diffie-Hellman (ECDH) protocol, but without private keys saved anywhere (they are useful only for decryption and malicious actors can create them anyway using their private key).

          This may look complicated, but almost all those functions are just wrappers for ECC primitive – named CurveEncrypt by us. For example, computing matching public key is curve25519(secretKey, basePoint) – where basePoint is equal to 9 (one 9 and 31 zeroes).

          Shared key computation is very similar, but instead of using constant base point we use public key:

          Due to the design of Curve25519, converting between any sequence of random bytes and a secret key is very easy – it’s enough to mask few bits:

          And, also because of this, secret key generation is completely trivial (it’s enough to generate 32 random bytes and convert them to the secret key):

          That’s all for the key generation. What about file encryption? Files are encrypted with ChaCha (unconventional algorithm, again) and key is appended to output file – but after being encrypted with Curve25519:

          AppendFileKeyInfo fucntion appends sharedKey and pubKey to the file:

          ChaCha is not very popular algorithm among ransomware creators. It’s very closely related to Salsa20 which was used in Petya ransomware. We don’t know why AES is not good enough for Sage – probably it’s only trying to be different.

          In other words, there are two sets of keys + one key pair for every encrypted file:

          After ransomware finishes we know only my_public, sh_public, fl_shared, but we need chachakey to actually decrypt the file.

          This encryption scheme is quite solid because it makes offline encryption possible – there is no need to bother connecting with C&C and negotiating encryption keys – the public key is hardcoded in binary and because of asymmetric cryptography decryption is impossible. Assuming that malware creators didn’t make any drastic implementation mistakes (and we have no reason to suspect that they did), recovery of encrypted files is impossible. Of course, it’s always possible that master encryption key will eventually be leaked or released.

          Additional information

          Yara rules:

          Hashes (sha256):

            • sample 1, 362baeb80b854c201c4e7a1cfd3332fd58201e845f6aebe7def05ff0e00bf339
            • sample 2, 3b4e0460d4a5d876e7e64bb706f7fdbbc6934e2dea7fa06e34ce01de8b78934c
            • sample 3, ccd6a495dfb2c5e26cd65e34c9569615428801e01fd89ead8d5ce1e70c680850
            • sample 4, 8a0a191d055b4b4dd15c66bfb9df223b384abb75d4bb438594231788fb556bc2
            • sample 5, 0ecf3617c1d3313fdb41729c95215c4d2575b4b11666c1e9341f149d02405c05

          Additional information: