Employment Fraud: Erkennen betrügerischer Bewerbungen auf Remote-Stellen im Unternehmen

Im ersten Blog dieser Reihe, „Imposters at the Gate: Spotting Remote Employment Fraud Before It Crosses the Wire“ (in englischer Sprache verfügbar) über die Erkennung betrügerischer Bewerbungen auf Remote-Stellen (engl. Remote Employment Fraud, REF) haben wir Strategien vorgestellt, mit denen ihr potenzielle Bedrohungsakteure bereits vor der Einstellungsphase aufspüren könnt. Wir haben die Ziele dieser Angreifer untersucht, die entscheidende Bedeutung der Erkennung vor der Einstellung hervorgehoben und betont, wie wichtig die enge Zusammenarbeit von Sicherheitsteams mit Personalabteilung, Personalbeschaffung und Einstellungsmanagern ist, um Frühwarnsignale zu erkennen.

Unsere Angreifer haben den Bewerbungsprozess erfolgreich überstanden, alle Kriterien der Personalabteilung erfüllt (ja, einschließlich der Hintergrundprüfung!)... und sind jetzt in eurem Netzwerk. Was nun? Dieser Blog behandelt die technischen Indikatoren, die REF-Akteure während des Onboardings und noch vor einem ausgewachsenen Sicherheitsverstoß entlarven. Macht euch bereit, zuverlässige Splunk-Erkennungen bereitzustellen, die Kontrolle über eure Onboarding-Pipeline zurückzugewinnen und diese Bedrohungen zu stoppen, bevor sie Schaden anrichten.

Bevor wir uns dem Code zuwenden, möchten wir einen wichtigen Hinweis vorausschicken: Zur Identifizierung dieser Bedrohungsart sind mehrere Indikatoren und Verhaltensmuster erforderlich. Bei jedem der folgenden Beispiele kann es auch legitime Gründe für das beschriebene Verhalten geben. Es ist wichtig, diese Beispiele im Zusammenhang mit anderen Aktivitäten zu betrachten. Zudem ist eine enge Zusammenarbeit mit den Teams eurer Personal- und Rechtsabteilungen unerlässlich. Wir empfehlen dringend, einen risikobasierten Ansatz zu verfolgen und verschiedene Indikatoren sowohl auf technischen als auch nicht-technischen Plattformen zu vergleichen, bevor ihr endgültige Schlüsse zieht. Risk-Based Alerting (RBA), eine Funktion von Splunk Enterprise Security, kann Teil der Lösung sein. Für RBA-Neulinge ist der Basisleitfaden Risk-based Alerting (RBA) von Splunk eine wertvolle Ressource, die zeigt, wie man RBA in der Splunk-Umgebung einrichtet. Der Einsatz von RBA bietet einen umfassenderen Überblick und gewährleistet eine vollständige Beurteilung, die eure Personal- und Rechtsabteilungen besonders schätzen werden. Vor diesem Hintergrund werden wir die technischen Erkennungsstrategien jetzt eingehender betrachten.

Abweichungen bei Laptop-Lieferungen

Eine automatisierte Erkennung vor der Einstellung von Mitarbeitern ist zwar unwahrscheinlich, die Onboarding-Phase bietet jedoch einzigartige Möglichkeiten, verdächtige Aktivitäten aufzudecken. So kann beispielsweise der scheinbar einfache Vorgang des Versands von IT-Geräten, wie etwa eines Laptops, schon wichtige Hinweise liefern.

In der Tech-Branche ist weithin bekannt, dass REF-Akteure häufig die Zustellung an Adressen wünschen, die nicht mit ihrem angegebenen Standort übereinstimmen, und dafür oftmals ausgeklügelte (und schwer zu überprüfende) Gründe vorbringen. Der Akteur liefert in der Regel eine Erklärung für eine solche Bitte, deren Überprüfung sich logistisch schwierig gestalten würde bzw. sogar mit einer Verletzung der Datenschutzrechte verbunden sein könnte (etwa ein medizinischer Notfall oder ein vorübergehender Umzug). Die Begründung für die Abweichung zwischen Standort und Zustelladresse für das Gerät ist vielleicht völlig legitim, doch in Verbindung mit anderen Verhaltensweisen könnte mehr dahinterstecken.

