[viraptor]

That would be a weird and not so subtle approach. The service has to be responsive enough to handle that 100GB of traffic, which DDoS works against. 1GB a day would be a rounding error for any established internet service, on the other hand if you get DDoS'ed, you will do at least a bit of log review.

I don't see what anyone would gain this way.

[KirillPanov]

Not really. If the attacker has code execution on the target servers they can just blast out UDP packets (with erasure coding for bonus points). The DDOS will jam up the inbound link to the target server, but the outbound link will be able to send out unacknowledged UDP packets just fine. Can make them look like DNS requests if you're paranoid.

If the attacker doesn't have code execution on the target -- in other words they just found a way to make some web server cough up data that it shouldn't -- then this won't work.

[viraptor]

This sounds like an action movie sequence. See the sibling answer. DDoS gives people reason to look into logs/metrics. If you get caught by an automatic check, you fail either way. If not, you move from an "everything normal" scenario to "we're looking at ways to kill traffic" scenario, which is not beneficial for exfil.

[dannyw]

You divert the time and attention of the security and ops teams; and DDoS-for-hire has made it relatively trivial to stage an attack even if you don’t have a bot net.

[viraptor]

Sec/ops doesn't normally involve looking at live network capture snapshots all day. ("Eyes on glass" monitoring exists, but that's not for common services) You're not distracting people from spotting exfil.

Either the company has the capacity to spot traffic anomalies like that or it doesn't. If they do, you're caught. If they don't, you're only giving them a reason to look in the logs because of DDoS. If your only issue was masking the higher network throughput, you can slow down. By starting DDoS you don't know what protections will be activated - it can be "running services in this state is useless, let's kill all of them until traffic stops". Or "there's lots of traffic to/from this AS, let's just kill that route". (it was your AS)

[sofixa]

> Sec/ops doesn't normally involve looking at live network capture snapshots all day. ("Eyes on glass" monitoring exists, but that's not for common services) You're not distracting people from spotting exfil

No, but if the people on call are being drowned in alerts because everything is down due to the DDoS, an alert saying there's anomalous traffic ( if it's even capable to detect that during a DDoS, when all traffic would be anomalous depending on infrastructure) could be easily missed.

[viraptor]

From my experience handling on-call during DDoS, there's not much drowning in alerts. You mute alerts about things being down. Then look at ways to drop the biggest / isolated types of traffic. Then analyse what is affected and start logging the impact. I don't believe anything would be missed: security monitors would alert different people / channels than service ops, post-incident review would look at alerts raised, any weird traffic would be looked at during "isolate and kill traffic" stage.

Volume is not the only way to notify about anomalies. Poisoned data entries / canaries, outbound traffic which should never exist, unexpected DNS queries, and many others will trigger regardless of DDoS.

[dannyw]

You are assuming everyone has their sh*t together, which is often not the case.

[jackjeff]

Are there any precedents?