Trying to find the source of TLS 1.0 connection prior to AWS stopping support.

This article covers the changes and how to find the sources of TLS 1.0 and 1.1 connections.

https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/

By enabling CloudTrail logging for the S3 bucket, and enabling CloudWatch for the trail, you should start to see ListObject events by searching the associated log group using the CloudWatch console. I just ran a test where I did the following:

1. Enable Server access logging for the S3 bucket
2. Create a new CloudTrail trail for S3 Data Events (and enable CloudWatch logs)
3. Use CloudWatch / Log Groups to search log streams for ListObject log events

I used the AWS CLI to execute test ls events, and was able to find those events logged that include the sourceIPAddress field.

More information: https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-understanding-s3-entries.html#example-ct-log-s3

You can also try to isolate the process by adding a bucket policy that denies the ListObject action based on the user agent string.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::bucket-name",
            "Condition": {
                "StringLike": {
                    "aws:UserAgent": "*aws-sdk-java/1.1.9*"
                }
            }
        }
    ]
}

When searching for Access Denied events in CloudWatch logs, note that AWS Console will also has aws-sdk-java in the user agent string, so will have to search for more than that to find events related only to the unknown Java app. The policy will cause the app to fail which may help identify it, though runs the risk of disrupting a production workload.