Es ist nicht immer leicht, solche Unstimmigkeiten zu erkennen. Eine manuelle Überprüfung ist zwar möglich, in großen Unternehmen jedoch nicht praktikabel. Splunk kann dazu beitragen, solche Unstimmigkeiten aufzudecken, indem es Daten aus Bewerbermanagementsystemen mit Laptop-Zustellungen korreliert. Jetzt ist der richtige Zeitpunkt, sich mit eurem Asset-Management-Team abzustimmen und mehr über den Bereitstellungs- und Versandprozess von IT-Assets für neue Mitarbeiter zu erfahren, um diese Daten in euer Splunk-System zu integrieren. Darüber hinaus benötigt ihr Daten über Neuzugänge in eurem Unternehmen: Diese könnten sich in einem Bewerbermanagementsystem oder einem anderen Repository für zukünftige Mitarbeiter befinden.

Die folgende Abfrage verwendet Daten aus einer ServiceNow-Instanz, die mit den Workday-Informationen eines Mitarbeiters verknüpft ist, um festzustellen, wann ein potenzieller Mitarbeiter einen Laptop an einen Ort liefern lassen möchte, der von seinem angegebenen physischen Standort abweicht.

Abfrage zu abweichender Lieferadresse für Laptop-Lieferungen

index=servicenow sourcetype=laptop_shipment ```laptop shipment data```
| eval delivered_location=case(arrivalState="CA","California", arrivalState="TX","Texas", arrivalState="WA","Washington",arrivalState="VA","Virginia",arrivalState="OR","Oregon") ```specify the most commonly shipped to locations for string matching```
| table name Shipped_status arrivalTime employeeId Email home_state postalCode arrivalState delivered_location arrivalLocation
| join type=outer Email ```compare laptop shipment data joining on employee's email with employee record data. If employee does not have email yet, then the employee ID could also be used to correlate```
    [ search index=identity sourcetype=workday:employee earliest=-24h ```log source for employee record data```
    | dedup name employeeId home_state]
| search delivered_location=*
| eval Suspicious=if(delivered_location==home_state,"No","Yes") ```if the laptop was delivered to a state that does not match their registered home address```
| search Suspicious="Yes"

Der oben abgebildete Screenshot zeigt das Beispiel eines Benutzers, der angibt, in Pennsylvania zu wohnen, während die von ihm angegebene Lieferadresse in Oregon liegt. In Splunk Enterprise wurde ein Feld namens „Suspicious“ erstellt, das anzeigt, wenn das Feld „home_state“ des Benutzers nicht mit dem Feld „delivered_location“ übereinstimmt. Dieses Beispiel ließe sich problemlos auf weltweite Lieferungen ausweiten und an die Anforderungen eures Unternehmens anpassen.

Datenverkehr von nicht standardmäßigen VPN-Anbietern

REF-Akteure nutzen häufig virtuelle private Netzwerke (VPNs), um ihren tatsächlichen physischen Standort zu verschleiern. Sie verbergen ihre Ursprungs-IP-Adresse und geben vor, sich an einem Ort zu befinden, an dem der VPN-Dienst einen Knotenpunkt betreibt. Dies ist einer von mehreren Indikatoren, die sich mit technischen Mitteln erkennen lassen, sobald der Angreifer ein Firmengerät besitzt.

VPNs verbergen zwar die echten IP-Adressen der REF-Akteure, erzeugen aber gleichzeitig ein neues Signal, nämlich unerwarteten Datenverkehr von VPN-Anbietern. Doch was tun, wenn es in eurem Unternehmen Remote-Mitarbeiter gibt, die ganz legitim VPNs nutzen? Hier kommen Baselining und Ausnahmebehandlung ins Spiel (mehr dazu unten). Ihr könnt den Netzwerkverkehr von verdächtigen VPN-Anbietern mithilfe der Logs eures Identitätsanbieters (IDP) mit einigen wenigen Schritten ganz leicht beobachten. Das folgende Beispiel zeigt, wie mithilfe von Okta-Daten nach gängigen VPN/VPS-Anbietern gesucht wird.

Anfrage zu nicht standardmäßiger VPN-Nutzung

