Several grammatical edits

This commit is contained in:
arcanedev 2021-09-01 19:22:32 +00:00
parent f82ef9da4b
commit 2f63d09984
No known key found for this signature in database
GPG Key ID: 13BA4BD4C14170C0
1 changed files with 5 additions and 5 deletions

View File

@ -115,9 +115,9 @@ For desktop, this process eliminates Windows, Mac, and ChromiumOS/CloudReady fro
Note: Solutions with Windows 10 aren't necessarily the anti-thesis to anti-forensics. These systems are extremly bloated and can pursue the same aims. Windows provides many areas to hide files amongst the system. Windows systems can also be an overload to inexperienced investigators with the caches, shellbags, shortcut files, monolithic registry hives, and a myriad of ways to set persistence mechanisms. This could force investigators to expend more time in the investigation. The reason it is avoided in this book is due to the proprietary blobs, bloatware, legacy protocols (which will continue to render it vulnerable to exploitation), and excess telemetry. In good faith, one could not claim to provide secure cryptography on a system that was designed for the aims of counterinsurgency.
GNU/Linux is the only operating system baseline that will not phone home and create excess logs locally. Even after making such a decision, there are hundreds of derivatives to sift through. At the time of writing, the only anti-forensic friendly distributions designed to reduce the creation and storage of artifacts are Qubes, TAILS, and Whonix. However, any OS lacking telemetry with properly implemented full-disk encryption (FDE) and physical security is sufficient for the job of anti-forensics. If more persistence is desired while keeping distribution size minimal, hardened variants of Arch, Void, Gentoo, or Alpine are advised.
GNU/Linux is the only operating system baseline that will not phone home and create excess logs locally. Even after making such a decision, there are hundreds of derivatives to sift through. At the time of writing, the only anti-forensic friendly distributions designed to reduce the creation and storage of artifacts are TAILS and Whonix. However, any OS lacking telemetry with properly implemented full-disk encryption (FDE) and physical security is sufficient for the job of anti-forensics. If more persistence is desired while keeping distribution size minimal, hardened variants of Arch, Void, Gentoo, or Alpine are advised.
One more factor to consider for the OS selection is the service manager being used. There are plenty of security enthusiasts who justifiably denounce the use of the SystemD service manager (used to spawn processes like networking, scheduled tasks, logging, etc). There are a variety of service managers that have less bloat and a more simple codebase - OpenRC, runit, etc. The fact that most of these OSs are open-source results in the problem of funding. A side-project that has peaked a developer's interest often go long durations (if not permanantly) without any efforts to maintain/patch. The best OS alternatives without systemD at the time of writing include Artix (Arch variant)[^5], Void Linux (Debian Variant)[^6], and Alpine Linux.[^7]
One more factor to consider for the OS selection is the service manager being used. There are plenty of security enthusiasts who justifiably denounce the use of the SystemD service manager (used to spawn processes like networking, scheduled tasks, logging, etc). There are a variety of service managers that have less bloat and a more simple codebase - OpenRC, runit, etc. The fact that most of these OSs are open-source results in the problem of funding. A side-project that has peaked a developer's interest often go long durations (if not permanantly) without any efforts to maintain/patch. Some recommended OS alternatives without systemD at the time of writing include Artix (Arch variant)[^5], Void Linux (Debian Variant)[^6], and Alpine Linux.[^7]
Note: Ideally, an operating system running a microkernel (minimal core) such as seL4 could be in the running. These alternatives are still too early to advise with little community support.
@ -376,7 +376,7 @@ While some of these proposed methods may be unconventional, these are unconventi
A physical wired dead man's switch reduces attack surface and intricacy. After the dead man's switch aka killswitch is configured, we can move on to the commands to issue. If we wanted to securely wipe the random access memory before shutting down, we could issue the "sdmem -v" command to verbosely clean the RAM as the killswitch is activated. The killswitch can be activated from a system event. Any form of shell command that is compatible with the particular GNU/Linux system can be ran based on a specified system behavior. See resources at the end of this section [^30], [^31], and [^32] for USB dead man's switch. In a nutshell, this is configured to watch system USB events. When a change occurs, the switch commands are invoked. Panic buttons are another form of a killswitch that essentially remains active on your display and is ready to select at any moment. (Centry.py[^33] is a good example of a panic button). There are USB devices known as "Mouse Jigglers" that are used by forensic teams after device seizure. These jigglers are serial devices plugged in to interface with the system to keep the screenlock from being invoked.
There are easy preventative software-based solutions such as USBCTL[^34] that can prevent these devices for operating, however this will likely be picked up on and human mouse jigglers can take their place. Ideally a process can be utilized to detect such a device and invoke a shutdown process. A mitigation for the human mouse jigglers could be implementing forced authentication every half hour to an hour. If the credentials have not been entered, the user session could be terminated, memory could be cleared, or the shutdown command could even be invoked.
Remote switches are interesting devils, and their utility should be in high consideration if the size of the operation warrants it. Panic buttons such as Centry.py can be used to broadcast or propagate a panic signal to all nodes on the network.
Remote switches are interesting devils, and their utility should be placed under high consideration if the size of the operation warrants it. Panic buttons such as Centry.py can be used to broadcast or propagate a panic signal to all nodes on the network.
## Play on Resources
Earlier, it was said that these groups have unlimited resources; this is not entirely true. The one resource which they lack is time. While they have infinite funds to allocate towards password and key cracking methods, so long as quantum physics strays behind computing, time is their main constraint. Taking methods from obscurity, the use of non-default encryption algorithms and hashing mechanisms for keys substantially increases the amount of time the analyst must expend on cracking. If the analyst cannot identify the hash function or cipher, they must try all possible options. Even if the correct password is obtained, this becomes useless without the proper cipher. For instance, Veracrypt uses over fifteen combinations of individual encryption algorithms and cascaded/stacked ciphers. Complement this with the five supported hash functions, and we are looking at 75 possible combinations of symmetric ciphers and one-way hash functions. As stated by ElcomSoft,[^35] "Trying all possible combinations is about 175 times slower compared to attacking a single combination of AES+SHA-512."
@ -498,11 +498,11 @@ While I could write mounds of literature diving into the depths of cryptocurrenc
## Defensive Mechanisms
System security or hardening is vital for successful operations. Lack of hardening could result in your machines being cut through like hot butter. Center for Internet Security (CIS)[^43] and Defense Information Systems Agency (DISA) with Standard Technical Implementation Guides[^44] both have decent system hardening standards that are to be applied to all DoD contractor, government, and affiliated nodes. For Linux and Unix systems, Kernel Self-Protection Project (KSPP)[^45] is a great resource for kernel configuration settings. More information about these configurations and concepts can be found at https://www.kernel.org/doc/html/latest/security/self-protection.html.
System security or hardening is vital for successful operations. Lack of hardening could result in your machines being cut through like hot butter. Center for Internet Security (CIS)[^43] and Defense Information Systems Agency (DISA) with Standard Technical Implementation Guides[^44] both have decent system hardening standards that are to be applied to all DoD contractor, government, and affiliated nodes. For Linux and Unix systems, Kernel Self-Protection Project (KSPP)[^45] is a great resource for kernel configuration settings.
Hardening procedures fall in line with the concept of minimizing architecture and running processes on a system. This makes each system easier to audit with less noise/clutter, and reduces the attack surface for exploitation. Hardening should encompass patches, scans with most recent virus definitions, restrictive permissions, kernel hardening, purging unnecessary software, and disabling physical ports, unnecessary users, filesystems, firmware modules, compilers, and network protocols.
System hardening is far from a quick and easy process, unless you have preconfigured images for systems. For small operations lacking technical prowess, preconfigured operating systems such as TAILS or Whonix mentioned in the Operating System section assure the greatest security and the least hassle.
If the goal is to run a more persistent lightweight OS with minimal functionality, I suggest running a variant of Arch Linux that does not use SystemD (Consider runit, OpenRC, or s6). If wide community support is needed, Arch with a hardened configuration will be your best bet. For the tech-savvy, hardened variants of Gentoo are ideal.
The more persistence desired for the operation increases the complexity of the hardening. Some projects have been introduced to rival Xen-based hypervisors with minimalist GNU/Linux systems. Some development towards Whonix Host[^46] was started but never seemed to come to fruition. PlagueOS[^47] is based on the Void musl build to with numerous hardening mechanisms. This is designed to act strictly as a locked down hypervisor with all system activities conducted inside of Kicksecure/Whonix VMs. The VMs also are restricted by AppArmor profiles and are ran inside a `bwrap`[^48] sandboxed container.
The more persistence desired for the operation increases the complexity of the hardening. Some projects have been introduced to rival Xen-based hypervisors with minimalist GNU/Linux systems. Some development towards Whonix Host[^46] was started but never seemed to come to fruition. PlagueOS[^47] is based on the Void musl build with numerous hardening mechanisms. This is designed to act strictly as a locked down hypervisor with all system activities conducted inside of Kicksecure/Whonix VMs. The VMs also are restricted by AppArmor profiles and are ran inside a `bwrap`[^48] sandboxed container.
Note:
The listed hardening is incomplete and will not fit all operations and GNU/Linux systems. This is not meant to be a book on methods for defensive cybersecurity.