Anti-Spam Doesn't Catch Everything

Here's an interesting email: 

 

You'll need to click to enlarge.  The interesting part isn't that it's a phish, it's that it seems to have been released by Proofpoint and marked safe.

Initially, I thought that the email had been dressed up to look as something that had been screened, enabling it to slip through the email filters - sort of like parking where you know you're not supposed to park and leaving your own ticket on your windshield - maybe the meter maid will think they've already ticketed you and will leave you alone.  But on looking at the headers, that doesn't seem to be the case:

Based on comments by others (see https://security.stackexchange.com/questions/172860/analyzing-received-from-header-of-phishing-email), the prod.exchangelabs.com addresses seem to be various Microsoft servers, dutifully passing along the mail, and the original header looks to be gone, perhaps deleted by Proofpoint.

Oddly, the email address looks to be a Microsoft spoof:

The same address appears higher in the email (see the first image) as a "To" address earlier in the email thread.  Always look closely at email addresses - they may not be what they look like.  I nice trick to check email addresses for hidden mispellings is to (carefully) copy them into Word, then convert case to all caps: an rn masquerading as an m becomes RN, rather than M.

Finally, a coda.  As I wrote this post, my email app labeled the original email as junk and blocked the links.  Better late than never.

 

 

Rannsomeware deployed via unsecured webcam

Bleeping Computer reports the Akira ransomeware gang, initially stymied in their effort to deploy ransomware due to the target's EDR system, pivoted to an unsecured webcam for their deplyment. The gang gained most-likely gained initial access via stolen or brute-forced credentials, then used remote-desktop protocol software to move laterally. Once in place, they attempted to deploy their ransomeware. The target's End-point Detection and Response (EDR) solution quarantined the ransomware, so Akira scanned the network and found the unsecured camera, from which they successfully deployed the ransomware.

This raises a few questions:

• Why was the camera unsecured? Details are limited, but web-enabled cameras need to be patched in the same way that other items are. If the device can no longer be updated, the most-secure next move is to replace it, but failing that, wall it off.
• Related, why didn;t the EDR solution include the camera? Clearly, the EDR was capable of recognizing the ransomeware, so this seems like a missed opportunity to head oiff this attack.
• Did the camera need to be on the same network as the data server housing the target's corporate data? Internet of Things devices often can be relegated to their own network. If they can't be, monitoring their traffic seems like an obvious step. Here, the threat actor made had to increase the ammount of traffic between the camera and the servers, presenting an opportunity to discover the attack, but the camera's traffic wasn't being monitored. Similarly, it looks like Akira had to use the camera to connecct to end points that it didn't normally connect with, meaning that monitoring of the volume or type of communicationf wiht the camera, or the devices with which it communicated, would have revelaed the attack.

What all of this boils down to is: Zero Trust. All of the traffic accociated with this camera seems to have been trusted implicitly. As an industry, many of us are being slow to move from an implicit trust (or allow) to an implicit suspicion (or deny) among the components of our networks. The reasons are the usual, including inertia, financial and labor costs, lack of will from above, and the need to accommodate legacy components; but the costs only go up.