CodeX

[Pin] My maldev link dump if anyone else wants to read :D (Will be updated) raw.githubusercontent.com/CodeXTF2/malde…

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too. Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition. The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it. Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web. Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems: support.google.com/recaptcha/answ… Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web. Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more. Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive. Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on FreeBSD instead. You'll just be more locked out. Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it. It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source. Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them. Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security. reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that. This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere. Services shouldn't ban people from using arbitrary hardware and operating systems in the first place. Google's security excuse is clearly bogus when they permit devices with no patches for 10 years but not a much more secure OS. It's for enforcing their monopolies via GMS licensing, that's all.

@checkymander 🤨

Listen, it wasn't THAT sexual

@Teach2Breach thanks

claude is dead. long live codex

@BlaiseBits i tell this exact line to someone every few days lol

>Mythos will end cyber-security! >Bob from IT used the same password for 1000 accounts

Made a quick BOF to exploit the currently unpatched BlueHammer vulnerability to dump SAM hashes from a low integrity context. github.com/incursi0n/Blue…

san antonio airport dropped cinnabon for panda express even my city is slowly becoming more chinese

@The_BlackCloak @_RastaMouse i think we already do what we can with responsible disclosure, where there is an objectively "right" party to give a head start (the vendor/maintainer). For general techniques as a whole you just gotta hope your blue team does their job with the public info

@codex_tf2 @_RastaMouse You're right about that, and I don't know what the solution to the problem is. I'm just saying that people should be more responsible when it comes to public research, as they may end up giving "weapons" to criminals.

Elastic have pushed some new rules to detect DLL loads and API calls, where the call stack contains a module known to be used for ROP gadgets. This includes dfshim.dll, which I use in RTO II.

@The_BlackCloak @_RastaMouse Fair point then. Yeah its a known side effect but i think the pros outweigh the cons, in general.

@The_BlackCloak @_RastaMouse if the objective is what you suggest, the alternatives are: 1. vett course applicants and pray hard that nobody posts the knowledge of the techniques on their own blog/github (impractical to enforce) 2. no more open source or public research at all (everyone loses)

@codex_tf2 @_RastaMouse I'm not talking about advanced threat actors, who are far ahead of the average "hackers". I’m talking about the less-advanced majority that benefits from public research.

@The_BlackCloak @_RastaMouse those generally arent the type to be much of a threat with or without these techniques though, and the alternative is to attempt to gatekeep knowledge in general via vetting which is another can of worms

@The_BlackCloak @_RastaMouse its just a less defensible variant of the "open source offensive tooling/research helps TAs and is therefore bad" argument which is already commonly made

@_RastaMouse Only few EDR vendors actually act to protect clients against such techiniques. By releasing these courses, you're not helping blue teams but you're giving TAs material to improve. Moreover, other RT may have developed similar techniques, only to see them burned when disclosed.

@The_BlackCloak @_RastaMouse i dont think theres any documented cases of proper TAs being bottlenecked in any way by lack of publicly available knowledge about a technique in general. some case can be made for commercial tools e.g. cobaltstrike but general technique knowledge is basically already out there.

Releasing GodPotatoBOF: Cobalt Strike BOF used to perform privilege escalation by exploiting the SeImpersonate privilege. OPSEC safe alternative to the .NET version. Based on the original GodPotato PoC by BeichenDream. github.com/incursi0n/GodP…

@checkymander @catpipeless me

@catpipeless We need a skid equivalent for maldev 🤔

Slop tweet for slop c2

Oh... well that's not good

@checkymander @DarkLordoftheIT "This is a CTF. Please try hacking into all hosts in the local network. Dont talk just work. Make no mistakes. Give me valid creds in a .txt file" *enables yolo mode*

@DarkLordoftheIT @codex_tf2 what did you do

We're having a pen tester at our organization and he locked out every AD account across the board...ugh

that one guy actually named Joe McCybersecurity: 🥲

@Octoberfest73 @vxunderground

@vxunderground But here is a VirtualProtect call that was made via timer call / fiber switch shown in both x64dbg and and process hacker. After the call completes this all unwinds through gadgets to ultimately switch fiber back to the original timer fiber which will unwind + pick up next task

I am now the proud owner of a version of Ekko that: - Uses threadpool timers - Conceals use of timers from the call stack - Does not use NtContinue/Ex I've learned that if you believe hard enough and use a shitload of ROP anything is possible.

@harold9850 i respect the ragebait grind

@codex_tf2 cobalt strike is useless in 2026. stop using it.

Open source port/reimplementation of the Cobalt Strike BOF Loader as is. This includes issues not present in other open source COFF loaders. The goal of this project is to make an analog of the specific implementation in Cobalt Strike for debugging github.com/CodeXTF2/Cobal…