If you look at the definition of counter mode, you will see that it actually turns the blockcipher into a stream cipher:
- The keystream is independent of the message.
- The ciphertext is just XOR of the keystream and the plaintext.
So if you just flip a single bit in the message, you just flip a single bit in the ciphertext if the keystream is the same - I guess that's what you call the patterns in the changing bytes?
However, this indicates wrong usage of counter mode: There is a nonce in CTR, basically it is the starting value of the counter (padded with 0 at the end). And it should never be the same for several messages. The concatenation of the nonce and the counter is the input to the block cipher, and 128 bits (AES) are more than enough that you never have to reuse either (e.g. 96 bit nonce and 32 bit counter, or both with 64 bit).
With a proper nonce, you should get an entirely different keystream for every message, and (under the assumption that a block cipher acts like a pseudo-random permutation, which is the theoretical model for a secure blockcipher) should not be able to distinguish different messages or in fact a ciphertext from a truly random number.
If you don't want to store the nonce (it is the equivalent of an IV in other modes), you could use a message-counter instead: A nonce does not have to be random, it just needs to be unique (never reused - even after restarting the whole process / program).