Do you mean ingress? You probably wouldn’t want to allow ingress or egress, but the statement says connecting from a TOR exit node to CapitalOne, not the other way around.

Sometimes the best way to handle "bad" traffic is not to reject/block it, but to respond to it incredibly slowly, or divert to an uninteresting flaky phantom server, or reject every login attempt (even with correct credentials) to divert attacker's attention.

The ingress was okay, but the egress flow was very very bad!

That seems like a great way to waste your own time accomplishing nothing.

I think it was a part of mailinator’s approach to running a disposable email server.

The operator’s approach to bad actors was to respond as slowly as possible instead of quickly rejecting.

What sort of rule or policy would you put into play to detect that a connection was a TOR node?

Tor node IPs are published, so you can just block that list. There's probably a way to detect them too, but I don't think an exit node can be secret.

Is there enough space in an S3 bucket access policy to include DENY rules for every known Tor IP address?

By the sounds of it, the s3 bucket was internally accessible only. But attacker connected through the corp's Web Application Firewall after grabbing the credentials to login to the S3 bucket.

"Internally accessible only" just means you have to have credentials to access it.

You can also add IP address restrictions to a bucket access policy; this was obviously not done here because once she had the credentials, it didn't matter where she was accessing from.

Looks to me that it should rather be using an IP white list. It's not like their systems would need access to these documents from an dynamic IP dial up connection.

Commenting on you because I can't comment below:

Tor node IPs are published, so you can just block that list.

You can reply to deep-nested posts by clicking into their permalink.

Ah, I thought this was meant from the attacker's perspective.