index=okta sourcetype=OktaIM2:log ```enter your IdP log source``` debugContext.debugData.tunnels IN (*Astrill*,*Azire*,*CyberGhost*,*Express*VPN,*HideMe*,*IPVanish*,*Mullvad*,*Nord*VPN*,*OVPN*,*PIA*VPN*,*Proton*VPN*,*Pure*VPN*,*Slick*VPN*,*Surf*Easy*,*SurfShark*,*Star*VPN*,*TorGuard*,*TorProxy*,*Tiger*VPN*,*TunnelBear*,*Unblock*VPN*,*Warp*VPN*,*WarpSpeed*,*VPNReactor*,*VPN*Shield*,*VPN*Super*VPN*,*ZenMate*) ```listing of commonly used known VPN providers. Add or remove whatever is appropriate for your environment```
| eval user=coalesce('actor.alternateId',user), user=mvindex(split(user, "@"), 0)
| rename targetUserAlternateId as user client.* as * request.* as * ipChain{}.* as * geographicalContext.* as * debugContext.* as * debugData.* as *
| eval status=case(match(_raw, "FAILURE"), "failure", !match(_raw, "FAILURE"), "success")
| stats count values(status) as status max(published) as UTC min(_time) as firsttime max(_time) as lasttime values(target_data) as target_data values(displayMessage) as displayMessage values(eventType) as eventType values(city) as city values(country) as country values(action) as action values(src_ip) as src_ip values(outcome.*) as * values(user) as user by tunnels,_time,host sourcetype index
| fillnull value="N/A"
| convert ctime(*ttime)
    ```| where isnotnull(user)``` ```uncomment this line if you only want to see events where an actual user was recorded in the IdP```

Die oben angegebene Liste von VPN-Anbietern ist nicht vollständig. Es empfiehlt sich, eure Liste bekannter und genutzter VPNs regelmäßig zu aktualisieren. Um eine Liste der am häufigsten verwendeten VPNs zu erstellen, könnt ihr eure Logs danach durchsuchen.

Auch euer Identitätsanbieter kann euch hierbei möglicherweise unterstützen! Viele der gängigen IdPs ermöglichen es, Datenverkehr von bekannten VPN-Anbietern zu blockieren, der eventuell nicht mit den Unternehmensrichtlinien übereinstimmt. Die nachfolgenden Screenshots aus der Okta- und Duo-Konsole zeigen Beispiele dafür, wie und wo VPN-Anonymisierungs-Traffic blockiert werden kann. In Okta wird dieser Blockierungsmechanismus als Netzwerkzone definiert und kann nach der Konfiguration dazu verwendet werden, VPN-Datenverkehr abzulehnen. In Duo können analog dazu autorisierte Netzwerke konfiguriert werden, um einen ähnlichen Effekt zu erzielen.

Okta-Verwaltungsschnittstelle mit Netzwerkzone und Blockadekonfiguration

Dieses Beispiel des IdP Duo zeigt, dass anonymen Netzwerkanbietern (VPN) der Zugriff verweigert werden oder vor weiteren Schritten ein zweiter Authentifizierungsfaktor gefordert werden kann.

Unwahrscheinliche Reisen

Geolokalisierungsdaten können ungenau sein und lassen sich von REF-Akteuren leicht fälschen. Doch REF-Akteure machen manchmal Fehler und verraten ihren wahren Standort, wodurch sogenannte „unwahrscheinliche Reise“-Szenarien entstehen – also z. B. Anmeldungen von Standorten an entgegengesetzten Enden der Welt innerhalb weniger Minuten. Die Sache hat allerdings einen Haken: Diese Erkennung erfordert eine sorgfältige Feineinstellung. Ihr wollt ja nicht gleich den Vertriebsdirektor an den Pranger stellen, nur weil er für ein Meeting von New York nach London gereist ist. Konzentriert euch auf neu eingestellte Mitarbeiter, die normalerweise nicht so bald nach ihrem Einstieg schon geschäftlich reisen würden.

