How does pandora.x86 infect cloud servers?

merlin

5/5/24, 11:47 AM

We have a cloud server instance hosted at vultr. A previous instance at this provider has been infected by pandora.x86 a few weeks ago, causing 100% CPU load and over 1TB of traffic. (We believe it is this one, due to the name of the process running 100% CPU: https://blog.cyble.com/2022/03/15/deep-dive-analysis-pandora-ransomware/ )

The quickest solution for us was to destroy the server and rebuild from scratch. Now, two weeks later the rebuild cloud instance has the same issue. While rebuilding the server we took extreme caution to secure everything to our best knowledge and we can not think off any security leek that might have caused it. It is running on a 22.04 Ubuntu system with patches installed only about 2 weeks ago.

Our other systems are not affected but this service is the only one running at vultr. The same code base is also running at other providers without issues. The server has been now shut down.

What would be the best approach to track down the issue in order to prevent infection of a replacement system?

Here is a list of python modules we run: We run those services: Docker, node exporter, silenium, prometheus, python, modules from python (List added to the question) and our own code in python.

bcrypt==3.2.2
beautifulsoup4~=4.11.1
certifi==2022.6.15
cffi==1.15.0
charset-normalizer==2.0.12
cryptography==37.0.2
extruct==0.13.0
html-text==0.5.2
html5lib==1.1
idna==3.3
isodate==0.6.1
jstyleson==0.0.2
lxml==4.9.0
mf2py==1.1.2
mysql-connector-python==8.0.29
numpy==1.22.4
pandas==1.4.2
paramiko==2.11.0
protobuf==4.21.1
pycparser==2.21
pycrypto==2.6.1
PyNaCl==1.5.0
pyparsing==3.0.9
pyRdfa3==3.5.3
python-dateutil==2.8.2
pytz==2022.1
PyYAML==6.0
rdflib==6.1.1
rdflib-jsonld==0.6.2
requests==2.28.0
six==1.16.0
soupsieve==2.3.2.post1
sshtunnel==0.4.0
urllib3==1.22
w3lib==1.22.0
webencodings==0.5.1
argparse==1.4.0
sentry-sdk==1.7.2
rabbitmq==0.2.0
pika==1.3.0
scikit-learn==1.2.2
selenium==4.5.0
pytrends==4.8.0
scipy==1.9.3
mysql==5.7.24
bs4==0.0.1
yaml==0.2.5

0 + 6

security

ubuntu

malware

ransomware

HBruijn

5/5/24, 12:05 PM

At first glance: the analyses might be incorrect when you go from *"we have a misbehaving Ubuntu server"* and reach a conclusion *"it was infected by malware designed for Windows systems"* - note the generic https://serverfault.com/questions/218005/how-do-i-deal-with-a-compromised-server

vidarlo

5/5/24, 12:11 PM

What services were you running?

HBruijn

5/5/24, 12:12 PM

*"What would be the best approach to track down the issue in order to prevent infection of a replacement system?"* - don't destroy the old server, make a snapshot, null-route / remove network access and investigate if you can find a flaw that was used to compromise the system and/or hire somebody to that for you. - as to why other systems running elsewhere have not been infected, that may simply be luck on your part and not indicative that those systems are not vulnerable.

merlin

5/5/24, 12:18 PM

@vidarlo We run Docker, node exporter, silenium, prometheus, python, modules from python (List added to the question) and our own code in python.

Greg Askew

5/5/24, 12:20 PM

If by "cloud server" you mean not dedicated hardware, there's no assurance this wasn't compromised from the "providers" infrastructure. Also it sounds like there is *zero* EDR/forensic capability here. Information Security in 2023 shouldn't be roaming the countryside on a bug hunt.

vidarlo

5/5/24, 12:22 PM

So what docker containers? Insecure container? Insecure python module? Insecure python code? I don't see any way we can diagnose this. You should look into providing forensic capabilities for the future.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How does pandora.x86 infect cloud servers?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.