For all 3 scenarios, it's difficult to spot anomalies just by looking at or learning from network layer. Why?
1) The first endpoint could have visited the intranet pages at some point in time, there's nothing unusual about that.
2) Likewise, the admin could have made RDP connections to servers for work.
3) Again, that user could have printed to that vulnerable printer.
With fused data, the anomaly would surface if it wasn't a browser process that had connected to the intranet web server. Of course we can argue that a careful adversary would have injected into a browser process, but that will be flagged if we are monitoring cross process activities with Sysmon or better still with Endpoint Protection that can block injections to browsers.
Also it is also very likely that the adversary would need additional C2 with another process that is more long-live/persistent within the system in case the user terminates the browser.
For the 2nd scenario, it is unlikely that the attacker would use native Windows RDP client since it will appear in the foreground, possibly giving away to the actual user (though it is possible eg. compromised headless jump server). Then it would be some background process that connects to server RDP port. That would be the anomaly.
The 3rd scenario will need Deep Packet Inspection to look at the type of PJL/Postscript commands (print jobs are essentially a series of commands usually over plain/not-encrypted channel) to typically TCP 9100 printer port. Suppose the attacker had to use some other ports to access the network printer (eg. 8443 for printer admin page & we love default passwords), then it may be possible to use network meta-data alone to flag this as a rare event.
One approach would be to train the machine with fused data sequences or combination of attack sequences; think of it as training the machine with scenarios, but at the same time also train the machine the legitimate use-cases of using the resources for the various attack stages.
When a new sequence (both endpoint & network data points) comes along, there are actually two non-binary results such that it becomes a ratio of how close is this new sequence is map to known bad and good, and also multiplied to the various stages of attack weightages.
Graph-based database is good for tracking across possibly long time-span & multiple assets as depicted by the various examples. Graph visualization is also useful even we did not have any machine learning capabilities.
With fused (endpoint + network) data constantly updating a graph database, we can generalised queries that match for processes that accessed both internal resources & connects to an external C2 (don't even need machine-learning at this juncture of analysis). The matched results are then be subjected to machine-classification to reduce false positives, instead of bashing it with unnecessary data, which in turns bumping up the cost of analysis. This approach can pick up quite reliably rare (as in unique hash within the population, Sysmon event type 1 has hash checksum) unsigned binaries (eg. custom RAT/backdoors) or even system tools like Powershell (or some other Windows components) that are not known to communicate with internal resources. For non-browser processes that constantly beacons out to the same external addresses are good indicators that something is fishy,
with the assumption that we cannot detect various host-side code injections like DLL/shellcode, process hollowing, dopelgangring payloads. Without that capability, it is tricky to catch malicious codes that are injected into browsers (or any other process) that are known to communicate-with/access both external web sites & internal web sites or resources within a given user-session. It would mean we need to check for suspicious code-injections into browsers for a more conclusive assessment. Trying to detect beaconing on browser process may not be a good idea since websites are known to poll with javascript. Websockets over SSL (proxy may pass-through TLS/SSL web traffic) may be used as ad-hoc (aperiodic) C2, such that there's a long-live connection that only ping-pong once in a while from the remote server. https://github.com/Arno0x/WSC2Better way to mitigate the browser problem is to separate Internet surfing since browsers are notoriously hard to secure given the abilities to extend with add-ons & various programmatic mechanisms like Javascript & HTML5 (attack surface, the sum of attack vectors or means to attack).Consider Isolation approaches like BlackPC (physical), Menlo Security (web), Bromium (process level) disrupt
Adversarial Emulation to Train AITable-top exercises are good for refining procedures (eg. SOPs) & inter-stalk-holder communications. But when it comes to technical detection, adversarial emulation is useful for various purposes like accessing effectiveness of combined controls & training AI for cyber.It is not really a matter of "predicting" the attack like as if it was Minority Report movie, but rather to pre-emptively train the machines with scenarios combinations such that it becomes better at spotting sequences that may differ in tools/techniques but similar in asset access pathsMITRE released an opensource tool to automate adversary actions: https://github.com/mitre/caldera but it has limitations in terms of network size. https://www.blackhat.com/docs/eu-17/materials/eu-17-Miller-CALDERA-Automating-Adversary-Emulation.pdfAnother possible approach is to use production grade tools like https://cronus-cyber.com to overcome Caldera's limitation & enumerate the attack paths of a larger network. The output of Cronus is then fed into actuation module of automation tools like Caldera or AutoTTPAutoTTP does not have "planning" ability like Caldera. It is more of a code/scripting-driven penetration testing tool. Caldera is more sophisticated given that it models the environment & uses certain logic to decide the next course of offensive action based on real-time survey of the environment. Caldera does not use exploits & only uses 1 type of RAT, while AutoTTP can in practice be extended to use outputs from Cronus to decide which exploits based on vulnerabilities discovered by Cronus vulnerability scanning & path-generation (ie. a vulnerability to technique mapping module). Cronus provides network paths/trajectories that an adversary might take after the discovered vulnerabilities after scanning, which in practice be translated to AutoTTP scripts for automated actuation of the entire attack sequence.