Wir können sogar noch weiter gehen und auf inkonsistente oder unwahrscheinliche Reisen prüfen, die den tatsächlichen physischen Standort der Bedrohungsakteure offenlegen. Dies kommt zwar wahrscheinlich nicht oft vor, sollte aber dennoch überwacht werden. Es gibt zahlreiche Quellen für Logs, anhand derer ein unwahrscheinlicher geografischen Standort für einen Benutzer oder Datenverkehr erkannt werden kann, der über ungewöhnliche Standorte geleitet wird. Zu den wesentlichen Log-Quellen gehören: IdP-Logs (Okta, Duo, Azure etc.), Firewall-Logs (Cisco, Palo Alto, Fortinet, Checkpoint etc.), EDR-Logs (Crowdstrike, Cisco CSE, FireEye, SentinelOne etc.) und Logs von Chat-Plattformen (Zoom, Webex, Teams, Google Meet etc.).

Die folgende Abfrage verwendet das Authentifizierungsdatenmodell und Splunk Enterprise Security zum Aufspüren unwahrscheinlicher Reisen: Dazu werden ungefähre Werte für Geschwindigkeit und Entfernung ermittelt, die der Benutzer erreichen bzw. zurücklegen müsste, um sich innerhalb des angegebenen Zeitfensters von unterschiedlichen geografischen Standorten aus anzumelden bzw. zu arbeiten. Anschließend werden die Ergebnisse genauer geprüft, bei denen die Geschwindigkeit und Entfernung über einem von euch festzulegenden Schwellenwert liegen. Die nachfolgende Abfrage beinhaltet eine umfassende SPL-Sequenz. Ihr müsst sie zwar an eure spezifische Umgebung anpassen, könnt die zugrunde liegenden Berechnungen und die Logik jedoch auch mit euren eigenen Daten verwenden.  Wir empfehlen, eure Abfragen für die Ausführung in eurer Umgebung anzupassen, indem ihr beispielsweise Schwellenwerte für die Geschwindigkeit oder Entfernung festlegt.

Abfrage zu geografisch unwahrscheinlichem Standort

