Randomly initialised global counter used to encrypt the kth message with $\operatorname{IV} = \operatorname{IV} + k \hspace{5mm} mod \hspace{5mm} 2^n$ The use of an increasing IV is not secure for a block cipher. That is, using a random IV for the first message then $\operatorname{IV} + 1$ for the second , $\operatorname{IV}+ 2$ for the 3rd etc. How can I construct an attack to show that this mode is not secure?
A block cipher, per se, does not have a notion of initialization vector.  But a randomized or stateful message cipher may.  If you're building an application, you should forget the concept of ‘block cipher’ altogether: the fact that some cryptographic magic is built out of a pseudorandom permutation family whose name is spelled A-E-S is not important to you; the security contract of the result, including your obligations and the security you get in exchange, is what's important.


For a randomized cipher like AES-CBC, your obligation in the security contract is to choose an IV unpredictably.

If, given the first message's IV, the adversary can guess the second message's IV, the security contract is voided.  This mistake was exploited to recover plaintext in ssh sessions in 2009[1] (paywall-free).
For a stateful cipher like AES-CTR, your obligation in the security contract is typically to choose a nonce uniquely, which you can do by counting.  (The ‘nonce’, for number used once, is sometimes called an ‘IV’, but some authors—like this one—prefer to reserve the term ‘IV’ for unpredictable ones.)

It does not matter if the adversary can predict the nonce in advance, as long as the sender never repeats a nonce.  As a bonus, you can immediately detect buggy implementations by having the receiver require the nonces to be sequential.


One can always safely use state to choose the IV for a randomized cipher, by deriving it by a pseudorandom function of the number of messages so far; and one can choose a nonce randomly for a stateful cipher, but at risk of nonce collision, so it's not so safe.

All this said, you should really use an authenticated message cipher.  Even if an adversary can't read secrets in an encrypted message by eavesdropping, without authentication you might act on adversary-controlled input which causes secrets to leak.  Examples of authenticated ciphers include:


AES-GCM, with a message sequence number for the 96-bit nonce;
NaCl crypto_secretbox_xsalsa20poly1305, with a message sequence number or uniform random nonce, since the 192-bit nonce is large enough to be safely chosen uniformly at random; or,
if you must use AES-CBC, at least use it in encrypt-then-MAC composition with HMAC-SHA256 or similar, and the sender must choose the IV unpredictably for each message.