A follower sent me a suspicious looking file recently to get my opinion on its behavior and to see if I could pull out a little detail on how it’s working. “Suspicious looking” because at the time, it was getting a zero score on VirusTotal but it appeared to be doing something just a little dodgy in the background. I wanted to post some notes around my quick tear down of the malware show that since so much malware is poorly written and obfuscated you can often do a large amount of analysis of a file’s behaviour in a short period of time.
There’s no doubt that domain accounts with weak passwords can be a serious concern for companies, there are a few ways you can protect yourself against issues like this. The first is to set a domain and local account lockout policy and the second is to enforce password complexity. However if your users are using “Password1” as their password, neither of these steps will protect you.
LulzSec were an international hacking crew and today marks 5 years since the end of their most well-known campaign: the “50 Days of Lulz”.
Interpreting and understanding law is a difficult thing. However many Information Security, Ethical Hacking, and Cyber Security degree courses feature understanding the law as a requirement. There’s also an awful lot of law and literature out there about the many offences that an individual could commit during the normal course of careers in offensive security roles such as penetration testing.
Here’s a photodeck of how my weekend went…
Brief: A talk about options advanced attackers can deploy to beat behavioural malware analysis through the detection (and subversion!) of the behaviour engines themselves. Including a demonstration of how to beat modern engines through a working tool (demos!).This talk should be interesting to malware writers and analysts alike as it shows implementations of beating analysis, but also includes enough inline explanation to make it accessible to beginners.
This weekend I posted a tweet, a short simple statement – with a lot hidden behind it:
Security is Hard
I was trying to provoke discussion around two opposite ends of the security spectrum. The idea that security is so difficult that we might as well abandon the whole idea and the idea that security is trivially simple but there are certain blockers in the way (such as managerial denial, being understaffed, tech debt) which are preventing any real progress. The idea being that people are laughing at the statement “Security is hard” because they so wholeheartedly believe one of the above views that they cannot see the other.
Recently during a CTF I found a few users were unfamiliar with abusing setuid on executable on Linux systems for the purposes of privilege escalation. If an executable file on Linux has the “suid” bit set when a user executes a file it will execute with the owners permission level and not the executors permission level. Meaning if you find a file with this bit set, which is owned by a user with a higher privilege level than yourself you may be able to steal their permissions set.
The settings are configured server side and given to the web browser via a server response header, the “Content-Security-Policy” header, here’s a simple example of one of these headers:
Content-Security-Policy: script-src 'self'; object-src 'self'
Docker is all the rage at the moment, but a few people have asked me to give an overview of security considerations when using Docker. So here’s some notes!