| tstats summariesonly=true values(Authentication.app) as app from datamodel=Authentication.Authentication where ((index="okta" AND sourcetype="OktaIM2:log") OR (index="firewall" AND sourcetype="pan:globalprotect")) ```enter your appropriate Auth log sources, and ensure Authentication Datamodel is being used and accelerated``` AND Authentication.action="success" AND Authentication.app IN ("Workday", "Slack", "*GlobalProtect", "Jira*", "Atlassian Cloud", "Zoom") AND NOT Authentication.user="unknown" by _time index sourcetype host Authentication.user Authentication.src span=1s ```pick what Apps are important to you to monitor geographic improbable access. These are some examples```
| `drop_dm_object_name("Authentication")`
| fields user,src,app,_time,count,host
| eval user=lower(replace(user, "((^.*\\\)|(@.*$))", "")) ```normalize how user appears```
| join type=outer user
    [| inputlookup identity_lookup_expanded where user_status=active ```Asset and Identities lookup from Splunk Enterprise Security that holds all identities and their respective information```
| rex field=email "^(?<user>[a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$"
| rename email as user_email bunit as user_bunit priority as user_priority work_country as user_work_country work_city as user_work_city
| fields user user_email user_bunit user_priority user_work_country user_work_city]
| eventstats dc(src) as src_count by user
| eventstats dc(user) as user_count by src
| sort 0 + _time
| iplocation src
| lookup local=true asn_lookup_by_cidr ip as src OUTPUT ip asn description ```lookup that comes with Splunk that tracks ASN information```
| eval session_lat=if(isnull(src_lat), lat, src_lat), session_lon=if(isnull(src_long), lon, src_long), session_city=if(isnull(src_city), City, src_city), session_country=if(isnull(src_country), Country, src_country), session_region=if(isnull(src_region), Region, src_region)
| eval session_city=if(isnull(session_city) OR match(session_city,"^\s+|^$"), null(), session_city), session_country=if(isnull(session_country) OR match(session_country,"^\s+|^$"), null(), session_country), session_region=if(isnull(session_region) OR match(session_region,"^\s+|^$"), null(), session_region)
| where isnotnull(session_lat) and isnotnull(session_lon)
| eval session_city=if(isnull(session_city),"-",session_city), session_country=if(isnull(session_country),"-",session_country), session_region=if(isnull(session_region),"-",session_region)
| streamstats current=t window=2 earliest(session_region) as prev_region,earliest(session_lat) as prev_lat, earliest(session_lon) as prev_lon, earliest(session_city) as prev_city, earliest(session_country) as prev_country, earliest(_time) as prev_time, earliest(src) as prev_src, latest(user_bunit) as user_bunit, earliest(app) as prev_app values(user_work_country) as user_work_country by user
| where (src!=prev_src) AND !(prev_city=session_city AND prev_country=session_country) AND ((isnotnull(prev_city) AND isnotnull(session_city)) OR prev_country!=session_country) ```looking for when the previous IP and current IP do not match, or the previous city and current city do not match, or previous country and current country do not match```
| `globedistance(session_lat,session_lon,prev_lat,prev_lon,"m")` ```built in command to help calculate distance```
| eval time_diff=if((_time-prev_time)==0, 1, _time - prev_time)
| eval speed = round(distance*3600/time_diff,2)
| eval distance= round(distance,2)
| eval user_work_country=case(user_work_country="usa","United States", user_work_country="cze","Czechia",user_work_country="pol","Poland", user_work_country="ind","India", user_work_country="fra","France", user_work_country="can","Canada", user_work_country="mys","Malaysia", user_work_country="kor","South Korea", user_work_country="aus","Australia", user_work_country="bel","Belgium", user_work_country="dnk","Denmark", user_work_country="bra","Brazil", user_work_country="deu","Germany", user_work_country="jpn","Japan", user_work_country="che","Switzerland", user_work_country="swe","Sweden", user_work_country="zaf","South Africa", user_work_country="irl","Ireland", user_work_country="ita","Italy", user_work_country="nor","Norway", user_work_country="gbr","United Kingdom", user_work_country="hkg","Hong Kong", user_work_country="chn","China", user_work_country="esp","Spain", user_work_country="nld", "Netherlands", user_work_country="twn","Taiwan", user_work_country="est","Estonia", user_work_country="sgp","Singapore", user_work_country="are","United Arab Emirates", 1=1,"N/A") ```popular countries that appeared in IdP logs and normalized them to their fullname```
| lookup local=true asn_lookup_by_cidr ip as prev_src OUTPUT ip as prev_ip asn as prev_asn description as prev_description
| eval suspect=if(!user_work_country==session_country,"Sketchy","Normal") ```determing if a user's work country matches their current country```
| search (speed>500 AND distance>750) ```this should be geographically improbable within the given time period```
| table _time,prev_time,user,host,src,prev_src,app,prev_app,distance,speed,suspect,session_city,session_region,session_country,prev_city,prev_region,prev_country,user_priority,user_work_*,prev_ip,ip,asn,prev_asn,prev_description,description
| rename _time as event_time
| convert ctime(event_time) timeformat="%Y-%m-%d %H:%M:%S"
| convert ctime(prev_time) timeformat="%Y-%m-%d %H:%M:%S"
| eval problem=if(!session_country==prev_country AND (!session_country==user_work_country),"Yes","Nope")
| search NOT (prev_city="-" OR session_city="-") AND NOT
    [inputlookup known_devices_public_ip_filter.csv
    | fields ip
    | rename ip as src]  ```add lookup of known IPs to remove False Positives```
| dedup user host prev_src src
| fillnull value="N/A"
| search problem="Yes"

Virtuelle Audio- und/oder Videogeräte  

Es wurde festgestellt, dass Angreifer eine Kombination aus virtuellen Audio- und Videogeräten einsetzen, um ihren tatsächlichen Standort bei Anrufen über Cisco Webex, Zoom oder Microsoft Teams zu verbergen. Dies erweckt den Anschein, als kämen Audio- und Videoanrufe von einem Standort, der mit dem des Mitarbeiters oder Bewerbers übereinstimmt, während der Angreifer den Audio- und Videodatenverkehr in Wirklichkeit von seinem tatsächlichen physischen Standort über einen Zwischenstandort (wahrscheinlich eine Laptop-Farm) weiterleitet.

Für die Erkennung solcher Aktivitäten sind sorgfältige Analysen, eine regelmäßige Überprüfung und ein umfassender Überblick über die üblicherweise in eurer Umgebung eingesetzten Audio- und Videogeräte notwendig. Der Schlüssel zur Erkennung liegt hier darin, zunächst Basiswerte für eure Umgebung zu ermitteln, um dann Ausreißer zu erkennen. (Beispiel: Ein brandneuer Mitarbeiter nutzt plötzlich eine virtuelle Kamera, die sonst niemand im Unternehmen verwendet.) Auch Auditlogs aus Telekonferenz- und Zusammenarbeits-Tools wie Zoom, Cisco Webex und Microsoft Teams können dazu beitragen, die von den REF-Akteuren verwendeten Geräte zu ermitteln. Die nachfolgende Suche kann helfen, nicht standardmäßige oder atypische Video- und Audiogeräte zu identifizieren, die auf solchen Plattformen eingesetzt werden.

