As well as reporting procedure, the admin should sensibly have a handling policy. This means they are unlikely to currently have one. Luckily, some of us have a clue.
What I suggest be done is first you take the IP used to sign up with, and whois it. If for some reason it returns rDNS instead of IP then "nslookup" (I think that's common across OS's) or ping will produce an IP from that. To use the IP I'm using to connect to here through as an example, it should return contents similar:
[eyer@Supay ~]$ whois 149.255.98.121
[Querying whois.arin.net]
[Redirected to whois.ripe.net]
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '149.255.96.0 - 149.255.99.255'
% Abuse contact for '149.255.96.0 - 149.255.99.255' is 'abuse@openitc.co.uk'
inetnum: 149.255.96.0 - 149.255.99.255
netname: OPENITC-20110817
descr: OpenITC
country: GB
admin-c: OPEN9-RIPE
tech-c: OPEN9-RIPE
status: ASSIGNED PA
mnt-by: SEAN-MNT
mnt-lower: SEAN-MNT
mnt-domains: SEAN-MNT
mnt-routes: GB10488-RIPE-MNT
created: 2011-08-22T15:02:12Z
last-modified: 2011-09-02T15:05:13Z
source: RIPE
role: OpenITC DBM
address: International House
address: 24 Holborn Viaduct
address: CITY OF LONDON
address: London
address: EC1A 2BN
address: United Kingdom
abuse-mailbox: abuse@openitc.co.uk
admin-c: SEAN-RIPE
tech-c: SEAN-RIPE
nic-hdl: OPEN9-RIPE
mnt-by: SEAN-MNT
created: 2011-08-18T10:19:36Z
last-modified: 2016-05-08T17:01:06Z
source: RIPE # Filtered
% Information related to '149.255.96.0/22AS20860'
route: 149.255.96.0/22
descr: OpenITC
origin: AS20860
mnt-by: GB10488-RIPE-MNT
created: 2011-08-30T09:52:30Z
last-modified: 2011-08-30T09:52:30Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.88 (ANGUS)
Of primary interest in that glob is the abuse mailbox. Any responsible provider will not tollerate abuse. Sending emails to that, with logs or extracts of highlighting abusive use usually results in swift action taking the offensive unit offline. If there is no abuse mailbox, or NOC contact listed, then you can usually trace one back from the firm that runs the operation. This serves two main purposes:
- It prevents it from being used again, here or somewhere else
- It costs these criminals money when they do not get a refund on the services they have paid for. Some services even incur additional charges on reciept of abuse reports.
Software like fail2ban can be tailored to perform this(and the following) action autonomously.
In the rare cases that this service was not expressly rented for this purpose and was compromised by hostile third parties for this purpose, then don't feel guilty about getting their serivces stamped on, they've just demonstrated why they are unworthy of operating these, and their incompetence forms a danger to everyone else.
After lodging abuse reports(your ticketing system should be used to track this from your end, additionally), then look at the email used to sign up with. Here I would suggest the use of software like "maltego" to graph the attacks and evidence behaviours. I've only seen manual spam runs on here so far, but it's only time before organised botnets. Commonly bots will generate usernames via an algorythm on 'tard services like gmail and other things with low to no signup verification, clock that algorythm and you can prevent signup to this service. I'd personally blacklist such providers, but I sense that's not an entirely viable option here with high numbers of "legitimate" accounts using. You could contact the abuse mail listed for the email services used and attempt to have them shut down services - most are not interested in promoting this sort of behaviour in their users.
After recording and reporting the confirmed hostile event, then the IP should be entered into pf - to assume a table already exists called "badhosts": pfctl -t badhosts -T add 1.2.3.4
should do the trick. I would suggest doing the entire range if the provider isn't residential. Ie for the example listed above, 149.255.96.0/22 will take out that block of the datacenter. Services exist that hoard known public access proxy addresses and TOR exit nodes etc. These should be regularly scraped(hourly or so) and used to augment local system firewall rules to prevent abuse as no-one with legitimate purposes will be using these services. If using something like fail2ban to actually perform this action then it should be possible to have it also keep the list pruned of stale adresses.
Then follow up on the abuse report, it's common to have a resolution in less than 48hrs, it's uncommon to get customer details without LEA credentials. Contacting LEA is somewhat advisable, but in honesty most hold little interest in actually doing anything - even if you highlight how they go about doing it.
I don't think this is a "test of defence capabilities" or it'd of been an automated run of steadily increasing intensity to find out the cut-out point set in IDS (lol, if there is even IDS running). However, I'd expect things like this sooner rather than later.