I don’t see why blocking/blacklisting would help (unless the gateway is on some metered connection).
If the DevAddr is a TTN address (starting with the hexadecimal 0x26 or 0x27) then it would be nice if TTN can block this; this would be a good use case for the Fair Access policy.
If the DevAddr is not TTN, then assuming the gateway forwards to TTN, then the packet will be dropped anyway. So filtering in the gateway has no effect.
The most significant 7 bits of a DevAddr are known as the NwkID, and match the least significant 7 bits of the NetID (network identifier). TTN currently uses NetID 0x000013, hence its NwkID is the binary %0010011.† I assume there is some overview of assigned NetIDs or NwkIDs, so we might be able to match the 7 MSB of the abusive DevAddr to one or more specific LoRaWAN networks, and complain there.
So, to repeat the question:
(As an aside: a hardcoded SF11 is not allowed either, so their provider should take some action…)
† Just to verify: hexadecimal 0x26 is binary %00100110, and 0x27 is %00100111, so both indeed start with the 7 bits NwkID.