Bug report: AES CTR results differ from expected

I was working on cryptopals challenge, https://cryptopals.com/sets/3/challenges/18
It provided me an AES Key for CTR mode and a base64 encoded message to decrypt,
key=YELLOW SUBMARINE
nonce=0
format=64 bit unsigned little endian nonce,
64 bit little endian block count (byte count / 16)
The string: L77na/nrFsKvynd6HzOoG7GHTLXsTVu9qvY/2syLXzhPweyyMTJULu/6/kXX0KSvoOLSFQ==

The code I used to decrypt it worked, but when I used it on Cyberchief encrypted strings, it did not. I implemented behavior to work with cyberchief encrypted strings and found that the CTR was computed differently for non-zero block numbers, 00000000000000000100000000000000 for cryptopals and 00000000000000000000000000000001 for cyberchief.

What should happen
Given the key, nonce/IV, it should decrypt

- CyberChef version: cyberchief.org version

**Additional context**

This could legitly be two different implementations, if so the option to choose one or the other would be in order.

No source file, test, or entry point is named. Reproduce the provided AES-CTR case and compare the counter byte ordering at non-zero block numbers with the Cryptopals and CyberChef formats. Done means the expected format is decided and the chosen behavior is covered by a regression test.

Written by the indexing model from the issue text.