How to Stay as Safe from the NSA as humanly possible

No replies
notballin's picture
Joined: 2011/06/18

Not deleting it this time (and given the nature of the contents of this post, I don't expect much discussion. As I don't live in fear anymore, I'm using my real name)

Original link is here (with more pertinent details that I won't post in this thread):

My name is Carlos Royal and I've witnessed several zero day exploits used against my computer. As a result of this, I've been the target of government corruption AND an extended gaslighting campaign that's designed to undermine the fact that the government got caught red handed breaking into my pc (when I was using an end-of-life system that had no management engine) by means of both attempting to erode my sanity/make me question my memory and attempting to pull me out of integrity (so I hand my power away/do something criminal-esque due to provocation and end up in prison/lose liberties or rights... to undermine the fact that the NSA got caught red handed). This post, which spans an experience of at least three years, is meant to combat the governments method/tactic of gaslighting (to escape accountability/acknowledgement of misusing government capabilities), by means of making my experience a public record (since the techniques/tactics employed rely on me staying silent due to doubt, fear, and "what if's"), and is highly beneficial to any security professional that reads it.

(to the organization that targeted me: Consider the above paragraph "Game Over.")

Mandatory backstory:

A while ago, I decided to challenge myself by attempting to obtain the Offensive Security Certified Professional certification in an effort to break into the penetration testing field. Over the course of 120 days, I managed to successfully breach and escalate on 16 systems within the OSCP lab.

Firefox Zero Day:

During my progress, I noticed unusual activity on my computer. I make heavy use of the Linux terminal on an everyday basis and I noticed that the shell that I was using wasn’t the first shell that was open.

Upon further investigation, I noticed two bash processes running on my PC. Upon closing the one that I wasn’t using, my Firefox browser closed at the exact same instant. This leads me to believe that I was targeted by the FoxAcid system due to my activity from the OSCP labs and that the zero day exploit didn't use the proper escape sequence.

Tor Malicious Node Zero Day:

I utilized an Open-WRT router as the base of my build. From behind it, I built an Arch Linux “transparent TOR router” that was designed to fail-close (where if my PC could not connect to the internet through TOR, it wouldn’t be able to connect to the internet whatsoever). From behind this router, I rebuilt my new PC using the Arch Linux distro. A few weeks later, after my build was complete, in use, and thoroughly tested, I observed on the “” page (which was a page that I would check compulsively) that I “wasn’t using TOR.”


This would lead me to believe that the government is in possession of a risky zero day exploit that exists to target TOR only users. Instead of targeting the TOR network directly, it would seem that this exploit works at the modem level and intercepts and possibly redirects the user to a malicious TOR node that’s not on the TOR network.

NOTE: If you "attempt to browse" the page and it attempts to resolve for an extended period of time when using TOR, you should probably reset your circuit. You're probably being unmasked and your connection to the page is most likely being dropped.

DBUS Daemon Socket Exploit/X11 Socket Exploit:

The "bash" and "sh" Linux binaries aren't the only things that the government can target. They are also capable of targeting other things, such as the DBUS-DAEMON socket or the X11 socket on a Linux PC, to create a secondary session for the purpose of viewing, and perhaps interacting, with the target's PC. Things that can be done include, but are not limited to: spawning extra lock screens, crashing GUI tied processes (such as security scripts running in konsole), crashing the GUI in general, viewing your keystrokes and monitors, etc. A home user's browser is one of the primary avenues of attack and can be targeted by state actors to spawn shell binaries (or any binary) or use exploits against the DBUS-DAEMON socket or X11 socket.

NOTE: This can be rectified with pre-existing open source software, such as firejail (read the man page, USE THE AUDIT FEATURE. It will TELL YOU WHAT TO FIX.):

firejail --rmenv=DBUS_SESSION_BUS_ADDRESS --private=/root/a/fake/home/directory/ --x11=xephyr --quiet --net=ethernet1 openbox

Alternative to openbox, adding "nolisten local" to the X11 options of the X server running on a users system will disable abstract sockets (which should be sufficient in combination with a private tmp directory and private network spaces to use the PC's gui instead of nesting it).

If you're cosmologically "lucky," you may be able to see firejail kick back an error when the "sandboxed application" attempts to access a blacklisted file/folder that it's not supposed to.

If you're concerned about sandbox escapes (which do exist), this can be combated with the "kill" command listed below, as well as with good old fashioned socket monitoring (such as running "ss," with extra parameters, in a loop to tie processes to IP addresses). I've also found that renaming "dbus-launch" and "dbus-send" to "dbus-launch.old" and "dbus-send.old" as well as qdbus to qdbus.old serves to stifle the sandbox escapes that aren't covered by the shell kill script. These sandbox escapes aren't AS DETRIMENTAL as having shell access/control over the users PC, but can still be used for seriously nefarious purposes.

Theory: The 3 letter agencies connect to a users pc through google IP addresses.

Zombie Tracking Cookies:

Firefox connects to the internet when opened, regardless of whether or not the user chooses to browse. Upon attempting to disable third party cookies, I noticed that there was a tracking cookie that was implanted in my browser despite the fact that I did no browsing. Previously, the only third party tracking cookie that I've witnessed was one belonging to "google." I theorize that the NSA's zombie cookies implant themselves when the user opens up their browser (which connects to the internet) and disguises itself as the site that the user visits first. Because I did no surfing whatsoever, the tracking cookie was disguised as a Mozilla tracking cookie. The Mozilla home page does not require third party tracking cookies. This exploit was spotted originally due to my use of an addon that self-destructs unused cookies after 1 minute. Before I found this cookie undisguised, I noticed that a "google" tracking cookie would continue to self-destruct every minute, despite me closing and re-opening the browser and not navigating to google. Catching it in it undisguised state some time later confirmed my suspicions that this was a zombie tracking cookie (which was most likely set to attempt to re-implant itself automatically whenever I opened my browser).

How Corna's Intel ME removal script no shit saved my skin:

Because of the nature of the incidents that I've witnessed, I've designed a script that utilizes the killall command that will kill all processes specified that are older than 5 seconds.

killall "sh" -q -v -y 5s

This command, when run in a loop every two seconds, kills all shells ("bash" and "sh" specifically) that are younger than 5 seconds. So long as a terminal process that THE USER CONTROLS is already running, the user gains the ability to use their own terminals while denying access to terminals that are opened as a result of any exploits that are used against their computer. The terminal is THE HEART of pentesting, and in denying this resource to an attacker, it denies an attacker the ability to gain control over a users PC. The idea is to open a few terminal processes before running this command in a loop in a script (AS ROOT AND AS A BACKGROUND PROCESS, since a terminal manager's process can be "crashed"), and then connecting to the internet as normal. Your operating system is capable of defending itself (for free) with native tools.

This technique can be used for more than just stopping shells. It can also be used for sandbox escapes that occur through firejail. Common binaries that the 3 letters can target are "bash," "sh," "dbus-daemon," and "qdbus (kde)." The last two can be spawned as processes and attached to firefox, similar to escaped shells. The kill command will work to stop the end result of Firefox forking to binaries on your system that it shouldn't fork to.

I actually ENCOURAGE anyone and EVERYONE to try this for themselves (I want to be proven wrong).

What's important to note here is that THIS IS USELESS WITHOUT THE INTEL MANAGEMENT ENGINE REMOVED FROM YOUR COMPUTER. No software solution will ever be a good enough solution so long as hardware backdoors/secondary operating systems exist within a users system. The Intel management engine contains an Operating system that shares physical resources with the target machine. Without Corna's removal efforts, I would be up the creek with no paddle. To obtain a better stance on PC security, open source security solutions must be used IN COMBINATION WITH CORNA'S REMOVAL SCRIPT/the removal of the Intel Management Engine. Both hardware and software security solutions must be used together.

I leave my post here for the security experts to judge for themselves (all attempts to take the appropriate channels to close the leaks, have failed spectacularly). Critique this logic, spin up a vulnerable VM, and TEST IT FOR YOURSELF.

I'd love for someone to prove me wrong.

There are no EIGRP adjacencies. Just routers that I allow to talk.

"Would you believe that my first hacking interest involved breaking OUT of a network rather than breaking into one?"