Under Attack (or attacking other servers)

SYSTEM INFORMATION
OS type and version Latest
Virtualmin version Latest

Reported Activity: Intrusion Attempts
Abuse Time: 7 May 2022 07:48:49 GMT

  • Log Extract:
    <<<

=============================================================================
Current records of unwanted activities toward our server(s) on file;
the second field designates our server that received the unwanted connection;
if this is a webserver log, the [VirtualHost] designates the visited website.

Source IP / Targeted host / Issue processed @ / Log entry

=============================================================================

  • Comments:
    <<<
    ========== X-ARF Style Summary ==========
    Date: 2022-05-06T13:56:15+02:00
    Source: 52.56.159.6
    Type of Abuse: Portscan/Malware/Intrusion Attempts
    Logs: 52.56.159.6 - - [06/May/2022:13:56:13 +0200] “GET /wordpress/ HTTP/1.1” 301 554 “-” “-” [VirtualHost: www.flantua.nl]

To whom it may concern,

52.56.159.6 is reported to you for performing unwanted activities toward our server(s).

If 52.56.159.6 is a (CG)NAT gateway, use the following packet data.
Time stamps are in NTP-synced Unix seconds, time zone UTC (GMT, +0000);
convert to regular date and your time zone at https://www.epochconverter.com/
Only the 25 most recent connections are shown per connected host.

1651838173.725917 IP 52.56.159.6.55484 > 91.190.98.84.80: Flags [S], seq 3049094662, win 62727, options [mss 1460,sackOK,TS val 3895387366 ecr 0,nop,wscale 7], length 0
1651838173.791000 IP 52.56.159.6.55486 > 91.190.98.84.80: Flags [S], seq 3428541740, win 62727, options [mss 1460,sackOK,TS val 3895387429 ecr 0,nop,wscale 7], length 0
1651838173.817804 IP 52.56.159.6.38348 > 91.190.98.84.443: Flags [S], seq 3234613947, win 62727, options [mss 1460,sackOK,TS val 3895387457 ecr 0,nop,wscale 7], length 0
1651838173.886990 IP 52.56.159.6.55484 > 91.190.98.84.80: Flags [F.], seq 3049094722, ack 2836283399, win 487, options [nop,nop,TS val 3895387527 ecr 2089922752], length 0
1651838173.888117 IP 52.56.159.6.55486 > 91.190.98.84.80: Flags [F.], seq 3428541804, ack 3772657771, win 487, options [nop,nop,TS val 3895387527 ecr 1272392734], length 0
1651838173.888152 IP 52.56.159.6.38348 > 91.190.98.84.443: Flags [F.], seq 3234614791, ack 2119125071, win 443, options [nop,nop,TS val 3895387527 ecr 456728983], length 0

You need to explain what this is.

Where/who did this report come from? I assume these domains are on your server and you manage a server with that IP?

Sorry, I removed much of the context as I didn’t want to inundate you with information, but as you ask I suppose this is relevant info:

We have not received a response regarding the abuse report implicating resources on your account. Failure to respond could lead to possible mitigation against the implicated resources.

In order to resolve this report please reply to this email within 24 hours with the corrective action taken to cease the activity.

Required Actions: investigate root cause

AWS Account ID: 209723503314
Implicated Resource:Lightsail
Private IP : Public IP: 172.26.10.4 : 52.56.159.6
Reported Activity: Intrusion Attempts
Abuse Time: 7 May 2022 07:48:49 GMT

The best recourse in this case is to create a new Lightsail instance from a snapshot taken well before this abuse notice was first received, for instructions on creating a new instance from a snapshot see: Creating an instance from a manual snapshot in Amazon Lightsail | Lightsail Documentation

If you do not have a such snapshot, please consider creating a new Lightsail instance from scratch.

To prevent further abuse from your new Lightsail resource(s), AWS Trust & Safety has the following recommendations:

• Review Lightsail documentations on Security best practices: Search Results – Overviews | Lightsail Documentation
• Ensure that you use strong and complex passwords for administrative access.
• Ensure that you are taking your Lightsail snapshots on a regular basis. Also consider utilizing Automatic Snapshots feature to automate this process: Enabling or disabling automatic snapshots for instances or disks in Amazon Lightsail | Lightsail Documentation
• Ensure latest OS patches and security updates have been applied. If your Lightsail is running a content management platform such as Wordpress, also ensure their applications and plugins are kept up to date as much as possible. Any unnecessary applications and plugins should be removed.
• Consider moving administrative access ports, such as TCP 22 or 3389, to non-default port and enhancing site security with Lightsail firewall features : Enhancing site security with new Lightsail firewall features | AWS Compute Blog
• Ensure you are monitoring Average CPU Utilization, Incoming Network Traffic, and Outgoing Network Traffic regularly and look for any abnormalities, such as unusual spikes.

Please remember that you are responsible for ensuring that your resources and all applications are properly secured.

If you require further assistance with resolving this abuse report/complaint please see: Review and respond to an AWS abuse report

I’m afraid I need to start again as I failed to take the suggested snapshots :pensive:

I’m still not able to make any sense out of this. Where did the logs above come from? What are we supposed to see in them?

