SMB is indeed commonly used outside of broadcast domains, hosts can find each other through dns (or wins etc), and happily communicate across ethernet segments. In many cases most of the servers will be in a different ethernet segment to the workstations etc.

SMB will almost never be filtered internally because it's used for domain logons and file sharing, and users will have a need to access files stored on servers in other parts of the company.

On the other hand, SMB is a terrible protocol... Not only does it allow file sharing, but it can be used for all manner of other things too, so by permitting it for something you need (file sharing) you are opening yourself to all manner of other things you don't need or want.

Doing what you describe is simply not practical for a windows based environment. Sure ideally SMB would be blocked, and a dedicated "file sharing only" protocol would be used, but windows only supports SMB by default.

You're assuming that it spread by trying to guess usernames and passwords, which is highly unlikely.

Chances are it spreads using usernames and password hashes that it already knows. If you compromise a single windows host you can extract the local admin hashes (which are often the same across many hosts because they were all built from a stock image), you can also extract the hashes as well as the plain text password of any currently logged in account including domain accounts, and any account which is saved in the registry for use to start services (i've seen networks where the antivirus is running as a domain admin on every host - ensuring that an admin password is extractable from every single host).

Using this hash passing approach you can almost always spread throughout a network.

As for logging...

Your IPS will probably ignore SMB traffic, because it's extremely common and expected.
The hacker will target the workstations first, they are probably not configured to send their logs back somewhere centrally... Chances are at least one workstation will have a valid domain admin hash available on it at some point. You only start hitting the servers once you have confirmed valid logins, valid SMB logins from internal workstations won't trigger any IPS because they are expected.
Windows logging especially is usually quite shit, it's either far too verbose (the attack gets lost in the noise), or utterly useless... You might be able to detect a flood of invalid login attempts against the domain or directly against core servers, but a competent hacker is highly unlikely to try that.
Otherwise your logs are only really useful "after the fact" to try and determine what went wrong, because by that point you now have time and budget to sit and comb through them. Ofcourse this also only works if your logs are sufficiently detailed, and are still intact. If the system hosting your logs was on the domain, or accessed from workstations which are part of the domain then your logs are effectively worthless, a competent hacker would have deleted or modified them to cover their own actions.

So they're stuck with poorly designed tools (ie windows), that have gaping design flaws that make such attacks easy to perform and hard to detect or stop. You could go to significant effort and expense to make such attacks more difficult, but many companies just won't have the budget for that in terms of the number and quality of staff (competent people are expensive), all the various expensive third party software and all the extra time (or extra staff) required to do things in a more secure but far more time consuming way.
In reality, people cut corners. Even those who should know better, want to save themselves time or have to save themselves time because the company hasn't hired enough people for what they need.

Yes, yes they are...
Most companies have a horrendously insecure internal network, with virtually everything tied to an active directory domain which is laughably easy to compromise. They follow what they believe are best practices by installing patches every month, using strong passwords, setting account lockouts etc, but because of how the system is designed it only takes one weakness to make everything fall down. And then they will probably spend a lot of money buying "security software" that just makes the systems run far slower, while not fixing any of the underlying weaknesses.

Most company networks are like a tardis, they use a network firewall to ensure that only a tiny fraction is visible from the outside, but once you get inside it's much bigger. All it takes is for one minor breach in the firewall by someone semi competent and 99% of companies would be looking at a catastrophic breach. If it hasn't happened to your company yet then it's either a) luck, or b) it has happened but the perpetrators have other motives than publicity

It's common practice to put all of your servers and workstations in an active directory domain, and once you have a tiny foothold on an active directory domain it is almost always trivially easy to get administrative privileges over the whole domain (have been working as a pentester for 10+ years and never failed to get domain admin when the job scope allowed it)...
Once you have domain admin, you typically have access to pretty much everything. Even if the organisation has devices which aren't linked to active directory (typically unix boxes, routers, switches etc), you will probably find that the guys responsible for managing these devices do so from a windows workstation which is part of the domain, so you just find their workstation and start keylogging (or in many cases just find the textfile full of passwords).
Also in my experience, very few companies notice once you take control of their domain, and as a legitimate pentester i'm not trying to cover my tracks. The chances of most organisations noticing someone who is being careful is virtually 0.

China...

Noone ever picked FAT, it's a very poor filesystem and the only reason it ever gets used for anything is because MS won't support anything else unless it's even more proprietary.

Hiding insecure boxes behind firewalls is NOT any kind of solution...
A firewall may stop unsolicited inbound scans but thats about all... You can still be attacked via outbound connections that you initiate (e.g. browsing), removable media you insert, files you download etc or from other boxes on the same network behind the same firewall.

While i agree about blocking intrusive ads, the fact that adblock are demanding money from advertisers really is extortion.
If they were just allowing unintrusive ads by default and not taking money for it they might actually encourage advertisers to clean up their act.

One of the stories on this mentioned they had access for a year...
Sony pictures likely has extremely fast internet connections at multiple sites, as they deal with movies its highly likely they will be sending large high resolution video files around.

Chances are they do have high bandwidth links for copying high resolution video files around, and that pipe will not be fully utilised all the time, there would be plenty of downtime when there was a lot of bandwidth available for exfiltrating data, and because high bandwidth usage is not uncommon it could easily go unnoticed. It doesn't matter if it takes a long time, so long as it hasn't been noticed you can sit on there for weeks or months gradually copying stuff.

Also in one of the other stories about this hack i read that they had access for over a year.

Many pieces of malware are far more benign than that, and yet people have gone to jail for writing them...

No, you can run full blown linux on the Amiga if you have a model with an MMU (which an A1200 with accelerator typically does), see https://www.debian.org/ports/m... for instance.
I used to run linux on an A1200 with a 68040, and i still have an A4000 with linux installed on one of the drives.

The 68030 has an MMU providing you don't have the cut down 68EC030 model...
Motorola made an external MMU for the 68020, known as the 68851 i believe.
Some 68000 based machines also used an external MMU, but typically not a Motorola design, eg the early sun workstations.

#1 does not require compromising the CA... Any CA is beholden to the government of the country in which it operates, and would be required to hand over the private key if ordered to do so. And the more people who have the private key, the greater chances of it leaking.

Depending where you live, the publisher may have added an arbitrary delay themselves - ie the game is not released yet where you are... Even with a delayed crack, the crack may become available first in some places.

And the few who will buy because a crack isn't available yet could well be outnumbered by the people who decide not to buy as a result of seeing or reading about the game being unstable and/or causing other stability problems outside of the game (eg some drm schemes come with background processes or drivers which cause problems even when the game in question isn't running).

Instead of wasting so much effort on ever more complex (and thus error prone) DRM schemes, they should retask those developers to actually improve the quality of the games themselves.