I run training courses on developer security to broaden their understanding of threat surface from their behaviour, day-to-day tooling, the repositories they work on and broader supply chain. One of the modules covers this exact scenario, it's amazing how many people do these exercises on corporate machines let alone their personal device!
There are mitigations you can put in place by using containers, virtual machines or even the execution environment e.g. Deno's ability to block/whitelist network calls[0], Bun's --ignore-scripts [1] and supply chain package managers have made some strides here like pnpm [2]. But it's knowing your threat surface and how to use your tooling which can be quite overbearing on cognitive load, especially in fast paced scenarios like "job of a lifetime offer!" from linked in.
Easiest way by default is to use ephemeral VMs / Sandbox Containers for such tasks which don't have mounted directories to your system etc. Or spin up a cheap EC2 / VPS to work on them in a short period of time.
Dependencies and supply chain attacks are probably the greatest risk to a lot of software orgs, as they run them across all their environments: Development (with secrets and other valuable artefacts on developer VMs), CI/CD pipelines which may have access tokens to production (and other) environments, and production itself.
Notably even security companies are being impacted by this[0]. The scale of these attacks has amplified quite significantly the past three years, but are not solely exclusive to the javascript ecosystem [1] or even just namesquatting/typosquatting [2].
The resolution is broader security awareness, "onion layered" security controls and implementing simple non-burden inducing processes and policies. Sometimes not updating (what was wrong with the previous version of a dependency if there was no immediate vulnerability or production issue caused by it?) or having a two week cool down for updates (which some supply chain tooling natively supports) can appease some security functions through clear communication of the supply chain risk etc.
If anyone has interest in courses aligned to your org on improving developer and broader engineering management awareness on this, e-mails in my profile :).
*Unless your in the cloud, then it's a metric to nickel and dime with throttling!
On a more serious note, the performance of hardware today is mind boggling from what we all encountered way back when. What I struggle to comprehend though is how some software (particularly Windows as an OS, instant messaging applications etc.) feel less performant now than they ever were.
Thanks! I actually wrote my master thesis surrounding cyber resilience, and the same week of submission they released their Cyber Action Toolkit (a precursor to Cyber Essentials). I was able to provide them some feedback which has since been incorporated so believe I am closely aligned to their recommendations!
I'm building a training platform for cyber security and secure development practices. Mainly to address the junior to mid engineer gaps of "depth" across general cyber security and software engineering skills. I've encountered quite a few folk who have surface level knowledge but when having to problem solve production ready problems are blocked quite quickly, it's depth of knowledge which is missing. If anyone is interested reach out in a preview / providing some thoughts, reach out - my emails in my profile!
Call me dumb - I'll take it! But if we really are trying to keep it simple simple...
Then you just query from event_receiver_svcX side, for events published > datetime and event_receiver_svcX = FALSE. Once read set to TRUE.
To mitigate too many active connections have a polling / backoff strategy and place a proxy infront of the actual database to proactively throttle where needed.
It does sound like you've been compromised by an outfit that has got automation to run these types of activities across compromised accounts. A Reddit post[0] from 3 years ago seems to indicate similar activities.
Do what you can to triage and see what's happened. But I would strongly recommend getting a professional outfit in ASAP to remediate (if you have insurance notify them of the incident as well - as often they'll be able to offer services to support in remediating), as well as, notify AWS that an incident has occurred.
I'm officially off of AWS so don't have any consoles to check against, but back on a laptop.
Based on docs and some of the concerns about this happening to someone else, I would probably start with the following:
1. Check who/what created those EC2s[0] using the console to query: eventSource:ec2.amazonaws.com eventName:RunInstances
2. Based on the userIdentity field, query the following actions.
3. Check if someone manually logged into Console (identity dependent) [1]: eventSource:signin.amazonaws.com userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda] eventName:ConsoleLogin
4. Check if someone authenticated against Security Token Service (STS) [2]: eventSource:sts.amazonaws.com eventName:GetSessionToken
5. Check if someone used a valid STS Session to AssumeRole: eventSource:sts.amazonaws.com eventName:AssumeRole userIdentity.arn (or other identifier)
6. Check for any new IAM Roles/Accounts made for persistence: eventSource:iam.amazonaws.com (eventName:CreateUser OR eventName:DeleteUser)
7. Check if any already vulnerable IAM Roles/Accounts modified to be more permissive [3]: eventSource:iam.amazonaws.com (eventName:CreateRole OR eventName:DeleteRole OR eventName:AttachRolePolicy OR eventName:DetachRolePolicy)
8. Check for any access keys made [4][5]: eventSource:iam.amazonaws.com (eventName:CreateAccessKey OR eventName:DeleteAccessKey)
9. Check if any production / persistent EC2s have had their IAMInstanceProfile changed, to allow for a backdoor using EC2 permissions from a webshell/backdoor they could have placed on your public facing infra. [6]
etc. etc.
But if you have had a compromise based on initial investigations, probably worth while getting professional support to do a thorough audit of your environment.
Cognisant US pricing for the HP Z Book Ultra was astronomical, within the EU it's on par with standard laptops and to good effect. The only regret I have is ordering on release day and not wanting to wait for the 128gb version; but battery life and power has remain unmatched to any of the pretty large workloads I have thrown at it!
Outside of laptops, Beelink and co. are making NUCs with them which are relatively affordable!
I do agree, the scarcity has limited their opportunity to assess the growth opportunity.
Sure then throw Ansible over the top for configuration/change management. Packer gives you a solid base for repeatable deployments. Their model was to ensure that data stays within the VM which a deployed AMI made from Packer would suit the bill quite nicely. If they need to do per client configuration then ansible or even AWS SSM could fit the bill there once EC2 instance is deployed.
For data sustainment if they need to upgrade / replace VMs, have a secondary EBS (volume) mounted which solely stores persistent data for the account.
If you want to integrate this into Windows AD look at ADFS[1] and MSAL[2]. Pretty much can give you OIDC from AD, but you'll have to deal with Microsoft licencing :D.
There are mitigations you can put in place by using containers, virtual machines or even the execution environment e.g. Deno's ability to block/whitelist network calls[0], Bun's --ignore-scripts [1] and supply chain package managers have made some strides here like pnpm [2]. But it's knowing your threat surface and how to use your tooling which can be quite overbearing on cognitive load, especially in fast paced scenarios like "job of a lifetime offer!" from linked in.
Easiest way by default is to use ephemeral VMs / Sandbox Containers for such tasks which don't have mounted directories to your system etc. Or spin up a cheap EC2 / VPS to work on them in a short period of time.
[0] - https://deno.com/blog/deno-protects-npm-exploits and https://docs.deno.com/runtime/fundamentals/security/
[1] - https://bun.com/docs/pm/lifecycle
[2] - https://pnpm.io/supply-chain-security
[2] - https://