Abfrage seltener Audio-/Video-/Streaming-Geräte

index=zoom      sourcetype=zoom:metrics:meetings:participant ```input appropriate audio/video log source``` camera=* microphone=* speaker=*  ```looking for logs that contain information about camera, microphone, and speakers that are being used``` NOT (camera=*iPhone* OR camera="*FaceTime*" OR speaker="*AirPods*" OR camera="*MacBook*" OR microphone="*MacBook Pro Microphone*") ```Usually REF actors will use a combination of camera/microphone/speakers that are unique in the environment. Regardless if a Mac or Windows is used, there will typically be at least one odd indicator of tooling that is not commonly seen across the general employee user base``` ```use the rare command one at a time to scope cameras, microphones and speakers. Uncomment each line when needed below, and ensure only one rare command is uncommented at once```
| rare camera limit=50 ```search to show top 50 rarest cameras```
```| rare speaker limit=50```
```| rare microphone limit=50```
```once you know what the rarest speakers, cameras and microphones are, you can specify them in the search directly```

Je nachdem, welcher Akteur gerade für die Mitarbeiter-Persona zuständig ist, kann ein REF-Akteur Zwischenstationen nutzen, um seinen oder den Standort seines Firmengeräts zu verschleiern. Ihr könnt dies durch sorgfältiges Prüfen und Korrelieren relevanter Logs feststellen. Das Korrelieren der Logs mehrerer Plattformen wie Zoom und Workday HR ist standardmäßig eine bewährte Methode zur Erkennung von Diskrepanzen. Im folgenden Codebeispiel wurden Zoom-Logs zusammen mit den HR-Logs eines Benutzers (aus Workday) verwendet.

Abfrage seltener Audio- und Video-Geräte mit Inkonsistenzen beim scheinbaren physischen Standort

index=zoom sourcetype=zoom:metrics:meetings:participant ```input appropriate audio/video streaming log source``` camera="*Stream*"  (speaker="*Headphones*" OR speaker="*DarkStar*" OR microphone="*Tiny*")   ```Declare any known rare combos of cameras, microphones, or speakers that are uncommon in your environment. These are examples```
| table join_time leave_time leave_reason speaker camera location microphone user_name role pc_name email ip_address
| where isnotnull(role) ```only show results where a user is either an attendee or a host in a Zoom meeting```
| stats count min(join_time) as join_time max(leave_time) as leave_time values(pc_name) as pc_name values(leave_reason) as leave_reason by ip_address speaker camera location microphone user_name role email ```location is in logs but it's generic so we also use iplocation on ip_address```
| iplocation ip_address
| rename email as work_email
| join type=outer work_email
    [ search index=identity sourcetype=workday:employee earliest=-24h ```join to HR data, in this case data from Workday```
    | spath All_Work_Addresses output=Workday_location
    | spath primaryWorkEmail output=work_email
    | spath Employee_ID output=employeeNumber
    | spath Preferred_Name output=name
    | spath "Location_Address_-_State__United_States_" output=state  
| table Workday_location name state work_email employeeNumber
| dedup name employeeNumber state]
| eval problem=if(Region==state,"No","Yes") ```Region comes from iplocation on the IP address in Zoom and state comes from Workday logs```
| search problem="Yes" Workday_location=* ```Find results where there is no match```
| fields - lat lon
| table ip_address speaker camera microphone location City Country Region state Workday_location problem ```work_email hidden from results for privacy reasons```

Wie die nachfolgenden Beispiel-Suchergebnisse zeigen, befinden sich die REF-Mitarbeiter laut den Zoom-Logs in Kalifornien und Virginia. In Workday wird dagegen entweder Texas, Maryland oder Idaho als Standort der Mitarbeiter angegeben. Für den HR-Standort Idaho gibt es keinerlei Übereinstimmung mit den Zoom-Logs aus Idaho. Stattdessen wird für diesen potenziellen REF-Mitarbeiter der Standort Kalifornien und nicht Idaho angegeben. Das Feld „problem“ wurde erstellt, um anzuzeigen, dass es eine geografische Diskrepanz zwischen dem Standort des Zoom-Geräts eines Mitarbeiters und seinem registrierten HR-Standort gibt.

