I've had 3 calls so far today (it's not even 10) about defending against Russian cyber ops

I'm tired of having the same call... so... here's what I've told everyone. This is the playbook you need... but it's not going to be what you think it will be.

Ready? Lets go!
1
Watch your egress. Firewalls work both ways. Carefully monitor outbound traffic. DMZ servers RESPOND to external requests. Look for DMZ systems initiating outbound. This is what "phoning home" (aka C2) looks like.

2
Note: you will have a handful of DMZ servers initiating outbound. File xfer systems, any mail server (you likely shouldn't be running your own). Some web services may also initiate outbound.

But it's rare.

Most orgs? Your exception list will fit on a single sheet of paper.

3
Don't get too hung up on IP address blocks. Geo blocking has some advantages, but the only time Russian groups come from Russian IP space is when they want to rub it in.

Start treating the entire internet as hostile... because it is.

4
You 100% must know what is "normal" exes on your systems. App control (used to be call white listing) is no longer a "nice to have" it's IMO table stakes. Anyone who claims otherwise is giving dated & dangerous advice.

5
If building an app control list sounds hard, you're doing it wrongly. Use native logging functions to know the apps that are running on systems.

If you don't have an EDR, etc.

Windows SRUM is my go to. It has a 30 day rolling view of EVERY exe run. Use that. Please.

6
I'd suggest you use @MarkBaggett's SRUM Dump utility or ESE tools

For single hosts:
github.com/MarkBaggett/sr…

For multiple hosts:
github.com/MarkBaggett/es…

7
For knowing normal app use on linux hosts, use auditd or sysmon for linux. (again... if you don't have a fancy edr or something that can track this info)

Auditd
access.redhat.com/documentation/…
(this info will work even if you're not RH/RPM based)

8
Shoutout to @Lares_ for a great doc on how to use sysmon for linux

lares.com/blog/sysmon-fo…

9
You *must* know how your systems are being used for two reasons.

1. you need to block any app not on your accepted list. (set block alerts at highest priority. It might be legit need, and you'll want to fix that right away)

2. Living off land attacks...

10
Living off land attacks are NOT new.

In 2013, there were two talks about LOL attacks. If you're not familiar with this... watch them NOW.

at is the new black


Living off the land


11
The reason it's key that you DEEPLY understand LOL attacks... they are what state sponsored attackers use when pressured to do so.

LOL attacks _work_

They allow attackers to bypass your AV, and yes likely your EDR.

12
Because many orgs over rely on EDR and SIEM now, LOL attacks are highly successful. Attackers blend in. They are using core parts of the OS against you. None of your tools will stop these. You likely already have exclusions for the ports and protocols these tools use.

13
Do NOT believe your heuristics or ML/AI based tool will save you either.

A *CRITICALLY* under-viewed talk from @HackingDave at @WWHackinFest 2019 is how attacker are bypassing these techniques

(don't let Dave's outfit confuse you, it was Halloween)

14
Super critical: Don't buy vendor tools to catch the attackers. No matter how good the demo is... it's a demo.

Folks, I run a small company. We're not yet 5 years old. But I've personally bypassed EVERY SINGLE defensive control. Every single one.

15
I bypass all these controls in a lab. I invested about $17k and have a massive 3 node proxmox cluster and 14 TB NAS. I can emulate most orgs, or a significant portion of them.

If my boutique infosec consultancy has these resources... what does a state sponsored one have?

16
If your IR plan doesn't have a rapid (host and network level) isolation workflows. Make it just after the stuff I've talked about in prior tweets. Drill it. You're going to need to work at a speed you likely haven't before.

17
Have a frank talk with your cyber insurance provider. It might get *real* bad. Ask where you will be on the priority list. Chances are if you're not a fortune single digit org, you're going to be way down the queue. Find some alternate DFIR firms that will take you on.

18
Increase your logging, while both filtering out stuff you don't care about at your aggregators, and SHORTENING the retention length for the data you don't need long term.

Many logs age like milk. (looking at you DNS logs)

19
I know things are going to get spicy. It sucks. It's not fair. But it is what it is.

The playbooks we've been following for too long are now being used against us. You can either accept that, or be beaten before you even show up to fight.

20
That said, you *can* win this fight.

Once the attackers are in, you only need to detect them once.

You can do stuff like make MSFT an untrusted publisher on a Windows box by allowing ONLY what is listed in SRUM analysis.

21
You have the best CTI at your fingertips. Leverage CTI feeds if you have them.

Your hosts tell you how they're being used and abused. Start listening.

Prevent isn't possible. Try anyway.
Move to a detect and respond model. That's our path to victory.

You got this.
fin

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Mick Douglas

Mick Douglas Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @bettersafetynet

Feb 21
There was a LOT of interest when What2Log.com launched. Far more than we would have dared to dream!

EVERYONE wanted to directly contribute... but we weren't setup for that... until now.

We have converted the entire W2L platform over to TOML and opened up the repo!
1
This means you (yes *you*) can generate TOMLs that will be reviewed by the W2L crew. As long as you follow the template guides, your content will be included in the releases.

This is _huge_ and should allow W2L to scale almost vertically in terms of community involvement.
2
I'm super hopeful that we get a TON of contributions. We've done so much care and attention to the input we've had already.

Here's some notable things:
3
Read 10 tweets
Jan 24
Have a DLP solution? Want to **REALLY** make it actually... useful?

Scan the endpoints for sensitive info. You'll get a report with the data on that host.

Work with risk and legal to assign any arbitrary point value to this sensitive info.

1
Example:
PCI data is 5 points per record
PII is 3 points per record
PHI is 10 points per record

Note: your points will be based on your orgs concern over exposure of each record type. Don't let anyone else tell you what points you should use. You're measuring your risk

2
Now calculate the total risk points per endpoint. Get ready for some shocks!

There are some tools that do this already, but now you have a fancier DLP risk report tool.

Here's what almost nobody does though... :-)

3
Read 10 tweets
Jan 17
You have network monitoring capabilities. Great! But what are you looking for?

All too often folks start focusing on individual attacks. And yes, it's important that you can catch the latest RAT from Grid Iguana (from Hacksylvania)

Don't lose sight of the big picture.
1
Monitor for DMZ outbound traffic.
Almost all DMZ systems are responding to some request from remote user. Your DMZ systems are the destination, not the source. An early indicator an attack worked is a DMZ system phoning home to the C2 network. Your machine is a source here.
2
Like all things, this isn't 100%. There will be a few DMZ systems that do originate outbound traffic... but it should be rare enough that you can detect on this alone and have a short exception list for known outbound originators.
3
Read 11 tweets
Jan 11
I've got several DMs where folks are telling me it's hard to get logs. Yes. I agree. It's also table stakes. If you cannot get logs, hire someone who can... or get a contractor to help. Saying "it's hard" is true... but you 100% need those logs.
1
It's uncharacteristically harsh of me to say this... I don't care if it's hard for you to get those logs. GET THEM. If you cannot get them you no shot of stopping attackers.

Prevent is great, but it's not nearly enough. You must be able to detect. Logs are how you do this.
2
If your org isn't allowing you to get the logs for $reasons, maybe you need to leave. This is a no excuses thing. I cannot overstate this. I cannot believe I'm having folks argue this. I take comfort that they're embarrassed enough to only do this in DMs. They know it's bad.
3
Read 5 tweets
Jan 11
Blue team folks... we have to talk.

It's awesome that you're logging. That's the first step. Now here's the cool stuff to look for that the vendor didn't tell you about.
1
Pay careful attention to logs that stop coming in. If it's worth logging, it's worth monitoring when the logs stop flowing. (how long a gap you'll accept is up to you, but I rarely allow for over an hour)
2
Watch out for log sources where the time changes too much. (except for daylight savings changes)

Time drift is one of the most critical things to account for in log analysis. That's a given... but...
3
Read 8 tweets
Dec 23, 2021
Pen testers, we need to talk. Please listen up, take notes... and above all, ask questions.

A non-trivial part of my service portfolio is now reviewing the reports of other firms and either adjusting or providing missing context.

Read on for the common issues...
1
Most important: you need to give clients multiple options on how to fix something. MULTIPLE. At least 3. Telling them "fix the code" when it's from a vendor that's closed, doesn't help at all.
2
Show your work. There's a few firms that hide what they're doing. Some to the point where they just show a "ta da!" screenshot and don't explain how they did it... and frankly, that's weaksauce.
3
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(