Recently Twitter had a security breach, with a silly scam. At least, I'd think it was silly. I saw a tweet from Elon Musk noting that he'd return $2k in bitcoin for every $1k anyone sent to him. He said he was feeling generous towards others. I didn't believe him.

While that might seem silly, a number of other high profile accounts were breached and seemed to lend some level of veracity to the offer. I saw a few news reports that the hackers made off with over US$100,000, so apparently at least a few people were fooled. Twitter locked down verified accounts for a bit while it investigated, removed some tweets, and tried to close the security hole.

What is disturbing here is that apparently the hack took place through Twitter syadmins, with privileged accounts. As of this writing, it isn't clear if this was social engineering or a sysadmin worked with hackers, but there were internal tools allowing Twitter employees to post tweets on behalf of users.

I have no idea how this happened, but I'm assuming this is some sort of data change made to their system. If this were an RDBMS with a "tweets" table, this would be adding a row to the table with links to the verified accounts' linkage. Not a hard change in the SQL Server world, and certainly the type of change that most admins could make.

The question might be should they be allowed? Many of us have made ad hoc data changes to systems to correct an issue, and some of us do this regularly.

This reminds me of some customers whose DBAs aren't allowed to directly connect from SSMS (or other clients) to production and make changes. All changes, including ad hoc data changes, must be submitted to some sort of pipeline, where the change is logged, and perhaps approved by someone else. A different sort of two factor authentication.

Should this be a more common pattern of access to production systems? Limiting access by everyone, even admins? I know we need to trust administrators, but what happens when administrators get fooled by social engineering? A thorny attack vector that we ought to be considering in our architectures.