Earlier this year, AWS made available a new feature named "Traffic Mirroring" to their customers. This feature is available on any compute workload that is built using the new AWS Nitro System (link contains supported EC2 instance types). It is a really interesting feature, and as such I've wanted to try it out, as network traffic inspection and collection is notoriously challenging in the AWS cloud environment.
The next objective I want to deliver is to allow the code that I will be enabling the ability to access the infrastructure I just put together in Malware Analysis Pipeline in AWS (part 0). You see, AWS instances that execute code typically initialize in an unprivileged (and, in the case of Lambda, isolated) state. This means that, if I want these components actually working together, I will need to do additional work to grant them permission to interact with one another.
Many months ago, I purchased some of the following "Hardware Security Key" devices:
Lately I've been teaching myself AWS, as becoming “Cloud Native” is becoming a very popular strategy. During a few presentations, I've shared the benefits of maintaining a “Malware Zoo” for my team. One good example is my Malware Analysis on a Budget talk. The premise is relatively simple: Any security team needs a repository for long-term & organized archiving of malware. Over time, teams adopt or develop many analysis tools that will take malware samples as input, and output analysis. I'd like to share some of my experiments in adapting this approach to an AWS “server-less” architecture.