🐈 What you can learn from the Cisco breach

Read time: 5 minutesChuckles: 12

Hi again, it's meoward – your inbox's weekly dose of security. You know that ad for Coca-Cola that plays right before the movie starts? It’s just like that. Refreshing.

On the stack this week:

• 😵 Cisco got hacked: we do a deep dive into the attack, skip the IOC list, and go straight into how we can detect and prevent.

• 🦮 Microsoft patches Dogwalk: this vulnerability in the Microsoft Windows Support Diagnostic Tool was reported over 2 years ago. Woof.

• 🍭 Snacks: a free book on Mac Malware, a blog on how WMI classes invoke COM methods, and more tasty morsels!

Chop, chop. Look lively now.

HTTP/3 here we come!

The Cisco Breach

Last week, the Yanluowang ransomware group posted a list of files to the dark web claiming to have compromised Cisco. Cisco confirmed, stating the incident happened in May and was limited to their corporate IT infrastructure. The ransomware group claims to have stolen 2.75GB of data, including source code, NDAs, engineering drawings, and data dumps.

What happened?

Here's the play-by-play:

1. Compromise a Cisco employee’s personal Google account

2. Find their corporate credentials synced to their Google account via Chrome password saving

3. Get past MFA

   1. ❎ MFA fatigue: send the victim push requests until they're overwhelmed and approve

   2. ✅ Vishing: call the victim and pretend to be technical support

4. Enroll new devices in MFA

5. Connect to the VPN

6. Move laterally using the employee's AD credentials to login to other systems

7. Discover systems where they can get local admin privileges

8. Drop C2's and maintain persistent access

9. Dump credentials from LSASS

10. Get domain admin

11. Dump AD password hashes

12. Crack passwords offline

13. Use cracked accounts to steal more data

14. Ransom victim for profit

Lessons learned

I've seen this attacker playbook before, so let's talk about a few ways you can prevent and detect:

Passwords syncing to personal Google account

Two reasons this might occur:

1. Employees need to login from their personal devices into some Cisco corporate website. Maybe it's for accessing their pay stubs.

2. Employees are signing into their personal Google profiles on Chrome on their work computers. Corporate passwords saved in the browser are synced to their personal profile.

The solution for number 1 is to separate the credentials employees use to access things like pay stubs from the credentials employees use to access the internal corporate network.

Number 2 should be prevented by managing the Chrome browser in your enterprise environment.

MFA fatigue

MFA push requests, authentication successes and failures, and device additions and removals should all be logged. A flood of push requests, even if spaced out over time, are easily detected. It's unfortunate a lot of big MFA vendors still don't offer out-of-the-box detections for activities like these.

Answering simple questions like "how many push notifications does this user usually get in a day?" will get you most of the way there.

Device control

Connect to the VPN? Holy moly, please don't let just any device connect to your enterprise networks. Require some kind of enrollment. Block devices missing management and security agents.

This one made me cringe.

Enumerate

There's lots of local tools built-in to Windows, Linux, and macOS that threat actors use to learn more about the system, network, and environment. Attackers want to know what kind of system they're on, the groups and users present, what context they're running in, and what systems are available to hop onto.

Obviously, alerting on every net user is gonna be a bad time – focus more on detecting series of discovery commands and you'll have much saner alert volume.

Lateral movement

Getting complete network visibility can be difficult. Let's keep this one simple.

Get all your authentication logs in one place and start answering these questions for a single user over different time intervals:

• What's a normal number of interactive logon events?

• How many systems do they usually login to?

• What systems do they usually authenticate from?

Now scale those questions across all your users. Depending on your technology stack, detecting what's abnormal may not be straightforward, but it's time worth investing.

Dump credentials

Once an attacker has local admin privileges, there are many, many ways to dump LSASS without using Mimikatz. A lot of these won't trigger antivirus, either. Here's the method Cisco saw:

Once the attacker has the dump, they can move it offline and pull the passwords out with Mimikatz.

At some point, the attacker will find domain admin creds, and then it's game over for many of your users. The attacker will login to the domain controllers with the domain admin creds and dump the NTDS database file. Here's an example:

Once dumped, the attacker can move the Ntds.dit file offline, extract the password hashes, and start cracking.

Final thoughts

If you've been doing this awhile, you've seen this all before. It's not rocket science. But if you're a defender, it's a good exercise to walk through and identify any gaps or improvement opportunities. If you play an attacker (on TV), it's a nice playbook to test on your blue teams.

For everyone else, it's just a fun read. 😎

Microsoft patches DogWalk

Good doggo.

DogWalk is a path traversal vulnerability in the Microsoft Support Diagnostic Tool (MSDT).

You've probably seen MSDT pop up every time you uninstall the wrong driver and suddenly your graphics card stops working. MSDT will scan your computer for common problems and attempt to resolve them automatically.

MSDT opens Diagnostic Cabinet (.diagcab) files by default, which are really just archives for Diagnostic Configuration files (.diagcfg). This configuration file takes one important variable: a path. When MSDT opens a .diagcab, it copies any files in that path to a predictable temporary folder.

So if the variable is set to "C:\temp\" and this folder contains the single file "test.txt", MSDT would find that file, determine its name to be "test.txt", and move it to the temporary folder "C:\Users\meoward\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca\test.txt"

Here's the vulnerability: MSDT assumes the file is a valid Windows filename.

So if the variable in the config is set to be a folder on a remote WebDAV server, you can create a file called "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe". So instead of MSDT writing the malicious file to a temporary folder, it ends up writing it to the Startup folder. Next time anyone logs in, the malicious file will automatically run.

Anyway, Microsoft finally patched it after it was reported more than 2 years ago.

Snacks

• 💿 [tip] Phishing is bringing ISO's back. Here's a hot threat hunting tip for finding this activity on Windows.

• 🤷 [blog] WMI is complicated, so this concise 2 part series is worth a read. Part 2 covers how WMI classes invoke COM methods to perform actions.

• 📘 [book] Want to learn how to analyze Mac malware? This book is the perfect place to start.

• 💰 [discovery] Here's a cool recon method: find all the domains associated with a server just by correlating time values in certificate transparency logs.