Skip to main content
radar

Radar #8: Week of 12/23/2024

— Graham

Radar #8: Week of 12/23/2024

Finding What To Work On

I recently had a discussion where someone asked a seemingly simple question: “How do you know what to work on”. The answer is not immediately obvious until you’ve found yourself working on something useful, but there are some general guidelines I like to follow.

Look for areas of technology where something important and interesting is happening. This might not be obvious. What technologies are going to be critical in the next few months/years?

Look for areas that are complex or not well understood but provide massive capabilities. It was “The Cloud” a few years ago, now some examples might be: Kubernetes, eBPF, WASM, etc.

You might say “AI”. This would likely be the correct answer a few years ago, but now everyone is working on AI. You should find something complex that the majority of people haven’t looked into or heard of before. If everyone is an expert in something, it’ll decrease the demand for your experience.

Often times you will have to convince people that something is important. Demonstrate its usefulness, talk about it with others, and pitch it those who can give you time to dig deeper into it. If the project is too big, develop a circle of people working on it. This could be a work chat or a discord group of people interested in the same idea.

The result of your research may not be immediately apparent for the context it’s being applied to. If you spend 6 months learning WASM, but you work as a SOC analyst, you may have to move roles before utilizing the research. However, if you’re a principal solutions architect, the results may be immediately beneficial.

Learn tools that will help with any project. Learning how to script a proof of concept in Bash or Python, and then writing custom tooling in C, Rust, or Go, will be beneficial to many projects. If you don’t know these languages, this is a good place to start but don’t discount the important of note taking, conducting research, and the basics of project management.

“This work is an intersection of what you’re exceptionally good at and what you genuinely care about” -Will Larson

The formula I’ve found works in the context of pentesting: Find something to hack -> Research it deeply -> Hack it better -> Build tooling so others can leverage your research without the lengthy research phase-> Tell people about it (blogs, conferences, etc).

CISA Mobile Communications Best Practice Guidance (PDF)

In light of the recent Telecommunication breaches, CISA has released best practices for mobile phone usage.

  1. Use end-to-end encrypted communications (IE: Signal)
  2. Use FIDO authentication. (Such as hardware keys)
  3. Don’t use SMS-based MFA
  4. Use a password manager
  5. Set a Telco Pin
  6. Update software
  7. Opt for the latest phone hardware
  8. Don’t use a personal VPN.

If you’ve been trying to get friends and family to use Signal and have received pushback about “installing another app”, bringing up CISA’s report might help bolster your case. Most surprising was the recommendation “Don’t use a personal VPN”. It’s commendable that CISA has publicly called this out as the vast majority of non-technical people regard buying a VPN such as NordVPN to increase their security due to the massive amount of marketing that has gone into commercial VPN advertising. Reading between the lines, I’m very interested in this recommendation. It’s sound advice, using a VPN routes your traffic to another location, but why now? We don’t have many details about the recent Telco breaches, did a VPN provider getting compromised have something to do with the recent Telco breaches?

The Linux EDR Landscape

The EDR market is highly focused on stopping threats and providing telemetry on Windows devices. This makes sense as many initial access vectors such as phishing, social engineering, and password guessing, land an attacker on a Windows machine. Every year, each vendor marketing department comes out and says how they cover 100% of the MITRE ATT&CK. But do EDRs perform well on Linux devices? The data says no, even the top performing EDRs Uptycs, SentinelOne, and Crowdstrike taking the top spot didn’t do great on the benchmarks. Notably, they only perform marginally better than AuditD (The Linux Audit Daemon).

Key takeaways: Ensure telemetry from Linux servers is collected even if it’s just AuditD. The first place many advanced attackers establish persistence is a Linux server or hardware device they’re unlikely to be monitored. Linux EDR is a fairly new market that needs more skilled attackers to harden it.

Browser Extensions are Ripe For (Ab)use

Browser extensions are at a bizarre intersection of software that doesn’t quite run on the endpoint but isn’t quite a traditional web application. It runs somewhere in between, those “in-between” spaces are typically great areas for attackers to explore for stealing data, money, and personal information. Personal information collected from stealer malware includes: auto-fill information, cache data, cookies, session cookies (which allow for bypassing MFA), and hardware identifiers.

Recently, the popular coupon finder extension Honey was exposed for HIGHLY shady business practices, essentially stealing affiliate links from businesses when a user had the extension installed. I’ve been having interesting conversations about just how malicious these browser extensions can get, especially with the advent of Web Assembly (WASM) in the browser. It’s well known that browser extensions can be used to collect massive amounts of data, but can browser extensions be used to run covert infrastructure by running a container using WASM? The technology seems to exist already and the demand for popular extensions is already there.

What can you do to protect your organization? You can disallow unwanted extensions via GPO by configuring Computer Configuration > Administrative Templates > Google > Google Chrome. Additionally, monitor for inconsistencies and unusual browser activity.

Caught My Eye