Beispielereignisse, die inkonsistente Mitarbeiterstandorte zeigen

Hohe Videolatenz beobachtet

Eine tiefer greifende Untersuchung des Netzwerkverkehrs, speziell aus Videokonferenzanwendungen, kann hilfreich sein, um andere Beobachtungen zu untermauern. In einigen Fällen wurde bei diesen Bedrohungsakteuren eine besonders hohe Latenz beobachtet, die weit über dem gängigen Latenzwert der meisten anderen Mitarbeiter lag. Latenzzeiten können zwar auch einfach ein Zeichen für eine langsame Netzwerkverbindung sein, doch in Kombination mit anderen Indikatoren liefern sie ein weiteres Puzzlestück für das Gesamtbild. REF-Mitarbeiter verwenden meist verschiedene Arten von Streaming-Software auf ihren Computern, an einem entfernten Standort und oft über Laptop-Farmen als Zwischenstation, was zu Latenz, niedrigen Bildraten oder sehr niedrigen Auflösungen führen kann. Häufig arbeiten die von den REF-Mitarbeitern genutzten Laptop-Farmen mit verschiedenen Zwischenstationen oder ändern ihre Taktik, was wiederum die Erkennung erleichtert. Im nachfolgenden SPL-Code wurden Basiswerte für die Umgebung ermittelt und festgestellt, dass eine Videolatenz von 150 ms ziemlich hoch und ungewöhnlich ist. Erhöht man diesen Wert auf 300 ms, stechen Ausreißer noch deutlicher hervor. 

Abfrage zu hoher Videolatenz

index=zoom  ```use appropriate audio/video data source```
| spath "payload.object.participant.qos{}.type"
| search "payload.object.participant.qos{}.type"=video_input ```focus on video input, as that's what would register lag in the most obvious manner```
| rename payload.object.participant.qos{}.details.avg_latency as avg_latency "payload.object.participant.qos{}.details.latency" as latency payload.object.participant.email as email
| rex field=avg_latency "(?<average_latency>\d+) ms"
| rex field=latency "(?<overall_latency>\d+) ms"
| search email="*@splunk.com" ```put in correct company email domain```
| table email overall_latency latency avg_latency average_latency _raw
| stats latest(overall_latency) as overall_latency by email _raw
| where overall_latency>300 ```150ms of latency should be very noticable to end user```

Verschiedene Möglichkeiten von Remote-Zugriffs-Tools

Remote-Zugriffs-Tools bieten Bedrohungsakteuren Möglichkeiten durch mehrere Funktionen. Diese Tools haben ähnliche Funktionen, wie etwa Dateiübertragung, Fernsteuerung eines Systems und Geräteumleitung. Ein REF-Akteur kann diese Funktionen nutzen, um verschiedene Ziele innerhalb des Netzwerks zu realisieren, etwa das Exfiltrieren von Dateien, das Installieren von Malware und die Remote-Arbeit im System, um seinen Standort zu verbergen. Der Einsatz dieser Software kann auf ähnliche Weise erkannt werden. Manche Unternehmen besitzen Lizenzen für Remote-Zugriffs-Tools wie Splashtop der TeamViewer, es wird also die kostenpflichtige Version genutzt und das Unternehmen trägt die Kosten. Kostenpflichtige Tools mit Lizenzen sind bei REF-Angriffen eher selten. Es ist wichtig, durch Baselining einer Umgebung festzustellen, welche Remote-Zugriffs-Tools oder -programme zugelassen bzw. verboten sind. Die beste Möglichkeit, diese Vorgehensweise zu verhindern, besteht darin, die Ausführung der Anwendung auf einer Workstation von vornherein zu blockieren, indem man Jamf/JumpCloud/Intune/AppLocker oder sogar EDRs wie Crowdstrike/SentinelOne/Cisco CSE usw. einsetzt.

