By Rodrigo Montoro and Ricardo Silva

The use of services exposed on the Internet attracts criminals with multiple interests. However, we have observed a favoritism in the search for services designed to handle large volumes of data in order to convert them into cryptocurrency miners, this is because these resources are usually configured to process multiple and large requests. In recent analyzes, we were able to observe machines in these conditions, in which the Jupyter Notebook product was abused for the purpose described above.

Anyone who works, or has colleagues in the field of data science, must have heard about Jupyter Notebook, an interactive web application that allows the creation and sharing of documents with dynamic code. The product is widely used in the areas of data mining, facilitating its activities of visualization, cleaning and data exploration, in addition to allowing the mixing of code and text snippets, optimizing the creation of presentations and reports, allowing the construction of everything in a single location, as if it were an IDE (Integrated Development Environment) for the data scientist. The following image shows a basic architecture of the tool.

Basic architecture reference. Image: Jupyter


At the beginning of the analysis, we observed that the studied machines had a Docker running. As this product has been commonly used as an attack vector, we imagine that there would be the source of the compromise.

However, a single port released in the firewall of the obtained environments was an 8888, which in turn took a Jupyter server whose authentication process was configured to not require a token/password.

We found that there was little documentation on this type of behavior, limited mainly to users of GitHub exchanging information about the case. Thus, by intensifying the study of environmental conditions, we arrive at the following scenario:

1-) The server’s IP address and port were indexed on

2-) Tools that use the Shodan API can detect and connect to the Jupyter server in order to validate access via WebSocket.

Moment when the tool connects to the target via WebSocket. Image: Tempest


3-) With validated access, the attackers establish the WebSocket connection and send the miner which has commands very similar to those of a PoC published by the GitHub user harshu4 in September 2019, but with some modifications in the versions and commands.

Commands used by the threat. Image: Tempest


Original PoC script. Image: harshu4 on GitHub


4-) After executing the commands, the XMRig miner is activated.

In searches on Shodan through Tornado Server – Web Server that makes up the Jupyter Notebook application ­– we were able to observe approximately 15 thousand available servers. Many of them requiring tokens in their authentication process, but exposed.

Search for exposed Jupyter servers. Image: Shodan


Lessons learned and suggestions

Keeping in close contact with your cloud provider can be crucial in detecting attacks like this, as the company can identify unusual fluctuations in resource usage and issue alerts in a very short time.

It’s also important to check periodically whether assets in your environment are being indexed by services like Censys and Shodan. This is a relevant measure to assess if everything that is exposed to the Internet should really be in this condition.

It’s also important to monitor network traffic in order to identify any suspicious communications and periodically review permissions both in the on-premises and in the cloud environment, so that critical events such as instance activation or modifying firewall permissions must be rigorously reviewed.


MITRE ATT&CK Techniques


T1596.005 – Search Open Technical Databases: Scan Databases

T1190 – Exploit Public-Facing Application

T1059.004 – Command and Scripting Interpreter: Unix Shell

T1496 – Resource Hijacking




Files (sha256)

5db5646a8d3f5e980b28ccc69fa2b9a19d807698ca3fa6a33d8286783ac1b2df *config.json

88478b53af34395b7df22705f93161913294b3e17d00db1999a118bf28c1989a *xmrig