My CFO received an email from a director at a financial institution advising that all traffic (inbound and outbound) from certain IP addresses should be blocked at the firewall. The director at the financial institution was advised by his IT department to send this mail. The list of addresses (about 40) was in an attached, password-protected PDF. The password was sent to my CFO by text message.
The only part about this that I find strange is that the CFO is involved at all in this. CTOs (or subordinates) routinely deal with cyberintelligence and information sharing amongst institutions and national intelligence agencies (FBI, CERT, etc.).
I initially thought this was a malicious attempt to get our CFO to open an infected PDF, or a phishing/whaling attempt, but it seems legit. We have spoken to the IT department at the FI and they say it's genuine, but they can't (won't) provide any more information. Due to the nature of the relationship between my company and the FI, refusing isn't really an option. From what I can see most of the IP addresses appear to belong to tech companies.
Your diligence is worth applause; that is a plausible vector.
You don't specify what these "tech companies" are, but if they are things like AWS, DigitalOcean, Linode, Vultr, Choopa, Hetzner, OVH, Velia, et al. then you should know that these tech companies (and many other smaller ones, including torrent seedboxes) are routinely implicated in botnets, malware and financial fraud. Anything offering shared hosting or VPS services is a possible platform for launching attacks. I can tell you from direct experience that many of the HSA, W2, tax return fraud and other scams journalists like Krebs reports on are launched from cheap VPS services like these.
Does this approach strike you as suspicious? Is there some social engineering going on here?
Information about current incidents can get shared formally (through publication to US-CERT mailing lists, amongst institutions on DIBNET, FS-ISAC, etc.) or via weird PDF-sharing schemes between executives that originated from what was supposed to be a non-disclosable, non-attributable FBI tip. It happens.
When the FBI is the originating source, they generally provide little to no detail or context and so shaking the tree and refusing to take action without further information may not be received well by your superiors. Keep holding out and you'll end up like the shmuck at Equifax who delayed patching Struts prior to the breach; he was the first person to get thrown under the bus. You apparently have a business agreement obligating you to implement some IP blocks based on threat intelligence received. Just do it.
Again, the only fishy part to me is that the CFO was the recipient. But that could just be due to the nature of an existing relationship between him and that director.
It is entirely possible someone is trying to cause chaos by having you block IPs of companies you do business with, but that seems farfetched-- it requires a lot of inside knowledge and effort to accomplish a small interruption at worst.
What could the nature of the threat be?
Director at financial institution X was made aware of an incident. They were likely compromised by one or more of those 40 IPs, or made aware of a threat from an external source. They may or may not have observed evidence that your company may also be a potential target, either through credentials they saw attempted, endpoints requested, or data exfiltrated. They saw fit to share this information with your company so you could take proactive measures.
Between you and me, I'm not fazed by this scenario. This is the sort of thing I come in to find in my mailbox every Monday (and especially in the days following national holidays-- foreign attackers love waiting until they know nobody's going to be in the office for a few days. Labor Day was last week...).
What I personally do with these lists before implementing blocks is run them through our own logs and see what activity the same actors may have been up to with our own systems. Look for activity by any IPs within the same subnets; the IPs supplied may not have been the same ones that might have targeted you already. Sometimes it uncovers evidence of compromise that wasn't within the scope of the supplied intelligence.