When I think about threat hunting:

- Pro-active search for active / historical threats
- Pro-active search for insights
- Insights lead to better understanding of org
- Insights are springboard to action
- Actions improve security / risk / reduce attack surface
With these guiding principles in hand, here's a thread of hunting ideas that will lead to insights about your environment - and those insights should be a springboard to action.
Here are my DCs

Do you see evidence of active / historical credential theft?

Can you tell me the last time we reset the krbtgt account?

Recommendations to harden my org against credential theft?

How many do we already have enabled?

Where can we improve?
Here's my #AWS environment

We're worried about credential theft.

Let's query #CloudTrail logs for API calls that returned "Access Denied" from the same IAM / Principal ID in a short time-frame.

At a minimum this will lead to insights about our #AWS env
Here's where my critical data is stored.

Do you see any evidence of active or historical threat actor activity.

How can we improve visibility to these systems?

What am we doing well to protect these systems and any suggestions on how I can improve?
Here's a list of how employees can access the environment remotely - yeah, here are the single factor methods.

Any sign of active / historical unauthorized access?

How can we improve viz?

New detection opportunities?

Recommendations to secure remote access?
I'm worried about unauthorized access to O365 / Okta

Any sign of unauthorized access?

Can you tell me how many employees access O365 / Okta remotely via VPN?

Which VPN services do they use?

Policy / config recommendations to secure O365 / Okta?
Recap: We started with a question / a worry.

We first asked: is there a problem?

And then we asked: given what we've learned, how can we improve?

Hunting will lead to insights and insights should be a springboard to action.

• • •

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

Keep Current with Jon Hencinski

Jon Hencinski 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 @jhencinski

30 Oct
To the "do it all" IT folks or new #SOC analysts that need a little help - a thread for you.

Cheat sheets and example queries for Endgame, CS Falcon, ATP, and CbR using a recent incident as the starting point.

cc: thanks to @AshwinRamesh94 for the query work
Yesterday we stopped a #ransomware attack at a customer where initial entry was a remote admin connection from a 3p IT provider

- Attacker had admin
- Connected to host via ConnectWise (RDP)
- Opened CMD shell to open PS download cradle to deploy SODINOKIBI from hastebin[d]com
The attacker ransomed 1 host - but by removing access 6 min after the attack started - stopped it from becoming a much bigger issue.

Let's walk through a question or two we asked along the way using different EDR tech....
Read 15 tweets
28 Oct
TL;DR - Potentially bad #ATP rule update last night. Don't panic. Investigate - don't let me bias you. Providing for broader context.

#MDR insight: Between 06:25 UTC - 07:40 UTC we detected an unusually high # of false positive MS Defender ATP alerts for "Cobalt Strike C2".
We observed false positive alerts for:
[CommandAndControl] Cobalt Strike C2

Observed at: all customers running MS Defender ATP.

Fp sequence: System boot / logon initialization / ATP alert on netconn to 127.0.0.1.

We timelined.

No evidence of attacker activity. Bad rule.
Please don't let me bias you. This thread was built with the intent to provide greater context.

Yes, other orgs running @Microsoft Defender ATP had false positive alerts for [CommandAndControl] Cobalt Strike last night / this am.

From what we see: bad vendor rule (it happens)
Read 5 tweets
25 Oct
"Do you have any questions for us?"

An effective interview includes 🕘 for the applicant to ask questions.

A few to consider if you're interviewing:
1. What are the big problems you're solving this year?
2. One year from now this person has been successful. What did they do?
3. Conversely, six months from now it didn't work out. What happened?
4. How do you measure performance? What's the cadence?
5. What's the typical tenure for this role?
6. Is the team growing or is this hire a backfill? If backfill: can you talk about the employee's new role?
7. Will we have weekly 1:1s. If so, what's a typical agenda?
8. How many direct reports do you have?
9. What's a typical day look like?

If you're unclear on the traits and skills the hiring manager is seeking, ask!

"What are the traits and skills you're seeking for this role?"
Read 8 tweets
26 Apr
How do you measure #SOC quality? 🤔

1. ISO 2859-1 (#AQL) to determine sample size
2. #Python #Jupyter notebook to perform random selection
3. Check sheet to spot defects
4. Process runs every 24 hrs
5. (Digestible) #Metrics to improve

How'd we get there? Story in /thread
I'll break the thread down into four key points:

1. What we're solving for
2. Guiding principles
3. Our (current) solution
4. Quick recap

My goal is to share what's working for us and how we get there. But I'd love to hear from others. What's working for you?
What we're solving for: All work is high quality, not just incidents.

On a typical day in our #SOC we'll:
- Process Ms of alerts w/ detection engine
- Send 100s to analysts for human judgement

Those 100s of alerts result in:
- Tens of investigations
- Handful of incidents
Read 10 tweets
17 Apr
Highlights from chasing an attacker in #AWS this week:

Initial lead: custom alert using #CloudTrail
- SSH keygen from weird source
IP enrichment helped
Historical context for IAM user, "this isn't normal"
#GuardDuty was not initial lead
- Did have LOW sev high vol alerts
Attacker tradecraft:
- Made ingress rules on sec groups that allowed any access to anything in VPC
- Interesting API calls: > 300 AuthorizeSecurityGroupIngress calls
- Spun up new ec2 instance likely to persist
- Mostly recon - "What policy permissions does this IAM user have?"
Investigations:
Orchestration was super helpful. We bring our own.

For any AWS alert we auto acquire:
- Interesting API calls (anything that isn't Get*, List*, Describe*)
- List of assumed roles (+ failures)
- AWS services touched user user/role
- Gave us answers, fast
Read 4 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

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

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!