I am able to gather that you have an Amazon Lightsail instance? And, the public IP of this instance is 52.56.159.6.

And, maybe(?), the reported activity is attacks on someone else’s WordPress? But, also port scanning was happening from your server?

Unless you were running malware intentionally, it’s safe to say you have an exploitable web app running and it was exploited. It could be any web app, but I’m inclined to say some WordPress plugin, since WordPress exploits often try to replicate themselves via the same vector(s). But, any way in is a way to build a botnet to perform further attacks.

I can’t tell you what went wrong. You haven’t told us anything that would help figure that out. You know infinitely more than we do about who has access to your server and what applications (and plugins/themes for those applications) you are running. That’s how they got in, almost certainly (unless you have reason to suspect a root escalation, in which case you pretty much must start over, you can never trust a system that has been rooted.

If it’s a non-root exploit, you have the ability to figure out what’s going on. If it’s been rooted, there may be no trail in the logs. Figure out which domain/user is responsible (ps, w, lastlog, top or htop, and looking at access/error logs for unusually high activity for a given user) and then search their home for clues. A user-level exploit will be mostly limited to existing in /home (and maybe /tmp, depending on config), so once narrowed down to a single user, you can try to figure out how they got it.

Yup looks like that while the first ( only) abuse report i see is from feb 2022 on abuseip…

If this is one of your server ip’s 52.56.159.6 ?

Better while cleaning up is mmm depending you find all a risk that stay’s

To find and clean could also be more work, but i don’t know how much work clean install and restore backups is, restore you take care that accounts are closed from outside other then you then check again before going online . ( you can handle that with the firewall)

Also all you clients need new passwords, and better for all mail to.

( if you clients has received mail with passwords in it for other external services and not set , changed there passwords themselves then they should change those passwords ofcourse)
This is often forgotten if server rooted they have acces to mail of your clients if IMAP then they could read mails with text passwords in it.

Not only passwords i advice if possible use also other new usernames!

@Joe if non root access but access to 1 or more account they (could also have) do have acces to mail boxes from those accounts right?

(Or do you mean if only webspace access to put some cullprit on doesn’t mean mail accounts are comprimized. ? )

Probably yes. The domain owner has group ownership of the mailboxes of users, so they can at least read that mail if they obtain a shell. Whether they obtain a shell depends, once again, on how they got in. It’s sometimes possible to exploit a bug in a web app/theme/plugin that allows varying levels of exploitation. Some exploits just allow sending email through the system, so it gets enlisted into a spam botnet. Some exploits allow placing arbitrary files on the file system and then running them, which is generally a user level shell exploit (unless you’re using mod_php, in which case it is potentially a much more serious exploit, though still not a root level exploit).

In this case, if the computer was being used to do port scans, it implies at least a user-level shell exploit. It could be worse even than that (a root exploit, but that would likely require there to have been multiple security holes…not just a buggy web app). There are no known security vulnerabilities in Webmin/Virtualmin, and haven’t been in quite a while, so I don’t believe it was the attack vector (but if it were, it would be very serious…Webmin runs as root, so if compromised in a serious way, it’s a root exploit…though most reported security issues for many years have been things like potential XSS/CSRF, which are tricky to exploit).

I don’t understand what you’re asking. But, if an attacker gains shell access as a domain owner user (or is able to arbitrarily add executable files to the site, since they could upload a web shell), then the mailboxes of the domains users can be assumed to be compromised, as well, even if the attacker cannot directly login to those mailboxes via POP/IMAP or obtain a shell for those users.

This to make clear mailboxes are not safe ( probably in this case), especially where info’s for login credentials, or reset passwords is or was possible for whatever services.

Take care of those Custommers then

Good luck

Yes, it’s pretty serious when an attacker gets a shell on a system. Virtualmin 8 will mitigate some of the mailbox concerns, as we’re building a new mail stack that will work quite differently (there are some trade offs in either direction, but given how systems have evolved since we originally developed our current mail stack, it makes sense to isolate and separate, making it easier to move mail to other systems, but also getting some security benefits, too).

1 Like

7 is not out yet… what we missing?

8 comes after 7. It’s a time/work thing. Unless we all die or otherwise lose the ability to keep working on Virtualmin before then, there will eventually be a Virtualmin 8.

Edit: And, you know, we’re the ones who decide what to work on next, and that’s what I plan to work on next (after 7 is out and stable).

1 Like

thanks for all the replies, I really appreciate your helpful suggestions.

Sorry it has taken a while to respond as I’m on holiday so trying to avoid logging in :slight_smile:

It’s possible I could restart the server to carry out a post-mortem to determine if it was a rogue plugin or that script I replaced the web min default Wordpress installation script!

In any case I tried starting from scratch while skipping the FQDN step and got an error suggesting something wrong with my distro, details in error100 | Text Sharing- Powerful Text Paste & Sharing Tool

I’m back at work next week so will try again then.

Your package manager (apt-get) is not working. The step that failed does an apt-get update. That’s a basic feature of Debian, if it’s not working, obviously our installation can never work. Everything we install is installed via native packages.

Please start a new topic for any follow up. This is entirely unrelated to the original problem.

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.