It really depends on the environment and if you actually know (or can reasonably suspect) where they got in -- or at least have a grasp of what data they have to give you a hint of where it might have been sourced.
It's worth noting: the vast majority of breaches are caught in the act and subsequently contained, and you'll never hear about them. Examples from my past typically started with a piece of malware on a PC somewhere, which begins reaching laterally across the same network to find other vulnerable PCs, and then will start reaching out into other routed networks (usually as linked to mapped network drives or open network sessions from the infected PCs) to begin scouring those areas for weaknesses. Most attempts are blocked at the source with high quality EDR software; you can think of it as a far more advanced form of antivirus combined with a good huerstics analysis engine. Even if a brand new piece of malware which has never before been seen lands on a PC with a good EDR solution, the behavior of a brand new process having been spawned out of a browser parent process which then immediately starts walking the network sessions list in the kernel is immediately flagged as bad news and stopped.
If that piece of malware is far sneakier, maybe it just runs and does nothing for hours, or days, or maybe even longer. Maybe it only opens up one network session every few hours, to a single IP and port, just to test. What you're looking for is traffic that shouldn't be there: why is John Doe's laptop from Accounting trying to access the engineering file server? Why is our internet bandwidth egress somehow 5% larger today than our typical, and why is that excess seem to be destined for an Akamai endpoint? Why did Jane Doe's account get authentication denied against ten completely different servers over the past two days, when she's never accessed any of those servers in her past?
A diligent organization will have detailed logging around processes which stopped and started for each machine, network session establishment and teardown for those same machines, where authentications were approved or rejected across the enterprise, sample netflows for things crossing internal and external network boundaries. If you suddenly get an alarm for non-normal behavior, now you get to start walking that all backwards -- where did this new network session come from? Ok, now from that source PC, who has it been talking to, and who has been talking to it? Walk those backwards, are they normal? These five network sessions are non-normal, where did they come from, whose account was it using to auth? Where else does has that account logged in successfully in the last day? Two days? Weeks? You just keep following all the little silk threads until you finally have convered the entire spider web.
Really good threat actors don't smash and grab, they sit very quietly in your environment for weeks or months or longer, and will take very tiny and very carefully planned steps to discover the topology of your environment, unearth where the interesting things may lie, and then move data out in the most inconspicuous way possible. Whatever this databreach was at AMD, I can already tell you those threat actors had been in their org for probably weeks if not months. And if the SOC only discovered the breach when the news headlines hit the virtual airwaves, they have a world of pain waiting for them as they now try to reverse-engineer all the places that data could exist, what and who touched that data in the prior weeks or months, and so the process grows...
www.cdw.com
www.tomshardware.com
