Enhancement: Adding Trending Attackers Feed with Rank Delta

[rootp1]

Hi @regulartim,

I was exploring the current IOC feeds in GreedyBear and had an idea that might be a useful enhancement.

Right now, the platform exposes real time IOC feeds, which are great for seeing the most active attackers at a given moment. However, it doesn’t provide a sense of how activity is changing over time,, specifically, which attackers are rising or falling.

It could be interesting to introduce a “trending attackers” feed that compares attacker activity across rolling time windows. For example:

• Last 24 hours vs previous 24 hours
• Last 7 days vs previous 7 days

This feed could return various impactful insights rank delta, growth score

Please let me know with how much impact this aligns with the project direction

[aaditiii2717]

Hi, I’m a GSoC applicant and I’m interested in contributing to this project.

I’ve started exploring the repository—could you suggest a good starting point or any beginner-friendly tasks?

[regulartim]

Hey @rootp1 ! Good idea, I'll assign you!

[regulartim]

Hi @aaditiii2717 ! This is not the right place for a writing about that. Please use a GitHub Discussion or contact me on Slack.

[rootp1]

Hi @regulartim,

I put together a rough implementation plan and wanted to run it by you and review the approach to see if the it makes sense before I go deeper into it.

[rootp1]

The main goal is to keep things simple and cost efficient.
Instead of doing heavy aggregations at request time, I’m thinking of reusing the existing extraction flow to capture per attacker counts and store them as hourly buckets in Postgres.
This way, we’re not adding any extra load upstream and can still build the comparisons we need over time.

[rootp1]

On top of that,
I’d add a scheduled task that computes things like rank, rank delta, and a basic growth score for windows like 24h vs previous 24h and 7d vs previous 7d. (time gaps not yet decided)
These would be precomputed and stored, so the API just reads ready-made results and stays fast. The freshness would stay roughly in line with the current pipeline (like approx. 10 minutes).

[rootp1]

For now, I’m keeping it scoped to source IP and interaction volume so it stays aligned with the current feeds
and doesn’t get too complex. I’ve also thought a bit about retention and indexing so this doesn’t grow unbounded over time.

[rootp1]

Does this direction seem good, @regulartim ?

[regulartim]

For the TrainModels job, we are using data snapshots from the previous day. That works quite well and is an already established functionality in our code base. I am wondering if we can use that for your purpose. The downside of course would be that we would be slower to detect trends. But it would be sufficient for a 24h / 7d time window, I think. What do you think about that?

[rootp1]

For the TrainModels job, we are using data snapshots from the previous day. That works quite well and is an already established functionality in our code base. I am wondering if we can use that for your purpose. The downside of course would be that we would be slower to detect trends. But it would be sufficient for a 24h / 7d time window, I think. What do you think about that?

Ohh that's a great model, Tim. But I just wanted to discuss the extended functionality of inclusion of a feature that allows to set the time according to the user request and not just being bound to 24h /7d.
I feel this freedom should be given to the user to set the time frame by themselves.
I really look forward to get your opinion on what exactly this feeds idea would be bettered with?

[rootp1]

What do you feel about this vision, @regulartim
This would help users' find the specific timed attack patterns also.

[regulartim]

Yeah, I agree! Not being bound to 24h/7d would be better. I'll assign you.