This article makes so many unfounded assumptions in order to make a point.
> Presumably they are going to immediately make themselves admin, or wire all your bitcoin to their account.
Attackers running scams like a sophisticated BEC will lay dormant for long stretches of time to gather information before acting. Sure, they can export the emails and set up auto-forward rules to maintain visibility when the session expires, but they've now made a lot more noise to detect on. I've seen threat actors view mailboxes once a day for months before they launch this scam.
> Also, it would be better to protect against this by securing the logs or using hard drive encryption.
Of course it would, but often it's not. It's that simple. It's crazy to think the person responsible for writing a secure app is also the one making decisions on endpoint encryption.
> some applications are used strictly within an company from company devices
Some are, lots are not. This reads like someone who has worked in enterprise environments with well funded security teams, not a small business with one IT guy running the show.
> But even then, the attacker could install a browser extension that sends your credentials to them the next time you log in.
This contradicts the rest of the article. Why is a company securing logs, encrypting disks, locking down where users can access apps, but then allowing anyone to install browser extensions?
I agree that short sessions are not the quick fix that some devs make them out to be, but the author is ruling out a perfectly acceptable control based on an imaginary end user setup.
I recently had a BEC on my desk where they had gained access months earlier to a real estate agent's mailbox. They took the time to create perfect forged documents and understand the agent's workflow. Finally it was time to tell a buyer where to send their Earnest Money and the actions were perfect. They made a mail rule that captured the RE agent's outbound message and then sent their own, an exact replica with just the account number changed. Even if the buyer had called to verify the message it would have been fine because the agent really did send a message.
Of course finance people are used to stuff taking an arbitrarily long time (partly the users, partly the system) so they were able to do this several times before anyone raised the issue of MIA transfers.
Oh and we don't know the exact date of the compromise because the customer was not paying for good log retention from microsoft or exporting them to any kind of collector. We were able to uncover a lot but I wonder how this goes for indy RE agents that do everything out of AOL or whatever.
> Presumably they are going to immediately make themselves admin, or wire all your bitcoin to their account.
Attackers running scams like a sophisticated BEC will lay dormant for long stretches of time to gather information before acting. Sure, they can export the emails and set up auto-forward rules to maintain visibility when the session expires, but they've now made a lot more noise to detect on. I've seen threat actors view mailboxes once a day for months before they launch this scam.
> Also, it would be better to protect against this by securing the logs or using hard drive encryption.
Of course it would, but often it's not. It's that simple. It's crazy to think the person responsible for writing a secure app is also the one making decisions on endpoint encryption.
> some applications are used strictly within an company from company devices
Some are, lots are not. This reads like someone who has worked in enterprise environments with well funded security teams, not a small business with one IT guy running the show.
> But even then, the attacker could install a browser extension that sends your credentials to them the next time you log in.
This contradicts the rest of the article. Why is a company securing logs, encrypting disks, locking down where users can access apps, but then allowing anyone to install browser extensions?
I agree that short sessions are not the quick fix that some devs make them out to be, but the author is ruling out a perfectly acceptable control based on an imaginary end user setup.