Anhand allgemein verfügbarer Listen von Remote-Zugriffs-Tools könnt ihr Endpunktlogs nach der Verwendung nicht genehmigter Tools durchsuchen. Stellt fest, welche Tools in eurer Umgebung verboten bzw. erlaubt sind, und führt dann Abfragen eurer EDR-Daten durch, um festzustellen, ob jemand diese Tools verwendet hat. Es folgen einige Beispiele für GitHub-Repositorys mit den Namen dieser Art von Apps.

• https://github.com/jischell-msft/RemoteManagementMonitoringTools
• https://github.com/0x706972686f/RMM-Catalogue/blob/main/rmm.csv
• https://github.com/LivingInSyn/RMML/tree/main/RMMs
• https://github.com/magicsword-io/LOLRMM/tree/main/yaml

Hinweis: Diese Repositorys sind zwar hervorragende Ressourcen für Listen mit Remote-Zugriffs-Tools, doch sie veralten mit der Zeit. Ihr solltet auf jeden Fall den Ursprung sorgfältig prüfen und ihnen nicht blind als Allheilmittel vertrauen.

Abfrage von Remote-Zugriffs-Tools

index=edr* sourcetype=crowdstrike:falcon:fdr:* CommandLine ```input appropriate EDR log source that contains CommandLine and Process Application information``` IN (
    *Splashtop*,
    *LogMeIn*) ```these are just examples. Recommendation is to pull a full list of RMM tools from various Git Repos and input the names inside of the IN statement``` OR AppName IN (*Splashtop*,
    *LogMeIn*) ```input the same examples above here``` ```exclude any known processes or Apps```
| eval App=coalesce(AppName,ParentBaseFileName) ```combine the appname and parent file name if known```
| fillnull value="null"
| stats values(App) as App by AppName event_simpleName ParentBaseFileName ImageFileName CommandLine ```aggregate on eventtype, Commandline, process, parent process, and App name```
| convert ctime(*time)
| sort 0 + f_time
| stats count values(ParentBaseFileName) as ParentBaseFileName values(CommandLine) as CommandLine by event_simpleName App
| table App event_simpleName ParentBaseFileName CommandLine

Betrachten des Gesamtbilds

Wir möchten noch einmal betonen, dass isoliert betrachtet keine der oben beschriebenen Strategien die Existenz von REF in eurem Unternehmen nachweisen kann. Ihr solltet vielmehr mehrere Indikatoren zusammen bewerten, um eine zuverlässigere Beurteilung zu erhalten.

RBA eignet sich für diesen Use Case ganz hervorragend. Es ermöglicht eurem Unternehmen, Indikatoren zu aggregieren und Verhaltensmuster zu beobachten, die eventuell vom Verhalten typischer Remote-Mitarbeiter abweichen. In weiteren Schritten können diese Einzelfälle genauer untersucht werden. Dabei können nicht-technische Indikatoren berücksichtigt und in Zusammenarbeit mit euren Personal- und Rechtsabteilungen eine ganzheitlichere Beurteilung vorgenommen werden.

Ihr verfügt jetzt über leistungsstarke Splunk-Erkennungen, die euch helfen, REF-Akteure schon während der Onboarding-Phase und auch später noch zu identifizieren. Angriffstechniken entwickeln sich zwar ständig weiter (das liegt in der Natur der Sache), aber der Einsatz von Erkennungsmechanismen ist ein entscheidender erster Schritt. Und wenn man weiß, wonach man suchen muss, ist das bereits die halbe Miete.

Mit der nächsten Herausforderung – der Reaktion – wird die Sache dann komplex, vor allem, wenn es um die Navigation im Dschungel aus HR- und Rechtsvorschriften geht. Im Gegensatz zu den üblichen technischen Bedrohungen erfordert die Reaktion auf REF-Angriffe Zusammenarbeit in einem für viele Tech- und HR-Teams ungewöhnlichen Maß. Im letzten Blog dieser Reihe betrachten wir, wie wir bei Splunk in enger Zusammenarbeit einen Prozess entwickelt haben, mit dem wir REF-Fälle identifizieren, recherchieren, bewerten und eskalieren können. Hierzu stellen wir eine schrittweise Anleitung für die Erarbeitung eines funktionsübergreifenden, praxistauglichen Reaktionsplans vor. Das solltet ihr nicht verpassen.