Thread by @bettersafetynet

Just got off phone with a client. Log4j is in their network. Vendor claims patch will be available next release... which is multiple months from now.

Here's what you do if you're in this situation.

1. Keep calm. There's no need to panic.
2. Carefully read this thread.

1/?

First, it's bad. It's a remote code execution meaning any attacker will almost certainly be able to run code of their choice on your systems.

If you can, please patch it's the easiest path. But you're reading this because you can't patch (for whatever reason) OK, let's go!
2

When dealing with attacks like this you should remember the acronym IMMA.

I = Isolate
M = Minimize
M = Monitor
A = Active Defense

I'll walk you through the IMMA model for the Log4j attacks we've seen so far.

3

Isolate.
If you can, move impacted systems to a 'vulnerable VLAN'.

If you can't do that, *carefully* review firewall rules between impacted hosts and the rest of your fleet.

Another option is deploying a proxy firewall with deep packet inspection.
4

Monitor
Start looking for odd traffic patterns to or from systems (even if they're not known)

Some interesting things I've seen so far... Look for DMZ systems that INITIATE outbound connections. Typically your web servers RESPOND to requests.
5

When attackers get shell access they will frequently have a phone home check... or are establishing a "reverse shell" (where your victim system calls back to them)

This looks odd from a network layer because most internet facing systems respond to requests.
6

Key word last tweet: MOST
Some of your systems do initiate outbound comms. But these should be few. Even if you don't know which ones do/don't the odds are in your favor here. Your false positive rate should be low-ish.

Start looking for outbound initiated connections now.
7

Monitoring cont:
We all hate change management, right? I know I do! This is a time it pays off. Look for unauthorized config changes on ALL systems. Some of these vuln log4j instances will be tucked away. When an attacker starts changing the host... you should see it.
8

Monitoring cont:
start looking for port/protocol mismatch. lots of the early attacks I've seen are using very old tricks to do recon in your network. In many cases, these are probes to common ports... but... they're not using the protocol. They're empty probes. Or just wrong.
9

side note: you should be doing port/protocol mismatch checks anyway because it's a great detect for misconfigured systems or janky code.
/end side note

Monitoring cont:
if you cannot isolate the host, consider putting a firewall or any other type of tool that logs network connections next to vuln systems.

Even a firewall with ALLOW ALL/ALL rules and a LOG unexpected connections is an amazing win.
10

Mon cont:
Start looking for AD interactions from non-AD systems. Lots of appliances have these Log4j issues. Typically such devices are NOT bound to AD.
DO THIS RIGHT NOW, PLEASE!! Yes, you will get false positives. (typically printers) make a list, alert on all others
11

Mon cont:
now is a GREAT time to start doing "top talkers" analysis on all suspected vuln systems. I suggest you do this for every protocol, not just the common ones. Attackers try to blend in, but it's tricky. Top talkers tend to stick out.
12

Minimize:
This isn't great, but as a quick and dirty check, you can use strings on the binaries to see if you have references to log4j. I've found a few this way. It's not elegant, but it may work for you too
docs.microsoft.com/en-us/sysinter…

13

Minimize:
Now's a great time to consider shutting off unneeded services! One client had a VPN that appears vulnerable, but it looks like it's only used by the management web ui. They like using that UI because it's easy... just for now they're doing without.
14

Active defense:
Now more than ever it's a great idea to setup a fake simple web service that mimics a vuln system. Even something as simple as a cowrie target is worth deploying. Find out who's doing recon on your network.

15
github.com/cowrie/cowrie

Active defense -- spicy advice -- WARNING! not for everyone.
If you find attacker indicators... you may want to sit back and observe what they're doing. If you simply firewall block them, they'll be back almost instantly.
16

Active Defense MAJOR WIN
I've had some clients shy away from firewall blocks "what if this is a real customer?"
If that's you, use QoS to your advantage. QoS allows you to shape traffic. Most use it for service mins. But you can also set for service max! slow down the attacker
17

That's it for now. I hope the IMMA process helps you triage this difficult time. I've got to hop back into the fray right now.

We're all in this together. Take some time, chill.

Slow is smooth, and smooth is fast.

LMK if any of the infosec fam can help you out.

Let's go!
fin

Monitor bonus: look for CPU load spikes. Coin miners are going nuts with this vuln. It's not great that you're hit, but the silver lining is they are making vulnerable boxes really stand out.