In this month’s newsletter, we we cover off on:
We wrote a HR and security blog post a couple of years ago; we’ve updated the post now because it looks like we were on the money back then and more recent investigations are revealing an interesting trend where crooks, including North Korean operatives, have infiltrated numerous Western companies by posing as remote IT workers.
Interestingly there is often an insider to lend a hand. A notable case involves Christina Chapman, an Arizona resident indicted for assisting North Korean nationals in obtaining remote IT jobs in the U.S. Chapman managed a “laptop farm,” enabling these operatives to appear as though they were working domestically, thereby bypassing security protocols. Of course Bob the cat fiend was there first!
Compounding the threat, the FBI has issued warnings about the use of AI-generated deepfake audio in scams targeting U.S. officials.
The attacks that the FBI has warned about involve impersonating senior government figures to extract sensitive information or credentials from unsuspecting victims. Of course, they’re not all experts… that’s where the LOLs come in:-)
Seriously though, this trend does underscore the imperative for HR and recruitment professionals to implement rigorous verification processes. This includes thorough background checks, validation of candidate identities, heightened awareness of potential red flags during the interview and hiring process and the implementation post-employment of technologies including Zero Trust, MFA, EDR and SIEM as part of the organisation’s Secure Operating Environment.
We’ve posted part 2 of our technical blog post, describing our investigation into the process that attackers use when sideloading malicious DLLs into .NET executables. Part 1 is here; you should read that first!
Sideloading .NET DLLs can be very easy when strong-name signatures are not validated, due to the simple algorithm used to search for dependencies. However, even when strong-name signature validation is enforced there are still plenty of Authenticode-signed .NET executables which are not strong-name signed which can be (ab)used for sideloading malicious code.
As a defence practitioner, what are your options for detecting sideloading of .NET DLLs? The obvious tell in all the examples given above is that the DLLs which were modified were originally (authenticode-)signed and modification breaks their signature.
In terms of practical detection and prevention, the best way forward is probably implementation of application whitelisting through a solution such as ‘Application Control for Business’ (formally WDAC).
While implementing App Control may be a non-trivial task in an Enterprise environment, it certainly does make an otherwise quite-easy life more difficult for attackers.
Have a read and give us a yell if you want to know more!
We’ve written about the PCI DSS (Payment Card Industry Data Security Standard) on many occasions, so you’ll know that is a standard (one of a set of standards, actually) that is designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment.
Selecting the correct SAQ is crucial unless you want to waste money and time on unnecessary reporting.
Merchants need to (and yes, dotSec can help here) determine which SAQ applies to them based on their cardholder data flow and review their data flow against the eligibility criteria in each SAQ.
The SAQs themselves have the eligibility criteria listed before the questionnaire. So in general, we can determine which SAQ applies to a merchant based on their cardholder data flow and by reviewing the data flow against the eligibility criteria in the SAQs.
If you handle this data, or if your service provider does (on behalf of your organisation), you are bound by PCI DSS requirements. And in this post, we’ll help you to understand how to reduce your PCI DSS-compliance reporting load.
We’ll be back with another summary newsletter next month. In the mean time, please enjoy our blog posts!
