Cisco ASA 8.2 - 106015 (Deny) and 106100 (Permit) Logs for the Same Packet

I'm seeing traffic from numerous internal endpoints where a RST or FIN/ACK is sent by the endpoint to a host on the Internet. These connections are related with a transparent proxy that is not handling these properly. Instead of dealing with them, it simply forwards them to the ASA. The ASA has never observed these connections before.

The ASA (8.2) sees this traffic and generates a 106015 event (no connection) and denies the traffic. This is precisely what I expect. However, the ASA will also log a 106100 event that states the traffic is permitted. There is an ACE that states "permit ip any any log".

Based on traffic captures, it was confirmed that the traffic was denied and not permitted.

Why is the 106100 event happening then? It's completely thrown us for a loop as it appears that the ASA has allowed traffic when in fact it has not. If the ASA drops the traffic due to lack of existing connection, why would it go anywhere near the ACLs, much less generate a permit log?

Here are the logs in questions:

: %ASA-6-106015: Deny TCP (no connection) from 10.x.x.x/62938 to 216.x.x.x/80 flags FIN ACK  on interface inside

: %ASA-6-106100: access-list inside permitted tcp inside/10.x.x.x(62938) -> outside/216.x.x.x(80) hit-cnt 1 first hit [0x62c4905, 0x0]

Timestamps of the two events are identical.

Any advice would be appreciated, thanks.

Edit: Clarification
According to this Cisco article on packet flow. http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

"If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged."

Based on this described behavior, I'm still unsure as to why I'm seeing the 106100 log indicating the traffic is permitted.

The ACL is being evaluated before the connection tracking and NAT evaluation (check the output of packet-tracer simulating this traffic), and because the traffic hits that rule, it logs as you've instructed it to in permit ip any any log.