Cybersecurity News You Can Use: Solarwinds APT Edition

Insights and Observations from a week of dealing with SolarWinds Orion & APT

The Dispatch highlights cybersecurity news you can use. I share what I think is informative, relevant, interesting, and actionable. Look for //My take: for context and actionable information.

Whew, what a week. Obviously this week’s news has been dominated by the SolarWinds Orion Active Exploit that I shared on Monday. In today’s dispatch you’ll get a smorgasbord of insights and links related to this situation.

Avoid Rumors, Follow Trusted Sources

There is an ever evolving story with many aspects. Be careful to follow trusted Sources. The Washington Post is really leading out in their coverage here IMHO. Follow WaPo’s National Security Reporter, Ellen Nakashima on Twitter. Also you should be aware of everything that CISA publishes right now.

Technical Advice

I won’t rehash CISA’s Emergency Directive but you should be using their mitigations as your playbook if you have SolarWinds Orion. They know more than we do, follow their advice. I heard more than once this week from people close to this, "We are rebuilding, that’s all I can say". That speaks to some advanced attacker persistence that only a wipe/reload can mitigate.

Supply Chain Risk Mgmt (SCRM)

You’ll hear me talk about this much more in coming weeks/months. However, I want to say up front: Don’t throw paperwork at this problem. Adding more check boxes and forms to your Supply Chain Risk Mgmt. (aka Vendor Risk Mgmt) process is NOT going to help. SolarWinds would likely have checked all your boxes. This is about how you manage the risk by using Security best practices in how you implement systems and how you monitor them.

I see these systems setup with too many permissions/privileges, access to too many systems, wide open internet traffic, and very little review or audit. That is a recipe for disaster. Management & Monitoring systems are often implemented by teams primarily concerned with availability. Get your security team/advisor involved.

This is not a SolarWinds problem.

Yes this threat actor focused on SolarWinds Orion. However, every network management system (NMS) or Remote Monitoring & Mgmt (RMM) software has been in the crosshairs and this just amplifies the risk. Your threat model needs to be updated because these very advanced supply chain attacks are no longer theoretical.

When you Threat Model, start with the assumption that you downloaded and installed a malicious patch. I don’t see how anyone would have detected this as a trojanized update back in March. Your best chance at detection would be to see the attacker’s lateral movement or data exfiltration.

Speaking of Detection

My colleagues and I preach comprehensive and correlated logging and monitoring. This should re-enforce that conversation all the way to the boardroom this December. If you aren’t doing full scale logging and monitoring (SIEM/SOC/MDR), you should be having a serious conversation about revising your 2021 budget. Remember there are 2 aspects of this:

  • Detection: Where you see this activity in near real time and respond.
  • Discovery: Where you can look back through 9 months of system and network logs to see if you have indicators of comprimises (IoC).

You do have 9 months of logs right? Too often that answer is NO and that should bother you more than ever.

The MFA Concern

Several people have asked my about the report from Volexity about this APT bypassing DUO. To be clear they didn’t leverage a Duo Vulnerability. They had access to this OWA server already, it seems, and found the private key in a config file. Then using that key the created a parallel valid token so they didn’t need the users MFA token. This sounds scarier than it is IMHO. The attacker already have privileged access to the server. This was not an initial vector. Also, it seems as if the the OWA server was on-prem. This vector should be made more challenging if the email server was hosted (365/Google). One great takeaway though is that if you do experience a breach you need to change your secret keys for your MFA integration.


Talking about language in times like this may seem academic but words and the concepts they communicate matter. So in the interest of promoting clarity and precision I’ll briefly mention two terms that I’ve seen used incautiously this week.

  1. Vulnerability – This is not a vulnerability. The original vector into SolarWinds may have utilized a vulnerability but the malicious patch that allowed the adversary to compromise organizations was not a vulnerability. They hid malicious code inside the patch. That’s why I call it a trojanized patch. So what to call it? The best I’ve found is an active exploit. Have a better suggestion? Let me know in the comments.
  2. Attack – Another lesson I re-learned this week. In cybersecurity, I would have easily labeled this as attack. However, that language is problematic when speaking in the context of national security. From a National Security standpoint this is more akin to an act of espionage. The difference is reflected in the concept of proportional response. Think about the difference between Russia attacking soldiers versus spying on their communications. Suddenly the word attack seem inappropriate. Politicians will call it what they want and for different reasons but as professionals I think we should be reticent about using the word attack. Stay tuned for a larger conversation about the predicament that military/war language brings to cybersecurity. See @pwnallthethings short and excellent thread on the topic.

2 Closing Technical Observations from APT Advisory

A couple of things I noted in CISA’s APT Advisory,


Set account options for service accounts to support AES256_CTS_HMAC_SHA1_96 and not support DES, RC4, or AES128 bit encryption.

It’s obvious that AES256 is the gold standard but AES128 is still widely used. They said in a briefing, "we just want to encourage people to move up the encryption chain to the best available." Its good advice but it does shake my confidence in AES128 a bit.

25 Character Passwords

Require use of multi-factor authentication. If not possible, use long and complex passwords (greater than 25 characters) for service principal accounts, and implement a good rotation policy for these passwords.

I typically recommend regular accounts have a 16+ character password. This is clear guidance that sensitive and/or privileged accounts, especially service and admin accounts, should be 25 characters.

Link Dump

I’ll close with links that I’ve opened 50x this week.

That’s it for this week. I wish you a Merry Christmas and thank you for reading.

Leave a Reply