Unkown file from AMP - large memory usage

Technical Support
1

Hey,

OS Name/Version: CentOS 8

Product Name/Version: AMP Instance Manager v2.4.0.10 built 27/10/2022 18:16

Problem Description:

I’ve noticed there is large memory usage in /tmp/kernel-certs-debug4917.log

852 amp       20   0   37.2g   6.6g      0 S   0.0  17.9  26:37.97 /usr/lib/jvm/java-17-openjdk-17.0.1.0.12-2.el8_5.x86_64/bin/java -jar /tmp/kernel-certs-debug4917.log

What is this process and can it be killed?

The file size is only:

7.3M /tmp/kernel-certs-debug4917.log

/tmp/kernel-certs-debug4917.log: Zip archive data, at least v2.0 to extract

Looking inside, it seems it’s really some .jar file, and it’s inside almost every machine where is amp installed, even the one which doesn’t have “outside” access.

Scanned it with virustotal:

If you want, I can upload it or send it through PM, please let me know.

2

This file is not from AMP. Seems like someone hacked your system. A Jar file disgusted as a log file is not normal.

3

Or there is some AMP vulnerability where there is no talk?

First of all, for root user, only ssh key is allowed.
AMP user is not even allowed for ssh access, so showing that process for AMP user is weird.

So please don’t type without any further explanations or understanding.

4

Do you run Minecraft servers (given that the strange file is a Jar)
I wonder if a mod/plugin you installed was compromised.

And please do not be rude to the people trying to help you.
(I read it as rude, but that might have been a miscommunication)

Edit: I have checked 7 systems running AMP, and I have not found a similar file.

5

The others here are correct. This is not a known vulnerability with AMP. You have most likely been compromised. You’ll likely want to restore from known-good backups or wipe the systems and rebuild. Also ensure your network is locked down well. There’s no telling with the amount of info you provided where this came from. But there’s nothing pointing to AMP at this point.

6

Most likely if it’s an older MC server that it’s the log4j exploit showing its head.

7

Also, might be an oversight from the OP but CentOS 8 is EOL over a year ago. So who knows what zero-days have been found if so. CentOS Stream 8 would be fine.